• Nenhum resultado encontrado

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

N/A
N/A
Protected

Academic year: 2021

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

Copied!
48
0
0

Texto

(1)

Padrões de Análise

Martin Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, 2000

Osvaldo Kotaro Takai João Eduardo Ferreira

(2)

Capítulo 1 - Introdução

(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

(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.

(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

(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

(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

„ 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

(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

(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

(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

(17)

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

(18)

Capítulo 1 - Introdução

(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

(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

(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

(27)

Capítulo 1 - Introdução

(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.

(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

(32)

Capítulo 1 - Introdução

(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

(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

(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

(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

Referências

Documentos relacionados