Aplicação de padrões ao processo de desenvolvimento de software RUP Trabalho de Conclusão de Curso Engenharia da Computação Tiago Moraes de Miranda Farias Orientador: Prof. Márcio Lopes Cornélio Recife, 20 novembro de 2006
Aplicação de padrões ao processo de desenvolvimento de software RUP Trabalho de Conclusão de Curso Engenharia da Computação Este Projeto é apresentado como requisito parcial para obtenção do diploma de Bacharel em Engenharia da Computação pela Escola Politécnica de Pernambuco Universidade de Pernambuco. Tiago Moraes de Miranda Farias Orientador: Prof. Márcio Lopes Cornélio Recife, 20 de novembro de 2006
Tiago Moraes de Miranda Farias Aplicação de padrões ao processo de desenvolvimento de software RUP
i Resumo Processos de desenvolvimento de software e padrões são dois recursos utilizados para melhorar a qualidade dos softwares. Os processos de desenvolvimento de software organizam e controlam a produção de software, enquanto os padrões fornecem boas soluções para problemas encontrados em diversas atividades do desenvolvimento de software. A utilização combinada desses dois recursos pode ser uma importante ferramenta para fornecer qualidade na criação de softwares. Este trabalho apresenta um estudo do uso de padrões no processo de desenvolvimento de software do RUP. Através do estudo de padrões de projeto, padrões de análise e archetype patterns identificamos em que fases do RUP esses padrões podem ser utilizados e como podem contribuir com a qualidade dos produtos desenvolvidos. Utilizando alguns padrões como exemplos de modelos, este trabalho apresenta como é possível realizar a transição entre os modelos descritos utilizando os padrões estudados. Um modelo que descreve a solução de um problema utilizando archetype patterns, por exemplo, é descrito utilizando padrões de análise e padrões de projeto. Através deste trabalho espera-se facilitar a utilização de padrões em um processo de desenvolvimento de software. Saber que tipos de padrões podem ser úteis em determinadas fases do processo pode ajudar a antecipar a solução de alguns problemas através da utilização dos padrões.
ii Abstract Software development process and patterns are two features used to improve softwares quality. The software development processes organize and control software production whereas patterns provide good solutions to problems encountered in many activities of software development. The combined use of these two features can be an important instrument to provide quality in software creation. This work presents a study on the use of patterns with the RUP software development process. Through the study of design patterns, analysis patterns and archetype patterns we identified the phases in which these patterns can be used, and how they can contribute in the quality of developed products. Using some patterns as models examples, this work presents how it is possible to make a transition between models described using the studied patterns. A model that describes a problem solution using archetype patterns, for example, is described using analysis patterns and design patterns. This work it aims to facilitate the use of patterns in a software development process. By knowing which types of patterns can be useful in certain process phases we can help to anticipate the solution of some problems by using these patterns.
iii Sumário Índice de Figuras Tabela de Símbolos e Siglas v vii 1 Introdução 9 1.1 Objetivos e Metas 10 1.2 Visão Geral do Trabalho 10 2 O Rational Unified Process 11 2.1 Introdução 11 2.2 Boas práticas do desenvolvimento de software 13 2.2.1 Desenvolver software iterativamente 13 2.2.2 Gerenciar requisitos 14 2.2.3 Arquitetura baseada em componentes 14 2.2.4 Modelagem visual de software 15 2.2.5 Verificação contínua de qualidade 15 2.2.6 Controle de mudanças 16 2.3 Estrutura do Processo 16 2.3.1 Estrutura estática 17 2.3.2 Estrutura dinâmica 17 2.4 Resumo 19 3 Padrões 20 3.1 Introdução 20 3.1.1 O que são Padrões 21 3.1.2 Elementos Essenciais 21 3.2 Padrões de Projeto 22 3.2.1 Descrição de um Padrão de Projeto 22 3.2.2 Classificação dos Padrões de Projetos 23 3.3 Padrões de Análise 23 3.3.1 O que são modelos 23 3.3.2 O que são os padrões de análise 24 3.4 Archetype Patterns 24 3.4.1 O que é Archetype 24 3.4.2 Archetype Patterns e Padrões de Análise 26 3.4.3 Características dos Archetype Patterns 26 3.5 Resumo 26 4 Transitando entre Padrões 28 4.1 Introdução 28 4.2 Problema de representar quantidades 29 4.2.1 Solução: Padrões de Análise 29 4.2.2 Solução: Archetype Patterns 31 4.2.3 Solução: Padrões de Projeto 34
iv 4.3 Problema de representar pessoas e organizações 37 4.3.1 Solução: Padrões de Análise 38 4.3.2 Solução: Archetype Patterns 39 4.3.3 Solução: Padrões de Projeto 41 4.4 Resumo 42 5 Estudo de Caso 45 5.1 Introdução 45 5.1.1 O caso do Ponto de Venda 46 5.2 Adaptação do RUP 46 5.3 Aplicando os padrões às fases do RUP 47 5.4 Utilização de padrões no ponto de venda 50 5.5 Resumo 52 6 Conclusões e Trabalhos Futuros 54 6.1 Contribuições 54 6.2 Trabalhos Futuros 55
v Índice de Figuras Figura 1. Página Web do RUP disponibilizada como ferramenta. 12 Figura 2. Ciclo de vida do modelo cascata de desenvolvimento de software. 13 Figura 3. Modelo de desenvolvimento iterativo e incremental. 14 Figura 4. Gráfico do RUP estrutura organizada em duas dimensões. 16 Figura 5. Fases do processo iterativo e seus marcos. 18 Figura 6. Representação do padrão de análise Quantity. 29 Figura 7. Representação do padrão de análise Conversion Ratio. 30 Figura 8. Representação do padrão de análise CompoundUnit. 30 Figura 9. Solução de representação de quantidades utilizando padrões de análise. 31 Figura 10. Modelo que representa o quantity archetype pattern. 32 Figura 11. Modelo adaptado do quantity archetype pattern para se assemelhar ao 33 modelo do padrão de análise quantity. Figura 12. Modelo do quantity archetype pattern representado por classes no lugar 34 dos archetypes. Figura 13. Estrutura que representa o padrão de projeto Strategy. 35 Figura 14. Representação de uma possível aplicação do padrão de projeto Strategy 35 no modelo que descreve a solução do problema. Figura 15. Estrutura do padrão de projeto Abstract Factory. 36 Figura 16. Representação do conjunto de unidades, que poderia utilizar o padrão 36 Abstract Factory. Figura 17. Estrutura do padrão de projeto Composite. 37 Figura 18. Estrutura que define o relacionamento para descrever unidades 37 compostas no modelo. Figura 19. Representação do padrão de análise party. 38 Figura 20. Representação do padrão de análise organization hierarchies. 39 Figura 21. Solução de representação de pessoas e organizações utilizando padrões 39 de análise. Figura 22. Representação do party archetype pattern. 40 Figura 23. Adaptação do modelo do party achetype pattern para se assemelhar ao 41 modelo definido através de padrões de análise. Figura 24. Estrutura do padrão de projeto Iterator. 42 Figura 25. Seqüência de utilização dos três tipos de padrões de acordo com o nível 44 de abstração. Classes de Negócio Classes de Análise Classes de Projeto Figura 26. Ilustração de um sistema de ponto de venda. 46 Figura 27. Fluxo de trabalho da disciplina de modelagem de negócios. 48
vi Figura 28. Fluxo de trabalho da disciplina de análise e projeto. 49 Figura 29. Modelo de negócios parcial do ponto de venda definido por Larman 50 [19]. Figura 30. Modelo do Money Archetype Pattern. 51 Figura 31. Relações envolvendo pagamentos no modelo do ponto de venda. 52 Figura 32. Modelo que representa o product archetype pattern. 58 Figura 33. Modelo que representa o product analysis pattern. 59
vii Tabela de Símbolos e Siglas RUP Rational Unified Process XP Extreme Programming MSF Microsof Solutions Framework UML Unified Modeling Language SI Sistema Internacional de Unidades
viii Agradecimentos Gostaria de agradecer primeiramente a Deus que sempre me orientou e me mostrou os caminhos a seguir, que sempre me confortou nos momentos difíceis e ilumina a minha vida com muita paz e alegria. Agradeço a meu pai, José Carlos de Miranda Farias, meu melhor amigo, por continuar sempre me passando ensinamentos e compartilhando sua sabedoria. Agradeço a minha mãe, Nádia Luna Moraes Farias, meu porto seguro, sempre presente, cuidadosa, atenciosa e carinhosa. Agradeço a ela por ter insistido que eu fizesse o vestibular de Engenharia da Computação, pois senão não estaria agora completando mais essa jornada. Agradeço a meu irmão, Daniel Moraes de Miranda Farias, por ser mais que simplesmente irmão, ser sempre um companheiro, um amigo. Agradeço a Deus por ter me dado uma segunda mãe, Ivonete Vone Fernandes da Silva (in memorian), a quem sempre amarei e que estará comigo para o resto da vida. Agradeço a toda minha família que, sempre unida, me proporcionou uma base educacional e moral muito boa e que sempre está presente nos mais diversos momentos. Agradeço a todos os meus amigos e amigas, companheiros para a vida toda, irmãos que conheci na vida e que sempre me acompanham. Aos amigos de infância, que cresceram comigo e acompanham todas as etapas da minha vida. Aos amigos de faculdade, muitos novos amigos que estiveram a meu lado nessa jornada e que passaram a fazer parte da minha vida, em especial ao grupo AMIGOSPOLI e a diretoria do grupo, Diogo Pacheco, Filipe Regueira e Herbert Menezes, amigos sempre presentes entre estudos e festas. Agradeço Deus pela minha namorada, Mariana Pinheiro de Amorim, a quem conheci durante a faculdade e que desde então está sempre ao meu lado, que sempre me apóia e me dá amor e carinho. Agradeço à empresa WPD Tecnologia por ter acreditado em mim, por ter ajudado bastante na minha formação profissional e por sempre fornecer as condições necessárias para minha formação acadêmica, ajudando sempre que precisei. Agradeço a todos que fazem dessa empresa uma grande família, um ambiente agradável de se trabalhar mesmo nos momentos difíceis. A todos os amigos que tenho na empresa, que nunca se negaram a me ensinar o que sabiam e a me ajudar quando precisei. Agradeço a todos os professores do DSC que participaram da minha formação acadêmica, por fazerem com que eu tenha orgulho do curso que escolhi. Em especial ao professor Márcio Lopes Cornélio, meu orientador, por toda a sua dedicação e ajuda na concretização deste trabalho. Agradeço a Deus por todas essas pessoas e por todas aquelas que por ventura não foram citadas, mas que também contribuíram para que mais um passo da minha vida fosse dado. Apenas um passo, mas importante passo, na longa jornada que é a vida.
9 Capítulo 1 Introdução O desenvolvimento de softwares tem se tornado mais complexo ao longo dos anos. As exigências por parte dos clientes são cada vez maiores em termos de produtividade, qualidade de software e prazos cada vez menores [1]. O surgimento de novas tecnologias e a necessidade de realização de mudanças nos software desenvolvidos para atender às exigências dos clientes também dificulta a tarefa de desenvolver software com qualidade. Acompanhar as mudanças tecnológicas e atender às necessidades de mudança pode ser uma tarefa bastante complicada se o software não estiver preparado para suportar essas mudanças. Alguns estudos sugerem que pouco mais da metade do esforço utilizado para o desenvolvimento de software esteja voltado para atividades voltadas para assegurar a qualidade de software [2]. Dois dos recursos utilizados como forma de buscar o desenvolvimento de software com qualidade são a utilização de processos de desenvolvimento de software e a utilização de padrões. Entre os processo de desenvolvimento de software duas questões essenciais devem ser consideradas para assegurar a qualidade de software: o fornecimento de técnicas que auxiliem no desenvolvimento de software de qualidade e técnicas que assegurem os atributos de qualidade exigidos nos artefatos existentes [3]. A utilização de padrões durante o processo de desenvolvimento pode ser uma das técnicas utilizadas para assegurar qualidade nos documentos gerados. O Rational Unified Process (RUP) [4] é o processo de desenvolvimento de software mais utilizado na indústria de software atualmente [3]. Uma das características principais desse processo é a busca contínua pelo desenvolvimento de software com qualidade. Na descrição do seu processo, o RUP define um guia a ser seguido para o desenvolvimento de software. O RUP define, por exemplo, diversas atividades que devem ser realizadas e diversos documentos que devem ser gerados a fim de garantir a qualidade do software que está sendo desenvolvido. No entanto, um processo de desenvolvimento de software é apenas um guia e, como tal, pode ser adaptado para ser utilizado em diversas situações. Muitos dos documentos que são criados durante um processo de desenvolvimento de software são comuns a vários sistemas. Muitas vezes as mesmas técnicas são utilizadas para a criação desses documentos e, portanto, os mesmos problemas são encontrados. Os padrões apresentam uma forma de descrever soluções para esses problemas comuns baseado na experiência de outras pessoas. Existem diversos tipos de padrões e esses padrões podem ser utilizados para auxiliar na criação dos documentos gerados em um processo de desenvolvimento de software como o RUP.
10 Padrões de projeto [5], padrões de análise [6] e archetype patterns [7] são apenas alguns dos diversos tipos de padrões que existem e poderiam ser utilizados juntamente com o RUP para buscar o desenvolvimento de software com qualidade. 1.1 Objetivos e Metas O objetivo geral deste trabalho é apresentar o uso de padrões no processo de desenvolvimento de software do RUP. Diversos tipos de padrões podem ser utilizados em um processo de desenvolvimento de software para ajudar na criação de documentos e realização de tarefas. No entanto, muitas vezes, esses padrões não são utilizados por falta de conhecimento. Saber quando e como os diversos tipos de padrões podem ser utilizados, em um processo de desenvolvimento de software, pode ajudar a antecipar a consulta a determinados tipos de padrões durante o processo, auxiliando na tarefa de desenvolver software de qualidade. Este trabalho tem como objetivo utilizar três tipos de padrões e busca apresentar quando e como eles poderiam auxiliar no processo de desenvolvimento do RUP, além de apresentar em que fases do processo cada padrão mais se adequaria e poderia ser utilizado. O objetivo específico deste trabalho é apresentar como esses tipos de padrões podem ser utilizados em conjunto para ajudar na descrição de problemas. Como podemos realizar uma transição de um problema descrito utilizando um determinado tipo de padrão para uma descrição utilizando outro tipo de padrão. Um estudo de caso que utiliza o processo de desenvolvimento do RUP foi selecionado para apresentar como os padrões poderiam ajudar a resolver alguns problemas presentes. 1.2 Visão Geral do Trabalho Este trabalho está organizado em seis capítulos. No Capítulo 2 apresentamos o processo de desenvolvimento de software RUP. É nele apresentada uma introdução a respeito do processo, apresentamos as seis boas práticas de desenvolvimento de software nas quais o processo se baseia e a estrutura como o processo é organizado. No Capítulo 3 apresentamos padrões, o que são e quais os elementos essenciais de um padrão. Estudamos um pouco a respeito de três tipos de padrões: padrões de projeto, padrões de análise e archetype patterns. Apresentamos as definições, as características e as diferenças entre esses três tipos de padrões. No Capítulo 4 mostramos como os três tipos de padrões podem ser utilizados em conjunto para ajudar na resolução de problemas. Através de dois exemplos estudamos como cada tipo de padrão pode ser utilizado para descrever o mesmo problema e como podemos representar esse problema passando de um padrão para outro. No Capítulo 5 realizamos o mapeamento dos três tipos de padrões estudados para as fases do RUP. Apresentamos algumas disciplinas do RUP que se concentram na criação de artefatos em que os padrões poderiam ser utilizados para ajudar na criação de boas soluções. Verificamos as características desses artefatos criados e verificamos quais padrões mais se identificam com tais características. No Capítulo 6 apresentamos as conclusões obtidas através do desenvolvimento deste trabalho, as contribuições realizadas e são apresentadas propostas para trabalhos futuros.
11 Capítulo 2 O Rational Unified Process Desenvolver software com qualidade não é uma tarefa fácil desde o surgimento da indústria de software. A qualidade do software desenvolvido normalmente é avaliada em função de questões como a satisfação do cliente (principalmente ligadas a custo e prazo), a adequação aos requisitos funcionais (funcionalidades que espera-se que o sistema atenda), usabilidade, segurança, estabilidade, etc [3]. No começo os sistemas eram desenvolvidos como uma forma de arte, pois havia poucos métodos sistemáticos e poucas pessoas utilizavam os métodos existentes. O desenvolvimento era realizado de maneira ad-hoc 1 e o sucesso de um projeto estava vinculado à qualidade individual dos profissionais envolvidos. Com o tempo os sistemas desenvolvidos se tornaram cada vez mais complexos e tornou-se evidente a necessidade de utilização de técnicas e métodos sistemáticos para o desenvolvimento de software, o que levou ao surgimento da engenharia de software [8]. Os processos de desenvolvimento de software surgiram como parte da engenharia de software e ajudam a assegurar a qualidade no desenvolvimento de softwares. São funções de um processo de desenvolvimento de software servir como guia para a execução de atividades, definir que produtos serão desenvolvidos e quando, assegurar a qualidade e coordenar as mudanças necessárias, e auxiliar o acompanhamento do progresso do desenvolvimento do software. Atualmente existem diversos processos de desenvolvimento de software, entre os mais conhecidos estão: o Rational Unified Process (RUP) [4], o Microsof Solutions Framework (MSF) [9] e o Extreme Programming (XP) [10]. No entanto, o processo de desenvolvimento de software mais utilizado na indústria é o RUP [3], razão pela qual foi selecionado para o desenvolvimento deste projeto. Este capítulo apresenta uma introdução ao Rational Unified Process. Apresenta o que é o RUP, as principais questões referentes a este processo e a estrutura em que está organizado. 2.1 Introdução O Rational Unified Process (RUP) é um processo de desenvolvimento de software baseado no trabalho de Booch, Jacobson e Rumbaugh na definição do Unified Process (Processo Unificado) 1 A palavra ad-hoc tem origem latina e significa: destinado para esta finalidade. O termo ad-hoc geralmente significa algo desenvolvido para um problema específico e que não pode ser adaptado para outros propósitos.
12 [11]. O foco principal do RUP é garantir a produção de sistemas com qualidade de maneira padronizada e, até certo ponto, previsível [4]. Para atingir esse objetivo o RUP é construído sobre seis boas práticas de desenvolvimento de software, como será apresentado no decorrer deste capítulo. O RUP pode ser definido também como um produto ou um framework 2. O RUP possui diversas características comuns a produtos de software. Como os produtos de software o RUP foi projetado, desenvolvido, distribuído e recebe manutenção. Regularmente são disponibilizadas atualizações do processo. A descrição do processo, assim como exemplos de documentos utilizados ao longo do processo e outras informações são disponibilizadas através de um sistema Web (veja a Figura 1). Este sistema pode ser obtido através da internet ou CD-ROM e pode ser integrado com outras ferramentas de desenvolvimento de software. Figura 1. Página Web do RUP disponibilizada como ferramenta. O RUP é também um framework de processos de desenvolvimento de software. Empresas que não necessitem de toda a metodologia ou documentação utilizada no processo de desenvolvimento proposto pelo RUP podem adaptá-lo. É possível utilizar apenas um subconjunto do que é definido pelo RUP, um exemplo disso pode ser visto em [12], como também é possível estender o processo adicionando novos métodos, técnicas, documentos, etc. 2 Framework pode ser definido como uma estrutura definida para servir como uma base em que projetos de software podem utilizar para se organizar e facilitar o seu desenvolvimento.
2.2 Boas práticas do desenvolvimento de software ESCOLA POLITÉCNICA É grande o número de projetos de desenvolvimento de software que falham. Sistemas que não atendem às necessidades do usuário, mal documentados, softwares de baixa qualidade, difíceis de manter e integrar com outros sistemas, são alguns dos diversos problemas que ocasionam o fracasso de um projeto de desenvolvimento de software [1]. O RUP utiliza seis boas práticas de desenvolvimento de software para garantir o sucesso dos projetos que utilizem o processo. Essas boas práticas são abordagens comprovadas comercialmente que, quando combinadas, atacam a origem dos principais problemas que ocasionam o fracasso de um projeto de software, evitando que tais problemas ocorram ou antecipando-os de forma que o projeto possa ser reavaliado. As seis boas práticas adotadas pelo RUP são: desenvolver software iterativamente gerenciar requisitos utilizar arquiteturas baseadas em componentes modelar o software visualmente verificar a qualidade do software de forma contínua controlar as mudanças do software 2.2.1 Desenvolver software iterativamente O modelo de desenvolvimento clássico da engenharia de software é o modelo cascata, como apresentado na Figura 2. Neste modelo é realizada uma abordagem seqüencial do desenvolvimento de software iniciando na engenharia de sistemas e passando por todas as etapas até a entrega do produto [8]. Um grande problema deste modelo é o impacto de erros causados nas etapas iniciais e descobertos apenas próximo ao fim do projeto. 13 Figura 2. Ciclo de vida do modelo cascata de desenvolvimento de software.
14 O RUP utiliza um ciclo de vida iterativo e incremental como modelo de desenvolvimento. Nessa abordagem um conjunto de atividades em modelagem de negócios, requisitos, análise e projeto, implementação, testes e implantação são desenvolvidos de forma seqüencial a cada iteração, mas em diferentes proporções dependendo da fase projeto (veja Figura 3). Utilizando essa abordagem os riscos do projeto são identificados e tratados logo no início do ciclo de vida de desenvolvimento, pois a cada iteração uma pequena parte do produto será produzida e validada. Esse modelo possui diversas vantagens sobre o modelo clássico, pois os riscos são reduzidos mais cedo, os requisitos são validados à medida que são desenvolvidos, a melhoria e o refinamento do produto são facilitados e a capacidade de reutilização aumenta. Figura 3. Modelo de desenvolvimento iterativo e incremental. 2.2.2 Gerenciar requisitos O gerenciamento de requisitos é uma abordagem sistemática para localizar, documentar, organizar e controlar os requisitos variáveis do sistema. Requisitos são funções ou capacidades que o sistema deve atender [4]. A tarefa de gerenciar requisitos possui diversos aspectos que exigem atenção. Os requisitos do sistema devem ser definidos de maneira clara e fácil de entender, precisam ser o mais precisos possível e precisam ser validados pelos interessados no projeto. Alguns fatores complicadores para o gerenciamento de requisitos é o fato de diferentes interessados possuírem diferentes visões a respeito dos requisitos, os requisitos também se relacionam entre si e, inevitavelmente, alguns requisitos serão alterados no decorrer do projeto. O RUP recomenda a utilização de casos de uso como método de organização de requisitos funcionais. Casos de uso é uma técnica para capturar requisitos funcionais de um sistema. Os casos de uso descrevem as interações típicas entre os usuários do sistema e o sistema [13]. 2.2.3 Arquitetura baseada em componentes A arquitetura do software, possui um papel fundamental durante o seu desenvolvimento. É a partir da arquitetura que todos os envolvidos no desenvolvimento do projeto irão buscar o entendimento do que o software irá fazer, como irá funcionar e como estará organizado, por exemplo. A arquitetura de um software define a organização de um sistema de software ou estrutura de elementos que o compõem. Determina como esses elementos interagem entre si e como se
15 combinam em subsistemas para compor um sistema maior. A arquitetura não se limita a questões estruturais e de comportamento, mas também atua em questões como usabilidade, funcionalidade, desempenho, recuperabilidade, reusabilidade, constantes econômicas e tecnológicas e estética [4]. No RUP, o início do processo de desenvolvimento é focado na definição da arquitetura do sistema, como será visto mais adiante neste capítulo. O RUP aconselha o uso de arquitetura baseada em componentes. Componentes podem ser definidos como um módulo, um pacote ou um subsistema que desempenha uma função clara e que pode ser integrado em uma arquitetura bem definida [4]. Os componentes utilizados para definir a arquitetura podem ser desenvolvidos e testados separadamente, ou mesmo adquiridos prontos de terceiros e, depois, integrados. Alguns componentes são desenvolvidos para serem reutilizáveis, pois resolvem problemas comuns em determinadas situações. O RUP fornece diversos benefícios para o desenvolvimento de arquitetura baseado em componentes. Um desses benefícios é o fato de através do ciclo de desenvolvimento iterativo e incremental os componentes poderem ser desenvolvidos, testados e integrados de maneira incremental ao longo do projeto. 2.2.4 Modelagem visual de software Modelos são utilizados para descrever sistemas de uma forma particular e simplificada da realidade. Através de modelos podemos entender e visualizar de uma maneira mais simples e clara o que deve ser desenvolvido. A utilização de modelos em um processo de desenvolvimento de software é importante, pois permite que a equipe de desenvolvimento visualize, especifique, construa e documente a estrutura e o comportamento da arquitetura do sistema de software [4]. O RUP utiliza a UML (Unified Modeling Language) [13] como linguagem padrão para modelagem de forma a facilitar a comunicação entre a equipe de desenvolvimento. Através da utilização de modelos e de uma linguagem padrão como a UML para descrever esses modelos, a compreensão de sistemas complexos é facilitada, alternativas de projeto podem ser melhor exploradas e comparadas, é possível a formação de uma base para implementação, requisitos são capturados com maior precisão e a comunicação de decisões entre a equipe é realizada com menos ambigüidade [4]. 2.2.5 Verificação contínua de qualidade No RUP a responsabilidade pela qualidade é atribuída a todos os envolvidos no desenvolvimento do software. O foco em relação à qualidade é dividido em duas áreas: qualidade do produto e qualidade do processo. A qualidade do produto está ligada à qualidade do software desenvolvido, assim como seus componentes, arquitetura, etc. A qualidade do processo verifica o grau de efetividade do processo definido, incluindo métricas e critérios de qualidade adotados para o processo, e qualidade dos documentos criados para dar suporte ao desenvolvimento do software. O custo para identificação e correção de problemas no software é maior após a entrega do produto [4]. Para que possíveis problemas sejam identificados o mais cedo possível o RUP determina a verificação contínua de qualidade. A cada iteração o processo indica a realização de testes e avaliações de qualidade em diversos aspectos do software e do processo. Desta maneira é possível identificar os problemas cedo, reduzindo os custos de manutenção.
2.2.6 Controle de mudanças ESCOLA POLITÉCNICA Projetos de desenvolvimento de software geralmente envolvem diversas pessoas trabalhando juntas ou separadas, organizadas ou não em equipes, podendo estar até fisicamente separadas. Diversas atividades são realizadas e produtos são gerados e modificados com freqüência de uma forma que torna-se necessária a realização de algum tipo de controle. O RUP fornece uma maneira de coordenar as atividades desempenhadas e produtos gerados pelos desenvolvedores e equipes participantes do processo de desenvolvimento. O controle é realizado através do estabelecimento de fluxos de trabalho para gerenciamento de mudanças do software e dos documentos gerados durante o desenvolvimento do software. Em conjunto com o desenvolvimento iterativo, o gerenciamento de mudanças permite um maior monitoramento sobre as alterações realizadas. O controle de mudanças permite que mudanças de requisitos possuam um melhor monitoramento, facilita a organização e comunicação entre equipes trabalhando paralelamente e permite um maior controle sobre os produtos gerados no processo [4]. 16 2.3 Estrutura do Processo A estrutura do RUP é organizada em duas dimensões, como mostrado na Figura 4. O eixo vertical é a parte estática do processo, apresentando as principais disciplinas que compõem o processo. O eixo horizontal representa o tempo, o aspecto dinâmico do processo, e apresenta o aspecto do ciclo de vida do processo em termos de ciclos, fases, iterações e marcos. Figura 4. Gráfico do RUP estrutura organizada em duas dimensões.
2.3.1 Estrutura estática ESCOLA POLITÉCNICA A parte estática do RUP, representada pelo eixo vertical da Figura 4, é descrita através dos conceitos de papéis, atividades, artefatos e fluxos de trabalho apresentados a seguir. Papéis Um papel define o comportamento e as responsabilidades assumidas por uma pessoa ou um conjunto de pessoas trabalhando em equipe. Cada papel é responsável pela criação, modificação e controle de determinados artefatos que são gerados a partir da realização de certas atividades ligadas ao papel em questão [4]. Uma papel não representa uma pessoa. Uma pessoa pode assumir diferentes papéis em momentos diferentes, devendo realizar as atividades pertinentes ao papel e gerar os artefatos devidos. Atividades Uma atividade é um trabalho desempenhado por um indivíduo. O indivíduo que realiza a atividade deve assumir o papel responsável pela realização de tal atividade. As atividades estão diretamente ligadas a criação ou manutenção de artefatos e são executadas repetidas vezes em diferentes iterações [4]. Artefatos Um artefato é um pedaço de informação que é produzido, modificado e utilizado por um processo. Artefatos são utilizados como entrada para a realização de uma atividade e são resultados das saídas das atividades. Um artefato pode ser um documento, um modelo, um arquivo executável ou código-fonte, etc [4]. Fluxos de Trabalho Um fluxo de trabalho, ou disciplina, descreve uma seqüência de atividades e interações entre papéis de forma a produzir um conjunto de artefatos. Esses fluxos são descritos de forma a apresentar todos os papéis, atividades e artefatos envolvidos, mostrando como esses papéis interagem para produzir os artefatos em um nível mais detalhado [4]. O RUP possui nove fluxos de trabalho principais, apresentados no eixo vertical da Figura 4, representando grupos de papéis e atividades separados por áreas de interesse. Através da definição de um plano de iteração é possível escolher quais atividades serão realizadas a cada iteração de acordo com a necessidade. A descrição dos fluxos de trabalho pode ser realizada através da UML utilizando diagramas de seqüência, diagramas de colaboração ou diagramas de atividades [13]. 2.3.2 Estrutura dinâmica A estrutura dinâmica do RUP representa o desenvolvimento do processo no decorrer do tempo. O processo é caracterizado pelo desenvolvimento iterativo e por uma evolução incremental e com foco na redução dos riscos. O ciclo de vida de um projeto utilizando o RUP é dividido em uma sucessão de pequenos ciclos do modelo clássico, em cascata, chamado de modelo iterativo [4]. 17
18 Figura 5. Fases do processo iterativo e seus marcos. Em cada iteração o processo passa por todas as etapas do modelo clássico realizando as atividades para uma pequena parte do projeto. A cada nova iteração uma nova parte do projeto é desenvolvida e integrada ao que já foi realizado em iterações anteriores, evoluindo o projeto de maneira incremental. Como forma de acompanhar e monitorar o progresso do projeto no desenvolvimento iterativo e incremental são definidos pontos no tempo em que o andamento do projeto é avaliado. Esses pontos, chamados de marcos, definem se o desenvolvimento irá prosseguir ou não, ou se será necessário alguma mudança. Existem quatro marcos principais no RUP que dividem as iterações em quatro fases: iniciação, elaboração, construção e transição. Cada fase é finalizada quando um dos marcos principais é realizado, como mostrado na Figura 5 [4]. A cada iteração do processo iterativo incremental atividades como levantamento de requisitos, análise, projeto, implementação e testes são realizadas em um ciclo de vida em cascata. No entanto, em cada fase do processo a ênfase em cada atividade muda, como podemos observar no gráfico da Figura 4. Abaixo detalhamos um pouco mais as quatro fases do RUP. Iniciação A principal meta da fase de iniciação é a definição dos objetivos do ciclo de vida do projeto. Nesta fase é estabelecido o escopo do projeto a ser desenvolvido, critérios de aceitação e o que deve ou não deve estar no produto; são identificados os casos de uso críticos do sistema; uma sugestão de arquitetura básica é apresentada; estimativas de custos geral e programação para o projeto; estimativas de riscos; e o ambiente do projeto é preparado. O foco da fase de iniciação é concentrado nas atividades voltadas para modelagem de negócios, requisitos, gerência de projeto e ambiente. O marco para o final da fase é o marco dos objetivos do ciclo de vida, que avalia a viabilidade do projeto. Elaboração A principal meta da fase de elaboração é a definição de uma arquitetura estável para o sistema. A arquitetura definida deve ser estável o suficiente para diminuir os riscos do projeto e dar suporte à determinação dos custos e programação para a conclusão do desenvolvimento. Normalmente é desenvolvido um protótipo como forma de validar a arquitetura desenvolvida. A fase de elaboração é focada nos requisitos, análise e projeto, além das atividades de gerência de projetos e ambiente, mas já é realizada a implementação do protótipo da arquitetura. O marco para o final da fase é o marco da arquitetura do ciclo de vida que estabelece uma base para a arquitetura do sistema.
Construção ESCOLA POLITÉCNICA Na fase de construção os últimos requisitos são detalhados e é concluído o desenvolvimento do sistema. Nesta fase os objetivos são para minimizar os custos de desenvolvimento, otimizando recursos e evitando retrabalho desnecessários; atingir a qualidade adequada; concluir a análise, implementação e testes de todas as funcionalidade; disponibilizar um produto completo e decidir se está pronto para ser implantado. Na fase de construção as atividades de análise e implementação são o foco principal. O marco para o final da fase é o marco da capacidade operacional inicial, que determina se o produto está pronto para ser implantado. Transição A fase de transição deve assegurar que o software estará disponível para os usuários finais. Nesta fase os objetivos estão voltados para a realização de testes dos usuários, treinamentos, distribuição e vendas, engenharia voltada para implantação, atividades de ajustes, etc. Na fase de transição o foco é voltado para testes e gerência de configuração. O marco final desta fase é o marco de lançamento do produto. 19 2.4 Resumo Neste capítulo apresentamos a importância que um processo de desenvolvimento de software tem na busca de produção de softwares de qualidade. Apresentamos o RUP, processo de desenvolvimento de software mais utilizado pela indústria de software, e os benefícios que a adoção de um processo como o RUP proporciona. Explicamos o que é o RUP, quais os seus conceitos e como pode ser utilizado. Mostramos que o RUP pode ser visto não apenas como um processo, mas como um produto ou um framework de processos de desenvolvimento. Apresentamos seis boas práticas de desenvolvimento de software que ajudam a diminuir os riscos inerentes a projetos de software. Vimos como o RUP utiliza essas boas práticas em seu processo de desenvolvimento e os benefícios incorporados pela utilização delas. Por fim, estudamos como o RUP é estruturado e que características possui. Apresentamos as características estáticas e dinâmicas ligadas ao processo e como funciona essa estrutura no processo. Conhecemos diversos conceitos utilizados pelo RUP, as fases em que se divide o ciclo de desenvolvimento do software e a importância dos marcos.
20 Capítulo 3 Padrões As primeiras referências sobre o termo padrões surgiram em trabalhos desenvolvidos na área de arquitetura e engenharia civil por Christopher Alexander e alguns colegas. Através da publicação do livro A Patterns Language Towns, Buildings, Construction (Uma Linguagem de Padrões Cidades, Edificações, Construções) [14] Alexander e seus colegas descreveram técnicas de arquitetura e construções que resolviam problemas recorrentes em determinadas situações, o que chamaram de padrões. Segundo Alexander, os padrões descrevem problemas que ocorrem com determinada freqüência em determinadas situações e apresentam elementos principais para a solução do problema de forma que a solução possa ser aplicada diversas vezes para resolvê-lo, mesmo que em diferentes maneiras [14]. Após a publicação do trabalho de Alexander surgiram diversos outros trabalhos a respeito de padrões. No entanto, o trabalho que mais se destacou na área de sistemas de software foi o trabalho desenvolvido por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides [5] em que são descritos Padrões de Projeto. Este capítulo apresenta uma breve introdução a respeito de padrões e apresenta três tipos de padrões utilizados no desenvolvimento de softwares: Padrões de Projeto [5], Padrões de Análise [6] e Enterprise Patterns, conhecidos como Archetype Patterns [7]. 3.1 Introdução No desenvolver de uma atividade, muitas vezes nos deparamos com problemas que outras pessoas já resolveram, problemas que ocorrem com freqüência e que são, de certa forma, comuns. O tempo perdido para resolver esses problemas novamente poderia ser economizado através de alguma forma de consultar as soluções disponíveis para o problema. Além disso, o uso freqüente dessas soluções comuns para resolver tais problemas levaria a um amadurecimento das soluções aplicadas. Com a utilização de padrões, as soluções para esses problemas comuns são descritas de uma maneira que possam ser utilizadas de uma forma mais rápida por uma pessoa que utilize um padrão como um guia. Um padrão é apresentado como um guia, pois não descreve a solução final para os problemas, mas descreve um ponto de partida que pode ser ajustado para resolver um problema específico.
3.1.1 O que são Padrões ESCOLA POLITÉCNICA Desde o surgimento do termo através do trabalho de Alexander diversos autores publicaram seus trabalhos a respeito de padrões e em diferentes áreas. Apenas na área de software, por exemplo, foram propostos padrões para diversas fases do processo de desenvolvimento: padrões de requisitos, padrões de análise, padrões de arquitetura, archetype patterns, padrões de projeto, entre outros [15]. No trabalho desenvolvido por Gamma et al [5] foi apresentado o seguinte conceito sobre o que seriam padrões: Um padrão consiste de uma descrição de um problema, da contextualização do problema e de uma possível solução para o problema dentro deste contexto. Em seu trabalho os padrões são vistos como uma forma de distribuição de conhecimento, uma maneira de aumentar a reutilização de boas práticas e como uma forma de facilitar a comunicação sobre as soluções existentes. Um outro conceito apresentado para o que seriam padrões é o de Martin Fowler, no seu trabalho sobre padrões de análise: Um padrão é uma idéia que foi útil em um contexto prático e que provavelmente será útil em outros. Independentemente da área, de uma maneira geral, os conceitos de padrões se assemelham. De modo geral os padrões descrevem problemas e apresentam soluções já utilizadas e que funcionaram em determinadas situações. Descrevem de uma maneira que outras pessoas possam reutilizar as soluções ao se depararem com problemas iguais ou semelhantes, podendo adaptar a solução proposta para o problema específico que deseja resolver. 3.1.2 Elementos Essenciais Cada padrão definido no trabalho de Gamma et al [5] possui quatro elementos essenciais para identificá-los: O nome do padrão pode ser visto como um identificador para o padrão. É uma forma de descrever o problema, a solução e a conseqüência em poucas palavras. A utilização do nome do padrão facilita a comunicação entre pessoas que o utilizam, aumenta o nível de abstração que pode ser utilizado na hora de descrever a solução e discutir sobre o assunto, por isso é importante a escolha de um bom nome para o padrão proposto. O problema descreve quando o padrão deve ser aplicado. Descreve o contexto do problema que o padrão resolve propriamente. Um problema pode descrever também algumas condições que devem ser observadas antes da utilização do padrão. A solução descreve os elementos que compõem a solução assim como os seus relacionamentos e comportamentos. A solução não descreve uma solução concreta para o problema, pois ela representa apenas um modelo que pode ser aplicado em diferentes situações. 21
22 A conseqüência representa os efeitos e resultados da aplicação do padrão. Descreve vantagens e desvantagens e pode ser utilizada para avaliar o impacto causado pela utilização do padrão. 3.2 Padrões de Projeto Padrões de projeto são padrões que descrevem possíveis soluções a problemas comuns encontrados em projetos orientados a objetos [16]. A definição dada por Gamma et al [5] é de que padrões de projeto são descrições de objetos e classes que se relacionam e que são adaptados para resolver problemas de projeto em um dado contexto. Nos padrões são identificados as classes e objetos, como se relacionam, quais suas funções e quais as responsabilidades. Cada padrão de projeto busca resolver um problema específico em projetos orientados a objetos. 3.2.1 Descrição de um Padrão de Projeto Descrever um padrão de projeto é uma tarefa muito importante para facilitar o entendimento e a utilização dos padrões. Através da descrição de um padrão é possível identificar particularidades que facilitem a comparação entre os padrões, auxiliando na decisão de escolha por um padrão específico. Para descrever um padrão de projeto existe um modelo, definido por Gamma et al [5], em que o cada padrão é dividido em seções como apresentado a seguir: Nome do padrão e Classificação: um bom nome é muito importante para um padrão, pois deve indicar a essência do padrão em poucas palavras. A classificação do padrão é apresentada como definida na Seção 3.2.2 a seguir. Intenção do padrão: a intenção do padrão descreve o que o padrão faz, qual a sua intenção e qual problema o padrão se propõe a resolver. Também conhecido como: um outro nome pelo qual o padrão é conhecido, caso exista. Motivação: um exemplo de problema de projeto e como a utilização do padrão resolve este problema. Aplicabilidade: condições em que o padrão pode ser aplicado, exemplo de situação em que o padrão pode ser aplicado e como identificar essas situações. Estrutura: uma representação gráfica das classes no padrão utilizando uma linguagem de modelagem, UML [13] por exemplo, em que possam ser representados os relacionamentos entre os objetos e seqüências de requisições. Participantes: apresenta as classes e objetos que fazem parte do padrão e quais as suas responsabilidades. Colaborações: como os participantes colaboram para atender as suas responsabilidades. Conseqüências: descreve como um padrão alcança seus objetivos, quais as decisões e resultados de usar o padrão e que aspectos da estrutura do sistema podem ser variados independentemente.
Implementação: que detalhes de implementação devem ser observados o padrão for implementado. Deve ser observado se existem detalhes específicos a uma determinada linguagem. Exemplo de código: um exemplo de código que demonstre como o padrão deve ser implementado em alguma linguagem. Usos conhecidos: exemplos de padrões encontrados em sistemas reais. Padrões relacionados: apresenta padrões que se assemelham a este padrão e quais as diferenças. Apresenta também outros padrões que podem ser utilizados em conjunto. 3.2.2 Classificação dos Padrões de Projetos Devido ao grande número de padrões de projeto existentes, assim como para facilitar a busca por padrões e o seu entendimento, os padrões foram agrupados e organizados. Os padrões foram classificados, segundo Gamma et al [5], de forma que é possível separá-los em famílias de padrões. A classificação dos padrões é realizada segundo dois critérios: o propósito e o escopo. A classificação segundo o propósito agrupa os padrões de acordo com o que cada padrão faz. Nesta classificação os padrões são classificados como: padrões de criação, estruturais ou comportamentais. Ao classificar padrões segundo o escopo é especificado se o padrão se refere primariamente a classes ou objetos. Os padrões de criação se concentram no processo de criação de objetos e, de acordo com o escopo, se referem a criação de objetos para subclasses (escopo de classe) ou para outros objetos (escopo de objeto). Os padrões estruturais se preocupam com a composição das classes e dos objetos. Dependendo do escopo se utilizam de herança entre classes para realizar a composição (escopo de classe) ou apresentam formas de como agregar objetos (escopo de objeto). Os padrões comportamentais tratam a forma como classes e objetos interagem e distribuem responsabilidade. No nível de escopo de classe, os padrões comportamentais utilizam herança para descrever algoritmos e controle de fluxo, enquanto que no nível de escopo de objeto demonstram como um grupo de objetos pode ser utilizado para solucionar tarefas mais complexas. 3.3 Padrões de Análise Padrões de análise [6] são modelos de negócios de diferentes domínios. Estes modelos são definidos a partir da constatação de que a estrutura do negócio é uma estrutura comum, observada em determinados domínios. 3.3.1 O que são modelos No desenvolvimento orientados a objetos o software é projetado de uma maneira que reflita a estrutura do problema. Ao realizar a análise de um problema projetamos uma estrutura que represente o que acontece no problema. Quando o problema e seus conceitos não são claros e simples de entender uma alternativa que podemos usar é a criação de modelos para representar o problema. 23
24 Um modelo é criado a fim de facilitar o entendimento do problema. Podem ser criados diversos modelos diferentes para representar um mesmo problema, o que significa que não existe apenas um modelo correto, mas existe um modelo mais adequado a cada situação [6]. Na realização da análise de um sistema a escolha do modelo pode afetar flexibilidade e reusabilidade. A escolha de um modelo errado pode torná-lo difícil de ser alterado, por ser pouco flexível, ou pode impactar a sua reusabilidade por ser muito complexo. O ideal é que o modelo escolhido seja simples e efetivo. As técnicas de análise utilizadas para a criação dos modelos devem ser o mais independentes possível de tecnologias de software. Desta forma os modelos desenvolvidos podem ser úteis e aplicáveis a diferentes tecnologias. 3.3.2 O que são os padrões de análise Alguns problemas de análise são difíceis de observar fora do contexto de um grande projeto. Esses problemas exigem do desenvolvedor alguma experiência em modelagem para que o problema possa ser melhor compreendido. Os padrões fornecem uma boa maneira de analisar estes problemas. Segundo Martin Fowler [6], os padrões não são criados, mas descobertos, pois eles apenas se tornam padrões quando observa-se que eles possuem um uso comum. Baseado em suas experiências pessoais realizando modelagem de grandes sistemas de informação corporativos, Martin Fowler reuniu em seu trabalho uma série de padrões que descobriu analisando estes sistemas. Para esses padrões ele deu o nome de Padrões de Análise e fez a seguinte definição: Padrões de Análise são grupos de conceitos que representam uma construção comum na modelagem de negócios. Estes conceitos podem ser relevantes para apenas um domínio ou podem se estender a vários domínios. Portanto, os padrões de análise definidos por Fowler são modelos que representam aspectos de negócios observados por ele. Os padrões de análise podem ser utilizados como um ponto de partida para a criação de modelos de negócios. Podemos utilizá-los para validar decisões de negócio de uma forma mais clara, ou mesmo para revisar modelos que utilizamos. Segundo Fowler os padrões não têm que ser utilizados na íntegra, mas podem ser adaptados para atender às reais necessidades de quem os utiliza. 3.4 Archetype Patterns Archetype Patterns [7] são padrões que descrevem estruturas de negócios a partir da sua essência. Esses padrões de negócios são descritos em um nível de abstração maior que os padrões de análise, pois procuram representar os conceitos de uma forma mais geral. Utilizando archetype patterns é possível adaptar um conceito de negócio mantendo a essência que o identifica. 3.4.1 O que é Archetype A origem da palavra archetype (no português: arquétipo 3, modelo ou original) 4 vem da palavra grega archetypo, que significa padrão original e pode ser definida como segue: [7] 3 s.m. Filos. 1. Na filosofia platônica, modelo dos seres criados. 2. Modelo, padrão. Dicionário Michaelis
25 Um archetype é uma coisa ou circunstância primordial que ocorre periodicamente de forma consistente e é considerado como uma situação ou conceito universal. O psicologista Carl Gustav Jung [17] apresenta o conceito de archetypes partindo do conceito que ele chama de inconsciente coletivo. Segundo ele os archetypes surgem de um ponto comum das experiências humanas. Um exemplo que pode esclarecer melhor o conceito defendido por Jung é o exemplo do herói. O modelo de um herói americano se comparado a um modelo de herói aborígene australiano seriam bem diferentes. No entanto, o herói seria identificado nos dois casos apesar da variação existente entre os dois modelos, o que definiria o arquétipo do herói [7]. Podemos dizer então que um archetype define a essência de um modelo de maneira tal que mesmo ocorrendo variações podemos identificar o conceito principal representado. Assim sendo, podemos imaginar como pode ser útil este conceito se aplicado ao desenvolvimento software. Através da utilização de archetypes podemos modelar conceitos de negócios de maneira que possamos reutilizá-los em diversas situações, pois podemos adaptá-lo e manter o conceito principal definido. Na implementação de sistemas orientados a objetos buscamos modelar através de estruturas de classes e objetos os conceitos de negócios que desejamos representar. No entanto, em alguns desses conceitos podemos encontrar alguns archetypes. Por exemplo, se buscarmos modelar um sistema de compra de produtos, independente de como se realizará esta compra, podemos identificar conceitos principais que sempre farão parte do modelo como: produto, preço, comprador, vendedor, etc. Nesse contexto poderíamos identificar archetypes de negócios, assim como podemos identificar que entre esses conceitos também podem existir relacionamentos que sempre existirão. Esses archetypes e seus relacionamentos definem o que seriam os archetype patterns, que é definido da seguinte forma por Arlow e Neustadt [7] : Um archetype pattern de negócio é uma colaboração entre archetypes de negócios que ocorrem consistente e universalmente em ambientes de negócios e sistemas de softwares. Algumas características essenciais são definidas para archetypes e archetype patterns como apresentado abaixo: [7] Universal: para ser considerado um archetype, deve ocorrer de maneira consistente em domínios de negócios e sistemas. Difundido: deve ocorrer tanto no domínio de negócios quanto no domínio de sistemas de software. Na construção de sistemas orientados a objetos os archetype patterns devem se comportar da mesma forma que no domínio dos negócios. Possuir um Histórico: o archetype deve possuir uma história, de maneira que seja um conceito bem formado e conhecido. Evidente para especialistas: um bom indicador para determinar um archetype é o fato de o conceito ser evidente para os especialistas no seu domínio. Um archetype que não é evidente pode não representar um archetype. 4 Neste trabalho utilizaremos o termo archetype (em inglês) para facilitar o entendimento, pois não há uma tradução definida para o termo archetype patterns.