Desenvolvimento Baseado em Componentes: Experiências de Sucesso

Transcrição

1 Desenvolvimento Baseado em Componentes: Experiências de Sucesso Leonardo Guerreiro Azevedo 1, Fernanda Baião 1,2, Márcio Duran 1, José Roberto Blaschek 3, Jano Moreira de Souza 1,4, Geraldo Zimbrão 1,4 1 Programa de Engenharia de Sistemas e Computação - Universidade Federal do Rio de Janeiro (UFRJ) Caixa Postal Rio de Janeiro Brasil 2 Departamento de Informática Aplicada Universidade Federal do Estado do Rio de Janeiro (UNIRIO) Rio de Janeiro Brasil 3 Faculdade de Administração e Finanças Universidade Estadual do Rio de Janeiro (UERJ) Rio de Janeiro Brasil. 4 Departamento 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.

2 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 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 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 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.

3 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.

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.

5 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.

6 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. GERENTE ANALISTA DE COMPONENTES ANALISTA DE APLICAÇÃO PROGRAMADORES E DESIGNER PROGRAMADORES E DESIGNER EQUIPE DE COMPONENTES 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

7 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.