Um Padrão para o Desenvolvimento de Software Baseado em

Um Padrão para o Desenvolvimento de Software
Baseado em Componentes Distribuídos1
Eduardo Santana de Almeida
[email protected]
Calebe de Paula Bianchini
[email protected]
Antonio Francisco do Prado Luis Carlos Trevelin
[email protected]
[email protected]
Departamento de Computação – DC
Universidade Federal de São Carlos – UFSCar
1. Contexto
O Padrão proposto está inserido no contexto do Desenvolvimento Baseado em
Componentes Distribuídos (DBCD), onde a intenção é a criação de componentes distribuídos
reutilizáveis para diferentes domínios de aplicações.
2. Motivação
De maneira a motivar o uso do Padrão, parte de um domínio de Ordem de Serviços
(OS) foi construído. O domínio possui componentes de negócio, como clientes, funcionários,
ordens de serviço e tarefas. Outros requisitos não funcionais, como persistência em banco de
dados, arquitetura distribuída e interfaces, também, foram utilizados no padrão.
Adicionalmente, é utilizado um processo para o desenvolvimento de aplicações, reutilizando
os componentes construídos.
3. Problema
O Desenvolvimento Baseado em Componentes se preocupa com a criação de
componentes que possam ser reutilizados em outras aplicações. A reutilização caracteriza-se
pela utilização de produtos de software, em uma situação diferente daquela para qual estes
produtos foram originalmente construídos [21]. Para aumentar a reutilização de software,
pesquisas [8, 16, 21] apontam, como passo fundamental, a sistematização do processo de
análise e criação de componentes para um determinado domínio de aplicações.
Para que a reutilização possa ser efetiva, deve-se considerá-la em todas as fases do
processo de desenvolvimento do software. Portanto, o Desenvolvimento Baseado em
Componentes (DBC) deve oferecer métodos, técnicas e ferramentas que suportem desde a
identificação e especificação dos componentes, referente ao domínio do problema, até o seu
projeto e implementação em uma linguagem executável. Além disso, o DBC deve empregar
inter-relações entre componentes já existentes, que tenham sido previamente testados, visando
reduzir a complexidade e o custo de desenvolvimento do software [21].
Apesar das recentes e constantes pesquisas na área de DBC, ainda há carência de
métodos, técnicas e ferramentas que suportem tanto o desenvolvimento quanto a reutilização
de componentes, em aplicações de um determinado domínio. Outro problema importante
relaciona-se com a dificuldade de integração das diferentes técnicas e ferramentas que apóiam
o DBC. Considerando o caso de componentes distribuídos, como ocorre na rede Internet, com
plataforma cliente e servidor, o problema é ainda maior.
1
Copyright (c) 2002, Eduardo Santana de Almeida. Permission is granted to copy for the SugarloafPLoP 2002
Conference. All other rights reserved.
Diferentes métodos, técnicas e ferramentas têm sido propostos para suportar o DBC,
destacando-se as ferramentas CASE [7, 9, 17]. Entretanto, a maioria destes métodos, técnicas
e ferramentas, cobrem parcialmente o DBC, principalmente no caso de aplicações
distribuídas.
Assim, o Padrão de DBCD permite:
• a integração de diferentes tecnologias, como UML [3, 12], Catalysis [5, 8],
CORBA [1, 6, 14], e Java [11] em uma ferramenta CASE, para apoiar o DBC,
particularmente o de aplicações distribuídas. A ferramenta CASE automatiza
grande parte das atividades do DBC Distribuídos;
• cobrir todo o ciclo de vida dos componentes distribuídos, desde a fase de
especificação, em alto nível de abstração, na ferramenta CASE, até a sua
implementação em uma linguagem orientada a objetos;
• definir mudanças no código de comunicação dos componentes, de uma forma
minimizada, com a utilização do padrão DAP (Distributed Adapters Pattern)
[1].
4. Solução
Assim, combinando as idéias do método Catalysis de desenvolvimento de software
baseado em componentes, a arquitetura CORBA para especificação dos componentes
distribuídos, os frameworks baseado em Padrões e a ferramenta MVCase [15], definiu-se um
padrão para o Desenvolvimento de Software Baseado em Componentes Distribuídos.
O padrão cobre os três níveis de Catalysis, e é realizado em quatro passos: Definir
Problema, Especificar Componentes, Projetar Componentes e Implementar
Componentes, conforme mostra a Figura 1.
Figura 1 – Padrão de DBC Distribuídos.
Segue-se uma apresentação de cada passo do padrão, instanciado para desenvolver
componentes para um domínio de Ordem de Serviços, o qual faz parte de um domínio maior,
176
o de Gestão de Recursos de Negócio, conforme mostra a Figura 2. Embora o domínio de
Ordem de Serviços não esteja completo, o exemplo serve para mostrar detalhes das técnicas
empregadas, e os principais artefatos gerados em cada passo do padrão.
Figura 2 – Estrutura geral da Gestão de Recursos de Negócio.
4.1 Definir Problema
Conforme mostra a Figura 3, as aplicações do domínio de Ordem de Serviços se
dividem em três grandes módulos: o primeiro, Clientes, é responsável pelo cadastro e
notificação dos clientes de uma determinada ordem de serviço. O segundo, Funcionários, é
responsável pelo cadastro de funcionários e controle das tarefas da ordem de serviço. O
terceiro, Relatórios, é responsável pela emissão de relatórios para a gerência, relacionados
com a consulta de tarefas realizadas e pendentes, ordens de serviços de determinado cliente e
dos funcionários responsáveis por cada tarefa.
Figura 3 – Domínio Ordem de Serviços.
Neste primeiro passo do padrão, é dada ênfase no entendimento do problema,
especificando-se “o quê” os componentes devem atender para solucionar o problema.
Inicialmente, são identificados os requisitos do sistema, usando técnicas como storyboards ou
mind-maps [16], visando representar as diferentes situações e cenários do domínio do
problema. Em seguida, os requisitos identificados são especificados em Modelos de
Colaborações [3, 8, 12], representando a coleção de ações e os objetos participantes.
Finalmente, os modelos de colaborações são refinados em Modelos de Casos de Uso [3, 8,
12].
A Figura 4 resume o primeiro passo do padrão, onde um mind-map, definido na
identificação dos requisitos do domínio Ordem de Serviços, é especificado num Modelo de
177
Colaborações, e, posteriormente, refinado e particionado em um Modelo de Casos de Uso,
visando diminuir a complexidade e melhorar o entendimento do domínio do problema.
Figura 4 - Primeiro Passo do Padrão: Definir Problema.
4.2 Especificar Componentes
Este passo cobre o segundo nível de Catalysis, onde é descrito o comportamento
externo do sistema de uma forma não ambígua. Na ferramenta CASE, o engenheiro de
software refina as especificações do nível anterior, visando obter as especificações dos
componentes.
Esse passo tem início com o refinamento dos modelos do domínio do problema.
Especifica-se o Modelo de Tipos [3, 8, 12], conforme mostra a Figura 5, mostrando atributos
e operações dos tipos de objetos, sem se preocupar com a implementação. Ainda neste passo,
pode-se utilizar o dicionário de dados para especificar cada tipo encontrado, e a Object
Constraint Language (OCL) [3, 12], para detalhar o comportamento dos objetos, sem
ambigüidades.
Figura 5 – Modelo de Tipos do passo Especificar Componentes.
178
Conforme mostra a Figura 6, o Modelo de Tipos é organizado em um Framework de
Modelos de Tipos de componentes [4, 7], com os seus atributos e relacionamentos. O
framework é reutilizado através do Modelo de Aplicação do Framework [4, 7], representando
a dependência dos tipos do framework, com os tipos estendidos na aplicação. Os Modelos de
Casos de Uso, do passo anterior, são refinados em Modelos de Interações representados pelos
diagramas de seqüência [4, 7, 11], para detalhar os cenários de utilização dos componentes
nas diferentes aplicações do domínio do problema.
Figura 6 – Segundo Passo do Padrão: Especificar Componentes.
Em resumo, as atividades deste passo, realizadas pelo engenheiro de software, na
ferramenta MVCase, compreendem a especificação do:
a) Modelo de Tipos;
b) Framework de Modelos de Tipos de componentes;
c) Modelo de Aplicação do Framework, baseado nos Modelos de Tipo de
componentes; e
d) Modelos de Interações representados pelos diagramas de seqüência, baseado
nos Modelos de Casos de Uso.
Estes modelos são utilizados no próximo passo do padrão, para obter o projeto interno
dos componentes.
4.3 Projetar Componentes
Neste passo, o engenheiro de software faz o projeto interno dos componentes,
conforme o terceiro nível de Catalysis. Agora, os detalhes de implementação são importantes,
destacando-se: segurança, persistência, arquitetura distribuída e a linguagem de
implementação.
Como passo inicial, refina-se o Modelo de Tipos em Modelos de Classes de
componentes, onde são modeladas as classes, e seus relacionamentos, preocupando-se com a
definição dos componentes com suas interfaces, conforme mostra a Figura 7. Os Modelos de
Interações, representados pelas técnicas dos diagramas de seqüência são refinados para
mostrar detalhes de projeto dos comportamentos dos métodos dos em cada classe.
179
Figura 7 – Modelo de Classes obtido do Modelo de Tipos.
A partir do Modelo de Classes, pode-se construir o Modelo de Componentes [3, 8, 12],
que mostra a organização e a dependência entre os componentes. O Modelo de Componentes
pode reutilizar componentes de outros frameworks já existentes. Assim, podem ser
reutilizados componentes de domínios relacionados com requisitos não funcionais, como, por
exemplo, para criação de interfaces (GUI) [10], persistência em Banco de Dados
(Persistencia) [10, 19, 23] e distribuição de componentes (Broker) [1, 10]. A Figura 8 mostra
o Modelo de Componentes obtido do Modelo de Classes da Figura 7, fazendo reuso dos
componentes dos frameworks GUI, Persistencia e Broker.
Figura 8 – Modelo de Componentes.
A utilização de Padrões de Projeto do Catálogo de Gamma [10], Abstract Factory,
Factory Method, e Singleton, na construção dos componentes, pode aumentar a sua
reutilização.
A Figura 9 mostra, por exemplo, os componentes do framework GUI. O componente
AbstractToolkit permite criar componentes básicos de widgets, como frames, textfields,
labels, botões, e demais elementos que compõem a interface do usuário. Para melhor
visualização das interfaces, existem, ainda, outros widgets que compõem a interface do
usuário, como: combobox, panel, e textarea que não aparecem na figura, assim como os
componentes da biblioteca swing [11] do Java. Os componentes LinToolkit e WinToolkit
180
implementam os métodos definidos pelo componente AbstractToolkit para as plataformas
Linux e Windows, respectivamente, mantendo a portabilidade da aplicação para diferentes
ambientes. O framework GUI dispõe, ainda, de interfaces para cada tipo de widget, como:
IFrame, ITextField, ILabel, e IButton. Os componentes WinFrame, LinFrame, WinTextField,
LinTextField, WinLabel, LinLabel, WinButton, e LinButton implementam os widgets,
conforme a plataforma de execução da interface.
Figura 9 – Framework GUI.
Da mesma forma, têm-se os componentes dos demais frameworks, como no caso do
framework Persistencia, que suporta a persistência das informações em banco de dados
relacional. Baseia-se nos padrões de Projeto do Catálogo de Gamma, Singleton, Facade e
outros, como PersistentObject [10, 23] e ObjectPool [10, 23].
A Figura 10 mostra componentes do framework Persistencia. O componente
ConnectionPool, através de sua interface IConnectionPool, faz a gerência e conexão com o
banco de dados utilizado na aplicação. O componente DriversUtil, com base em definições
eXtensible Markup Language (XML) [22], contém as informações do banco de dados
disponibilizadas, através de sua interface IDriverUtil. O componente TableManager gerencia
o mapeamento de um objeto para tabelas do banco de dados, disponibilizando seus métodos
pela interface ITableManager. O componente persistente da estrutura FacadePersistent,
através de sua interface IPersistentObject, disponibiliza os valores que devem ser adicionados
ao banco de dados, passando parâmetros ao componente TableManager.
Figura 10 – Framework Persistencia.
Os componentes do framework Broker utilizam o Padrão Distributed Adapters Pattern
(DAP) [1] para comunicação remota entre dois componentes. A técnica adotada pelo DAP
181
para oferecer esta funcionalidade é introduzir um par de componentes adaptadores, visando
conseguir um melhor desacoplamento dos componentes dentro de uma arquitetura distribuída.
Os adaptadores, basicamente, encapsulam a API, necessária para permitir o acesso remoto,
para componentes Targets. Deste modo, componentes Sources de uma aplicação possuem
autonomia em relação à camada de distribuição, e as mudanças nesta camada não causam
impactos. A Figura 11 mostra a estrutura do framework Broker. Os componentes Source e
Target abstraem regras de negócio, do domínio de um problema. A interface TargetInterface
abstrai o comportamento do componente Target em um cenário distribuído. Tanto esta
interface, como os componentes, Source e Target, não possuem código de comunicação. Estes
três elementos constituem uma camada independente de distribuição.
Os principais componentes do framework Broker são SourceAdapter e TargetAdapter.
Estes elementos estão conectados a uma específica API de distribuição e encapsulam os
detalhes de comunicação. SourceAdapter é um adaptador que isola o componente Source do
código de distribuição. Reside na mesma máquina que o Source e trabalha como um proxy
para o TargetAdapter. TargetAdapter reside em outra máquina, isolando o componente
Target do código de distribuição. SourceAdapter e TargetAdapter, usualmente, residem em
máquinas diferentes, e não interagem diretamente. TargetAdapter implementa a
RemoteInterface usada para conectar com SourceAdapter. O componente Initializer reside na
mesma máquina que os componentes Target e TargetAdapter, e é responsável pela criação
dos componentes TargetAdapter e Target [1].
Figura 11 – Estrutura do Framework Broker.
A Figura 12 resume os principais artefatos e a seqüência de atividades do passo
Projetar Componentes, que incluem:
a) Refinamento dos Modelos de Tipos em Modelos de Classes;
b) Refinamento dos Modelos de Interações; e
c) Criação dos Modelos de Componentes, com reutilização de componentes já
disponíveis.
Figura 12 – Terceiro passo do Padrão: Projetar Componentes.
182
4.4. Implementar Componentes
Por último, após o projeto dos componentes, o engenheiro de software determina, na
MVCase, que se faça a geração automática do código dos stubs e skeletons, e interfaces dos
componentes.
A Figura 13 mostra parte dos componentes projetados do Domínio Ordem de
Serviços, e os respectivos códigos em IDL e Java gerados. A geração do código é feita com o
utilitário idlj, nativo do Java Development Kit (JDK), disponibilizado na ferramenta.
Figura 13 – Quarto passo do Padrão: Implementar Componentes.
Resumindo, as principais atividades do passo Implementar Componentes, realizada
pelo engenheiro de software, na ferramenta MVCase, incluem a geração dos códigos IDL e
Java dos componentes distribuídos.
5. Consequências
O Padrão de Desenvolvimento de Software Baseado em Componentes Distribuídos
oferece os seguintes benefícios:
• Modularidade: o Padrão permite separar os aspectos de distribuição, interface e
persistência em banco de dados;
• Reutilização: através dos aspectos de modularidade oferecidos com a divisão em
camadas, os desenvolvedores podem reutilizar os componentes para diversas
aplicações do domínio construído, diminuindo a redundância de código;
• Automação Parcial: com o suporte da ferramenta MVCase, grande parte das
atividades propostas no padrão podem ser executadas de forma automática.
Mesmo com as vantagens listadas acima, as seguintes desvantagens podem ser
apresentadas:
• Incremental número de classes [1]: com a utilização do padrão DAP, usa-se um par
de adaptadores, componentes de inicialização e nomeação que são necessários; de
qualquer modo, estas estruturas podem ser geradas através da automação parcial,
utilizando a ferramenta MVCase;
• Conhecimento de outras tecnologias: com o uso do framework Persistencia, o
engenheiro de software necessita conhecer tecnologias, como o XML, para
definição das informações referentes aos sistemas gerenciadores de banco de
dados, como porta de conexão, nome do usuário, senha, e outros.
183
6. Implementação
Para suportar o padrão proposto para DBC Distribuídos, são utilizados diferentes
métodos, técnicas e ferramentas, apresentados a seguir.
6.1 Método Catalysis
O padrão baseia-se no método Catalysis [5, 8] para DBC, que é executado em três
níveis: Definição do Domínio do Problema, onde é dada ênfase no entendimento do problema,
especificando-se “o quê” o sistema deve atender para solucionar o problema; Especificação
dos Componentes, onde é descrito o comportamento do sistema de uma forma não ambígua;
e, Projeto Interno dos Componentes, onde define-se como serão implementados os requisitos
especificados para os componentes.
Catalysis fundamenta-se nos princípios de abstração, precisão e componentes “plugin”. O princípio abstração orienta o desenvolvedor na busca dos aspectos essenciais do
sistema, dispensando detalhes que não são relevantes para o contexto do sistema. O princípio
precisão tem como objetivo descobrir erros e inconsistências na modelagem e o princípio
componentes “plug-in” suporta o reuso de componentes para construir outros sistemas.
6.2 Common Object Request Broker Architecture (CORBA)
No DBC é necessário estabelecer uma relação formal entre os componentes e a
aplicação que os utiliza, por meio de interfaces bem definidas. Para atender a este requisito, o
padrão de DBC Distribuídos baseia-se na arquitetura CORBA [1, 6, 14], que é um padrão
estabelecido pela Object Management Group (OMG) para suporte a objetos distribuídos.
CORBA apresenta interfaces bem definidas e independentes de aplicações, através da
Interface Definition Language (IDL), que se encaixa perfeitamente no contexto de DBC.
Outros aspectos que motivaram o uso do CORBA foram: a independência de
linguagem de programação, devido ao mapeamento da IDL para diversas linguagens; a
portabilidade entre ambientes computacionais; e os serviços de Segurança, Nomeação e
Notificação, oferecidos pela especificação.
6.3 Frameworks e Padrões
Para especificar e construir componentes de software mais seguros, confiáveis, fáceis
de manter e de utilizar, o DBC emprega técnicas de frameworks, baseados em Padrões [10,
12]. Framework é um conjunto de classes relacionadas, que fazem reuso de um projeto para
classes específicas de software [10]. A utilização de padrões em sistemas complexos de
softwares permite que soluções previamente testadas sejam reutilizadas, tornando o sistema
mais compreensível, flexível, fácil de desenvolver e de manter. O objetivo do uso de padrões
de software é a disseminação das soluções de desenvolvimento de software já existentes. O
uso de padrões na construção de frameworks objetiva torná-los ainda mais flexíveis, e,
principalmente, facilitar a reutilização dos componentes no desenvolvimento das aplicações.
6.4 Ferramenta MVCase
Ferramentas CASE têm sido empregadas, com sucesso, no projeto ou reprojeto de
sistemas a serem reconstruídos. Dentre as ferramentas CASE, destaca-se a MVCase [15], que
suporta a especificação do sistema em linguagens de modelagem orientadas a objetos, gera
código, automaticamente, em uma linguagem de programação orientada a objetos, a partir das
especificações em alto nível, usando componentes distribuídos especificados em IDL.
A MVCase utiliza uma arquitetura em três camadas para construção de componentes.
As três camadas permitem que o engenheiro de software separe as aplicações clientes das
184
regras de negócio, e dos serviços de armazenamento em banco de dados, ou outro meio de
armazenamento.
Os componentes destas camadas podem ser distribuídos em diferentes plataformas,
suportando aplicações cliente-servidor, que podem ser executadas pela internet.
7. Exemplo de Aplicação do Padrão
Uma vez construídos, os componentes podem ser reutilizados pelas aplicações do
domínio. A Figura 14 mostra os passos para o desenvolvimento das aplicações. Parte-se dos
requisitos da aplicação e segue-se o ciclo de vida normal de desenvolvimento, que
compreende: Especificar Aplicação, Projetar Aplicação, Implementar Aplicação e Testar
Aplicação. As principais diferenças do ciclo de vida normal do software estão na reutilização
dos componentes previamente construídos e na distribuição de objetos, baseado na arquitetura
CORBA.
Figura 14- Desenvolvimento de aplicações usando Componentes.
Para melhor compreensão, o desenvolvimento será instanciado para uma aplicação que
registra uma ordem de serviço, do domínio Ordem de Serviço (OS), cujos componentes foram
construídos.
7.1 Especificar Aplicação
Este passo tem inicio com o entendimento do problema, identificando-se os requisitos
da aplicação. Antes de iniciar a especificação dos requisitos da aplicação, na MVCase, o
engenheiro de software importa os componentes do domínio do problema, no caso OS, que
serão reutilizados pela aplicação. Em seguida, o engenheiro de software especifica os
requisitos em Diagramas de Casos de Uso e de Seqüência. A Figura 15 mostra o Caso de Uso
RegistrarOrdemServico e o Diagrama de Seqüência do seu curso normal.
185
Figura 15 – Diagrama de Caso de Uso e Seqüência.
Continuando a modelagem, o engenheiro de software especifica o modelo de classes
da aplicação. No caso, foi criada a classe FrameRegistrarOrdemServico, que reutiliza os
serviços dos componentes do domínio OS. A Figura 16 mostra quatro componentes
(sombreados), reutilizados na aplicação Registrar Ordem de Serviço.
Figura 16 – Componentes reutilizados para Aplicação Registrar Ordem de Serviço.
7.2 Projetar Aplicação
As especificações do passo anterior são refinadas pelo engenheiro de software para
obter o projeto da aplicação. Neste passo, são especificados os requisitos não funcionais,
relacionados com: segurança da aplicação, arquitetura distribuída, linguagem de
implementação, e outros.
A Figura 17 mostra o diagrama de componentes do projeto da aplicação, onde foram
adicionados os componentes DriversUtil, ConnectionPool, FacadePersistent e TableManager
para tratar o acesso a banco de dados e os componentes OrdemServicoSourceAdapter,
186
TargetOrdemServico, Initializer e OrdemServicoTargetAdapter para tratar a distribuição dos
objetos.
Figura 17 – Projeto da Aplicação.
7.3 Implementar Aplicação
Com base no projeto da aplicação, o engenheiro de software utiliza o gerador de
código da MVCase para fazer sua implementação. A Figura 18 mostra parte do código gerado
para a aplicação Registrar Ordem de Serviço.
Figura 18 – Implementação da Aplicação Registrar Ordem de Serviço.
Após a implementação da aplicação, o engenheiro de software passa para o último
passo, que consiste em testar a aplicação.
187
7.4 Testar Aplicação
Neste passo, o engenheiro de software realiza os testes com a aplicação, para verificar
se a mesma atende aos requisitos especificados. Os testes ficam facilitados, considerando que
os componentes reutilizados já foram previamente testados.
A Figura 19 mostra o ambiente de execução e teste da aplicação, utilizando os pacotes
de componentes GUI, Broker, Persistencia e OS numa arquitetura distribuída cliente e
servidor.
Figura 19 – Teste da Aplicação de Ordem de Serviço.
A aplicação pode ser executada em diferentes sistemas operacionais e CPUs, e os
resultados das execuções são analisados pelo engenheiro de software, para verificar se
atendem aos requisitos da aplicação. Estes resultados fornecem um feedback para os passos
anteriores, orientando as correções.
8. Padrões Relacionados
•
•
•
•
Abstract Factory, Factory Method e Singleton. O framework GUI é implementado
usando os padrões de projeto [9] Abstract Factory, Factory Method e Singleton.
Broker e Trader. O Broker [4] e o Trader [4] são padrões arquiteturais com o
principal objetivo de permitir mecanismos de distribuição específicos, como
empacotamentos de parâmetros e protocolos de mensagens. DAP usa estes padrões
e provê um alto nível de abstração, com transparência de API de distribuição para
ambos, clientes e servidores [1].
Wrapper-Facade [18] e DAP possuem objetivos comuns de minimizar variações
no código das aplicações com mudanças de plataformas. De qualquer modo,
Wrapper-Facade encapsula existentes APIs não orientadas a objetos (como
sockets, threads), enquanto DAP encapsula APIs de distribuição orientada a
objetos, como RMI (Remote Method Invocation) [20] e CORBA.
Facade, PersistentObject e ObjectPool. O framework Persistencia é implementado
usando os padrões de projeto Singleton e Facade, e, padrões para persistência em
banco de dados [20], como PersistentObject e ObjectPool.
188
9. Agradecimentos
Os autores gostariam de agradecer ao Shepherd Dr. Jugurta Lisboa Filho pelas criticas
e sugestões recebidas durante o andamento deste processo.
10. Referências
[1] ALVES, V., BORBA, P. Distributed Adapters Pattern: A Design Pattern for Object-Oriented
Distributed Applications, I Conferência Latino Americana em Linguagens de Padrões para
Programação. Rio de Janeiro 2001.
[2] BEM-NATAN, R. CORBA A Guide to the Common Object Request Broker Architecture.
Mc-Graw-Hill, 1995.
[3] BOOCH, G. UML Guia do Usuário. Editora Campus, 2000.
[4] BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P., STAL, M. Pattern
Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996.
[5] CATALYSIS. Catalysis Enterprise Components with UML. Disponível: site URL:
http://www.catalysis.org. Consultado em 10/08/2001.
[6] CORBA. The Common Object Request Broker: Architecture and Specification. Disponível: site
OMG (1996). URL: http://www.omg.org. Consultado em 10/04/2001.
[7] COOL:GEN. Ferramenta Cool:Gen. Disponível: site URL: http://cai.com/acq/sterling. Consultado
em 10/07/2001.
[8] D’SOUZA, D.; WILLS, A. Objects, Components and Frameworks with UML – The Catalysis
Approach. USA:Addison Wesley, 1998.
[9] ERWIN. Ferramenta Erwin. Disponível: site URL: http://www.cai.com. Consultado em
10/07/2001.
[10] GAMMA, E. et al. Design Patterns. Elements of Reusable Object-Oriented Software. Ed.
Addison-Wesley. USA.1995.
[11] HORSTMANN, S, C. Core Java2 Volume2-Advanced Features. Sun Microsystems Hal 1999.
[12] LARMAN, C. Utilizando UML e Padrões. Prentice Hall , Inc, 1999.
[13] NETSCAPE. Introduction to SSL. Disponível site DevEdge OnLine (1998). URL:
http://developer.netscape.com/docs/manuals/security/sslin/index.htm. Consultado em 02/05/2001.
[14] ORFALI, R., HARKEY, D. Client/Server Programming with Java and CORBA. John Wiley &
Sons, Second Edition, 1998.
[15] LUCRÉDIO, D., PRADO, A. F. Ferramenta MVCASE – Estágio Atual: Especificação, Projeto
e Construção de Componentes, XV Simpósio Brasileiro de Engenharia de Software, Sessão de
Ferramentas. Outubro de 2001.
[16] PRESSMAN, R. S. Software Engineering: A Practitioner's Approach. 5th Edition, june 2000.
[17] ROSE. Ferramenta Rational Rose. Disponível: site URL: http://www.rational.com. Consultado em
10/07/2001.
[18] SCHMIDT, D., STAL, M., ROHNERT, H., BUSCHMANN, F. Pattern Oriented Software
Architecture. John Wiley & Sons, 1996.
[19] SOBRAL, D. Framework para Comércio Eletrônico Mediado por Agentes de Software.
Dissertação de Mestrado. DC UFSCar fevereiro de 2002.
[20] SUN. RMI Specification. Disponível: site URL: http://www.sun.com/products/jdk/rmi/index.html.
Consultado em 10/01/2002.
[21] WERNER, C.M.L., BRAGA, R. M.M. Desenvolvimento Baseado em Componentes. XIV
Simpósio Brasileiro de Engenharia de Software SBES2000 – Minicursos e Tutoriais – pg. 297-329 –
2-6 de Outubro, 2000.
189
[22] XML. Extensible Markup Language (XML) 1.0 Second Edition. Disponível: site URL:
http://www.w3.org/TR/2000/REC-xml-2000-10-06. Consultado em 10/07/2001.
[23] YODER, J.W., JOHNSON, R.E., WILSON, Q.D. – Connecting Business Objects to Relational
Databases. In: Conference on the PLOP, 5, Monticello-IL, EUA. Proceedings 1998.
190