Padrões de Análise. Martin Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, Osvaldo Kotaro Takai João Eduardo Ferreira

Transcrição

1 Padrões de Análise Martin Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, 2000 última atualização: agosto 2005 Osvaldo Kotaro Takai João Eduardo Ferreira

2 Capítulo 1 - Introdução Modelos Conceituais

3 Fato Não existe consenso sobre a fronteira entre a análise e projeto

4 1º Princípio de Modelagem A estrutura de um projeto de software deve refletir a estrutura do problema

5 Modelos Conceituais 1 Resultado: modelos de análise e de projeto são muito parecidos. Conseqüência: pessoas acham que não existe diferença entre esses modelos; mas existe!

6 Modelos Conceituais 2 A diferença entre análise e projeto está na ênfase. Análise: Entender o problema. Não basta apenas criar uma lista de requisitos e use-cases. É necessário olhar além da superfície de requisitos e visualizar o mapa mental (o Modelo Conceitual) do que está se passando no problema. Projeto: Construir uma solução.

7 Exemplo 1 Para construir um programa que simule um jogo de sinuca poderíamos: especificar o sistema escrevendo use-cases. filmar centenas de jogadas e tentar simular os resultados no computador.

8 Exemplo 2 Mas, para escrever uma boa simulação, isso não seria suficiente. Precisamos entender o que está se passando subjacente daquilo que estamos observando; Precisamos de um modelo conceitual para explicar as leis do movimento que relacionam massa, força, velocidade, etc.

9 Exemplo 3 Para isso, podemos usar um modelo: newtoniano da física clássica ou einsteiniano baseado na física moderna. Provavelmente o modelo newtoniano seria mais apropriado, pois é mais simples embora menos exato. Um purista poderia dizer que o modelo einsteiniano seria mais apropriado, pois o código poderia ser reutilizado em um programa para simular colisões entre átomos.

10 Exemplo 4 Acrescentar flexibilidade demais a um sistema é ruim pois pode elevar a complexidade. Portanto, escolha o modelo mais simples e que atenda às suas necessidades. Trata-se da escolha custo/benefício, no qual o domínio de aplicação define a abordagem simples ou mais complexa.

11 2º Princípio de Modelagem Modelos não são certos ou errados; apenas são mais ou menos apropriados Cuidado! Normalmente, o modelo simples não é o primeiro que vem em nossa mente. Vale a pena investir tempo para simplificar nossos modelos.

12 Expressar Modelos Conceituais Modelos conceituais podem ser expressos através de linguagens de programação. Vantagens: podemos executar os modelos para verificar sua exatidão e explorá-lo. simplificação do processo de transformação do modelo para a linguagem-alvo. Desvantagens: perigo de desviar-se do objetivo de entender o problema por perder-se nos detalhes da linguagem. modelos podem usar características de linguagem de modelagem que não estão presentes na linguagem-alvo.

13 Técnicas de Análise e Projeto Devido a esses problemas, utilizamos técnicas de análise e projeto para criar modelos conceituais. Tais técnicas: nos ajudam a concentrar nos conceitos ao invés de nos detalhes de projeto de software. para serem mais expressivos, usam gráficos. podem ser utilizados em conjunto com uma linguagem de programação, não necessitando que sejam muito rigorosos. são fáceis de serem compreendidas por especialistas de domínio.

14 Especialistas de Domínio É essencial que especialistas do domínio estejam envolvidos na modelagem conceitual, pois são os únicos que, de fato, entendem o domínio. Dificilmente um analista de sistemas substituiria um especialista de domínio na modelagem conceitual. O conhecimento de especialistas é central para um bom modelo de análise.

15 As Técnicas de Análise Idealmente, técnicas de modelagem conceitual deveriam ser totalmente independentes da tecnologia de software, como as leis de movimento. Esta independência previne que a tecnologia obscureça o entendimento de um problema e os modelos resultantes podem ser utilizados por todos os tipos de tecnologia de software.

16 Influência das Linguagens Na prática, esse purismo não ocorre. Por exemplo, modelos conceituais, com base nas tecnologias OO e Relacional. Linguagens controlam a máquina física e a expressão das necessidades do problema. Linguagens mudam porque encontramos melhores formas de expressar as necessidades e problemas. Assim, as linguagens influenciam na maneira como construímos modelos conceituais.

17 3º Princípio de Modelagem Modelos conceituais estão associados à interfaces (tipos) e não à implementações (classes) Infelizmente esta distinção é facilmente esquecida devido a linguagem comum não deixar esta distinção explícita. Não esqueça! Modelos Conceituais estão intimamente associados à interfaces de software, não à implementações de software.

18 Capítulo 1 - Introdução O Mundo dos Padrões

19 Situação Atual 1 Nos últimos anos, padrões vêm se tornando mania na comunidade de objetos, gerando imenso interesse e uso exagerado. Existem batalhas internas à comunidade de objetos sobre o que é exatamente um padrão. Certamente é difícil encontrar alguma definição consensual de padrão.

20 Situação Atual 2 O mundo do software não foi muito bom para descrever e proliferar boas práticas de projeto. Existem muitos métodos, mas apenas definem linguagens para descrever projetos e não descrevem projetos reais. Faltam descrições de projetos reais, que possam ser usados para educar e inspirar. Ralph Johnson e Ward Cunningham disseram que Projetos falham a despeito das recentes tecnologias por falta de soluções básicas.

21 Situação Atual 3 Padrões desenvolveram-se de várias iniciativas. Kent Beck e Ward Cunningham, dois pioneiros do Smalltalk, encontraram as idéias de Christopher Alexander, que havia desenvolvido uma teoria e coleção de padrões na área de Arquitetura. Os padrões tornaram-se públicos após a publicação do livro Padrões de Projeto da Gang of Four ou GoF.

22 Capítulo 1 - Introdução Christopher Alexander

23 Christopher Alexander 1 Para alguns, o mundo dos padrões apareceram no software quase que totalmente dos trabalhos de Christopher Alexander, um professor de arquitetura na Universidade de Califórnia em Berkeley. Alexander desenvolveu várias teorias sobre padrões na arquitetura e os publicou numa série de livros.

24 Christopher Alexander 2 Seu livro, Linguagens de Padrões, um catálogo de padrões na arquitetura, é visto como um protótipo para livros de padrões em software. Seu estilo de escrever padrões é usado com algumas extensões, por muitos escritores de padrões. Sua frase uma qualidade sem um nome é freqüentemente citado como um atributo que todos os padrões deveriam ter.

25 Christopher Alexander 3 Porém, muitos negam que Alexander tenha exercido papel central na inspiração de padrões em software. Peter Coad diz que a noção de padrões é utilizada por vários autores em diversas áreas, e são melhores exemplos do que os de Alexander.

26 Christopher Alexander 4 As idéias de Alexander, mesmo na Arquitetura, não são universalmente aceitas. O livro da GoF influenciou muito mais os padrões de software do que o de Alexander e 3 dos 4 autores não haviam lido Alexander antes de escrever o livro.

27 Capítulo 1 - Introdução Forma Literária

28 Forma Literária 1 Uma das características que mais diferenciam os padrões é a forma como eles são descritos. No entanto, não existe nenhum formato simples. Muitas pessoas seguem o estilo inspirado por Alexander. Outros seguem o formato usado pela GoF.

29 Forma Literária 2 Um padrão, sempre que é descrito, têm essencialmente quatro partes: declaração do contexto onde o padrão se aplica. o problema que o padrão trata. as forças que atuam no problema. a solução que resolve essas forças

30 Forma Literária 3 Esta forma é importante porque apóia uma das definições de padrão: uma solução para um problema num dado contexto. Uma definição que delimita o padrão como um simples par problema-solução. Importante! Todo padrão deve ter um nome.

31 Forma Literária 4 Uma das vantagens em se utilizar padrões é que eles enriquecem o nosso vocabulário de desenvolvimento. Ao dizermos: use um proxy de proteção aqui usamos observer para registrar as métricas de produto. podemos comunicar nossas idéias com maior efetividade.

32 Capítulo 1 - Introdução O Nível de Abstração do Autor

33 Padrões não são invenções acadêmicas Um dos elementos chaves de padrões é que eles são descobertos observando o que ocorre no dia-a-dia de desenvolvimento, ao invés de serem invenções acadêmicas. Os padrões de análise não são apenas úteis aos desenvolvedores de uma mesma área de domínio, normalmente eles podem ser úteis em outros domínios.

34 Padrões de Análise são Úteis para Vários Domínios Por exemplo, o padrão portfólio que foi criado para agrupar contratos financeiros, pode ser utilizado para agrupar qualquer tipo de objeto, pois define uma consulta implícita e é suficientemente abstrato para ser utilizado em qualquer domínio. O nível de abstração de Padrões de Análise deve ser amplo o suficiente para atender a vários domínios e específico o suficiente para que seja útil quando aplicados em aplicações.

35 Capítulo 1 - Introdução Os Padrões do Livro

36 Definição de Padrão Um padrão é uma idéia que é útil num contexto prático e que provavelmente continuará a ser útil em outros contextos.

37 Explicação da Definição 1 O termo idéia é usado pelo fato de que um padrão pode ser qualquer coisa. Pode ser um grupo de objetos com colaboração mútua, como os padrões da GoF ou princípios para organização de projetos de Coplien. A frase contexto prático reflete o fato de que os padrões são desenvolvidos como resultado de experiências práticas em projetos reais.

38 Explicação da Definição 2 Padrões são descobertos e não criados. Modelos se tornam padrões quando houver utilidade comum. Nem todas as idéias de um projeto são padrões; padrões são coisas que desenvolvedores acreditam ser úteis em outros contextos.

39 Padrões do Livro Os Padrões do Livro são divididos em duas categorias: Padrões de Análise: grupo de conceitos que representam uma construção comum na modelagem de negócio. Eles podem ser relevantes a um ou mais domínios. Padrões de Apoio: são padrões que descrevem como capturar os padrões de análise, aplicá-los e torná-los reais.

40 Exemplos de Modelagem 1 A maioria dos livros de análise e projeto são introdutórios e não explicam o método do autor. Tais livros não cobrem problemas importantes de modelagem problemas que surgem no contexto de um grande projeto. Tais problemas são de difícil compreensão fora do contexto e precisam que o leitor tenham alguma experiência em modelagem.

41 Exemplos de Modelagem 2 Padrões fornecem uma boa maneira de enxergar esses problemas. Muitos padrões do livro tratam de assuntos de modelagem considerando um particular problema de um domínio, facilitando a sua compreensão.

42 Exemplos de Modelagem 3 Exemplos: manipulação de métodos que podem ser ligados a instâncias de objetos individuais. subtipos de diagramas de estados. separação de modelos em níveis de conhecimento e operacional. uso de portfólios para agrupar objetos em uma consulta.

43 Modelos Conceituais e Reengenharia de Processos de Negócio (BPR) 1 Muitos usam modelos conceituais para auxiliar no desenvolvimento de sistemas computacionais, mas modelos conceituais têm outros propósitos. Bons analistas de sistemas sabem que simplesmente automatizar um processo existente não é um bom uso de recursos.

44 Modelos Conceituais e Reengenharia de Processos de Negócio (BPR) 2 Computadores fazem com que pessoas pensem de forma diferente. No entanto, analistas de sistemas encontram dificuldades de levar suas idéias adiante. Suas técnicas ainda estão muito dependentes dos pensamentos de software. Os especialistas de IT tem gasto muito tempo para convencer líderes de negócio a levarem suas idéias a sério.

45 Modelos Conceituais e Reengenharia de Processos de Negócio (BPR) 3 Usar a tecnologia OO para a modelagem conceitual pode realmente fazer com que a análise de sistemas e a Reengenharia de Processos de Negócio (BPR) sejam a mesma atividade. Os especialistas de domínio aprendem rapidamente o seu potencial e começam a pensar em seus próprios domínios de maneira diferente.

46 4º Princípio de Modelagem Padrões são um ponto de partida, não o destino.

47 5º Princípio de Modelagem Modelos não são certos ou errados, eles são mais ou menos úteis.

48 Fim da Introdução Continue com a apresentação Padrões de Análise - Parte 1.ppt