cap 6 - uml - modelacao da estrutura
DESCRIPTION
modelação de estruturas em umlTRANSCRIPT
-
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
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]
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.
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]
Descrevem
as classes - descries abstratas e condensadas de um conjunto de objetos
do domnio da aplicao, caracterizadas pelos seus:
Diagrama de Classes4
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)
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]
A classe representada no exemplo :
identificada pelo nome Tringulo
tem como atributos base e altura
Diagrama de Classes5
Triangulo
tem como atributos base e altura
executa a operao area(),
a partir dos atributos
est sujeita restrio
{area
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
A relao de incluso
indica que uma classe usa a outra;
normalmente usada quando uma classe usada como argumento numa
Diagrama de Classes9
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.
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]
Exemplo:
Diagrama de Classes10
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]
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
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]
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
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]
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.
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]
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
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
nome
Empregado Emprego Empregador
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
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
-Nome-Morada
Chefe
Chefiar
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
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
Professor Disciplina
Lecionar Ser lecionada
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
Lecionar Ser lecionada
As cardinalidades representam limites superiores
* significa qualquer coisa entre 0 e vrios
1 representa o valor um e s um
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]
Se fosse pretendido indicar ser possvel algumas disciplinas no serem
lecionadas por algum professor, utilizaramos 0..1
Associaes: Perspetiva Conceptual - Multiplicidade18
Formas mais comuns de multiplicidade:
0..1 - Opcional
1..1 ou 1 - Obrigatrio existir um objeto
Professor 0..1 *Disciplina
Lecionar Ser lecionada
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
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]
Exemplos de multiplicidades mais frequente
Associaes: Perspetiva Conceptual - Multiplicidade19
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]
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.
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]
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.
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]
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.
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
Aluno
Disciplina
Professor
Data_IncioData_Fim
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
Associaes: Perspetiva Conceptual - Multiplicidade23
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
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
DisciplinaData_IncioData_Fim
Aluno Disciplina Professor
Data_IncioData_Fim
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
As associaes N-rias podem geralmente ser transformadas em vrias
relaes binrias entre a classe-associao e as restantes classes
participantes.
Associaes: Perspetiva Conceptual - Multiplicidade24
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
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
Aluno
Disciplina
Professor
Data_IncioData_Fim
Disciplina
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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.
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]
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
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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.
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
A B
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
Associaes: Navegabilidade28
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
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
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"}
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
Associaes: Navegabilidade29
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.
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]
Uma associao sem setas entendida como
bidirecional, ou
uma associao cujas navegabilidades no foram ainda definidas:
Associaes: Navegabilidade30
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)
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]
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)
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]
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
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]
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.
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]
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.
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]
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.
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]
Exemplo:
Visibilidade de Atributos e Operaes36
ClienteCliente
# Registar( )+ Alterar Dados( )+ CalcularIdade( )
Privado
Pblico
Protegido
- BI- Nome- Morada- Telefone
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]
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.
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]
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.
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]
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
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
Gato Co Guaxim
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
Cliente Institucional
nomeContactoregimeCrditolimiteCrdito
avisa()facturaParaMs(Inteiro)
Cliente Individual
cartoCrdito#
(o supertipo) ficando as
outras classes (os subtipos)
com as caractersticas
que so diferentes.
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
Subtipos Supertipo
facturaParaMs(Inteiro){regimeCrdito()=="fraco"}
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
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
Areos
Tapetes voadores
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
regimeCredito(): string
Cliente Institucional
nomeContactoregimeCrditolimiteCrdito
avisa()facturaParaMs(Inteiro)
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.
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
Subtipo Supertipo
{regimeCrdito()=="fraco"}
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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.
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]
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
regimeCredito(): string
Cliente Institucional
nomeContactoregimeCrditolimiteCrdito
Cliente Individual
cartoCrdito#
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
Subclasse Superclasse
limiteCrdito
avisa()facturaParaMs(Inteiro)
{regimeCrdito()=="fraco"}
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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.
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]
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
regimeCredito(): string
Cliente Institucional
nomeContactoregimeCrditolimiteCrdito
Cliente Individual
cartoCrdito#
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
Restrio: neste caso o regime de crdito s pode ser fraco
avisa()facturaParaMs(Inteiro)
{regimeCrdito()=="fraco"}
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
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]
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.
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]
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
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
PessoaEmpregado Empregador
Empresa
* *
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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.
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]
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.
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
controlControlo Acesso
+ VerificaAcesso()
interfaceGesto
+ Criar()+ Apagar()+ Ver()
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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.
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]
A UML representa as interfaces:
Utilizando pequenos crculos ligados por uma linha ao elemento que
proporciona os servios descritos pela interface.
Conceitos Avanados: Interfaces e Desenho do Sistema53
proporciona os servios descritos pela interface.
uma classe
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]
Em alternativa a interface pode representar-se por uma classe, com o
esteretipo interface, mas sem atributos, apenas operaes.
Conceitos Avanados: Interfaces e Desenho do Sistema54
Encomenda
- NumeroE: long- Data: date- TipoEncomenda: string- ValorTotal: long
+ Criar()
interface
Gesto
+ Criar()+ Apagar()
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
+ Criar()+ Apagar()+ Ver()+ AdicionaProduto()+ CalculaValorTotal()
+ Apagar()+ Ver()
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
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
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
+ Criar()+ Apagar()+ Ver()+ AdicionaProduto()+ CalculaValorTotal()
interfaceGesto
+ Criar()+ Apagar()+ Ver()
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
- BI: string- Nome: string- Morada: string
interface
Cliente
- BI: string- Nome: string- Morada: string
+ Pr-Registo()
operao Ver()
A classe Encomenda
disponibiliza duas interfaces:
Gesto e
Visualizar.
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
- Data: date- TipoEncomenda: string- ValorTotal: long
+ Criar()+ Apagar()+ Ver()+ AdicionaProduto()+ CalculaValorTotal()
interfaceGesto
+ Criar()+ Apagar()+ Ver()
interfaceVisualizar
+ Ver()
Realizao
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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.
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]
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.
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]
Conceitos Avanados: Diagrama de Classe com 3 nveis59
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}
controlControlo Acesso
+ 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
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 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}
- NumeroE- Data- TipoEncomenda
+ Criar()+ Apagar()+ Consultar()+ Actualizar()
Encomenda
{persistence = Yes}
Encomenda
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
Conceitos Avanados: Diagrama de Classe com 3 nveis60
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}
controlControlo Acesso
+ 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
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
de negcio, esta seria marcada como persistente e teria uma classe correspondente nos servios de
dados.- NumeroE- Data- TipoEncomenda
+ Criar() {sequencial}
- NumeroE- Data- TipoEncomenda
+ Criar()+ Apagar()+ Consultar()+ Actualizar()
Encomenda
{persistence = Yes}
Encomenda
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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
Conceitos Avanados: Diagrama de Classe com 3 nveis61
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.
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]
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
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
Um restaurante possui um conjunto de mesas (o losngulo sem enchimento pretende representar o conceito de agregao)
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
Os critrios seguintes implicam uma agregao, mas o oposto nem
sempre verdade, ou seja, a agregao no os implica
necessariamente:
Conceitos Avanados: Agregao e Composio63
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.
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]
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
Conceitos Avanados: Agregao e Composio64
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
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
No faz sentido haver linhas de encomenda (parte) sem a encomenda
respetiva (todo).
Encomenda ItemEncomenda
1 1..*
- NmeroE- Data- TipoEncomenda
- Codtem- Quantidade
TodoComposio Parte
-
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
Exemplo:
Um polgono contm uma coleo ordenada de pontos. Esses pontos podem
ser alterados com a edio do polgono (agregao)
Conceitos Avanados: Agregao e Composio65
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.
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
Ponto Pacote Grfico
CorTextura
Cap. 6.1 UML - Modelao de Estrutura Diagrama de Classes [Parte 2]
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.
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]
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.
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
-
ENGENHARIA DE SOFTWARE
PARTE 2
LINGUAGEM DE MODELAO UML
CAP. 6.2 UML MODELAO DA ESTRUTURA -
D IAGRAMA DE OBJETOS
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.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
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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.
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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.
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
Transio de um caso de uso para uma formulao orientada para
objetos
Transio para os Objetos5
ColaboraoCaso de uso
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
Objeto Objeto Objeto
Cap. 6.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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
Transio para os Objetos6
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.
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
Transio para os Objetos7
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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.
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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
Diagramas de Objetos9
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.
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
Exemplo:
Diagramas de Objetos10
Nome do objeto: ClasseNome do objeto: ClasseModelo completo:
Nome do objetoModelo incompleto:
: ClasseModelo annimo:
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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
Diagramas de Objetos11
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
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
: Automvel
Cor = Vermelha
Cap. 6.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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
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
uma instancia de
: Roda : Roda : Roda : Roda Roda
-
Cap. 6.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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
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.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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
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
: Parte 1 : Parte 2 : Parte 3
Objeto compsito
Cap. 6.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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
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
Classe compsita Janela Objeto compsito Janela
: Zona de desenho
Zona de desenho
1
:Elevador vertical
:Elevador horizontal
Cap. 6.2 UML - Modelao de Estrutura Diagramas de Objetos [Parte 2]
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.
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
-
ENGENHARIA DE SOFTWARE
PARTE 2
LINGUAGEM DE MODELAO UML
CAP. 6.3 UML MODELAO DA ESTRUTURA -
D IAGRAMA DE PACOTES
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.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
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.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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
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.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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?
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.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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.
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
Gesto de Encomendas
Gesto de Clientes
Cap. 6.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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.
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.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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
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
Gesto de encomendas, ilustrativa da hierarquia
de pacotes.Encomendas
Fax
Encomendas Balco
Cap. 6.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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
-
Cap. 6.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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.
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.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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.
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
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.
Cap. 6.3 UML - Modelao de Estrutura Diagramas de Pacotes [Parte 2]
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.
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