Diagramas de Classes

8/18/2019 Diagramas de Classes

1/30


2/30


3/30

© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 3

TÓPICOS COBERTOS

u Diagramas de classesu Perspectivas dos diagramas de classesu Associaçõesu Atributosu Operaçõesu Visibilidade dos atributos e operaçõesu Generalizaçãou Restriçõesu Quando usar os diagramas de classes


4/30


5/30


A classe representada no exemplo é:

• identificada pelo nome“Rectângulo”,

• tem como atributos “Largura” e

“Altura”,• executa a operação “Área ()”, a

partir dos atributos, e• está sujeita à restrição “{Área


6/30


Encomenda

dataRecebidaéPrepaganúmero: stringprice: money

Despacha()Fecha()

Linha de Encomenda

quantidade: inteiropreço: moneyestáSatisfeita: Booleana

Produto

1

*

*

1

*

Cliente

nomeendereço

regimeCrédito(): string

Cliente Institucional

nomeContactoregimeCréditolimiteCrédito

avisa ()facturaParaMês (Inteiro)

Cliente Individual

cartãoCrédito#

Empregado

*0..1

1

1. Diagramas de classesExemplo de diagram de classes

{Se Encomenda.cliente.regimeCréditoé “fraco”, então Encomenda.éPrepagatem que ser verdadeiro}

técnico de vendas{regimeCrédito()== “fraco”}


7/30


2. Perspectivas dos diagramas de classes

As classes podem ser entendidas sob três perspectivas:

• Conceptual. A classe exprime um conceito abstracto nodomínio em estudo.

• De especificação. A classe é escrita pensando já em termosde software, mas é encarada de um ponto de vista exterior, enão em termos de implementação (i.e., pensa-se nasinterfaces, mas não na sua caracterização interna)

•

De implementação. A classe é descrita pensando já naforma como vai ser implementada.


8/30


• No caso da perspectiva conceptual, desenha-se a classe sem pensar no tipo de implementação que vai ter (i.e., é indpendenteda linguagem de programação que vai ser utilizada).

• No caso da perspectiva de especificação, é por vezes usado o

conceito de tipo para designar as interfaces quando ainda não se pensou na sua forma de implementação, que pode ser variada.

• De um modo geral, há vantagem em pensar mais na perspectivade especificação do que na perspectiva de implementação,embora a segunda seja hoje em dia mais popular.

• É fundamental reconhecer sempre em que perspectiva se está adesenhar, ou a ler, um diagrama de classes.

2. Perspectivas dos diagramas de classes


9/30


Representam relacionamentos entre instâncias declasses.

Ex.:

3. Associações

1 *Professor Disciplina


10/30


3. AssociaçõesNa perspectiva conceptual:

h As associações representam relacionamentos conceptuais.

h Cada associação tem dois papéis (“roles ”), que correspondem a

cada um dos dois sentidos do relacionamento. No exemplo acima os papéis são “professor leccionadisciplina” e “disciplina é leccionada por professor”

h Um papel pode ser caracterizado explicitamente por uma

etiqueta que se coloca, em itálico, a meio, entre as duas classes.Se não houver etiquetas, o papel fica caracterizado pela classede destino.


11/30


3. AssociaçõesNa perspectiva conceptual (continuação):

h Um papel tem multiplicidade (ou cardinalidade).

No exemplo acima o par “1,*”significa que cada professor pode ensinar várias diciplinas e que não há nenhuma

disciplina que possa ser ensinada por vários professores.As cardinalidades representam limites superiores.

h“*” significa qualquer valor ente zero e vários,

h“1” representa o valor 1,

h se se pretendesse dizer que é possível que alguns professoresnão ensinem disciplina nenhuma, utilizava-se a notação “0..1”

h outra notação possível é “1..*”


12/30


3. AssociaçõesNa perspectiva de especificação:

h As associações representam responsabilidades.

No diagrama da transparência 6 isso significa, por exemplo,

que há um ou mais métodos associados a “Cliente” quedefinem que “Encomenda(s)” é que um cliente fez.

Do mesmo modo, haverá métodos em “Encomenda” que meinformam de que “Cliente” fez determinada encomenda e deque “Linha(s) de Encomenda” constituem uma “Encomenda”.

Estas responsabilidades não implicam, no entanto, estruturas dedados. O diagrama exprime apenas as interfaces, e nada mais.


13/30


3. AssociaçõesNa perspectiva de implementação:

h As associações exprimem agora a existência de ponteiros nosdois sentidos, entre as classes ligadas pela associação.

No diagrama da transparência 6 isso significa, por exemplo,que “Encomenda” tem um campo que é uma colecção de ponteiros para “Linha(s) de Encomenda” e tem um ponteiro aapontar para “Cliente”.

A este nível não se podem tirar, a partir das associações,

quaisquer conclusões acerca das interfaces. As operações sobreas classes é que darão essa informação.


14/30


3. AssociaçõesNavegabilidade

h As associações descrevem a rede de relações estruturais queexistem entre as classes e que dão origem às ligações entre osobjectos, instâncias dessas classes.

h Essas ligações podem ser vistas como canais de navegabilidadeentre objectos.

h Por omissão, as associações são navegáveis nos dois sentidos,mas em alguns casos só interessa um dos sentidos da

navegabilidade.


15/30


3. AssociaçõesNavegabilidade (continuação)

h Quando se pretende exprimir uma navegabilidade de um sósentido recorre-se a uma seta colocada sobre o papel para o quala navegabilidade é possível.

h O diagrama da transparência 16 representa o diagrama datransparência 6 no qual se colocaram duas navegabilidades. Aque aponta de “Encomenda” para “Cliente” significa que“Encomenda” tem a responsabilidade de dizer a que “Cliente” sedestina, mas “Cliente” não tem a responsabilidade de dizer que

“Encomenda” lhe corresponde.h Temos assim responsabilidades assimétricas.


16/30


Encomenda

dataRecebidaéPrepaganúmero: stringprice: money

Despacha()Fecha()

Linha de Encomenda

quantidade: inteiropreço: moneyestáSatisfeita: Booleana

Produto

1

*

*

1

*

Cliente

nomeendereço

regimeCrédito(): string

Cliente Institucional

nomeContactoregimeCréditolimiteCrédito

avisa ()facturaParaMês (Inteiro)

Cliente Individual

cartãoCrédito#

Empregado

*0..1

1

Exemplo com navegabilidades

{Se Encomenda.cliente.regimeCréditoé “fraco”, então Encomenda.éPrepagatem que ser verdadeiro}

técnico de vendas {regimeCrédito()== “fraco”}

3. Associações


17/30



h A navegabilidade constitui um aspecto importante dos diagramasde implementação e de especificação, mas não se pensa quetenha qualquer interesse ao nível conceptual.

h É frequente ver-se um diagrama conceptual que começa semnavegabilidades e que depois se tranforma num diagrama deespecificação ou de implementação, pela introdução dasnavegabilidades.

h Tem-se uma associação unidireccional quando só há

navegabilidade num sentido e uma associação bidireccionalquando as navegabilidades são nos dois sentidos.


18/30



h Uma associação sem setas é entendida como uma associação bidireccional, ou então como uma associação cujasnavegabilidades ainda não foram definidas (no seio de um grupo

de trabalho deve-se decidir de antemão qual destas interpretaçõesse adopta; para o caso dos diagrams de especificação e deimplentação é mais frequente adoptar-se a segunda).

h Se uma associação é bidireccional, isso significa que os dois papéis são inversos um do outro (tal como numa função inversa,

em Matemática). Esta propriedade é válida nas três perspectivas(conceptual, de especificação e de implementação).


19/30


3. AssociaçõesNomeação

h Podemos atribuír nomes , ou etiquetas, às associações.

h Os analistas tradicionais preferem usar nomes expressos por

formas verbais, quer activas (“lecciona”), quer passivas (“éleccionada”). Os analistas OO preferem usar substantivos, por entenderem que exprimem melhor as responsabilidades eoperações

h Alguns analistas dão nomes a todas as associações. Outros

preferem só atribuír nomes às associações que tenham a ganhar,em clareza, pela atribuição de um nome.


20/30


4. Atributosh No caso mais geral, a notação para um atributo especifica o seu

nome (name), tipo (type) e valor por omissão (default value), bem como a sua visibilidade (visibility). A sintaxe UML é:

visibility name: type = defaultValue

h O conceito de visibilidade que aqui se aplica é o mesmo que para as operações (ver transparências seguintes).

h Os atributos têm sempre um valor único de cada vez.

h Em geral os diagramas não indicam se um atributo é opcionalou obrigatório (embora, em rigôr, devessem fazê-lo).


21/30


5. Operaçõesh As operações correspondem aos métodos da classe. A sintaxe

UML completa de uma operação é a seguinte:

visibility name(parameter list): type =

return-type-expression {property-string}

onde:h visibilidade tem o significado descrito nas transparência seguintes,

h name é uma cadeia de caracteres,

h parameter-list contém argumentos (opcionais) cuja sintaxe é a mesmados atributos,

h return-type-expression é uma especificação opcional,

h property-string indica valores de uma propriedade que se aplica àoperação.


22/30


5. Operaçõesh É útil distinguir entre operações que alteram, e não alteram, o

estado de uma classe.

Uma interrogação (“query ”) é uma operação que obtem ovalor de uma classe sem alterar o seu estado observável. As

operações que alteram o estado observável de uma classe sãodenominadas modificadores.

As interrogações podem ser executadas por qualquer ordem,mas os modificadores exigem cuidados com a suasequenciação. O melhor é não procurar obter valores a partir demodificadores.


23/30


5. Operaçõesh Outra designação frequente é a de métodos de obtenção

(“getting methods ”), que devolvem o valor de um campo (e nãofazem nada mais), e métodos de fixação (“setti ng methods ”),que colocam um valor num campo (e não fazem nada mais).

h Também se deve reconhecer a distinção entre operação e

método. Uma operação é algo que se evoca sobre um objecto (achamada do procedimento), enquanto que um método é o corpodo procedimento. É frequente confundirem-se os dois, masimporta notar que a operação não é mais do que a “chamada” dométodo. Havendo polimorfismo, operação e método sãodistintos.

h As linguagens de programação tendem a complicar mais adistinção: Em C++ as operações são chamadas “funçõesmembro”, enquanto que em Smalltalk são chamadas “métodos”.


24/30


6. Visibilidade dos atributos e operaçõesh A UML define três tipos de visibilidade para os atributos e

operações:

h pública , (simbolizada pelo caracter +), que torna oelemento visível a todos os clientes da classe,

h protegida , (simbolizada pelo caracter #), que torna oelemento visível às sub-classes da classe,

h privada , (simbolizada pelo caracter -), que torna oelemento visível apenas à própria classe.

h Embora nem sempre figure de maneira explícita nos diagramasde classes, isso não significa que a visibilidade não seja definidano modelo.


25/30


7. Generalização e sub-tiposh Em UML preferiu-se utilizar o termo generalização em vez do

termo herança, já nosso conhecido. As classes obtidas por herança são denominadas sub-tipos (excepto no caso dosdiagramas de implementação, em que são designadas por sub-classes).

No diagrama da transparência 6, distinguem-se os “clientesinstitucionais” e os “clientes individuais”, que, tendo algumasdiferenças entre si, têm também algumas semelhanças. Essassemelhanças podem ser colocadas na classe “cliente” (o

super-tipo) ficando as outras classes (os sub-tipos) com ascaracterísticas que são diferentes.


26/30


7. Generalização e sub-tiposTambém aqui se podem considerar três perspectivas:

h Na perspectiva conceptual podemos dizer, por exemplo, que“cliente institucional” é um sub-tipo de “cliente” se todas asinstâncias de “cliente institucional” forem também, por

definição, instâncias de “cliente”. A ideia chave é que tudo oque estabelecermos para “cliente” (associações, atributos,operações) é também válido para “cliente institucional”.

h Na perspectiva de especificação, a generalização significa que ainterface do sub-tipo tem que incluir todos os elementos dainterface do super-tipo. Diz-se que a interface do sub-tipo estáconforme com a interface do super-tipo.


27/30


7. Generalização e sub-tipos

h Na perspectiva de implementação, a generalização estáassociada com o fenómeno da herança nas linguagens de programação orientadas para objectos. Fala-se aqui de sub-classes, e não de sub-tipos, e considera-se que a sub-classe

herda todos os métodos e todos os campos da super-classe, podendo os métodos da sub-classe sobrepor-se aos métodosherdados.


28/30


8. Restriçõesh O próprio facto de se desenhar um diagrama de classes significa

que se estão a respeitar restrições. Os conceitos de associação,de atributo ou de generalização são, afinal, formas deespecificar restrições. No entanto, os conceitos chave dosdiagramas de classe não permitem exprimir todas as restrições.

h Há restrições que têm que ser expressas de forma explícita porque não caem em nenhuma das categorias previstas nosdiagramas de classes. A sintaxe UML para exprimir restriçõeslimita-se a indicar que devem ser colocadas entre {}. Tudo o

resto é livre, podendo ser expressas numa pseudo-linguagem, para enfatizar a legibilidade, ou ser traduzidas por instruçõesem código de programação.


29/30


9. Quando usar os diagramas de classesOs diagramas de classes são a espinha dorsal de praticamente todosos métodos orientados para objectos, e são por isso os mais usados.São, no entanto, os mais ricos e complexos, pelo que se recomendao seu uso com alguns cuidados:

h Não tentar usar todas as notações disponíves. Usar as maiscomplexas (do capítulo seguinte) apenas quando for indispensável.

h Adequar a perspectiva que se está a usar à fase em que o projecto se encontra (fazer diagramas conceptuais se se está afazer a análise; de especificação se começa a pensar emsoftware; e de implementação apenas quando se quer ilustrar uma solução de implementação mais particular).


30/30


9. Quando usar os diagramas de classesh Não desenhar modelos para tudo; é preferível concentrarmo-

nos nas áreas chave. É melhor ter poucos diagramas que sevão actualizando quando necessário do que ter muitosdiagramas que se vão tornando obsoletos por falta deactualização.

h Evitar a todo o custo começar a pensar nos promenores deimplementação demasiado cedo. Para o conseguir, procurar concentrar a atenção nas perspectivas de concepção e deespecificação.

Diagramas de Classes

Documents

Transcript of Diagramas de Classes