MODELAGEM DE SISTEMAS

DIAGRAMA DE CLASSES

-1-
Olá!
Bom dia!

Um dos diagramas de maior relevância dentro do contexto da orientação a objeto é o modelo de classes, que visa

apresentar as classes do sistema, com suas estruturas (atributos e métodos) e os relacionamentos entre as

classes.

A técnica adotada nesta aula pressupõe a existência do diagrama de casos de uso e as descrições textuais de cada

caso de uso, de onde serão derivadas as classes do negócio.

O modelo de classes vai sendo refinado e acrescido de outras classes, até chegar ao nível em que conterá as

classes a serem implementadas na linguagem de programação, dando forma ao sistema que fora elaborado,

paulatinamente, usando e refinando diversos diagramas da UML.

É desse assunto que trataremos nesta aula. Bons estudos!

Objetivos

•Distinguir os elementos do diagrama de classes;

•Reconhecer os possíveis relacionamentos entre as classes;

•Aplicar como se deriva o diagrama de classes a partir do diagrama e especificações de casos de uso.

Conceitos de diagrama de classes

O diagrama de classes é considerado por muitos o principal diagrama da UML, sendo também o mais

amplamente usado por aqueles que usam a UML na modelagem de seus sistemas orientados a objetos.

Existem vários níveis de diagramas de classes, que são usados no nível de domínio — conceitual — e de

projeto.

Nesta aula, vamos inicialmente abordar o diagrama de classes a partir da observação do mundo real para

um determinado contexto. Vamos construir o diagrama em nível de domínio, ou ainda, o chamado modelo

conceitual de classes.

Para começarmos , atente-se para a seguinte informação, referente ao diagrama conceitual de classes:

Não se devem representar estruturas de projeto (interfaces, chaves, arquivos, campos etc.). O foco da análise

é o negócio.

Modelo conceitual de classes

Com base no que vimos, podemos conhecer o modelo conceitual de classes.

-2-
Esse modelo usa os elementos mais básicos do diagrama de classes, pois a finalidade é representar os

objetos tal qual existem no mundo real, sem inserir aspectos de projeto ou de implementação no modelo.

Assim, o diagrama de classes descreve, de forma gráfica, os tipos de objetos que interagem para realizar as

funcionalidades previstas em um sistema, bem como os vários tipos de relacionamentos estáticos entre

eles. O diagrama de classes mostra, ainda, as propriedades e operações de uma classe e as restrições

relacionadas à forma como os objetos se relacionam.

A evolução do diagrama de classes

O diagrama de classes evolui à medida que o projeto avança. Observe esse processo através do esquema a

seguir:

Fase de projeto

Nessa fase, o mesmo diagrama de classes pode ser refinado com a inserção de:
• Multiplicidades e papéis;
• Relacionamento entre as classes;
• Novos métodos (como, por exemplo, get, set e formatações);
• Novos atributos;
• Parâmetros nas chamadas dos métodos;
• Visibilidade dos atributos e métodos;
• Novas classes, chamadas de classes de projeto (como representação de persistência).
Fase de implementação

Durante a implementação (codificação na linguagem), novas classes podem surgir, como classes que

implementem determinada característica da linguagem de programação ou determinada forma de

programar. É o diagrama de classes de implementação.

Fase de análise – 1º momento

Inicialmente, em sua primeira versão, na fase de análise, o diagrama apresenta as classes do negócio (também

chamada de entidades) e chama-se diagrama de classes conceitual.

-3-
Esse é um diagrama compatível com as funcionalidades dos casos de uso, ou seja, mostra a modelagem em

classes dos requisitos essenciais do sistema.

Fase de análise – 2º momento

Num segundo momento, ainda na fase de análise, novas classes podem ser inseridas no diagrama de classes,

como as de controle e as de interface (ou fronteira).

Classe de fronteira (boundary) ou interface: responsável pela interação com os atores. Exemplo: para

representar um formulário, para representar a interface com outro equipamento (um acionador de cancelas de

entrada e saída de veículos, por exemplo);

Classes de controle: responsável pela coordenação da interação entre os objetos, na realização de um caso

de uso. A princípio, cada caso de uso teria uma classe de controle.

Na verdade, embora com diferentes nomenclaturas, o diagrama de classes é um só, que vai crescendo e sendo

alterado a cada fase do ciclo de desenvolvimento. Algumas equipes de projeto podem optar por guardar as

versões finais de cada diagrama, mas a última versão guarda todas as alterações feitas.

A classe

Vamos conhecer o conceito de classe com mais detalhe:

Uma classe é uma abstração da realidade, na qual representamos algo do mundo real. Se, por exemplo, em

um contexto de sistema, identificarmos que desejamos armazenar os dados de um determinado elemento,

estamos diante de uma candidata à classe do sistema.

Na UML, uma classe é representada por um compartimento contendo três partes, conforme ilustra a figura

a seguir:

-4-
Exemplo

A figura, abaixo, ilustra um exemplo de classe de nome “cliente”, contendo os atributos Nome e Matrícula e os

métodos (operações) Criar(), Destruir() e Incluir Cliente():

-5-
Classe x Objeto

Qual a relação existente entre classe e objeto?

Na imagem, a seguir, você pode visualizar o exemplo de um objeto específico pertencente à classe cliente. O

objeto é como se fosse um elemento específico do conjunto (classe) cliente.

Fique ligado
Ao modelarmos um sistema, estamos em busca de classes, e não de objetos. Poderíamos
pensar que o nome da técnica deveria chamar-se “orientação a classes”, e não “orientação a
objetos”.

Visão geral do diagrama de classes e seus elementos

A figura abaixo ilustra um diagrama conceitual de classes, contendo apenas classes de negócio (entidades)

que são modeladas, bem como apresenta comentários dos principais elementos do diagrama de classes.

-6-
 Fonte: Figura extraída do livro UML Essencial: um breve guia para a linguagem-padrão de modelagem de
objetos, de Martin Fowler, 3a edição.

Por meio do exemplo de diagrama, podemos observar que um diagrama de classes possui os seguintes

elementos básicos:

1. Classes, com atributos e operações (métodos) de cada uma;

2. Relacionamentos entre as classes;

3. Multiplicidade dos relacionamentos;

4. Visibilidade de atributos e métodos;

5. Nome dos relacionamentos e papel nos relacionamentos;

6. Navegabilidade nos relacionamentos;

7. Notas e comentários.

Classes com seus atributos e operações

Cada classe possui os seus atributos e operações específicos. Veja como esses elementos se relacionam:

Atributo

O conceito de atributo remete ao conjunto de características (estado) dos objetos da classe.

-7-
Ele descreve uma propriedade estrutural da classe, um dado relevante que desejamos armazenar daquela

classe. Segundo a UML, forma mínima de representar um atributo é: visibilidade Nome: tipo.

Operações

O conceito de método remete ao conjunto de operacões (comportamento) que a classe fornece.

A operacão de uma classe é representada por um método, que é um procedimento ou função da classe.

Segundo a UML, a forma mínima de representar um método é: visibilidade Nome (Lista de parâmetros) : tipo.

Associação entre classes

O relacionamento de associação é o mais simples e comum relacionamento entre classes. Ocorre entre uma,

duas ou mais classes distintas, não correlatas e independentes. Ao final do relacionamento, as classes

permanecem com suas vidas próprias.

A associação entre classes pode acontecer das seguintes maneiras, veja:

Associação binária: É a associação mais comum, também chamada de associação entre duas classe.

Autoassociação: Também chamada de associação unária, corresponde à associação que ocorre com a mesma

classe, na qual uma classe se relaciona com ela própria.

Associação exclusiva: É uma restrição em duas ou mais associações. Ela indica que objetos de uma

determinada classe podem participar de no máximo uma das associações, em determinado momento.

Ela é representada por uma linha tracejada, entre as associações, com a especificação {ou}, denotando que o

relacionamento é exclusivo a somente uma das duas classes.

Multiplicidade nos relacionamentos

A multiplicidade é um conceito extremamente relevante nos relacionamentos. De uma forma bem simples, ela

indica quantos objetos de cada classe podem estar envolvidos no relacionamento.

Visibilidade de atributos e métodos

Diz respeito a quais classes podem ver (visualizar) o quê de outra classe. A ideia é que cada classe tenha

elementos privados e públicos. Observe:

O que for público pode ser visualizado e usado por qualquer outra classe.

O que for privado só pode ser usado pela classe proprietária.

No entanto, ao sairmos da modelagem e passarmos para a implementação, temos que observar as

particularidades de cada um no tocante à visibilidade.

A UML aborda o tema sem entrar nessa confusão e deixa a cargo da equipe de desenvolvimento esses aspectos

de compatibilidade. Basicamente, a UML permite que se rotule todo atributo e método de uma classe com um

indicador de visibilidade.

Atenção

-8-
Em todos os exemplos vistos até aqui, usamos as visibilidades públicas (sinal de mais +) para os métodos e

visibilidade privada (sinal de menos -) para os atributos. A UML fornece quatro possibilidades de visibilidade, a

saber:

Preparamos algumas diretrizes relevantes sobre visibilidade que você deve estar atento. Veja:

1 O encapsulamento, um dos princípios básicos da orientação a objetos, diz que os atributos de uma classe

não devem ser usados por outras classes, e sim apenas por métodos da própria classe. A conclusão é que os

atributos devem ser classificados com visibilidade privada (-);

2 Uma classe deve prestar serviço às demais, através de seus métodos. Assim sendo, pelo menos um dos

métodos da classe deve ter visibilidade pública, para que as demais classes possam usá-lo;

3 Num relacionamento de generalização/ especialização, todos os atributos e métodos que desejar que

sejam herdados pela classe especializada (subclasse) devem ter visibilidade protegida na classe geral

(superclasse).

Outros relacionamentos entre classes

Os relacionamentos representam os mais relevantes elementos de um diagrama de classes. Por isso, agora

estudaremos os relacionamentos mais usados na modelagem de classes.

Além das associações, são possíveis os seguintes relacionamentos:

Classe se associação: É uma classe que surge do relacionamento de associação entre outras duas classes.

Generalização/especialização(herança): É o relacionamento entre classes que implementa o conceito de

herança, com reaproveitamento de código, preconizado pela orientação a objetos.

Agregação ou composição: Esses dois relacionamentos são do tipo “todo-parte”, ou seja, existe uma classe que

denota um todo e outras que denotam as partes.

Dependência: A dependência entre duas classes existe se: mudanças na definição de uma classe puder

demandar mudanças na definição da outra classe.

Nome do relacionamento e papel nos relacionamentos

-9-
Podemos definir, para um relacionamento, um nome e um papel. A imagem a seguir mostra um exemplo de

como definir esses elementos:

Faz pedido: O papel no relacionamento é um nome dado ao papel que cada classe representa no

relacionamento. Semanticamente, é útil para o entendimento do diagrama. Exemplo: Faz Pedido.

Faz: Pode ser dado um nome ao relacionamento, no caso faz, e com o sentido da leitura (seta indicando como

se lê), no caso a leitura é: cliente faz pedido.

Fique ligado
Cada classe pode ter o nome de seu papel descrito no relacionamento, conforme ilustra a
figura anterior. Seu uso é opcional e, caso seja necessário, pode-se especificar o papel de
apenas uma das classes no relacionamento. Veja:
• Faz é o nome do relacionamento, com a seta apontado para pedido, indicando
que a leitura é na direção cliente faz pedido;
• Possui é o nome do relacionamento entre pedido e itens pedido, com a seta
apontada para itens pedido, indicando que a leitura é na direção pedido possui
itens pedidos;
• Faz pedido é o papel que o cliente tem no relacionamento entre cliente e
pedido;

• Cada item do pedido é o papel que itens pedido tem no relacionamento entre

- 10 -
 • Cada item do pedido é o papel que itens pedido tem no relacionamento entre
pedido e itens pedido.

Navegabilidade nos relacionamentos de associação

A navegabilidade mostra a direção da navegação.

Podemos citar como exemplo, uma associação que é dita navegável da classe C1 para a classe C2 se, a partir de

um objeto de C1, consegue-se obter diretamente os objetos relacionados da classe C2. Assim, denota-se, no

diagrama de classes, a capacidade de um objeto mandar mensagens a objetos de outra classe.

Veja mais um exemplo:

No diagrama de classes representado pela figura a seguir, está sendo representada a navegabilidade da

associação entre as classes cliente e endereços. O símbolo é a seta colada na classe endereços.

A interpretação para o diagrama que vimos anteriormente é a seguinte:

Notas são comentários nos diagramas. Elas podem ser isoladas ou vinculadas, por linha tracejada, a um dos

elementos do diagrama. Podem ainda ser usadas em qualquer diagrama.

A figura a seguir, ilustra as duas possibilidades: notas associadas a um elemento, no caso à classe endereços

e nota associada ao diagrama, de uma forma geral.

- 11 -
Saiba mais
Para saber mais sobre os tópicos estudados nesta aula, pesquise na internet sites, vídeos e
artigos relacionados ao conteúdo visto. Se ainda tiver alguma dúvida, fale com seu professor
online, utilizando os recursos disponíveis no ambiente de aprendizagem.

O que vem na próxima aula

•Elementos e modelagem de interações com diagrama de sequência.

CONCLUSÃO
Nesta aula, você:
• Reconheceu os elementos básicos e avançados da UML para a criação do diagrama de classes;
• Avaliou, através de uma atividade, os diagramas de casos de uso e de classes.

- 12 -
Referências
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML — Guia do Usuário. 2. ed. Rio de Janeiro: Elsevier, 2005. cap. 1 e 2.

FOWLER, Martin. UML essencial — um breve guia para a linguagem padrão. 3. ed. Porto Alegre: Artmed, 2005.

cap. 1

LARMAN, Craig. Utilizando UML e padrões? uma introdução à análise e ao projeto orientados a objetos e ao

processo unificado. 3. ed. Porto Alegre: Artmed, 2007. cap. 2.

- 13 -