2. 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
3. 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
5. 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;
6. 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;
7. “É 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.”
Eric Evans, Domain Driven
Design, página 13
8. 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;
9. 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;
10. Aprendizado contínuo
› Programar
é definir uma teoria, em
código, que representa elementos no
mundo real;
› Conhecimentose fragmenta, se torna
obsoleto ou representa entidades de
pouca importância, é necessário
continuar aprendendo;
12. 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;
13. 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.
14. 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! $$$!
16. Tudo começa com os
requisitos
› Ouça o que o cliente deseja que o sistema
faça;
› Tenteusar 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;
17. 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;
18. A linguagem Ubíqua
› Desenvolvedorese 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;
19. Um diálogo de exemplo
Como desenvolvedores e clientes se comunicam
20. Conhecimento sendo
passado pela fala
› Oseu 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;
21. Ah, mas o cliente não
entende de objetos!
› Nemvocê 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;
22. Documentos, diagramas,
modelos visuais
› Nãose 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;
23. 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;
› DiagramasNÃO SÃO O SEU PRODUTO (na
maior parte das vezes);
24. Passo a passo
› Reúnaos 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;
25. 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"
27. O que é uma classe?
Reencontrando a orientação a objetos
28. 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çõessão as atividades que um
objeto é capaz de executar ou as
mensagens que ele recebe;
29. O que é herança?
Reencontrando a orientação a objetos
30. O que é herança?
Reutilizar código de uma outra classe herdando
suas propriedades e seus comportamentos
31. O que é polimorfismo?
Reencontrando a orientação a objetos
32. 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
34. 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.
35. O que são composição e
agregação?
Revisando orientação a objetos
36. 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.
37. Objetos devem fazer ou
representar uma coisa e
somente isso. Se o Bolo é
comida, vai ser sempre
comida.
Responsabilidade
38. 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;
39. 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;
41. 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;
42. Modelo de classes -
Especificação
› Adicionadetalhes da implementação
que foi escolhida ao modelo (interfaces
de infraestrutura, classes base de
frameworks, funcionalidades da
linguagem);
› Normalmentedefinido antes de se entrar
em detalhes de implementação;
43. Modelo de classes -
Implementação
› Classes
implementadas na tecnologia
escolhida;
› Códigoreal e executável, normalmente
gerado inicialmente através dos modelos
definidos anteriormente;
44. 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;
45. Associações no modelo
› Objetos estão sempre se relacionando
entre si, esses relacionamentos são
chamados de associações;
› Apesardo modelo ser um modelo de
classes, as associações são para os
objetos dessas classes;
47. 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..*”;
48. 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
50. Cardinalidade na fórmula 1
› Corridastem 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
51. 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;
52. 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;
53. Exemplo de associação
Nome da Direção
Papel associação de leitura
Papel
contratante Contrata contratado
Organização Indivíduo
* *
54. Casos especiais: Agregação
› Losangos
definem a classe todo no
diagrama;
Afiliada membro
AssociaçãoEsportiva Equipe Jogador
* * * *
55. 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;
56. Exemplo de modelo com
classe associativa
Emprego
salário
dataContratação
Pessoa * * Empresa
nome
razãoSocial
telefone
empregado empregador endereço
endereço
58. 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;
59. Associação ternária
Projeto
Técnico 1 1
Uso nome
nome
verba
*
Computador
modelo
60. Associações reflexivas
› Associações
onde um objeto se associa a
outros objetos da mesma classe;
› Cadaobjeto tem um papel diferente na
associação, de forma que eles sejam
diferenciáveis;
62. Crie os diagramas de
associação entre os objetos
da loja
Lembre-se de adicionar as cardinalidades e os
nomes das associações.
63. 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.
64. Responsabilidades e
colaboradores
› Naprá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.
65. Responsabilidades e
colaboradores
› Umexemplo: 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.
66. Responsabilidades e
colaboradoresObjetos
possuem
realizadas por
Responsabilidades Colaboradores
O que o objeto conhece O padrão de cooperação
+ (comunicação) entre objetos
O que o objeto faz
precisam de
67. Tipos comuns de objetos
encontrados nos sistemas
› Entidades;
› Value objects;
› Serviços;
› Repositórios;
› Controllers;
68. Camadas de um software
Presentation Layer
Application Layer
Domain Layer
Infrastructure Layer
69. 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;
70. 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;
72. 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);
73. 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;
75. Ao implementar value objects
› Elesnormalmente 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);
76. 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;
77. 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;
79. Serviços como fronteiras
› Para
alguns autores, como Jacobson, existem
também os objetos de “fronteira”;
› Taisobjetos são definidos por serem serviços
que lidam com entidades externas ao
sistema e enviam os dados para clientes;
› Essesserviços são vistos como serviços de
infra estrutura;
80. Serviços como Fronteiras - 2
› Fronteiras
seriam qualquer entidade
externa, como:
› Usuáriosatravés de uma interface gráfica;
› Web services;
› Servidores de dados externos, como email
e bancos de dados;
› Arquivos;
81. 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;
82. 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;
83. 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;
84. 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;
86. 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);
87. Controllers
› Servempara 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;