Diagrama de classes - Class diagram

Hierarquia de diagramas UML 2.5, mostrado como um diagrama de classes. As classes individuais são representadas apenas com um compartimento, mas geralmente contêm até três compartimentos.

Na engenharia de software , um diagrama de classes na Unified Modeling Language (UML) é um tipo de diagrama de estrutura estática que descreve a estrutura de um sistema, mostrando as classes do sistema , seus atributos, operações (ou métodos) e os relacionamentos entre os objetos.

O diagrama de classes é o principal bloco de construção da modelagem orientada a objetos . É usado para modelagem conceitual geral da estrutura do aplicativo e para modelagem detalhada, traduzindo os modelos em código de programação . Os diagramas de classes também podem ser usados ​​para modelagem de dados . As classes em um diagrama de classes representam os elementos principais, as interações no aplicativo e as classes a serem programadas.

No diagrama, as classes são representadas com caixas que contêm três compartimentos:

  • O compartimento superior contém o nome da classe. Está impresso em negrito e centralizado, e a primeira letra em maiúscula.
  • O compartimento do meio contém os atributos da classe. Eles são alinhados à esquerda e a primeira letra é minúscula.
  • O compartimento inferior contém as operações que a classe pode executar. Eles também são alinhados à esquerda e a primeira letra é minúscula.
Uma aula com três compartimentos.

No projeto de um sistema, várias classes são identificadas e agrupadas em um diagrama de classes que ajuda a determinar as relações estáticas entre elas. Na modelagem detalhada, as classes do projeto conceitual são freqüentemente divididas em subclasses.

Para descrever melhor o comportamento dos sistemas, esses diagramas de classes podem ser complementados por um diagrama de estado ou máquina de estado UML .

Membros

A UML fornece mecanismos para representar os membros da classe, como atributos e métodos, e informações adicionais sobre eles como construtores.

Visibilidade

Para especificar a visibilidade de um membro da classe (ou seja, qualquer atributo ou método), essas notações devem ser colocadas antes do nome do membro:

+ Público
- Privado
# Protegido
~ Pacote

Uma propriedade derivada é uma propriedade cujo valor (ou valores) é produzido ou calculado a partir de outras informações, por exemplo, usando valores de outras propriedades.

Uma propriedade derivada é mostrada com seu nome precedido por uma barra '/'.

Alcance

A UML especifica dois tipos de escopo para membros: instância e classe , e a última é representada por nomes sublinhados .

  • Os membros da instância têm como escopo uma instância específica.
    • Os valores dos atributos podem variar entre as instâncias
    • A invocação do método pode afetar o estado da instância (ou seja, alterar os atributos da instância)
  • Os membros da classe são comumente reconhecidos como “estáticos” em muitas linguagens de programação. O escopo é a própria classe.
    • Os valores dos atributos são iguais para todas as instâncias
    • A invocação do método não afeta o estado do classificador

Para indicar um escopo de classificador para um membro, seu nome deve ser sublinhado. Caso contrário, o escopo da instância é assumido por padrão.

Relacionamentos

Notação de relações UML

Um relacionamento é um termo geral que cobre os tipos específicos de conexões lógicas encontradas em diagramas de classes e objetos. UML define os seguintes relacionamentos:

Relacionamentos em nível de instância

Dependência

Uma dependência é uma conexão semântica entre elementos de modelo dependentes e independentes. Ele existe entre dois elementos se as alterações na definição de um elemento (o servidor ou destino) podem causar alterações no outro (o cliente ou fonte). Esta associação é unidirecional. Uma dependência é exibida como uma linha tracejada com uma seta aberta que aponta do cliente para o fornecedor.

Associação

Exemplo de diagrama de classes de associação entre duas classes

Uma associação representa uma família de links. Uma associação binária (com duas extremidades) é normalmente representada como uma linha. Uma associação pode vincular qualquer número de classes. Uma associação com três links é chamada de associação ternária. Uma associação pode ser nomeada e as extremidades de uma associação podem ser adornadas com nomes de funções, indicadores de propriedade, multiplicidade, visibilidade e outras propriedades.
Existem quatro tipos diferentes de associação: bidirecional, unidirecional, agregação (inclui agregação de composição) e reflexiva. As associações bidirecionais e unidirecionais são as mais comuns.
Por exemplo, uma classe de vôo está associada a uma classe de avião bidirecionalmente. Associação representa o relacionamento estático compartilhado entre os objetos de duas classes.

Agregação

Diagrama de classes mostrando a agregação entre duas classes. Aqui, um Professor 'tem uma' aula para dar.

A agregação é uma variante do relacionamento de associação "tem um"; a agregação é mais específica do que a associação. É uma associação que representa um relacionamento parte-todo ou parte-de. Conforme mostrado na imagem, um Professor 'tem' uma aula para dar. Como um tipo de associação, uma agregação pode ser nomeada e ter os mesmos adornos que uma associação. No entanto, uma agregação não pode envolver mais de duas classes; deve ser uma associação binária. Além disso, dificilmente há uma diferença entre agregações e associações durante a implementação, e o diagrama pode ignorar as relações de agregação completamente.

A agregação pode ocorrer quando uma classe é uma coleção ou contêiner de outras classes, mas as classes contidas não têm uma forte dependência do ciclo de vida do contêiner. O conteúdo do contêiner ainda existe quando o contêiner é destruído.

Na UML , ele é representado graficamente como uma forma de diamante oco na classe contida com uma única linha que o conecta à classe contida. O agregado é semanticamente um objeto estendido que é tratado como uma unidade em muitas operações, embora fisicamente seja feito de vários objetos menores.

Exemplo: Biblioteca e alunos. Aqui o aluno pode existir sem biblioteca, a relação entre aluno e biblioteca é de agregação.

Composição

Dois diagramas de classes. O diagrama acima mostra a composição entre duas classes: um carro tem exatamente um carburador e um carburador é parte de um carro. Os carburadores não podem existir como peças separadas, destacadas de um carro específico. O diagrama na parte inferior mostra a agregação entre duas classes: Um Lago tem zero ou mais Patos e um Pato tem no máximo um Lago (por vez). O pato pode existir separadamente de uma lagoa, por exemplo, pode viver perto de um lago. Quando destruímos uma lagoa, geralmente não matamos todos os patos.

A representação UML de um relacionamento de composição mostra a composição como uma forma de losango preenchido no final da classe contida das linhas que conectam a (s) classe (s) contida (s) à classe contida.

Diferenças entre composição e agregação

Relação de composição
1. Ao tentar representar relacionamentos do mundo real entre todo e parte, por exemplo, um motor é uma parte de um carro.
2. Quando o contêiner é destruído, o conteúdo também é destruído, por exemplo, uma universidade e seus departamentos.
Relação de agregação
1. Ao representar um relacionamento de software ou banco de dados, por exemplo, o motor do modelo de carro ENG01 faz parte de um modelo de carro CM01, pois o motor, ENG01, também pode fazer parte de um modelo de carro diferente.
2. Quando o recipiente é destruído, o conteúdo geralmente não é destruído, por exemplo, um professor tem alunos; quando o professor morre, os alunos não morrem junto com eles.

Assim, a relação de agregação é freqüentemente uma contenção de "catálogo" para distingui-la da contenção "física" da composição.

Relações em nível de classe

Generalização / Herança

Diagrama de classes mostrando a generalização entre a superclasse Person e as duas subclasses Student e Professor

Isso indica que uma das duas classes relacionadas (a subclasse ) é considerada uma forma especializada da outra (o supertipo ) e a superclasse é considerada uma Generalização da subclasse. Na prática, isso significa que qualquer instância do subtipo também é uma instância da superclasse. Uma árvore exemplar de generalizações dessa forma é encontrada na classificação biológica : os humanos são uma subclasse do símio , que é uma subclasse do mamífero e assim por diante. A relação é mais facilmente compreendida pela frase 'um A é um B' (um humano é um mamífero, um mamífero é um animal).

A representação gráfica UML de uma generalização é uma forma de triângulo oco na extremidade da superclasse da linha (ou árvore de linhas) que a conecta a um ou mais subtipos.

O relacionamento de generalização também é conhecido como relacionamento de herança ou "é um" .

A superclasse (classe base) no relacionamento de generalização também é conhecida como "pai" , superclasse , classe base ou tipo base .

O subtipo em relação a especialização também é conhecido como o "criança" , subclasse , classe derivada , tipo derivado , herdar classe , ou herdar tipo .

Observe que esse relacionamento não tem nenhuma semelhança com o relacionamento biológico pai-filho: o uso desses termos é extremamente comum, mas pode ser enganoso.

A é um tipo de B
Por exemplo, "um carvalho é um tipo de árvore", "um automóvel é um tipo de veículo"

A generalização só pode ser mostrada em diagramas de classes e diagramas de casos de uso .

Realização / Implementação

Na modelagem UML, um relacionamento de realização é um relacionamento entre dois elementos do modelo, no qual um elemento do modelo (o cliente) percebe (implementa ou executa) o comportamento que o outro elemento do modelo (o fornecedor) especifica.

A representação gráfica UML de uma Realização é uma forma de triângulo oco na extremidade da interface da linha tracejada (ou árvore de linhas) que a conecta a um ou mais implementadores. Uma ponta de seta simples é usada na extremidade da interface da linha tracejada que a conecta aos usuários. Em diagramas de componentes, a convenção gráfica de bola e soquete é usada (os implementadores expõem uma bola ou pirulito, enquanto os usuários mostram um soquete). As realizações só podem ser mostradas em diagramas de classes ou componentes. Uma realização é um relacionamento entre classes, interfaces, componentes e pacotes que conecta um elemento cliente a um elemento fornecedor. Uma relação de realização entre classes / componentes e interfaces mostra que a classe / componente realiza as operações oferecidas pela interface.

          symbolic of realization                   -------▻

Relacionamento geral

Diagrama de classes mostrando a dependência entre a classe "Carro" e a classe "Roda" (um exemplo ainda mais claro seria "Carro depende da roda", porque Carro já agrega (e não apenas usa ) Roda)

Dependência

Dependência é uma forma mais fraca de vínculo que indica que uma classe depende de outra porque a usa em algum momento. Uma classe depende da outra se a classe independente for uma variável de parâmetro ou variável local de um método da classe dependente. Isso é diferente de uma associação, em que um atributo da classe dependente é uma instância da classe independente. Às vezes, a relação entre duas classes é muito fraca. Eles não são implementados com variáveis ​​de membro. Em vez disso, eles podem ser implementados como argumentos de função de membro.

Multiplicidade

Essa relação de associação indica que (pelo menos) uma das duas classes relacionadas faz referência à outra. Essa relação é geralmente descrita como "A tem um B" (uma mãe gata tem gatinhos, os gatinhos têm uma mãe gata).

A representação UML de uma associação é uma linha que conecta as duas classes associadas. Em cada extremidade da linha existe uma notação opcional. Por exemplo, podemos indicar, usando uma ponta de seta, que a extremidade pontiaguda é visível a partir da cauda da seta. Podemos indicar a propriedade pela colocação de uma bola, o papel que os elementos desse final desempenham, fornecendo um nome para o papel e a multiplicidade de instâncias dessa entidade (a gama de número de objetos que participam da associação da perspectiva da outra extremidade).

0 Sem instâncias (raro)
0..1 Nenhuma instância ou uma instância
1 Exatamente uma instância
1..1 Exatamente uma instância
0 .. * Zero ou mais instâncias
* Zero ou mais instâncias
1 .. * Uma ou mais instâncias

Estereótipos de análise

EntityControlBoundary Pattern.jpg

Entidades

As classes de entidade modelam informações de longa duração manipuladas pelo sistema e, às vezes, o comportamento associado às informações. Eles não devem ser identificados como tabelas de banco de dados ou outros armazenamentos de dados.

Eles são desenhados como círculos com uma linha curta anexada à parte inferior do círculo. Como alternativa, eles podem ser desenhados como classes normais com a notação de estereótipo «entidade» acima do nome da classe.

Veja também

Diagramas relacionados

Referências

links externos