Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
2
Tópicos
ENGENHARIA DE SOFTWARE
Diagrama de Classes
Perspetivas dos Diagramas de Classes
Associações
Atributos
PARTE 2
Operações
Visibilidade dos Atributos e Operações
LINGUAGEM DE MODELAÇÃO UML
Generalização
Restrições
Conceitos Avançados
C AP. 6 . 1 – U M L – M O D E L AÇ ÃO D A E S T R U T U R A -
Quando Utilizar os Diagramas de Classes
D I AG R AM A D E C L AS S E S
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
3
Diagrama de Classes
4
Diagrama de Classes
Técnica central em qualquer método orientado para objetos
virtualmente todos os métodos incluem alguma variação desta técnica.
Descrevem
as classes - descrições abstratas e condensadas de um conjunto de objetos
do domínio da aplicação, caracterizadas pelos seus:
O diagrama de classes
É uma descrição formal da estrutura de objetos num sistema.
nome (ou identificador)
deve facilitar a compreensão do que a classe é e não o que faz
Descreve
qualquer classe deve ter um nome (mesmo que genérico e provisório)
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.
•
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)
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
5
Diagrama de Classes
6
Diagrama de Classes
A classe representada no exemplo é:
Os atributos das classes:
Triangulo
identificada pelo nome “Triângulo”
tem como atributos “base” e “altura”
da classe.
base
executa a operação “area()”,
Triangulo
Representam-se por baixo do nome
base: int
Pode apenas ser escrito o nome de um
altura
a partir dos atributos
altura: int
atributo ou pode ser colocada também
area()
está sujeita à restrição
area()
informação relativa ao seu tipo.
“{area <= 300}” que limita a 300
Os nomes dos atributos devem começar
o valor máximo da área a calcular
por minúsculas e quando são compostos
por mais de uma palavra, a primeira
Os nomes das classes
devem começar por maiúsculas e quando
{area <= 300}
letra de cada palavra deve ser maiúscula
{area <= 300}
(excetuando a primeira).
são compostos por mais de uma palavra,
a primeira letra de cada palavra
restrição
restrição
deve ser maiúscula.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
7
Diagrama de Classes
8
Diagrama de Classes
As operações das classes:
A forma usada para representar as classes depende do seu fim:
Representam-se por baixo dos atributos.
Pode apenas ser escrito o nome da
Triangulo
Numa fase de análise, usar uma
operação ou pode ser colocada também
Triangulo
representação simplificada
base: int
altura: int
informação relativa ao tipo de dados que
area(): int
devolve, ou pode ainda ser colocada
informação relativa aos parâmetros
Na fase de desenho devem ser
que recebe e seus tipos.
incluídos mais detalhes
Os nomes das operações seguem as
mesmas regras dos nomes dos atributos.
{area <= 300}
Triangulo
base: int
altura: int
area(): int
restrição
As classes estão relacionadas usando as mesmas relações estudadas
para os casos de uso: inclusão, generalização e associação.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
9
Diagrama de Classes
10
Diagrama de Classes
A relação de inclusão
Exemplo:
indica que uma classe usa a outra;
é 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.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
11
Perspectivas dos Diagramas de Classes
12
Perspectivas dos Diagramas de Classes
As classes podem ser entendidas sob três perspetivas:
Conceptual
Perspetiva conceptual
desenha-se a classe sem pensar no tipo de implementação que vai ter (i.e., é
a classe exprime um conceito abstrato no domínio de estudo
De especificação
independente da linguagem de programação que vai ser utilizada)
Perspetiva 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)
é 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,
De implementação
a classe é descrita pensando já na forma como vai ser implementada
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
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
13
Associações
14
Associações
As associações
Exemplo:
Representam relacionamentos entre instâncias de classes.
O papel de uma pessoa é ser o Empregado, enquanto que o papel de uma
São representadas através de uma linha que une as classes associadas.
empresa é ser o Empregador
São caracterizadas por possuir um nome e, quando necessário, incluir o
papel que as classes têm na relação.
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
O nome das associações é dado, de preferência, utilizando formas verbais
ativas (“trabalha para”) ou
papel
passivas (“é empregado por”),
embora haja quem defende o uso de substantivos em análise OO, uma vez
Pessoa
Empregado
Emprego
Empresa
Empregador
que assim é salientado o carácter estático da associação.
nome
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
15
Associações: Associação Reflexiva
16
Associações: Perspetiva Conceptual - Papéis
Uma classe pode ter associações consigo própria, significando que um
Papéis:
objeto da classe se relaciona com um ou mais objetos da mesma
O papel descreve como uma das classes vê a outra classe na associação.
classe.
Cada associação binária tem dois papeis (“roles”), que correspondem a cada
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
Subordinado
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,
-Nome
-Morada
enquanto que o papel de uma disciplina é Ser lecionada por professor
Chefiar
Disciplina
Professor
Chefe
Lecionar
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Ser lecionada
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
17
Associações: Perspetiva Conceptual - Multiplicidade
18
Associações: Perspetiva Conceptual - Multiplicidade
Multiplicidade ou Cardinalidade:
Se fosse pretendido indicar ser possível algumas disciplinas não serem
Um papel tem multiplicidade (ou cardinalidade), que indica quantos objetos
lecionadas por algum professor, utilizaríamos “0..1”
de uma dada classe podem estar ligados a um objeto da outra classe.
Professor
No exemplo a seguir o “1 … *” significa
0..1
*
Lecionar
que cada professor pode ensinar várias disciplinas, e
Disciplina
Ser lecionada
que não há nenhuma disciplina que possa ser ensinada por vários professores.
Professor
1
*
Lecionar
Formas mais comuns de multiplicidade:
Disciplina
0..1 - Opcional
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
As cardinalidades representam limites superiores
0..* ou * - Zero a qualquer inteiro positivo objetos da classe
“*” significa qualquer coisa entre 0 e vários
1..* - Um a qualquer inteiro positivo objetos da classe
“1” representa o valor um e só um
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
19
Associações: Perspetiva Conceptual - Multiplicidade
Exemplos de multiplicidades mais frequente
20
Associações: Perspetiva Conceptual – Classe-associação
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
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.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
21
Associações: Perspetiva Conceptual – Classe-associação
22
Associações: Perspetiva Conceptual – Associações N-árias
Exemplo:
A maioria das associações são binárias, pois ligam duas classes.
a associação entre as classes “Pessoa” e
“Empresa” traduz as tarefas que
cada empregado realiza na empresa.
Mas, uma classe pode estar ligada a mais do que uma outra, através
das denominadas associações N-árias.
Para cada tarefa é mantido um conjunto de atributos.
Estas podem ser representadas por um losangulo apontado para as
A classe-associação “Tarefa” é representada visualmente como qualquer
outra classe, mas apresenta uma linha a tracejado a ligá-la à linha da
várias componentes da associação.
Exemplo:
associação.
Sala
a classe “Disciplina” resulta da
associação entre as classes
“Aluno”, “Professor” e “Sala”.
Aluno
Professor
Disciplina
Data_Início
Data_Fim
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
23
Associações: Perspetiva Conceptual - Multiplicidade
24
Associações: Perspetiva Conceptual - Multiplicidade
Exemplo de uma associação ternária e de uma classe-associação:
As associações N-árias podem geralmente ser transformadas em várias
A associação “Disciplina” relaciona as classes “Professor”, “Aluno” e “Sala”.
relações binárias entre a classe-associação e as restantes classes
Caso a associação tenha também atributos e/ou operações próprias, cria-se
participantes.
uma classe-associação, a qual é ligada ao losango por uma linha a tracejado.
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)
Sala
junto à classe-associação.
Sala
Sala
Aluno
Aluno
Disciplina
Data_Início
Data_Fim
Professor
Professor
Aluno
Disciplina
Professor
Disciplina
Data_Início
Data_Fim
Disciplina
Data_Início
Data_Fim
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
25
Associações: Perspectiva de Especificação
26
Associações: Perspectiva de Implementação
As associações representam responsabilidades:
As associações representam agora a existência de ponteiros nos dois
No diagrama isso significa que há um ou mais métodos associados a
“Cliente” que definem que “Encomenda(s)” é que um cliente fez
sentidos, entre as classes ligadas pela associação
No diagrama isso significa que “Encomenda” tem
Do mesmo modo haverá
um campo que é uma
métodos em “Encomenda”
coleção de ponteiros para
que informam
”Linha(s) de Encomenda”, e
de que “Cliente” fez
um ponteiro que aponta
determinada encomenda, e
para Clientes
de que “Linha(s) de
A este nível não se podem
Encomenda” constituem
tirar, a partir das
uma “Encomenda”
Estas responsabilidades
associações, quaisquer
não implicam, no entanto,
conclusões acerca das
estruturas de dados. O diagrama exprime apenas as interfaces e nada mais.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
interfaces. As operações sobre as classes é que darão essa informação.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
27
Associações: Navegabilidade
28
Associações: Navegabilidade
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.
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.
Engenharia de Software - 2011/2012
se uma seta sobre o papel para o qual a navegabilidade é possível
Temos assim responsabilidades assimétricas
Essas ligações podem ser vistas como canais de navegabilidade entre
A
Quando se pretende exprimir a navegabilidade num só sentido, coloca-
B
Carlos Barrico - Departamento Informática da UBI
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
correspondem.
Podia-se fazer o mesmo
tipo de considerações
acerca da navegabilidade
entre Linha de Encomenda
e Produto
Engenharia de Software - 2011/2012
Encomenda
Cliente
dataRecebida
éPrepaga
número:string
preço:money
1
*
Despacha()
Fecha()
nome
endereço
regimeCrédito(): string
{se Encomenda.cliente.regimeCrédito
é "fraco", então
Encomenda.éPrepaga tem de ser
verdadeiro}
1
*
Linha de Encomenda
quantidade: inteiro
preço: money
estáSatisfeita:Booleano
*
1
Produto
Cliente Institucional
nomeContacto
regimeCrédito
limiteCrédito
Cliente Individual
cartãoCrédito#
avisa()
facturaParaMês(Inteiro)
*
0 .. 1
Empregado
{regimeCrédito == "fraco"}
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
29
Associações: Navegabilidade
A navegabilidade constitui um aspeto importante dos diagramas de
frequente
ver-se
navegabilidade
e
um
que
diagrama
depois
se
conceptual
transforma
que
num
começa
diagrama
Uma associação sem setas é entendida como
bidirecional, ou
implementação e de especificação, mas não a nível conceptual
É
30
Associações: Navegabilidade
sem
de
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
especificação ou implementação, pela adição das navegabilidade.
adotar-se a segunda
Tem-se uma associação
Se uma associação for bidirecional, isso significa que os dois papeis são
unidirecional quando só há navegabilidade num sentido;
inversos um do outro.
bidirecional quando as navegabilidades são nos dois sentidos.
Esta
Uma associação que só pode ser navegada num sentido pode ser vista
propriedade
é
válida
para
as
três
perspetivas
(conceptual,
de
especificação e de implementação)
como uma meia associação, mostrando uma assimetria nos requisitos
de comunicação.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
31
Atributos
32
Operações
Os atributos são características das classes
As operações correspondem aos métodos da classe.
No caso mais geral, a notação para um atributo especifica o seu nome,
A sintaxe completa em UML para uma operação é a seguinte:
tipo e valor por omissão (default), bem como a sua visibilidade
visibility name(parameter list): type = return-type-expression {property-string}
onde:
Em UML, teremos:
visibility name: type = defaultValue
visibility (visibilidade) será descrita mais à frente
O conceito de visibilidade (visibility) é descrito mais à frente
name é uma cadeia de caracteres
Os atributos têm um valor único de cada vez
parameter-list contém argumentos (opcionais) cuja sintaxe é a mesma dos
Em geral os diagramas não indicam se um atributo é opcional ou obrigatório
atributos
return-type-expression é uma especificação opcional,
(embora, em rigor, devesse fazê-lo)
property-string indica valores de uma propriedade que se aplica à operação
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
33
Operações
34
Operações
É útil distinguir entre operações que alteram e não alteram o estado de
Outras designações:
métodos de obtenção (getting methods) - devolvem o valor de um campo
uma classe
Uma interrogação (query) é uma operação que obtém o valor de uma
(e não fazem nada mais)
métodos de fixação (setting methods) - que colocam um valor num campo
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.
(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.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
35
Visibilidade de Atributos e Operações
36
Visibilidade de Atributos e Operações
A UML define três tipos de visibilidade para os atributos e operações:
Exemplo:
pública (simbolizada através do prefixo “+”)
que torna o elemento visível a todos os clientes da classe;
Cliente
protegida (simbolizada través do prefixo “#”)
que torna o elemento visível às subclasses da classe (aos respetivos descendentes);
Privado
-
Público
# Registar( )
+ Alterar Dados( )
+ CalcularIdade( )
privada (simbolizada através prefixo “-”)
que torna o elemento apenas visível à própria classe
BI
Nome
Morada
Telefone
Protegido
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.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
37
Generalização
A Generalização é um caso especial no diagrama de classes
Em UML preferiu-se utilizar o termo generalização em vez do termo
noção de supertipo (superclasse) e subtipo (subclasse) na perspetiva de uma
relação pai-filho
mais específico.
termo
herança, já nosso conhecido.
As classes obtidas por herança são denominadas subtipos (exceto no caso
Especifica o relacionamento entre um elemento geral e um elemento
O
38
Generalização
dos diagramas de implementação, em que são designadas por subclasses)
O elemento mais específico contém informação que lhe é particular,
generalização
especifica
uma
perspetiva
focada
numa
classificação de hierarquia.
desde que continue completamente consistente com a descrição do
elemento mais geral.
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.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
39
Generalização
40
Generalização
Um relacionamento de generalização significa um “é um” ou “é um tipo
No diagrama distinguem-se
O relacionamento de generalização é representado através de uma
que, tendo algumas diferenças
especializada para a mais geral.
entre si, têm também algumas
semelhanças.
Essas semelhanças podem ser
Animal
colocadas na classe “cliente”
(o supertipo) ficando as
Cão
Guaxim
Nome
Endereço
os ”clientes individuais”,
seta cuja ponta é um triângulo vazio, que aponta da classe mais
Gato
Cliente
os “clientes institucionais” e
de”. Exemplo: um gato “é um” animal.
regimeCredito(): string
Cliente Institucional
Cliente Individual
nomeContacto
regimeCrédito
limiteCrédito
cartãoCrédito#
avisa()
facturaParaMês(Inteiro)
{regimeCrédito()=="fraco"}
outras classes (os subtipos)
com as características
Subtipos
Supertipo
que são diferentes.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
41
Generalização
As classes podem ter várias superclasses.
Na perspetiva conceptual pode-se dizer que
Quando é esse o caso, a generalização diz-se múltipla e várias setas
“cliente institucional” será um subtipo
Cliente
de “cliente” se todas as instâncias de
são desenhadas da subclasse para as várias superclasses.
Nome
Endereço
“cliente institucional” forem também,
A classe Tapetes voadores tem dois antecessores distintos:
a classe Tapetes, e
42
Generalização: Perspetiva Conceptual e de Especificação
regimeCredito(): string
por definição, instâncias de “cliente”.
Tapetes
Veículos
A ideia chave é que tudo o que se
a classe Veículos.
estabelecer para “cliente” (associações,
atributos, operações) é também
Terrestres
válido para “cliente institucional”.
Aéreos
Cliente Institucional
Cliente Individual
nomeContacto
regimeCrédito
limiteCrédito
cartãoCrédito#
avisa()
facturaParaMês(Inteiro)
{regimeCrédito()=="fraco"}
Na perspetiva de especificação,
a generalização significa que a interface
Subtipo
Supertipo
do subtipo tem que incluir todos os elementos da interface do supertipo. Diz-
Tapetes voadores
se que a interface do subtipo está conforme com a interface do supertipo.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
43
Generalização: Perspetiva de Implementação
44
Generalização: Perspetiva de Implementação
Na perspetiva de implementação,
O conceito de herança está presente, pois que
A generalização está associada ao fenómeno de herança das linguagem de
programação orientadas para objetos.
as subclasses (“filhos”) herdam da superclasse (“pai”) a estrutura em termos
de atributos e operações.
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.
Cliente
Assim, está implícito que
Nome
Endereço
As subclasses “Cliente Institucional” e
regimeCredito(): string
“Cliente Individual” possuem
um nome, e
um endereço.
Cliente Institucional
Cliente Individual
nomeContacto
regimeCrédito
limiteCrédito
cartãoCrédito#
avisa()
facturaParaMês(Inteiro)
{regimeCrédito()=="fraco"}
Subclasse
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Superclasse
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
45
Restrições
46
Restrições
O próprio facto de se desenhar um diagrama de classes significa que se
estão a respeitar restrições.
A sintaxe UML para exprimir restrições limita-se a indicar que devem
ser colocados entre {}.
Os conceitos de associação, de atributo ou de generalização são, afinal de
contas, formas de especificar restrições.
Cliente
Tudo o resto é livre, podendo
Nome
Endereço
ser expressas em
Apesar disto, os conceitos chave dos diagramas de classe não permitem
exprimir todas as restrições.
regimeCredito(): string
pseudolinguagem, para
enfatizar a legibilidade, ou
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
Cliente Institucional
ser traduzidas por instruções
nomeContacto
regimeCrédito
limiteCrédito
em código de programação.
de classes.
Cliente Individual
cartãoCrédito#
avisa()
facturaParaMês(Inteiro)
{regimeCrédito()=="fraco"}
Restrição: neste caso o regime de crédito só pode ser “fraco”
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
47
Conceitos Avançados
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.
Há,
no
entanto,
48
Conceitos Avançados: Classes Associativas
alguns
conceitos
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
adicionais,
dos
quais
iremos
descrever alguns, os mais relevantes, podendo os restantes ser
consultados na bibliografia indicada no início do capítulo.
terá significado.
Normalmente surgem nas relações de “Muitos para Muitos” e o nome
da classe é dado pelo nome da associação.
Iremos assim descrever:
Classes Associativas
Estereótipos
Interfaces e desenho do sistema
Agregação e Composição
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
49
Conceitos Avançados: Classes Associativas
50
Conceitos Avançados: Estereótipos
Exemplo:
Um estereótipo em UML é parte de um leque de mecanismos de
pretende saber-se quando (período de tempo) em que cada empregado
trabalhou para a empresa
extensibilidade utilizável quando a semântica base do elemento de
modelação se revela insuficiente.
poderíamos adicionar este atributo à classe Pessoa, mas trata-se realmente
de um facto acerca do relacionamento da pessoa com a empresa.
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
Emprego
Classe Associativa
elementos pré-definidos pela UML,
Data_Início
Data_Fim
mantendo um controlo sobre as extensões das classes de metamodelos.
É possível criar qualquer tipo de estereótipo, sendo os mais utilizados,
Pessoa
Empregado
para as classes, os de interface e controlo.
Empresa
Empregador
Os estereótipos são normalmente mostrados entre aspas (por ex:,
*
*
Engenharia de Software - 2011/2012
«control»), mas podem também ser representados por um ícone.
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
51
Conceitos Avançados: Estereótipos
O
estereótipo
disponibilizam
de
um
«interface»
conjunto
de
classifica
as
operações
classes
visíveis
que
apenas
externamente
Uma classe com o estereótipo de «control» representa uma classe cujo
Proporciona uma vista total ou parcial do conjunto dos vários serviços
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
objetivo é conter um conjunto
a interface respetiva.
de regras que controlam
Estereótipo
determinadas operações do
Permite separar o que é fornecido pela abstração da classe da forma como é
produzido.
sistema e que coordenam as
interações com as outras classes.
Interface:
proporcionados por um ou mais elementos.
(públicas).
«control»
Controlo Acesso
+ VerificaAcesso()
Engenharia de Software - 2011/2012
52
Conceitos Avançados: Interfaces e Desenho do Sistema
«interface»
Gestão
É um grupo de operações que são utilizadas para especificar um serviço.
+ Criar()
+ Apagar()
+ Ver()
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
53
Conceitos Avançados: Interfaces e Desenho do Sistema
54
Conceitos Avançados: Interfaces e Desenho do Sistema
A UML representa as interfaces:
Em alternativa a interface pode representar-se por uma classe, com o
Utilizando pequenos círculos ligados por uma linha ao elemento que
estereótipo «interface», mas sem atributos, apenas operações.
proporciona os serviços descritos pela interface.
Encomenda
uma classe
-
«interface»
Gestão
+ Criar()
+ Apagar()
+ Ver()
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
NumeroE: long
Data: date
TipoEncomenda: string
ValorTotal: long
+
+
+
+
+
Engenharia de Software - 2011/2012
Criar()
Apagar()
Ver()
AdicionaProduto()
CalculaValorTotal()
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
55
Conceitos Avançados: Relação de Dependência
Os dependentes da interface podem utilizar todos ou alguns dos
serviços descritos na interface.
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
Engenharia de Software - 2011/2012
A classe Funcionário, através da interface Gestão, pode Criar, Apagar e Ver
encomendas.
serviços disponibilizados
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
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.
Uma relação de dependência surge quando uma classe recorre aos
por outra classe.
56
Conceitos Avançados: Relação de Dependência e Realização
A classe Cliente apenas pode
Funcionário
- BI: string
- Nome: string
- Morada: string
visualizar as encomendas,
Cliente
Funcionário
- BI: string
- Nome: string
- Morada: string
- BI: string
- Nome: string
- Morada: string
+ Pré-Registo()
Dependência
uma vez que a respetiva
interface só disponibiliza a
Encomenda
«interface»
Gestão
+ Criar()
+ Apagar()
+ Ver()
-
NumeroE: long
Data: date
TipoEncomenda: string
ValorTotal: long
+
+
+
+
+
Criar()
Apagar()
Ver()
AdicionaProduto()
CalculaValorTotal()
Carlos Barrico - Departamento Informática da UBI
operação Ver()
A classe Encomenda
disponibiliza duas interfaces:
Gestão e
Encomenda
«interface»
Gestão
+ Criar()
+ Apagar()
+ Ver()
-
NumeroE: long
Data: date
TipoEncomenda: string
ValorTotal: long
+
+
+
+
+
Criar()
Apagar()
Ver()
AdicionaProduto()
CalculaValorTotal()
«interface»
Visualizar
+ Ver()
Realização
Visualizar.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
57
Conceitos Avançados: Interface e Desenho do Sistema
58
Conceitos Avançados: Diagrama de Classe com 3 níveis
Podemos construir um diagrama de classes com 3 níveis, dividido em
Como as regras de negócio tendem a ser alteradas com relativa
três camadas de serviços:
frequência, os serviços de negócio são úteis para encapsular estas
1. Serviços de interface - fornece a interface para os utilizadores para
regras, separando a
apresentação e recolha de dados.
tarefa
a desempenhar da
forma como
é
desempenhada.
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
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
específica sobre dados relevantes com base em regras de negócio.
3. Serviços de Dados - permite manter, atualizar e aceder aos dados
manutenção dos componentes.
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.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
59
Conceitos Avançados: Diagrama de Classe com 3 níveis
A classe de interface “Ecrã PréRegisto” necessita da classe clientes,
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.
Serviços de Interface
«user interface»
Ecrã Pré-Registo
«user interface»
Ecrã Reservas
Esquema semelhante se aplica para
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.
Engenharia de Software - 2011/2012
Serviços de Negócio
Serviços de Dados
Cliente
«data connection»
{persistence = Yes}
- BI
- Nome
- Morada
+ Pré-Registo() {sequencial}
«control»
SD_Cliente
- BI
- Nome
- Morada
1
efetua
Controlo Acesso
«user interface»
60
Conceitos Avançados: Diagrama de Classe com 3 níveis
+
+
+
+
+ VerificaAcesso()
Ecrã Encomenda
«data connection»
Encomenda
Encomenda
{persistence = Yes}
- NumeroE
- Data
- TipoEncomenda
+ Criar() {sequencial}
1
0..*
0..*
- NumeroE
- Data
- TipoEncomenda
+
+
+
+
Serviços de Interface
«user interface»
Ecrã Pré-Registo
«user interface»
Criar()
Apagar()
Consultar()
Actualizar()
efetua
As classes persistentes
“Persistence=Yes” necessitam que
os seus objetos sejam gravados
fisicamente numa base de dados ou
outro meio.
Ecrã Reservas
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
como persistente e teria uma classe
correspondente nos serviços de
dados.
Criar()
Apagar()
Consultar()
Actualizar()
Carlos Barrico - Departamento Informática da UBI
Serviços de Negócio
Cliente
«data connection»
{persistence = Yes}
- BI
- Nome
- Morada
+ Pré-Registo() {sequencial}
«control»
efetua
Controlo Acesso
+
+
+
+
Ecrã Encomenda
1
0..*
0..*
«data connection»
Encomenda
Encomenda
{persistence = Yes}
- NumeroE
- Data
- TipoEncomenda
Criar()
Apagar()
Consultar()
Actualizar()
efetua
+ VerificaAcesso()
+ Criar() {sequencial}
Engenharia de Software - 2011/2012
SD_Cliente
- BI
- Nome
- Morada
1
«user interface»
Serviços de Dados
- NumeroE
- Data
- TipoEncomenda
+
+
+
+
Criar()
Apagar()
Consultar()
Actualizar()
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
61
Conceitos Avançados: Diagrama de Classe com 3 níveis
A parte física dos dados dependerá do tipo de base de dados
(relacional ou objeto):
Se
base
de
dados
62
Conceitos Avançados: Agregação e Composição
A agregação num diagrama de classes pretende demonstrar a relação
que um todo é composto por partes (part-of relationship).
relacional,
aplicam-se
as
regras
de
transposição
semelhantes às já tratadas em análise de sistemas, a propósito da
Representa
uma
relação
assimétrica,
na
qual
uma
das
partes
desempenha um papel mais importante do que a outra.
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”.
Mesa
Restaurante
- Nome
- Morada
- Num_mesa
1
1..*
Um restaurante possui um conjunto de mesas
(o losângulo sem enchimento pretende
representar o conceito de agregação)
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
63
Conceitos Avançados: Agregação e Composição
Os critérios seguintes implicam uma agregação, mas o oposto nem
sempre
é
verdade,
ou
seja,
64
Conceitos Avançados: Agregação e Composição
a
agregação
não
os
implica
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
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
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,
classe.
Uma ação numa classe implica uma ação na outra classe.
ao contrário da agregação.
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.
Não faz sentido
haver linhas de
encomenda
(parte) sem a
encomenda
respetiva (todo).
ItemEncomenda
Encomenda
- NúmeroE
- Data
- TipoEncomenda
1
1..*
Composição
- Codtem
- Quantidade
Parte
Todo
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
65
Conceitos Avançados: Agregação e Composição
Exemplo:
Os diagramas de classes são a espinha dorsal de praticamente todos os
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)
seu uso com alguns cuidados:
Polígono
gráfico do polígono (por ex., cor ou
textura); foi separado do polígono
1
Não tentar usar todas as notações disponíveis.
1
composição
agregação
porque diversos elementos gráficos
O relacionamento com o pacote gráfico
Adequar a perspetiva que se está a usar à fase em que o projeto se
1
{ordenado} 3..*
atributos gráficos.
encontra:
Ponto
Pacote Gráfico
é composição porque o pacote gráfico
fazer diagramas conceptuais, se se está a fazer análise;
Cor
Textura
fazer diagramas de especificação, ao começar a pensar-se em software; e
será criado ou destruído com o polígono.
fazer diagramas de implementação, apenas quando se pretender ilustrar uma solução
de implementação mais particular.
Classes compostas - classes implementadas por composição.
Carlos Barrico - Departamento Informática da UBI
Cap. 6.1 – UML - Modelação de Estrutura – Diagrama de Classes [Parte 2]
67
Quando Usar os Diagramas de Classes
Não desenhar modelos para tudo; é preferível concentrarmo-nos nas
áreas chave.
É melhor ter poucos diagramas, que se vão atualizando quando necessário,
do que ter muitos diagramas que se vão tornando obsoletos por falta de
atualização.
todo o custo começar a
pensar nos
pormenores
de
implementação demasiado cedo.
Para o conseguir, concentrar a atenção nas perspetivas de concepção e de
especificação.
Engenharia de Software - 2011/2012
Usar as mais complexas (aspetos avançados) quando forem estritamente
necessárias.
podem utilizar o mesmo pacote de
Engenharia de Software - 2011/2012
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
A composição é utilizada para o pacote
Evitar a
66
Quando Usar os Diagramas de Classes
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
2
Tópicos
ENGENHARIA DE SOFTWARE
Objetivos
Transição para os Objetos
Diagramas de Objetos
Representação das Ligações
PARTE 2
Objetos Compósitos
Quando Utilizar os Diagramas de Objetos
LINGUAGEM DE MODELAÇÃO UML
C AP. 6 . 2 – U M L – M O D E L AÇ ÃO D A E S T R U T U R A D I AG R AM A D E O B J E TO S
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
3
Objetivos
4
Transição para os Objetos
Facilitar a compreensão do processo de transição dos casos de uso para
Os diagramas de casos de uso
Centram o desenvolvimento sobre as necessidades do utilizador.
o universo dos objetos.
Familiarizar com os conceitos essenciais à utilização dos diagramas de
Têm um objetivo de eficácia: fazer o que deve ser feito.
Dizem o que o sistema deve fazer, mas não como deve fazê-lo.
objetos.
Esclarecer as relações entre os diagramas de objetos e diagramas de
Os diagramas de objetos
Satisfazem um objetivo complementar, o da eficiência: fazer corretamente;
classes.
Dizem como deve ser feito.
Esta complementaridade é importante porque um bom projeto de
software tem de satisfazer, em simultâneo, os objetivos de eficiência e
eficácia.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
5
Transição para os Objetos
6
Transição para os Objetos
Transição de um caso de uso para uma formulação orientada para
objetos
A realização de um caso de uso é um momento crucial da construção
do modelo: é o momento da passagem para objetos.
Note-se, contudo, que uma decomposição que siga de forma direta um
caso de uso, tal como ele foi criado, corre o risco de conduzir a uma
Caso de uso
<<realiza>>
Colaboração
abordagem estruturada clássica, com todos os inconvenientes de uma
estruturação em torno de funções.
Numa abordagem para objetos, realiza-se o caso de uso através de
<<participa>>
<<participa>>
uma colaboração entre objetos.
<<participa>>
Veremos que os cenários, instâncias dos casos de uso, serão
Objeto
Objeto
representados por diagramas de interação de dois tipos:
Objeto
de colaboração, e
de sequência.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
7
Transição para os Objetos
8
Diagramas de Objetos
Os diagramas de objetos ou diagramas de instâncias representam os
objetos e as ligações entre eles, exatamente da mesma maneira que
os diagramas de classes representam as classes e as associações entre
elas.
Tal como nos diagramas de classes, os diagramas de objetos, que não
são mais do que a instanciação dos diagramas de classes, representam
estruturas estáticas.
A notação utilizada pelos diagramas de objetos deriva diretamente da
dos diagramas de classes, com a diferença que apresenta os nomes
dos elementos, que são as instâncias, sublinhados.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
9
Diagramas de Objetos
10
Diagramas de Objetos
Cada objeto é representado por um retângulo que contém os seguintes
Exemplo:
elementos:
o nome da classe e do objeto, separados por “:” (diz-se que se tem o modelo
Modelo completo:
Nome do objeto: Classe
completo)
o nome da classe à qual o objeto pertence (diz-se que se tem o modelo
Modelo incompleto:
anónimo)
Nome do objeto
o nome do objeto, sem indicação da classe a que pertence (diz-se que se tem
o modelo incompleto)
Modelo anónimo:
: Classe
O modelo anónimo é utilizado quando se sabe a que classe pertence
o objeto, mas ainda não se atribuiu um nome para ele
O modelo incompleto corresponde a situações em que já se escolheu
o nome para o objeto, mas não se sabe ao certo a que classe pertence.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
11
Diagramas de Objetos
12
Representação das Ligações
Os retângulos que simbolizam os objetos podem igualmente comportar
um segundo compartimento que contém o valor dos atributos.
O tipo não será necessário dado que já foi definido no diagrama de
classes que engloba o dos objetos.
Os objetos de um diagrama encontram-se ligados por ligações que são
instâncias das associações entre as classes às quais pertencem os
objetos considerados.
Exemplo do diagrama de objetos (simplificado) para um automóvel e
Exemplo para um objeto anónimo da classe Automóvel, com um único
do diagrama de classes para o qual representa uma instância:
atributo, Cor, cujo valor é Vermelha:
: Automóvel
: Motor
Automóvel
1
1
Motor
1
: Automóvel
: Roda
: Roda
: Roda
: Roda
4
Roda
Cor = Vermelha
É uma instancia de
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
13
Representação das Ligações
14
Objetos Compósitos
Ligações que são instâncias de associações reflexivas podem ligar os
objetos a si mesmos.
Os objetos compostos a partir de sub-objetos podem ser representados
por objetos compósitos, que permitem reduzir a complexidade dos
Dois exemplos da mesma associação reflexiva:
diagramas.
Representam-se como objetos normais, exceto no facto de nos objetos
Chefe
*
1
compósitos serem colocados os sub-objetos como atributos.
Mostra que o Dinis é o
chefe de si mesmo
João: Pessoa
Trabalhador
Pessoa
Chefe
Exemplo de objeto compósitos:
Mostra que o João
é chefe do Luís
Chefe
Luís: Pessoa
Dinis: Pessoa
Objeto compósito
: Parte 1
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
Engenharia de Software - 2011/2012
: Parte 2
: Parte 3
Carlos Barrico - Departamento Informática da UBI
Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]
15
Objetos Compósitos
16
Quando Utilizar os Diagramas de Objetos
Os objetos compósitos são instâncias de classes compósitas, isto é, as
classes construídas a partir de outras classes por meio de forma forte
Os diagramas de objetos utilizam-se principalmente para
ilustrar o contexto da instanciação de uma classe (por exemplo, antes ou
depois de uma interação) e
de agregação (composição).
Exemplo da classe compósita Janela e do diagrama de objetos
facilitar a compreensão das estruturas de dados complexas, como as
estruturas recursivas.
compósito que representa uma das suas instâncias:
1
Janela
2
:Janela
Elevador
1
: Zona de desenho
:Elevador horizontal
1
Zona de desenho
:Elevador vertical
Classe compósita “Janela”
Engenharia de Software - 2011/2012
Objeto compósito “Janela”
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
2
Tópicos
ENGENHARIA DE SOFTWARE
Diagramas de Pacotes
Pacote = agrupamento por critérios lógicos
Conceitos de acoplamento e coesão
Pacotes
PARTE 2
Hierarquias de Pacotes
Acesso aos Elementos
LINGUAGEM DE MODELAÇÃO UML
Arte na Conceção
Exemplo
Quando utilizar os Diagramas de Pacotes
C AP. 6 . 3 – U M L – M O D E L AÇ ÃO D A E S T R U T U R A D I AG R AM A D E P AC O T E S
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
3
Objetivos
4
Diagramas de Pacotes
Familiarizar com os conceitos essenciais sobre Diagramas de Pacotes:
perceber o conceito de pacote e dependência
mostrar exemplos de diagramas de pacotes
compreender o papel dos diagramas de pacotes na minimização das
dependências
Trata-se do responder à questão:
“Como dividir um grande sistema em subsistemas?”
Na abordagem estruturada tradicional era usada a decomposição funcional,
na qual o sistema era mapeado como uma
função e,
esta dividida em
subfunções, sub-subfunções e assim sucessivamente
Havia uma separação entre processos e dados, e além da decomposição
funcional havia uma estrutura de dados
Algumas técnicas de engenharia de informação agrupavam registos de dados
em áreas e produziam matrizes que mostravam como as funções e registos
de dados interatuavam.
Mas agora surgem os objetos: a separação dos processos e dados
desapareceu, a decomposição funcional desapareceu, mas a velha
questão permanece – como dividir?
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
5
Pacotes
Solução: agrupar qualquer elemento de modelação UML (ex. Classes,
componentes,
6
Pacotes
interfaces,
etc.),
utilizando
critérios
lógicos,
em
unidades de mais alto nível, chamadas pacotes.
Os pacotes podem ser relacionados entre si, através de relações de
dependência.
Assim, criam-se os diagramas de pacotes - mostram os pacotes de
Interessante para projetos de grande dimensão, permitindo assim
manter a simplicidade dos diagramas ao possibilitar que cada diagrama
classes e as suas dependências.
Dependência - existe dependência entre dois elementos se, ao alterar-se a
definição de um dos elementos, isso levar a alterações no outro.
caiba numa página.
Permite-se o dividir da complexidade do sistema em partes mais
pequenas para uma melhor gestão.
Um pacote é representado graficamente como uma pasta, contendo
Com as classes, as dependências existem por várias razões:
Uma classe envia uma mensagem a outra;
uma classe tem outra como parte dos seus dados;
uma classe menciona outra como um parâmetro de uma operação.
Se uma classe altera a sua interface, então qualquer mensagem que enviar pode não
um nome.
ser mais válida.
Gestão de
Clientes
Gestão de
Encomendas
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
7
Hierarquias de Pacotes
8
Acesso aos Elementos
Cada um dos pacotes pode ser subdividido em mais pacotes e assim
sucessivamente, criando-se uma hierarquia de pacotes.
Não exagerar nos níveis de hierarquia, no máximo, 3.
Todos os elementos do sistema pertencem pelo menos a um pacote,
sendo o seu acesso público ou privado:
se público (representado graficamente com o prefixo +), os elementos estão
disponíveis nos outros pacotes;
se privado (representado
Gestão de Encomendas
Encomendas
Central
Divisão do pacote
Gestão de encomendas,
ilustrativa da hierarquia
de pacotes.
Encomendas
Balcão
graficamente com o prefixo -),
Encomendas
Telefone
só os elementos do próprio
pacote (incluindo subpacotes)
+ FormEncomenda
+ FormCatálogo
- Encomenda
é que lhe têm acesso.
Encomendas
Fax
Encomendas
Balcão
Os dois formulários são de acesso público
O elemento Encomenda é privado, sendo
apenas visível dentro do pacote.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
9
Arte na Conceção
10
Exemplo
A arte na conceção será: minimizar as dependências - os efeitos das
alterações são reduzidos e é necessário menor esforço para realizar
Interface Utilizador p/
Recolha de Encomendas
Interface Utilizador p/
Recolha de Encomendas
Interface Utilizador p/
Mailing List
alterações (lembremo-nos do que foi dito no cap. 1, acerca da coesão e
Pacote
Dependência
acoplamento).
Idealmente só as alterações na interface da classe poderão afetar
Aplicação p/ Recolha
De Encomendas
Aplicação de
Mailing List
qualquer outra.
Os pacotes não oferecem respostas de como reduzir as dependências
no sistema, mas ajudam a ver o que são as dependências: só
Encomendas
poderemos trabalhar na redução das dependências se pudermos vê-las
facilmente.
Os diagramas de pacotes são uma ferramenta chave para manter sob
controlo a estrutura global dum sistema.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Cap. 6.3 – UML - Modelação de Estrutura – Diagramas de Pacotes [Parte 2]
11
Quando utilizar Diagramas de Pacotes
São uma ferramenta vital para grandes projetos.
Usar sempre que um diagrama de classe que mostre o sistema todo
não for legível numa folha A4.
Pretende-se manter as dependências ao mínimo, pois que isso diminui
o acoplamento.
Os pacotes são também particularmente úteis nos testes, devendo ter
uma ou mais classes de teste para testar o comportamento do pacote.
Engenharia de Software - 2011/2012
Carlos Barrico - Departamento Informática da UBI
Clientes
2. As dependências não são transitivas: se uma classe no pacote Encomendas for
alterada, isso não implica alterações no pacote Interface Utilizador p/ Recolha de
Encomendas, mas unicamente indica que o pacote de aplicação de Recolha de
Encomendas precisa de ser olhado para ver se necessita de alterações. Só se a
interface do pacote Aplicação p/ Recolha de encomendas for alterada, então implicará
alterações ao pacote de Interface de utilizador para recolha de encomendas.
Engenharia de Software - 2011/2012
3. A aplicação Recolha
de Encomendas isola a
Interface de Utilizador
para Recolha de
Encomendas de
alterações nas
Encomendas.
Comportamento
clássico de arquitetura
em camadas.
1. Existe uma
dependência entre dois
pacotes se existir
qualquer dependência
entre quaisquer duas
classes nos pacotes.
Ex. Se qualquer classe
no pacote Mailing List
for dependente de
qualquer classe no
pacote Clientes, então
há uma dependência
entre os dois pacotes.
Carlos Barrico - Departamento Informática da UBI