Obviamente, os mais desavisados ou puristas, iriam propor uma engenharia de processo, depois uma análise do negócio, capturando e gerenciando os requisitos, depois com os casos de uso realizarem a análise OO, seguidos do projeto via componentização, e implementar via um application server em Java, controlar via massivos testes de forma a garantir o quality assurance e, finalmente, após tudo realizado, verificar quais foram os problemas no sentido de melhorar o processo utilizado. Não esquecendo do treinamento "rápido e barato" de todos os desenvolvedores da empresa bem como ao final comprar uma ferramenta "barata" de change management. Ora, talvez devesse ser colocado em uma exposição artística, ao lado de um grande quadro de Leonardo da Vinci. Mas, não é assim que funciona na prática. Não é, caro leitor?
     

     Portanto, para aqueles que efetivamente, quebrando minha língua, conseguem realizar a façanha acima, sem desperdiçar milhares de reais e ainda atender às necessidades do pagador (quem assina o cheque), meus sinceros parabéns.

     Aqui iremos por um caminho que visa o mesmo objetivo mas que, com certeza, não usa a mesma estratégia.

     Embora nosso Web Development Center (WDC) seja destinado a construção corporativa de software para Web, iremos iniciar sua exposição do topo do processo passando por todas as fases para garantir o entendimento. Comecemos pelo fim, pois uma solução só pode ser proposta se entendermos o problema. E formular o problema, no mundo científico, para os que não sabem, garante 50% de sua solução.

     Problema básico: gostaríamos de um ambiente de desenvolvimento que pudesse capturar de forma precisa a especificação do problema, preferencialmente, através de componentes e regras de negócio, que pudessem transformar esta especificação em um projeto conciso e consistente, de forma que houvesse uma sincronização entre a especificação e o código gerado. Além de permitir que o código fosse estendido com facilidade pela equipe de desenvolvimento.

     Gostaríamos também que as regras do negócio fossem isoladas de forma consistente do resto da aplicação e também fossem síncronas com o modelo.
Seria interessante que ficássemos independentes do RDBMS utilizado, e que todo este ambiente fosse projetado para produzir software para Web, onde teríamos as páginas de formulários, consultas, relatórios e gráficos gerados
automaticamente de forma satisfatória pela arquitetura, permitindo obviamente a extensão pelo desenvolvedor.

     É fundamental também que mais de 70% do código seja gerado, código real e não stubs, para que possamos nos concentrar no negócio. Neste código, deverá estar presente a escolha do RDBMS, para que o código saia de acordo; bem como através dos relacionamento de classes, herança e associações, gerar os scripts necessários de tabelas e stored procedures de forma normalizada e correta, para que não nos preocupemos com a persistência dos objetos.

     A solução deverá ser barata e, portanto, não precisa ser necessariamente de emissão crítica. E, fundamentalmente, deverá permitir a comunicação com software legados.

     Que desafio, não? Contudo, sabíamos que deveríamos acreditar apenas em uma sentença: quem tem medo de perder não ganha.

     Qual a teoria que nos propicia a captura correta do "o que", e não do "como"? Acreditamos que a teoria que melhor se encaixa neste perfil seja CBD. Veja que CBD não é OO. Componentes e classes não precisam um do outro.

     Na verdade, são teorias independentes. É claro, que idealmente uma complementa a outra.
Por que CBD e não o OO para especificar o "o que"? Basicamente, CBD trabalha com pré e pós condição e invariâncias. Desta forma, resolve com facilidade a questão: dado A, aplico X e tenho que obter B. Nada se diz sobre X, apenas
espera-se que ele exista.

     Ora, OO não faz isso? Para os de mente aberta, não. OO força um caminho de solução, através dos fluxos de eventos e de seus diagramas de interação. Ah, podem dizer: "basta o analista abstrair". Digo para estes professores, procurarem um psicólogo pois, como disse Einsten: "como o tempo se apresenta para quem esta sentado em um formigueiro?" Conseguirá abstrair?

     O analista sempre sabe o que está resolvendo e a mente humana, pelo menos para os ocidentais, sempre o engana. Assim, como não podemos trocar o analista trocamos a teoria, para que não precisemos de um mago para abstrair.

     Veja que ainda estamos falando da captura do negócio e não da análise do sistema. Um erro freqüente de todos os ambientes de software é começar especificando diretamente o software. Ou seja, acreditam que o analista de negócio e o analista de sistema são a mesma pessoa. Podem até ser, mas com certeza exercem papéis diferentes.

     Agora sim, após a captura do "o que" sob o ponto de vista do negócio (user requirements), começaremos a capturar o "o que" do ponto de vista do software (software requirements). E aqui entra o analista de sistema e as técnicas de análise OO.

     Após a aplicação da análise OO, aplicamos as técnicas de projeto orientado a objetos e finalmente chegamos ao que interessa (para este artigo): diagrama de classe refinado, diagrama de componente refinado e as regras do negócio refinadas (fato, assertiva ou derivada).

     Estes elementos de modelagem são insumos para o WDC. Veja, que se a empresa
efetivamente estiver utilizando um processo iterativo e incremental, equipes chegarão a este estágio em tempos diferentes e com propósitos diferentes, por exemplo, prototipagem evolutiva. Ou seja, o processo não precisa ser top-down. Chegamos finalmente ao WDC.

     A construção do WDC não foi um projeto isolado. Praticamente dois softwares foram desenvolvidos em paralelo. Pois, quando resolvíamos um problema de forma correta e consistente, víamos na prática sua utilidade em um futuro WDC. Assim, isolávamos o modelo e o código, para uso futuro na construção de um futuro WDC. Assim, o WDC nasceu da prática, ou seja, de um processo real de Engenharia de Software, da mesma forma que o avião nasceu da Engenharia, e não da Física.

     Assim, inicialmente, verificamos assim, que tínhamos que dividir o problema
da seguinte maneira:

     * Construção de um repositório que guardaria o meta-modelo, ou seja, componentes, classes, atributos, métodos, associações, etc.
     * Criar um gerenciamento dinâmico das páginas. Ou seja, as páginas HTMLS deveriam estar em um repositório e seu controle e gerência deveria ser feito pelo Web design e pelo responsável pelo repositório. Deveria existir também um mecanismo que ligasse os componentes e suas interfaces as páginas que permitem a interação com o usuário. Este processo também deveria ser
dinâmico.
     * Deveríamos construir também um mini-application server que seguisse a especificação J2EE, contudo em Object Pascal e não em Java. Esta seria a tarefa mais difícil, contudo poderíamos simplificar desprezando vários aspectos de missão crítica.
     * Deveríamos construir um gerador de código, que a partir do modelo, gerasse as classes, métodos de verificação de invariâncias e regras de negócio; que a partir do RDBMS escolhido gerasse a camada de persistência e, finalmente, se o componente ao qual a classe implementa fosse vista pela Web, gerasse também as páginas HTMLS bem como o código Java Script associado.
     * Um mecanismo de controle e gerência de quebra de invariância e regras de
negócio obtidos na especificação.
     * E que também tratasse os componentes e as páginas HTMLS como recurso de um sistema de segurança. De forma, que fosse possível gerenciar os usuários, seus grupos e os recursos de quem acessará o que e quando.
     * Construir uma mini-ferramenta CASE que suportasse os diagramas da UML e também os da teoria de CBD.

     Chegamos ao problema e uma proposta de solução. Vamos então entrar em cada um dos sete tópicos acima.

     Repositório
     

     O repositório tem como principal objetivo armazenar o meta-modelo dos sistemas desenvolvidos. Contudo, todos os outros tópicos de nossa solução precisam persistir objetos. Sendo assim, nosso repositório deverá possuir uma visão organizacional de forma a permitir o seu gerenciamento pela empresa.

     Pois, aqueles que realmente desenvolvem software utilizando OO, sabem que rapidamente surgem centenas de classes e até milhares de classes em um projeto. Neste contexto, a pergunta: "existe alguma classe com esta responsabilidade, onde eu possa estender ou reutilizar?" Fica completamente desprovida de sentido e assim todo e qualquer problema gera novas classes e
a reutilização tão esperada de OO, simplesmente não existe.

     Obviamente, quem trabalha com CBD e OO juntos, consegue um nível de organização extra proveniente das técnicas de CBD. Todos hoje sabem que a porta de um carro não é um objeto, e sim um componente, o objeto é o parafuso e a porca.

     Páginas Web
     

     As páginas Web possuem duas origens: produzidas do zero pelo Web design; e estendidas via página gerada pelo gerador.

     Tanto em um caso como no outro, do ponto de vista de design, as páginas devem ser trabalhadas via ferramentas como Dreamweaver, HomeSite, Fireworks e Corel Draw.

     Contudo, seu gerenciamento se tornaria impraticável se o Web design fosse o responsável pelas páginas e não houvesse link entre os componentes de negócio e as páginas. Desta forma, foi realizada a divisão virtual dos componentes de uma página Web:

     1. Cabeçalho. 

     2. Título.

     3. Menu. 

     4. Form. 

          4.1 Form solicitação. 

          4.2 Form resposta. 

          4.3 Form erro. 

          4.4 Form ajuda. 

     5. Rodapé.

  
     Vejam, que cada pedaço ou componente da página estão armazenadas normalmente no repositório como um objeto qualquer. O cabeçalho e o rodapé são praticamente constante para uma dada empresa. Sendo assim, o meta-modelo possui esta ligação com a empresa. O menu e o form possuem uma ligação com o componente de negócio responsável por seu processamento. Na verdade, alguns componentes de negócio ou processo possuem uma interação visual, e quando
for este o caso, há uma ligação direta no repositório entre o componente visual (página) e o componente de negócio (modelado, especificado, implementado e armazenado no repositório). O que isto tudo significa?

     Inicialmente, o visual de todos os software de toda a empresa pode mudar apenas com a alteração do componente de cabeçalho, rodapé e título. Não há nenhuma outra mudança sequer.
Da mesma forma, se novos objetos forem incluídos no application server a única alteração necessária seria no componente de menu, o que poderia ser feito sem a necessidade de nenhuma outra alteração.

     E também, caso o componente visual seja alterado sem a necessidade de quebra de alguma interface do componente de negócio, nenhuma alteração seria necessária além da troca do form e seu novo visual.

     Uma alteração necessária no componente de negócio, possui dois impactos diferentes: a interface foi quebrada (assinatura) e a interface não foi quebrada.

     No primeiro caso, pode ser necessária uma alteração no componente visual ou form. No segundo caso, basta apenas trocar o componente de negócio no application server, mais nada.
Um dos principais problemas encontrados aqui seria o mecanismo de montagem e devolução das páginas do application server para o Web server. Como funciona este mecanismo? Este mecanismo foi denominado DSP (Dynamic Server Page). E se encontra implementado no application server. Iremos discutir aqui, devido sua ligação direta com as páginas Web.

     Nosso Web Server recebe uma solicitação HTTP. Imediatamente ele repassa esta solicitação para nossa .dll ou .exe (CGI, ISAPI ou NSAPI). Dentro desta .dll (por exemplo), temos um código que transfere a solicitação HTTP em uma chamada CORBA/DCOM para o application server correto.

     Nos concentrando apenas no DSP, a chamada é repassada do application server para o DSP correto, este o trata e retorna a página montada para o application server (in process), que por sua vez, responde a chamada CORBA/DCOM com a página montada. Desta forma, o leitor poderá verificar que nosso Web server não faz absolutamente nada, servido praticamente como um
proxy de chamadas aos application server distribuídos pela empresa.

     Veja que o DSP além da montagem dinâmica possui um montador que faz a ligação entre o componente visual (páginas) e o componente de negócio armazenado no application server. O interessante é que esta ligação é feita através da configuração no application server e não via hardcore.
 

     A pergunta que, inevitavelmente, surge é: muito bonito, mas e a performance?
     A resposta é: simplesmente várias vezes mais veloz do que ASP.

     Mini-application server
    

     O application server realmente foi um desafio. Fazer voar um avião com poucos recursos realmente é complicado. Na verdade, o nome correto seria mini-application server, pois só implementamos algumas idéias básicas e não se compara de longe ao reais application server do mercado.

     Contudo, existe um divisor de fronteiras esquecidos pelos técnicos e engenheiros, mas que representam um simples dever de casa para os empresários. Se resolvo 80% dos meus problemas pagando X, por que tentarei resolver 100% pagando 1.000 X?

     O primeiro ponto seria o correto gerenciamento das conexões. O que seria uma conexão para nosso application server? Entendemos como conexão um login efetuado por algum usuário (que recebe um ID o diferenciando dele mesmo, após entrar no application server, pois ele pode "logar" em várias maquinas simultaneamente) em um sistema. Esta conexão habilita o usuário a utilizar vários componentes de negócio daquele sistema.

     Quando o usuário solicita (via form ou menu) o uso de um determinado componente de negócio, o application server gera uma sessão ligando a conexão ao componente de negócio.
Neste instante tivemos que resolver o problema de memória e não dos componentes de negócio. No J2EE, este problema é discutido como componentes Session ou SessionLess.

     O application server então verifica se aquele componente já está sendo utilizado em uma sessão, por este mesmo usuário, é claro. Caso a resposta seja sim, ele ativa o componente (na verdade o seu DSP) e passa o processamento para este componente via um thread. Se o componente ainda não estiver sendo utilizado ele instancia o componente (na verdade seu DSP) e
repassa o thread para ele, colando também sua entrada no gerenciamento dos componentes ativos do application server, para uma eventual chamada posterior.

     Obviamente todos os passos anteriores estão sob a supervisão do sub-sistema de segurança do application server. Toda e qualquer chamada ao application server, login, chamadas a componentes e logoff, passam antes pelo sub-sistema de segurança.

     Uma outra questão interessante é que o application server esta divido em três camadas lógicas. Assim, as responsabilidades são divididas da seguinte maneira:

     * DSP (Dynamic Server Page) - Responsável pela montagem das páginas
     * BR (Business Rules) - Responsável pelas regras do negócio, independente da Web ou qualquer outro font-end e também do RDBMS. Implementado via CBD e OO.
     * DB (Data Base) - Responsável em interfacear com o RDBMS, tabelas e procedures. 

     Garantindo uma total transparência do RDBMS utilizado, e resolvendo também o problema de persistência de objetos. Ou seja, o mapeamento de classes (OO) para tabelas (relacional).

     E como os componentes são desativados? Inicialmente colocamos um timeout no application server que desconectava automaticamente o usuário após certo tempo de desuso. Contudo, esta solução foi sumariamente rejeitada pela comunidade usuária. Assim, trocamos esta abordagem dando ao usuário a possibilidade de dar logoff no sistema.

     No entanto, sabemos que esta abordagem por si só não funcionaria, pois obviamente alguns usuários irão simplesmente desligar o computador ou fechar o navegador. Assim, criamos o gerenciamento remoto das conexões pelo responsável do application server. O responsável possui um gerenciador remoto de conexões, que permite a liberação das conexões perdidas no
application server.

     Um outro problema gravíssimo é o gerenciamento e controle das transações. Um componente pode possuir uma transação qualquer internamente, contudo outro componente que passou a usar o segundo possui sua própria transação e agora, indiretamente também a transação do componente que ele utiliza e assim sucessivamente. Para piorar, cada um dos componentes pode possuir objetos persistentes em RDBSM diferentes. Nos resumiremos aqui a dizer que
resolvemos este problema em 90% dos casos, criando um gerenciador de transação no application server.

     Assim, o estudo completo do nosso application server, mesmo sendo bastante limitado, exigiria várias páginas. Portanto, vamos voltar a nossa solução Web.

     Gerador de código

     O gerador de código representa a peça chave para a velocidade do ambiente de desenvolvimento.

     Inicialmente, a partir de um modelo gerado por uma ferramenta CASE, o gerador de código irá gerar código inteligente para todas as partes do WDC.

     A pergunta que pode surgir aqui é a seguinte: como código inteligente? Pois, as ferramentas CASE geram basicamente stubs ou assinatura e definição. Na verdade foi construído um framework de componente e classes para toda a solução. Nosso framework foi gerado através de alguns patterns e templates padrões para uma solução comercial.

     Por exemplo, as operações de cadastro (incluir, alterar, pesquisar e excluir) possuem Pattern (soluções testadas e eficientes) que podem ser implementados via polimorfismo com sucesso.

     Assim, se um objeto deve ser persistido, basta ele herdar do framework as classes corretas e estará garantido não só a persistência, mas um conjunto de outras funcionalidades, como validação de invariâncias, regras, alguns befores (incluir, excluir, etc.).

     Em uma inclusão, por exemplo, o framework testa as regras atômicas, gerenciais e colaborativas dos componentes. Garantindo um funcionamento padrão (pattern) e de fácil manutenção. Onde estão as regras do negócio?

     Certamente aqui, ali ou lá. Portanto o gerador, esta absolutamente integrado não só com o framework, mas também com o application server, com o RDBMS, etc., em suma, com todo WDC. Por isso, ele pode gerar código, com ifs, thens, whiles, for, etc., dependendo do modelo (diagrama de classes, componentes e regras).

     Para garantir a velocidade criamos um ambiente que gera o código (Control Center), um ambiente que testa o componentes individualmente (Component Test) e um ambiente que integra os componente (Component Integrator).

     Podendo obviamente, ser feito por equipes diferentes de desenvolvedores, cada equipe com seu próprio Control Center (o repositório é corporativo).

     Tratamento de erro e regras de negócio
     

     Uma outra reclamação constante da comunidade usuária, era o repasse nada significativo de erros do RDBMS para a aplicação. Mas, antes de olharmos para o tratamento de erro, vejamos uma discussão interessante. Vejam, que três níveis de regras de negócio são testadas no próprio application server em memória. Portanto, para aqueles que acham que a colocação de um
application server torna o software mais lento, terão uma surpresa inacreditável. O application server torna a aplicação várias vezes maisrápida do que a implementação pesada de stores procedures em um RDBMS.

     Obviamente, aqui existe o bom senso (para não dizer competência) do pessoal de desenvolvimento em saber que em alguns casos, as stored procedures realmente funcionam com maior eficiência. Mas no todo, a utilização do application server garante uma velocidade bastante superior.

     Isto é fácil de visualizar. Sem o application server, várias regras serão testadas somente no RDBMS, forçando uma passagem pele rede e depois um overhead do próprio RDBMS. No caso do application server, tudo esta em memória, sendo assim o que é mais rápido?

     Voltando a reclamação de erros não significativos da comunidade usuária. O application server sabe quando alguma regra foi quebrada, seja em memória ou do RDBMS. Ele então obtém a mensagem de erro gerada, aplica uma matemática de CRC e armazena no componente a mensagem original solicitando ao responsável pelo componente uma mensagem mais viva e significativa.

     Ou seja, o usuário remete uma página que o application server ou o RDBMS entendem como quebra de regra ou invariância. Por exemplo, o cliente não possui saldo para comprar este produto. Digamos que a mensagem veio do RDBMS, sendo assim, a primeira vez que fosse gerado o erro o usuário receberia a mensagem nada amigável, além de ser em inglês, do RDBMS em sua resposta na página (obviamente com toda a formatação possível, feito pelo
Web design).

     Contudo, aplicando a matemática de CRC, o application server irá verificar que esta mensagem ainda não foi tratada, armazenaria então esta quebra de regra no repositório, esperando que o dono do componente ou o responsável pelo application server a traduza ou a melhore (isto se não for um bug).

     Se isto não ocorrer, a mensagem continuará sendo a mesma para o usuário. Mas assim que a mensagem mais significativa é registrada como substituta da mensagem original do RDBMS, o próximo erro irá omitir a mensagem do RBDMS e trazer a nova para o usuário.

     Veja que este mecanismo é controlado pelo application server, sem nenhuma alteração no código fonte, nem nas páginas Web. A única interação seria a melhora da mensagem feita através do WDC pelo desenvolvedor ou responsável pelo repositório.

     O leitor poderia dizer: basta ter um banco de mensagens traduzidas e pronto.

     Isto não funciona na prática. O desenvolvedor jamais irá parar e digitar textos de erros e estudar todas as possibilidades.

     Invertemos o processo e realmente fizemos o application server aprender com os erros e solicitar uma providência. O desenvolvedor passa a sofrer um controle do próprio application server.

     Outro benefício é que após o ciclo de implantação, todos os erros praticamente serão descobertos pelo application server e traduzidos, ou melhorados, pelo responsável de forma contínua e gradual. Esta abordagem realmente foi um sucesso.

     Segurança
    

     Nossa abordagem de segurança não difere muito da abordagem padrão. Temos um conjunto de usuário que podem pertencer a vários grupos ou perfis de usuários. Da mesma forma, temos um conjunto de recursos que podem pertencer a vários grupo ou perfis de recursos. Nosso recurso contém um conjunto de operações de interfaces dos componentes. Lembramos aos leitores que um componente possui um conjunto de interfaces e que uma interface possui um
conjunto de operações.

     Nosso repositório controla estes elementos de modelagem. O desenvolvedor faz a ligação das operações às páginas armazenadas no repositório e o montador reúne todas as partes de uma página de acordo com a configuração de cada operação. Sendo assim, no nível mais baixo controlamos o acesso às operações dos componentes.

     Para aumentar ainda mais a velocidade de acesso, pois toda chamada exige a verificação de segurança, criamos um cache de segurança. Sendo assim, caso o usuário tenha acessado um componente em um tempo predeterminado (timeout do cache), o sistema pula parte da verificação de segurança.

     Mini-Case

     Entendemos que o maior erro no desenvolvimento de software atual é a falta de especificação. Assim, de nada adianta ferramentas avançadas para Web, se a especificação de um sistema continua não existindo ou tendendo a zero.

     Desta maneira, o leitor deve ter percebido, que o WDC possui como insumo uma especificação em CBD/OO.

     No desenvolvimento de nossos dois sistemas corporativos, que deram origem ao WDC, tínhamos uma excelente ferramenta CASE, na qual especificamos todo o projeto.

     Desta forma, não foi necessário o desenvolvimento de uma ferramenta CASE (mini, como já dissemos). Contudo, entendemos que várias empresas não possuem condição para comprar tais ferramentas. Sendo assim, estamos neste momento iniciando o desenvolvimento de uma mini-ferramenta CASE, integrada ao WDC e fornecendo suporte a todos os diagramas da UML, incluindo os diagramas de tipos de negócio e ações provenientes de CBD.

     Esperamos que esteja claro para o leitor, que não acreditamos em milagres de ferramentas para Web. Um software para Web possui vários pontos tecnológicos novos a serem resolvidos, contudo o problema não mudou sua forma de se apresentar.

     Conclusão
     

     O leitor que desenvolve para Web, não deve cair no mesmo erro dos desenvolvedores que utilizam exaustivamente as ferramentas RAD.

     O principal problema é incluir todas as regras de negócio junto com os formulários ou janelas e também no RDBMS. Este erro freqüente nas ferramentas RAD vem se tornando uma prática padrão também para Web. Assim, o reuso se perde completamente, as regras ficam soltas e inconsistentes entre si, a manutenção se torna dificílima e o caos se implanta em seis meses.

     Sugerimos que o desenvolvimento em camadas seja seguido sempre quando possível.

     Em tempo, a linguagem utilizada para produzir os objetos de negócio é o Object Pascal e o ambiente Delphi. Nosso repositório está no Interbase, contudo o application server gera código para SQL Server e Oracle. Estamos trabalhando na tentativa de disponibilizar o WDC para Linux, via Kylix, tendo em vista que nosso código é 90% Object Pascal, ou seja, praticamente não utilizamos componentes Delphi.

     Embora não explorado neste artigo, nosso application server também se comunica com outros front-ends como VB, PowerBuilder, C++ e Java, via DCW (Dynamic Client Window). Mas, esta é outra história. 

     Chegamos ao fim de nosso artigo. Esperamos que o leitor tire o máximo proveito, e novamente nos deixamos a disposição para aqueles que queiram nos contatar. Abaixo deixamos uma lista de URL, onde o leitor pode se aprofundar nas teorias expostas aqui. E para os mais cépticos, deixamos uma versão reduzida, mas full em suas funcionalidades, em nossa página Web do WDC.

     E finalmente, atenderemos as solicitações dos leitores, deixaremos inteiramente Free algumas apostilas de engenharia de software. Para isso basta entrar em contato pelo e-mail especificado abaixo nos créditos.

     Referências bibliográficas

     Object Oriented - www.omg.org
     Component Based Development - www.catalysisgroup.com , www.cbd-hq.com  e
www.dcs.ed.ac.uk/home/pxs/ Book/  
     Pattern - www.hillside.net/patterns/patterns.html
     CORBA - www.corba.org
     DCOM - www.sei.cmu.edu/str/descriptions/com_body.html 
     Application server - http://Java.sun. com/j2ee/ 
     Business rules - www.businessrulesgroup.org 
     Software Engineering - Theory and Practice - Shari Lawrence
     Object-Oriented Software Engineering - Ivar Jacobson
     Objects, Componenets, and Framworks with UML - Desmond - Alan
     Design Pattern - Gamma
     Analysis Patterns - Martin Fowler
     The Essential Distributed Objects - Robert Orfali

     Autor: Rogério Magela Silva
     E-mail: rmagelas@athenasconsulting.com.br
     Biografia: Rogério Magela Silva é engenheiro de computador, pela PUC-RJ. É o criador do processo de Engenharia de Software Athenas Process (antiga Vincit). É sócio-proprietário da Athenas Consulting.