Análise de sistemas oo 1

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;

“É 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

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;

›  Conhecimentose 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;

›  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;

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
›  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;

Um diálogo de exemplo
Como desenvolvedores e clientes se comunicam

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;

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;

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;

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);

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;

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çõessão as atividades que um
objeto é capaz de executar ou as
mensagens que ele recebe;

O que é herança?

O que é herança?
Reutilizar código de uma outra classe herdando
suas propriedades e seus comportamentos

O que é polimorfismo?

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?

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
›  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;

Modelo de classes -
Implementação
›  Classes
implementadas na tecnologia
escolhida;

›  Códigoreal 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;

›  Apesardo 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
›  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

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
Nome da Direção
Papel associação de leitura

Papel

contratante Contrata contratado
Organização Indivíduo
* *

Casos especiais: Agregação
›  Losangos
definem a classe todo no
diagrama;

Afiliada membro
AssociaçãoEsportiva Equipe Jogador
* * * *

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
Emprego
salário
dataContratação

Pessoa * * Empresa
nome
razãoSocial
telefone
empregado empregador endereço
endereço

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
Projeto
Técnico 1 1
Uso nome
nome
verba

*

Computador
modelo

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;

Exemplo de associação
reflexiva
Supervisão

supervisor 1
*
Empregado
supervisionado

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
›  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.

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.

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

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
›  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);

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”;

›  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;

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;

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
›  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;

Análise de sistemas oo 1

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Análise de sistemas oo 1

Mais de Maurício Linhares

Análise de sistemas oo 1