SlideShare uma empresa Scribd logo
1 de 45
Diagrama de Classes
                                       Conceitos básicos




Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
Roteiro

• Casos de uso X AOO;

• Diagrama de classes:
   – Identificação

   – Criação

   – Abstração

                 Disciplina: Análise e Projeto de Sistemas I
                 Email para contato: marcia@imed.edu.br
Análise Orientada a Objetos

• Descreve entidades no mundo real e suas interações.

• Na OO o analista precisa:
   – Decompor o sistema em um conjunto de objetos que
     interagem entre si.




          Obs.: Todas as informações destes slides estão contidos em [1]


                    Disciplina: Análise e Projeto de Sistemas I
                    Email para contato: marcia@imed.edu.br
Análise Orientada a Objetos


• Identificando       os     Objetos:         os      objetos   são
  identificados conforme as entidades que existem em
  um determinado domínio.

• Interação: por meio de troca de mensagens.
  – Requisição de um serviço, ou

  – Reação a uma outra mensagem.


                  Disciplina: Análise e Projeto de Sistemas I
                  Email para contato: marcia@imed.edu.br
Porque utilizar a Análise Orientada a Objetos?

 O mapeamento de conceitos em entidades (objetos), torna um
    problema mais fácil de ser entendido.

 – Ex.:
                                          Entidades            Objetos



                          Pratos                                           GARÇON
                                                                    # Matricula: Int;
                                                                    + Nome: String;
                                                                    + Telefone: String;
                                      Garçons                       - Comissao: Real;
 Conceitos:                                                         + ServeMesa(Cliente);
Restaurante
                       Clientes             Aula baseada nos originais de Morais , Edison A. M.



                 Disciplina: Análise e Projeto de Sistemas I
                 Email para contato: marcia@imed.edu.br
Porque utilizar a Análise Orientada a Objetos?

Ocultamento e abstração de informações.

– Ex.:                  GARÇON
                 # Matricula: Int;
                 + Nome: String;
                 + Telefone: String;
                 - Comissao: Real;            Detalhes           sobre
                 + ServeMesa(Cliente);        implementação podem (e
                                              devem) ser ocultados
 Deve-se abstrair somente
 aquilo que é importante
 no contexto.



                                           Aula baseada nos originais de Morais , Edison A. M.



                Disciplina: Análise e Projeto de Sistemas I
                Email para contato: marcia@imed.edu.br
UML – Diagrama de classes
                Floribela                                              Antoniolo




    - Nome: Floribela                                        - Nome: Antoniolo
    - Sexo: feminino                                         - Sexo: masculino
    - Cor do cabelo: verde                                   - Cor do cabelo: preto
    - Cor da roupa: azul                                     - Cor da roupa: verde e branca
    - Cor da pele: amarela                                   - Cor da pele: marrom
    - Cor dos sapatos: vermelho                              - Cor dos sapatos: azul
    - Altura: 6cm                                            - Altura: 5,5cm
    - Humor: assustada                                       - Humor: feliz



Aula baseada nos originais de Mateus Raeder – fevereiro de 2009


                          Disciplina: Análise e Projeto de Sistemas I
                          Email para contato: marcia@imed.edu.br
UML – Diagrama de classes

 Uma classe, então, vai representar o conjunto de objetos que
  possuem determinadas características em comum


 Ao definir uma classe, então, devemos definir dois pontos
  principais:
      1 – atributos, que são informações da classe (cor do
 cabelo, sexo, altura, etc...)
        2 – métodos, que são as ações que podem ser
 realizadas       pelos      objetos    de cada classe
 (andar, correr, falar, pensar, etc...)


   Aula baseada nos originais de Mateus Raeder – fevereiro de 2009


                             Disciplina: Análise e Projeto de Sistemas I
                             Email para contato: marcia@imed.edu.br
UML – Diagrama de classes

Classe Pessoa                   Objeto Floribela    Objeto Antoniolo




                                       Floribela e Antoniolo
                                 são instâncias da classe Pessoa




                Disciplina: Análise e Projeto de Sistemas I
                Email para contato: marcia@imed.edu.br
UML – Diagrama de classes

            Pessoa                                                Nome da classe
             nome
             sexo
             cor_cabelo
             cor_roupa
                                                                   Atributos da classe
             cor_pele
             cor_sapato
             altura
             humor
             falar
             correr                                               Métodos da classe
             andar
             pensar



Aula baseada nos originais de Mateus Raeder – fevereiro de 2009


                          Disciplina: Análise e Projeto de Sistemas I
                          Email para contato: marcia@imed.edu.br
UML – Diagrama de classes
  Nome da classe                         Pessoa
                                     -nome: String
                                     -sexo: char
                                     -cor_cabelo: String
                                     +cor_roupa: String
visibilidade atributo: tipo          -cor_pele: String
                                     +cor_sapato: String
                                     -altura: double
                                     +humor: String
                                      +falar(): String
                                      +correr(): int
visibilidade método: retorno          +andar(): int
                                      +pensar()



      Visibilidade:
      - : privado (visível somente dentro da classe)
      + : público (visível por qualquer classe)
      # : protegido               Aula baseada nos originais de Mateus Raeder – fevereiro de 2009


              Disciplina: Análise e Projeto de Sistemas I
              Email para contato: marcia@imed.edu.br
Diagrama de Classes


• Descreve
  – Classes de objetos do sistema

  – Relacionamentos estáticos que existem entre elas
     • Associações (ex. Um cliente pode alugar vários filmes)

     • Subtipos (Generalização) - ( ex. Uma enfermeira é do tipo pessoa )

                                         Elementos
                                          Básicos



                 Disciplina: Análise e Projeto de Sistemas I
                 Email para contato: marcia@imed.edu.br
Diagrama de Classes

• Conceitos Avançados

   –   Estereótipos
   –   Diagramas de Objetos
   –   Operações e Atributos com escopo de Classe
   –   Classificação Múltiplica e Dinâmica
   –   Agregação e Composição
   –   Associações e Atributos Derivados
   –   Interfaces e Classes Abstratas
   –   Objetos de Referência e Objetos de Valor
   –   Coleções e Frozen
   –   Classificação e Generalização
   –   Associações Qualificadas
   –   Classes de Associações e Classes Parametrizadas
   –   Visibilidade


                     Disciplina: Análise e Projeto de Sistemas I
                     Email para contato: marcia@imed.edu.br
Perspectivas dos Diagramas de Classes



• Conceitual ou de domínio

• Especificação

• Implementação




             Disciplina: Análise e Projeto de Sistemas I
             Email para contato: marcia@imed.edu.br
Conceitual ou de domínio
• Representa os conceitos do domínio;

• Destinada ao cliente;

• Conceitos do domínio – considerado independente de
  implementação (da linguagem);

• Construído na fase de análise;

• Nesta fase deve ser dado pouco ou nenhum enfoque ao
  software.


                  Disciplina: Análise e Projeto de Sistemas I
                  Email para contato: marcia@imed.edu.br
Conceitual




             Disciplina: Análise e Projeto de Sistemas I
             Email para contato: marcia@imed.edu.br
Modelagem de Classes de Domínio (conceitual)


• O processo de criação:


   – Passo 1: Identificação das classes conceituais de domínio;



   – Passo 2: Identificação das associações relevantes entre as
     classes.



                 Disciplina: Análise e Projeto de Sistemas I
                 Email para contato: marcia@imed.edu.br
Modelo de Domínio - (conceitual)

• Para identificar as classes, o analista deve investigar:
       • Relatórios;

       • Documentos;

       • Textos;

       • Outros softwares relacionados;

       • Qualquer outro artefato que faça parte do domínio do problema.




                       Disciplina: Análise e Projeto de Sistemas I
                       Email para contato: marcia@imed.edu.br
Modelagem de Classes de Domínio

• Para criar o modelo de domínio:
   – Crie um lista de categorias de classes.

   – Ex.:

   No modelo de
  domínio pode-se
     definir um
    vocabulário
  comum sobre os
  componentes do
      sistema
                                          Fonte: Morais , Edison A. M.


                    Disciplina: Análise e Projeto de Sistemas I
                    Email para contato: marcia@imed.edu.br
Modelagem de Classes de Domínio (conceitual)


• Como criar o modelo de domínio:


  – Identifique substantivos a partir dos requisitos.




              Disciplina: Análise e Projeto de Sistemas I
              Email para contato: marcia@imed.edu.br
Modelo de Domínio (conceitual)

• Diretrizes importantes
  – 1. Use nome no singular para as classes conceituais.

  – 2. Use um nome que identifique um único objeto ao
    invés de uma coleção deles (categorias).




               Disciplina: Análise e Projeto de Sistemas I
               Email para contato: marcia@imed.edu.br
Modelo de Domínio (conceitual)

• Ex.:




   – Uma   instância      de      funcionário,        ex.    Márcia
    Rabello, trabalha para empresa, por exemplo IMED.



               Disciplina: Análise e Projeto de Sistemas I
               Email para contato: marcia@imed.edu.br
Especificação

• Foca nas principais interfaces da arquitetura;

• Principais métodos, mas não de sua implementação;

• Definir a navegabilidade entre as classes;

• Destinado    as   pessoas    que   não   necessitam     dos   detalhes   do
   desenvolvimento (gerente de projetos por exemplo)

• Neste nível novas classes podem ser definidas para a solução do
   problema;

• É definido na fase de projeto;


                      Disciplina: Análise e Projeto de Sistemas I
                      Email para contato: marcia@imed.edu.br
Especificação




                Disciplina: Análise e Projeto de Sistemas I
                Email para contato: marcia@imed.edu.br
Implementação
• Aborda detalhes da implementação:
    – Navegabilidade;

    – Atributos;

    – Tipos;

    – Métodos, etc.

• Construído na fase de implementação;

• Voltado para a equipe de desenvolvimento;

• Segundo Martin Fowler, esta é utilizada com freqüência, porém a
   perspectiva de especificação é freqüentemente a melhor para ser usada.


                        Disciplina: Análise e Projeto de Sistemas I
                        Email para contato: marcia@imed.edu.br
Implementação




                Disciplina: Análise e Projeto de Sistemas I
                Email para contato: marcia@imed.edu.br
Nomenclaturas

• A equipe pode utilizar qualquer tipo de
 nomenclatura, porém uma vez escolhida esta
 deve ser seguida.




            Disciplina: Análise e Projeto de Sistemas I
            Email para contato: marcia@imed.edu.br
Nomenclaturas
• Identificadores: espaços em branco serão removidos.

• Nomes das classes e relacionamentos: começam com letras
  maiúsculas. Ex. Cliente, ItemPedido, Pedido, Realiza, Reside, etc.



• Nome de atributos e operações: escrever a primeira palavra do
  nome do atributo em minúscula e as palavras subseqüentes em
  maiúsculas.    Ex.   quantidade,      precoUnitario,      CPF,   nome,
  dataNascimento, obterTotal, etc.

                   Disciplina: Análise e Projeto de Sistemas I
                   Email para contato: marcia@imed.edu.br
Notações

                            Classe A                                Classe B
                                           1                  1,*
• Classe   Nome               Atributos                             Atributos

           Atributos         Operações                              Operações

           Operações                            Associação
• Relacionamento

            A Tipo 1                           A Tipo 2
• Relacionamento
           Atributos                           Atributos
                        Generalização
            Operações                          Operações


                Disciplina: Análise e Projeto de Sistemas I
                Email para contato: marcia@imed.edu.br
Exemplo - Reservas


• Classes de Objetos (Algumas delas)
   – Cliente

   – Vôo

   – Categoria Vôo

   – Reservas

   – Compra


                 Disciplina: Análise e Projeto de Sistemas I
                 Email para contato: marcia@imed.edu.br
Exemplo – Reservas
                                                   Perspectiva conceitual

                                                        Voo
Cliente                   Reserva                       Numero
                                                        horaSaida
Nome          1           Data                      1   horaChegada
Fone                  *   Horario
                                        *               tempoVoo
Email                                                   AeroportoSaida
                                                        AeroportoChegada


                                    *
                                                                   *


                                                                   *
Cli Fidelid                         1
                          Compra                        Categoria
                          Data                          Nome
                          Horario                       Equivalência




                  Disciplina: Análise e Projeto de Sistemas I
                  Email para contato: marcia@imed.edu.br
Exercício


• Crie o diagrama de classes para o Sistema de
 Compra pela Internet ou conta de luz .
  – Use a perspectiva conceitual




               Disciplina: Análise e Projeto de Sistemas I
               Email para contato: marcia@imed.edu.br
Exemplo – Reservas
                                                           Perspectiva de especificação

                                                                      Voo
Cliente                             Reserva                           Numero
                                                                      horaSaida
Nome                    1           Data                          1   horaChegada
Fone                            *   Horario
                                                       *              tempoVoo
Email                                                                 AeroportoSaida
                                    total():Numeric                   AeroportoChegada
categCliente():String
                                                                      horaChegada():Time
                                              *                       tempoAtraso():Minutes
                                                                                 *
                                                      Navegabilidade

                                                                                 *
Cli Fidelid                                   1
cqtdMilhas():Integer                Compra                            Categoria
                                    Data                              Nome
                                    Horario                           Equivalência

                                                                      listarEquiv(): List
 Mais modelos                       tipoPgto():Int




                            Disciplina: Análise e Projeto de Sistemas I
                            Email para contato: marcia@imed.edu.br
Exemplo – Reservas
                                                         Perspectiva de implementação

                                    Reserva                           Voo
Cliente                         *   Data             *                Numero
                                                                      horaSaida
                                    Horario
Nome                    1                                         1   horaChegada
                                    cliente: Cliente
Fone                                                                  tempoVoo
                                    voo: Voo
Email                                                                 AeroportoSaida
                                    numero: Compra
                                                                      AeroportoChegada
categCliente():String
                                    total():Numeric                   horaChegada():Time
                                                                      tempoAtraso():Minutes
                                                                                 *
                                              *

                                                                                 *
Cli Fidelid                                   1
cqtdMilhas():Integer                Compra                            Categoria
                                    Data                              Nome
                                    Horario                           Equivalência

                                                                      listarEquiv(): List
                                    tipoPgto():Int




                            Disciplina: Análise e Projeto de Sistemas I
                            Email para contato: marcia@imed.edu.br
Exemplo – Reservas
                                      Perspectiva de implementação



• Exemplo da implementação da Classe Reserva em java:

class Reserva{

    private Cliente cliente;

    private Voo voo;

    private Compra numero;

}
             Disciplina: Análise e Projeto de Sistemas I
             Email para contato: marcia@imed.edu.br
Exercício


• Crie o diagrama de classes para o Sistema de Compra
  pela Internet ou conta de luz.
  – Use a perspectiva de especificação

  – Crie as classes em PHP5, ou java.




               Disciplina: Análise e Projeto de Sistemas I
               Email para contato: marcia@imed.edu.br
Exemplo – Reservas:                                         Regras de Restrição

                                                                               Voo
 Cliente                             Reserva                                   Numero
                                                                               horaSaida
 Nome                    1           Data                                1     horaChegada
 Fone                            *   Horario
                                                        *                      tempoVoo
 Email                                                                         AeroportoSaida
                                                                               AeroportoChegada
                                     total():Numeric
 categCliente():String
                                                                               horaChegada():Time
                                                *
                                               {se                             tempoAtraso():Minutes
                                                Reserva.cliente.categCliente                *
                                                <> Fidelidade
                                                Então prePago = sim}


                                                                                            *
 Cli Fidelid                                   1
 cqtdMilhas():Integer                Compra                                    Categoria
                                     Data                                      Nome
                                     Horario                                   Equivalência

                                                                               listarEquiv(): List
                                     tipoPgto():Int




                             Disciplina: Análise e Projeto de Sistemas I
                             Email para contato: marcia@imed.edu.br
Exercício



• Crie,   no     mínimo,         duas        regras      de
  restrições, em classes diferentes.




           Disciplina: Análise e Projeto de Sistemas I
           Email para contato: marcia@imed.edu.br
Agregação e Composição


• Agregação
  – Relacionamento “parte de”

  – “A parte pode viver sem o todo”

• Composição
  – Relacionamento “composição de”

  – “A composição não vive sem o todo”


               Disciplina: Análise e Projeto de Sistemas I
               Email para contato: marcia@imed.edu.br
Agregação e Composição


     • Exemplo
                Dependentes é parte de pessoa

                                    Pessoa                          1
                                                                        Emprego
Dependentes           *         1   Nome                    *           Nome
                                    Fone                                Area
Nome
Data de nascimento                  Email                               Salário

                                    listaEmprego():String               calculaBonus():String

             Composição
                                                            Agregação




                            Disciplina: Análise e Projeto de Sistemas I
                            Email para contato: marcia@imed.edu.br
Agregação vs Composição vs Associação


    Pessoa                                    Emprego
*   Nome                     *            1   Nome                     Associação?
    Fone                                      Area
    Email                                     Salário

    listaEmprego():String                     calculaBonus():String




     Pessoa                               1
                                               Emprego
*    Nome
     Fone
                             *                 Nome
                                               Area
                                                                       Composição?
     Email                                     Salário

     listaEmprego():String                     calculaBonus():String



    Pessoa                                1
                                              Emprego
*   Nome                     *                Nome
    Fone
    Email
                                              Area
                                              Salário
                                                                       Agregação?
    listaEmprego():String                     calculaBonus():String




                                 Disciplina: Análise e Projeto de Sistemas I
                                 Email para contato: marcia@imed.edu.br
Agregação vs Composição vs Associação


•    Dica de perguntas:
    1.       Se deletar PESSOA, tem que deletar EMPREGO/TRABALHO?
         •      se a resposta for Sim é = composição

         •      Não = pode ser agregação ou nada...

    2.       TRABALHO/EMPREGO             tem          alguma   utilidade   SOZINHO   ?


         •      Sim = associação comum

         •      Não = agregação




                            Disciplina: Análise e Projeto de Sistemas I
                            Email para contato: marcia@imed.edu.br
Corrigindo o diagrama das Reservas
                                                                   Voo
 Cliente                         * Reserva
                                                                   Numero
 Nome
                                                      *            horaSaida
                         1          Data                       1   horaChegada
 Fone                               Horario                        tempoVoo
 Email                                                             AeroportoSaida
                                                                   AeroportoChegada
                                    total():Numeric
 categCliente():String
                                                                   horaChegada():Time
                                                  *                tempoAtraso():Minutes
                                                                                *


                                                                                *
 Cli Fidelid                                  1
 cqtdMilhas():Integer               Compra                         Categoria
                                    Data                           Nome
                                    Horario                        Equivalência

                                                                   listarEquiv(): List
                                    tipoPgto():Int




                             Disciplina: Análise e Projeto de Sistemas I
                             Email para contato: marcia@imed.edu.br
Exercício


• Considerando os conceitos de agregação, composição
  e associação, corrija o seu diagrama de classes.




              Disciplina: Análise e Projeto de Sistemas I
              Email para contato: marcia@imed.edu.br
Referências

•   Dorneles, Carina F. UML Unified Modeling Language : Conceitos básicos. Passo Fundo, 2008.

•   UML Essencial: um breve guia para a linguagem-padrão de modelagem de objetos. Martin
    Fowler e Kendall Scott. 2.ed. Bookman: Porto Alegre, 2000

•   The Unified Modeling Language User Guide. Grady Booch, James Rumbaugh e Ivar
    Jacobson. Addison-Wesley, 1999.

•   Morais , Edison A. M. Engenharia de requisitos – Orientação a objetos. 2006.

•   Nogueira, F. Criação de Modelos de Domínio: Identificando Classes e Associações.

•   Raeder, Mateus. UML - Diagrama de classes. unisinos, 2009.




                           Disciplina: Análise e Projeto de Sistemas I
                           Email para contato: marcia@imed.edu.br

Mais conteúdo relacionado

Mais procurados

Introdução a poo
Introdução a pooIntrodução a poo
Introdução a pooSedu
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Luís Fernando Richter
 
Análise e Modelagem de Software
Análise e Modelagem de SoftwareAnálise e Modelagem de Software
Análise e Modelagem de SoftwareMarcelo Yamaguti
 
Aula 4 - Diagrama Entidade Relacionamento (com exercício no final)
Aula 4  - Diagrama Entidade Relacionamento (com exercício no final)Aula 4  - Diagrama Entidade Relacionamento (com exercício no final)
Aula 4 - Diagrama Entidade Relacionamento (com exercício no final)Janynne Gomes
 
Uml Diagramas Estruturais
Uml   Diagramas EstruturaisUml   Diagramas Estruturais
Uml Diagramas Estruturaisthaisedd
 
Estrutura de Dados - Aula 02 - Estrutura de Dados e TAD
Estrutura de Dados - Aula 02 - Estrutura de Dados e TADEstrutura de Dados - Aula 02 - Estrutura de Dados e TAD
Estrutura de Dados - Aula 02 - Estrutura de Dados e TADLeinylson Fontinele
 
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. CarvalhoAula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. CarvalhoRudson Kiyoshi Souza Carvalho
 
Conceitos Básicos Sobre Analise de Sistemas
Conceitos Básicos Sobre Analise de SistemasConceitos Básicos Sobre Analise de Sistemas
Conceitos Básicos Sobre Analise de SistemasClayton de Almeida Souza
 
Banco de Dados I - Aula 05 - Banco de Dados Relacional (Modelo Conceitual)
Banco de Dados I - Aula 05 - Banco de Dados Relacional (Modelo Conceitual)Banco de Dados I - Aula 05 - Banco de Dados Relacional (Modelo Conceitual)
Banco de Dados I - Aula 05 - Banco de Dados Relacional (Modelo Conceitual)Leinylson Fontinele
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geralsergiocrespo
 
Banco de Dados I - Aula 03 - Conceitos de Sistemas de Banco de Dados
Banco de Dados I - Aula 03 - Conceitos de Sistemas de Banco de DadosBanco de Dados I - Aula 03 - Conceitos de Sistemas de Banco de Dados
Banco de Dados I - Aula 03 - Conceitos de Sistemas de Banco de DadosLeinylson Fontinele
 

Mais procurados (20)

Introdução a poo
Introdução a pooIntrodução a poo
Introdução a poo
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 
Análise e Modelagem de Software
Análise e Modelagem de SoftwareAnálise e Modelagem de Software
Análise e Modelagem de Software
 
Apresentação da UML
Apresentação da UMLApresentação da UML
Apresentação da UML
 
Apostila UML
Apostila UMLApostila UML
Apostila UML
 
Aula 4 - Diagrama Entidade Relacionamento (com exercício no final)
Aula 4  - Diagrama Entidade Relacionamento (com exercício no final)Aula 4  - Diagrama Entidade Relacionamento (com exercício no final)
Aula 4 - Diagrama Entidade Relacionamento (com exercício no final)
 
Trabalho uml
Trabalho umlTrabalho uml
Trabalho uml
 
Uml Diagramas Estruturais
Uml   Diagramas EstruturaisUml   Diagramas Estruturais
Uml Diagramas Estruturais
 
Estrutura de Dados - Aula 02 - Estrutura de Dados e TAD
Estrutura de Dados - Aula 02 - Estrutura de Dados e TADEstrutura de Dados - Aula 02 - Estrutura de Dados e TAD
Estrutura de Dados - Aula 02 - Estrutura de Dados e TAD
 
UML
UMLUML
UML
 
Caso De Uso
Caso De UsoCaso De Uso
Caso De Uso
 
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. CarvalhoAula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
 
UML
UMLUML
UML
 
Diagrama de Casos de Uso
Diagrama de Casos de UsoDiagrama de Casos de Uso
Diagrama de Casos de Uso
 
Conceitos Básicos Sobre Analise de Sistemas
Conceitos Básicos Sobre Analise de SistemasConceitos Básicos Sobre Analise de Sistemas
Conceitos Básicos Sobre Analise de Sistemas
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Banco de Dados I - Aula 05 - Banco de Dados Relacional (Modelo Conceitual)
Banco de Dados I - Aula 05 - Banco de Dados Relacional (Modelo Conceitual)Banco de Dados I - Aula 05 - Banco de Dados Relacional (Modelo Conceitual)
Banco de Dados I - Aula 05 - Banco de Dados Relacional (Modelo Conceitual)
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
 
Banco de Dados I - Aula 03 - Conceitos de Sistemas de Banco de Dados
Banco de Dados I - Aula 03 - Conceitos de Sistemas de Banco de DadosBanco de Dados I - Aula 03 - Conceitos de Sistemas de Banco de Dados
Banco de Dados I - Aula 03 - Conceitos de Sistemas de Banco de Dados
 
O compilador dev c++
O compilador dev c++O compilador dev c++
O compilador dev c++
 

Aula diagrama de classes

  • 1. Diagrama de Classes Conceitos básicos Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 2. Roteiro • Casos de uso X AOO; • Diagrama de classes: – Identificação – Criação – Abstração Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 3. Análise Orientada a Objetos • Descreve entidades no mundo real e suas interações. • Na OO o analista precisa: – Decompor o sistema em um conjunto de objetos que interagem entre si. Obs.: Todas as informações destes slides estão contidos em [1] Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 4. Análise Orientada a Objetos • Identificando os Objetos: os objetos são identificados conforme as entidades que existem em um determinado domínio. • Interação: por meio de troca de mensagens. – Requisição de um serviço, ou – Reação a uma outra mensagem. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 5. Porque utilizar a Análise Orientada a Objetos? O mapeamento de conceitos em entidades (objetos), torna um problema mais fácil de ser entendido. – Ex.: Entidades Objetos Pratos GARÇON # Matricula: Int; + Nome: String; + Telefone: String; Garçons - Comissao: Real; Conceitos: + ServeMesa(Cliente); Restaurante Clientes Aula baseada nos originais de Morais , Edison A. M. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 6. Porque utilizar a Análise Orientada a Objetos? Ocultamento e abstração de informações. – Ex.: GARÇON # Matricula: Int; + Nome: String; + Telefone: String; - Comissao: Real; Detalhes sobre + ServeMesa(Cliente); implementação podem (e devem) ser ocultados Deve-se abstrair somente aquilo que é importante no contexto. Aula baseada nos originais de Morais , Edison A. M. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 7. UML – Diagrama de classes Floribela Antoniolo - Nome: Floribela - Nome: Antoniolo - Sexo: feminino - Sexo: masculino - Cor do cabelo: verde - Cor do cabelo: preto - Cor da roupa: azul - Cor da roupa: verde e branca - Cor da pele: amarela - Cor da pele: marrom - Cor dos sapatos: vermelho - Cor dos sapatos: azul - Altura: 6cm - Altura: 5,5cm - Humor: assustada - Humor: feliz Aula baseada nos originais de Mateus Raeder – fevereiro de 2009 Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 8. UML – Diagrama de classes  Uma classe, então, vai representar o conjunto de objetos que possuem determinadas características em comum  Ao definir uma classe, então, devemos definir dois pontos principais: 1 – atributos, que são informações da classe (cor do cabelo, sexo, altura, etc...) 2 – métodos, que são as ações que podem ser realizadas pelos objetos de cada classe (andar, correr, falar, pensar, etc...) Aula baseada nos originais de Mateus Raeder – fevereiro de 2009 Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 9. UML – Diagrama de classes Classe Pessoa Objeto Floribela Objeto Antoniolo Floribela e Antoniolo são instâncias da classe Pessoa Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 10. UML – Diagrama de classes Pessoa Nome da classe nome sexo cor_cabelo cor_roupa Atributos da classe cor_pele cor_sapato altura humor falar correr Métodos da classe andar pensar Aula baseada nos originais de Mateus Raeder – fevereiro de 2009 Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 11. UML – Diagrama de classes Nome da classe Pessoa -nome: String -sexo: char -cor_cabelo: String +cor_roupa: String visibilidade atributo: tipo -cor_pele: String +cor_sapato: String -altura: double +humor: String +falar(): String +correr(): int visibilidade método: retorno +andar(): int +pensar() Visibilidade: - : privado (visível somente dentro da classe) + : público (visível por qualquer classe) # : protegido Aula baseada nos originais de Mateus Raeder – fevereiro de 2009 Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 12. Diagrama de Classes • Descreve – Classes de objetos do sistema – Relacionamentos estáticos que existem entre elas • Associações (ex. Um cliente pode alugar vários filmes) • Subtipos (Generalização) - ( ex. Uma enfermeira é do tipo pessoa ) Elementos Básicos Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 13. Diagrama de Classes • Conceitos Avançados – Estereótipos – Diagramas de Objetos – Operações e Atributos com escopo de Classe – Classificação Múltiplica e Dinâmica – Agregação e Composição – Associações e Atributos Derivados – Interfaces e Classes Abstratas – Objetos de Referência e Objetos de Valor – Coleções e Frozen – Classificação e Generalização – Associações Qualificadas – Classes de Associações e Classes Parametrizadas – Visibilidade Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 14. Perspectivas dos Diagramas de Classes • Conceitual ou de domínio • Especificação • Implementação Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 15. Conceitual ou de domínio • Representa os conceitos do domínio; • Destinada ao cliente; • Conceitos do domínio – considerado independente de implementação (da linguagem); • Construído na fase de análise; • Nesta fase deve ser dado pouco ou nenhum enfoque ao software. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 16. Conceitual Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 17. Modelagem de Classes de Domínio (conceitual) • O processo de criação: – Passo 1: Identificação das classes conceituais de domínio; – Passo 2: Identificação das associações relevantes entre as classes. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 18. Modelo de Domínio - (conceitual) • Para identificar as classes, o analista deve investigar: • Relatórios; • Documentos; • Textos; • Outros softwares relacionados; • Qualquer outro artefato que faça parte do domínio do problema. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 19. Modelagem de Classes de Domínio • Para criar o modelo de domínio: – Crie um lista de categorias de classes. – Ex.: No modelo de domínio pode-se definir um vocabulário comum sobre os componentes do sistema Fonte: Morais , Edison A. M. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 20. Modelagem de Classes de Domínio (conceitual) • Como criar o modelo de domínio: – Identifique substantivos a partir dos requisitos. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 21. Modelo de Domínio (conceitual) • Diretrizes importantes – 1. Use nome no singular para as classes conceituais. – 2. Use um nome que identifique um único objeto ao invés de uma coleção deles (categorias). Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 22. Modelo de Domínio (conceitual) • Ex.: – Uma instância de funcionário, ex. Márcia Rabello, trabalha para empresa, por exemplo IMED. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 23. Especificação • Foca nas principais interfaces da arquitetura; • Principais métodos, mas não de sua implementação; • Definir a navegabilidade entre as classes; • Destinado as pessoas que não necessitam dos detalhes do desenvolvimento (gerente de projetos por exemplo) • Neste nível novas classes podem ser definidas para a solução do problema; • É definido na fase de projeto; Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 24. Especificação Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 25. Implementação • Aborda detalhes da implementação: – Navegabilidade; – Atributos; – Tipos; – Métodos, etc. • Construído na fase de implementação; • Voltado para a equipe de desenvolvimento; • Segundo Martin Fowler, esta é utilizada com freqüência, porém a perspectiva de especificação é freqüentemente a melhor para ser usada. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 26. Implementação Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 27. Nomenclaturas • A equipe pode utilizar qualquer tipo de nomenclatura, porém uma vez escolhida esta deve ser seguida. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 28. Nomenclaturas • Identificadores: espaços em branco serão removidos. • Nomes das classes e relacionamentos: começam com letras maiúsculas. Ex. Cliente, ItemPedido, Pedido, Realiza, Reside, etc. • Nome de atributos e operações: escrever a primeira palavra do nome do atributo em minúscula e as palavras subseqüentes em maiúsculas. Ex. quantidade, precoUnitario, CPF, nome, dataNascimento, obterTotal, etc. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 29. Notações Classe A Classe B 1 1,* • Classe Nome Atributos Atributos Atributos Operações Operações Operações Associação • Relacionamento A Tipo 1 A Tipo 2 • Relacionamento Atributos Atributos Generalização Operações Operações Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 30. Exemplo - Reservas • Classes de Objetos (Algumas delas) – Cliente – Vôo – Categoria Vôo – Reservas – Compra Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 31. Exemplo – Reservas Perspectiva conceitual Voo Cliente Reserva Numero horaSaida Nome 1 Data 1 horaChegada Fone * Horario * tempoVoo Email AeroportoSaida AeroportoChegada * * * Cli Fidelid 1 Compra Categoria Data Nome Horario Equivalência Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 32. Exercício • Crie o diagrama de classes para o Sistema de Compra pela Internet ou conta de luz . – Use a perspectiva conceitual Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 33. Exemplo – Reservas Perspectiva de especificação Voo Cliente Reserva Numero horaSaida Nome 1 Data 1 horaChegada Fone * Horario * tempoVoo Email AeroportoSaida total():Numeric AeroportoChegada categCliente():String horaChegada():Time * tempoAtraso():Minutes * Navegabilidade * Cli Fidelid 1 cqtdMilhas():Integer Compra Categoria Data Nome Horario Equivalência listarEquiv(): List Mais modelos tipoPgto():Int Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 34. Exemplo – Reservas Perspectiva de implementação Reserva Voo Cliente * Data * Numero horaSaida Horario Nome 1 1 horaChegada cliente: Cliente Fone tempoVoo voo: Voo Email AeroportoSaida numero: Compra AeroportoChegada categCliente():String total():Numeric horaChegada():Time tempoAtraso():Minutes * * * Cli Fidelid 1 cqtdMilhas():Integer Compra Categoria Data Nome Horario Equivalência listarEquiv(): List tipoPgto():Int Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 35. Exemplo – Reservas Perspectiva de implementação • Exemplo da implementação da Classe Reserva em java: class Reserva{ private Cliente cliente; private Voo voo; private Compra numero; } Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 36. Exercício • Crie o diagrama de classes para o Sistema de Compra pela Internet ou conta de luz. – Use a perspectiva de especificação – Crie as classes em PHP5, ou java. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 37. Exemplo – Reservas: Regras de Restrição Voo Cliente Reserva Numero horaSaida Nome 1 Data 1 horaChegada Fone * Horario * tempoVoo Email AeroportoSaida AeroportoChegada total():Numeric categCliente():String horaChegada():Time * {se tempoAtraso():Minutes Reserva.cliente.categCliente * <> Fidelidade Então prePago = sim} * Cli Fidelid 1 cqtdMilhas():Integer Compra Categoria Data Nome Horario Equivalência listarEquiv(): List tipoPgto():Int Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 38. Exercício • Crie, no mínimo, duas regras de restrições, em classes diferentes. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 39. Agregação e Composição • Agregação – Relacionamento “parte de” – “A parte pode viver sem o todo” • Composição – Relacionamento “composição de” – “A composição não vive sem o todo” Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 40. Agregação e Composição • Exemplo Dependentes é parte de pessoa Pessoa 1 Emprego Dependentes * 1 Nome * Nome Fone Area Nome Data de nascimento Email Salário listaEmprego():String calculaBonus():String Composição Agregação Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 41. Agregação vs Composição vs Associação Pessoa Emprego * Nome * 1 Nome Associação? Fone Area Email Salário listaEmprego():String calculaBonus():String Pessoa 1 Emprego * Nome Fone * Nome Area Composição? Email Salário listaEmprego():String calculaBonus():String Pessoa 1 Emprego * Nome * Nome Fone Email Area Salário Agregação? listaEmprego():String calculaBonus():String Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 42. Agregação vs Composição vs Associação • Dica de perguntas: 1. Se deletar PESSOA, tem que deletar EMPREGO/TRABALHO? • se a resposta for Sim é = composição • Não = pode ser agregação ou nada... 2. TRABALHO/EMPREGO tem alguma utilidade SOZINHO ? • Sim = associação comum • Não = agregação Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 43. Corrigindo o diagrama das Reservas Voo Cliente * Reserva Numero Nome * horaSaida 1 Data 1 horaChegada Fone Horario tempoVoo Email AeroportoSaida AeroportoChegada total():Numeric categCliente():String horaChegada():Time * tempoAtraso():Minutes * * Cli Fidelid 1 cqtdMilhas():Integer Compra Categoria Data Nome Horario Equivalência listarEquiv(): List tipoPgto():Int Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 44. Exercício • Considerando os conceitos de agregação, composição e associação, corrija o seu diagrama de classes. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br
  • 45. Referências • Dorneles, Carina F. UML Unified Modeling Language : Conceitos básicos. Passo Fundo, 2008. • UML Essencial: um breve guia para a linguagem-padrão de modelagem de objetos. Martin Fowler e Kendall Scott. 2.ed. Bookman: Porto Alegre, 2000 • The Unified Modeling Language User Guide. Grady Booch, James Rumbaugh e Ivar Jacobson. Addison-Wesley, 1999. • Morais , Edison A. M. Engenharia de requisitos – Orientação a objetos. 2006. • Nogueira, F. Criação de Modelos de Domínio: Identificando Classes e Associações. • Raeder, Mateus. UML - Diagrama de classes. unisinos, 2009. Disciplina: Análise e Projeto de Sistemas I Email para contato: marcia@imed.edu.br