artigo Desenvolvimento de sistemas baseado em componentes

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Desenvolvimento Baseado em Componentes: Experiências 
de Sucesso 
Leonardo Guerreiro Azevedo1, Fernanda Baião1,2, Márcio Duran1, José Roberto 
Blaschek3, Jano Moreira de Souza1,4, Geraldo Zimbrão1,4 
1Programa de Engenharia de Sistemas e Computação - Universidade Federal do Rio de 
Janeiro (UFRJ) 
Caixa Postal 68.511 - 21945-970 - Rio de Janeiro – Brasil 
2Departamento de Informática Aplicada – Universidade Federal do Estado do Rio de 
Janeiro (UNIRIO) – Rio de Janeiro – Brasil 
3Faculdade de Administração e Finanças – Universidade Estadual do Rio de Janeiro 
(UERJ) – Rio de Janeiro – Brasil. 
4Departamento de Ciência da Computação – Instituto de Matemática – Universidade 
Federal do Rio de Janeiro (UFRJ) – Rio de Janeiro - Brasil 
azevedo@cos.ufrj.br, baiao@cos.ufrj.br, mlfduran@cos.ufrj.br, 
blachek@attglobal.net, jano@cos.ufrj.br, zimbrao@cos.ufrj.br 
Abstract. This work presents experiences of the use of a software development 
process, based in components and derived from RUP and UML, and a team 
appropriate organization for its use. The process and team characteristics are 
also presented. The proposed process regards practical and efficient 
principles in order to guide the development leading to good results, 
increasing the productivity and the quality of the process and the product. 
Resumo. Este trabalho relata experiências de uso de um processo de 
desenvolvimento de software, baseado em componentes e derivado do RUP e 
da UML, e de uma organização de equipe de desenvolvimento adequada ao 
seu uso. As características do processo utilizado e da equipe são 
apresentadas. O processo proposto contemplou diretrizes práticas e eficientes 
para orientar o desenvolvimento, apresentando bons resultados de aumento de 
produtividade e da qualidade do processo e do produto resultante. 
1. Introdução 
No início deste novo século, onde rapidez no desenvolvimento, qualidade e flexibilidade 
dos sistemas de informação tornaram-se um aspecto crítico para a sobrevivência das 
organizações, o desenvolvimento de sistemas baseados em componentes tem sido 
apontado como solução [Allen e Frost 1998] e [Szyperski 1997]. 
 Por outro lado, no contexto das organizações, promover mudanças nos 
paradigmas de desenvolvimento de sistemas de informação não é tarefa simples, 
envolvendo não só um processo complexo de treinamento das equipes de 
desenvolvimento em novas tecnologias, como também a definição de novos processos 
de software e a seleção de novos métodos e ferramentas. 
 
 Este artigo relata três experiências diferentes e bem sucedidas de mudanças de 
paradigmas de desenvolvimento, do tradicional para o baseado em componentes, que 
resultaram em sistemas de qualidade e que atenderam às expectativas dos usuários, 
dentro de prazos e custos previstos. Para o relato destas experiências, a seção 2 do artigo 
caracteriza os três projetos; a seção 3 apresenta o processo, os métodos e os diagramas 
utilizados; e a seção 4 mostra como a equipe foi organizada para executar o 
desenvolvimento. As conclusões são apresentadas na seção 5. 
2. Caracterização dos Projetos 
Esta seção descreve três sistemas em que o desenvolvimento baseado em componentes 
foi essencial para o sucesso dos projetos. 
Os sistemas descritos a seguir foram desenvolvidos para uma organização com 
unidades de armazenamento localizadas geograficamente em várias regiões do Brasil e 
do exterior. Para o desenvolvimento dos sistemas, foram utilizadas arquiteturas em 
plataformas baixas distintas: uma arquitetura cliente servidor em duas camadas, com 
sistema gerenciador de bases de dados (SGBD) Oracle e linguagem de programação 
(LP) Delphi, e uma segunda em quatro camadas, também com SGBD Oracle e LP ASP 
com componentes em Visual Basic. 
2.1. Descrição do domínio dos sistemas 
O primeiro sistema desenvolvido englobou as funções de controle financeiro, 
distribuição de estoque, identificação e catalogação do material fornecido, compra de 
material junto a fornecedores externos, entre outras. O sistema foi implementado com o 
objetivo de substituir um sistema legado, que era executado em um ambiente de 
plataforma alta, com custo operacional elevado e interface com o usuário baseada em 
caracter, ou seja, extremamente rígida e com funcionalidades limitadas. Um segundo 
sistema foi desenvolvido para dar suporte às funções de auditoria e análise de contas de 
outro departamento da mesma organização. Neste contexto, os dois novos sistemas 
foram construídos, independentemente, usando uma arquitetura cliente-servidor em duas 
camadas, com interface gráfica orientada a evento, utilizando uma abordagem RAD 
(Rapid Application Development) [McConnell 1996]. O primeiro sistema encontra-se 
em produção desde março de 2001. A primeira versão do segundo sistema foi 
disponibilizada em abril de 2002, tendo sido desenvolvida num período de 5 meses. 
A terceira experiência foi o desenvolvimento de um sistema para o 
gerenciamento de transporte de carga da mesma organização, incluindo importações e 
exportações de material. Entre as atividades principais, destacam-se o controle de todo o 
fluxo de transporte de material e controle do custo associado a este transporte. O fato de 
os depósitos de materiais estarem geograficamente distribuídos e de existirem pontos 
móveis de entrega e retirada de material foram requisitos para a escolha do 
desenvolvimento de um sistema voltado para WEB, com arquitetura cliente servidor em 
quatro camadas, utilizando o modelo MVC [Gamma et al. 1995]. O primeiro módulo 
desde sistema encontra-se atualmente em produção. 
Todos os três sistemas foram desenvolvidos dentro das expectativas de tempo e 
de custo estimadas no plano de projeto, tendo sido muito bem aceitos pelos usuários da 
organização. 
 
2.2. Eliminando os riscos através de componentes 
As características dos projetos determinaram diversos desafios e riscos, entre os quais 
destacam: 
• Aumentar o grau de modularização dos sistemas através da criação de 
componentes reutilizáveis; 
• Melhorar a produtividade das equipes de desenvolvimento para viabilizar a 
execução dos projetos dentro do cronograma estabelecido; 
• Garantir a qualidade do desenvolvimento realizado por diversas equipes 
constituídas por pessoas com formação heterogênea; 
• Definir um padrão de interface funcional e de fácil uso, para todo o sistema, 
implementada em todos os subsistemas por todas as equipes, garantindo uma 
identidade visual do sistema como um todo e facilitando o aprendizado pelos 
usuários; 
• Estabelecer um padrão de codificação, principalmente para aumentar a 
manutenibilidade das aplicações; 
• Garantir o bom desempenho do sistema, mesmo para o ambiente de rede 
metropolitanas. 
Com a análise destes riscos, optou-se pelo desenvolvimento baseado em 
componentes. Os componentes criados na primeira experiência foram essencialmente 
componentes de interface, segurança (controle de acesso às funcionalidades do sistema) 
e de acesso a dados, com o objetivo de padronizar a interface com o usuário e obter um 
bom desempenho. Na segunda experiência, com a aplicação da arquitetura MVC, foram 
criados componentes de modelo, incluindo objetos de negócio e de dados, componentes 
de vista (ou de interface) e de controle da aplicação. 
O desenvolvimento baseado em componentes foi essencial para evitar os riscos 
acima, possibilitar o aumento do reuso, incrementar a produtividade das equipes, 
estabelecer padrões para a codificação e garantir a qualidade do processo e dos produtos 
resultantes. Todas essas vantagens puderam ser alcançadas através da utilização do 
modelo orientado a objetos em todas as fases do desenvolvimento. 
Durante a implementação do sistema dois tipos diferentes de componentes foram 
desenvolvidos: componentes com funcionalidades mais gerais (por exemplo, 
componentes de acesso a dados); e componentes
mais específicos (por exemplo, 
componentes responsáveis pela execução de uma determinada regra de negócio 
específica de um dos módulos do sistema). 
O desenvolvimento do primeiro tipo de componentes fez surgir um novo 
desafio: a construção de componentes de qualidade a serem reutilizados em todos os 
módulos dos sistemas. Isto tornou essencial a definição de um processo de 
desenvolvimento adequado e a definição de uma equipe dedicada ao desenvolvimento 
dos componentes. O processo de desenvolvimento é discutido na Seção 3 e a 
organização e estrutura da equipe na Seção 4. 
 
3. Processo de desenvolvimento orientado a componentes usando a UML 
Esta seção descreve o processo de desenvolvimento orientado a componentes que foi 
seguido para os sistemas apresentados na seção 2. O processo de desenvolvimento 
baseou-se no RUP [Kruchten 1999], o qual foi estendido para melhor suportar a 
construção de componentes, incluindo o uso da UML [Cheesman e Daniels 2000]. Este 
processo define uma seqüência de atividades que devem ser conduzidas para a 
identificação, especificação, análise, projeto e distribuição dos componentes da 
aplicação. Além disso, o processo proposto contemplou diretrizes práticas e eficientes 
para orientar o desenvolvimento de aplicações baseadas em componentes, apresentando 
bons resultados de aumento de produtividade e da qualidade do processo e do produto 
resultante. 
A primeira fase do processo de desenvolvimento foi a fase de concepção, cujo 
propósito incluiu: identificar o problema ou oportunidade de negócio; definir o escopo 
do projeto; identificar os requisitos do usuário e as funcionalidades que o sistema deve 
possuir para atender tais requisitos; identificar premissas e restrições existentes no 
ambiente que interfiram no sistema; além de prever o custo e o tempo de 
desenvolvimento do sistema. 
Para atingir tais objetivos, foram conduzidas as primeiras entrevistas com os 
usuários do sistema para construir o “Modelo Conceitual de Negócio”, representando os 
conceitos do domínio através de um diagrama de classes da UML [Rumbaugh 1999]. 
Em seguida, construiu-se o “Modelo do Processo”, representando todo o fluxo de 
atividades do sistema através do diagrama de atividades da UML. O próximo passo foi a 
construção dos diagramas de casos de uso essenciais [Larman 1998], detalhando cada 
funcionalidade do sistema, com suas respectivas descrições e casos de teste. Todos estes 
produtos foram então validados com o usuário através de reuniões JAD [Wood e Silver 
1996]. Esta validação foi essencial para assegurar o correto entendimento do escopo do 
sistema pela equipe de desenvolvimento. 
Após a fase de concepção, passou-se para a fase de elaboração, responsável pela 
confecção do plano de projeto, que incluiu: a lista de riscos do projeto, estimativa do 
tempo de preparação da infra-estrutura de desenvolvimento, planejamento da 
importação de dados legados, definição dos critérios de aceitação e validação dos 
produtos pelo usuário, estabelecimento das prioridades para o projeto e o cronograma de 
desenvolvimento, com marcos e pontos de controle para que o usuário pudesse 
acompanhar o andamento do projeto e validar os artefatos de software produzidos. 
A terceira fase do processo de desenvolvimento, denominada construção, teve 
como propósito entregar ao usuário as versões atendendo às suas necessidades, com 
bom desempenho, sem erros, e no tempo estimado. Essa fase caracterizou-se pelo 
desenvolvimento do sistema e disponibilização de uma versão do sistema em produção. 
A primeira versão do sistema contemplou os casos de uso definidos como prioritários 
pelo usuário. 
A seqüência de atividades realizadas na fase de construção foi: a preparação do 
ambiente de desenvolvimento, análise e projeto, codificação, realização de testes, 
elaboração da documentação e validação do usuário. 
 
A mais importante destas atividades foi a de análise e projeto, já que foi a 
responsável por especificar e modelar os requisitos do sistema de forma a possibilitar a 
identificação e desenvolvimento dos componentes. A modelagem seguiu o padrão 
UML, através da elaboração dos seguintes produtos: 
• Diagrama de Casos de Uso Reais [Larman 1998], detalhando as 
funcionalidades identificadas no diagrama de casos de uso essenciais da fase 
de concepção; 
• Diagrama de Dados, representado por um diagrama Entidade-
Relacionamento, identificando e modelando as tabelas e atributos do(s) 
SGBD(s) necessários para implementação dos objetos de dados; 
• Diagrama de Interface de Componentes, representado por um diagrama de 
classes da UML, identificando os métodos de cada componente 
(componentes de interface e dados na primeira e segunda experiências, e 
componentes do modelo MVC na segunda) disponíveis para a interação entre 
eles. Neste ponto, os componentes foram identificados através dos eventos 
extraídos da descrição dos casos de uso reais, seguindo a abordagem 
sugerida em [Poo 1999]; 
• Diagrama de Seqüência, descrevendo a seqüência de mensagens trocadas 
entre os componentes necessárias para a implementação dos casos de uso 
reais; 
• Diagrama de Componentes, especificando os métodos públicos e privados de 
cada componente identificado no Diagrama de Interface de Componentes 
anterior, e agrupando-os em “packages” que definiram as bibliotecas de 
componentes (ex.: DLL’s, arquivos “.jar”) geradas na etapa de 
implementação. Neste diagrama foram também representados todos os 
artefatos de software (ex.: stored procedures, páginas html e java scripts) 
utilizados na implementação dos componentes. 
• Diagrama da Arquitetura do Sistema, representado por um Diagrama de 
Desenvolvimento da UML (Deployment Diagram), identificando a 
distribuição de cada componente ou artefato de software pelos servidores do 
sistema (Web Server, servidores de aplicação, servidores de banco de dados 
e máquinas cliente). Esta representação foi importante para visualizar a 
arquitetura na qual o sistema é executado. 
A realização de validações periódicas com o usuário (previstas no cronograma 
pelos marcos e pontos de controle estabelecidos) permitiu a identificação antecipada de 
eventuais atrasos no cronograma. No momento da identificação de um atraso, foram 
avaliadas as causas e tomadas as devidas providências para que o atraso não impactasse 
a entrega dos produtos previstos no cronograma. 
Finalmente, a última fase do processo de desenvolvimento foi a fase de 
implantação, onde foram realizadas as atividades de preparação, configuração e 
documentação do ambiente de operação do sistema; instalação da nova versão do 
sistema; elaboração do manual de instalação; e realização de testes para garantir a 
operação do sistema pelo usuário. Além disso, esta fase também foi responsável pela 
manutenção das versões que já se encontravam em produção. 
 
4. Organização da Equipe de Desenvolvimento 
Para alcançar o sucesso na construção de um sistema baseado em componentes foi 
essencial definir uma equipe dedicada ao seu desenvolvimento dos componentes 
genéricos. Entre as responsabilidades desta equipe destacou-se a aplicação do processo 
de desenvolvimento descrito na Seção 3, e a definição de padrões de codificação (como 
por exemplo definir as regras de nomenclaturas e relacionar as boas práticas de 
programação que devem ser utilizadas e as más técnicas que devem se evitadas). Esta 
equipe também zelou pela qualidade do desenvolvimento realizado pelas diversas 
equipes que participaram da implementação da aplicação. Desta forma, enquanto os 
analistas de componentes foram responsáveis pelo projeto e qualidade dos componentes, 
os analistas de aplicação foram responsáveis pelo levantamento de requisitos junto ao 
usuário, pelo projeto em alto nível e pela construção da aplicação, utilizando os 
componentes criados pela equipe anterior. A Figura 1 apresenta a estrutura
da equipe de 
desenvolvimento, a qual foi dividida em equipe de componentes e equipe de aplicacao, 
sendo ambas coordenadas pelo gerente. 
O gerente desempenha um papel muito importante no processo de 
desenvolvimento. Ele é o responsável por coordenar as duas equipes e por garantir a 
perfeita comunicação entre as mesmas. Esta interação foi essencial para definir os 
requisitos dos componentes criados, já que coube à equipe da aplicação determinar as 
necessidades que precisavam ser supridas pelos componentes. O gerente deve ser uma 
pessoa capaz de identificar oportunidades para a componentização ou aplicação de 
reuso, a fim de impedir que as equipes trabalhassem de forma distinta e 
implementassem as mesmas funcionalidades de maneiras diferentes. 
EQUIPE DE COMPONENTES
GERENTE
ANALISTA DE COMPONENTES ANALISTA DE APLICAÇÃO
PROGRAMADORES E 
DESIGNER
PROGRAMADORES E 
DESIGNER
EQUIPE DE APLICAÇÃOEQUIPE DE COMPONENTES
GERENTE
ANALISTA DE COMPONENTES ANALISTA DE APLICAÇÃO
PROGRAMADORES E 
DESIGNER
PROGRAMADORES E 
DESIGNER
EQUIPE DE APLICAÇÃO
 
Figura 1: Estrutura da equipe de desenvolvimento 
Foi necessário ter também um ambiente de homologação dos novos 
componentes, já que os sistemas desenvolvidos baseados em componentes são 
tipicamente muito sensíveis a qualquer problema que surja nos mesmos. O ambiente de 
homologação permitiu a realização de testes, reduzindo assim o impacto no 
desenvolvimento das aplicações. Após a homologação, os componentes eram liberados 
para a equipe de aplicação para utilização e testes. Somente após a validação dos 
componentes pela equipe de aplicação, estes eram então liberados para a entrada em 
produção. 
A comunicação entre as equipes de componente e de aplicação foi um fator de 
risco acompanhado cuidadosamente de forma a garantir que a equipe de aplicação 
 
tomasse conhecimento de qualquer alteração produzida nos componentes. A divulgação 
dos novos componentes também era muito importante, inclusive com a realização de 
treinamentos para a equipe de aplicação para tornar mais clara a forma correta de uso 
dos novos componentes. Portanto, a adoção destes procedimentos de homologação e 
comunicação entre as equipes foi essencial para aumentar a qualidade dos componentes, 
e conseqüentemente do sistema como um todo. 
5. Conclusão 
Na nova economia, os gerentes de tecnologia de informação (TI) enfrentam sérias 
dificuldades para atender às necessidades de mudança das organizações. Se por um lado 
as novas tecnologias e os novos processos de desenvolvimento são apontados como 
solução, a implantação de processos de mudanças é lenta e oferece muitos riscos. 
Este artigo relatou duas experiências de mudança desses paradigmas, 
enfatizando aspectos técnicos do desenvolvimento e de organização de equipes de 
desenvolvimento. 
O processo de desenvolvimento descrito neste trabalho baseou-se no RUP, e foi 
estendido para suportar mais adequadamente a construção de sistemas orientados a 
componentes e o uso da UML. 
A simplicidade do processo e dos métodos descritos neste trabalho constituiu 
uma importante vantagem para o sucesso na sua utilização. 
Referências 
Allen, P. e Frost, S. (1998) “Component -Based Development for Enterprise Systems”, 
Cambridge University Press. 
Cheesman, J. e Daniels, J. (2000) “UML Components: A Simple Process for Specifying 
Component-Based Software”, Addison Wesley. 
Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1995) “Design Patterns”, Addison 
Wesley Pub. 
Kruchten P. (1999), “The Rational Unified Process - an Introduction”, Addison -Wesley. 
Larman, C. (1998) “Applying UML and Patterns”, Prentice -Hall. 
McConnell, S. (1996) “Rapid Development”, Microsoft Press. 
Poo, D.C.D. (1999) Events in Use Case as a Basis for Identifying and Specifying 
Classes and Business Rules, Anais da “TOOLS 29 Conference”, Nancy, France, 
Junho. 
Rumbaugh, J., Jacobson, I., Booch, G. (1999) “The Unified Modeling Language 
Reference Manual”, Addison -Wesley. 
Szyperski, C. (1997) “Component Software: Beyond Object -Oriented Programming”, 
Addison-Wesley. 
Wood, J. e Silver, D. (1996) “Joint Application Development”, 2 nd ed., New York, 
Wiley.