Diagrama de classes

Diagramas da UML 2.0 editar

Diagramas Estruturais Diagrama de classes Diagrama de objetos Diagrama de componentes Diagrama de instalação ou de implantação Diagrama de pacotes Diagrama de estrutura composta Diagrama de Perfil

Diagramas Comportamentais Diagrama de Caso de Uso Diagrama de transição de estados ou de Estados Diagrama de atividade Diagramas de Interação Diagrama de sequência Diagrama de Interatividade ou de Interação Diagrama de Colaboração ou Comunicação Diagrama de tempo ou Temporal

Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos.

É uma modelagem muito útil para o desenvolvimento de sistemas, pois define todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, sequência e estados.

Conceitos

• Classe: Elemento abstrato que representa um conjunto de objetos. A classe contém a especificação do objeto; suas características: atributos e métodos (ações / comportamentos).
  • Atributo: Define características da classe como:
    • Visibilidade: Pública onde outras classes podem ter acesso ao atributo. Privada o atributo somente é acessado diretamente pela própria classe e Protegida ou Pacote que é acessado pelo relacionamento da classe com a classe externa,.
    • Nome: Identificação do atributo.
    • Tipo de dados: Tipo de dado do atributo.
    • Multiplicidade: Relacionamentos.
    • Valor inicial: Depende da linguagem de programação, valor opcional.
    • Propriedade: Características do elemento, opcional.
  • Operação: Função requerida a um objeto.
    • Nome, Visibilidade e Parâmetros.
  • Associação: Relacionamentos entre classes.
    • Nome: Nome da associação.
    • Multiplicidade
    • Navegação: De onde vem as informações da classe e para onde vai.

Tipos de relacionamentos

Agregação e composição são tipos especiais de associações.

Agregação

Uma agregação representa um todo que é composto de várias partes. Exemplo: um conselho é um agregado de membros, da mesma forma que uma reunião é um agregado de uma pauta, uma sala e de participantes. A implementação deste relacionamento não é uma contenção, pois uma reunião não CONTÉM uma sala. Assim sendo, as partes da agregação podem fazer outras coisas em outras partes da aplicação, eles podem ser referenciados por outros objetos e não somente por um objeto. Em outras palavras, na implementação não há diferença entre agregação e um simples relacionamento “uses”. Nos dois casos, um objeto tem referências para outros objetos. Em UML, a agregação é representada por uma linha com um losango vazio do lado da classe que manda no relacionamento.

Composição

A composição, diferentemente da agregação, é um relacionamento de contenção. Um objeto (container) CONTÉM outros objetos (elementos). Esses elementos que estão contidos dentro de outro objeto dependem dele para existir. Eles são criados e destruídos de acordo com o seu container. Um exemplo de container poderia ser uma nota fiscal, e seus elementos seriam seus itens. Não faz sentido existirem itens de nota fiscal sem existir uma nota fiscal onde tais itens estariam contidos. Eles só existem se existir uma nota fiscal da qual eles fazem parte. Se a nota fiscal é destruída, todos os seus itens também são, o que não acontece com a agregação, onde, se uma reunião é destruída, seus participantes continuam existindo, pois podem participar de outras reuniões. A composição, na UML, é representada por uma linha com um losango preenchido do lado da classe dona do relacionamento.

Especialização ou Generalização

Também conhecida como herança, representa as dependências e hierarquias.

Exemplo

Hierarquia dos diagramas da UML, mostrados como um diagrama de classes.