Um pouco sobre diagramas de classes em UML

Joo Paulo Barros Escola Superior de Tecnologia e Gesto Instituto Politcnico de Beja
10 de Junho de 2008 revisto em 11 de Maio de 2009

Este texto apresenta a parte que se considera mais importante dos diagramas de classes da UML 2.2, cuja especicao se encontra disponvel no stio Internet da Object Management Group (OMG) em http://www.uml.org. Enfatiza-se a ligao dos diagramas de classes ao cdigo, nomeadamente utilizando a linguagem JavaTM . Actualmente, a especicao da UML tem 226 + 740 = 966 pginas e muitas delas esto relacionadas com os diagramas de classes. Ainda assim, o que "realmente interessa" sobre diagramas de classes est aqui! Os programas orientados pelos objectos podem (e muitas vezes devem) ser especicados por linguagens grcas, visuais ou "diagramticas"(do ingls diagrammatic). Ou seja, por desenhos ou diagramas. A razo est no facto, bem conhecido, das imagens poderem facilitar a visualizao e compreenso de muitas coisas: problemas, estruturas, interaces, etc.. Muito provavelmente, o diagrama mais utilizado no desenvolvimento de programas orientados pelos objectos o DIAGRAMA DE CLASSES parte da U NIFIED M ODELING LANGUAGE (UML1 ). Num diagrama de classes cada classe (de objectos pois claro) representada por um rectngulo contendo o nome da classe. As linhas entre rectngulos indicam relaes entre os objectos dessas classes. As cinco relaes (Relationship) de que iremos falar so classicadas da seguinte forma (ver exemplo na Fig. 1): Relationship). Vamos considerar apenas associa1. Associao (Association es binrias. Cada extremo da associao pode assumir um de trs valores (a) Associao "simples" (AggregationKind=none)(e.g. entre Teacher e CurricularUnit) (b) Agregao partilhada (AggregationKind=shared) (e.g. entre Course e CurricularUnit) (c) Agregao composta (AggregationKind=composite) (e.g. CurricularUnit e Syllabus) 2. Relao dirigida (DirectedRelationship Relationship) DirectedRelationship) (e.g. entre

diagrama de classes UML

(a) Generalizao/Herana (Generalization entre LocalStudent e Student) (b) Dependncia (Dependency

DirectedRelationship)

Realization i. Realizao de interface (InterfaceRealization Abstraction Dependency) (e.g. entre Student e Comparable) ii. Utilizao (Usage Dependency) (e.g. entre Syllabus e Validator)
1 http://www.uml.org

A Fig. 1 apresenta exemplos das vrias relaes.

Figura 1: Relaes em UML.

Seguidamente, apresentamos os vrios tipos de relao que iremos utilizar.

Associao

A associao a forma mais comum de compor objectos: um objecto tem outro. Nada mais simples! Bom, na verdade, no assim to simples e por duas razes: 1. Um objecto pode ter ou estar associado a outro sem que este seja parte do primeiro. Por exemplo, dizemos que um professor tem ou est associado a unidades curriculares, mas estas no so parte do professor. 2. Em rigor, um objecto tem o nome de outro objecto e no o prprio objecto. Tal permite que um objecto pertena a mais do que um outro objecto! Ao primeiro tipo em que um objecto tem outro sem que esse seja parte dele chamamos associao simples ou simplesmente ASSOCIAO, e j est. Ao segundo tipo de associao, quando podemos dizer convictos que um objecto parte de outro, chamamos AGREGAO. Se tivermos dvidas devemos evitar a agregao e especicar uma associao "simples", ou seja, sem agregao. Se consideramos que se trata de uma agregao podemos ainda utilizar uma de duas formas:

associao

agregao

Agregao partilhada Um objecto da classe A contm (o nome de) um objecto da classe B, mas sem exclusividade, ou seja, outros objectos podem conter o nome do mesmo objecto da classe B. Representa-se colocando um losango sem preenchimento (vazio) no lado do objecto (o composto) que contm o outro (o componente). 2

Agregao composta Em cada instante apenas um objecto da classe A contm (o nome de) um objecto da classe B. Representa-se colocando um losango com preenchimento (a cheio) no lado do objecto (o COMPOSTO) que contm o outro (o COMPONENTE). O composto tem a responsabilidade pela existncia e armazenamento do composto. Regra geral, as associaes so implementadas no cdigo (por exemplo em JavaTM ) colocando nomes de objectos dentro de outros. Por vezes, diferentes associaes so implementadas por igual cdigo. Tal signica, que a diferena pode s estar presente no diagrama mas no no cdigo. Tal especialmente frequentemente para a associao simples e a agregao partilhada. Este facto no deve surpreender pois o diagrama de classes um modelo mais abstracto (com menos detalhes) do que o cdigo. Ou seja, o cdigo pode e deve ser visto como um modelo mais detalhado e portanto menos abstracto do que o diagrama de classes. Seguem-se os "esqueletos" de cdigo JavaTM que especicam as associaes apresentadas na Fig. 1.
class Teacher implements Comparable<Teacher> { private List<CurricularUnit> currUnits; // association ... }

composto componente

abstract class Student implements Comparable<Student> { private List<Enrolment> es; // association ... } class CurricularUnit { private Teacher teacher; // association private Syllabus syllabus; // composite aggregation ... } class Enrolment { private List<CurricularUnit> units; // shared aggregation ... } class Course { private List<CurricularUnit> units; // shared aggregation ... }

1.1

Navegabilidade

Nas associaes possvel indicar a navegabilidade entre os objectos, ou seja, se um objecto tem acesso ao outro, tipicamente devido a ter um atributo desse ou3

tro objecto. A associao entre a classe Student e a classe Enrolment, na Fig. 1, um exemplo dos dois tipos de notao: a cruz e a seta aberta. Naturalmente, a seta indica que os objectos da classe Student podem alcanar objectos da classe Enrolment. A cruz do lado da classe Student indica que os objectos da classe Enrolment no podem alcanar os da classe Student.

1.2

Multiplicidade

Ainda podemos adicionar mais informao nas associaes. A linguagem UML admite os seguintes indicadores de multiplicidade2 .
Indicador Multiplicidade zero ou um um zero ou mais um ou mais n ou mais (com n > 1) apenas n (com n > 1) zero a n (com n > 1) um a n (com n > 1) n a m (com n > 1, m > 1 e n < m )

0..1 1 0..* ou apenas * 1..* n..* n 0..n 1..n n..m

As letras n e m representam nmeros inteiros. Por exemplo, 1..n signica que so permitids todas as seguintes especicaes: 1..1, 1..2, 1..3, etc.. Note que 1..1 igual a 1 e que o valor aps o .. tem de ser maior ou igual do que est antes de ... Por exemplo, 3..2 no permitido

Relaes -um (em ingls is-a)

A generalizao/herana e a realizao de interfaces, correspondem ao tipo de relao mais caracterstico da programao orientada pelos objectos. nelas que se baseia a ligao dinmica (dynamic binding) para suporte ao polimorsmo o qual permite aumentar a coeso das classes atravs da ocultao automtica de if s ou switches para escolher entre diversos tipos.
generalizao/herana Quer a GENERALIZAO / HERANA (extends em JavaTM ) quer a REALIZAO (implements realizao um

em JavaTM ) signicam um (is-a). Por exemplo: cada Student e cada Teacher um Comparable; um LocalStudent um Student; um ErasmusStudent um Student. Tambm podemos dizer que a classe ErasmusStudent herda da classe Student, ou ainda que a classe Student generaliza a classe ErasmusStudent. Herana ainda o termo mais comum.

tem-um versus -um

Devemos optar por uma associao/agregao ou uma generalizao/herana? Numa perspectiva de alto-nvel (independente do cdigo), a diferena deve ser vista atravs do "teste" um is-a versus tem um has-a: ou um A tem um B, ou um A um
2 in

UML Superstructure Specication, v2.1.2, 7.3.32 MultiplicityElement (from Kernel)

B. Por exemplo, um avio tem um motor, mas dicilmente (apesar de verdadeiro!) diramos um avio um motor com mais coisas. Por outras palavras, devemos pensar no que faz mais sentido no mundo real.

Numa perspectiva de baixo-nvel, quer a generalizao/herana quer a associao/agregao permitem aumentar as funcionalidades dos objectos de uma classe. A a grande diferena est no facto da generalizao/herana permitir a denio de mtodos polimrcos. Em caso de dvida e se no necessitarmos de polimorsmo, devemos optar por associaes/agregaes em lugar de generalizaes/heranas. Seguem-se os "esqueletos" de cdigo JavaTM que especicam as generalizaes apresentadas na Fig. 1.

class Teacher implements Comparable<Teacher> { private List<CurricularUnit> units; ... } abstract class Student implements Comparable<Student> { private List<Enrolment> enrolments; ... } class LocalStudent extends Student { ... } class ErasmusStudent extends Student { ... }

Utilizao

A utilizao (usage) uma forma de dependncia no cdigo (ou seja, na implementao). Dizemos que um objecto da classe A depende de outro da classe B quando necessita de algo nesse objecto para a sua denio. Pode ser vista como dependncia de compilao: se a classe B no existir, a classe A no compila. Note que tambm as outras relaes implicam dependncia entre os objectos. Assim, a relao de utilizao deve ser utilizada apenas quando nenhuma das outras se aplica. Tipicamente existem duas situaes em que existe utilizao podendo no existir associao/agregao ou generalizao/herana: 1. Quando o objecto da classe A utiliza um objecto da classe B como varivel local de um mtodo, mas no o guarda como atributo. Ento A utiliza B. 2. Quando o objecto da classe A utiliza um objecto da classe B que recebeu como parmetro mas no o guarda como atributo. 5

Relaes e classes nos diagramas

A Fig. 2 apresenta os diagramas para as vrias relaes.

Notao Relao Associao

Agregao partilhada

Agregao composta

Generalizao/herana (extends)

Realizao de interface (implements)

Utilizao

Figura 2: Notao para as relaes apresentadas

Cada classe pode conter tambm os seus atributos e mtodos. Para tal o respectivo rectngulo deve ser dividido em trs partes. Por exemplo, se a classe Student contiver um atributo para o respectivo nome, outro para o nmero mecanogrco de aluno e os respectivos getters, mais um mtodo private somethingToDo(int n), tal pode ser representado como se exemplica na Fig. 3.

Figura 3: Uma classe com indicao de atributos (ambos privados) e trs mtodos: dois pblicos e um privado

Os sinais antes dos atributos e mtodos indicam a visibilidade dos mesmos:

Notao Visibilidade

+ #

public private protected

package visibility (sem qualicador em JavaTM )

MUITO IMPORTANTE: os atributos que especicam associaes no devem ser representados dentro da classe. Por exemplo, o atributo syllabus para objectos 6

da classe CurricularUnit no deve ser colocado no diagrama de classes porque j l est sob a forma de notao grca, mais especicamente sob a forma de uma linha, com um losango a cheio numa das extremidades, que une as duas classes. Como regra, representamos como atributos os de um tipo primitivo (por exemplo int, double) ou de classes j feitas e de muito comum utilizao como a classe String. Os atributos que correspondam a outras classes por ns feitas devem ser representados de forma implcita utilizando a notao grca para as associaes. S no cdigo todos tero que surgir: os que j estavam dentro da classe no diagrama e os que resultaram das especicaes grcas.

Leituras complementares

Para saber mais aqui cam alguns links com mais informao sobre diagramas de classes, e no s, em UML 2: 1. Allen Holub , "Allen Holubs UML Quick Reference", disponvel em http:// www.holub.com/goodies/uml. 2. Scott W. Ambler, UML 2 Class Diagrams, disponvel em

http://www.agilemodeling.com/artifacts/classDiagram.htm.
3. Scott W. Ambler, "UML 2 Class Diagram Guidelines", disponvel em http:// www.agilemodeling.com/style/classDiagram.htm.

Ferramentas

Existem MUITAS ferramentas para a linguagem UML. A wikipedia apresenta um boa lista em http://en.wikipedia.org/wiki/List_of_UML_tools. Se se pretender apenas desenhar, a UMLet (http://www.umlet.com/) especialmente simples e eciente. Foi a nica ferramenta utilizada para desenhar os diagramas neste texto.

Agradecimentos
A professora Isabel Soa Brito e o aluno Joo Paulo Pereira Candeias apresentaram-me sugestes que contriburam para melhorar este texto.