análise de sistemas oo 1
TRANSCRIPT
Análise de Sistemas OO - 1 Maurício Linhares
Material de referência � Head First Object Oriented Design and
Analysis – Brett D. McLaughlin e outros
� Domain Driven Design – Tackling Complexity in the Heart of Software – Eric Evans
� Refactoring: Improving the design of existing code – Martin Fowler e outros
O que é análise Orientada a Objetos? Definição dos objetos, suas atividades, propriedades e funções dentro do sistema onde eles estão inseridos
Modelando um simulador de rotas de rede Pense nos atores e nas atividades
Modelagem eficiente � Manter modelos e implementação
fortemente ligados;
� Cultivar uma linguagem baseada no modelo;
� Desenvolver um modelo que represente conhecimento sobre o assunto tratado;
Modelagem Eficiente � Destilar o modelo, removendo conceitos
desnecessários ou não essenciais;
� Brainstorms e experimentação para garantir que a solução que está sendo desenvolvida é realmente a melhor possível;
Eric Evans, Domain Driven Design, página 13
“É a criatividade dos brainstorms e experimentações, junto com uma linguagem baseada no modelo e disciplinada pelo feedback da implementação, que torna possível encontrar um modelo rico e destilá-lo para o software funcional.”
Knowlege Crunching – Triturando conhecimento � A equipe trabalha junto com os
especialistas do domínio para criar o modelo;
� O conhecimento deve ser refinado e construído de acordo com as funcionalidades desejadas;
Knowledge crunching � Ilhas de informação devem ser evitadas,
é importante que todos os membros tenham conhecimento sobre o modelo para que possam escrever o software;
� Abstrações do modelo devem surgir através das abstrações do próprio domínio, o modelo sempre reflete o mundo real;
Aprendizado contínuo � Programar é definir uma teoria, em
código, que representa elementos no mundo real;
� Conhecimento se fragmenta, se torna obsoleto ou representa entidades de pouca importância, é necessário continuar aprendendo;
Implementando cargas, viagens e overbooking Construindo um modelo rico em conhecimento
Modelos profundos � Não perca tempo demais tentando ir o
mais fundo possível nos seus modelos;
� Conhecimento e refinamento vem com tempo, prática e experimentação;
� O modelo final dificilmente é o mesmo do modelo inicial;
Momentos da análise OO – Conceitualmente
� Deduzir os requisitos do cliente para o sistema; � Identificar cenários de casos de uso; � Selecionar classes e objetos usando os
requisitos; � Identificar atributos e operações para cada
objeto do sistema; � Definir estruturas e hierarquias que organizem as
classes; � Construir um modelo objeto-relacionamento; � Construir um modelo de comportamento de
objeto; � Revisar o modelo de análise OO com base nos
casos de uso ou cenários.
Caminho do sucesso - simplificado � Descubra as funcionalidades que o cliente
necessita;
� Primeiro escreva código que atende a necessidade do cliente (e com testes);
� Depois atente para os problemas de design OO que o seu código possa ter e adicione flexibilidade onde necessário;
� Mantenha o seu código bem organizado, legível e passível de ser reutilizado;
� Lucro! $$$!
Escreva a funcionalidade que você deve implementar Como começar?
Tudo começa com os requisitos � Ouça o que o cliente deseja que o sistema
faça;
� Tente usar mockups ou desenhos se ele tiver dificuldade explicando o que ele deseja (http://balsamiq.com/ );
� Não se preocupe demais com a solução tecnológica que você vai ter que implementar;
Atenção aos verbos e substantivos! � O seu cliente entende do negócio, ele
normalmente sabe do que ele está falando então ENTENDA os conceitos básicos;
� Use dentro do seu sistema os mesmos nomes e atividades que o seu cliente está explicando nas funcionalidades;
� Substantivos normalmente simbolizam objetos e verbos seus métodos;
A linguagem Ubíqua � Desenvolvedores e usuários devem falar a
mesma língua quando estiverem falando sobre o sistema;
� Traduções entre conceitos são ruins e geram perda de informação;
� Desenvolvedores devem procurar entender ao menos os conceitos básicos do sistema onde eles estão inseridos;
Um diálogo de exemplo Como desenvolvedores e clientes se comunicam
Conhecimento sendo passado pela fala � O seu cérebro é especializado em entender
a língua falada;
� A forma mais eficiente de aprender uma outra língua é através da imersão, não se fala nada além da nova língua;
� Equipe e especialistas do domínio devem expandir e adicionar novos significados a linguagem comum;
Ah, mas o cliente não entende de objetos! � Nem você entende de direito tributário,
contabilidade, engenharia civil ou gestão de órgãos públicos. E aí?
� A linguagem criada é uma interseção entre o jargão técnico da informática e o jargão técnico do domínio pro qual o seu software vai ser produzido;
Documentos, diagramas, modelos visuais � Não se prenda demais a papéis somente
pelo fato deles serem documentos;
� Documentação deve “pagar” pra existir;
� Não tenha pena de jogar fora documentação que sirva somente de peso;
Documentos, diagramas, modelos visuais � Não se prenda demais a detalhes
técnicos da UML ou da representação que você está utilizando;
� Simplifique qualquer coisa que não atenda as suas necessidades;
� Diagramas NÃO SÃO O SEU PRODUTO (na maior parte das vezes);
Passo a passo � Reúna os caminhos básicos do sistema,
crie uma lista, passo a passo, de o que precisa ser implementado (o que é isso?);
� Bonus se você estiver utilizando uma ferramenta de testes que seja capaz de receber texto puro;
Exemplo hardcore Cenário: Remover itens do carrinho "!Dado que estou na listagem de produtos"E adiciono "5" itens do produto "Lean Software Development" ao carrinho"E adiciono "5" itens do produto "Agile Estimating and Planning" ao carrinho"!Quando vou pra página do carrinho "E removo o produto "Agile Estimating and Planning" do carrinho"!Entao devo ver "Lean Software Development“ "!Mas não devo ver "Agile Estimating and Planning"
Como implementar Settlers of Catan? Crie uma lista de requisitos que defina o jogo. Trivial, claro.
O que é uma classe? Reencontrando a orientação a objetos
O que é uma classe? � Define a estrutura de um objeto, com
seus atributos e operações;
� Atributos são os dados guardados no objeto;
� Operações são as atividades que um objeto é capaz de executar ou as mensagens que ele recebe;
O que é herança? Reencontrando a orientação a objetos
O que é herança? Reutilizar código de uma outra classe herdando suas propriedades e seus comportamentos
O que é polimorfismo? Reencontrando a orientação a objetos
O que é polimorfismo? É a capacidade de se utilizar uma subclasse de um objeto onde o objeto pai (ou interface) é utilizado sem que o código perceba a diferença
O que é encapsulamento? Reencontrando a orientação a objetos
O que é encapsulamento? É o ato de esconder as informações de implementação de um objeto dos seus clientes externos com o objetivo de facilitar as mudanças no futuro.
O que são composição e agregação? Revisando orientação a objetos
O que são composição e agregação? Composição é o fato de que vários objetos interligados compõem um objeto maior e não fazem sentido em separado. Agregação é quando vários objetos podem existir dentro de um objeto maior ou isolados, não sendo necessário que estejam reunidos.
Objetos devem fazer ou representar uma coisa e somente isso. Se o Bolo é comida, vai ser sempre comida. Responsabilidade
Como identificar objetos que fazem demais? � É difícil definir um nome pra eles; � Uma mudança nesse objeto afeta vários
outros objetos dentro do sistema;
� O objeto tem várias propriedades nulas e isso é comum;
Modelo de classes? � É o diagrama de classes acompanhado
de uma descrição textual definindo o que cada classe faz no sistema;
� Existe em três diferentes tipos, domínio, especificação e implementação;
Exemplo de classes num diagrama de classes
Modelo de classes - Domínio � É o diagrama de classes puro, sem
dependência ou associação com a tecnologia que vai ser utilizada;
� Normalmente só existe nos momentos iniciais ou em rascunhos do sistema;
� Usa fortemente a linguagem ubíqua;
Modelo de classes - Especificação � Adiciona detalhes da implementação
que foi escolhida ao modelo (interfaces de infraestrutura, classes base de frameworks, funcionalidades da linguagem);
� Normalmente definido antes de se entrar em detalhes de implementação;
Modelo de classes - Implementação � Classes implementadas na tecnologia
escolhida;
� Código real e executável, normalmente gerado inicialmente através dos modelos definidos anteriormente;
Implementando um inventário � Imagine uma livraria;
� Crie modelos que representem o inventário e que sejam capazes de fazer uma busca dado o título, autor e/ou categoria onde o livro se encontra;
� O sistema deve ser capaz de encontrar vários livros com uma única busca;
Associações no modelo � Objetos estão sempre se relacionando
entre si, esses relacionamentos são chamados de associações;
� Apesar do modelo ser um modelo de classes, as associações são para os objetos dessas classes;
Notação para associações entre objetos
Hóspede Quarto
ContaCorrente HistóricoTransações
Cliente Produto
Cardinalidade � Definem os limites inferiores e superiores
na associação entre dois objetos;
� Associações normalmente tem limites em “0..1”, “0..N” ou “0..*”;
Exemplos de cardinalidade
Nome Simbologia Apenas Um 1..1 (ou 1) Zero ou Muitos 0..* (ou *) Um ou Muitos 1..* Zero ou Um 0..1 Intervalo Específico li..ls
Notação para associações com cardinalidade
Cliente Pedido
1 0..*
Cardinalidade na fórmula 1 � Corridas tem pelo menos 20 carros; � Uma corrida só pode ter no máximo 24
carros; � Um carro pode estar em várias corridas;
Carro Corrida
20..24 0..N
Participação � Define se uma associação é obrigatória
ou não entre os objetos relacionados;
� Se a cardinalidade for 1, então ela é obrigatória, se for 0 em algum momento ela não é obrigatória;
Detalhes das associações em UML � Associações tem nomes, que definem o
seu significado dentro do sistema;
� Direção, definindo como você faz a leitura da mesma;
� Papel, para definir um papel específico onde essa associação existe;
Exemplo de associação
contratante
*
contratado
*
ContrataOrganização Indivíduo
PapelNome da
associação
Papel
Direçãode leitura
Casos especiais: Agregação
JogadorEquipe*
membro
*AssociaçãoEsportiva
* *
Afiliada
� Losangos definem a classe todo no diagrama;
Classes associativas � Classes que existem para dar valores
especiais a uma associação entre objetos;
� Utilizadas quando não há sentido em colocar os atributos em nenhuma das classes relacionadas;
Exemplo de modelo com classe associativa
nometelefoneendereço
Pessoa
razãoSocialendereço
Empresa
saláriodataContratação
Emprego
*
empregado
*
empregador
Outros exemplos de classes associativas? Pense.
Associações n-árias � Utilizadas para demonstrar associações
entre objetos de N classes;
� Associações ternárias são o caso mais comum;
� Um losango é a forma representada em UML para essa associação;
Associação ternária
UsonomeTécnico
modeloComputador
nomeverba
Projeto1 1
*
Associações reflexivas � Associações onde um objeto se associa a
outros objetos da mesma classe;
� Cada objeto tem um papel diferente na associação, de forma que eles sejam diferenciáveis;
Exemplo de associação reflexiva
Empregado
supervisor 1
supervisionado
*
Supervisão
Crie os diagramas de associação entre os objetos da loja Lembre-se de adicionar as cardinalidades e os nomes das associações.
Responsabilidades e colaboradores � Em sistemas OO, objetos encapsulam
tanto dados quanto comportamento. � O comportamento de um objeto é
definido de tal forma que ele possa cumprir com suas responsabilidades.
� Uma responsabilidade é uma obrigação que um objeto tem para com o sistema no qual ele está inserido. � Através delas, um objeto colabora (ajuda)
com outros para que os objetivos do sistema sejam alcançados.
Responsabilidades e colaboradores � Na prática, uma responsabilidade é alguma
coisa que um objeto conhece ou faz. (sozinho ou não). � Um objeto Cliente conhece seu nome, seu
endereço, seu telefone, etc. � Um objeto Pedido conhece sua data de
realização e sabe fazer o cálculo do seu total. � Se um objeto tem uma responsabilidade a
qual não pode cumprir sozinho, ele deve requisitar colaborações de outros objetos.
Responsabilidades e colaboradores � Um exemplo: quando a impressão de uma
fatura é requisitada em um sistema de vendas, vários objetos precisam colaborar: � um objeto Pedido pode ter a responsabilidade
de fornecer o seu valor total � um objeto Cliente fornece seu nome � cada ItemPedido informa a quantidade
correspondente e o valor de seu subtotal � os objetos Produto também colaboraram
fornecendo seu nome e preço unitário.
Responsabilidades e colaboradores
Objetos
Colaboradores
O padrão de cooperação(comunicação) entre objetos
Responsabilidades
O que o objeto conhece+
O que o objeto faz
possuemrealizadas por
precisam de
Tipos comuns de objetos encontrados nos sistemas � Entidades;
� Value objects;
� Serviços;
� Repositórios;
� Controllers;
Camadas de um software Presentation Layer
Application Layer
Domain Layer
Infrastructure Layer
Camadas de um software � Cada camada só deve ter acesso direto
a objetos de si mesma ou de objetos em uma camada inferior;
� Em alguns casos, a camada de aplicação pode estar diretamente ligada a camada de interface com o usuário;
� A camada do domínio deve ser sempre a mais independente de todas dentro da aplicação;
Entidades � Objetos que não são definíveis apenas
através dos seus atributos; � Eles representam uma linha de
identidade que existe de forma temporal, mas que deve ser capaz de se comparar com o mesmo objeto, ainda que hajam atributos diferentes;
Modelando entidades Comparando os cheques com os pagamentos num extrato
Entidades e identidade � Em entidades, a identificação única não
deve depender somente de seus atributos, deve haver um mecanismo de se identificar se dois objetos são os mesmos independente de o que eles aparentam ser;
� Um campo identificador (como o número do cheque) pode ser adicionado ao objeto para que ele possa ser comparado no futuro;
� Essa numeração deve ser garantidamente única e imutável (como em colunas de auto-incremento no banco de dados);
Value objetcs � Nem tudo no domínio são entidades; � Value objects são objetos que
representam valores e são comparados apenas pelos seus atributos, eles não tem identidade própria;
� Eles não são necessariamente simples, mas o fato de não existir identidade faz com que seja possível reutilizar, montar caches ou pre-carregar value objects sem maiores preocupações;
Modelando value objects O Endereço é um value object?
Ao implementar value objects � Eles normalmente são imutáveis, depois
de criados, não se alteram; � É comum que sejam usados como no
padrão de projeto “Flyweight”; � Podem ser criados de forma indireta
através de fábricas (que podem implementar caching);
Services � As vezes existem conceitos dentro do seu
modelo que não são coisas, mas atividades; � Serviços servem para implementar “verbos”
que não estão cobertos por entidades ou value objects dentro do seu modelo;
� Eles são stateless, executam a sua operação mas não contém nenhum estado;
Services e layers � Serviços não existem somente na camada do
domínio, eles podem estar também na camada de aplicação e infra estrutura;
� Serviços de aplicação podem ser responsáveis por organizar os dados antes deles chegarem no domínio;
� Serviços de infra estrutura podem ser responsáveis por falar com agentes externos a aplicação, como companhias de cartão de crédito;
Modelagem de serviços Implementando as interações com vários serviços de cartão de crédito
Serviços como fronteiras � Para alguns autores, como Jacobson, existem
também os objetos de “fronteira”;
� Tais objetos são definidos por serem serviços que lidam com entidades externas ao sistema e enviam os dados para clientes;
� Esses serviços são vistos como serviços de infra estrutura;
Serviços como Fronteiras - 2 � Fronteiras seriam qualquer entidade
externa, como: � Usuários através de uma interface gráfica; � Web services; � Servidores de dados externos, como email
e bancos de dados; � Arquivos;
Módulos e Pacotes � Num mundo ideal, deve existir baixo
acoplamento entre pacotes diferentes e alta coesão dentro deles;
� Pacotes devem criar interfaces ou meios de acesso indiretos para as suas classes;
� Se você não faz parte de um pacote, não deve ficar olhando para todas as classes dele, deve haver uma fachada que faça com que você faça a sua tarefa;
Integridade referencial no domínio � É difícil garantir a integridade referencial de
um modelo quando todo mundo pode apontar pra todo mundo;
� Se uma Pessoa tem um Endereço e uma Conta aponta diretamente para o Endereço da pessoa, ao remover a Pessoa, o Endereço é removido e Conta fica apontando para o Nada;
� O uso de referências deve ser controlado de forma que as dependências sejam minimizadas;
Aggregates � É normal existir interdependências entre os
objetos do modelo, mas também é normal que alguns objetos tornem-se mais importantes do que outros;
� Se uma Conta precisa saber o Endereço de uma Pessoa, ela deve antes chegar a Pessoa e depois acessar o Endereço;
� Aggregates definem os objetos que funcionam como raízes dos relacionamentos, protegendo os objetos que são internos a eles;
Aggregates � O objeto tido como raiz é o único objeto
que pode ser referenciado por objetos que estejam “fora” do aggregate;
� Os objetos internos a raiz tem identidade própria, mas essa identidade normalmente também depende do objeto raiz, eles não existem se o objeto raiz não existir;
Modelando um carro Um Cliente tem um Carro, ou tem Pneus, Direção, Caixa de Marcha?
Repositories � Fontes de objetos raiz carregados do
mecanismo de persistência para o modelo; � Devem ser responsáveis por apenas um único
tipo de objeto, cada objeto deve ser o seu (ou seus) repositórios;
� Idealmente devem se comportar como se o cliente estivesse acessando dados em memória (não deve deixar vazar detalhes de sua implementação);
Controllers � Servem para orquestrar as chamadas
que vem de serviços de infra-estrutura até os objetos de domínio (value-objects e entidades);
� Normalmente não contém lógica de aplicação e funcionam muito mais traduzindo dados externos para os objetos do domínio;
Dúvidas?