SlideShare ist ein Scribd-Unternehmen logo
1 von 88
Downloaden Sie, um offline zu lesen
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?
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
›  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;
Dúvidas?

Weitere ähnliche Inhalte

Was ist angesagt?

Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesDomain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesiMasters
 
Domain Driven Design (DDD) - DevIsland, BH
Domain Driven Design (DDD) - DevIsland, BHDomain Driven Design (DDD) - DevIsland, BH
Domain Driven Design (DDD) - DevIsland, BHGiovanni Bassi
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisRogerio Fontes
 
Paradigmas de Programação
Paradigmas de ProgramaçãoParadigmas de Programação
Paradigmas de ProgramaçãoNatanael Simões
 
Aula 1 - Introdução a POO
Aula 1 -  Introdução a POOAula 1 -  Introdução a POO
Aula 1 - Introdução a POODaniel Brandão
 
Programação orientada à objetos & mvc
Programação orientada à objetos & mvcProgramação orientada à objetos & mvc
Programação orientada à objetos & mvcJhordam Siqueira
 
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!Flávio Lisboa
 
Algoritmos - Paradigmas de Programação
Algoritmos - Paradigmas de ProgramaçãoAlgoritmos - Paradigmas de Programação
Algoritmos - Paradigmas de ProgramaçãoElaine Cecília Gatto
 
Padrão De Projeto Adapter
Padrão De Projeto AdapterPadrão De Projeto Adapter
Padrão De Projeto AdapterMatheus Andrade
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVAMoises Omena
 
Padrão de Projeto - Adapter
Padrão de Projeto - AdapterPadrão de Projeto - Adapter
Padrão de Projeto - AdapterJuliana Cindra
 
Padrões De Projeto e Anti Patterns
Padrões De Projeto e Anti PatternsPadrões De Projeto e Anti Patterns
Padrões De Projeto e Anti PatternsHerval Freire
 
Apresentação java
Apresentação javaApresentação java
Apresentação javamunosai
 
Introdução a Padrões de Projeto
Introdução a Padrões de ProjetoIntrodução a Padrões de Projeto
Introdução a Padrões de ProjetoEduardo Mendes
 
Padrões de Projeto - Design Patterns e Anti-Patterns
Padrões de Projeto - Design Patterns e Anti-PatternsPadrões de Projeto - Design Patterns e Anti-Patterns
Padrões de Projeto - Design Patterns e Anti-PatternsRodrigo Kono
 
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de software
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de softwareAplicação de Padrões de Projeto para a melhoria da manutenabilidade de software
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de softwareCesar Rocha
 

Was ist angesagt? (20)

Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesDomain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
 
Domain Driven Design (DDD) - DevIsland, BH
Domain Driven Design (DDD) - DevIsland, BHDomain Driven Design (DDD) - DevIsland, BH
Domain Driven Design (DDD) - DevIsland, BH
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everis
 
Paradigmas de Programação
Paradigmas de ProgramaçãoParadigmas de Programação
Paradigmas de Programação
 
Aula 1 - Introdução a POO
Aula 1 -  Introdução a POOAula 1 -  Introdução a POO
Aula 1 - Introdução a POO
 
Programação orientada à objetos & mvc
Programação orientada à objetos & mvcProgramação orientada à objetos & mvc
Programação orientada à objetos & mvc
 
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
 
Algoritmos - Paradigmas de Programação
Algoritmos - Paradigmas de ProgramaçãoAlgoritmos - Paradigmas de Programação
Algoritmos - Paradigmas de Programação
 
Padrão De Projeto Adapter
Padrão De Projeto AdapterPadrão De Projeto Adapter
Padrão De Projeto Adapter
 
A Arte do Código Limpo
A Arte do Código LimpoA Arte do Código Limpo
A Arte do Código Limpo
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVA
 
DCI com PHP
DCI com PHPDCI com PHP
DCI com PHP
 
Padrão de Projeto - Adapter
Padrão de Projeto - AdapterPadrão de Projeto - Adapter
Padrão de Projeto - Adapter
 
Padrões De Projeto e Anti Patterns
Padrões De Projeto e Anti PatternsPadrões De Projeto e Anti Patterns
Padrões De Projeto e Anti Patterns
 
Uml
UmlUml
Uml
 
Apresentação java
Apresentação javaApresentação java
Apresentação java
 
Padrões de projeto
Padrões de projetoPadrões de projeto
Padrões de projeto
 
Introdução a Padrões de Projeto
Introdução a Padrões de ProjetoIntrodução a Padrões de Projeto
Introdução a Padrões de Projeto
 
Padrões de Projeto - Design Patterns e Anti-Patterns
Padrões de Projeto - Design Patterns e Anti-PatternsPadrões de Projeto - Design Patterns e Anti-Patterns
Padrões de Projeto - Design Patterns e Anti-Patterns
 
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de software
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de softwareAplicação de Padrões de Projeto para a melhoria da manutenabilidade de software
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de software
 

Andere mochten auch

Andere mochten auch (9)

Apresentação sobre DB4O
Apresentação sobre DB4OApresentação sobre DB4O
Apresentação sobre DB4O
 
Banco de dados dbo4
Banco de dados dbo4Banco de dados dbo4
Banco de dados dbo4
 
Além do java
Além do javaAlém do java
Além do java
 
The Fast, The Slow and the Lazy
The Fast, The Slow and the LazyThe Fast, The Slow and the Lazy
The Fast, The Slow and the Lazy
 
Migrando pra Scala
Migrando pra ScalaMigrando pra Scala
Migrando pra Scala
 
Conhecendo o Decorator
Conhecendo o DecoratorConhecendo o Decorator
Conhecendo o Decorator
 
Introdução ao desenvolvimento web - 2 - iDez 2010
Introdução ao desenvolvimento web - 2 - iDez 2010Introdução ao desenvolvimento web - 2 - iDez 2010
Introdução ao desenvolvimento web - 2 - iDez 2010
 
Curso java 01 - molhando os pés com java
Curso java   01 - molhando os pés com javaCurso java   01 - molhando os pés com java
Curso java 01 - molhando os pés com java
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 

Ähnlich wie Análise de sistemas oo 1

Módulo 9 - Introdução à Programação Orientada a Objectos
Módulo 9 - Introdução à Programação Orientada a Objectos Módulo 9 - Introdução à Programação Orientada a Objectos
Módulo 9 - Introdução à Programação Orientada a Objectos Luis Ferreira
 
Modelagem de sistemas
Modelagem de sistemasModelagem de sistemas
Modelagem de sistemassauloroos01
 
5507 os principais design patterns
5507   os principais design patterns5507   os principais design patterns
5507 os principais design patternsAndre Baltieri
 
Apresentação versão 1.5
Apresentação   versão 1.5Apresentação   versão 1.5
Apresentação versão 1.5oliveiraprog
 
Net uma revisão sobre a programação orientada a objetos
Net   uma revisão sobre a programação orientada a objetosNet   uma revisão sobre a programação orientada a objetos
Net uma revisão sobre a programação orientada a objetosLP Maquinas
 
3 oo-concepts
3 oo-concepts3 oo-concepts
3 oo-conceptsjorge600
 
Reutilização
ReutilizaçãoReutilização
Reutilizaçãoemjorge
 
Poo apostila visual c
Poo apostila visual cPoo apostila visual c
Poo apostila visual cFabiano Lima
 
Apresentação Introdução Design Patterns
Apresentação Introdução Design PatternsApresentação Introdução Design Patterns
Apresentação Introdução Design PatternsLucas Simões Maistro
 
Test driven development
Test driven developmentTest driven development
Test driven developmentclauvane1708
 
ALM - Testes Exploratórios
ALM - Testes ExploratóriosALM - Testes Exploratórios
ALM - Testes ExploratóriosAlan Carlos
 
DDD e PHP - TDC 2012
DDD e PHP - TDC 2012DDD e PHP - TDC 2012
DDD e PHP - TDC 2012Luís Cobucci
 

Ähnlich wie Análise de sistemas oo 1 (20)

Módulo 9 - Introdução à Programação Orientada a Objectos
Módulo 9 - Introdução à Programação Orientada a Objectos Módulo 9 - Introdução à Programação Orientada a Objectos
Módulo 9 - Introdução à Programação Orientada a Objectos
 
Modelagem de sistemas
Modelagem de sistemasModelagem de sistemas
Modelagem de sistemas
 
5507 os principais design patterns
5507   os principais design patterns5507   os principais design patterns
5507 os principais design patterns
 
3 oo-concepts
3 oo-concepts3 oo-concepts
3 oo-concepts
 
Apresentação versão 1.5
Apresentação   versão 1.5Apresentação   versão 1.5
Apresentação versão 1.5
 
Net uma revisão sobre a programação orientada a objetos
Net   uma revisão sobre a programação orientada a objetosNet   uma revisão sobre a programação orientada a objetos
Net uma revisão sobre a programação orientada a objetos
 
3 oo-concepts
3 oo-concepts3 oo-concepts
3 oo-concepts
 
Reutilização
ReutilizaçãoReutilização
Reutilização
 
Apresentação faef
Apresentação faefApresentação faef
Apresentação faef
 
Poo apostila visual c
Poo apostila visual cPoo apostila visual c
Poo apostila visual c
 
Sld 4
Sld 4Sld 4
Sld 4
 
Padrões de design orientado a objetos
Padrões de design orientado a objetosPadrões de design orientado a objetos
Padrões de design orientado a objetos
 
Apresentação Introdução Design Patterns
Apresentação Introdução Design PatternsApresentação Introdução Design Patterns
Apresentação Introdução Design Patterns
 
Test driven development
Test driven developmentTest driven development
Test driven development
 
Feature Driven Development
Feature Driven DevelopmentFeature Driven Development
Feature Driven Development
 
ALM - Testes Exploratórios
ALM - Testes ExploratóriosALM - Testes Exploratórios
ALM - Testes Exploratórios
 
Naked Objects
Naked ObjectsNaked Objects
Naked Objects
 
DDD e PHP - TDC 2012
DDD e PHP - TDC 2012DDD e PHP - TDC 2012
DDD e PHP - TDC 2012
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
 
Aula 01 introdução aoo
Aula 01   introdução aooAula 01   introdução aoo
Aula 01 introdução aoo
 

Mehr von Maurício Linhares

Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop
Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDropUnindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop
Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDropMaurício Linhares
 
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDropMixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDropMaurício Linhares
 
Curso java 08 - mais sobre coleções
Curso java   08 - mais sobre coleçõesCurso java   08 - mais sobre coleções
Curso java 08 - mais sobre coleçõesMaurício Linhares
 
Curso java 06 - mais construtores, interfaces e polimorfismo
Curso java   06 - mais construtores, interfaces e polimorfismoCurso java   06 - mais construtores, interfaces e polimorfismo
Curso java 06 - mais construtores, interfaces e polimorfismoMaurício Linhares
 
Curso java 05 - herança, classes e métodos abstratos
Curso java   05 - herança, classes e métodos abstratosCurso java   05 - herança, classes e métodos abstratos
Curso java 05 - herança, classes e métodos abstratosMaurício Linhares
 
Curso java 04 - ap is e bibliotecas
Curso java   04 - ap is e bibliotecasCurso java   04 - ap is e bibliotecas
Curso java 04 - ap is e bibliotecasMaurício Linhares
 
Curso java 03 - métodos e parâmetros
Curso java   03 - métodos e parâmetrosCurso java   03 - métodos e parâmetros
Curso java 03 - métodos e parâmetrosMaurício Linhares
 
Outsourcing e trabalho remoto para a nuvem
Outsourcing e trabalho remoto para a nuvemOutsourcing e trabalho remoto para a nuvem
Outsourcing e trabalho remoto para a nuvemMaurício Linhares
 
Aulas de Java Avançado 2- Faculdade iDez 2010
Aulas de Java Avançado 2- Faculdade iDez 2010Aulas de Java Avançado 2- Faculdade iDez 2010
Aulas de Java Avançado 2- Faculdade iDez 2010Maurício Linhares
 
Aulas de Java Avançado 1 - Faculdade iDez 2010
Aulas de Java Avançado 1 - Faculdade iDez 2010Aulas de Java Avançado 1 - Faculdade iDez 2010
Aulas de Java Avançado 1 - Faculdade iDez 2010Maurício Linhares
 
Projeto e desenvolvimento de sistemas de informação 4 - computação em rede
Projeto e desenvolvimento de sistemas de informação   4 - computação em redeProjeto e desenvolvimento de sistemas de informação   4 - computação em rede
Projeto e desenvolvimento de sistemas de informação 4 - computação em redeMaurício Linhares
 

Mehr von Maurício Linhares (20)

Mercado de TI
Mercado de TIMercado de TI
Mercado de TI
 
Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop
Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDropUnindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop
Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDrop
 
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDropMixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDrop
 
Aprendendo ruby
Aprendendo rubyAprendendo ruby
Aprendendo ruby
 
Curso java 07 - exceções
Curso java   07 - exceçõesCurso java   07 - exceções
Curso java 07 - exceções
 
Curso java 08 - mais sobre coleções
Curso java   08 - mais sobre coleçõesCurso java   08 - mais sobre coleções
Curso java 08 - mais sobre coleções
 
Curso java 06 - mais construtores, interfaces e polimorfismo
Curso java   06 - mais construtores, interfaces e polimorfismoCurso java   06 - mais construtores, interfaces e polimorfismo
Curso java 06 - mais construtores, interfaces e polimorfismo
 
Curso java 05 - herança, classes e métodos abstratos
Curso java   05 - herança, classes e métodos abstratosCurso java   05 - herança, classes e métodos abstratos
Curso java 05 - herança, classes e métodos abstratos
 
Curso java 04 - ap is e bibliotecas
Curso java   04 - ap is e bibliotecasCurso java   04 - ap is e bibliotecas
Curso java 04 - ap is e bibliotecas
 
Curso java 02 - variáveis
Curso java   02 - variáveisCurso java   02 - variáveis
Curso java 02 - variáveis
 
Curso java 03 - métodos e parâmetros
Curso java   03 - métodos e parâmetrosCurso java   03 - métodos e parâmetros
Curso java 03 - métodos e parâmetros
 
Outsourcing e trabalho remoto para a nuvem
Outsourcing e trabalho remoto para a nuvemOutsourcing e trabalho remoto para a nuvem
Outsourcing e trabalho remoto para a nuvem
 
Mercado hoje
Mercado hojeMercado hoje
Mercado hoje
 
Revisão html e java script
Revisão html e java scriptRevisão html e java script
Revisão html e java script
 
Aulas de Java Avançado 2- Faculdade iDez 2010
Aulas de Java Avançado 2- Faculdade iDez 2010Aulas de Java Avançado 2- Faculdade iDez 2010
Aulas de Java Avançado 2- Faculdade iDez 2010
 
Aulas de Java Avançado 1 - Faculdade iDez 2010
Aulas de Java Avançado 1 - Faculdade iDez 2010Aulas de Java Avançado 1 - Faculdade iDez 2010
Aulas de Java Avançado 1 - Faculdade iDez 2010
 
Projeto e desenvolvimento de sistemas de informação 4 - computação em rede
Projeto e desenvolvimento de sistemas de informação   4 - computação em redeProjeto e desenvolvimento de sistemas de informação   4 - computação em rede
Projeto e desenvolvimento de sistemas de informação 4 - computação em rede
 
Extreme programming explicada
Extreme programming explicadaExtreme programming explicada
Extreme programming explicada
 
Jdbc e hibernate
Jdbc e hibernateJdbc e hibernate
Jdbc e hibernate
 
Java wsdp
Java wsdpJava wsdp
Java wsdp
 

Análise de sistemas oo 1

  • 1. Análise de Sistemas OO - 1 Maurício Linhares
  • 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
  • 4. Modelando um simulador de rotas de rede Pense nos atores e nas atividades
  • 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;
  • 11. Implementando cargas, viagens e overbooking Construindo um modelo rico em conhecimento
  • 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! $$$!
  • 15. Escreva a funcionalidade que você deve implementar Como começar?
  • 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"
  • 26. Como implementar Settlers of Catan? Crie uma lista de requisitos que defina o jogo. Trivial, claro.
  • 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
  • 33. O que é encapsulamento? Reencontrando a orientação a objetos
  • 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;
  • 40. Exemplo de classes num diagrama de classes
  • 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;
  • 46. Notação para associações entre objetos Hóspede Quarto ContaCorrente HistóricoTransações Cliente Produto
  • 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
  • 49. Notação para associações com cardinalidade Cliente Pedido 1 0..*
  • 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
  • 57. Outros exemplos de classes associativas? Pense.
  • 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;
  • 61. Exemplo de associação reflexiva Supervisão supervisor 1 * Empregado supervisionado
  • 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;
  • 71. Modelando entidades Comparando os cheques com os pagamentos num extrato
  • 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;
  • 74. Modelando value objects O Endereço é um value object?
  • 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;
  • 78. Modelagem de serviços Implementando as interações com vários serviços 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;
  • 85. Modelando um carro Um Cliente tem um Carro, ou tem Pneus, Direção, Caixa de Marcha?
  • 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;