ENGENHARIA DE SOFTWARE

(1)

ENGENHARIA DE SOFTWARE

PARTE 2

LINGUAGEM DE MODELAÇÃO UML

C

A P. 6 . 1 – U M L – M

O D E L A Ç Ã O D A

ES T R U T U R A

-D

I A G R A M A D E

CL A S S E S

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBI

Diagrama de Classes

Perspetivas dos Diagramas de Classes

Associações

Tópicos

2 Associações

Atributos

Operações

Visibilidade dos Atributos e Operações

Generalização

Restrições

Conceitos Avançados

Quando Utilizar os Diagramas de Classes

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Técnica central em qualquer método orientado para objetos

virtualmente todos os métodos incluem alguma variação desta técnica.

O diagrama de classes

Diagrama de Classes

3 O diagrama de classes

É uma descrição formal da estrutura de objetos num sistema.

Descreve

os tipos de objetos no sistema, e

os vários tipos de relacionamentos estáticos entre eles.

Expressam, de uma forma geral, a estrutura estática do sistema em termos

das classes e relacionamentos entre essas classes.

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBI

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Descrevem

as classes - descrições abstratas e condensadas de um conjunto de objetos

do domínio da aplicação, caracterizadas pelos seus:

Diagrama de Classes

4 do domínio da aplicação, caracterizadas pelos seus:

nome (ou identificador)

deve facilitar a compreensão do que a classe é e não o que faz

qualquer classe deve ter um nome (mesmo que genérico e provisório)

• exemplo: a_ser_definido

atributos

operações

restrições

os relacionamentos estáticos entre as classes

associações (por ex., um cliente pode alugar vários vídeos)

subtipos (por ex., uma enfermeira é um tipo de pessoa)

(2)

A classe representada no exemplo é:

identificada pelo nome “Triângulo”

tem como atributos “base” e “altura”

Diagrama de Classes

5 Triangulo

tem como atributos “base” e “altura”

executa a operação “area()”,

a partir dos atributos

está sujeita à restrição

“{area <= 300}” que limita a 300

o valor máximo da área a calcular

Os nomes das classes

base

altura

area

()

Os nomes das classes

devem começar por maiúsculas e quando

são compostos por mais de uma palavra,

a primeira letra de cada palavra

deve ser maiúscula.

{area <= 300}

restrição

Os atributos das classes:

Representam-se por baixo do nome

da classe.

Diagrama de Classes

6 Triangulo

da classe.

Pode apenas ser escrito o nome de um

atributo ou pode ser colocada também

informação relativa ao seu tipo.

Os nomes dos atributos devem começar

por minúsculas e quando são compostos

por mais de uma palavra, a primeira

base: int

altura: int

area()

por mais de uma palavra, a primeira

letra de cada palavra deve ser maiúscula

(excetuando a primeira).

{area <= 300}

restrição

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

As operações das classes:

Representam-se por baixo dos atributos.

Pode apenas ser escrito o nome da

Diagrama de Classes

7 Triangulo

Pode apenas ser escrito o nome da

operação ou pode ser colocada também

informação relativa ao tipo de dados que

devolve, ou pode ainda ser colocada

informação relativa aos parâmetros

que recebe e seus tipos.

Os nomes das operações seguem as

base: int

altura: int

area(): int

Os nomes das operações seguem as

mesmas regras dos nomes dos atributos.

{area <= 300}

restrição

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

A forma usada para representar as classes depende do seu fim:

Numa fase de análise, usar uma

representação simplificada

Diagrama de Classes

8 Triangulo

representação simplificada

Na fase de desenho devem ser

incluídos mais detalhes

Triangulo

base: int

altura: int

As classes estão relacionadas usando as mesmas relações estudadas

para os casos de uso: inclusão, generalização e associação.

altura: int

area(): int

(3)

A relação de inclusão

indica que uma classe usa a outra;

é normalmente usada quando uma classe é usada como argumento numa

Diagrama de Classes

9 é normalmente usada quando uma classe é usada como argumento numa

operação de outra classe.

A generalização

É uma relação entre uma classe geral (a superclasse ou pai) e uma ou mais

classes mais específicas (subclasses ou filhos);

As classes filho herdam todos os atributos e operações da classe pai e podem

ter mais atributos e operações que aqueles que herdam.

Se uma operação num filho tem o mesmo nome da do pai está a fazer um

override (obrepôr-se) à do pai.

A associação

É uma relação estrutural entre duas classes.

Exemplo:

Diagrama de Classes

10 Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

As classes podem ser entendidas sob três perspetivas:

Conceptual

a classe exprime um conceito abstrato no domínio de estudo

Perspectivas dos Diagramas de Classes

11 a classe exprime um conceito abstrato no domínio de estudo

De especificação

a classe é escrita pensando já em termos de software, mas é encarada de um ponto

de vista exterior e não em termos de implementação (i.e., pensa-se nas interfaces,

mas não na sua caracterização interna)

De implementação

a classe é descrita pensando já na forma como vai ser implementada

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Perspetiva conceptual

desenha-se a classe sem pensar no tipo de implementação que vai ter (i.e., é

independente da linguagem de programação que vai ser utilizada)

Perspectivas dos Diagramas de Classes

12 independente da linguagem de programação que vai ser utilizada)

Perspetiva 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 perspetiva de especificação do que na

perspetiva de implementação, embora a segunda seja hoje mais popular.

É fundamental reconhecer sempre em que perspetiva se está a

desenhar ou a ler um diagrama de classes

(4)

As associações

Representam relacionamentos entre instâncias de classes.

São representadas através de uma linha que une as classes associadas.

Associações

13 São representadas através de uma linha que une as classes associadas.

São caracterizadas por possuir um nome e, quando necessário, incluir o

papel que as classes têm na relação.

O nome das associações é dado, de preferência, utilizando formas verbais

ativas (“trabalha para”) ou

passivas (“é empregado por”),

embora haja quem defende o uso de substantivos em análise OO, uma vez

que assim é salientado o carácter estático da associação.

Exemplo:

O papel de uma pessoa é ser o Empregado, enquanto que o papel de uma

empresa é ser o Empregador

Associações

14 empresa é ser o Empregador

Alguns analistas dão nomes a todas as associações. Outros preferem só

atribuir nomes às associações que tenham a ganhar em clareza com a

existência de um nome

papel

Pessoa

_Empregado

_Emprego

_Empregador

Empresa

nome

Empregado

Emprego

Empregador

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Uma classe pode ter associações consigo própria, significando que um

objeto da classe se relaciona com um ou mais objetos da mesma

classe.

Associações: Associação Reflexiva

15 classe.

Este tipo de relação surge, tipicamente, em relações de hierarquia (o

chefe de um conjunto de empregados é também um empregado)

Exemplo: associação na mesma classe

Empregado

-Nome

Subordinado

-Nome -Morada

Chefe

Chefiar

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Papéis:

O papel descreve como uma das classes vê a outra classe na associação.

Cada associação binária tem dois papeis (“roles”), que correspondem a cada

Associações: Perspetiva Conceptual - Papéis

16 Cada associação binária tem dois papeis (“roles”), que correspondem a cada

um dos dois sentidos do relacionamento

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 classe de destino.

Exemplo:

o papel de um professor é Lecionar disciplina,

enquanto que o papel de uma disciplina é Ser lecionada por professor

Professor

Disciplina

(5)

Multiplicidade ou Cardinalidade:

Um papel tem multiplicidade (ou cardinalidade), que indica quantos objetos

de uma dada classe podem estar ligados a um objeto da outra classe.

Associações: Perspetiva Conceptual - Multiplicidade

17 de uma dada classe podem estar ligados a um objeto da outra classe.

No exemplo a seguir o “1 … *” significa

que cada professor pode ensinar várias disciplinas, e

que não há nenhuma disciplina que possa ser ensinada por vários professores.

Professor

₁

_*

Disciplina

Lecionar

Ser lecionada

As cardinalidades representam limites superiores

“*” significa qualquer coisa entre 0 e vários

“1” representa o valor um e só um

Se fosse pretendido indicar ser possível algumas disciplinas não serem

lecionadas por algum professor, utilizaríamos “0..1”

Associações: Perspetiva Conceptual - Multiplicidade

18 Formas mais comuns de multiplicidade:

0..1 - Opcional

1..1 ou 1 - Obrigatório existir um objeto

Professor

_0..1

_*

Disciplina

Lecionar

Ser lecionada

1..1 ou 1 - Obrigatório existir um objeto

M..N - Um valor do intervalo estabelecido (de M a N); 1..10 - de um a dez

0..* ou * - Zero a qualquer inteiro positivo objetos da classe

1..* - Um a qualquer inteiro positivo objetos da classe

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Exemplos de multiplicidades mais frequente

Associações: Perspetiva Conceptual - Multiplicidade

19 Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Numa relação de associação entre classes, a associação pode também

ter os seus próprios atributos (e eventualmente operações), devendo

ser, por conseguinte, modelizada também como uma classe. Este tipo

Associações: Perspetiva Conceptual – Classe-associação

20 ser, por conseguinte, modelizada também como uma classe. Este tipo

de classes designa-se por classe-associação.

Estas são representadas por uma linha a tracejado a ligá-la à linha da

associação entre as duas classes.

(6)

Exemplo:

a associação entre as classes “Pessoa” e

“Empresa” traduz as tarefas que

cada empregado realiza na empresa.

Associações: Perspetiva Conceptual – Classe-associação

21 cada empregado realiza na empresa.

Para cada tarefa é mantido um conjunto de atributos.

A classe-associação “Tarefa” é representada visualmente como qualquer

outra classe, mas apresenta uma linha a tracejado a ligá-la à linha da

associação.

A maioria das associações são binárias, pois ligam duas classes.

Mas, uma classe pode estar ligada a mais do que uma outra, através

das denominadas associações N-árias.

Associações: Perspetiva Conceptual – Associações N-árias

22 das denominadas associações N-árias.

Estas podem ser representadas por um losangulo apontado para as

várias componentes da associação.

Exemplo:

a classe “Disciplina” resulta da

associação entre as classes

“Aluno”, “Professor” e “Sala”.

Aluno

Sala

Professor

“Aluno”, “Professor” e “Sala”.

Aluno

Disciplina

Professor

Data_Início Data_Fim

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Exemplo de uma associação ternária e de uma classe-associação:

A associação “Disciplina” relaciona as classes “Professor”, “Aluno” e “Sala”.

Caso a associação tenha também atributos e/ou operações próprias, cria-se

Associações: Perspetiva Conceptual - Multiplicidade

23 Caso a associação tenha também atributos e/ou operações próprias, cria-se

uma classe-associação, a qual é ligada ao losango por uma linha a tracejado.

Aluno

Sala

Professor

Aluno

Disciplina

Sala

Professor

Disciplina

Aluno

Disciplina

Professor

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

As associações N-árias podem geralmente ser transformadas em várias

relações binárias entre a classe-associação e as restantes classes

participantes.

Associações: Perspetiva Conceptual - Multiplicidade

24 participantes.

No entanto, se for esta a estratégia adotada deve ser assinalado esse

facto (por exemplo, através de um estereótipo ou de uma anotação)

junto à classe-associação.

Sala

Aluno

Disciplina

Professor

Data_Início Data_Fim Disciplina

(7)

As associações representam responsabilidades:

No diagrama isso significa que há um ou mais métodos associados a

“Cliente” que definem que “Encomenda(s)” é que um cliente fez

Associações: Perspectiva de Especificação

25 “Cliente” que definem que “Encomenda(s)” é que um cliente fez

Do mesmo modo haverá

métodos em “Encomenda”

que informam

de que “Cliente” fez

determinada encomenda, e

de que “Linha(s) de

Encomenda” constituem

uma “Encomenda”

Estas responsabilidades

não implicam, no entanto,

estruturas de dados. O diagrama exprime apenas as interfaces e nada mais.

As associações representam agora a existência de ponteiros nos dois

sentidos, entre as classes ligadas pela associação

No diagrama isso significa que “Encomenda” tem

Associações: Perspectiva de Implementação

26 No diagrama isso significa que “Encomenda” tem

um campo que é uma

coleção de ponteiros para

”Linha(s) de Encomenda”, e

um ponteiro que aponta

para Clientes

A este nível não se podem

tirar, a partir das

associações, quaisquer

conclusões acerca das

interfaces. As operações sobre as classes é que darão essa informação.

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

As associações descrevem a rede de relações estruturais que existem

entre as classes e que dão origem às ligações entre os objetos,

instâncias dessas classes.

Associações: Navegabilidade

27 instâncias dessas classes.

Essas ligações podem ser vistas como canais de navegabilidade entre

os objetos.

Por omissão, as associações são navegáveis nos dois sentidos, embora

em alguns casos, só interesse um dos sentidos da navegabilidade.

Exemplo: as instâncias do objeto A veem as instâncias do objeto B,

mas as instâncias do objeto B, não veem as instâncias do objeto A.

A

B

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Quando se pretende exprimir a navegabilidade num só sentido,

coloca-se uma coloca-seta sobre o papel para o qual a navegabilidade é possível

Temos assim responsabilidades assimétricas

Associações: Navegabilidade

28 Temos assim responsabilidades assimétricas

Exemplo com navegabilidade:

Encomenda

Cliente

significa que Encomenda

tem a responsabilidade de

dizer a que Cliente se

destina, mas Cliente não

tem a responsabilidade de

dizer que Encomendas lhe

Encomenda dataRecebida éPrepaga número:string preço:money Despacha()

Fecha() {se Encomenda.cliente.regimeCrédito é "fraco", então Encomenda.éPrepaga tem de ser

verdadeiro} 1 * Cliente nome endereço regimeCrédito(): string * 1

dizer que Encomendas lhe

correspondem.

Podia-se fazer o mesmo

tipo de considerações

acerca da navegabilidade

entre Linha de Encomenda

e Produto

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBI Linha de Encomenda quantidade: inteiro preço: money estáSatisfeita:Booleano Produto 1 * Cliente Institucional nomeContacto regimeCrédito limiteCrédito avisa() facturaParaMês(Inteiro) Empregado 0 .. 1 * Cliente Individual cartãoCrédito# {regimeCrédito == "fraco"}

(8)

A navegabilidade constitui um aspeto importante dos diagramas de

implementação e de especificação, mas não a nível conceptual

É

frequente

ver-se

um

diagrama

conceptual

que

começa

sem

Associações: Navegabilidade

29 É

frequente

ver-se

um

diagrama

conceptual

que

começa

sem

navegabilidade

e

que

depois

se

transforma

num

diagrama

de

especificação ou implementação, pela adição das navegabilidade.

Tem-se uma associação

unidirecional quando só há navegabilidade num sentido;

bidirecional quando as navegabilidades são nos dois sentidos.

Uma associação que só pode ser navegada num sentido pode ser vista

como uma meia associação, mostrando uma assimetria nos requisitos

de comunicação.

Uma associação sem setas é entendida como

bidirecional, ou

uma associação cujas navegabilidades não foram ainda definidas:

Associações: Navegabilidade

30 uma associação cujas navegabilidades não foram ainda definidas:

deve definir-se qual das interpretações se adota;

no caso dos diagramas a nível de especificação e de implementação é mais frequente

adotar-se a segunda

Se uma associação for bidirecional, isso significa que os dois papeis são

inversos um do outro.

Esta

propriedade

é

válida

para

as

três

perspetivas

(conceptual,

de

especificação e de implementação)

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Os atributos são características das classes

No caso mais geral, a notação para um atributo especifica o seu nome,

tipo e valor por omissão (default), bem como a sua visibilidade

Atributos

31 tipo e valor por omissão (default), bem como a sua visibilidade

Em UML, teremos:

visibility name: type = defaultValue

O conceito de visibilidade (visibility) é descrito mais à frente

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

Em geral os diagramas não indicam se um atributo é opcional ou obrigatório

(embora, em rigor, devesse fazê-lo)

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

As operações correspondem aos métodos da classe.

A sintaxe completa em UML para uma operação é a seguinte:

visibility name(parameter list): type = return-type-expression {property-string}

Operações

32 visibility name(parameter list): type = return-type-expression {property-string}

onde:

visibility (visibilidade) será descrita mais à frente

name é uma cadeia de caracteres

parameter-list contém argumentos (opcionais) cuja sintaxe é a mesma dos

atributos

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

(9)

É útil distinguir entre operações que alteram e não alteram o estado de

uma classe

Uma interrogação (query) é uma operação que obtém o valor de uma

Operações

33 Uma interrogação (query) é uma operação que obtém o valor de uma

classe sem alterar o seu estado observável.

As operações que alteram o estado observável são chamadas de

modificadores.

As interrogações podem ser executadas por qualquer ordem, mas os

modificadores exigem cuidados com a sequência de execução. O

melhor é não misturar operações dos dois tipos citados.

Outras designações:

métodos de obtenção (getting methods) - devolvem o valor de um campo

(e não fazem nada mais)

Operações

34 (e não fazem nada mais)

métodos de fixação (setting methods) - que colocam um valor num campo

(e nada mais fazem)

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

Uma operação é algo que se evoca sobre um objecto (a chamada ao

procedimento);

já o método é o corpo do procedimento.

É frequente confundirem-se os dois, mas importa fazer notar que a

operação não é mais do que a invocação do método. Havendo

polimorfismo, operação e método são distintos.

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

A UML define três tipos de visibilidade para os atributos e operações:

pública (simbolizada através do prefixo “+”)

que torna o elemento visível a todos os clientes da classe;

Visibilidade de Atributos e Operações

35 que torna o elemento visível a todos os clientes da classe;

protegida (simbolizada través do prefixo “#”)

que torna o elemento visível às subclasses da classe (aos respetivos descendentes);

privada (simbolizada através prefixo “-”)

que torna o elemento apenas visível à própria classe

Embora a indicação da visibilidade nem sempre figure de forma

explícita nos diagramas de classes, isso não significa que ela não seja

definida no modelo.

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Exemplo:

Visibilidade de Atributos e Operações

36 Cliente

Cliente

# Registar( ) + Alterar Dados( ) + CalcularIdade( ) Privado Público Protegido - BI - Nome - Morada - Telefone

(10)

A Generalização é um caso especial no diagrama de classes

noção de supertipo (superclasse) e subtipo (subclasse) na perspetiva de uma

relação pai-filho

Generalização

37 relação pai-filho

Especifica o relacionamento entre um elemento geral e um elemento

mais específico.

O

termo

generalização

especifica

uma

perspetiva

focada

numa

classificação de hierarquia.

Exemplo: um animal é um conceito mais geral do que um gato, um cão ou

um guaxim.

Inversamente, um gato é um conceito mais específico do que um animal.

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 subtipos (exceto no caso

Generalização

38 As classes obtidas por herança são denominadas subtipos (exceto no caso

dos diagramas de implementação, em que são designadas por subclasses)

O elemento mais específico contém informação que lhe é particular,

desde que continue completamente consistente com a descrição do

elemento mais geral.

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Um relacionamento de generalização significa um “é um” ou “é um tipo

de”. Exemplo: um gato “é um” animal.

O relacionamento de generalização é representado através de uma

Generalização

39 O relacionamento de generalização é representado através de uma

seta cuja ponta é um triângulo vazio, que aponta da classe mais

especializada para a mais geral.

Animal

Gato

Cão

Guaxim

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

No diagrama distinguem-se

os “clientes institucionais” e

os ”clientes individuais”,

Generalização

40

Cliente Nome Endereço

os ”clientes individuais”,

que, tendo algumas diferenças

entre si, têm também algumas

semelhanças.

Essas semelhanças podem ser

colocadas na classe “cliente”

Endereço regimeCredito(): string Cliente Institucional nomeContacto regimeCrédito limiteCrédito avisa() facturaParaMês(Inteiro) Cliente Individual cartãoCrédito#

(o supertipo) ficando as

outras classes (os subtipos)

com as características

que são diferentes.

Subtipos

_Supertipo

facturaParaMês(Inteiro)

(11)

As classes podem ter várias superclasses.

Quando é esse o caso, a generalização diz-se múltipla e várias setas

são desenhadas da subclasse para as várias superclasses.

Generalização

41 são desenhadas da subclasse para as várias superclasses.

A classe Tapetes voadores tem dois antecessores distintos:

a classe Tapetes, e

a classe Veículos.

Veículos

Terrestres Aéreos Tapetes

Aéreos

Tapetes voadores

Na perspetiva conceptual pode-se dizer que

“cliente institucional” será um subtipo

de “cliente” se todas as instâncias de

Generalização: Perspetiva Conceptual e de Especificação

42

Cliente Nome

de “cliente” se todas as instâncias de

“cliente institucional” forem também,

por definição, instâncias de “cliente”.

A ideia chave é que tudo o que se

estabelecer para “cliente” (associações,

atributos, operações) é também

válido para “cliente institucional”.

Nome Endereço regimeCredito(): string Cliente Institucional nomeContacto regimeCrédito limiteCrédito avisa() facturaParaMês(Inteiro) Cliente Individual cartãoCrédito# {regimeCrédito()=="fraco"}

válido para “cliente institucional”.

Na perspetiva de especificação,

a generalização significa que a interface

do subtipo tem que incluir todos os elementos da interface do supertipo.

Diz-se que a interface do subtipo está conforme com a interface do supertipo.

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBI Subtipo Supertipo

{regimeCrédito()=="fraco"}

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Na perspetiva de implementação,

A generalização está associada ao fenómeno de herança das linguagem de

programação orientadas para objetos.

Generalização: Perspetiva de Implementação

43 programação orientadas para objetos.

Fala-se aqui de subclasse e não de subtipos e considera-se que a subclasse

herda todos os métodos e campos da superclasse, podendo os métodos da

subclasse sobrepor-se aos métodos herdados.

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

O conceito de herança está presente, pois que

as subclasses (“filhos”) herdam da superclasse (“pai”) a estrutura em termos

de atributos e operações.

Generalização: Perspetiva de Implementação

44 de atributos e operações.

Assim, está implícito que

As subclasses “Cliente Institucional” e

“Cliente Individual” possuem

um nome, e

um endereço.

Cliente Nome Endereço regimeCredito(): string Cliente Institucional nomeContacto regimeCrédito limiteCrédito Cliente Individual cartãoCrédito#

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBI Subclasse Superclasse

limiteCrédito avisa()

(12)

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 de

Restrições

45 Os conceitos de associação, de atributo ou de generalização são, afinal de

contas, formas de especificar restrições.

Apesar disto, os conceitos chave dos diagramas de classe não permitem

exprimir todas as restrições.

Assim, há restrições que têm de ser expressas de forma explícita,

porque não caem em nenhuma das categorias previstas nos diagramas

de classes.

A sintaxe UML para exprimir restrições limita-se a indicar que devem

ser colocados entre {}.

Tudo o resto é livre, podendo

Restrições

46

Cliente

Tudo o resto é livre, podendo

ser expressas em

pseudolinguagem, para

enfatizar a legibilidade, ou

ser traduzidas por instruções

em código de programação.

Nome Endereço regimeCredito(): string Cliente Institucional nomeContacto regimeCrédito limiteCrédito Cliente Individual cartãoCrédito#

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBI Restrição: neste caso o regime de crédito só pode ser “fraco”

avisa()

{regimeCrédito()=="fraco"}

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Os conceitos até agora descritos, correspondem às notações chaves

dos diagramas de classes. Correspondem a cerca de 90% do esforço

na criação de diagramas de classes.

Conceitos Avançados

47 na criação de diagramas de classes.

Há,

no

entanto,

alguns

conceitos

adicionais,

dos

quais

iremos

descrever alguns, os mais relevantes, podendo os restantes ser

consultados na bibliografia indicada no início do capítulo.

Iremos assim descrever:

Classes Associativas

Estereótipos

Interfaces e desenho do sistema

Agregação e Composição

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Surge da necessidade de obter mais informação de uma associação,

permitindo adicionar atributos, operações e outros aspectos.

Só existe em resultado da relação entre duas classes; por si só, não

Conceitos Avançados: Classes Associativas

48 Só existe em resultado da relação entre duas classes; por si só, não

terá significado.

Normalmente surgem nas relações de “Muitos para Muitos” e o nome

(13)

Exemplo:

pretende saber-se quando (período de tempo) em que cada empregado

trabalhou para a empresa

Conceitos Avançados: Classes Associativas

49 trabalhou para a empresa

poderíamos adicionar este atributo à classe Pessoa, mas trata-se realmente

de um facto acerca do relacionamento da pessoa com a empresa.

Emprego

Classe Associativa

Pessoa

Empregado Empregador

Empresa

*

Um estereótipo em UML é parte de um leque de mecanismos de

extensibilidade utilizável quando a semântica base do elemento de

modelação se revela insuficiente.

Conceitos Avançados: Estereótipos

50 modelação se revela insuficiente.

Cada elemento UML pode ter um ou mais estereótipos.

Permite, genericamente,

criar novas classes de elementos de modelação por cima do núcleo de

elementos pré-definidos pela UML,

mantendo um controlo sobre as extensões das classes de metamodelos.

É possível criar qualquer tipo de estereótipo, sendo os mais utilizados,

para as classes, os de interface e controlo.

Os estereótipos são normalmente mostrados entre aspas (por ex:,

«control»), mas podem também ser representados por um ícone.

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

O

estereótipo

de

«interface»

classifica

as

classes

que

apenas

disponibilizam

um

conjunto

de

operações

visíveis

externamente

(públicas).

Conceitos Avançados: Estereótipos

51 (públicas).

Uma classe com o estereótipo de «control» representa uma classe cujo

objetivo é conter um conjunto

de regras que controlam

determinadas operações do

sistema e que coordenam as

«control»

Estereótipo

«interface»

interações com as outras classes.

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBI «control» Controlo Acesso + VerificaAcesso() «interface» Gestão + Criar() + Apagar() + Ver()

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Interface:

Proporciona uma vista total ou parcial do conjunto dos vários serviços

proporcionados por um ou mais elementos.

Conceitos Avançados: Interfaces e Desenho do Sistema

52 proporcionados por um ou mais elementos.

Permite que o impacto das alterações seja limitado, podendo efetuar-se

alterações na classe sem afetar as classes restantes, desde que não se altere

a interface respetiva.

Permite separar o que é fornecido pela abstração da classe da forma como é

produzido.

É um grupo de operações que são utilizadas para especificar um serviço.

(14)

A UML representa as interfaces:

Utilizando pequenos círculos ligados por uma linha ao elemento que

proporciona os serviços descritos pela interface.

Conceitos Avançados: Interfaces e Desenho do Sistema

53 proporciona os serviços descritos pela interface.

uma classe

Em alternativa a interface pode representar-se por uma classe, com o

estereótipo «interface», mas sem atributos, apenas operações.

Conceitos Avançados: Interfaces e Desenho do Sistema

54 Encomenda

- NumeroE: long

- Data: date

- TipoEncomenda: string

- ValorTotal: long

+ Criar()

«interface»

Gestão

+ Criar()

+ Apagar()

+ Criar()

+ Apagar()

+ Ver()

+ AdicionaProduto()

+ CalculaValorTotal()

+ Apagar()

+ Ver()

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Os dependentes da interface podem utilizar todos ou alguns dos

serviços descritos na interface.

Uma relação de dependência surge quando uma classe recorre aos

Conceitos Avançados: Relação de Dependência

55 Uma relação de dependência surge quando uma classe recorre aos

serviços disponibilizados

por outra classe.

Quando um funcionário efetua uma consulta a uma encomenda, este terá de aceder aos

serviços disponibilizados pela classe Encomenda, através da interface Gestão, que

disponibiliza os serviços Criar(), Apagar() e

Ver() da classe Encomenda Encomenda

Funcionário

- BI: string - Nome: string - Morada: string

Dependência

Ver() da classe Encomenda

O serviço funciona como um contrato entre a classe e os seus clientes, que, por sua vez,

constroem os seus serviços com base na interface estabelecida - NumeroE: long - Data: date - TipoEncomenda: string - ValorTotal: long + Criar() + Apagar() + Ver() + AdicionaProduto() + CalculaValorTotal() «interface» Gestão + Criar() + Apagar() + Ver()

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

A relação de Realização mostra que existe um contrato entre a classe

que utiliza o serviço e outra que garante a sua realização.

A classe Funcionário, através da interface Gestão, pode Criar, Apagar e Ver

Conceitos Avançados: Relação de Dependência e Realização

56 A classe Funcionário, através da interface Gestão, pode Criar, Apagar e Ver

encomendas.

A classe Cliente apenas pode

visualizar as encomendas,

uma vez que a respetiva

interface só disponibiliza a

operação Ver()

Encomenda - NumeroE: long - Data: date «interface» Funcionário - BI: string - Nome: string - Morada: string «interface» Cliente - BI: string - Nome: string - Morada: string + Pré-Registo()

operação Ver()

A classe Encomenda

disponibiliza duas interfaces:

Gestão e

Visualizar.

- Data: date - TipoEncomenda: string - ValorTotal: long + Criar() + Apagar() + Ver() + AdicionaProduto() + CalculaValorTotal() «interface» Gestão + Criar() + Apagar() + Ver() «interface» Visualizar + Ver() Realização

(15)

Podemos construir um diagrama de classes com 3 níveis, dividido em

três camadas de serviços:

1. Serviços de interface - fornece a interface para os utilizadores para

Conceitos Avançados: Interface e Desenho do Sistema

57

1. Serviços de interface - fornece a interface para os utilizadores para

apresentação e recolha de dados.

2. Serviços de negócio - engloba as classes que possuem as regras

fundamentais de negócio, respondendo aos pedidos da camada 1 ou de

outros serviços da própria camada, através da execução de uma operação

específica sobre dados relevantes com base em regras de negócio.

3. Serviços de Dados - permite manter, atualizar e aceder aos dados

persistentes.

Nesta arquitetura, quando os dados residem num servidor de base de

dados, os serviços de negócio asseguram o acesso ao serviço de dados,

isolando o seu acesso.

Como as regras de negócio tendem a ser alteradas com relativa

frequência, os serviços de negócio são úteis para encapsular estas

regras,

separando

a

tarefa

a

desempenhar

da

forma

como

é

Conceitos Avançados: Diagrama de Classe com 3 níveis

58 regras,

separando

a

tarefa

a

desempenhar

da

forma

como

é

desempenhada.

Ao isolar os serviços de negócio dos serviços de interface e dados, este

diagrama permite ir ao encontro do paradigma de desenvolvimento de

aplicações cliente/servidor, promovendo a reutilização, escalabilidade e

manutenção dos componentes.

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Conceitos Avançados: Diagrama de Classe com 3 níveis

59

A classe de interface “Ecrã Pré-Registo” necessita da classe clientes,

nos serviços de negócio, para _Cliente

Serviços de Negócio

Serviços de Interface Serviços de Dados

«user interface» _{«data connection»} nos serviços de negócio, para

efetuar o registo, invocando para tal a operação pré-registo. Por sua vez, a classe cliente necessita de guardar num suporte físico os dados do cliente que está a

efetuar o pré-registo, utilizando os serviços de dados através da classe

SD_Cliente.

Esquema semelhante se aplica para as classes “Ecrã Reservas” e “Ecrã

Cliente {persistence = Yes} - BI - Nome - Morada + Pré-Registo() {sequencial} «control» Controlo Acesso + VerificaAcesso() 0..* 1 efetua Encomenda «data connection» Encomenda «user interface» Ecrã Encomenda «user interface» Ecrã Reservas «user interface» Ecrã Pré-Registo - BI - Nome - Morada + Criar() + Apagar() + Consultar() + Actualizar() «data connection» SD_Cliente 0..* 1 efetua

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBI as classes “Ecrã Reservas” e “Ecrã

Encomenda”. Dado necessitarem de verificar se o cliente tem permissão, o que é feito invocando a classe

“Controlo de Acesso” (com estereótipo «control»), classe esta

que contém as regras de negócio que gerem o acesso ao sistema.

- NumeroE - Data - TipoEncomenda + Criar() {sequencial} - NumeroE - Data - TipoEncomenda + Criar() + Apagar() + Consultar() + Actualizar() Encomenda {persistence = Yes} Encomenda

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Conceitos Avançados: Diagrama de Classe com 3 níveis

60

As classes persistentes “Persistence=Yes” necessitam que

os seus objetos sejam gravados Cliente Serviços de Negócio

Serviços de Interface Serviços de Dados

«user interface» «data connection» os seus objetos sejam gravados

fisicamente numa base de dados ou outro meio.

A classe “Controlo”, neste caso, não necessita de gravar os seus dados, utilizando os serviços da classe

“Cliente”.

No entanto, se fosse necessário manter um registo de acessos específicos da classe ou de regras

de negócio, esta seria marcada

Cliente {persistence = Yes} - BI - Nome - Morada + Pré-Registo() {sequencial} «control» Controlo Acesso + VerificaAcesso() 0..* 1 efetua Encomenda «data connection» Encomenda «user interface» Ecrã Encomenda «user interface» Ecrã Reservas «user interface» Ecrã Pré-Registo - BI - Nome - Morada + Criar() + Apagar() + Consultar() + Actualizar() «data connection» SD_Cliente 0..* 1 efetua

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBI de negócio, esta seria marcada

como persistente e teria uma classe correspondente nos serviços de

dados. - NumeroE - Data - TipoEncomenda + Criar() {sequencial} - NumeroE - Data - TipoEncomenda + Criar() + Apagar() + Consultar() + Actualizar() Encomenda {persistence = Yes} Encomenda

(16)

A parte física dos dados dependerá do tipo de base de dados

(relacional ou objeto):

Se

base

de

dados

relacional,

aplicam-se

as

regras

de

transposição

Conceitos Avançados: Diagrama de Classe com 3 níveis

61 Se

base

de

dados

relacional,

aplicam-se

as

regras

de

transposição

semelhantes às já tratadas em análise de sistemas, a propósito da

transposição do modelo E-R para o modelo relacional.

Se B.D. objeto ou relacional-objeto, a transposição será mais direta, e será

tratada numa disciplina do plano de estudos do curso “Tópicos Avançados de

bases de Dados”.

A agregação num diagrama de classes pretende demonstrar a relação

que um todo é composto por partes (part-of relationship).

Representa

uma

relação

assimétrica,

na

qual

uma

das

partes

Conceitos Avançados: Agregação e Composição

62 Representa

uma

relação

assimétrica,

na

qual

uma

das

partes

desempenha um papel mais importante do que a outra.

Restaurante

Mesa

1 1..*

- Nome - Morada

- Num_mesa

Um restaurante possui um conjunto de mesas

(o losângulo sem enchimento pretende

representar o conceito de agregação)

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

Os critérios seguintes implicam uma agregação, mas o oposto nem

sempre

é

verdade,

ou

seja,

a

agregação

não

os

implica

necessariamente:

Conceitos Avançados: Agregação e Composição

63 necessariamente:

Uma classe é parte de outra classe (o todo é composto por partes)

Os valores de um atributo de uma classe propagam-se aos atributos de outra

classe.

Uma ação numa classe implica uma ação na outra classe.

Os objetos de uma classe estão subordinados aos objetos da outra classe.

Em casos de dúvida quanto à existência de agregação, a associação

simples será preferível: lembremo-nos de que é necessário escolher

uma solução que implique o acoplamento mais fraco.

Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]

A composição:

é uma agregação com um significado mais forte existindo uma dependência

direta entre as duas classes (se a parte deixar de existir, o todo também

Conceitos Avançados: Agregação e Composição

64 direta entre as duas classes (se a parte deixar de existir, o todo também

desaparece); dito de outra forma, a parte vive e morre com o todo.

qualquer remoção do todo implica a eliminação em cascata das partes.

Na composição a multiplicidade do lado do todo não ultrapassa o um,

ao contrário da agregação.

Encomenda ItemEncomenda

Não faz sentido

haver linhas de

encomenda

(parte) sem a

encomenda

respetiva (todo).

Encomenda ItemEncomenda

1 1..*

- NúmeroE - Data - TipoEncomenda - Codtem - Quantidade Todo Composição Parte

(17)

Exemplo:

Um polígono contém uma coleção ordenada de pontos. Esses pontos podem

ser alterados com a edição do polígono (agregação)

Conceitos Avançados: Agregação e Composição

65 ser alterados com a edição do polígono (agregação)

A composição é utilizada para o pacote

gráfico do polígono (por ex., cor ou

textura); foi separado do polígono

porque diversos elementos gráficos

podem utilizar o mesmo pacote de

atributos gráficos.

Polígono

1 3..* {ordenado} agregação 1 1 composição

atributos gráficos.

O relacionamento com o pacote gráfico

é composição porque o pacote gráfico

será criado ou destruído com o polígono.

Classes compostas - classes implementadas por composição.

Ponto

Pacote Gráfico

Cor Textura

Os diagramas de classes são a espinha dorsal de praticamente todos os

métodos orientados para objetos, sendo, por isso, os mais usados.

São, no entanto, os mais ricos e complexos, pelo que se recomenda o

Quando Usar os Diagramas de Classes

66 São, no entanto, os mais ricos e complexos, pelo que se recomenda o

seu uso com alguns cuidados:

Não tentar usar todas as notações disponíveis.

Usar as mais complexas (aspetos avançados) quando forem estritamente

necessárias.

Adequar a perspetiva que se está a usar à fase em que o projeto se

encontra:

fazer diagramas conceptuais, se se está a fazer análise;

fazer diagramas de especificação, ao começar a pensar-se em software; e

fazer diagramas de implementação, apenas quando se pretender ilustrar uma solução