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?