1 diagrama de classes perspectiva conceitual 2ª parte dicas dependÊncias avanÇado agregaÇÃo...
TRANSCRIPT
1
DIAGRAMA DE CLASSES PERSPECTIVA CONCEITUAL
2ª PARTEDICAS
DEPENDÊNCIAS AVANÇADO
AGREGAÇÃO
ATRIBUTOS E ASSOCIAÇÕES DERIVADAS
ASSOCIAÇÃO TERNÁRIA
GENERALIZAÇÃO
ORGANIZAÇÃO DAS CLASSES EM PACOTES
ELABORANDO O DIAGRAMA
ERROS COMUNS
2
DICASFoco: aspecto estático do sistemaNão prejudicar a leitura com minimalismosGeneralizações: evitar mais do que 5 níveisNome para cada diagramaEvitar linhas cruzadasElementos semânticos semelhantes próximos fisicamentePode-se usar notações visuais que chamem a atenção É possível usar mais que um relacionamento, mas tentar evitar
3
DEPENDÊNCIAS AVANÇADO
Tipos Definidos pela UMLBind: origem instancia o destinoDerive: Origem computada através do destino (ex. Idade -> Data de Nascimento)Friend: Origem recebe visibilidade especial no destino
InstanceOfInstantiatePowertypeRefineUse
4
I I . ATRI BUTOS E ASSOCI AÇÕES DERI VADAS Um elemento derivado é aquele que pode ser calculado a
partir de um ou mais elementos mas é incluído no modelo: - com o objetivo de tornar algo mais claro ou - por algum motivo de projeto. Por exemplo, para tornar uma
operação mais f ácil de ser realizada. Atributos ou associações derivadas podem ser representadas
através de uma barra (/ ) antes do nome da associação ou do atributo.
Os detalhes sobre o cálculo do elemento derivado podem ser
descritos junto a ele, através de uma nota (utilizada na UML para anexar inf ormações a um modelo)
5
Fatura
numFaturadataEmissãodataVencimentovalorPago [0..1]dataPagamento [0..1]dataPedidoCancelamento [0..1]dataCancelamento [0..1]status
1..*0..*
I tem faturado
quantFaturada
I tem pedido
quantidadePedidapreçoCobrado/ quantAtendida
quantAtendida = soma das quantidades f aturadas do item
Atributo derivado
Nota
6
PedidonumPedidodataEmissão
nomePresenteado [0..1]endereçoEntrega
dataCancelamento [0..1]status
Item pedidoquantidadePedidapreçoCobrado/ quantAtendida
1..*
1
0..*
LivroisbntítulodescriçãoquantEstoquepreçoprazoMédioEntrega
0..*
1..*
ClientecódigoCPFnomeendereçotelefone [0..1]eMail [0..1]
<- faz
1..*
1
/escolhe
Associação derivada
7
I I . ASSOCIAÇÃO TERNÁRIA
Associações podem ser binárias, ternárias ou deoutro grau.
Uma associação ternária é uma associação entretrês classes, onde uma classe pode ocorrer maisde uma vez.
8
Exemplo: Num sistema de controle de reservas deexcursões, ao ser criada uma excursão:
- são selecionados um ou mais veículos e- para cada veículo, podem ser alocados até dois
motoristas que o conduzirão nesta excursão.
1..*
1..2
1
Excursão
CódigoDataHoraValorLocalEncontro
Motorista
NomeEndereçoTelefone
Veículo
PlacaLotação
9
Neste caso não ocorre de serem selecionados veículospara a excursão e só depois serem alocados motoristas.Se f osse essa a situação não teríamos um ternárioporque a classe motorista não estaria participando dorelacionamento e num ternário as três classes têm queparticipar.
10
Para incluir a multiplicidade podemos pensar da seguintemaneira:
Analisamos excursão-veículo com relação ao motorista.Para cada veículo em uma excursão é alocado um ou nomáximo dois motoristas. Desta f orma do lado do motoristaincluímos o multiplicidade 1..2. Analisamos motorista-veículo com relação a excursão.Um motorista dirigindo um determinado veículo pode terparticipado de várias excursões. Desta f orma do lado daexcursão teríamos a multiplicidade 1..*. Analisando motorista-excursão com relação ao veículo.Um motorista numa determinada excursão só pode terdirigido um veículo. Desta f orma ao lado do veículo teríamosa multiplicidade 1.
11
I I I . GENERALIZAÇÃO
A generalização é um relacionamento entre um elementomais genérico (o pai) e um elemento mais específico (ofi lho) que é totalmente consistente com o primeiroelemento e acrescenta informações adicionais. É umrelacionamento utilizado em classes mas também emcasos de uso, atores, e outros elementos.
No diagrama de classes, a generalização é apresentadacomo uma linha da classe fi lha para a classe pai com umtriângulo ao fi m da linha onde está o pai. Representa umrelacionamento entre a superclasse e a subclasse. Asubclasse herda as propriedades do pai, como atributose operações e pode ter suas próprias propriedades.
12
À s v e z e s a d e c i s ã o p o r m o d e l a r u m ag e n e r a l i z a ç ã o c o m e ç a q u a n d o t e m o s u m a c l a s s ec o m i n f o r m a ç õ e s d e v á r i o s t i p o s .
P o r e x e m p l o , n u m c o n s u l t ó r i o m é d i c o op a g a m e n t o d e u m a c o n s u l t a p o d e s e r f e i t o a t r a v é sd e c o n v ê n i o o u p a r t i c u l a r . N e s t e ú l t i m o c a s o oc l i e n t e p o d e p a g a r c o m c h e q u e o u d i n h e i r o .
N a s o l u ç ã o a s e g u i r f o r a m i n c l u í d o s e mP a g a m e n t o a t r i b u t o s r e l a c i o n a d o s a c a d a u m d e s s e st i p o s d e p a g a m e n t o .
Convênio
nometelefonedata cobrança
Consulta
data horasintomasdiagnóticomedicamentos
Pagamento
data previstadata pagamentovalor cobradovalor pagotiponúmero chequenúmero banconúmero associado
0..10..* 0..10..*
11 11
13
Modelando com a generalização podemos ter maior clarezasobre pagamento, como podemos observar no diagrama aseguir.- Foram criadas duas subclasses, pagamento particular e
pagamento por convênio.- Em pagamento estão os atributos comuns a pagamento
particular e por convênio .- Em pagamento particular temos os atributos próprios só
deste tipo e em pagamento por convênio os atributos eassociações particulares ao pagamento por convênio.
- Como consulta está relacionada à pagamento, todas assubclasses têm este relacionamento.
14
Pagamento Particular
tipo
número cheque
número banco
Pagamento por Convênio
número associado
Convênio
nome
telefone
data cobrança
0..* 10..* 1
Pagamento
data prevista
data pagamento
valor cobrado
valor pago
Consulta
data hora
sintomas
diagnóstico
medicamentos11 11
15
Uma generalização pode ser total ou parcial,disjunta ou sobreposta.
- Total: Todas as subclasses são especifi cadas- Parcial: Nem todas as subclasses são
especificadas- Sobreposta: As classes derivadas de uma
superclasse podem ocorrer simultaneamente- Disjunta: As classes derivadas de uma
superclasse podem ocorrer de maneiramutuamente exclusivas.
Restrições, já comentadas anteriormente, podemser utilizadas para descrever o tipo da generalização.
16
Pagamento Particular
tiponúmero chequenúmero banco
Pagamento por Convênio
número associado
Convênio
nometelefonedata cobrança
0..* 10..* 1
{total, disjunta}
Pagamento
data previstadata pagamentovalor cobradovalor pago
Consulta
data horasintomasdiagnóticomedicamentos
11 11
Restrição
17
No caso anterior, as subclasses de pagamento f oramcriadas em f unção do tipo de pagamento. Pode sernecessário, no entanto, f azer várias classificações.
- Classifi cação única: No exemplo a seguir médico éclassificado somente quanto a sua especialidade.
- Classifi cação múltipla: No exemplo a seguir temos pessoaclassificada por sexo e por ocupação.
Quando temos uma classificação múltipla, discriminadoresdevem ser utilizados para dif erenciar esses tipos. Ao lado dodiscriminador podemos escrever as restrições entre chaves.
18
Pessoa
Médico Enfermeira Psicólogo
HomemMulher
Cirurgião Pediatra
sexo {total, disjunta}
ocupação {parcial,sobreposta}
especialidade{parcial,sobreposta}
Discriminador
19
Quando uma subclasse tem apenas uma classe paitemos uma herança simples. Mas é possível ocorrerde uma classe ter várias classes pai e desta f ormateremos uma herança múltipla.
20
IV. ORGANIZAÇÃO DAS CLASSES EMPACOTES
Na UML os modelos podem ser organizados empackages (ou pacotes) de f orma que possamoscompreendê-los mais f acilmente.
O package é f ormado por um grupo de elementos comum tema comum. Esses elementos podem ser classes,componentes, casos de uso e até mesmo outrospacotes.
21
Exemplo:
Poderíamos no caso exemplo, ter dois packages:Controle de pedidos e Controle de Livros
Controle de
livros
Controle de
pedidos
22
O diagrama de classes apresentado a seguirpertence ao package Controle de pedidos, quecontém as classes próprias à administração depedidos e f aturamento
Classes de outros packages podem aparecerneste diagrama, caso seja importante, como é ocaso de Livro. Ao lado do nome, no entanto, vemdiscriminado o nome do package ao qual pertence.
O package Controle de Livros contém a classelivro que pertence ao sistema de Controle deLivros
23
Item faturadoquantFaturada
Livro (from Controle de Livros)isbntítulodescriçãoquantEstoquepreçoprazoMédioEntrega
Item pedidoquantidadePedidapreçoCobrado
1
0..*
1
0..*
ClientecódigoCPFnomeendereçotelefone [0..1]eMail [0..1]
PedidonumPedidodataEmissão
nomePresenteado [0..1]endereçoEntrega
dataCancelamento [0..1]status
1..*1..*
1..*1 1..*1 faz ->
FaturanumFaturadataEmissãodataVencimentovalorPago [0..1]dataPagamento [0..1]dataPedidoCancelamento [0..1]dataCancelamento [0..1]
status
1..*0..* 1..*0..*
1
0..*
1
0..*
{ Se uma fatura atende a um pedido, necessariamente os itens pedidos ligados à fatura devem ser do pedido ao qual a fatura está relacionada }
Nomedo package
24
V. ELABORANDO O DIAGRAMA
1. A elaboração da primeira versão do diagrama de classecom uma perspectiva conceitual pode se realizada emparalelo à leitura dos casos de uso. Na descrição decada caso de uso há uma série de informações,conceitos, nomes de atributos, etc, que serão úteispara descobrir as classes, associações e atributos
25
2. Ao elaborar o diagrama de classes é possível que seconstate a f alta de informações, a existência deinconsistências e haverá necessidade então de seconsultar o cliente.
3. A elaboração de modelos é realizada através de váriasrepetições e o modelo deve ser construído emconjunto com os demais modelos, já que alterações emum modelo provocam alterações em outros.
26
4. Após a elaboração da primeira versão podemostentar refinar o modelo verifi cando a possibilidadede incluir notações como composição, generalizaçãoque permitem que as informações fi quem descritasde f orma mais clara.
5. Conforme é elaborado o diagrama pode sernecessário também organizar as classes em packages.
27
28
29
30
31
32