diagramas de classes
TRANSCRIPT
-
8/18/2019 Diagramas de Classes
1/30
-
8/18/2019 Diagramas de Classes
2/30
-
8/18/2019 Diagramas de Classes
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
-
8/18/2019 Diagramas de Classes
4/30
-
8/18/2019 Diagramas de Classes
5/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 5
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
-
8/18/2019 Diagramas de Classes
6/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 6
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”}
-
8/18/2019 Diagramas de Classes
7/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 7
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/18/2019 Diagramas de Classes
8/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 8
• 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
-
8/18/2019 Diagramas de Classes
9/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 9
Representam relacionamentos entre instâncias declasses.
Ex.:
3. Associações
1 *Professor Disciplina
-
8/18/2019 Diagramas de Classes
10/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 10
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.
-
8/18/2019 Diagramas de Classes
11/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 11
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..*”
-
8/18/2019 Diagramas de Classes
12/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 12
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.
-
8/18/2019 Diagramas de Classes
13/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 13
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.
-
8/18/2019 Diagramas de Classes
14/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 14
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.
-
8/18/2019 Diagramas de Classes
15/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 15
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.
-
8/18/2019 Diagramas de Classes
16/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 16
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
-
8/18/2019 Diagramas de Classes
17/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 17
3. AssociaçõesNavegabilidade (continuação)
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.
-
8/18/2019 Diagramas de Classes
18/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 18
3. AssociaçõesNavegabilidade (continuação)
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).
-
8/18/2019 Diagramas de Classes
19/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 19
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.
-
8/18/2019 Diagramas de Classes
20/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 20
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).
-
8/18/2019 Diagramas de Classes
21/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 21
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.
-
8/18/2019 Diagramas de Classes
22/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 22
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.
-
8/18/2019 Diagramas de Classes
23/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 23
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”.
-
8/18/2019 Diagramas de Classes
24/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 24
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.
-
8/18/2019 Diagramas de Classes
25/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 25
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.
-
8/18/2019 Diagramas de Classes
26/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 26
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.
-
8/18/2019 Diagramas de Classes
27/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 27
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.
-
8/18/2019 Diagramas de Classes
28/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 28
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.
-
8/18/2019 Diagramas de Classes
29/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 29
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).
-
8/18/2019 Diagramas de Classes
30/30
© A. Dias de Figueiredo, 1997/78 Engenhari a de Software , Departamento de Eng. Informática, FCTUC Acetato 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.