Cap 6 - UML - Modelacao Da Estrutura

ENGENHARIA DE SOFTWARE

PARTE 2

LINGUAGEM DE MODELAO UML

CAP. 6.1 UML MODELAO DA ESTRUTURA -

D IAGRAMA DE CLASSES

Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico Carlos Barrico Carlos Barrico ---- Departamento Informtica da UBIDepartamento Informtica da UBIDepartamento Informtica da UBIDepartamento Informtica da UBI

Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]

Diagrama de Classes

Perspetivas dos Diagramas de Classes

Associaes

Tpicos2

Associaes

Atributos

Operaes

Visibilidade dos Atributos e Operaes

Generalizao

Restries

Conceitos Avanados

Quando Utilizar os Diagramas de Classes



Tcnica central em qualquer mtodo orientado para objetos

virtualmente todos os mtodos incluem alguma variao desta tcnica.

O diagrama de classes

Diagrama de Classes3

O diagrama de classes

uma descrio formal da estrutura de objetos num sistema.

Descreve

os tipos de objetos no sistema, e

os vrios tipos de relacionamentos estticos entre eles.

Expressam, de uma forma geral, a estrutura esttica do sistema em termos

das classes e relacionamentos entre essas classes.



Descrevem

as classes - descries abstratas e condensadas de um conjunto de objetos

do domnio da aplicao, caracterizadas pelos seus:


do domnio da aplicao, caracterizadas pelos seus:

nome (ou identificador)

deve facilitar a compreenso do que a classe e no o que faz

qualquer classe deve ter um nome (mesmo que genrico e provisrio)

exemplo: a_ser_definido

atributos

operaes

restries restries

os relacionamentos estticos entre as classes

associaes (por ex., um cliente pode alugar vrios vdeos)

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



A classe representada no exemplo :

identificada pelo nome Tringulo

tem como atributos base e altura


Triangulo

tem como atributos base e altura

executa a operao area(),

a partir dos atributos

est sujeita restrio

{area


A relao de incluso

indica que uma classe usa a outra;

normalmente usada quando uma classe usada como argumento numa


normalmente usada quando uma classe usada como argumento numa

operao de outra classe.

A generalizao

uma relao entre uma classe geral (a superclasse ou pai) e uma ou mais

classes mais especficas (subclasses ou filhos);

As classes filho herdam todos os atributos e operaes da classe pai e podem

ter mais atributos e operaes que aqueles que herdam.ter mais atributos e operaes que aqueles que herdam.

Se uma operao num filho tem o mesmo nome da do pai est a fazer um

override (obrepr-se) do pai.

A associao

uma relao estrutural entre duas classes.



Exemplo:




As classes podem ser entendidas sob trs perspetivas:

Conceptual

a classe exprime um conceito abstrato no domnio de estudo

Perspectivas dos Diagramas de Classes11

a classe exprime um conceito abstrato no domnio de estudo

De especificao

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

de vista exterior e no em termos de implementao (i.e., pensa-se nas interfaces,

mas no na sua caracterizao interna)

De implementao

a classe descrita pensando j na forma como vai ser implementada



Perspetiva conceptual

desenha-se a classe sem pensar no tipo de implementao que vai ter (i.e.,

independente da linguagem de programao que vai ser utilizada)

Perspectivas dos Diagramas de Classes12

independente da linguagem de programao que vai ser utilizada)

Perspetiva de especificao

por vezes usado o conceito de tipo para designar as interfaces, quando

ainda no se pensou na sua forma de implementao, que pode ser variada.

De um modo geral,

h vantagem em pensar mais na perspetiva de especificao do que na

perspetiva de implementao, embora a segunda seja hoje mais popular.perspetiva de implementao, embora a segunda seja hoje mais popular.

fundamental reconhecer sempre em que perspetiva se est a

desenhar ou a ler um diagrama de classes



As associaes

Representam relacionamentos entre instncias de classes.

So representadas atravs de uma linha que une as classes associadas.

Associaes13

So representadas atravs de uma linha que une as classes associadas.

So caracterizadas por possuir um nome e, quando necessrio, incluir o

papel que as classes tm na relao.

O nome das associaes dado, de preferncia, utilizando formas verbais

ativas (trabalha para) ou

passivas ( empregado por),

embora haja quem defende o uso de substantivos em anlise OO, uma vez

que assim salientado o carcter esttico da associao.



Exemplo:

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

empresa ser o Empregador

Associaes14

empresa ser o Empregador

Alguns analistas do nomes a todas as associaes. Outros preferem s

atribuir nomes s associaes que tenham a ganhar em clareza com a

existncia de um nome

papel

Pessoa Empregado Emprego EmpregadorEmpresa


nome

Empregado Emprego Empregador


Uma classe pode ter associaes consigo prpria, significando que um

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

classe.

Associaes: Associao Reflexiva15

classe.

Este tipo de relao surge, tipicamente, em relaes de hierarquia (o

chefe de um conjunto de empregados tambm um empregado)

Exemplo: associao na mesma classe

Empregado

-Nome

Subordinado


-Nome-Morada

Chefe

Chefiar


Papis:

O papel descreve como uma das classes v a outra classe na associao.

Cada associao binria tem dois papeis (roles), que correspondem a cada

Associaes: Perspetiva Conceptual - Papis16

Cada associao binria 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 itlico a meio, entre as duas classes. Se no 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

Lecionar Ser lecionada


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.

Associaes: Perspetiva Conceptual - Multiplicidade17

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 vrias disciplinas, e

que no h nenhuma disciplina que possa ser ensinada por vrios professores.

Professor 1 *Disciplina


As cardinalidades representam limites superiores

* significa qualquer coisa entre 0 e vrios

1 representa o valor um e s um



Se fosse pretendido indicar ser possvel algumas disciplinas no serem

lecionadas por algum professor, utilizaramos 0..1


Formas mais comuns de multiplicidade:

0..1 - Opcional

1..1 ou 1 - Obrigatrio existir um objeto

Professor 0..1 *Disciplina


1..1 ou 1 - Obrigatrio 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



Exemplos de multiplicidades mais frequente




Numa relao de associao entre classes, a associao pode tambm

ter os seus prprios atributos (e eventualmente operaes), devendo

ser, por conseguinte, modelizada tambm como uma classe. Este tipo

Associaes: Perspetiva Conceptual Classe-associao20

ser, por conseguinte, modelizada tambm como uma classe. Este tipo

de classes designa-se por classe-associao.

Estas so representadas por uma linha a tracejado a lig-la linha da

associao entre as duas classes.



Exemplo:

a associao entre as classes Pessoa e Empresa traduz as tarefas que

cada empregado realiza na empresa.

Associaes: Perspetiva Conceptual Classe-associao21

cada empregado realiza na empresa.

Para cada tarefa mantido um conjunto de atributos.

A classe-associao Tarefa representada visualmente como qualquer

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

associao.



A maioria das associaes so binrias, pois ligam duas classes.

Mas, uma classe pode estar ligada a mais do que uma outra, atravs

das denominadas associaes N-rias.

Associaes: Perspetiva Conceptual Associaes N-rias22

das denominadas associaes N-rias.

Estas podem ser representadas por um losangulo apontado para as

vrias componentes da associao.

Exemplo:

a classe Disciplina resulta da

associao entre as classes

Aluno, Professor e Sala. Aluno

Sala

ProfessorAluno, Professor e Sala.


Aluno

Disciplina

Professor

Data_IncioData_Fim


Exemplo de uma associao ternria e de uma classe-associao:

A associao Disciplina relaciona as classes Professor, Aluno e Sala.

Caso a associao tenha tambm atributos e/ou operaes prprias, cria-se


Caso a associao tenha tambm atributos e/ou operaes prprias, cria-se

uma classe-associao, a qual ligada ao losango por uma linha a tracejado.

Aluno

Sala

Professor

Aluno Disciplina

Sala

Professor


DisciplinaData_IncioData_Fim

Aluno Disciplina Professor

Data_IncioData_Fim


As associaes N-rias podem geralmente ser transformadas em vrias

relaes binrias entre a classe-associao e as restantes classes

participantes.


participantes.

No entanto, se for esta a estratgia adotada deve ser assinalado esse

facto (por exemplo, atravs de um esteretipo ou de uma anotao)

junto classe-associao.Sala


Aluno

Disciplina

Professor

Data_IncioData_Fim

Disciplina


As associaes representam responsabilidades:

No diagrama isso significa que h um ou mais mtodos associados a

Cliente que definem que Encomenda(s) que um cliente fez

Associaes: Perspectiva de Especificao25

Cliente que definem que Encomenda(s) que um cliente fez

Do mesmo modo haver

mtodos em Encomenda

que informam

de que Cliente fez

determinada encomenda, e

de que Linha(s) de

Encomenda constituemEncomenda constituem

uma Encomenda

Estas responsabilidades

no implicam, no entanto,

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



As associaes representam agora a existncia de ponteiros nos dois

sentidos, entre as classes ligadas pela associao

No diagrama isso significa que Encomenda tem

Associaes: Perspectiva de Implementao26

No diagrama isso significa que Encomenda tem

um campo que uma

coleo de ponteiros para

Linha(s) de Encomenda, e

um ponteiro que aponta

para Clientes

A este nvel no se podem A este nvel no se podem

tirar, a partir das

associaes, quaisquer

concluses acerca das

interfaces. As operaes sobre as classes que daro essa informao.Engenharia de Software - 2011/2012 Carlos Barrico Carlos Barrico Carlos Barrico Carlos Barrico ---- Departamento Informtica da UBIDepartamento Informtica da UBIDepartamento Informtica da UBIDepartamento Informtica da UBI


As associaes descrevem a rede de relaes estruturais que existem

entre as classes e que do origem s ligaes entre os objetos,

instncias dessas classes.

Associaes: Navegabilidade27

instncias dessas classes.

Essas ligaes podem ser vistas como canais de navegabilidade entre

os objetos.

Por omisso, as associaes so navegveis nos dois sentidos, embora

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

Exemplo: as instncias do objeto A veem as instncias do objeto B,

mas as instncias do objeto B, no veem as instncias do objeto A.


A B


Quando se pretende exprimir a navegabilidade num s sentido, coloca-

se uma seta sobre o papel para o qual a navegabilidade possvel

Temos assim responsabilidades assimtricas


Temos assim responsabilidades assimtricas

Exemplo com navegabilidade: Encomenda Cliente

significa que Encomendatem a responsabilidade dedizer a que Cliente sedestina, mas Cliente notem a responsabilidade dedizer que Encomendas lhe

Encomenda

dataRecebida

Prepaga

nmero:string

preo:money

Despacha()

Fecha() {se Encomenda.cliente.regimeCrdito "fraco", ento

Encomenda.Prepaga tem de ser verdadeiro}

1

*

Cliente

nome

endereo

regimeCrdito(): string

* 1

dizer que Encomendas lhecorrespondem.

Podia-se fazer o mesmotipo de consideraesacerca da navegabilidadeentre Linha de Encomendae Produto


Linha de Encomenda

quantidade: inteiro

preo: money

estSatisfeita:Booleano

Produto

1

*

Cliente Institucional

nomeContacto

regimeCrdito

limiteCrdito

avisa()

facturaParaMs(Inteiro)

Empregado

0 .. 1

*

Cliente Individual

cartoCrdito#

{regimeCrdito == "fraco"}


A navegabilidade constitui um aspeto importante dos diagramas de

implementao e de especificao, mas no a nvel conceptual

frequente ver-se um diagrama conceptual que comea sem


frequente ver-se um diagrama conceptual que comea sem

navegabilidade e que depois se transforma num diagrama de

especificao ou implementao, pela adio das navegabilidade.

Tem-se uma associao

unidirecional quando s h navegabilidade num sentido;

bidirecional quando as navegabilidades so nos dois sentidos.

Uma associao que s pode ser navegada num sentido pode ser vista

como uma meia associao, mostrando uma assimetria nos requisitos

de comunicao.



Uma associao sem setas entendida como

bidirecional, ou

uma associao cujas navegabilidades no foram ainda definidas:


uma associao cujas navegabilidades no foram ainda definidas:

deve definir-se qual das interpretaes se adota;

no caso dos diagramas a nvel de especificao e de implementao mais frequente

adotar-se a segunda

Se uma associao for bidirecional, isso significa que os dois papeis so

inversos um do outro.

Esta propriedade vlida para as trs perspetivas (conceptual, de

especificao e de implementao)



Os atributos so caractersticas das classes

No caso mais geral, a notao para um atributo especifica o seu nome,

tipo e valor por omisso (default), bem como a sua visibilidade

Atributos31

tipo e valor por omisso (default), bem como a sua visibilidade

Em UML, teremos:

visibility name: type = defaultValue

O conceito de visibilidade (visibility) descrito mais frente

Os atributos tm um valor nico de cada vez

Em geral os diagramas no indicam se um atributo opcional ou obrigatrio

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



As operaes correspondem aos mtodos da classe.

A sintaxe completa em UML para uma operao a seguinte:

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

Operaes32

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

onde:

visibility (visibilidade) ser descrita mais frente

name uma cadeia de caracteres

parameter-list contm argumentos (opcionais) cuja sintaxe a mesma dos

atributos

return-type-expression uma especificao opcional, return-type-expression uma especificao opcional,

property-string indica valores de uma propriedade que se aplica operao



til distinguir entre operaes que alteram e no alteram o estado de

uma classe

Uma interrogao (query) uma operao que obtm o valor de uma

Operaes33

Uma interrogao (query) uma operao que obtm o valor de uma

classe sem alterar o seu estado observvel.

As operaes que alteram o estado observvel so chamadas de

modificadores.

As interrogaes podem ser executadas por qualquer ordem, mas os

modificadores exigem cuidados com a sequncia de execuo. O

melhor no misturar operaes dos dois tipos citados.



Outras designaes:

mtodos de obteno (getting methods) - devolvem o valor de um campo

(e no fazem nada mais)

Operaes34

(e no fazem nada mais)

mtodos de fixao (setting methods) - que colocam um valor num campo

(e nada mais fazem)

Tambm se deve reconhecer a distino entre operao e mtodo:

Uma operao algo que se evoca sobre um objecto (a chamada ao

procedimento);

j o mtodo o corpo do procedimento. j o mtodo o corpo do procedimento.

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

operao no mais do que a invocao do mtodo. Havendo

polimorfismo, operao e mtodo so distintos.



A UML define trs tipos de visibilidade para os atributos e operaes:

pblica (simbolizada atravs do prefixo +)

que torna o elemento visvel a todos os clientes da classe;

Visibilidade de Atributos e Operaes35

que torna o elemento visvel a todos os clientes da classe;

protegida (simbolizada travs do prefixo #)

que torna o elemento visvel s subclasses da classe (aos respetivos descendentes);

privada (simbolizada atravs prefixo -)

que torna o elemento apenas visvel prpria classe

Embora a indicao da visibilidade nem sempre figure de forma

explcita nos diagramas de classes, isso no significa que ela no seja

definida no modelo.



Exemplo:

Visibilidade de Atributos e Operaes36

ClienteCliente

# Registar( )+ Alterar Dados( )+ CalcularIdade( )

Privado

Pblico

Protegido

- BI- Nome- Morada- Telefone



A Generalizao um caso especial no diagrama de classes

noo de supertipo (superclasse) e subtipo (subclasse) na perspetiva de uma

relao pai-filho

Generalizao37

relao pai-filho

Especifica o relacionamento entre um elemento geral e um elemento

mais especfico.

O termo generalizao especifica uma perspetiva focada numa

classificao de hierarquia.

Exemplo: um animal um conceito mais geral do que um gato, um co ou

um guaxim.um guaxim.

Inversamente, um gato um conceito mais especfico do que um animal.



Em UML preferiu-se utilizar o termo generalizao em vez do termo

herana, j nosso conhecido.

As classes obtidas por herana so denominadas subtipos (exceto no caso

Generalizao38

As classes obtidas por herana so denominadas subtipos (exceto no caso

dos diagramas de implementao, em que so designadas por subclasses)

O elemento mais especfico contm informao que lhe particular,

desde que continue completamente consistente com a descrio do

elemento mais geral.



Um relacionamento de generalizao significa um um ou um tipo

de. Exemplo: um gato um animal.

O relacionamento de generalizao representado atravs de uma

Generalizao39

O relacionamento de generalizao representado atravs de uma

seta cuja ponta um tringulo vazio, que aponta da classe mais

especializada para a mais geral.

Animal


Gato Co Guaxim


No diagrama distinguem-se

os clientes institucionais e

os clientes individuais,

Generalizao40

Cliente

NomeEndereo os clientes individuais,

que, tendo algumas diferenas

entre si, tm tambm algumas

semelhanas.

Essas semelhanas podem ser

colocadas na classe cliente

Endereo

regimeCredito(): string


nomeContactoregimeCrditolimiteCrdito

avisa()facturaParaMs(Inteiro)

Cliente Individual

cartoCrdito#

(o supertipo) ficando as

outras classes (os subtipos)

com as caractersticas

que so diferentes.


Subtipos Supertipo

facturaParaMs(Inteiro){regimeCrdito()=="fraco"}


As classes podem ter vrias superclasses.

Quando esse o caso, a generalizao diz-se mltipla e vrias setas

so desenhadas da subclasse para as vrias superclasses.

Generalizao41

so desenhadas da subclasse para as vrias superclasses.

A classe Tapetes voadores tem dois antecessores distintos:

a classe Tapetes, e

a classe Veculos.Veculos

Terrestres Areos

Tapetes


Areos

Tapetes voadores


Na perspetiva conceptual pode-se dizer que

cliente institucional ser um subtipo

de cliente se todas as instncias de

Generalizao: Perspetiva Conceptual e de Especificao42

Cliente

Nomede cliente se todas as instncias de

cliente institucional forem tambm,

por definio, instncias de cliente.

A ideia chave que tudo o que se

estabelecer para cliente (associaes,

atributos, operaes) tambm

vlido para cliente institucional.

NomeEndereo





Cliente Individual

cartoCrdito#

{regimeCrdito()=="fraco"}vlido para cliente institucional.

Na perspetiva de especificao,

a generalizao 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.


Subtipo Supertipo

{regimeCrdito()=="fraco"}


Na perspetiva de implementao,

A generalizao est associada ao fenmeno de herana das linguagem de

programao orientadas para objetos.

Generalizao: Perspetiva de Implementao43

programao orientadas para objetos.

Fala-se aqui de subclasse e no de subtipos e considera-se que a subclasse

herda todos os mtodos e campos da superclasse, podendo os mtodos da

subclasse sobrepor-se aos mtodos herdados.



O conceito de herana est presente, pois que

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

de atributos e operaes.

Generalizao: Perspetiva de Implementao44

de atributos e operaes.

Assim, est implcito que

As subclasses Cliente Institucional e

Cliente Individual possuem

um nome, e

um endereo.

Cliente

NomeEndereo




Cliente Individual

cartoCrdito#


Subclasse Superclasse

limiteCrdito




O prprio facto de se desenhar um diagrama de classes significa que se

esto a respeitar restries.

Os conceitos de associao, de atributo ou de generalizao so, afinal de

Restries45

Os conceitos de associao, de atributo ou de generalizao so, afinal de

contas, formas de especificar restries.

Apesar disto, os conceitos chave dos diagramas de classe no permitem

exprimir todas as restries.

Assim, h restries que tm de ser expressas de forma explcita,

porque no caem em nenhuma das categorias previstas nos diagramas

de classes.de classes.



A sintaxe UML para exprimir restries limita-se a indicar que devem

ser colocados entre {}.

Tudo o resto livre, podendo

Restries46

Cliente Tudo o resto livre, podendo

ser expressas em

pseudolinguagem, para

enfatizar a legibilidade, ou

ser traduzidas por instrues

em cdigo de programao.

NomeEndereo




Cliente Individual

cartoCrdito#


Restrio: neste caso o regime de crdito s pode ser fraco




Os conceitos at agora descritos, correspondem s notaes chaves

dos diagramas de classes. Correspondem a cerca de 90% do esforo

na criao de diagramas de classes.

Conceitos Avanados47

na criao 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 incio do captulo.

Iremos assim descrever:

Classes Associativas

Esteretipos

Interfaces e desenho do sistema

Agregao e Composio



Surge da necessidade de obter mais informao de uma associao,

permitindo adicionar atributos, operaes e outros aspectos.

S existe em resultado da relao entre duas classes; por si s, no

Conceitos Avanados: Classes Associativas48

S existe em resultado da relao entre duas classes; por si s, no

ter significado.

Normalmente surgem nas relaes de Muitos para Muitos e o nome

da classe dado pelo nome da associao.



Exemplo:

pretende saber-se quando (perodo de tempo) em que cada empregado

trabalhou para a empresa

Conceitos Avanados: Classes Associativas49

trabalhou para a empresa

poderamos adicionar este atributo classe Pessoa, mas trata-se realmente

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

Emprego

Data_IncioData_Fim

Classe Associativa


PessoaEmpregado Empregador

Empresa

* *


Um esteretipo em UML parte de um leque de mecanismos de

extensibilidade utilizvel quando a semntica base do elemento de

modelao se revela insuficiente.

Conceitos Avanados: Esteretipos50

modelao se revela insuficiente.

Cada elemento UML pode ter um ou mais esteretipos.

Permite, genericamente,

criar novas classes de elementos de modelao por cima do ncleo de

elementos pr-definidos pela UML,

mantendo um controlo sobre as extenses das classes de metamodelos.

possvel criar qualquer tipo de esteretipo, sendo os mais utilizados, possvel criar qualquer tipo de esteretipo, sendo os mais utilizados,

para as classes, os de interface e controlo.

Os esteretipos so normalmente mostrados entre aspas (por ex:,

control), mas podem tambm ser representados por um cone.



O esteretipo de interface classifica as classes que apenas

disponibilizam um conjunto de operaes visveis externamente

(pblicas).

Conceitos Avanados: Esteretipos51

(pblicas).

Uma classe com o esteretipo de control representa uma classe cujo

objetivo conter um conjunto

de regras que controlam

determinadas operaes do

sistema e que coordenam ascontrol

Esteretipo

interface

interaes com as outras classes.


controlControlo Acesso

+ VerificaAcesso()

interfaceGesto

+ Criar()+ Apagar()+ Ver()


Interface:

Proporciona uma vista total ou parcial do conjunto dos vrios servios

proporcionados por um ou mais elementos.

Conceitos Avanados: Interfaces e Desenho do Sistema52

proporcionados por um ou mais elementos.

Permite que o impacto das alteraes seja limitado, podendo efetuar-se

alteraes na classe sem afetar as classes restantes, desde que no se altere

a interface respetiva.

Permite separar o que fornecido pela abstrao da classe da forma como

produzido.

um grupo de operaes que so utilizadas para especificar um servio. um grupo de operaes que so utilizadas para especificar um servio.



A UML representa as interfaces:

Utilizando pequenos crculos ligados por uma linha ao elemento que

proporciona os servios descritos pela interface.


proporciona os servios descritos pela interface.

uma classe



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

esteretipo interface, mas sem atributos, apenas operaes.


Encomenda

- NumeroE: long- Data: date- TipoEncomenda: string- ValorTotal: long

+ Criar()

interface

Gesto

+ Criar()+ Apagar()


+ Criar()+ Apagar()+ Ver()+ AdicionaProduto()+ CalculaValorTotal()

+ Apagar()+ Ver()


Os dependentes da interface podem utilizar todos ou alguns dos

servios descritos na interface.

Uma relao de dependncia surge quando uma classe recorre aos

Conceitos Avanados: Relao de Dependncia55

Uma relao de dependncia surge quando uma classe recorre aos

servios disponibilizados

por outra classe.

Quando um funcionrio efetua uma consulta a uma encomenda, este ter de aceder aos

servios disponibilizados pela classe Encomenda, atravs da interface Gesto, que disponibiliza os servios Criar(), Apagar() e

Ver() da classe Encomenda Encomenda

Funcionrio

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

Dependncia


Ver() da classe Encomenda

O servio funciona como um contrato entre a classe e os seus clientes, que, por sua vez, constroem os seus servios com base na

interface estabelecida

- NumeroE: long- Data: date- TipoEncomenda: string- ValorTotal: long


interfaceGesto



A relao de Realizao mostra que existe um contrato entre a classe

que utiliza o servio e outra que garante a sua realizao.

A classe Funcionrio, atravs da interface Gesto, pode Criar, Apagar e Ver

Conceitos Avanados: Relao de Dependncia e Realizao56

A classe Funcionrio, atravs da interface Gesto, pode Criar, Apagar e Ver

encomendas.

A classe Cliente apenas pode

visualizar as encomendas,

uma vez que a respetiva

interface s disponibiliza a

operao Ver()

Encomenda

- NumeroE: long- Data: dateinterface

Funcionrio


interface

Cliente


+ Pr-Registo()

operao Ver()

A classe Encomenda

disponibiliza duas interfaces:

Gesto e

Visualizar.


- Data: date- TipoEncomenda: string- ValorTotal: long


interfaceGesto


interfaceVisualizar

+ Ver()

Realizao


Podemos construir um diagrama de classes com 3 nveis, dividido em

trs camadas de servios:

1. Servios de interface - fornece a interface para os utilizadores para

Conceitos Avanados: Interface e Desenho do Sistema57

1. Servios de interface - fornece a interface para os utilizadores para

apresentao e recolha de dados.

2. Servios de negcio - engloba as classes que possuem as regras

fundamentais de negcio, respondendo aos pedidos da camada 1 ou de

outros servios da prpria camada, atravs da execuo de uma operao

especfica sobre dados relevantes com base em regras de negcio.

3. Servios de Dados - permite manter, atualizar e aceder aos dados3. Servios de Dados - permite manter, atualizar e aceder aos dados

persistentes.

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

dados, os servios de negcio asseguram o acesso ao servio de dados,

isolando o seu acesso.



Como as regras de negcio tendem a ser alteradas com relativa

frequncia, os servios de negcio so teis para encapsular estas

regras, separando a tarefa a desempenhar da forma como

Conceitos Avanados: Diagrama de Classe com 3 nveis58

regras, separando a tarefa a desempenhar da forma como

desempenhada.

Ao isolar os servios de negcio dos servios de interface e dados, este

diagrama permite ir ao encontro do paradigma de desenvolvimento de

aplicaes cliente/servidor, promovendo a reutilizao, escalabilidade e

manuteno dos componentes.




A classe de interface Ecr Pr-Registo necessita da classe clientes,

nos servios de negcio, para Cliente

Servios de NegcioServios de Interface Servios de Dados

user interface data connectionnos servios de negcio, para

efetuar o registo, invocando para tal a operao pr-registo.

Por sua vez, a classe cliente necessita de guardar num suporte fsico os dados do cliente que est a efetuar o pr-registo, utilizando os servios de dados atravs da classe

SD_Cliente.

Esquema semelhante se aplica para as classes Ecr Reservas e Ecr

Cliente

{persistence = Yes}

- BI- Nome- Morada

+ Pr-Registo() {sequencial}


+ VerificaAcesso()

0..*

1

efetua

Encomenda

data connectionEncomenda

user interface

Ecr Encomenda

user interfaceEcr Reservas

user interfaceEcr Pr-Registo

- BI- Nome- Morada

+ Criar()+ Apagar()+ Consultar()+ Actualizar()

data connectionSD_Cliente

0..*

1efetua


as classes Ecr Reservas e Ecr Encomenda. Dado necessitarem de verificar se o cliente tem permisso, o que feito invocando a classe

Controlo de Acesso (com esteretipo control), classe esta que contm as regras de negcio que gerem o acesso ao sistema.

- NumeroE- Data- TipoEncomenda

+ Criar() {sequencial}



Encomenda

{persistence = Yes}

Encomenda



As classes persistentes Persistence=Yes necessitam que os seus objetos sejam gravados Cliente

Servios de NegcioServios de Interface Servios de Dados

user interface data connectionos seus objetos sejam gravados fisicamente numa base de dados ou

outro meio.

A classe Controlo, neste caso, no necessita de gravar os seus dados, utilizando os servios da classe

Cliente.No entanto, se fosse necessrio manter um registo de acessos

especficos da classe ou de regras de negcio, esta seria marcada

Cliente

{persistence = Yes}

- BI- Nome- Morada

+ Pr-Registo() {sequencial}


+ VerificaAcesso()

0..*

1

efetua

Encomenda

data connectionEncomenda

user interface

Ecr Encomenda

user interfaceEcr Reservas

user interfaceEcr Pr-Registo

- BI- Nome- Morada


data connectionSD_Cliente

0..*

1efetua


de negcio, esta seria marcada como persistente e teria uma classe correspondente nos servios de

dados.- NumeroE- Data- TipoEncomenda

+ Criar() {sequencial}



Encomenda

{persistence = Yes}

Encomenda


A parte fsica dos dados depender do tipo de base de dados

(relacional ou objeto):

Se base de dados relacional, aplicam-se as regras de transposio


Se base de dados relacional, aplicam-se as regras de transposio

semelhantes s j tratadas em anlise de sistemas, a propsito da

transposio do modelo E-R para o modelo relacional.

Se B.D. objeto ou relacional-objeto, a transposio ser mais direta, e ser

tratada numa disciplina do plano de estudos do curso Tpicos Avanados de

bases de Dados.



A agregao num diagrama de classes pretende demonstrar a relao

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

Representa uma relao assimtrica, na qual uma das partes

Conceitos Avanados: Agregao e Composio62

Representa uma relao assimtrica, na qual uma das partes

desempenha um papel mais importante do que a outra.

Restaurante Mesa

1 1..*- Nome- Morada

- Num_mesa


Um restaurante possui um conjunto de mesas (o losngulo sem enchimento pretende representar o conceito de agregao)


Os critrios seguintes implicam uma agregao, mas o oposto nem

sempre verdade, ou seja, a agregao no os implica

necessariamente:


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 ao numa classe implica uma ao na outra classe.

Os objetos de uma classe esto subordinados aos objetos da outra classe.

Em casos de dvida quanto existncia de agregao, a associao Em casos de dvida quanto existncia de agregao, a associao

simples ser prefervel: lembremo-nos de que necessrio escolher

uma soluo que implique o acoplamento mais fraco.



A composio:

uma agregao com um significado mais forte existindo uma dependncia

direta entre as duas classes (se a parte deixar de existir, o todo tambm


direta entre as duas classes (se a parte deixar de existir, o todo tambm

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

qualquer remoo do todo implica a eliminao em cascata das partes.

Na composio a multiplicidade do lado do todo no ultrapassa o um,

ao contrrio da agregao.

Encomenda ItemEncomenda


No faz sentido haver linhas de encomenda (parte) sem a encomenda

respetiva (todo).

Encomenda ItemEncomenda

1 1..*

- NmeroE- Data- TipoEncomenda

- Codtem- Quantidade

TodoComposio Parte


Exemplo:

Um polgono contm uma coleo ordenada de pontos. Esses pontos podem

ser alterados com a edio do polgono (agregao)


ser alterados com a edio do polgono (agregao)

A composio utilizada para o pacote

grfico do polgono (por ex., cor ou

textura); foi separado do polgono

porque diversos elementos grficos

podem utilizar o mesmo pacote de

atributos grficos.

Polgono

1

3..*{ordenado}

agregao

1

1

composio

atributos grficos.

O relacionamento com o pacote grfico

composio porque o pacote grfico

ser criado ou destrudo com o polgono.

Classes compostas - classes implementadas por composio.


Ponto Pacote Grfico

CorTextura


Os diagramas de classes so a espinha dorsal de praticamente todos os

mtodos orientados para objetos, sendo, por isso, os mais usados.

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

Quando Usar os Diagramas de Classes66

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

seu uso com alguns cuidados:

No tentar usar todas as notaes disponveis.

Usar as mais complexas (aspetos avanados) quando forem estritamente

necessrias.

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

encontra:encontra:

fazer diagramas conceptuais, se se est a fazer anlise;

fazer diagramas de especificao, ao comear a pensar-se em software; e

fazer diagramas de implementao, apenas quando se pretender ilustrar uma soluo

de implementao mais particular.



No desenhar modelos para tudo; prefervel concentrarmo-nos nas

reas chave.

melhor ter poucos diagramas, que se vo atualizando quando necessrio,

Quando Usar os Diagramas de Classes67

melhor ter poucos diagramas, que se vo atualizando quando necessrio,

do que ter muitos diagramas que se vo tornando obsoletos por falta de

atualizao.

Evitar a todo o custo comear a pensar nos pormenores de

implementao demasiado cedo.

Para o conseguir, concentrar a ateno nas perspetivas de concepo e de

especificao.especificao.



PARTE 2



D IAGRAMA DE OBJETOS


Cap. 6.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]

Objetivos

Transio para os Objetos

Diagramas de Objetos

Tpicos2

Diagramas de Objetos

Representao das Ligaes

Objetos Compsitos

Quando Utilizar os Diagramas de Objetos



Facilitar a compreenso do processo de transio dos casos de uso para

o universo dos objetos.

Familiarizar com os conceitos essenciais utilizao dos diagramas de

Objetivos3

Familiarizar com os conceitos essenciais utilizao dos diagramas de

objetos.

Esclarecer as relaes entre os diagramas de objetos e diagramas de

classes.



Os diagramas de casos de uso

Centram o desenvolvimento sobre as necessidades do utilizador.

Tm um objetivo de eficcia: fazer o que deve ser feito.

Transio para os Objetos4

Tm um objetivo de eficcia: fazer o que deve ser feito.

Dizem o que o sistema deve fazer, mas no como deve faz-lo.

Os diagramas de objetos

Satisfazem um objetivo complementar, o da eficincia: fazer corretamente;

Dizem como deve ser feito.

Esta complementaridade importante porque um bom projeto de

software tem de satisfazer, em simultneo, os objetivos de eficincia esoftware tem de satisfazer, em simultneo, os objetivos de eficincia e

eficcia.



Transio de um caso de uso para uma formulao orientada para

objetos


ColaboraoCaso de uso


Objeto Objeto Objeto


A realizao de um caso de uso um momento crucial da construo

do modelo: o momento da passagem para objetos.

Note-se, contudo, que uma decomposio que siga de forma direta um


Note-se, contudo, que uma decomposio que siga de forma direta um

caso de uso, tal como ele foi criado, corre o risco de conduzir a uma

abordagem estruturada clssica, com todos os inconvenientes de uma

estruturao em torno de funes.

Numa abordagem para objetos, realiza-se o caso de uso atravs de

uma colaborao entre objetos.

Veremos que os cenrios, instncias dos casos de uso, sero

representados por diagramas de interao de dois tipos:

de colaborao, e

de sequncia.






Os diagramas de objetos ou diagramas de instncias representam os

objetos e as ligaes entre eles, exatamente da mesma maneira que

os diagramas de classes representam as classes e as associaes entre

Diagramas de Objetos8

os diagramas de classes representam as classes e as associaes entre

elas.

Tal como nos diagramas de classes, os diagramas de objetos, que no

so mais do que a instanciao dos diagramas de classes, representam

estruturas estticas.

A notao utilizada pelos diagramas de objetos deriva diretamente da

dos diagramas de classes, com a diferena que apresenta os nomes

dos elementos, que so as instncias, sublinhados.



Cada objeto representado por um retngulo que contm os seguintes

elementos:

o nome da classe e do objeto, separados por : (diz-se que se tem o modelo


o nome da classe e do objeto, separados por : (diz-se que se tem o modelo

completo)

o nome da classe qual o objeto pertence (diz-se que se tem o modelo

annimo)

o nome do objeto, sem indicao da classe a que pertence (diz-se que se tem

o modelo incompleto)

O modelo annimo utilizado quando se sabe a que classe pertence O modelo annimo utilizado quando se sabe a que classe pertence

o objeto, mas ainda no se atribuiu um nome para ele

O modelo incompleto corresponde a situaes em que j se escolheu

o nome para o objeto, mas no se sabe ao certo a que classe pertence.



Exemplo:


Nome do objeto: ClasseNome do objeto: ClasseModelo completo:

Nome do objetoModelo incompleto:

: ClasseModelo annimo:



Os retngulos que simbolizam os objetos podem igualmente comportar

um segundo compartimento que contm o valor dos atributos.

O tipo no ser necessrio dado que j foi definido no diagrama de


O tipo no ser necessrio dado que j foi definido no diagrama de

classes que engloba o dos objetos.

Exemplo para um objeto annimo da classe Automvel, com um nico

atributo, Cor, cujo valor Vermelha:

: Automvel


: Automvel

Cor = Vermelha


Os objetos de um diagrama encontram-se ligados por ligaes que so

instncias das associaes entre as classes s quais pertencem os

objetos considerados.

Representao das Ligaes12

objetos considerados.

Exemplo do diagrama de objetos (simplificado) para um automvel e

do diagrama de classes para o qual representa uma instncia:

: Automvel

: Roda : Roda : Roda : Roda

: MotorAutomvel Motor1 1

1

4


uma instancia de

: Roda : Roda : Roda : Roda Roda


Ligaes que so instncias de associaes reflexivas podem ligar os

objetos a si mesmos.

Dois exemplos da mesma associao reflexiva:

Representao das Ligaes13

Dois exemplos da mesma associao reflexiva:

Pessoa

Chefe

Trabalhador

*1

Joo: Pessoa

Lus: Pessoa

ChefeMostra que o Joo chefe do Lus Chefe

Mostra que o Dinis o chefe de si mesmo

Dinis: Pessoa



Os objetos compostos a partir de sub-objetos podem ser representados

por objetos compsitos, que permitem reduzir a complexidade dos

diagramas.

Objetos Compsitos14

diagramas.

Representam-se como objetos normais, exceto no facto de nos objetos

compsitos serem colocados os sub-objetos como atributos.

Exemplo de objeto compsitos:

Objeto compsito


: Parte 1 : Parte 2 : Parte 3

Objeto compsito


Os objetos compsitos so instncias de classes compsitas, isto , as

classes construdas a partir de outras classes por meio de forma forte

de agregao (composio).

Objetos Compsitos15

de agregao (composio).

Exemplo da classe compsita Janela e do diagrama de objetos

compsito que representa uma das suas instncias:

: Zona de desenho

:JanelaJanela Elevador

1

1

2

:Elevador horizontal


Classe compsita Janela Objeto compsito Janela

: Zona de desenho

Zona de desenho

1

:Elevador vertical

:Elevador horizontal


Os diagramas de objetos utilizam-se principalmente para

ilustrar o contexto da instanciao de uma classe (por exemplo, antes ou

depois de uma interao) e

Quando Utilizar os Diagramas de Objetos16

depois de uma interao) e

facilitar a compreenso das estruturas de dados complexas, como as

estruturas recursivas.



PARTE 2



D IAGRAMA DE PACOTES


Cap. 6.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]

Diagramas de Pacotes

Pacote = agrupamento por critrios lgicos

Conceitos de acoplamento e coeso

Tpicos2

Conceitos de acoplamento e coeso

Pacotes

Hierarquias de Pacotes

Acesso aos Elementos

Arte na Conceo

Exemplo

Quando utilizar os Diagramas de Pacotes



Familiarizar com os conceitos essenciais sobre Diagramas de Pacotes:

perceber o conceito de pacote e dependncia

mostrar exemplos de diagramas de pacotes

Objetivos3

mostrar exemplos de diagramas de pacotes

compreender o papel dos diagramas de pacotes na minimizao das

dependncias



Trata-se do responder questo:

Como dividir um grande sistema em subsistemas?

Na abordagem estruturada tradicional era usada a decomposio funcional,

Diagramas de Pacotes4

Na abordagem estruturada tradicional era usada a decomposio funcional,

na qual o sistema era mapeado como uma funo e, esta dividida em

subfunes, sub-subfunes e assim sucessivamente

Havia uma separao entre processos e dados, e alm da decomposio

funcional havia uma estrutura de dados

Algumas tcnicas de engenharia de informao agrupavam registos de dados

em reas e produziam matrizes que mostravam como as funes e registosem reas e produziam matrizes que mostravam como as funes e registos

de dados interatuavam.

Mas agora surgem os objetos: a separao dos processos e dados

desapareceu, a decomposio funcional desapareceu, mas a velha

questo permanece como dividir?



Soluo: agrupar qualquer elemento de modelao UML (ex. Classes,

componentes, interfaces, etc.), utilizando critrios lgicos, em

unidades de mais alto nvel, chamadas pacotes.

Pacotes5

unidades de mais alto nvel, chamadas pacotes.

Interessante para projetos de grande dimenso, permitindo assim

manter a simplicidade dos diagramas ao possibilitar que cada diagrama

caiba numa pgina.

Permite-se o dividir da complexidade do sistema em partes mais

pequenas para uma melhor gesto.

Um pacote representado graficamente como uma pasta, contendo

um nome.


Gesto de Encomendas

Gesto de Clientes


Os pacotes podem ser relacionados entre si, atravs de relaes de

dependncia.

Assim, criam-se os diagramas de pacotes - mostram os pacotes de

Pacotes6

Assim, criam-se os diagramas de pacotes - mostram os pacotes de

classes e as suas dependncias.

Dependncia - existe dependncia entre dois elementos se, ao alterar-se a

definio de um dos elementos, isso levar a alteraes no outro.

Com as classes, as dependncias existem por vrias razes:

Uma classe envia uma mensagem a outra;

uma classe tem outra como parte dos seus dados; uma classe tem outra como parte dos seus dados;

uma classe menciona outra como um parmetro de uma operao.

Se uma classe altera a sua interface, ento qualquer mensagem que enviar pode no

ser mais vlida.



Cada um dos pacotes pode ser subdividido em mais pacotes e assim

sucessivamente, criando-se uma hierarquia de pacotes.

No exagerar nos nveis de hierarquia, no mximo, 3.

Hierarquias de Pacotes7

No exagerar nos nveis de hierarquia, no mximo, 3.

Diviso do pacote Gesto de encomendas,

Encomendas Central

Encomendas Telefone

Gesto de Encomendas


Gesto de encomendas, ilustrativa da hierarquia

de pacotes.Encomendas

Fax

Encomendas Balco


Todos os elementos do sistema pertencem pelo menos a um pacote,

sendo o seu acesso pblico ou privado:

se pblico (representado graficamente com o prefixo +), os elementos esto

Acesso aos Elementos8

se pblico (representado graficamente com o prefixo +), os elementos esto

disponveis nos outros pacotes;

se privado (representado

graficamente com o prefixo -),

s os elementos do prprio

pacote (incluindo subpacotes)

que lhe tm acesso.

+ FormEncomenda+ FormCatlogo- Encomenda

EncomendasBalco

que lhe tm acesso.

Engenharia de Software - 2011/2012

Os dois formulrios so de acesso pblicoO elemento Encomenda privado, sendo

apenas visvel dentro do pacote.

Carlos Barrico Carlos Barrico Carlos Barrico Carlos Barrico ---- Departamento Informtica da UBIDepartamento Informtica da UBIDepartamento Informtica da UBIDepartamento Informtica da UBI


A arte na conceo ser: minimizar as dependncias - os efeitos das

alteraes so reduzidos e necessrio menor esforo para realizar

alteraes (lembremo-nos do que foi dito no cap. 1, acerca da coeso e

Arte na Conceo9

alteraes (lembremo-nos do que foi dito no cap. 1, acerca da coeso e

acoplamento).

Idealmente s as alteraes na interface da classe podero afetar

qualquer outra.

Os pacotes no oferecem respostas de como reduzir as dependncias

no sistema, mas ajudam a ver o que so as dependncias: s

poderemos trabalhar na reduo das dependncias se pudermos v-las

facilmente.

Os diagramas de pacotes so uma ferramenta chave para manter sob

controlo a estrutura global dum sistema.



Interface Utilizador p/Recolha de Encomendas

Interface Utilizador p/Mailing List

Exemplo10

3. A aplicao Recolha de Encomendas isola a Interface de Utilizador

para Recolha de Encomendas de

Interface Utilizador p/Recolha de Encomendas

Pacote

Aplicao p/ RecolhaDe Encomendas

Encomendas

Aplicao deMailing List

Dependncia

1. Existe uma dependncia entre dois

pacotes se existir qualquer dependncia entre quaisquer duas classes nos pacotes.

Encomendas de alteraes nas Encomendas.

Comportamento clssico de arquitetura

em camadas.

EncomendasClientes classes nos pacotes.

Ex. Se qualquer classe no pacote Mailing Listfor dependente de qualquer classe no

pacote Clientes, ento h uma dependncia entre os dois pacotes.


2. As dependncias no so transitivas: se uma classe no pacote Encomendas for alterada, isso no implica alteraes no pacote Interface Utilizador p/ Recolha de Encomendas, mas unicamente indica que o pacote de aplicao de Recolha de Encomendas precisa de ser olhado para ver se necessita de alteraes. S se a

interface do pacote Aplicao p/ Recolha de encomendas for alterada, ento implicar alteraes ao pacote de Interface de utilizador para recolha de encomendas.


So uma ferramenta vital para grandes projetos.

Usar sempre que um diagrama de classe que mostre o sistema todo

no for legvel numa folha A4.

Quando utilizar Diagramas de Pacotes11

no for legvel numa folha A4.

Pretende-se manter as dependncias ao mnimo, pois que isso diminui

o acoplamento.

Os pacotes so tambm particularmente teis nos testes, devendo ter

uma ou mais classes de teste para testar o comportamento do pacote.


Documents

Cap 6 - UML - Modelacao Da Estrutura