7.

8 DIAGRAMA DE CLASSES
O diagrama de classes representa a estrutura do sistema, recorrendo ao conceito
de classe e suas relações. O modelo de classes resulta de um processo de abstracção
onde são identificados os objectos relevantes do sistema em estudo. Um objecto é uma
ocorrência que tem interesse para o sistema em estudo e que se pretende descrever no
seu ambiente, contendo identidade e comportamento. O comportamento de um objecto
define o modo como ele age e reage a estímulos externos e a identidade de um objecto é
um atributo que o distingue de todos os demais, sendo preservada quando o seu estado
muda. Um objecto não é mais do que uma instância da classe.
Os objectos de modelação contemplados por este diagrama são:

Classe: é a representação de um conjunto de objectos que partilham os mesmos atributos e
comportamentos;

Relação: representa a ligação entre classes.

A simbologia usada para representar estes dois conceitos é:

Classe

Relação

Cada classe é descrita através do seu nome, identificação de todos os seus

atributos e identificação de todas as operações que traduzem o seu comportamento. O
símbolo utilizado para representar a classe, e como se representa na figura 7.23,
contempla três áreas distintas, uma área para se identificar o nome da classe, outra para
listar os atributos e, finalmente, a terceira, para listar as operações ou métodos, também
designados, segundo alguns autores, por serviços.

Nome da classe
Atributos

Serviços

Figura 7.23 – Simbologia usada para representar uma classe

7.8.1 REGRAS DE CONSTRUÇÃO
7.8.1.1 COMO UTILIZAR OS OBJECTOS

O diagrama de classes mostra como cada classe se relaciona com as outras,

tendo como objectivo, a satisfação dos requisitos funcionais definidos para o sistema em
estudo. Neste diagrama, uma classe só pode aparecer uma vez.

7.8.1.2 COMO ATRIBUIR NOMES AOS OBJECTOS

Qualquer classe e relação devem ter um nome elucidativo e claro para que o
diagrama seja facilmente entendido. As classes devem ser identificadas por um nome
comum, como, por exemplo, Encomenda, Produto, Cliente, etc. Os nomes das relações
devem ser traduzidas através de um verbo, como, por exemplo, efectua, contém, refere,
etc. Qualquer um destes nomes deve fazer parte do vocabulário do domínio do problema
em estudo.

7.8.1.3 COMO LIGAR OS OBJECTOS

Depois de se terem identificado as classes e os seus atributos, há que identificar

as relações que existem entre as diferentes classes, de forma a satisfazer os requisitos
funcionais do sistema.
A representação da ligação entre classes faz-se recorrendo a uma linha recta,
como pode ser visto na figura 7.24. O símbolo com a forma de um rectângulo com um
canto dobrado que aparece no diagrama da figura 7.24 é o utilizado para ilustrar notas
ou restrições.

Figura 7.24 – Notação usada no diagrama de classes

Na figura 7.24, mostra-se como se representam as relações e chama-se a

atenção para onde se coloca o nome e os atributos da classe. Nesta ilustração, foram
identificadas duas classes, Encomenda e Produto, cada uma das quais com os seus
atributos, e foi identificada a relação “Contém” entre as duas classes.
A associação acontece quando uma classe se associa a uma ou mais classes, ou
mesmo com ela própria. As classes estão associadas se:

Um objecto de uma classe envia uma mensagem a um objecto de outra classe;

Um objecto de uma classe cria um objecto de uma outra classe;

Um objecto de uma classe recebe uma mensagem com um objecto de outra classe como argumento.
 Existem outros tipos de relações, generalização e agregação, que são casos
particulares da associação. Exemplos destes tipos de relações são mostrados na figura
7.25.
A generalização é a relação que se estabelece entre uma superclasse e uma
subclasse. A Classe A é uma generalização da Classe B quando A e B estão
relacionados por uma relação: “B é como A”. É uma relação num sentido; se A é uma
generalização de B, então B não pode ser uma generalização de A. A classe A é a classe
pai ou superclasse e B é a classe filho ou subclasse. É uma associação entre classes
todo-parte, conhecida como uma relação “consiste em”. Este conceito é equivalente ao
conceito de herança da programação orientada a objectos, onde as subclasses, filhos,
herdam da superclasse, pai, os atributos e métodos comuns.
A agregação usa-se para mostrar o facto de um todo ser composto por partes.
Uma forma especial de agregação é a composição, que se usa quando as partes, para a
sua existência, dependem da existência do todo. Por exemplo, não faz sentido ter uma
linha de encomenda se não estiver associada a uma encomenda.

Generalização

A g r e ga ç ã o

Composição

Figura 7.25 – Generalização, agregação e composição

Num diagrama de classes, e após ter-se identificado a associação entre classes,

é necessário identificar a cardinalidade de uma associação, vulgarmente designada por
multiplicidade. A multiplicidade é especificada no extremo da associação e sobre a
linha que representa a associação. A tabela 7.11 identifica e descreve a notação usada
para representar os diferentes tipos de multiplicidade.
 Quando há necessidade de se saber mais sobre a associação que se estabelece
entre duas classes, surge o que se denomina por classes associativas. Por exemplo, se
um produto pode ser comercializado por diferentes fornecedores e cada fornecedor tem
um preço diferente para cada produto que comercializa, há necessidade de ter a classe
Produto_Fornecedor, pois pretende-se saber qual o preço para um fornecedor específico.
Esta classe associativa só existe devido à relação que se estabelece entre duas classes
com multiplicidade de muitos para muitos e tem sempre atributos próprios.

Multiplicidade Simbologia

0..1
Zero ou um (opcional)

1..1
Um para um

1..n
Um para muitos

0..n
Zero ou muitos

Um a vinte (valor entre o intervalo 1..20

estabelecido)

Tabela 7.11 – Notação usada para representar os diferentes tipos de multiplicidade

A figura 7.26 mostra como se representa uma classe associativa.

Figura 7.26 – Exemplo de uma classe associativa

7.8.2 ANÁLISE DE UM DIAGRAMA DE CLASSES
No sistema de recepção de encomendas em estudo, pode-se identificar as
seguintes classes: Cliente, Encomenda e Produto. Na figura 7.27, apresenta-se a
primeira versão do diagrama de classes para o referido sistema.

Figura 7.27 – Primeira versão do diagrama de classes para o sistema de recepção de

encomendas

Verifica-se que, neste sistema, a encomenda pode ser ou não satisfeita. Neste
caso, identifica-se um caso especial, designado, no diagrama de classes, por
generalização, que permite demonstrar a noção de superclasse e subclasse, herdando
esta os atributos da superclasse. Neste mesmo sistema, nota-se a necessidade da classe
Produto_Encomendado para se poder saber que produtos foram encomendados em cada
encomenda; esta última classe só existe se existir a classe Encomenda.
A figura 7.28 representa o diagrama de classes revisto, incluindo já associações
de generalização e de composição.

Produto_Encomendado
1..n 1..n
-Quant_enc
Pertence
Contém

Cliente
Encomenda Produto
-Num_Cliente
-Nome Cliente Faz 1..n
-Tipo_Ref -Num_Enc -Codigo_Prod
-Morada -Data_Enc -Preço_Unit
-Desconto -Quant_Disp

Encomenda aceite Encomenda rejeitada

-Data entrega -Razão

Figura 7.28 – Diagrama de classes revisto para o sistema de recepção de encomendas