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

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 5 - Modelo de Entidade e Relacionamento - MER
Aula 5 - Modelo de Entidade e Relacionamento - MER Aula 5 - Modelo de Entidade e Relacionamento - MER
Aula 5 - Modelo de Entidade e Relacionamento - MER Vitor Hugo Melo Araújo
 
Estrutura de Dados - Conceitos fundamentais
Estrutura de Dados - Conceitos fundamentaisEstrutura de Dados - Conceitos fundamentais
Estrutura de Dados - Conceitos fundamentaisFabrício Lopes Sanchez
 
Programação em Banco de Dados - Aula 23/08/2018
Programação em Banco de Dados - Aula 23/08/2018Programação em Banco de Dados - Aula 23/08/2018
Programação em Banco de Dados - Aula 23/08/2018Elaine Cecília Gatto
 
06 Modelagem de banco de dados: Modelo Lógico
06  Modelagem de banco de dados: Modelo Lógico06  Modelagem de banco de dados: Modelo Lógico
06 Modelagem de banco de dados: Modelo LógicoCentro Paula Souza
 
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
 
Conceitos de Banco de dados e SGBD
Conceitos de Banco de dados e SGBDConceitos de Banco de dados e SGBD
Conceitos de Banco de dados e SGBDVinicius Buffolo
 
Estrutura de Dados - Aula 02
Estrutura de Dados - Aula 02Estrutura de Dados - Aula 02
Estrutura de Dados - Aula 02thomasdacosta
 
Métodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - IntroduçãoMétodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - IntroduçãoYuri Morais
 
Aula 02 - Principios da Orientação a Objetos (POO)
Aula 02 - Principios da Orientação a Objetos (POO)Aula 02 - Principios da Orientação a Objetos (POO)
Aula 02 - Principios da Orientação a Objetos (POO)Daniel Brandão
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de SistemasGuilherme
 
Java: Heranca e polimorfismo
Java: Heranca e polimorfismoJava: Heranca e polimorfismo
Java: Heranca e polimorfismoArthur Emanuel
 
Lista de exercícios em portugol
Lista de exercícios em portugolLista de exercícios em portugol
Lista de exercícios em portugolGabriel Faustino
 
Aula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de AtividadeAula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de AtividadeAlberto Simões
 
Python - Programação funcional
Python - Programação funcionalPython - Programação funcional
Python - Programação funcionalfabiocerqueira
 

Mais procurados (20)

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
 
Aula 5 - Modelo de Entidade e Relacionamento - MER
Aula 5 - Modelo de Entidade e Relacionamento - MER Aula 5 - Modelo de Entidade e Relacionamento - MER
Aula 5 - Modelo de Entidade e Relacionamento - MER
 
Estrutura de Dados - Conceitos fundamentais
Estrutura de Dados - Conceitos fundamentaisEstrutura de Dados - Conceitos fundamentais
Estrutura de Dados - Conceitos fundamentais
 
Programação em Banco de Dados - Aula 23/08/2018
Programação em Banco de Dados - Aula 23/08/2018Programação em Banco de Dados - Aula 23/08/2018
Programação em Banco de Dados - Aula 23/08/2018
 
Modelagem de Dados
Modelagem de DadosModelagem de Dados
Modelagem de Dados
 
06 Modelagem de banco de dados: Modelo Lógico
06  Modelagem de banco de dados: Modelo Lógico06  Modelagem de banco de dados: Modelo Lógico
06 Modelagem de banco de dados: Modelo Lógico
 
Projeto de Software
Projeto de SoftwareProjeto de Software
Projeto de Software
 
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
 
Conceitos de Banco de dados e SGBD
Conceitos de Banco de dados e SGBDConceitos de Banco de dados e SGBD
Conceitos de Banco de dados e SGBD
 
Estrutura de Dados - Aula 02
Estrutura de Dados - Aula 02Estrutura de Dados - Aula 02
Estrutura de Dados - Aula 02
 
Métodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - IntroduçãoMétodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - Introdução
 
Aula 02 - Principios da Orientação a Objetos (POO)
Aula 02 - Principios da Orientação a Objetos (POO)Aula 02 - Principios da Orientação a Objetos (POO)
Aula 02 - Principios da Orientação a Objetos (POO)
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
 
Java: Heranca e polimorfismo
Java: Heranca e polimorfismoJava: Heranca e polimorfismo
Java: Heranca e polimorfismo
 
Lista de exercícios em portugol
Lista de exercícios em portugolLista de exercícios em portugol
Lista de exercícios em portugol
 
Paradigmas de programação
Paradigmas de programaçãoParadigmas de programação
Paradigmas de programação
 
Aula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de AtividadeAula 03 - Introdução aos Diagramas de Atividade
Aula 03 - Introdução aos Diagramas de Atividade
 
Python - Programação funcional
Python - Programação funcionalPython - Programação funcional
Python - Programação funcional
 
Aula 06 - Diagrama de classes
Aula 06 - Diagrama de classesAula 06 - Diagrama de classes
Aula 06 - Diagrama de classes
 

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