Um guia abrangente para diagrama de classes UML

Exemplo de classe

Um cão tem estados – cor, nome, raça, bem como comportamentos – abanar, latir, comer. Um objeto é uma instância de uma classe.

Notação de classe UML

Uma classe representa um conceito que encapsula estado ( atributos ) e comportamento ( operações ). Cada atributo tem um tipo. Cada  operação  tem uma  assinatura . O nome da classe é a  única informação obrigatória .

Nome da classe:

• O nome da classe aparece na primeira partição.

Atributos de classe:

• Os atributos são mostrados na segunda partição.
• O tipo de atributo é mostrado após os dois pontos.
• Os atributos mapeiam em variáveis ​​de membro (membros de dados) no código.

Operações de Classe (Métodos):

• As operações são mostradas na terceira partição. São serviços que a classe oferece.
• O tipo de retorno de um método é mostrado após os dois pontos no final da assinatura do método.
• O tipo de retorno dos parâmetros do método é mostrado após os dois pontos após o nome do parâmetro. As operações mapeiam em métodos de classe no código

Relações de classe

Uma classe pode estar envolvida em um ou mais relacionamentos com outras classes. Um relacionamento pode ser um dos seguintes tipos: (Consulte a figura à direita para a representação gráfica dos relacionamentos).

Tipo de relacionamento	Representação gráfica
Herança  (ou Generalização): Representa uma relação “é-um”. Um nome de classe abstrata é mostrado em itálico. SubClass1 e SubClass2 são especializações da Super Class. Uma linha sólida com uma ponta de seta oca que aponta da classe filha para a classe pai
Associação simples : Uma ligação estrutural entre duas classes de pares. Existe uma associação entre Class1 e Class2 Uma linha sólida conectando duas classes
Agregação :Um tipo especial de associação. Representa uma “parte de” relacionamento. A classe2 faz parte da classe1. Muitas instâncias (indicadas pelo *) de Class2 podem ser associadas a Class1. Objetos de Class1 e Class2 têm tempos de vida separados. Uma linha sólida com um diamante não preenchido na extremidade da associação conectada à classe de compósito
Composição :Um tipo especial de agregação onde as partes são destruídas quando o todo é destruído. Objetos de Class2 vivem e morrem com Class1. Class2 não pode ficar sozinho. Uma linha sólida com um diamante preenchido na associação ligada à classe de compósito
Dependência : Existe entre duas classes se as mudanças na definição de uma podem causar mudanças na outra (mas não o contrário). A classe1 depende da classe2 Uma linha tracejada com uma seta aberta

Nomes de relacionamento

• Os nomes dos relacionamentos são escritos no meio da linha de associação.
• Bons nomes de relacionamentos fazem sentido quando você os lê em voz alta:
  • “Toda planilha  contém  um certo número de células”,
  • “uma expressão é  avaliada como  um valor”
• Eles geralmente têm uma  pequena ponta de seta para mostrar a direção  em que direção ler o relacionamento, por exemplo, expressões são avaliadas como valores, mas valores não são avaliados como expressões.

Relacionamento – Funções

• Uma função é um propósito direcional de uma associação.
• Os papéis são escritos nas extremidades de uma linha de associação e descrevem o propósito desempenhado por essa classe no relacionamento.
  • Por exemplo, uma célula está relacionada a uma expressão. A natureza da relação é que a expressão é a  fórmula  da célula.

Navegabilidade

As setas indicam se, dada uma instância participando de um relacionamento, é possível determinar as instâncias da outra classe que estão relacionadas a ela.

O diagrama acima sugere que,

• Dada uma planilha, podemos localizar todas as células que ela contém, mas que
  • não podemos determinar a partir de uma célula em qual planilha ela está contida.
• Dada uma célula, podemos obter a expressão e o valor relacionados, mas
  • dado um valor (ou expressão) não podemos encontrar a célula da qual esses são atributos.

Visibilidade de atributos de classe e operações

No projeto orientado a objetos, há uma notação de visibilidade para atributos e operações. A UML identifica quatro tipos de visibilidade:  public ,  protected ,  private e  package .

Os símbolos +, -, # e ~ antes de um atributo e nome de operação em uma classe denotam a visibilidade do atributo e da operação.

• + denota atributos ou operações públicas
• – denota atributos ou operações privadas
• # denota atributos ou operações protegidas
• ~ denota atributos ou operações do pacote

Exemplo de visibilidade de classe

No exemplo acima:

• attribute1 e op1 de MyClassName são públicos
• attribute3 e op3 são protegidos.
• attribute2 e op2 são privados.

O acesso para cada um desses tipos de visibilidade é mostrado abaixo para membros de diferentes classes.

Multiplicidade

Quantos objetos de cada classe fazem parte dos relacionamentos e a multiplicidade pode ser expressa como:

• Exatamente um – 1
• Zero ou um – 0..1
• Muitos – 0..* ou *
• Um ou mais – 1..*
• Número exato – por exemplo, 3..4 ou 6
• Ou uma relação complexa – por exemplo, 0..1, 3..4, 6.* significaria qualquer número de objetos diferente de 2 ou 5

Exemplo de multiplicidade

• Requisito: Um Aluno pode fazer muitos Cursos e muitos Alunos podem estar matriculados em um Curso.
• No exemplo abaixo, o  diagrama de classes  (à esquerda), descreve a declaração do requisito acima para o modelo estático, enquanto o diagrama de objetos (à direita) mostra o instantâneo (uma instância do diagrama de classes) da matrícula do curso para os cursos Engenharia de Software e Gerenciamento de Banco de Dados, respectivamente)

Exemplo de agregação – Computador e peças

• Uma agregação é um caso especial de associação que denota uma hierarquia “consiste em”
• A agregação é a classe pai, os componentes são as classes filhas

Exemplo de herança – taxonomia celular

• A herança é outro caso especial de uma associação que denota um “tipo de” hierarquia
• A herança simplifica o modelo de análise introduzindo uma taxonomia
• As classes filhas herdam os atributos e operações da classe pai.

Diagrama de Classe – Exemplo de Ferramenta de Diagrama

Um diagrama de classes também pode ter notas anexadas a classes ou relacionamentos. As notas são mostradas em cinza.

No exemplo acima:

Podemos interpretar o significado do diagrama de classes acima lendo os pontos a seguir.

1. Shape é uma classe abstrata. É mostrado em itálico.
2. Forma é uma superclasse. Círculo, Retângulo e Polígono são derivados de Forma. Em outras palavras, um Círculo é uma Forma. Esta é uma relação de generalização/herança.
3. Existe uma associação entre DialogBox e DataController.
4. A forma faz parte da janela. Esta é uma relação de agregação. Shape pode existir sem Window.
5. Ponto é parte do Círculo. Esta é uma relação de composição. Ponto não pode existir sem um Círculo.
6. A janela depende do evento. No entanto, Event não depende de Window.
7. Os atributos de Círculo são raio e centro. Esta é uma classe de entidade.
8. Os nomes dos métodos de Circle são area(), circum(), setCenter() e setRadius().
9. O parâmetro radius em Circle é um parâmetro in do tipo float.
10. O método area() da classe Circle retorna um valor do tipo double.
11. Os atributos e nomes de métodos de Rectangle estão ocultos. Algumas outras classes no diagrama também têm seus atributos e nomes de métodos ocultos.

Lidando com Sistema Complexo – Diagrama de Classes Múltiplas ou Únicas?

Inevitavelmente, se você estiver modelando um grande sistema ou uma grande área de negócios, haverá várias entidades que você deve considerar. Devemos usar vários ou um único diagrama de classes para modelar o problema? A resposta é:

• Em vez de modelar cada entidade e seus relacionamentos em um único diagrama de classes, é melhor usar vários diagramas de classes.
• Dividir um sistema em vários diagramas de classes torna o sistema mais fácil de entender, especialmente se cada diagrama for uma representação gráfica de uma parte específica do sistema.

Perspectivas do Diagrama de Classes no Ciclo de Vida de Desenvolvimento de Software

Podemos usar diagramas de classes em diferentes fases de desenvolvimento de um  ciclo de vida de desenvolvimento de software  e, normalmente, modelando diagramas de classes em três perspectivas diferentes (níveis de detalhes) progressivamente à medida que avançamos:

Perspectiva conceitual : Os diagramas são interpretados como descrevendo coisas no mundo real. Assim, se você tomar a perspectiva conceitual, você desenha um diagrama que representa os conceitos no domínio em estudo. Esses conceitos naturalmente se relacionam com as classes que os implementam. A perspectiva conceitual é  considerada independente da linguagem .

Perspectiva de especificação : Os diagramas são interpretados como descrevendo abstrações de software ou componentes com especificações e interfaces, mas sem compromisso com uma implementação específica. Assim, se você tomar a perspectiva de especificação, estamos  olhando para as interfaces do software , não para a implementação.

Perspectiva de implementação : Os diagramas são interpretados como descrevendo implementações de software em uma determinada tecnologia e  linguagem . Assim, se você tomar a perspectiva de implementação, estamos  olhando para a implementação de software .