Arquivo

Posts Tagged ‘Projetos’

Modelos: BGP, Internet e outros componentes

 

Instead of trying to impress the reader with what I know,
I try to explain why the things I’ve learned impress me.

Donald Knuth, aqui

 

Introdução

 

Este é o terceiro da série (imagino, longa) de artigos necessários para consolidar as ideias do projeto sobre Objetos de Projeto Estendido (OPE)1. Na sequência do primeiro artigo foi apresentada a MEF (Máquina de Estado Finito) do BGP1. O modelo da MEF foi construído com base na descrição fundamental, isto é, a RFC42714.

Um dos mais importantes componentes dos artigos são os modelos. Via de regra abstratos e produzidos por imagens ou figuras, eles são acompanhados de uma descrição para que se desfaça algumas confusões mentais. A noção de modelos, tal qual se imagina é descrita, a seguir.

 

Modelos

 

Modelos tem sido explorados por muitos pesquisadores e autores. Particularmente, por Scott E. Page5, 6 e 7, em seus inúmeros textos além dos citados. Por exemplo, em seu curso Model Thinking. Professor Scott5 chama a atenção para fatos interessantes, sobre modelos:

  • Quando mais você conhece o contexto, mais seu modelo se aproxima da realidade.
  • Modelos devem ser aperfeiçoados, isto é, refinados de forma sistemática.
  • Nenhum modelo é perfeito. O modelo da MEF do BGP se aproxima mais da realidade quando damos nomes aos arcos com o objetivo de descrever, compreender e garantir sua consistência.
  • Muitas vezes, principalmente em sistema com razoável complexidade, precisamos de vários modelos para descrevê-lo. É o caso do BGP. A MEF não modela o BGP como um todo, mas sim uma parte dele que é o automato finito para que a conexão seja estabelecida. A figura e a respectiva descrição2 representam, por outro lado, uma parte da MEF do BGP. Está faltando o comportamento do autômato finitoo (ou MEF), no que diz respeito às mensagem recebidas, que está disponível no livro do Stewart8.
  • Sistemas como a MEF do BGP tendem a permitir a construção de modelos bem representativos do seu comportamento. Em sistema mais complexos isto só será possível com um conglomerado (ou nuvem) de modelos. O próprio BGP é um sistema muito complicado, como já foi dito. A MEF é um componente, simples, do BGP. Para entender o BGP, como um todo, precisamos de vários modelos. Até mesmo vários modelos de autômatos finitos. por exemplo, para que o BGP funcione, os pares precisam estar conectados. A conexão é feita em TCP. A modelagem de uma conexão TCP exige um outro autômato finito. Veremos isto mais à frente.
  • Há três equívocos comuns cometidos por pessoas, sobre modelos:
    1. Pessoas acreditam piamente em modelos.
    2. Algumas pessoas desacreditam os modelos, por razões políticas.
    3. Pessoas confundem modelos com o que foi produzido por eles. Algo como considerar o BGP como sendo a MEF. Ou, mais simplesmente, como diz Scott, a árvore com a madeira.

Dependendo das ferramentas utilizadas, modelos podem ser complicados para entendermos. É o caso de modelos mais formais onde matemática e física são utilizadas. O próprio Scott6, exibe um formalismo para modelar o comportamento de redes, em geral, com aplicações na Internet, na sociologia, nas finanças e em muitas outras áreas do conhecimento. O formalismo matemático apresentado pelo Professor Scott é necessário para manter o rigor da modelagem e permitir a verificação do desempenho de um modelo usando ferramentas computacionais. As dificuldades podem ser vistas no que o eminente físico Richard Freynman disse para Leonard Mlodinow, [9, página 54]: …eu jamais deveria pensar que compreendi um trabalho de física se tudo o que fiz foi ler a prova de outra pessoa. A única maneira de realmente entender uma teoria, afirmou, é refazer a prova por conta própria – quem sabe você não acaba refutando a teroria? … No mesmo parágrafo, Mlodinow lembra, também, que um professor de Harvard, especializado em probabilidade e estatística disse, a propósito de dificuldades de pessoas e bons matemáticos não conseguirem identificar o erro em algo aparentemente óbvio: …Nosso crérebro não foi muito bem projetado para resover problemas de probabilidade. …

 

O problema de Monty Hall

 

Leonard Mlodinow, faz as citações acima no capítulo 3 do seu incrível livro, páginas 50-68: Encontrando o caminho em meio a um espaço de possibilidades. É a abordagem sobre um programa de televisão apresentado por Monty Hall (nos períodos de 1963-1976 e 1981-1991), uma famosa colunista chamada Marilyn vos Savant (maior QI já registrado no planeta, segundo o Guiness), o brilhante matemático Paul Erdös e uma imensa parcela do povo americano.

Se você ouvir o Scott E. Page falar sobre o problema das três portas de Monty Hall, e em seguida responder a um questionário, este poderá ser apenas uma tentativa. Isto porque, naquele momento você não está acostumado com a Lei do Espaço Amostral, lembrada inicialmente por Gerolamo Cardano, no século XVI. Vejamos o problema, as consequências para Marilyn e sua coluna “Ask Marylin”, Paul Erdös, um pedaço do povo americano e você, ao assistir a aula de Scott.

Com pequenas modificações, ao invés de portas, teremos três caixas de chapéus idênticas e indevassáveis (digamos, chapéus de inglesas abastadas). Elas são grandes o suficiente para caber, em uma delas, o roteador dos seus sonhos (valor em torno de $50,000.00). Nas outras duas caixas serão colocadas “switches” usados, que não necessariamente funcionam, cujo preço de novos está em torno de R$50,00, cada um (“hubs”, talvez). Como a Figura 1, que segue.

 

Figura 1. Três caixas de chapéus enormes, idênticas e indevassáveis. (Desenhadas pelo autor)

 

Se olharmos as caixas com visão de raios X teremos algo parecido com a Figura 2. Esta é a visão do apresentador, que sabe qual caixa contem roteador e quais as duas que contem os equipamentos usados. Este é um fato importante que qualifica o apresentador para interferir no processo da escolha feita pelo competidor (ou você).

 

Figura 2. Conteúdo das caixas de chapéus, vistas com visão de raios X. (Desenhadas pelo autor)

 

O esquema é o seguinte: Você escolhe uma caixa. O apresentador irá então interferir no processo, abrindo uma das caixas que contem um equipamento usado. A seguir ele lhe pergunta se você quer trocar ou não a sua escolha original. O que você deve fazer? Permanecer na caixa escolhida ou trocar de caixa (só tem mais uma para a troca). Em outras palavras, você tem duas caixas a escolher, o que significa que você tem 50% de ganhar o roteador. O que fazer? Continuar na escolha original ou trocar?

Fizeram a mesma pergunta no “AskMarilyn”. Marilyn afirmou em sua coluna que o melhor seria mudar a escolha! Marilyn recebeu cerca de 10.000 cartas reagindo contra sua posição de trocar a caixa original. Também, quase 1.000 matemáticos, aparentemente irados, com a posição de Marilyn. Paul Erdös, em particular, foi agressivo: “Impossível!”, afirmou ele. Foi tão brutal, o impacto que Marilyn parou de discutir o tema. Até que ficou provado que Marilyn estava correta. Paul Erdös só se convenceu depois de avaliar uma simulação feita por computador que mostrou a resposta correta de Marilyn, e admitiu estar errado. Na realidade, quando você tinha de escolher, inicialmente, uma das três caixas, sua chance de coincidir com a caixa do roteador era de 1/3. Mas, quando o apresentador interferiu no processo que era aleatório ele alterou o estado da probabilidade. Melhor dizendo, você sabe que uma das caixas (ela foi aberta!), portanto tem de escolher 2 entre três (2/3!). Dobrou a probabilidade de acertar! Então, troque, pois sua escolha inicial foi com a chance de 1/3! Leonard Mlodinow é perfeito na descrição do problema, no capítulo 3 de seu livro. O modelo (Oops, figura?) exibido na Figura 3 nos dá a noção precisa de nossas escolhas em cada uma das alternativas.

 

Figura 3. Esquema de Monty Hall (adaptado pelo autor)

 

 

Modelando uma conexão BGP

 

Quando estabelecemos uma rede interna, usando o TCP/IP, ou em outras palavras, usando IPv6 ou IPv4 (hoje estamos preferindo o IPv6), nosso cenário é como o da Figura 4. É necessário que nossa LAN (rede local) tenha um “gateway” que seja capaz de receber pacotes em IPv6 de algum equipamento de origem e os encaminhe de volta para a LAN, na direção do destino, na mesma LAN. Este modelo não é único, pois neste caso, o “gateway” pode ser um simples “switch”. Estamos colocando um “gateway”, no modelo, porque estamos enxergando a Internet, na qual deseja-se ardorosamente conectar. Tanto que a exibimos no modelo.

 

Figura 4. Modelo de uma LAN com expectativa de se ligar à Internet em futuro próximo.

 

Quando da decisão de se conectar à Internet, o primeiro passo é encontrar um operador de trânsito que seja membro da Internet. Em outras palavra, procurar por um operador de trânsito que seja um Sistema Autônomo (AS). Por ser um AS, o operador de trânsito poderá nos fornecer os IPv6 que precisamos para estabelecer nossas conexões à Internet. Nosso modelo ficará um pouco mais complexo, visto na Figura 5. Agora temos IPv6 para atender nossas expectativas e nosso “gateway” passa a ser um roteador, quem sabe o que ganhamos do Monty Hall… Para os equipamentos que estão na rede local, a rota “default”, isto é, a direção de pacotes que contem IPv6 que não são nossos, é o IPv6v, colocado na LAN de nosso roteador. Já pacotes com IPv6 desconhecidos do roteador serão encaminhados para a sua rota “default”, que é o IPv6a.

 

Figura 5. Modelo de uma conexão simples de uma rede à Internet.

 

O modelo da Figura 5 não está legal. Falta a ele capturar diversas informações importantes, que podemos enumerar:

  1. A LAN, passou a ser uma rede do operador de trânsito. Na realidade, embora a LAN não pertença ao operador de trânsito, os IPv6 pertencem a ele, partindo do pressuposto de que são IPv6 válidos.
  2. A LAN é cliente comercial do operador de trânsito. O operador de trânsito é um AS.
  3. O cliente comercial não é um Sistema Autônomo. É parte de um Sistema Autônomo.
  4. A conexão TCP estabelece um tráfego de pacotes para, e da Internet usando um protocolo que não é o BGP. Quem usa o BGP é o operador de trânsito.
  5. O cliente comercial é uma rede que está na Internet, via o operador de trânsito.

Como estamos usando um modelo gráfico e estático, muitas informações complementares devem ser descritivas. Porém, à medida que padronizarmos o modelo gráfico, menos descrições complementares serão necessárias. Padronizar, neste caso, envolve um cenário mais universal, no sentido de que a grande maioria dos envolvidos concordam com o que está sendo desenhado. Já existem propostas para isto. Os diagramas da UML (Unified Modeling Language), iniciativa da OMG (Object Management Group) é uma proposta de unificação de padrões, que não cobre somente a engenharia de software.

 

Figura 6. Refinamento do modelo, de uma conexão simples de uma rede à Internet.

 

A Figura 6 é uma proposta de modelo com um significativo refinamento ao da Figura 5. Ele nos traz muito mais informações do que o frágil modelo da Figura 5. Eis os pontos importantes exibidos no novo modelo, os quais dizemos que fazem parte do escopo do modelo:

  1. A Internet que ele está exibindo é a Internet IPv6. Hoje temos duas Internet. A outra é a Internet IPv4.
  2. O operador de trânsito em questão é um Sistema Autônomo. Ele possui um número de AS, no modelo representado por n, ou ASn.
  3. A Internet é um conjunto de ASes (nuvens em verde), incluindo o operador de trânsito.
  4. Está claro agora, que o cliente do operador de trânsito tem acesso à Internet, e que é membro da rede do operador de trânsito, pois ele não é um AS.

Há, também, coisas que o modelo não nos informa (são partes do que chamamos de não escopo), a saber:

  1. Não nos fala nada sobre a Internet IPv4. Fica apenas o registro da Internet IPv6.
  2. O modelo não identifica qualquer acordo entre o cliente e seu operador de trânsito.

O próximo modelo, finaliza nosso refinamento desta etapa, pressupondo de que o cliente passa a ser um AS. Está na figura 7, a seguir.

 

Figura 7. Modelo de uma conexão BGP nas duas Internet.

 

O comentários importantes sobre o modelo da Figura 7, são os seguintes:

  1. Retiramos a ideia de operador de trânsito. Temos agora, somente os ASes que, na realidade, fornecem tráfego através da Internet ou não. Tráfego é trânsito, ou transporte, ou “peering”, ou todos eles. Estas noções podem ser vistas em [10].
  2. As duas Internet estão transparentes. O ex-cliente, agora ASj é dono de seus próprios IPs. Como, geralmente, um AS tem IPv6 e IPv4, ele pode se conectar à Internet IPv6 e/ou IPv4, através de várias técnicas, uma das quais é a pilha dupla, que o modelo subentende.
  3. A ideia mais importante mostrada no modelo é a Conexão TCP. Antes de ser AS, o cliente tinha, também, uma conexão TCP. Agora, sendo AS, ele ativou o protocolo BGP, que só se viabiliza, se os “pares” tiverem uma conexão TCP, entre si.

 

Modelando o BGP

 

Na seção anterior, os modelos foram construídos para conexões BGP e não para o BGP propriamente dito. Já está claro que para uma conexão BGP funcionar, dois componentes são importantes: uma conexão TCP e a MEF do BGP. A MEF do BGP já é nossa conhecida. Sobre conexão TCP, muito pouco foi dito, até agora. A questão importante sobre conexão TCP é de que ela é estabelecida, usando-se soquetes. Um exemplo prático pode ser visto aqui no blogue3, onde soquetes foram usados para estabelecer uma conexão de telnet sob a ótica do paradigma cliente-servidor. Entretanto, já sabemos, também, que ao falarmos de BGP, a característica cliente-servidor desaparece. O mesmo acontece com a conexão TCP que dá suporte, ou que viabiliza o BGP. Isto nos leva a pensar da forma correta de que uma conexão TCP é estabelecida atrávés de um autômato finito ou MEF, também.

Falaremos sobre a MEF de uma conexão TCP em outro momento, mas podemos modelar o BGP conforme a Figura 8, que segue.

 

Figura 8. Modelo de uma conexão da MEF do BGP.

 

Eis as informações que nos interessam sobre o modelo acima:

  1. Os empareamentos são: ASi com ASj e ASj com ASk.
  2. O pré-requisito para iniciar uma conexão TCP é a existência de ligações físicas (camada L1), entre os empareados. Não interessa a extensão destas ligações.
  3. A MEF do TCP inicia o processo em entendimento entre os pares. Uma vez estabelecida a conexão TCP, o estado IDLE da MEF do BGP é acionado.
  4. A MEF do TCP mantêm a conexão TCP. Se ela cair, a conexão BGP cai e o processo começa novamente por ela, que no momento adequado aciona novamente o estado IDLE do BGP.
  5. Cada empareamento age de maneira independente. Se cair a conexão de um, o outro continua.
  6. Observa-se que, cada dia que passa, as conexões de camada física estão se tornando mais estáveis, apesar do preço cada vez mais baixo. Provavelmente, consequência da competição que está aumentando e a necessidade das operadoras (ou ASes) se tornarem mais eficientes. Um visível sintoma é o fato do Nic.br (no Brasil) já admitir que um AS possa ter somente uma conexão.

 

Conclusões

 

A MEFTCP é o mais importante para a proposta de OEP1. Da mesma forma que a MEFBGP, a qual ficará completa quando for analisado o mecanismo de mensagens do BGP.

A noção sobre modelos é apenas um princípio de como se pode tratar questões ligadas a implementação de BGP. O tratamento deve ser semelhante a um projeto. Os processos são as diversas etapas que seguem aquelas recomendadas a um projeto normal. Há requisitos, escopo e a implementação propriamente dita. Provedores de Internet, principalmente os pequenos sofrem na mão de grandes operadores. Se as propostas referente a um esquema mais profissional de implementação de projetos, quando se tratar de BGP, os ganhos serão enormes e podem, inclusive, admitir à ANATEL a criação de um mecanismo adequado para ela administrar sua função de vigilante das normas legais. Um exemplo é o uso de algo parecido com um Termo de Abertura do Projeto (TAP), criado especificamente para este fim. Sobre este assunto, isto é, a aplicação de metodologias e/ou técnicas de projetos sobre implementações de BGP, incluindo análise de topologias e outros protocolos associados (iBGP, OSPF, entre outros), oportunamente serão tratadas aqui neste blogue.

 

Referências

 

  1. Julião Braga. (Agosto 2012). Objetos de Projeto Estendidos (OPE). Disponível em: https://juliaobraga.wordpress.com/2012/08/22/objetos-de-projeto-estendidos-ope/. Acessado em 05/09/2012.
  2. Julião Braga. (Agosto 2012). Máquinas de estado finito: Parte Prática: MEF do BGP. Disponível em: https://juliaobraga.wordpress.com/category/projetos/gerenciamento-de-projetos/. Acessado em 05/09/2012.
  3. Julião Braga. (Março 2012). Soquetes: PHP, IPv6 e ‘inseguridade. Disponível em: https://juliaobraga.wordpress.com/2012/03/04/soquetes-em-php-ipv6/. Acessado em 05/09/2012.
  4. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Updated-By RFC6286, RFC6608) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 05/09/2012.
  5. Scott E. Page. Prologue The Card Catalogue. Disponível em: http://www.cscs.umich.edu/~spage/ONLINECOURSE/R1Page.pdf. Acessado em 09/09/2012.
  6. Scott E. Page, Lecture 23 Networks. July 28, 2006. Disponível em: http://www.cscs.umich.edu/~spage/teaching_files/modeling_lectures/MODEL5/M29networknotes.pdf. Acessado em 09/09/2012.
  7. Scott E. Page, The Difference: How the power of diversity creates better groups, firms, schools, and societies. Aug 11, 2008. Disponível em: http://pt.scribd.com/doc/82442356/Scott-E-Page. 424 p. Acessado em 09/09/2012.
  8. Stewart, J. W. III. BGP4: inter-domain routing in the Internet. Reading, Mass.: Addison Wesley, 1998.
  9. Leonard Mlodinow (1954). O andar do bêbado: como o acaso determina nossas vidas. Rio de Janeiro: Zahar, 2009. Tradução de Diego Alfaro.
  10. Julião Braga. (Março 2010). Tráfego, trânsito, transporte e peering (uma proposta de definição). Disponível em: https://juliaobraga.wordpress.com/2010/03/09/trafego-transito-transporte-e-peering/. Acessado em 10/09/2012.
Anúncios

Objetos de Projeto Estendidos (OPE)

When knowledge is involved,
it is best to bring the Internet to the user,
instead of taking the user to Internet.

 

Uma dificuldade na Infraestrutura da Internet

 

Em tudo o que tem sido escrito sobre BGP neste blogue há sempre uma observação persistente: BGP é complexo. Na realidade, a complexidade do BGP está na sua abrangência e sua perspectiva de mudar constantemente. Mas, há outro componente importante quando se deseja implementar o BGP em roteadores de borda: a topologia.

Vamos a um exemplo. Recentemente, um Provedor consultou-me sobre uma topologia com três (3) trânsitos: dois com uma operadora A e um terceiro com a operadora B. A topologia parecia ser a mostrada na Figura 1, abaixo.

 

Figura 1. Três trânsitos sendo dois com a mesma operadora.

 

Este texto não propõe a implementação da topologia acima, com o BGP. Ele trata de outro assunto, correlato. Entretanto, vou dar algumas dicas sobre a implementação. Até aquele momento, nunca tinha passado por experiência semelhante. Ao entrar no roteador do Provedor foi curioso observar o fato de que a operadora A recomendou que se estabelecesse dois empareamentos com cada um de seus enlaces de trânsito: um com a tabela de roteamento completa e outro com tabela de roteamento parcial. Incluindo o empareamento da Operadora B haviam cinco sessões BGP ativas. O roteador estava em produção e alguns comportamentos ruins eram incompreensíveis. A primeira visão da implementação, sempre segue o instinto (da suposta experiência): (a) a Operadora A entende mais do que qualquer um e, (b) um ajuste nos filtros poderia resolver o comportamento ruim (abstraindo-se do fato do BGP ser complexo). Duas premissas completamente equivocadas. Revendo a presunção inicial, observou-se que, na realidade havia uma novidade na topologia: dois trânsitos com a mesma operadora. Google, eis a saída! Nesta hora é que você vê como o Google cansa!!! Depois de algum tempo, a luz no final do túnel veio com a RFC22701. Esta RFC, de 1998 é um pouco confusa, pois trata de topologias bem mais simples sem as variações possíveis do futuro atual. Por exemplo, a topologia poderia não ser a da Figura 1, exatamente. Em outras palavras, o trânsito poderia estar vindo através de um único roteador da Operadora A, ou chegando em uma única porta do roteador do Provedor. Ou ainda, alguma outra variação do tema. No Google, eficaz sintáticamente, infelizmente não consegue interpretar a semântica, ainda. Quem propõe a solução para implementar BGP em uma topologia destas é o primeiro autor da RFC2270, J. Stewart. No romance do BGP, escrito por ele2, Capítulo 3 há uma completa descrição de todos os comportamentos do BGP em casos como estes, incluindo balanceamento. Em particular, a Fig. 3.2, na página 78, Stewart explica em detalhes um multi-homed com uma mesma operadora, de forma didática!

Mas o erro mais grave da dúvida produzida pela topologia da Figura 1 é que, ao lidarmos com o BGP associado a uma topologia qualquer, não é por hábito fazer um projeto, minimamente cuidadoso, que permita o entendimento do comportamento esperado. Em outras palavras, não se pensa sobre o problema. Isto tem acontecido sistematicamente com os pequenos e médios provedores. Por outro lado, observa-se que a falta de pensar e/ou a falta de projeto são recorrentes, mesmo tendo do seu lado as grandes operadoras brasileiras. A Operadora A da Figura 1 é uma enorme de uma operadora. Por outro lado, o Google demorou demais em ajudar a encontrar uma saída.

 

Uma dificuldade em outras áreas de projetos

 

Há alguns meses atrás fiquei dependendo de uma informação relacionada com seguradoras que estariam dispostas a segurar riscos fortuitos. Suponha que você tenha um projeto cujo objetivo é a realização de um evento em uma determinada localidade. Um evento de grande porte, com um orçamento considerável. Imagine que na véspera do evento aconteça (digamos, uns 3 dias antes), uma tempestade de enormes proporções, que arrase a cidade e cause danos materiais irreversíveis (neste exemplo, não há perdas de vida, felizmente), causando uma perda total do evento. Qual seguradora seria capaz de segurar a perspectiva de uma perda destas? Procurei, procurei, googlei, telefonei, mandei e-mails e não consegui uma resposta. Finalmente entrei no Linkedin e coloquei uma pergunta relacionada, em um grupo de projetos. Houve um debate muito interessante, até que alguém passou o nome de uma seguradora que bancou um risco semelhante, na cidade de New Orleans e acabou pagando o prejuízo causado a um projeto semelhante que iria acontecer por lá. Desta forma, a dúvida e a ausência do seguro foram resolvidas.

Para uma equipe de projetos, a indisponibilidade de competências para descrever, detalhar ou desenvolver partes do projeto (ou mesmo o projeto completo) é a principal motivação para recorrer a opiniões especializadas.

 

Perdas de tempo em projetos

 

No primeiro exemplo, do BGP e topologias, o problema maior é a falta de pensar, com certa antecedência sobre a implementação de um trânsito com a Internet. Mas, esta questão, com a maturidade será resolvida e em breve teremos projetos sendo desenvolvidos para preparar devidamente os roteadores de borda ou até mesmo as redes internas que estão se tornando, também, complexas. Mesmo que sejam pequenos Sistemas Autônomos. Neste momento, o administrador (ou preposto) de um Sistema Autônomo passa a ser um gerente de projetos.

No segundo exemplo, a questão de segurar perdas fortuitas foi resolvida por um membro de um projeto completamente dissociado do meu projeto. Por acaso expor a dúvida em um grupo de alto nível do Linkedin foi um sucesso, embora a iniciativa tenha demorado um pouco para ser tomada.

Geralmente, dentro de uma mesma empresa, obter informações úteis ou fundamentais para projetos não levam muito tempo, porque há sempre disponível o chamado “golden book”, que vai acumulando informações úteis a cada término de um projeto. Entretanto, intergrupos desconexos de projetos, isto não acontece. Um provedor, dificilmente troca informações com outros Provedores. Não por considerarem as informações preciosas ou de valor competitivo, mas por falta de oportunidades ou de local adequado para fazê-los. Geralmente, as informações são trocadas quando alguém, em uma lista de e-mail ou fórum apropriados provoca a questão. Não é, portanto, usual alguém colocar em algum fórum ou lista, por livre e espontânea vontade: “o problema do multi-homed para um mesmo operador de trânsito resolve-se assim e assado…”. Da mesma forma, porque um membro ou gerente de projeto iria divulgar o nome de uma seguradora de riscos fortuitos, se não há um ambiente apropriado para fazê-lo?

 

Objetos de Projeto Estendidos

 

Se houvesse um ambiente apropriado, seguro, confiável e com um mecanismo de pesquisa mais “inteligente”, do que os disponíveis atualmente, a cooperação fluiria espontâneamente. Por várias razões, algumas relacionadas abaixo:

  • Pelo natural espírito de cooperação do ser humano, interessado e consciente.
  • Pela garantia de autoria da informação.
  • Pela perspectiva de auxiliar no crescimento de um repositório de sabedoria útil para projetos, em geral, do qual todos se beneficiarão.
  • Pela rapidez de acesso à informação.
  • Pela possibilidade de manter informações pessoais e privativas.
  • Pela garantia de intervir no ambiente garantindo a qualidade da informação.
  • Pela existência de mecanismos de pesquisa semântica, mais próximos do pensamento humano.

 

A disponibilidade de informações (textos, gráficos, imagens, videos, etc.), tratadas neste documento são armazenadas no que se convencionou chamar Objetos de Projeto Estendido (OPE). Existem dois tipos de OPEs: público e privado. Um OPE é público se ele pode ser compartilhado com terceiros. Um OPE é privado se ele não puder ser compartilhado com terceiros. Os OPEs são agrupados (ou armazenados) em um ambiente chamado de ROPE (Repositório de Objetos de Projeto Estendidos). Existem inúmeros ROPEs, cada um deles hospedados no computador do usuário interessado (o “dono” do ROPE). Um ROPE, possui uma interface humano-computador que, de forma independente classifica, pesquisa e visualiza os OPEs armazenados, além de permitir operações de criação/inclusão e demais atividades necessárias ao tratamento de um OPE isoladamente ou em conjunto. OPEs podem ser enviados ou recebidos de um Sistema de Gerenciamento de Projetos (SGP), através de uma interface apropriada que funcionaria da forma representada na Figura 2.

 

Figura 2. OPE e o Sistema de Gerenciamento de Projetos

 

Se o SGP possuir as facilidades adequadas, os recursos de WEB Semântica serão utilizados, mais apropriadamente, ontologias7 e as propostas da W3C relacionadas com a OWL (Web Ontologoy Language)6. Em futuro próximo, outro artigo abordará este tema, em detalhes, oportunidade em que será mostrado que ontologias podem ser transformadas em XML e vice-versa, aperfeiçoando a proposta da Figura 2. Uma ótima e rápida leitura pode ser encontrada no artigo da Scientific American8 e com maior profundidade, um texto clássico e completo em [9].

Cada OPE possui uma medida de aceitação, denominada assimetria e pode sofrer alterações por terceiros, no sentido de aprovar, reprovar ou identificar a relevância. Assimetria é uma medida de qualidade de um OPE. Por outro lado, o conteúdo de um OPE pode, também, sofrer alterações. Neste caso, o repositório manterá um histórico de tais alterações, desde o OPE original até o atual, incluindo cada uma das contribuições efetivamente aceitas, aprovadas ou reprovadas, e relacionadas com o OPE. A técnica usada para que este procedimento ocorra adequadamente é a procedência de dados, a qual garante que um OPE conterá a descrição de “como”, “quando”, “onde”, “porque” os dados foram obtidos e “quem” os obteve. Cada um dos componentes históricos de uma OPE, caracterizado pela procedência de dados, também tem o sua respectiva assimetria associada, que representa uma medida de aprovação/reprovação e relevância da nova alteração OPE. Por outro lado, a informação oferecida em um OPE pode ou não ter um valor financeiro para que ela se torne visível.

A contribuição da procedência de dados foi obtida da interessante experiência sobre imagens, proposta por Braga4. A noção de assimetria tem sido experimentada e abordada neste blogue em diversas oportunidades, como medida representativa de distorções sociais, de pessoas, entre outras.

 

Caracterizando o tratamento do ROPE

 

A Figura 3 é um esboço preliminar de um diagrama (que parece, mas não é uma diagrama de caso de uso!), caracterizando os pontos mais importantes. Na sequência uma abordagem, também preliminar, sobre o escopo do sistema. A formalização definitiva dependerá de alguns componentes ainda pendentes no âmbito acadêmico em que o autor está atualmente engajado.

 

Figura 3. Diagrama preliminar do sistema de tratamento do ROPE (Fonte: autor).

 

Os desafios de pesquisa avaliados a partir da abstração exposta na Figura 3, são:

  1. A medida de assimetria e as intervenções históricas (procedência) sobre um OPE exigem autenticação do usuário, a qual irá configurar sua validação. Também, a assimetria poderá indicar a permanência ou não de um OPE no repositório distribuído ou no repositório local, sem que haja intervenção humana direta, com base em critérios pré-definidos.
  2. O ROPE deverá estar disponível na Internet, da forma descrita em (c). A disponibilidade de um ROPE é ativa ou passiva. Uma disponibilidade é ativa, se o ROPE está hospedado em um IP público (IPv4 e/ou IPv6), e a disponibilidade é passiva se o IPv4 e/ou IPv6, no qual ele se hospeda é privado (não está visível na Internet). IPv6 é a alternativa preferencial.
  3. Não pode haver um sistema central, característica do paradigma cliente/servidor. Apesar de este paradigma criar uma imensa facilidade para o usuário, uma vez que o acesso poderia ser feito por qualquer navegador (cliente da WEB), ele traria um componente de custo que poderia inviabilizar sua implementação ou mesmo exigir um patrocínio, para garantir servidores e seus respectivos sistemas de segurança associados. Além do mais, tal alternativa afrontaria o princípio do domínio local.
  4. Os mecanismos de pesquisa e acesso ao ROPE que é, na verdade, uma base de conhecimento deve seguir as recomendações propostas nos padrões W3C e em técnicas derivadas.
  5. A quebra do paradigma cliente/servidor exige um mecanismo que permita que os ROPEs sejam distribuídos, isto é, sejam hospedados nas máquinas de cada usuário interessado. Tal predisposição leva às seguintes preocupações:
    1. Fácil implementação e uso de linguagem universal independente do sistema operacional utilizado pelo usuário. Preferencialmente em código objeto com versão bem definida onde, o sistema operacional é uma completa abstração.
    2. Cada ROPE deve ter uma identificação única sempre associada a seu usuário. Está identificação será um número de 32 bits permitindo até 4.294.967.296 repositórios diferentes. Tal identificação pode ser obtida através de qualquer repositório ativo (sempre o mais próximo do usuário, preferencialmente).
    3. Disponibilidade de mecanismo que permita atualização do(s) procedimento(s) associado(s) à operação local do ROPE. Por exemplo, o código objeto dito em (i).
    4. Atualização do repositório de OPE, em tempo real, que não poderá usar qualquer SGBD (Sistema de Gerenciamento de Base de Dados). O uso de um SGDB implicaria em complexidade adicional à implementação. Tal imposição leva à criação de representações de arquivos (incorporando XML, RDF, …) sob uma estrutura de diretórios locais, em texto ou outro formato, bem como qualquer outro tipo de informação (como por exemplo, aquelas necessárias ao mecanismo de autenticação).
    5. O projeto deve prever a ubiquidade, e usar recursos pervasivos.
    6. As propriedades ubíquas e pervasivas implicam na necessidade de mecanismo de cooperação entre os ROPEs disponíveis. A propriedade pervasiva somente poderá ocorrer em ROPEs ativos. Neste caso, o proprietário do ROPE pode autorizar ou não, terceiros usarem seu repositório para atender tal demanda.
    7. Por fim, um ROPE deve ser autônomo, com todas as facilidades e demandas disponíveis localmente.
  6. Mecanismos de criptografia adequados e transparentes aos usuários para garantir a segurança a todos os requisitos exigidos.
  7. O OPE deve ser caracterizado, também, pela sua aplicação às recomendações do PMBOK5, suas seções e capítulos. Consequentemente, deverá atualizar as características recomendadas pelas novas versões de padronizações propostas pelo PMI. Na hipótese de ocorrerem mudanças fundamentais na estrutura do PMBOK de referência, o OPE deverá manter histórico referencial.
  8. Os ROPEs devem ser identificados com garantia de autonomia. O mecanismo de cooperação (item d, subitem v), deve propagar tais informações para outros repositórios. A princípio, o mecanismo de propagação seguirá um esquema conhecido por empareamento (peering). Em outras palavras, um repositório OPE tem um ou mais empareados (peers).
  9. Cada empareado age ativamente (e de forma autônoma), no sentido de atualizar seus ROPEs, das seguintes maneiras:
    1. Cada ROPE está disposto a receber e enviar atualizações de um ou mais empareados, quando seu hospedeiro for ativo (item b);
    2. Um ROPE busca e envia atualizações em um ou mais empareados, previamente conhecidos, quando seu hospedeiro for passivo (item b).
  10. ROPEs empareados possuem um protocolo de relacionamento que permita a troca segura de informações. Tal protocolo é caracterizado por um autômato finito e seguirá os exemplos mais eficazes e simples, disponíveis na literatura.
  11. Um ROPE empareado que tenha sofrido uma alteração comunica-se com todos os seus empareados conhecidos com o objetivo de atualizá-los.
  12. Um OPE pode ter um custo associado à informação que ele está disponibilizando. Baseado na descrição objetiva do conteúdo do OPE pode-se decidir pelo pagamento com regras bem estabelecidas, inclusive uso de cartões de crédito. Neste caso, um mecanismo de pagamento deverá estar disponível para acesso imediato via o próprio OPE. A previsão de mecanismos de segurança descritas no item (e) torna factível esta proposição.

Vale lembrar, que o BGP é uma implementação que quebra o paradigma cliente/servidor (o que não é uma novidade), e usa a Internet para criar os ambientes de redes autônomas. Aliás, melhor seria afirmar que as implementações de BGP constroem a Internet.

Ademais, não é uma proposta de um sistema de relacionamento. Os ROPEs não possuem a identificação de seus proprietários, muito embora os OPEs e seus históricos, sim. Neste último caso, se o autor do OPE ou histórico, assim o desejar. Isto não configura o anonimato pois só se pode criar ou alterar um OPE se existir um proprietário de ROPE bem identificado.

Com referência à metodologia há fortes indícios que levam às recomendações propostas por Eeles e Crips3.

 

Observações finais

 

O trabalho deve ser desenvolvido em três etapas, a saber:

  1. Definição do problema: é a etapa em que o refinamento do texto acima irá acontecer, com a especificação do mecanismo de bases de dados distribuídas, as relações ubíqua e pervasiva. Formalização do esquema de mensagens e o autômato finito das conexões dos repositórios entre si. Adicionalmente, a especificação do modelo da base da dados do ROPE, através de uma metalinguagem.
  2. A descrição geral do sistema e suas relações com o PMBOK: etapa que irá descrever todo o sistema, com os detalhes das especificações e os componentes teóricos envolvidos. Os mecanismos de arbitragem das medidas de aceitação (assimetrias). Os tipos de OPEs possíveis e seus formatos relacionados com a estrutura do PMBOK. A proposta da linguagem de programação com base em comparações específicas.
  3. A evolução: propostas de estudos e pesquisas que possam viabilizar a implementação, testes de protótipos e fortalecimento de fragilidades a serem identificadas. Esta etapa está fora do escopo da proposta de trabalho inicial, que representam os itens (1) e (2), acima.

Referências

 

  1. RFC2270, Using a Dedicated AS for Sites Homed to a Single Provider J. Stewart, T. Bates, R. Chandra, E. Chen [ January 1998 ] (TXT = 12063) (Status: INFORMATIONAL) (Stream: IETF, Area: rtg, WG: idr)
  2. John W. Stewart III. (1999). BGP4: Inter-Domain Routing in the Internet. Addison-Wesley.
  3. Peter Eeles e Peter Cripps. (2012, Second Printing). The process of software architecting. Addison-Wesley.
  4. Juliana Cristina Braga. Procedência de Dados: Teoria e Aplicações ao Processamento de Imagens. 2004. 110 f. Tese de Doutorado do Curso de Pós-Graduação em Computação Aplicada. INPE, São José dos Campos, 2007.
  5. PMI. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK), 4a. edição, 2008
  6. W3C. OWL Web Ontology Language Guide. W3C Recommendation 10 February 2004. Disponível em: http://www.w3.org/TR/owl-guide/. Acessado em 16/12/2012.
  7. NOY, N.; MCGUINNESS, D. Ontology development 101: A guide to creating your first ontology, 2001. Disponivel em: http://liris.cnrs.fr/alain.mille/enseignements/Ecole_Centrale/What is an ontology and why we need it.htm. Acessado em 20/12/2012.
  8. BERNERS-LEE, T. I. M.; HENDLER, J.; LASSILA, O. R. A. The Semantic Web will enable machines to. Scientific American, n. May, p. 1-4, 2001. Disponível em http://www-sop.inria.fr/acacia/cours/essi2006/Scientific%20American_%20Feature%20Article_%20The%20Semantic%20Web_%20May%202001.pdf
  9. TRUSZKOWSKI, W.; BREITMANN, K. K.; CASANOVA, M. A. Semantic Web: Concepts, Technologies and Applications. [S.l.] Springer-Verlag, 2007.

 

Na sequência: Máquinas de estado finito: Parte Prática: MEF do BGP

%d blogueiros gostam disto: