• Nenhum resultado encontrado

ENGENHARIA DE SOFTWARE

N/A
N/A
Protected

Academic year: 2021

Share "ENGENHARIA DE SOFTWARE"

Copied!
24
0
0

Texto

(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

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

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



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.

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

{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).

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

{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.

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 Carlos Barrico Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBI



Exemplo:

Diagrama de Classes

10

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

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

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]



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.

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.

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



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

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

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

1

*

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

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



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

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

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



Exemplos de multiplicidades mais frequente

Associações: Perspetiva Conceptual - Multiplicidade

19

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]



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.

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



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”.

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

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

Data_Início Data_Fim

Aluno

Disciplina

Professor

Data_Início Data_Fim

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

Encomenda” constituem

uma “Encomenda”



Estas responsabilidades

não implicam, no entanto,

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

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



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



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.

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

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.

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

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.

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



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)

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

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)

(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,



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.

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



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.



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 Carlos Barrico Carlos Barrico Carlos Barrico ---- Departamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBIDepartamento Informática da UBI

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.

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]



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.

um guaxim.



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

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



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.

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

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

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

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.

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]



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()

facturaParaMês(Inteiro)

(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.

de classes.

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



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()

facturaParaMês(Inteiro)

{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

Data_Início Data_Fim

Classe Associativa

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

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,



É 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.

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

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.



É 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

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



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()

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

+ 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

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.

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



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.

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

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”.

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



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

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

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



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.

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

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:

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

de implementação mais particular.

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

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



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,

Quando Usar os Diagramas de Classes

67



É 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.



Evitar

a

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.

especificação.

(18)

ENGENHARIA DE SOFTWARE

PARTE 2

LINGUAGEM DE MODELAÇÃO UML

C

A P. 6 . 2 – 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

O

B J E TO 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



Objetivos



Transição para os Objetos



Diagramas de Objetos

Tópicos

2



Diagramas de Objetos



Representação das Ligações



Objetos Compósitos



Quando Utilizar os Diagramas de Objetos

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

Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]



Facilitar a compreensão do processo de transição dos casos de uso para

o universo dos objetos.



Familiarizar com os conceitos essenciais à utilização dos diagramas de

Objetivos

3



Familiarizar com os conceitos essenciais à utilização dos diagramas de

objetos.



Esclarecer as relações entre os diagramas de objetos e diagramas de

classes.

Cap. 6.2 – UML - Modelação de Estrutura – Diagramas de Objetos [Parte 2]



Os diagramas de casos de uso



Centram o desenvolvimento sobre as necessidades do utilizador.



Têm um objetivo de eficácia: fazer o que deve ser feito.

Transição para os Objetos

4



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.



Os diagramas de objetos



Satisfazem um objetivo complementar, o da eficiência: fazer corretamente;



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

software tem de satisfazer, em simultâneo, os objetivos de eficiência e

eficácia.

Referências

Documentos relacionados

Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software.. Comparado com outros modelos de

 “Gerência de Requisitos - Os requisitos do sistema são controlados de forma a estabelecer um perfil mínimo a ser utilizado pela engenharia de software e

Se n˜ ao for, construa um mundo — recorrendo ao software Tarski World — no qual as premissas sejam verdadeiras e a conclus˜ ao seja falsa.. Diga em que casos as “conclus˜ oes”

A amostragem da produção de café úmido em kg, utilizado na determinação do atributo PROD, foi utilizada também na determinação do atributo produtividade (PRODUT), por meio do

Observando o perfil de TPR do catalisador RuKL (figura 88), onde as temperaturas da primeira análise de TPR alcançaram valores de 222°C e 262°C e comparando com os

Já o Ministério do Turismo (2010), divulga não apenas as atribuições gerais que o guia deve cumprir, mas também as atribuições específicas de acordo com a

Neste contexto, este trabalho visa apresentar uma contribuição para aprofundar a discussão da relação entre parâmetros físico-químicos e ecotoxicológicos de

Juramento: “Prometo, no exercício da minha profissão, ser fiel aos princípios da ética, da honra e da honestidade, disseminar e praticar meus conhecimentos para promover