Download - Padroes de Projeto

Aplicao de padres ao processo de desenvolvimento de software

RUP

Trabalho de Concluso de Curso

Engenharia da Computao

Tiago Moraes de Miranda Farias Orientador: Prof. Mrcio Lopes Cornlio

Recife, 20 novembro de 2006

ESCOLA POLITCNICA

DE PERNAMBUCO

Este Projeto apresentado como requisito parcial para obteno do diploma de Bacharel em Engenharia da Computao pela Escola Politcnica de Pernambuco Universidade de Pernambuco.


RUP

Trabalho de Concluso de Curso

Engenharia da Computao

Tiago Moraes de Miranda Farias Orientador: Prof. Mrcio Lopes Cornlio

Recife, 20 de novembro de 2006

ESCOLA POLITCNICA

DE PERNAMBUCO

Tiago Moraes de Miranda Farias


RUP

i

ESCOLA POLITCNICA DE PERNAMBUCO

Resumo

Processos de desenvolvimento de software e padres so dois recursos utilizados para melhorar a qualidade dos softwares. Os processos de desenvolvimento de software organizam e controlam a produo de software, enquanto os padres fornecem boas solues para problemas encontrados em diversas atividades do desenvolvimento de software. A utilizao combinada desses dois recursos pode ser uma importante ferramenta para fornecer qualidade na criao de softwares.

Este trabalho apresenta um estudo do uso de padres no processo de desenvolvimento de software do RUP. Atravs do estudo de padres de projeto, padres de anlise e archetype patterns identificamos em que fases do RUP esses padres podem ser utilizados e como podem contribuir com a qualidade dos produtos desenvolvidos.

Utilizando alguns padres como exemplos de modelos, este trabalho apresenta como possvel realizar a transio entre os modelos descritos utilizando os padres estudados. Um modelo que descreve a soluo de um problema utilizando archetype patterns, por exemplo, descrito utilizando padres de anlise e padres de projeto.

Atravs deste trabalho espera-se facilitar a utilizao de padres em um processo de desenvolvimento de software. Saber que tipos de padres podem ser teis em determinadas fases do processo pode ajudar a antecipar a soluo de alguns problemas atravs da utilizao dos padres.

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


Sumrio

ndice de Figuras v

Tabela de Smbolos e Siglas vii

1 Introduo 9 1.1 Objetivos e Metas 10 1.2 Viso Geral do Trabalho 10

2 O Rational Unified Process 11 2.1 Introduo 11 2.2 Boas prticas 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 Verificao contnua de qualidade 15 2.2.6 Controle de mudanas 16

2.3 Estrutura do Processo 16 2.3.1 Estrutura esttica 17 2.3.2 Estrutura dinmica 17

2.4 Resumo 19

3 Padres 20 3.1 Introduo 20

3.1.1 O que so Padres 21 3.1.2 Elementos Essenciais 21

3.2 Padres de Projeto 22 3.2.1 Descrio de um Padro de Projeto 22 3.2.2 Classificao dos Padres de Projetos 23

3.3 Padres de Anlise 23 3.3.1 O que so modelos 23 3.3.2 O que so os padres de anlise 24

3.4 Archetype Patterns 24 3.4.1 O que Archetype 24 3.4.2 Archetype Patterns e Padres de Anlise 26 3.4.3 Caractersticas dos Archetype Patterns 26

3.5 Resumo 26

4 Transitando entre Padres 28 4.1 Introduo 28 4.2 Problema de representar quantidades 29

4.2.1 Soluo: Padres de Anlise 29 4.2.2 Soluo: Archetype Patterns 31 4.2.3 Soluo: Padres de Projeto 34

iv


4.3 Problema de representar pessoas e organizaes 37

4.3.1 Soluo: Padres de Anlise 38 4.3.2 Soluo: Archetype Patterns 39 4.3.3 Soluo: Padres de Projeto 41

4.4 Resumo 42

5 Estudo de Caso 45 5.1 Introduo 45

5.1.1 O caso do Ponto de Venda 46 5.2 Adaptao do RUP 46 5.3 Aplicando os padres s fases do RUP 47 5.4 Utilizao de padres no ponto de venda 50 5.5 Resumo 52

6 Concluses e Trabalhos Futuros 54 6.1 Contribuies 54 6.2 Trabalhos Futuros 55

v


ndice de Figuras

Figura 1. Pgina 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. Grfico do RUP estrutura organizada em duas dimenses. 16 Figura 5. Fases do processo iterativo e seus marcos. 18 Figura 6. Representao do padro de anlise Quantity. 29 Figura 7. Representao do padro de anlise Conversion Ratio. 30 Figura 8. Representao do padro de anlise CompoundUnit. 30 Figura 9. Soluo de representao de quantidades utilizando padres de anlise. 31 Figura 10. Modelo que representa o quantity archetype pattern. 32 Figura 11. Modelo adaptado do quantity archetype pattern para se assemelhar ao modelo do padro de anlise quantity.

33

Figura 12. Modelo do quantity archetype pattern representado por classes no lugar dos archetypes.

34

Figura 13. Estrutura que representa o padro de projeto Strategy. 35 Figura 14. Representao de uma possvel aplicao do padro de projeto Strategy no modelo que descreve a soluo do problema.

35

Figura 15. Estrutura do padro de projeto Abstract Factory. 36 Figura 16. Representao do conjunto de unidades, que poderia utilizar o padro Abstract Factory.

36

Figura 17. Estrutura do padro de projeto Composite. 37 Figura 18. Estrutura que define o relacionamento para descrever unidades compostas no modelo.

37

Figura 19. Representao do padro de anlise party. 38 Figura 20. Representao do padro de anlise organization hierarchies. 39 Figura 21. Soluo de representao de pessoas e organizaes utilizando padres de anlise.

39

Figura 22. Representao do party archetype pattern. 40 Figura 23. Adaptao do modelo do party achetype pattern para se assemelhar ao modelo definido atravs de padres de anlise.

41

Figura 24. Estrutura do padro de projeto Iterator. 42 Figura 25. Seqncia de utilizao dos trs tipos de padres de acordo com o nvel de abstrao. Classes de Negcio Classes de Anlise Classes de Projeto

44

Figura 26. Ilustrao de um sistema de ponto de venda. 46 Figura 27. Fluxo de trabalho da disciplina de modelagem de negcios. 48

vi


Figura 28. Fluxo de trabalho da disciplina de anlise e projeto. 49 Figura 29. Modelo de negcios parcial do ponto de venda definido por Larman [19].

50

Figura 30. Modelo do Money Archetype Pattern. 51 Figura 31. Relaes 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 Smbolos 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 difceis e ilumina a minha vida com muita paz e alegria. Agradeo a meu pai, Jos Carlos de Miranda Farias, meu melhor amigo, por continuar sempre me passando ensinamentos e compartilhando sua sabedoria. Agradeo a minha me, Ndia Luna Moraes Farias, meu porto seguro, sempre presente, cuidadosa, atenciosa e carinhosa. Agradeo a ela por ter insistido que eu fizesse o vestibular de Engenharia da Computao, pois seno no estaria agora completando mais essa jornada. Agradeo a meu irmo, Daniel Moraes de Miranda Farias, por ser mais que simplesmente irmo, ser sempre um companheiro, um amigo. Agradeo a Deus por ter me dado uma segunda me, Ivonete Vone Fernandes da Silva (in memorian), a quem sempre amarei e que estar comigo para o resto da vida. Agradeo a toda minha famlia que, sempre unida, me proporcionou uma base educacional e moral muito boa e que sempre est presente nos mais diversos momentos. Agradeo a todos os meus amigos e amigas, companheiros para a vida toda, irmos que conheci na vida e que sempre me acompanham. Aos amigos de infncia, 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. Agradeo Deus pela minha namorada, Mariana Pinheiro de Amorim, a quem conheci durante a faculdade e que desde ento est sempre ao meu lado, que sempre me apia e me d amor e carinho. Agradeo empresa WPD Tecnologia por ter acreditado em mim, por ter ajudado bastante na minha formao profissional e por sempre fornecer as condies necessrias para minha formao acadmica, ajudando sempre que precisei. Agradeo a todos que fazem dessa empresa uma grande famlia, um ambiente agradvel de se trabalhar mesmo nos momentos difceis. A todos os amigos que tenho na empresa, que nunca se negaram a me ensinar o que sabiam e a me ajudar quando precisei. Agradeo a todos os professores do DSC que participaram da minha formao acadmica, por fazerem com que eu tenha orgulho do curso que escolhi. Em especial ao professor Mrcio Lopes Cornlio, meu orientador, por toda a sua dedicao e ajuda na concretizao deste trabalho. Agradeo a Deus por todas essas pessoas e por todas aquelas que por ventura no foram citadas, mas que tambm contriburam para que mais um passo da minha vida fosse dado. Apenas um passo, mas importante passo, na longa jornada que a vida.

9


1

Introduo

O desenvolvimento de softwares tem se tornado mais complexo ao longo dos anos. As exigncias por parte dos clientes so 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 realizao de mudanas nos software desenvolvidos para atender s exigncias dos clientes tambm dificulta a tarefa de desenvolver software com qualidade. Acompanhar as mudanas tecnolgicas e atender s necessidades de mudana pode ser uma tarefa bastante complicada se o software no estiver preparado para suportar essas mudanas. Alguns estudos sugerem que pouco mais da metade do esforo 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 so a utilizao de processos de desenvolvimento de software e a utilizao de padres. Entre os processo de desenvolvimento de software duas questes essenciais devem ser consideradas para assegurar a qualidade de software: o fornecimento de tcnicas que auxiliem no desenvolvimento de software de qualidade e tcnicas que assegurem os atributos de qualidade exigidos nos artefatos existentes [3]. A utilizao de padres durante o processo de desenvolvimento pode ser uma das tcnicas utilizadas para assegurar qualidade nos documentos gerados. O Rational Unified Process (RUP) [4] o processo de desenvolvimento de software mais utilizado na indstria de software atualmente [3]. Uma das caractersticas principais desse processo a busca contnua pelo desenvolvimento de software com qualidade. Na descrio 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 situaes. Muitos dos documentos que so criados durante um processo de desenvolvimento de software so comuns a vrios sistemas. Muitas vezes as mesmas tcnicas so utilizadas para a criao desses documentos e, portanto, os mesmos problemas so encontrados. Os padres apresentam uma forma de descrever solues para esses problemas comuns baseado na experincia de outras pessoas. Existem diversos tipos de padres e esses padres podem ser utilizados para auxiliar na criao dos documentos gerados em um processo de desenvolvimento de software como o RUP.

Captulo

10


Padres de projeto [5], padres de anlise [6] e archetype patterns [7] so apenas alguns dos diversos tipos de padres 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 padres no processo de desenvolvimento de software do RUP. Diversos tipos de padres podem ser utilizados em um processo de desenvolvimento de software para ajudar na criao de documentos e realizao de tarefas. No entanto, muitas vezes, esses padres no so utilizados por falta de conhecimento. Saber quando e como os diversos tipos de padres podem ser utilizados, em um processo de desenvolvimento de software, pode ajudar a antecipar a consulta a determinados tipos de padres durante o processo, auxiliando na tarefa de desenvolver software de qualidade. Este trabalho tem como objetivo utilizar trs tipos de padres e busca apresentar quando e como eles poderiam auxiliar no processo de desenvolvimento do RUP, alm de apresentar em que fases do processo cada padro mais se adequaria e poderia ser utilizado. O objetivo especfico deste trabalho apresentar como esses tipos de padres podem ser utilizados em conjunto para ajudar na descrio de problemas. Como podemos realizar uma transio de um problema descrito utilizando um determinado tipo de padro para uma descrio utilizando outro tipo de padro. Um estudo de caso que utiliza o processo de desenvolvimento do RUP foi selecionado para apresentar como os padres poderiam ajudar a resolver alguns problemas presentes.

1.2 Viso Geral do Trabalho Este trabalho est organizado em seis captulos. No Captulo 2 apresentamos o processo de desenvolvimento de software RUP. nele apresentada uma introduo a respeito do processo, apresentamos as seis boas prticas de desenvolvimento de software nas quais o processo se baseia e a estrutura como o processo organizado. No Captulo 3 apresentamos padres, o que so e quais os elementos essenciais de um padro. Estudamos um pouco a respeito de trs tipos de padres: padres de projeto, padres de anlise e archetype patterns. Apresentamos as definies, as caractersticas e as diferenas entre esses trs tipos de padres. No Captulo 4 mostramos como os trs tipos de padres podem ser utilizados em conjunto para ajudar na resoluo de problemas. Atravs de dois exemplos estudamos como cada tipo de padro pode ser utilizado para descrever o mesmo problema e como podemos representar esse problema passando de um padro para outro. No Captulo 5 realizamos o mapeamento dos trs tipos de padres estudados para as fases do RUP. Apresentamos algumas disciplinas do RUP que se concentram na criao de artefatos em que os padres poderiam ser utilizados para ajudar na criao de boas solues. Verificamos as caractersticas desses artefatos criados e verificamos quais padres mais se identificam com tais caractersticas. No Captulo 6 apresentamos as concluses obtidas atravs do desenvolvimento deste trabalho, as contribuies realizadas e so apresentadas propostas para trabalhos futuros.

11


2

O Rational Unified Process

Desenvolver software com qualidade no uma tarefa fcil desde o surgimento da indstria de software. A qualidade do software desenvolvido normalmente avaliada em funo de questes como a satisfao do cliente (principalmente ligadas a custo e prazo), a adequao aos requisitos funcionais (funcionalidades que espera-se que o sistema atenda), usabilidade, segurana, estabilidade, etc [3].

No comeo os sistemas eram desenvolvidos como uma forma de arte, pois havia poucos mtodos sistemticos e poucas pessoas utilizavam os mtodos existentes. O desenvolvimento era realizado de maneira ad-hoc1 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 utilizao de tcnicas e mtodos sistemticos 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. So funes de um processo de desenvolvimento de software servir como guia para a execuo de atividades, definir que produtos sero desenvolvidos e quando, assegurar a qualidade e coordenar as mudanas necessrias, e auxiliar o acompanhamento do progresso do desenvolvimento do software. Atualmente existem diversos processos de desenvolvimento de software, entre os mais conhecidos esto: 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 indstria o RUP [3], razo pela qual foi selecionado para o desenvolvimento deste projeto. Este captulo apresenta uma introduo ao Rational Unified Process. Apresenta o que o RUP, as principais questes referentes a este processo e a estrutura em que est organizado.

2.1 Introduo O Rational Unified Process (RUP) um processo de desenvolvimento de software baseado no trabalho de Booch, Jacobson e Rumbaugh na definio 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 especfico e que no pode ser adaptado para

outros propsitos.

Captulo

12


[11]. O foco principal do RUP garantir a produo de sistemas com qualidade de maneira padronizada e, at certo ponto, previsvel [4]. Para atingir esse objetivo o RUP construdo sobre seis boas prticas de desenvolvimento de software, como ser apresentado no decorrer deste captulo. O RUP pode ser definido tambm como um produto ou um framework2. O RUP possui diversas caractersticas comuns a produtos de software. Como os produtos de software o RUP foi projetado, desenvolvido, distribudo e recebe manuteno. Regularmente so disponibilizadas atualizaes do processo. A descrio do processo, assim como exemplos de documentos utilizados ao longo do processo e outras informaes so disponibilizadas atravs de um sistema Web (veja a Figura 1). Este sistema pode ser obtido atravs da internet ou CD-ROM e pode ser integrado com outras ferramentas de desenvolvimento de software.

Figura 1. Pgina Web do RUP disponibilizada como ferramenta.

O RUP tambm um framework de processos de desenvolvimento de software. Empresas que no necessitem de toda a metodologia ou documentao utilizada no processo de desenvolvimento proposto pelo RUP podem adapt-lo. possvel utilizar apenas um subconjunto do que definido pelo RUP, um exemplo disso pode ser visto em [12], como tambm possvel estender o processo adicionando novos mtodos, tcnicas, 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.

13


2.2 Boas prticas do desenvolvimento de software grande o nmero de projetos de desenvolvimento de software que falham. Sistemas que no atendem s necessidades do usurio, mal documentados, softwares de baixa qualidade, difceis de manter e integrar com outros sistemas, so alguns dos diversos problemas que ocasionam o fracasso de um projeto de desenvolvimento de software [1]. O RUP utiliza seis boas prticas de desenvolvimento de software para garantir o sucesso dos projetos que utilizem o processo. Essas boas prticas so 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 prticas adotadas pelo RUP so:

desenvolver software iterativamente gerenciar requisitos utilizar arquiteturas baseadas em componentes modelar o software visualmente verificar a qualidade do software de forma contnua controlar as mudanas do software

2.2.1 Desenvolver software iterativamente

O modelo de desenvolvimento clssico da engenharia de software o modelo cascata, como apresentado na Figura 2. Neste modelo realizada uma abordagem seqencial 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 prximo ao fim do projeto.

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 negcios, requisitos, anlise e projeto, implementao, testes e implantao so desenvolvidos de forma seqencial a cada iterao, mas em diferentes propores dependendo da fase projeto (veja Figura 3). Utilizando essa abordagem os riscos do projeto so identificados e tratados logo no incio do ciclo de vida de desenvolvimento, pois a cada iterao uma pequena parte do produto ser produzida e validada. Esse modelo possui diversas vantagens sobre o modelo clssico, pois os riscos so reduzidos mais cedo, os requisitos so validados medida que so desenvolvidos, a melhoria e o refinamento do produto so facilitados e a capacidade de reutilizao aumenta.

Figura 3. Modelo de desenvolvimento iterativo e incremental.

2.2.2 Gerenciar requisitos

O gerenciamento de requisitos uma abordagem sistemtica para localizar, documentar, organizar e controlar os requisitos variveis do sistema. Requisitos so funes ou capacidades que o sistema deve atender [4]. A tarefa de gerenciar requisitos possui diversos aspectos que exigem ateno. Os requisitos do sistema devem ser definidos de maneira clara e fcil de entender, precisam ser o mais precisos possvel e precisam ser validados pelos interessados no projeto. Alguns fatores complicadores para o gerenciamento de requisitos o fato de diferentes interessados possurem diferentes vises a respeito dos requisitos, os requisitos tambm se relacionam entre si e, inevitavelmente, alguns requisitos sero alterados no decorrer do projeto. O RUP recomenda a utilizao de casos de uso como mtodo de organizao de requisitos funcionais. Casos de uso uma tcnica para capturar requisitos funcionais de um sistema. Os casos de uso descrevem as interaes tpicas entre os usurios 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 iro 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 organizao de um sistema de software ou estrutura de elementos que o compem. Determina como esses elementos interagem entre si e como se

15


combinam em subsistemas para compor um sistema maior. A arquitetura no se limita a questes estruturais e de comportamento, mas tambm atua em questes como usabilidade, funcionalidade, desempenho, recuperabilidade, reusabilidade, constantes econmicas e tecnolgicas e esttica [4]. No RUP, o incio do processo de desenvolvimento focado na definio da arquitetura do sistema, como ser visto mais adiante neste captulo. O RUP aconselha o uso de arquitetura baseada em componentes. Componentes podem ser definidos como um mdulo, um pacote ou um subsistema que desempenha uma funo 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 so desenvolvidos para serem reutilizveis, pois resolvem problemas comuns em determinadas situaes. O RUP fornece diversos benefcios para o desenvolvimento de arquitetura baseado em componentes. Um desses benefcios o fato de atravs 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 so utilizados para descrever sistemas de uma forma particular e simplificada da realidade. Atravs de modelos podemos entender e visualizar de uma maneira mais simples e clara o que deve ser desenvolvido. A utilizao 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 padro para modelagem de forma a facilitar a comunicao entre a equipe de desenvolvimento. Atravs da utilizao de modelos e de uma linguagem padro como a UML para descrever esses modelos, a compreenso de sistemas complexos facilitada, alternativas de projeto podem ser melhor exploradas e comparadas, possvel a formao de uma base para implementao, requisitos so capturados com maior preciso e a comunicao de decises entre a equipe realizada com menos ambigidade [4].

2.2.5 Verificao contnua de qualidade

No RUP a responsabilidade pela qualidade atribuda a todos os envolvidos no desenvolvimento do software. O foco em relao 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 mtricas e critrios de qualidade adotados para o processo, e qualidade dos documentos criados para dar suporte ao desenvolvimento do software. O custo para identificao e correo de problemas no software maior aps a entrega do produto [4]. Para que possveis problemas sejam identificados o mais cedo possvel o RUP determina a verificao contnua de qualidade. A cada iterao o processo indica a realizao de testes e avaliaes de qualidade em diversos aspectos do software e do processo. Desta maneira possvel identificar os problemas cedo, reduzindo os custos de manuteno.

16


2.2.6 Controle de mudanas

Projetos de desenvolvimento de software geralmente envolvem diversas pessoas trabalhando juntas ou separadas, organizadas ou no em equipes, podendo estar at fisicamente separadas. Diversas atividades so realizadas e produtos so gerados e modificados com freqncia de uma forma que torna-se necessria a realizao 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 atravs do estabelecimento de fluxos de trabalho para gerenciamento de mudanas do software e dos documentos gerados durante o desenvolvimento do software. Em conjunto com o desenvolvimento iterativo, o gerenciamento de mudanas permite um maior monitoramento sobre as alteraes realizadas. O controle de mudanas permite que mudanas de requisitos possuam um melhor monitoramento, facilita a organizao e comunicao entre equipes trabalhando paralelamente e permite um maior controle sobre os produtos gerados no processo [4].

2.3 Estrutura do Processo A estrutura do RUP organizada em duas dimenses, como mostrado na Figura 4. O eixo vertical a parte esttica do processo, apresentando as principais disciplinas que compem o processo. O eixo horizontal representa o tempo, o aspecto dinmico do processo, e apresenta o aspecto do ciclo de vida do processo em termos de ciclos, fases, iteraes e marcos.

Figura 4. Grfico do RUP estrutura organizada em duas dimenses.

17


2.3.1 Estrutura esttica

A parte esttica do RUP, representada pelo eixo vertical da Figura 4, descrita atravs dos conceitos de papis, atividades, artefatos e fluxos de trabalho apresentados a seguir.

Papis

Um papel define o comportamento e as responsabilidades assumidas por uma pessoa ou um conjunto de pessoas trabalhando em equipe. Cada papel responsvel pela criao, modificao e controle de determinados artefatos que so gerados a partir da realizao de certas atividades ligadas ao papel em questo [4]. Uma papel no representa uma pessoa. Uma pessoa pode assumir diferentes papis em momentos diferentes, devendo realizar as atividades pertinentes ao papel e gerar os artefatos devidos.

Atividades

Uma atividade um trabalho desempenhado por um indivduo. O indivduo que realiza a atividade deve assumir o papel responsvel pela realizao de tal atividade. As atividades esto diretamente ligadas a criao ou manuteno de artefatos e so executadas repetidas vezes em diferentes iteraes [4].

Artefatos

Um artefato um pedao de informao que produzido, modificado e utilizado por um processo. Artefatos so utilizados como entrada para a realizao de uma atividade e so resultados das sadas das atividades. Um artefato pode ser um documento, um modelo, um arquivo executvel ou cdigo-fonte, etc [4].

Fluxos de Trabalho

Um fluxo de trabalho, ou disciplina, descreve uma seqncia de atividades e interaes entre papis de forma a produzir um conjunto de artefatos. Esses fluxos so descritos de forma a apresentar todos os papis, atividades e artefatos envolvidos, mostrando como esses papis interagem para produzir os artefatos em um nvel mais detalhado [4]. O RUP possui nove fluxos de trabalho principais, apresentados no eixo vertical da Figura 4, representando grupos de papis e atividades separados por reas de interesse. Atravs da definio de um plano de iterao possvel escolher quais atividades sero realizadas a cada iterao de acordo com a necessidade. A descrio dos fluxos de trabalho pode ser realizada atravs da UML utilizando diagramas de seqncia, diagramas de colaborao ou diagramas de atividades [13].

2.3.2 Estrutura dinmica

A estrutura dinmica do RUP representa o desenvolvimento do processo no decorrer do tempo. O processo caracterizado pelo desenvolvimento iterativo e por uma evoluo incremental e com foco na reduo dos riscos. O ciclo de vida de um projeto utilizando o RUP dividido em uma sucesso de pequenos ciclos do modelo clssico, em cascata, chamado de modelo iterativo [4].

18


Figura 5. Fases do processo iterativo e seus marcos.

Em cada iterao o processo passa por todas as etapas do modelo clssico realizando as

atividades para uma pequena parte do projeto. A cada nova iterao uma nova parte do projeto desenvolvida e integrada ao que j foi realizado em iteraes anteriores, evoluindo o projeto de maneira incremental.

Como forma de acompanhar e monitorar o progresso do projeto no desenvolvimento iterativo e incremental so definidos pontos no tempo em que o andamento do projeto avaliado. Esses pontos, chamados de marcos, definem se o desenvolvimento ir prosseguir ou no, ou se ser necessrio alguma mudana. Existem quatro marcos principais no RUP que dividem as iteraes em quatro fases: iniciao, elaborao, construo e transio. Cada fase finalizada quando um dos marcos principais realizado, como mostrado na Figura 5 [4]. A cada iterao do processo iterativo incremental atividades como levantamento de requisitos, anlise, projeto, implementao e testes so 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 grfico da Figura 4. Abaixo detalhamos um pouco mais as quatro fases do RUP.

Iniciao

A principal meta da fase de iniciao a definio dos objetivos do ciclo de vida do projeto. Nesta fase estabelecido o escopo do projeto a ser desenvolvido, critrios de aceitao e o que deve ou no deve estar no produto; so identificados os casos de uso crticos do sistema; uma sugesto de arquitetura bsica apresentada; estimativas de custos geral e programao para o projeto; estimativas de riscos; e o ambiente do projeto preparado. O foco da fase de iniciao concentrado nas atividades voltadas para modelagem de negcios, requisitos, gerncia 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.

Elaborao

A principal meta da fase de elaborao a definio de uma arquitetura estvel para o sistema. A arquitetura definida deve ser estvel o suficiente para diminuir os riscos do projeto e dar suporte determinao dos custos e programao para a concluso do desenvolvimento. Normalmente desenvolvido um prottipo como forma de validar a arquitetura desenvolvida. A fase de elaborao focada nos requisitos, anlise e projeto, alm das atividades de gerncia de projetos e ambiente, mas j realizada a implementao do prottipo 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.

19


Construo

Na fase de construo os ltimos requisitos so detalhados e concludo o desenvolvimento do sistema. Nesta fase os objetivos so para minimizar os custos de desenvolvimento, otimizando recursos e evitando retrabalho desnecessrios; atingir a qualidade adequada; concluir a anlise, implementao e testes de todas as funcionalidade; disponibilizar um produto completo e decidir se est pronto para ser implantado. Na fase de construo as atividades de anlise e implementao so 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.

Transio

A fase de transio deve assegurar que o software estar disponvel para os usurios finais. Nesta fase os objetivos esto voltados para a realizao de testes dos usurios, treinamentos, distribuio e vendas, engenharia voltada para implantao, atividades de ajustes, etc. Na fase de transio o foco voltado para testes e gerncia de configurao. O marco final desta fase o marco de lanamento do produto.

2.4 Resumo Neste captulo apresentamos a importncia que um processo de desenvolvimento de software tem na busca de produo de softwares de qualidade. Apresentamos o RUP, processo de desenvolvimento de software mais utilizado pela indstria de software, e os benefcios que a adoo 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 no apenas como um processo, mas como um produto ou um framework de processos de desenvolvimento. Apresentamos seis boas prticas de desenvolvimento de software que ajudam a diminuir os riscos inerentes a projetos de software. Vimos como o RUP utiliza essas boas prticas em seu processo de desenvolvimento e os benefcios incorporados pela utilizao delas. Por fim, estudamos como o RUP estruturado e que caractersticas possui. Apresentamos as caractersticas estticas e dinmicas 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 importncia dos marcos.

20


3

Padres

As primeiras referncias sobre o termo padres surgiram em trabalhos desenvolvidos na rea de arquitetura e engenharia civil por Christopher Alexander e alguns colegas. Atravs da publicao do livro A Patterns Language Towns, Buildings, Construction (Uma Linguagem de Padres Cidades, Edificaes, Construes) [14] Alexander e seus colegas descreveram tcnicas de arquitetura e construes que resolviam problemas recorrentes em determinadas situaes, o que chamaram de padres.

Segundo Alexander, os padres descrevem problemas que ocorrem com determinada freqncia em determinadas situaes e apresentam elementos principais para a soluo do problema de forma que a soluo possa ser aplicada diversas vezes para resolv-lo, mesmo que em diferentes maneiras [14].

Aps a publicao do trabalho de Alexander surgiram diversos outros trabalhos a respeito de padres. 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 so descritos Padres de Projeto.

Este captulo apresenta uma breve introduo a respeito de padres e apresenta trs tipos de padres utilizados no desenvolvimento de softwares: Padres de Projeto [5], Padres de Anlise [6] e Enterprise Patterns, conhecidos como Archetype Patterns [7].

3.1 Introduo No desenvolver de uma atividade, muitas vezes nos deparamos com problemas que outras pessoas j resolveram, problemas que ocorrem com freqncia e que so, de certa forma, comuns. O tempo perdido para resolver esses problemas novamente poderia ser economizado atravs de alguma forma de consultar as solues disponveis para o problema. Alm disso, o uso freqente dessas solues comuns para resolver tais problemas levaria a um amadurecimento das solues aplicadas.

Com a utilizao de padres, as solues para esses problemas comuns so descritas de uma maneira que possam ser utilizadas de uma forma mais rpida por uma pessoa que utilize um padro como um guia. Um padro apresentado como um guia, pois no descreve a soluo final para os problemas, mas descreve um ponto de partida que pode ser ajustado para resolver um problema especfico.

Captulo

21


3.1.1 O que so Padres

Desde o surgimento do termo atravs do trabalho de Alexander diversos autores publicaram seus trabalhos a respeito de padres e em diferentes reas. Apenas na rea de software, por exemplo, foram propostos padres para diversas fases do processo de desenvolvimento: padres de requisitos, padres de anlise, padres de arquitetura, archetype patterns, padres de projeto, entre outros [15]. No trabalho desenvolvido por Gamma et al [5] foi apresentado o seguinte conceito sobre o que seriam padres: Um padro consiste de uma descrio de um problema, da contextualizao do problema e de uma possvel soluo para o problema dentro deste contexto. Em seu trabalho os padres so vistos como uma forma de distribuio de conhecimento, uma maneira de aumentar a reutilizao de boas prticas e como uma forma de facilitar a comunicao sobre as solues existentes. Um outro conceito apresentado para o que seriam padres o de Martin Fowler, no seu trabalho sobre padres de anlise: Um padro uma idia que foi til em um contexto prtico e que provavelmente ser til em outros. Independentemente da rea, de uma maneira geral, os conceitos de padres se assemelham. De modo geral os padres descrevem problemas e apresentam solues j utilizadas e que funcionaram em determinadas situaes. Descrevem de uma maneira que outras pessoas possam reutilizar as solues ao se depararem com problemas iguais ou semelhantes, podendo adaptar a soluo proposta para o problema especfico que deseja resolver.

3.1.2 Elementos Essenciais

Cada padro definido no trabalho de Gamma et al [5] possui quatro elementos essenciais para identific-los:

O nome do padro pode ser visto como um identificador para o padro. uma forma de descrever o problema, a soluo e a conseqncia em poucas palavras. A utilizao do nome do padro facilita a comunicao entre pessoas que o utilizam, aumenta o nvel de abstrao que pode ser utilizado na hora de descrever a soluo e discutir sobre o assunto, por isso importante a escolha de um bom nome para o padro proposto.

O problema descreve quando o padro deve ser aplicado. Descreve o contexto do

problema que o padro resolve propriamente. Um problema pode descrever tambm algumas condies que devem ser observadas antes da utilizao do padro.

A soluo descreve os elementos que compem a soluo assim como os seus

relacionamentos e comportamentos. A soluo no descreve uma soluo concreta para o problema, pois ela representa apenas um modelo que pode ser aplicado em diferentes situaes.

22


A conseqncia representa os efeitos e resultados da aplicao do padro. Descreve vantagens e desvantagens e pode ser utilizada para avaliar o impacto causado pela utilizao do padro.

3.2 Padres de Projeto Padres de projeto so padres que descrevem possveis solues a problemas comuns encontrados em projetos orientados a objetos [16]. A definio dada por Gamma et al [5] de que padres de projeto so descries de objetos e classes que se relacionam e que so adaptados para resolver problemas de projeto em um dado contexto. Nos padres so identificados as classes e objetos, como se relacionam, quais suas funes e quais as responsabilidades. Cada padro de projeto busca resolver um problema especfico em projetos orientados a objetos.

3.2.1 Descrio de um Padro de Projeto

Descrever um padro de projeto uma tarefa muito importante para facilitar o entendimento e a utilizao dos padres. Atravs da descrio de um padro possvel identificar particularidades que facilitem a comparao entre os padres, auxiliando na deciso de escolha por um padro especfico. Para descrever um padro de projeto existe um modelo, definido por Gamma et al [5], em que o cada padro dividido em sees como apresentado a seguir:

Nome do padro e Classificao: um bom nome muito importante para um padro, pois deve indicar a essncia do padro em poucas palavras. A classificao do padro apresentada como definida na Seo 3.2.2 a seguir.

Inteno do padro: a inteno do padro descreve o que o padro faz, qual a sua

inteno e qual problema o padro se prope a resolver.

Tambm conhecido como: um outro nome pelo qual o padro conhecido, caso exista.

Motivao: um exemplo de problema de projeto e como a utilizao do padro resolve este problema.

Aplicabilidade: condies em que o padro pode ser aplicado, exemplo de situao em

que o padro pode ser aplicado e como identificar essas situaes.

Estrutura: uma representao grfica das classes no padro utilizando uma linguagem de modelagem, UML [13] por exemplo, em que possam ser representados os relacionamentos entre os objetos e seqncias de requisies.

Participantes: apresenta as classes e objetos que fazem parte do padro e quais as suas

responsabilidades.

Colaboraes: como os participantes colaboram para atender as suas responsabilidades.

Conseqncias: descreve como um padro alcana seus objetivos, quais as decises e resultados de usar o padro e que aspectos da estrutura do sistema podem ser variados independentemente.

23


Implementao: que detalhes de implementao devem ser observados o padro for

implementado. Deve ser observado se existem detalhes especficos a uma determinada linguagem.

Exemplo de cdigo: um exemplo de cdigo que demonstre como o padro deve ser

implementado em alguma linguagem.

Usos conhecidos: exemplos de padres encontrados em sistemas reais.

Padres relacionados: apresenta padres que se assemelham a este padro e quais as diferenas. Apresenta tambm outros padres que podem ser utilizados em conjunto.

3.2.2 Classificao dos Padres de Projetos

Devido ao grande nmero de padres de projeto existentes, assim como para facilitar a busca por padres e o seu entendimento, os padres foram agrupados e organizados. Os padres foram classificados, segundo Gamma et al [5], de forma que possvel separ-los em famlias de padres. A classificao dos padres realizada segundo dois critrios: o propsito e o escopo. A classificao segundo o propsito agrupa os padres de acordo com o que cada padro faz. Nesta classificao os padres so classificados como: padres de criao, estruturais ou comportamentais. Ao classificar padres segundo o escopo especificado se o padro se refere primariamente a classes ou objetos. Os padres de criao se concentram no processo de criao de objetos e, de acordo com o escopo, se referem a criao de objetos para subclasses (escopo de classe) ou para outros objetos (escopo de objeto). Os padres estruturais se preocupam com a composio das classes e dos objetos. Dependendo do escopo se utilizam de herana entre classes para realizar a composio (escopo de classe) ou apresentam formas de como agregar objetos (escopo de objeto). Os padres comportamentais tratam a forma como classes e objetos interagem e distribuem responsabilidade. No nvel de escopo de classe, os padres comportamentais utilizam herana para descrever algoritmos e controle de fluxo, enquanto que no nvel de escopo de objeto demonstram como um grupo de objetos pode ser utilizado para solucionar tarefas mais complexas.

3.3 Padres de Anlise Padres de anlise [6] so modelos de negcios de diferentes domnios. Estes modelos so definidos a partir da constatao de que a estrutura do negcio uma estrutura comum, observada em determinados domnios.

3.3.1 O que so modelos

No desenvolvimento orientados a objetos o software projetado de uma maneira que reflita a estrutura do problema. Ao realizar a anlise de um problema projetamos uma estrutura que represente o que acontece no problema. Quando o problema e seus conceitos no so claros e simples de entender uma alternativa que podemos usar a criao de modelos para representar o problema.

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 no existe apenas um modelo correto, mas existe um modelo mais adequado a cada situao [6]. Na realizao da anlise de um sistema a escolha do modelo pode afetar flexibilidade e reusabilidade. A escolha de um modelo errado pode torn-lo difcil de ser alterado, por ser pouco flexvel, ou pode impactar a sua reusabilidade por ser muito complexo. O ideal que o modelo escolhido seja simples e efetivo.

As tcnicas de anlise utilizadas para a criao dos modelos devem ser o mais independentes possvel de tecnologias de software. Desta forma os modelos desenvolvidos podem ser teis e aplicveis a diferentes tecnologias.

3.3.2 O que so os padres de anlise

Alguns problemas de anlise so difceis de observar fora do contexto de um grande projeto. Esses problemas exigem do desenvolvedor alguma experincia em modelagem para que o problema possa ser melhor compreendido. Os padres fornecem uma boa maneira de analisar estes problemas. Segundo Martin Fowler [6], os padres no so criados, mas descobertos, pois eles apenas se tornam padres quando observa-se que eles possuem um uso comum. Baseado em suas experincias pessoais realizando modelagem de grandes sistemas de informao corporativos, Martin Fowler reuniu em seu trabalho uma srie de padres que descobriu analisando estes sistemas. Para esses padres ele deu o nome de Padres de Anlise e fez a seguinte definio: Padres de Anlise so grupos de conceitos que representam uma construo comum na modelagem de negcios. Estes conceitos podem ser relevantes para apenas um domnio ou podem se estender a vrios domnios. Portanto, os padres de anlise definidos por Fowler so modelos que representam aspectos de negcios observados por ele. Os padres de anlise podem ser utilizados como um ponto de partida para a criao de modelos de negcios. Podemos utiliz-los para validar decises de negcio de uma forma mais clara, ou mesmo para revisar modelos que utilizamos. Segundo Fowler os padres no tm 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] so padres que descrevem estruturas de negcios a partir da sua essncia. Esses padres de negcios so descritos em um nvel de abstrao maior que os padres de anlise, pois procuram representar os conceitos de uma forma mais geral. Utilizando archetype patterns possvel adaptar um conceito de negcio mantendo a essncia que o identifica.

3.4.1 O que Archetype

A origem da palavra archetype (no portugus: arqutipo3, modelo ou original)4 vem da palavra grega archetypo, que significa padro original e pode ser definida como segue: [7]

3 s.m. Filos. 1. Na filosofia platnica, modelo dos seres criados. 2. Modelo, padro. Dicionrio Michaelis

25


Um archetype uma coisa ou circunstncia primordial que ocorre periodicamente de forma consistente e considerado como uma situao 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 experincias humanas. Um exemplo que pode esclarecer melhor o conceito defendido por Jung o exemplo do heri. O modelo de um heri americano se comparado a um modelo de heri aborgene australiano seriam bem diferentes. No entanto, o heri seria identificado nos dois casos apesar da variao existente entre os dois modelos, o que definiria o arqutipo do heri [7]. Podemos dizer ento que um archetype define a essncia de um modelo de maneira tal que mesmo ocorrendo variaes podemos identificar o conceito principal representado. Assim sendo, podemos imaginar como pode ser til este conceito se aplicado ao desenvolvimento software. Atravs da utilizao de archetypes podemos modelar conceitos de negcios de maneira que possamos reutiliz-los em diversas situaes, pois podemos adapt-lo e manter o conceito principal definido. Na implementao de sistemas orientados a objetos buscamos modelar atravs de estruturas de classes e objetos os conceitos de negcios 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 faro parte do modelo como: produto, preo, comprador, vendedor, etc. Nesse contexto poderamos identificar archetypes de negcios, assim como podemos identificar que entre esses conceitos tambm podem existir relacionamentos que sempre existiro. 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 negcio uma colaborao entre archetypes de negcios que ocorrem consistente e universalmente em ambientes de negcios e sistemas de softwares. Algumas caractersticas essenciais so definidas para archetypes e archetype patterns como apresentado abaixo: [7]

Universal: para ser considerado um archetype, deve ocorrer de maneira consistente em domnios de negcios e sistemas.

Difundido: deve ocorrer tanto no domnio de negcios quanto no domnio de sistemas de

software. Na construo de sistemas orientados a objetos os archetype patterns devem se comportar da mesma forma que no domnio dos negcios.

Possuir um Histrico: o archetype deve possuir uma histria, 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 domnio. Um archetype que no evidente pode no representar um archetype.

4 Neste trabalho utilizaremos o termo archetype (em ingls) para facilitar o entendimento, pois no h uma

traduo definida para o termo archetype patterns.

26


3.4.2 Archetype Patterns e Padres de Anlise

Archetype Patterns e Padres de anlise, apesar de modelarem aspectos no nvel de negcios, no so a mesma coisa. Archetypes buscam reconhecer e identificar conceitos universais, enquanto que classes de anlise no se preocupam com o conceito de universalidade. Archetypes esto sempre em um nvel de abstrao mais alto que as classes de anlise [7].

Classes de anlise mapeiam conceitos de negcios reais, representam uma abstrao no domnio do problema. O objetivo das classes de anlise de facilitar a compreenso do negcio. Outro tipo de classes, as classes de projeto, so utilizadas para representar a soluo em um nvel mais tcnico junto com a compreenso do negcio, como nos padres de projeto. Os archetypes apresentam um nvel de abstrao maior que esses dois tipos de classes.

3.4.3 Caractersticas dos Archetype Patterns

Uma das principais caractersticas de um archetype pattern a sua capacidade de variao. Como os archetypes representam a essncia dos conceitos que modelam possvel adapt-los para modelar o mesmo conceito de maneiras diferentes. Esta caracterstica atende ao que chamado de princpio da variao, que diz que domnios de negcios diferentes geralmente necessitam de diferentes modelos para representar o mesmo conceito [7]. Existem trs tipos diferentes de variao suportadas pelos archetype patterns que possibilitam a sua capacidade de adaptao, so elas:

Variao de archetype: um archetype pode possuir diferentes recursos (atributos, operaes, constantes) para ser eficiente em diferentes contextos.

Variao de archetype pattern: alguns recursos so opcionais no padro, de maneira que

podem ser omitidos se forem desnecessrios para o domnio em questo.

Pleomorphism: um tipo especial de variao de archetype patterns, neste caso o padro pode assumir diferentes estruturas (diferentes archetypes, recursos dos archetypes e relacionamentos) para se adaptar s necessidades de um contexto de negcio.

3.5 Resumo Neste captulo estudamos o conceito de padres. O uso de padres surgiu na rea de arquitetura e engenharia civil, mas que logo despertou interesse de diversas outras reas. Vimos que a utilizao de padres na rea de desenvolvimento de software vem crescendo bastante e em diversas fases do processo de desenvolvimento. Apresentamos os conceito de padres e conhecemos seus quatro elementos essenciais: nome, problema, soluo e conseqncia. Aprendemos como um padro importante para a distribuio de conhecimento. Estudamos o conceito de padres de projeto, aprendemos como possvel descrever solues para problemas de projetos orientados a objetos utilizando padres de projeto. Aprendemos tambm como classificar os padres de projeto. Estudamos tambm os padres de anlise. Aprendemos o que so modelos conceituais e como so importantes na realizao de anlise de negcios. Conhecemos a origem dos padres de anlise e sua definio.

27


Por fim, estudamos os archetype patterns. Aprendemos o que um archetype, como os archetype patterns descrevem os problemas a partir da sua essncia. Conhecemos as caractersticas principais dos archetype patterns e verificamos as formas que podem ser utilizadas para adaptar os archetype patterns sem perder a essncia do conceito que ele define, um recurso importante para a reusabilidade deste tipo de padro.

28


4

Transitando entre Padres

Como vimos no captulo anterior os padres buscam apresentar boas solues para problemas que normalmente ocorrem em determinadas situaes. Cada padro descreve uma soluo para um problema em uma situao e cada tipo de padro apresenta as solues para os problemas em um nvel de abstrao. No entanto, nada impede que tipos diferentes de padres apresentem solues para um mesmo problema. Um certo tipo de padro pode apresentar um problema e descrever uma possvel soluo para este problema a partir de um determinado nvel de abstrao. Para esse mesmo problema podemos identificar que um outro tipo de padro apresenta uma soluo semelhante, mas utilizando um outro nvel de abstrao, apresentando uma nova viso para o problema em questo. Podemos ainda encontrar uma forma de implementar a soluo para este problema utilizando-se um terceiro tipo de padres.

No captulo anterior discutimos trs tipos de padres: Archetype Patterns, Padres de Anlise e Padres de Projeto. Neste captulo buscaremos mostrar, atravs de um exemplo, como diferentes tipos de padres podem descrever o mesmo problema, mas com vises e nveis de abstrao diferentes, e como podemos utiliz-los.

4.1 Introduo Os diversos tipos de padres existentes normalmente so organizados em catlogos como uma forma de organizar os problemas j documentados que cada tipo de padro se propes a resolver. No trabalho desenvolvido por Gamma et al [5], por exemplo, foi criado um catlogo com os 23 padres de projeto descritos. Archetype Patterns [7] e Padres de Anlise [6] tambm foram organizados em catlogos de forma semelhante.

Os padres de projeto descritos no catlogo definido por Gamma et al [5] buscam descrever solues para problemas encontrados em projetos orientados a objetos, como j foi apresentado no captulo anterior. Padres de anlise e archetype patterns, no entanto, agrupam padres que descrevem solues em um nvel mais elevado, solues no nvel de regras de negcio.

Por tratarem de problemas em um nvel mais prximo, ao analisarmos os catlogos de padres de anlise e archetype patterns podemos identificar padres que descrevem os mesmos problemas, ou semelhantes. Alguns deles compartilham inclusive do mesmo nome para referenciar o padro como: Party, Inventory, Product, Quantity, etc. Apesar de tratar de um nvel

Captulo

29


de abstrao diferente dos demais, a soluo apresentada para esses padres pode ser implementada com o auxlio de padres de projeto.

Um bom exemplo para descrever como esses tipos de padres podem descrever um mesmo problema atravs dos padres Quantity e Party, presentes nos catlogos de padres de anlise e archetype patterns. A seguir apresentaremos como esses padres so, ou podem ser, descritos em cada um dos trs tipos de padres apresentados. Dessa forma estaremos apresentando que, apesar de abordarem diferentes nveis de abstrao, diferentes tipos de padres podem ser combinados para ajudar a resolver um problema em comum.

4.2 Problema de representar quantidades Em diversas situaes e em diversos tipos de sistemas nos deparamos com a manipulao de valores. Em um sistema mdico informaes dos pacientes, como altura e peso, informaes monetrias em um sistema financeiro, informaes de estoque em sistemas de gerenciamento de estoque e diversos outros tipos de informaes so manipuladas freqentemente.

Esses valores geralmente representam uma determinada quantidade e esto associados a alguma unidade de medida. A altura de um paciente pode ser medida em centmetros ou metros, o dinheiro pode ser contado em reais ou dlares, um item de um estoque pode ser guardado em unidades ou caixas. Dependendo do sistema desenvolvido a maneira como essas informaes so representadas e armazenadas pode ser bastante significativa.

Em sistemas orientados a objetos as quantidades podem ser representadas de diversas formas. Uma quantidade pode ser representada como um atributo de um objeto ou como um objeto associado por exemplo. No entanto, a forma como as quantidades sero representadas podem impactar diretamente no sistema medida que preciso considerar questes como converter valores de uma unidade de medida para outra por exemplo.

A seguir apresentaremos como podemos utilizar padres de anlise, archetype patterns e padres de projeto para descrever uma possvel forma para representar quantidades. Nos padres de anlise e archetype patterns existem padres especficos que descrevem uma possvel soluo do problema, entretanto, tambm podemos aplicar padres de projeto na descrio dessa soluo.

4.2.1 Soluo: Padres de Anlise

No catlogo de padres de anlise definido por Fowler [6] existe o padro quantity, em que definido um novo tipo associando um valor a uma unidade para representar uma quantidade de algo, como mostrado na Figura 6. A idia substituir a utilizao de um atributo por um novo tipo (objeto) que represente a quantidade. Esse objeto pode conter operaes que podem ser aplicadas ao valor armazenado.

Figura 6. Representao do padro de anlise Quantity.

30


No entanto, apenas atravs da substituio de um atributo que represente a quantidade por um novo objeto que associa um valor a uma unidade no resolvemos os problemas envolvidos na representao de quantidades. Problemas como converso entre unidades no estariam bem tratados atravs desta representao. No catlogo de padres de anlise existem outros dois padres definidos que podem ser associados para resolver o problema de converso de unidades, so eles: Conversion Ratio (Figura 7) e Compound Units (Figura 8). O padro Conversion Ratio representa como podem ser realizadas converses dos valores entre unidades. Para isto existe uma relao entre uma unidade e uma taxa de converso, associada a um nmero, que define a qual ser a taxa utilizada para realizar a converso entre duas unidades. Entretanto, no se deve esquecer que existem unidades compostas, como m2 (metro quadrado) por exemplo. Atravs do padro Compound Units pode-se representar tais unidades realizando uma distino entre unidades atmicas e unidades compostas, que utilizam unidades de referncia, associadas a um valor inteiro, para compor unidades.

Figura 7. Representao do padro de anlise Conversion Ratio.

Figura 8. Representao do padro de anlise CompoundUnit.

31


Ao combinar esses trs padres definidos no catlogo de padres de anlise, colocando a classe de unidades como ponto central entre os trs padres, apresentamos o que seria uma boa soluo para representar quantidades em um sistema orientado a objetos no nvel dos padres de anlise, como apresentado na Figura 9.

Figura 9. Soluo de representao de quantidades utilizando padres de anlise.

4.2.2 Soluo: Archetype Patterns

No catlogo de archetype patterns, apresentado por Arlow e Neustadt [7], o quantity archetype pattern apresentado como uma extenso do padro de anlise quantity descrito por Martin Fowler em [6]. O modelo apresentado na Figura 10 apresenta a descrio da soluo indicada pelo catlogo para a soluo do problema de representar quantidades.

32


Figura 10. Modelo que representa o quantity archetype pattern.

No modelo podemos identificar alguns archetypes novos que no aparecem de maneira semelhante no modelo de padres de anlise apresentado anteriormente. O archetype Metric, por exemplo, representa padres de medida, sendo uma unidade um tipo de mtrica, como podemos ver atravs do archetype Unit. O archetype SystemOfUnits representa um conjunto de unidades definidos, como o conjunto definido pelo Sistema Internacional de Unidades (SI) [18]. Os archetypes RoundingPolicy e RoundingStrategy tambm merecem ateno. Esses archetypes definem polticas e estratgias de arredondamento de valores utilizados durante a manipulao desses valores. Os archetypes que herdam de Unit representam alguns subtipos, entre eles as unidades bsicas definidas no conjunto padro de unidades do SI.

33


No entanto, como vimos anteriormente, uma das principais caractersticas dos archetype patterns a sua capacidade de adaptao atravs de variao. Atravs dessa caracterstica podemos utilizar apenas o que desejarmos do archetype pattern definido para aplicarmos ao problema em que estamos tentando resolver. Atravs da variao podemos selecionar os archetypes que achamos relevantes para o nosso problema e eliminar o que acharmos desnecessrio. sempre bom lembrar que um padro deve ser utilizado apenas como um guia, ou um ponto de partida, para ajudar a resolver determinados problemas. Para visualizarmos melhor como o quantity archetype pattern pode apresentar uma descrio para um mesmo problema que um padro de anlise vamos adaptar o modelo proposto. Utilizando a caracterstica de variao eliminamos alguns archetypes presentes no modelo de maneira a tornar mais prximo o modelo do quantity archetype pattern ao modelo do padro de anlise quantity, como podemos visualizar na Figura 11. Comparando o modelo da Figura 11 com o modelo que foi apresentado na Figura 9 podemos identificar similaridades. O relacionamento entre os archetypes Unit, StandardConversion e UnitConverter, que representa o como seria tratada a questo de converso de unidades, bastante similar ao relacionamento entre as classes de anlise Unit, ConversionRatio e Number no modelo de padres de anlise.

Figura 11. Modelo adaptado do quantity archetype pattern para se assemelhar ao modelo do

padro de anlise quantity.

34


4.2.3 Soluo: Padres de Projeto

Apesar de descrever padres em um outro nvel de abstrao em relao aos padres de anlise e archetype patterns os padres de projeto podem, e se possvel devem, tambm ser utilizados para ajudar a resolver os problemas. Como j apresentamos no Captulo 3, os padres de projeto descrevem solues tanto a nvel de classes quanto a nvel de objetos, descrevem solues em relao criao de objetos, estruturao e comportamento dessas classes e objetos. O modelo do quantity archetype pattern, em sua estrutura, j utiliza alguns padres de projeto. Se considerarmos os archetypes definidos no modelo da Figura 10 como classes, como apresentado na Figura 12, podemos identificar que alguns padres de projeto foram, ou poderiam ter sido, utilizados para a criao do modelo.

Figura 12. Modelo do quantity archetype pattern representado por classes no lugar dos

archetypes. O primeiro padro de projeto que poderia ser identificado seria o padro Singleton. Esse padro de projeto faz com que para a classe que o implementa exista apenas uma nica instncia, de maneira que todos os objetos acessem esta mesma instncia da classe de forma global. A

35


classe SystemOfUnits representa um conjunto de unidades definidas por um determinado padro, como o SI. Portanto, esse conjunto de unidades nico e deve ser assim representado no sistema, fazendo com que a classe SystemOfUnits seja implementada com o padro de projeto Singleton. A classe Metric tambm pode ser implementada com esse padro de projeto, pois representa um padro de medida nico. Um outro padro de projeto que podemos identificar no modelo o padro Strategy. Uma das situaes em que esse padro de projeto pode ser utilizado quando uma classe define muitos comportamentos e esses comportamentos apresentam muitas condies. Atravs desse padro de projeto esses comportamentos podem ser agrupados em classes que sero responsveis pela implementao desses comportamentos. A estrutura de como esse padro implementado, conforme definido em [5], pode ser visto na Figura 13. A classe RoundingPolicy determina como deve se comportar a operao de arredondamento de valores da classe quantidade. A classe RoundingStrategy representa um aspecto da classe RoundingPolicy que determina o tipo de arredondamento que deve ser utilizado. Utilizando o padro de projeto Strategy poderamos representar as estratgias de arredondamento como na Figura 14.

Figura 13. Estrutura que representa o padro de projeto Strategy.

Figura 14. Representao de uma possvel aplicao do padro de projeto Strategy no modelo

que descreve a soluo do problema. Podemos tambm destacar o padro de projeto Abstract Factory. Esse padro permite que sejam criadas famlias de objetos relacionados revelando apenas a interface desses objetos e sem revelar suas implementaes. Esse padro pode ser utilizado para fornecer um conjunto de unidades revelando apenas uma interface comum e deixando a implementao concreta de cada

36


unidade como responsabilidade da classe concreta de cada unidade. A estrutura desse padro definida em [5] como apresentado na Figura 15 e poderia ser aplicado no modelo para implementar a questo das unidades como na Figura 16.

Figura 15. Estrutura do padro de projeto Abstract Factory.

Figura 16. Representao do conjunto de unidades, que poderia utilizar o padro Abstract

Factory.

37


Por fim, um outro padro de projeto que podemos identificar no modelo seria o padro Composite. O padro de projeto Composite permite que objetos individuais e composies de objetos sejam tratados de uma forma uniforme. A forma como esse padro de projeto pode ser implementado apresentado na Figura 17 (retirada de [5]). Em nosso modelo, a classe DerivedUnit representa uma combinao entre uma ou mais unidades e a classe DerivedUnitTerm representa uma parte de DerivedUnit composta de uma unidade e uma potncia. Para que o sistema manipule unidades de maneira uniforme ele deve ser capaz de manipular tanto unidades simples como unidades compostas, considerando-as apenas como unidades em si. A aplicao do padro composite no relacionamento dessas classes, apresentado na Figura 18, permite que as classes sejam manipuladas dessa forma.

Figura 17. Estrutura do padro de projeto Composite.

Figura 18. Estrutura que define o relacionamento para descrever unidades compostas no modelo.

4.3 Problema de representar pessoas e organizaes Um outro problema que os padres de anlise, archetype patterns e padres de projeto podem ajudar a resolver em conjunto o problema de representar e armazenar informaes sobre pessoas e organizaes em sistemas.

38


Em diversos tipos de sistemas, em diversos tipos de negcios, armazenar informaes sobre clientes, fornecedores ou parceiros essencial. Mesmo em uma simples agenda pessoal temos armazenadas informaes como telefones, endereos ou e-mails de diversas pessoas, ou mesmo de empresas. A forma como essas informaes so armazenadas importante para um sistema. A maneira como essas informaes so armazenadas podem impactar em problemas de redundncia de informaes, qualidade de informaes e at questes estratgicas como qualidade de servio ou questes legais por no obter acesso a informaes necessrias. O padro Party, tanto nos padres de anlise quando nos archetype patterns, busca descrever uma boa maneira de representar informaes essenciais de pessoas e organizaes de uma maneira generalizada, tratando pessoas e organizaes como partes. Os modelos apresentados, tanto em padres de anlise quanto em archetype patterns, abordam a questo na representao dos seus modelos questes no nvel de negcios, como contabilidade envolvendo organizaes e pessoas e responsabilidades entre partes. No entanto, para simplificar o exemplo apresentado, iremos focar apenas na questo da representao de organizaes e pessoas de uma maneira geral.

4.3.1 Soluo: Padres de Anlise

Para representar organizaes e pessoas de uma forma geral e associar as informaes de uma maneira centralizada o catlogo de padres de anlise fornece o padro party, como mostrado na Figura 19. Neste padro, pessoas e organizaes so considerados como partes, de maneira que as informaes estariam associadas s partes e no diretamente a uma pessoa ou organizao.

Figura 19. Representao do padro de anlise party.

No entanto, em uma grande organizao podemos ter diversos setores ou divises

independentes e que possuem informaes especficas associadas que precisam ser armazenadas tambm. Para esta situao o catlogo dispe do padro Organization Hierarchies que trata da criao de hierarquias dentro das organizaes, como mostrado na Figura 20.

39


Figura 20. Representao do padro de anlise organization hierarchies.

Assim como fizemos com os padres no caso da representao de quantidades, podemos combinar esses dois padres e obter uma forma de representao geral de pessoas e organizaes. O modelo apresentado na Figura 21 seria uma boa forma de representar e armazenar informaes sobre pessoas e organizaes considerando inclusive as subdivises das organizaes.

Figura 21. Soluo de representao de pessoas e organizaes utilizando padres de anlise.

4.3.2 Soluo: Archetype Patterns

O catlogo de archetype patterns tambm possui entre os seus padres o padro party para descrever o problema de representar pessoas e organizaes de uma forma geral e armazenar as informaes das partes. O padro apresentado no catlogo apresenta uma descrio bastante abrangente para problemas envolvendo partes, inclusive representando um relacionamento com um outro archetype pattern para simplificar o modelo, como podemos ver na Figura 22.

40


No entanto, utilizaremos da mesma tcnica que utilizamos para o padro quantity para representar o nosso problema. Atravs da aplicao da caracterstica de variao dos archetypes patterns podemos obter um modelo semelhante ao apresentado na Figura 23.

Figura 22. Representao do party archetype pattern.

41


Figura 23. Adaptao do modelo do party achetype pattern para se assemelhar ao modelo

definido atravs de padres de anlise.

4.3.3 Soluo: Padres de Projeto

Para identificar alguns padres de projeto que poderiam ser utilizados na soluo do padro party vamos utilizar da mesma estratgia que utilizamos com o padro quantity. Para a criar o relacionamento entre pessoas, organizaes, e as subdivises de uma organizao revelando apenas a interface comum desses objetos poderamos utilizar o padro Abstract Factory (veja Figura 15), como utilizado para o problema da representao das unidades no padro quantity . Poderamos tambm utilizar o padro de projeto Composite, mostrado na Figura 17, para manipular as organizaes simples e organizaes compostas por diversos setores (veja modelo da Figura 20) de uma maneira uniforme. Para o padro quantity utilizamos a mesma estratgia para solucionar o problema de manipular unidades simples e unidades derivadas. Para implementar uma agenda com as informaes armazenadas, por exemplo, seria necessrio uma forma de percorrer as informaes, como em uma lista. No entanto, a lista seria composta tanto de informaes de pessoas quanto de organizaes. O padro de projeto Iterator poderia ajudar a resolver esse problema. Esse padro possibilita uma maneira de percorrer uma lista composta de objetos de estruturas diferentes de uma maneira uniforme. A estrutura desse padro apresentada como na Figura 24 em [5].

42


Figura 24. Estrutura do padro de projeto Iterator.

4.4 Resumo Neste captulo observamos que nos catlogos dos diversos tipos de padres podemos encontrar padres que descrevem o mesmo problema e que essas descries podem apresentar diferentes vises para o mesmo problema. Verificamos inclusive que no catlogo dos padres de anlise e de archetype patterns encontramos padres que compartilham do mesmo nome, pois apresentam solues para o mesmo problema. No entanto, existem padres que apesar de possurem o mesmo nome no descrevem uma soluo da mesma maneira, como o caso do padro Product (veja Anexo A). Na descrio do Product Archetype Pattern o produto apresentado como elemento envolvido em compras e vendas, enquanto que no catlogo de padres de anlise o Product Pattern o produto apresentado em termos de contratos e itens dos contratos em um aspecto mais financeiro. Estudamos o problema de representao de quantidades em sistemas, pois o padro quantity que descreve esse problema um dos padres que existem tanto no catlogo de padres de anlise quanto no de archetype patterns. Utilizamos o padro quantity para mostrar que os trs diferentes tipos de padres estudados no Captulo 3 podem ser utilizados para ajudar a encontrar uma soluo para esse problema. Apresentamos primeiramente trs padres de anlise que foram descritos para ajudar a representar o problema da quantidade. Mostramos que esses trs padres podem ser combinados para descrever uma soluo mais completa para o problema de representao de quantidades. Mostramos como o mesmo problema foi tratado atravs do quantity archetype pattern. Verificamos que o modelo descrito para esse padro foi desenvolvido a partir de uma extenso do padro de anlise quantity e que possvel obter um modelo bastante semelhante a esse modelo utilizando-se da capacidade de adaptao dos archetype patterns atravs da caracterstica de variao. Mostramos tambm que mesmo no possuindo um nvel de abstrao de negcio os padres de projeto podem ser utilizados na composio da soluo para o problema. Mostramos que podem ser identificados e utilizados alguns padres de projeto no prprio modelo para o problema da representao de quantidades. Por fim apresentamos um outro exemplo em que os trs tipos de padres podem auxiliar a resolver o problema apresentado. Atravs do problema da representao de pessoas e organizaes mostramos mais uma vez que os trs tipos de padres apresentados podem ser utilizados em conjunto para resolver problemas. Os archetype patterns e padres de anlise

43


podem descrever o problema a nvel de negcio, enquanto que os padres de projeto podem auxiliar na criao de uma boa estrutura a nvel de projeto para o modelo. Atravs desses exemplos podemos destacar algumas estratgias e diretrizes utilizadas para realizar a transio entre os padres. Por descreverem solues no nvel de negcio a transio entre padres de anlise e archetype patterns ocorre de uma maneira mais natural em relao transio envolvendo padres de projeto. Na descrio de um mesmo problema no nvel de negcio os padres de anlise e archetype patterns naturalmente apresentam alguns elementos em comum, pois so elementos especficos do problema que esto modelando. Esses elementos acabam tornando-se elementos essenciais tambm na transio de um modelo descrito utilizando um tipo de padro para o outro. Neste captulo a estratgia adotada nos exemplos foi de utilizar a caracterstica de variao dos archetype patterns para destacar os elementos principais presentes nos modelos de anlise. No entanto, a transio envolvendo padres de projeto envolve a observao de algumas diretrizes alm da identificao de certos elementos. No catlogo de padres de projeto em Gamma et al. [5] existem algumas diretrizes que indicam situaes especficas em que cada padro poderia ser utilizado para solucionar um problema. Para realizar a transio para os padres de projeto a estratgia utilizada foi de identificar nos modelos de negcios elementos que satisfizessem as diretrizes dos padres do catlogo. Elementos que devem ser nicos em todo o sistema (Singleton), representao de classes que podem apresentar muitos comportamentos e com muitas condies (Strategy), criao de famlia de objetos relacionados (Abstract Factory), representao uniforme de objetos independentes ou compostos (Composite) e manipulao de listas compostas por objetos de estruturas diferentes (Iterator) foram algumas das diretrizes observadas para a determinao dos padres de projeto a serem utilizados nos modelos. O objetivo deste captulo era de apresentar como esses trs tipos de padres podem ser utilizados em conjunto para resolver problemas. Desta forma a seqncia em que os padres foram utilizados no deve ser considerada, pois o que realmente determina a seqncia em que os padres podero ser utilizados so os modelos que sero gerados para resolver o problema e a seqncia que esses modelos sero necessrios. No entanto, baseando-se no nvel de abstrao que cada tipo de padro utiliza, uma boa seqncia para utilizar esses padres seria como apresentado na Figura 25. A medida que detalhamos o que definimos durante o processo de desenvolvimento de um sistema novos elementos so acrescentados. Uma classe definida em um modelo no nvel de negcio poder ser representada por uma ou mais classes no nvel de anlise, podendo ocorrer o mesmo em relao s classes de anlise representadas no nvel de projeto.

44


Figura 25. Seqncia de utilizao dos trs tipos de padres de acordo com o nvel de abstrao.

Classes de Negcio Classes de Anlise Classes de Projeto

45


5

Estudo de Caso

Nos captulos anteriores abordamos o RUP e trs tipos de padres: padres de projeto, padres de anlise e archetype patterns. Aprendemos que um dos objetivos do RUP a busca contnua por qualidade de software e que a utilizao de padres ajuda no desenvolvimento de software com qualidade. No entanto, no vimos ainda como o RUP e os padres podem ser utilizados em conjunto. Neste captulo vamos apresentar como o RUP e os padres podem ser utilizados juntos. Baseado em um estudo de caso desenvolvido por Craig Larman [19] vamos apresentar onde os padres poderiam ser utilizados em um processo de desenvolvimento de software como o RUP. No desenvolvimento do seu estudo de caso Larman utilizou o processo de desenvolvimento de software do RUP para apresentar uma introduo anlise e projeto de software orientado a objetos e utilizou alguns padres de projeto. Nos basearemos neste estudo de caso, pois desta forma podemos manter o foco do nosso trabalho de apenas apresentar onde os padres poderiam ser utilizados dentro do processo, abstraindo o processo completo definido pelo RUP. Ao apresentar onde os tipos de padres que apresentamos podem ser utilizados no RUP iremos realizar o mapeamento da utilizao desses padres s fases do processo. Desta forma podemos identificar quando cada tipo de padro pode ser utilizado com mais intensidade.

5.1 Introduo Como j vimos no Captulo 2, a forma que o RUP organizado divide o seu processo de desenvolvimento de software em quatro fases: iniciao, elaborao, construo e transio. No decorrer destas quatro fases so desempenhadas diversas disciplinas definidas no processo variando a nfase dada a cada disciplina ao longo do tempo (ver Figura 4). No fluxo desenvolvido dessas disciplinas so realizadas diversas atividades e diversos artefatos so gerados, entre eles diversos modelos. Em projetos de software orientados a objetos o desenvolvimento de alguns desses modelos poderiam ser auxiliados pela utilizao de padres, portanto importante saber quando os padres poderiam ser teis no processo de desenvolvimento. Saber antecipadamente em que momento um determinado tipo de padro pode ajudar a buscar possveis solues nos catlogos de padres desde o comeo do desenvolvimento dos modelos.

Captulo

46


Para mostrar situaes em que um determinado tipo de padro poderia ser utilizado vamos utilizar como base o estudo de caso do ponto de venda desenvolvido em [19]. Durante esse estudo de caso Larman mostrou a evoluo do desenvolvimento do sistema utilizando o RUP e dando nfase s atividades de anlise e projeto orientados a objetos presentes no RUP. Durante o processo do RUP diversas atividades devem ser realizadas e artefatos gerados alm da criao de modelos de anlise e de projeto orientados a objetos. Como a realizao dessas atividades no objetivo deste trabalho aproveitamos um caso j realizado para nos concentrar apenas na aplicao dos padres s fases do RUP.

5.1.1 O caso do Ponto de Venda

Sistemas de ponto de venda so relativamente fceis de encontrar, sendo utilizado em diversos tipos de loja para controlar a compra e venda de produtos. So sistemas utilizados em caixas registradores mais modernos, como na Figura 26, e que auxiliam o controle de pagamentos, etc. O problema do ponto de venda foi descrito da seguinte forma em [19]: Um sistema de ponto de venda uma aplicao de computador utilizada, em parte, para registrar vendas e controlar pagamentos; tipicamente utilizado em lojas de varejo. O sistema normalmente inclui componentes como um computador, um leitor de cdigo de barras e um software para executar o sistema. O sistema se comunica com diversas outras aplicaes como sistemas de clculo de impostos e de controle de estoque. Estes sistemas devem ser relativamente tolerante a falhas, isto , mesmo que alguns servios remotos, como o controle de estoque, fiquem indisponveis temporariamente o sistema deve ser capaz de registrar vendas e controlar os pagamentos.

Figura 26. Ilustrao de um sistema de ponto de venda.

5.2 Adaptao do RUP Na utilizao do RUP para o desenvolvimento de um sistema real uma das atividades iniciais do processo faz a definio do plano de projeto e do plano de iterao. Atravs da definio desses

47


dois documentos definida a estratgia que ser utilizada para o desenvolvimento do sistema. definido como sero organizadas as fases, quantas iteraes sero realizadas em cada fase e os marcos que definem o incio e fim de cada fase, entre outras coisas. No entanto, para efeito deste trabalho iremos abstrair essas definies. Para atender o foco principal deste captulo, que o mapeamento do uso de padres ao RUP, nos concentraremos apenas nas fases e em algumas disciplinas e atividades dessas disciplinas. As disciplinas sero focadas em razo da relao entre os objetivos que a disciplina busca atender, os artefatos gerados e a possibilidade de utilizao de algum dos trs tipos de padro para auxiliar na criao desses artefatos.

5.3 Aplicando os padres s fases do RUP As disciplinas que iremos focar na nossa anlise sero as disciplinas de modelagem de negcios e anlise e projeto. Como podemos observar no grfico da Figura 4, a disciplina de modelagem de negcios tem um maior esforo concentrado logo no comeo da fase de iniciao e um pouco da fase de elaborao. J as disciplinas de anlise e projeto tm maior concentrao de esforo na fase de elaborao, mas tambm bem presente nas fases de iniciao e construo. A disciplina de modelagem de negcios tem como alguns de seus objetivos o entendimento do problema e do negcio alvo do sistema, assim como assegurar um entendimento comum do problema pelos interessados do projeto. O diagrama de estados apresentado na Figura 27 representa o fluxo de trabalho dessa disciplina. O fluxo principal para o nosso trabalho o fluxo relacionado ao desenvolvimento de um modelo de domnio. Um dos artefatos gerados nas atividades deste fluxo um modelo de objetos de negcio ou modelo de domnio [4]. Um modelo de domnio ilustra conceitos importantes em um domnio de negcio [19]. O modelo de domnio pod

Download - Padroes de Projeto

Top Related