Padrões de Análise
Martin Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, 2000
Osvaldo Kotaro Takai João Eduardo Ferreira
Capítulo 1 - Introdução
Fato
Não existe consenso sobre a fronteira entre a análise e projeto
1º Princípio de Modelagem
A estrutura de um projeto de software deve refletir a estrutura do problema
Modelos Conceituais
1 Resultado: modelos de análise e de projeto
são muito parecidos.
Conseqüência: pessoas acham que não existe
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.
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
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.
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
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.
2º Princípio de Modelagem
Cuidado! Normalmente, o modelo simples
não é o primeiro que vem em nossa mente.
Vale a pena investir tempo para simplificar
nossos modelos.
Modelos não são certos ou errados; apenas são mais ou menos apropriados
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.
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
É 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
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.
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
3º Princípio de Modelagem
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. Modelos conceituais estão associados à
interfaces (tipos) e não à implementações
Capítulo 1 - Introdução
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
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”.
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.
Capítulo 1 - Introdução
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.
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.
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.
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
Capítulo 1 - Introdução
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.
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
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.
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
Capítulo 1 - Introdução
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.
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.
Capítulo 1 - Introdução
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.
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.
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.
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.
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
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.
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
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.
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.
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.
4º Princípio de Modelagem
Padrões são um ponto de partida, não o destino.
5º Princípio de Modelagem
Modelos não são certos ou errados, eles são mais ou menos úteis.
Fim da Introdução