Analysis Patterns: Uma Breve Apresentao dos Principais Padres de Anlise Orientados a Objetos

Lucas Ferreira1, Ednelson Santos2 Coordenadoria de Informtica - Instituto Federal de Alagoas (IFAL) Rua Odilon Vasconcelos, Centro 57.035-350 Macei AL Brasil
lucasleao@hotmail.com, edtenente@hotmail.com
1

Resumo. Este artigo da disciplina de Anlise e Projeto de Sistemas Orientado a Objetos (APRS) do IFAL descreve brevemente os principais padres de anlise (analysis patterns) selecionados aps uma pesquisa bibliogrfica realizada na internet sobre o tema. Os padres apresentados so: PARTY, ORGANIZATION HIERARCHIES, ORGANIZATION STRUCTURE, QUANTITY, CONVERSATION RATIO, COMPOUND UNITS.

1. Introduo
Na anlise e projeto de sistemas, conforme estudos e conhecimentos empricos surgiram, ficou comprovado em muitos problemas a existncia de condies recorrentes. Aps desenvolvimentos e testes exaustivos vrios modelos de anlise e solues foram propostos para problemas idnticos ou semelhantes. Geralmente quando o problema est associado anlise usamos modelos chamados de Analysis patterns, quando o modelo est associado projeto e implementao usamos o termo Designer Patterns. Analysis patterns so ideias que foram teis em algum contexto e devem permanecer teis em outros, sendo teis na modelagem de domnios de negcio e apoiam o reuso de ideias durante a fase de anlise. Surgiu na dcada de 70, com a publicao dos livros: Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, onde arquiteto Christopher Alexander estabelece que um padro deve ter as seguintes caractersticas: Encapsulamento; Generalidade; Equilbrio; Abstrao; Abertura; Combinatoriedade. Em 1995, com o lanamento do livro, Design Patterns: Elements of Reusable Object-Oriented Software, escrito por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, a discusso sobre Padres de Projeto de Software ganha popularidade e h o surgimento do Padres GoF (Gang of Four) que um Catlogo de Padres Dividido em trs famlias: Padres de criao: preocupam-se em como criar objetos; Padres de estrutura: preocupam-se em como compor objetos; Padres de comportamento: preocupam-se em como os objetos devem interagir;

H o Padro GRASP (General Responsibility Assignment Software Patterns), que est disposto no estilo arquitetural MVC MVC = Model-View-Controller O estudo de anti-padro se faz necessrio devido a ser uma soluo negativa amplificada de forma a ajudar as organizaes a reconhecerem uma situao problemtica e dessa forma evit-la e saber como agir em caso de seu surgimento.

1.1 Modelos Conceituais

Ao fazer anlise, tentamos entender o domnio do problema nesse contexto envolve: Levantar requisitos funcionais (Use Cases ou User Stories) Levantar requisitos no funcionais Criar um modelo conceitual do domnio do problema Observamos ento que um modelo conceitual um modelo mental do que est acontecendo no domnio do problema. Um modelo conceitual um artefato para os desenvolvedores conversarem com o cliente. A princpio modelos no so corretos ou errados, so mais ou menos teis: Modelos conceituais devem ser criados juntamente com Domain Experts; oAnalistas no conhecem o domnio do problema suficiente bem para dispensar os experts; oAnalistas somam no time pela aplicao de rigor, tcnicas de modelagem e porque trazem um ponto de vista externo; Modelos conceituais so independentes de tecnologias de software; A partir do modelo possvel que todos os analistas entendam o problema, porm modelos podem, como j foi citado, no informar muita coisa. Para tanto foram criados alguns modelos de sucesso para anlise, que se tornaram padres de anlise.

2. Apresentao dos padres de anlise

Martin Fowler em seu livo Analysis Patterns: Reusable Object Models descreve detalhadamente como funcionam, para que servem e como devem ser utilizados os padres, alm de elucidar algumas situaes em que podero ser utilizados de maneira incorreta. Martin cita alguns padres muito recorrentes so eles: PARTY: Define um objeto parte como um supertipo para uma pessoa ou organizao, de maneira que a associao entre informaes fosse relativa s partes e no s pessoa ou organizao diretamente.

Figura 1: Analysis Patterns: Party ORGANIZATION HIERARCHIES: Modela uma hierarquia organizacional atravs

de uma estrutura recursiva. Estabelecendo organizacionais atravs de regras.

relacionamentos

entre

entidades

Figura 2: Analysis Patterns: Organization Hierarchies ORGANIZATION STRUCTURE: Usa tipos para definir relacionamentos entre

entidades organizacionais.

Figura 3: Analysis Patterns: Organization Structure QUANTITY: Define um tipo de objeto que tem como parte numeros e unidades.

Figura 4: Analysis Patterns: Quantity CONVERSATION RATIO: Define um objeto de converso entre unidades, e d a

quantidade uma operao, convertTo(Unit), que retorna uma nova quantidade na unidade.

Figura 5: Analysis Patterns: Conversation Ratio

 COMPOUND UNITS: Uma unidade composta a combinao entre unidades

atmicas, por exemplo milhas por hora. Uma operao de converso sofisticada pode usar um conversor em uma unidade atmica para converter unidades compostas.

Figura 6: Analysis Patterns: Compound Units

Alguns padres de Anlise surgem mais especificamente quando estamos lidando com um nincho menos abrangente, como por exemplo na rea fianceira vejamos o exemplo de um padro para uso e criao de uma conta: ANALYSIS PATTERN: ACCOUNT Definio: Use o padro "Conta" quando precisa de uma viso histrica de mudanas a um valor, se precisar apenas de saldos histricos e no das mudanas, podese usar o padro "Temporal Property". Como funciona: Junta lanamentos contbeis relacionados e prov dados de sumrio

Figura 7: Analysis Patterns: Account

 Contas surgem com freqncia em sistemas financeiros oContas bancrias oContas para custos de um projeto oPlano de contas de uma empresa etc. Podemos pensar sobre contas de vrias formas: oUma conta um repositrio de lanamentos oAo criar um lanamento, ele colocado numa conta oA conta prov informao sumarizada, tal como um saldo oUma conta mantm o histrico de algum valor numrico Voc no quer saber apenas o valor atual, mas o valor em qualquer momento do

passado Voc quer saber de todas as mudanas que ocorreram ao valor Uma conta uma forma de fatorar os elementos de um lanamento.

Figura 8: Analysis Patterns: Account Contas nem sempre tratam de dinheiro o Pense, por exemplo, num controle de estoque o Cada tipo de material sendo estocado corresponde a uma conta

Detalhes de funcionamento H dois aspectos importantes de contas: oGuardar uma coleo de lanamentos oProver informao de sumrio sobre os lanamentos Devido grande quantidade de lanamentos, deve-se freqentemente aperfeioar a forma de calcular a informao de sumrio oExemplo, para calcular o saldo, pode-se guardar o saldo atual e "andar para trs" nos lanamentos para obter saldos de datas passadas Depois de certo tempo, pode ser necessrio remover lanamentos muito antigos e substitu-los por lanamentos fictcios agregados para diminuir o nmero total de lanamentos

oClaro que, desta forma, perde-se a possibilidade de obter detalhes sobre os

perodos de tempo envolvidos Hierarquia de contas o Podemos tambm agrupar contas em um nvel mais alto.

3. Concluses
O bom uso de padres polpa tempo do analista, deixa o trabalho mais limpo, claro e de melhor qualidade, alm de facilitar o entendimento do cliente e da equipe de desenvolvedores. Uma maneira bastante inteligente economizar tempo no que j consolidado como boas prticas e utilizar esse tempo ganho em algo novo, desafiador ou que seja crucial ao projeto.

Referncias
1. Fowler, M.; Analysis Patterns: Reusable Object Models, MA.; Addison-Wesley; 1996. 2. http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/ap/, acessado em 30 de abril de 2012. 3. http://www.ufpa.br/cdesouza/teaching/labes/padroes-de-software.pdf, em 30 de abril de 2012. acessado

4. http://www.ufpa.br/cdesouza/teaching/cedai/7-patterns.pdf, acessado em 30 de abril de 2012.