Cap 05 Bezerra

Princpios de Anlise e
Projeto Orientados a
Objetos com UML
Eduardo Bezerra
Editora CAMPUS
Copyright 2002, 2003 Eduardo Bezerra
Captulo 5
Modelagem de Classes do
Domnio
Temos uma capacidade inata de ordenar em diferentes
grupos e classes todas as nossas impresses sensoriais.
Jostein Gaardner, O mundo de Sofia, 1995
Introduo
O modelo de casos de uso fornece uma
perspectiva do sistema a partir de um ponto

de vista externo.
De posse da viso de casos de uso, os
desenvolvedores precisam prosseguir no
desenvolvimento do sistema.
Copyright 2002, 2003
Aspectos dinmico e esttico

A funcionalidade externa de um sistema
orientado a objetos fornecida atravs de

colaboraes entre objetos.
Externamente, os atores visualizam
resultados de clculos, relatrios produzidos,
confirmaes de requisies realizadas, etc.
Internamente, os objetos colaboram uns com
os outros para produzir os resultados.
Essa colaborao pode ser vista sob o
aspecto dinmico e sob o aspecto

estrutural esttico.
Modelo de classes
O diagrama da UML utilizado para representar o
aspecto esttico o diagrama de classes.

O modelo de classes composto desse diagrama e
da descrio textual associada.
Objetivos principais deste captulo:
Descrever um mtodo para identificao das classes

de objetos de um sistema partir do modelo de casos
de uso.
Apresentar alguns dos elementos do diagrama de
classes (outros elementos so descritos em captulos
posteriores).
Descrever a construo do modelo de domnio.
Descrever a insero do modelo de classes no
processo de desenvolvimento.
Modelo de classes
O modelo de classes evolui durante o
desenvolvimento do sistema.
medida que o sistema desenvolvido,

o modelo de classes incrementado
com novos detalhes.
Trs nveis sucessivos de abstrao:

Domnio
Especificao
Implementao.
Modelo de classes
O modelo de classes de domnio representa as
classes no domnio do negcio em questo. No leva

em considerao restries inerentes tecnologia a
ser utilizada na soluo de um problema.
O modelo de classes de especificao obtido
atravs da adio de detalhes ao modelo anterior
conforme a soluo de software escolhida.
O modelo de classes de implementao
corresponde implementao das classes em
alguma linguagem de programao.
Modelo de classes de domnio

Representa termos do domnio do negcio.
Objetivo: descrever o problema representado
pelo sistema a ser desenvolvido, sem

considerar caractersticas da soluo a ser
utilizada.
O modelo de classes de domnio descrito
neste captulo.
Classes
Uma classe representa um grupo de objetos
semelhantes.
Uma classe descreve esses objetos atravs
de atributos e operaes.
Os atributos correspondem s informaes
que um objeto armazena.
As operaes correspondem s aes que
um objeto sabe realizar.
Notao para uma classe

Representada atravs de uma caixa com no
mximo trs compartimentos exibidos.

Notao utilizada depende do nvel de abstrao
desejado.
10
Exemplo (classe ContaBancria)
11
Associaes
Para representar o fato de que objetos
podem se relacionar uns com os outros,

utiliza-se a associao.
Uma associao representa relacionamentos
(ligaes)que so formados entre objetos
durante a execuo do sistema.
embora as associaes sejam representadas

entre classes do diagrama, tais associaes
representam ligaes possveis entre objetos
das classes envolvidas.
12
Notao para uma associao

Representada atravs de um segmento de reta
ligando as classes cujos objetos se relacionam.

Exemplos:
13
Multiplicidades
Representam a informao dos limites
inferior e superior da quantidade de objetos

aos quais um outro objeto pode estar
associado.
Cada associao em um diagrama de
classes possui duas multiplicidades, uma em
cada extremo da linha de associao.
14
Multiplicidades
Nome
Simbologia
Apenas Um
Zero ou Muitos
Um ou Muitos
Zero ou Um
Intervalo Especfico
1..1 (ou 1)
0..* (ou *)
1..*
0..1
li..ls
15
Exemplo (multiplicidade)
Pode haver um cliente que esteja associado a
vrios pedidos.
Pode haver um cliente que no esteja associado
a pedido algum.
Um pedido est associado a um, e somente um,
cliente.
16
Exemplo (multiplicidade)
Uma corrida est associada a, no mnimo,
dois velocistas
Uma corrida est associada a, no mximo,
seis velocistas.
Um velocista pode estar associado a vrias
corridas.
17
Conectividade
A conectividade corresponde ao tipo de
associao entre duas classes: muitos para

muitos, um para muitos e um para um.
A conectividade da associao entre duas
classes depende dos smbolos de
multiplicidade que so utilizados na
associao.
18
Conectividade X Multiplicidade
Conectividade
Em um extremo No outro extremo
Um para um
0..1
1
0..1
1
Um para muitos
0..1
1
*
1..*
0..*
Muitos para muitos
*
1..*
0..*
*
1..*
0..*
19
Exemplo (conectividade)
20
Participao
Uma caracterstica de uma associao que
indica a necessidade (ou no) da existncia

desta associao entre objetos.
A participao pode ser obrigatria ou
opcional.
Se o valor mnimo da multiplicidade de uma
associao igual a 1 (um), significa que a
participao obrigatria
Caso contrrio, a participao opcional.
21
Nome de associao, direo de leitura

e papis
Para melhor esclarecer o significado de uma
associao no diagrama de classes, a UML

define trs recursos de notao:
Nome da associao: fornece algum
significado semntico mesma.
Direo de leitura: indica como a associao
deve ser lida
Papel: para representar um papel especfico
em uma associao.
22
Exemplo (Nome de associao,

direo de leitura e papis)
23
Agregao
um caso especial da associao
conseqentemente, multiplicidades,
participaes, papis, etc. podem ser usados
igualmente
Utilizada para representar conexes que
guardam uma relao todo-parte entre si.

Em uma agregao, um objeto est contido no
outro, ao contrrio de uma associao.
Onde se puder utilizar uma agregao, uma
associao tambm poder ser utilizada.
24
Agregao
Caractersticas particulares:
Agregaes so assimtricas: se um objeto A

parte de um objeto B, B no pode ser parte
de A.
Agregaes propagam comportamento, no
sentido de que um comportamento que se
aplica a um todo automaticamente se aplica
as suas partes.
25
Agregao
Sejam duas classes associadas, X e Y. Se
uma das perguntas a seguir for respondida

com um sim, provavelmente h uma
agregao onde X todo e Y parte.
X tem um ou mais Y?
Y parte de X?
26
Notao para uma agregao

Representada como uma linha conectando as
classes relacionadas, com um diamante (losango)

branco perto da classe que representa o todo.
Exemplo:
27
Classe associativa
uma classe que est ligada a uma
associao, ao invs de estar ligada a outras

classes.
normalmente necessria quando duas ou
mais classes esto associadas, e
necessrio manter informaes sobre esta
associao.
Uma classe associativa pode estar ligada a
associaes de qualquer tipo de
conectividade.
28
Notao para uma classe

associativa
Representada pela notao utilizada para
uma classe. A diferena que esta classe

ligada a uma associao.
Exemplo:
29
Associaes n-rias
So utilizadas para representar a associao
existente entre objetos de n classes.

Uma associao ternria um caso mais
comum (menos raro) de associao n-ria (n
= 3).
Na notao da UML, as linhas de associao
se interceptam em um losango.
30
Exemplo (associao ternria)
31
Associaes reflexivas
Associa objetos da mesma classe.
Cada objeto tem um papel distinto na

associao.
A utilizao de papis bastante importante
para evitar ambigidades na leitura da

associao.
Uma associao reflexiva no indica que um
objeto se associa com ele prprio.
Ao contrrio, indica que objetos de uma

mesma classe se associam
32
Exemplo (associao reflexiva)
33
Identificando as classes
iniciais
34
Identificando classes
Um sistema de software orientado a objetos
composto de objetos em colaborao para

realizar as tarefas deste sistema.
Por outro lado, todo objeto pertence a uma
classe.
Portanto, quando se fala na identificao das
classes, o objetivo na verdade saber quais
objetos iro compor o sistema.
35
Identificando classes
De uma forma geral, a identificao de
classes se divide em duas atividades.

Primeiramente, classes candidatas so
identificadas.
Depois disso, so aplicados alguns princpios
para eliminar classes candidatas
desnecessrias.
Identificar possveis classes para um sistema
no complicado; o difcil eliminar deste

conjunto o que no necessrio.
36
Identificao dirigida a
responsabilidades
Mtodo de identificao onde a nfase est na
identificao de classes a partir de seus

comportamentos externos relevantes para o
sistema.
como a classe faz para cumprir com suas

responsabilidades deve ser abstrado.
O esforo recai sobre a identificao das
responsabilidades que cada classe deve ter.

O mtodo dirigido a responsabilidades
enfatiza o encapsulamento da estrutura e do
comportamento dos objetos..
37
Responsabilidades e colaboradores
Em sistemas OO, objetos encapsulam tanto
dados quanto comportamento.

O comportamento de um objeto definido de
tal forma que ele possa cumprir com suas
responsabilidades.
Uma responsabilidade uma obrigao que
um objeto tem para com o sistema no qual ele
est inserido.
Atravs delas, um objeto colabora (ajuda) com

outros para que os objetivos do sistema sejam
alcanados.
38
Na prtica, uma responsabilidade alguma
coisa que um objeto conhece ou faz. (sozinho

ou no).
Um objeto Cliente conhece seu nome, seu
endereo, seu telefone, etc.
Um objeto Pedido conhece sua data de
realizao e sabe fazer o clculo do seu total.
Se um objeto tem uma responsabilidade a
qual no pode cumprir sozinho, ele deve

requisitar colaboraes de outros objetos.
39
Um exemplo: quando a impresso de uma
fatura requisitada em um sistema de

vendas, vrios objetos precisam colaborar:
um objeto Pedido pode ter a responsabilidade
de fornecer o seu valor total
um objeto Cliente fornece seu nome
cada ItemPedido informa a quantidade
correspondente e o valor de seu subtotal
os objetos Produto tambm colaboraram
fornecendo seu nome e preo unitrio.
40
41
Categorias de responsabilidades
Costuma-se categorizar os objetos de um
sistema de acordo com o tipo de

responsabilidade a ele atribuda.
objetos de entidade
objetos de controle
objetos de fronteira
Esta categorizao foi proposta por Ivar
Jacobson (Jacobson et al, 1992) em uma

tcnica denominada Anlise de Robustez.
42
Objetos de Entidade
Um objeto de entidade um repositrio para
alguma informao manipulada pelo

sistema.
Esses objetos representam conceitos do
domnio do negcio.
Normalmente esses objetos armazenam
informaes persistentes.
H vrias instncias de uma mesma classe
de entidade coexistindo no sistema.
43
Objetos de Entidade
Atores no tm acesso direto a estes objetos.
Objetos de entidade se comunicam com o

exterior do sistema por intermdio de outros
objetos.
Objetos de entidade normalmente participam de
vrios casos de uso e tm um ciclo de vida

longo.
Um objeto Pedido pode participar dos casos de

uso Realizar Pedido e Atualizar Estoque. Este
objeto pode existir por diversos anos ou mesmo
tanto quanto o prprio sistema.
44
Objetos de Entidade
Responsabilidades de fazer tpicas de
objetos de entidade:
Informar valores de seus atributos a objetos
de controle.
Realizar clculos simples, normalmente com a
colaborao de objetos de entidade
associados atravs de agregaes.
Criar e destruir objetos parte (considerando
que o objeto de entidade seja um objeto todo
de uma agregao).
45
Objetos de Fronteira
Esses objetos traduzem os eventos gerados
por um ator em eventos relevantes ao sistema.

Tambm so responsveis por apresentar os
resultados de uma interao dos objetos em
algo inteligvel pelo ator.
Um objeto de fronteira existe para que o
sistema se comunique com o mundo exterior.
Por conseqncia, estes objetos so
altamente dependentes do ambiente.
46
Classes de fronteira realizam a comunicao
do sistema com atores, sejam eles outros

sistemas, equipamentos ou seres humanos.
H trs tipos principais de classes de
fronteira:
as que se comunicam com o usurio (atores
humanos),
as que se comunicam com outros sistemas
as que se comunicam com dispositivos
atrelados ao sistema.
47
Tipicamente tm as seguintes
responsabilidades de fazer:
Notificar aos objetos de controle de eventos
gerados externamente ao sistema.
Notificar aos atores do resultado de interaes
entre os objetos internos.
48
Responsabilidades de conhecer de classes
de fronteira para interao humana

representam informao manipulada atravs
da interface com o usurio.
A construo de prottipos pode ajudar a

identificar essas responsabilidades.
Responsabilidades de conhecer para classes
de fronteira que realizam comunicao com

outros sistemas representam propriedades
de uma interface de comunicao.
49
Objetos de Controle
So a ponte de comunicao entre objetos
de fronteira e objetos de entidade.

Responsveis por controlar a lgica de
execuo correspondente a um caso de uso.
Decidem o que o sistema deve fazer quando
um evento externo relevante ocorre.
Eles realizam o controle do processamento
Agem como gerentes (coordenadores,
controladores) dos outros objetos para a
realizao de um ou mais caso de uso.
50
Objetos de Controle
So bastante acoplados lgica da
aplicao.
Traduzem eventos externos em operaes
que devem ser realizadas pelos demais
objetos.
Ao contrrio dos objetos de entidade e de
fronteira, objetos de controle so tipicamente
ativos
consultam informaes e requisitam servios

de outros objetos.
51
Objetos de Controle
Responsabilidades de fazer tpicas:
Realizar monitoraes, a fim de responder a

eventos externos ao sistema (gerados por objetos
de fronteira).
Coordenar a realizao de um caso de uso
atravs do envio de mensagens a objetos de
fronteira e objetos de entidade.
Assegurar que as regras do negcio (Seo
4.5.1) esto sendo seguidas corretamente.
Coordenar a criao de associaes entre
objetos de entidade.
52
Objetos de Controle
Responsabilidades de conhecer esto
associadas manter valores acumulados,

temporrios ou derivados durante a
realizao de um caso de uso.
Podem tambm ter o objetivo de manter o
estado da realizao do caso de uso.
Tm vida curta: normalmente existem
somente durante a realizao de um caso de
uso.
53
Diviso de responsabilidades
A categorizao de responsabilidades implica
em que cada objeto especialista em realizar

um de trs tipos de tarefa:
se comunicar com atores (fronteira)
manter as informaes do sistema (entidade)
coordenar a realizao de um caso de uso
(controle).
A importncia dessa categorizao est
relacionada capacidade de adaptao do

sistema a eventuais mudanas
54
Se cada objeto tem funes especficas
dentro do sistema, eventuais mudanas no

sistema podem ser:
1.
2.
menos complexas
mais localizadas.
Uma eventual modificao em uma parte do
sistema tem menos possibilidades de

resultar em mudanas em outras partes.
55
Tipo de mudana
Onde mudar
Mudanas em relao
interface grfica, ou em
relao comunicao com
outros sistemas.
Fronteira
Mudanas nas informaes

manipuladas pelo sistema
Entidade
Mudanas em funcionalidades
complexas (lgica do
negcio)
Controle
56
Exemplo: vantagem de separao de
responsabilidades em um sistema para uma

loja de aluguel de carros.
Se o sistema tiver que ser atualizado para

que seus usurios possam utiliz-lo pela
Internet, a lgica da aplicao no precisaria
de modificaes.
Considerando a lgica para calcular o valor total das

locaes feitas por um cliente: se esta lgica estiver
encapsulada em uma classe de controle, somente
esta classe precisaria de modificao.
57
A construo de um sistema de software que
faa separao das responsabilidades de

apresentao (fronteira), de lgica da
aplicao (controle) e de manuteno dos
dados (entidade):
facilita tambm o reuso dos objetos no

desenvolvimento de sistemas de software
semelhantes.
ajuda no desacoplamento entre elementos
do sistema
58
59
Partindo para a identificao

Anlise os casos de uso: cada caso de uso
analisado para identificar classes

candidatas.
Premissa: a partir da descrio textual dos
casos de uso, podem-se derivar as classes
do sistema.
a existncia de uma classe em um sistema

s pode se justificar se ela participa de
alguma forma para o comportamento
externamente visvel do sistema.
60

Os substantivos que aparecem no texto do
caso de uso so destacados.
So tambm consideradas locues

equivalentes a substantivos.
Sinnimos so removidos.
Vantagem: abordagem bastante simples.
Desvantagem: depende de como os casos de
uso foram escritos.
em linguagem natural, as formas de expressar

uma mesma idia so bastante numerosas.
61

Para contornar os problemas na
identificao de classes atravs da anlise

de casos de uso, uma soluo aplicar uma
estratgia em dois passos.
1.
2.
Faz-se a anlise dos casos de uso para

identificar as classes candidatas.
Depois disso, aplica-se uma outra tcnica
para validar o que foi descoberto e para
identificar novas classes: a modelagem
CRC.
62
Modelagem CRC
Se baseia fortemente no paradigma da
orientao a objetos, onde objetos cooperam

uns com os outros para que uma tarefa do
sistema seja realizada.
Efetiva quando profissionais que no tm
tanta experincia com o paradigma da
orientao a objetos esto envolvidos na
identificao de classes.
realizada em conjunto por especialistas de

domnio e desenvolvedores
63
Modelagem CRC
A modelagem CRC no faz parte da UML.
A princpio, essa tcnica foi proposta como
uma forma de ensinar o paradigma da

orientao a objetos a iniciantes.
Contudo, a sua simplicidade de notao a
tornou particularmente interessante para ser
utilizada na identificao de classes de
domnio.
64
Modelagem CRC
Especialistas do negcio e desenvolvedores
trabalham em conjunto para identificar

classes, juntamente com suas
responsabilidades e colaboradores.
Estes profissionais se renem em uma sala,
onde tem incio uma sesso CRC.
Uma sesso CRC envolve por volta de meia
dzia de pessoas: especialistas de domnio,
projetistas, analistas e um moderador.
A cada pessoa entregue um carto CRC.
65
Carto CRC
Nome da classe (especialidade)

Responsabilidades
Colaboradores
1 responsabilidade
2 responsabilidade
...
n-sima responsabilidade
1 colaborador
2 colaborador
..
n-simo colaborador
66
Exemplo (Carto CRC)

ContaBancria (entidade)
Responsabilidades
Colaboradores
1.Conhecer o seu cliente.

2.Conhecer o seu nmero.
3.Conhecer o seu saldo.
4.Manter um histrico de
Cliente
HistricoTransaes
transaes.
5.Aceitar saques e depsitos.
67
Modelagem CRC
Na distribuio dos cartes pelos
participantes, deve-se considerar as

categorias de responsabilidades.
Para cada cenrio de caso de uso tpico,
pode-se comear com:
um objeto de fronteira para cada ator

participante do caso de uso;
um objeto de controle para todo o caso de
uso;
normalmente h vrios objetos de entidade.
68
Modelagem CRC
Configurao inicial:
O moderador da sesso pode desempenhar
o papel do objeto controlador
Outro participante desempenha o papel do
objeto de fronteira.
Um outro participante pode simular o ator (ou
atores, se houver mais de um).
Os demais representam objetos de entidade.
69
Modelagem CRC
Uma vez distribudos os cartes pelos
participantes, um conjunto de cenrios de

cada caso de uso selecionado.
Para cada cenrio, uma sesso CRC
realizada.
Se o caso de uso no for to complexo, ele

pode ser analisado em uma nica sesso.
Normalmente j existem algumas classes
candidatas para um certo cenrio.
70
Modelagem CRC
A sesso CRC comea com a simulao do
ator primrio disparando a realizao do

caso de uso.
Os demais participantes encenam a
colaborao entre objetos para que o
objetivo do ator seja alcanado.
Atravs dessa encenao, as classes,
responsabilidades e colaboraes so
identificadas.
71
Modelagem CRC (procedimento)

1. Selecionar um conjunto de cenrios de casos
de uso.
2. Para um dos cenrios:
a)
b)
Examinar a sua seqncia de passos para

identificar as responsabilidades do sistema
em relao a cada um desses passos.
Identificar classes relevantes que devem
cumprir com as responsabilidades.
3. Repetir o passo 2 para o prximo cenrio e
modificar a alocao de responsabilidades e

a definio de classes.
72
Dicas para atribuio de

responsabilidades
Associar responsabilidades com base na
especialidade da classe.
Distribuir a inteligncia do sistema
Agrupar as responsabilidades
conceitualmente relacionadas
Evitar responsabilidades redundantes
73
Construo do modelo de
classes de domnio
74
Propriedades de uma classe

Uma responsabilidade de conhecer
mapeada para um ou mais atributos.

Operaes de uma classe so um modo
mais detalhado de explicitar as
responsabilidades de fazer.
Uma operao pode ser vista como uma

contribuio da classe para uma tarefa mais
complexa representada por um caso de uso.
Uma definio mais completa das operaes
de uma classe s pode ser feita aps a
construo dos diagramas de interao.
75
Definio de associaes e
agregaes
O fato de uma classe possuir colaboradores
indica que devem existir relacionamentos

entre estes ltimos e a classe.
Isto porque um objeto precisa conhecer o outro para

poder lhe fazer requisies.
Portanto, para criar associaes, verifique os
colaboradores de uma classe.
O raciocnio para definir associaes
reflexivas, ternrias e agregaes o

mesmo.
76
Definio de classes associativas

Surgem a partir de responsabilidades de
conhecer que o modelador no conseguiu

atribuir a alguma classe.
(mais raramente, de responsabilidades de
fazer)
77
Documentando o modelo de
classes
As responsabilidades e colaboradores
mapeados para elementos do modelo de

classes devem ser organizados em um
diagrama de classes e documentados,
resultando no modelo de classes de domnio.
Podem ser associados esteretipos
predefinidos s classes identificadas:
<<fronteira>>
<<entidade>>
<<controle>>
78
classes
A construo de um nico diagrama de
classes para todo o sistema pode resultar

em um diagrama bastante complexo. Um
alternativa criar uma viso de classes
participantes (VCP) para cada caso de uso.
Em uma VCP, so exibidos os objetos que
participam de um caso de uso.
As VCPs podem ser reunidas para formar
um nico diagrama de classes para o
sistema como um todo.
79
classes
O modelador pode optar por esconder as
classes de fronteira ou at mesmo as

classes de controle.
Uma ferramenta CASE que d suporte a

essa operao seria de grande ajuda para a
equipe de desenvolvimento.
Alm do diagrama, as classes devem ser
documentadas textualmente.
80
Modelo de classes no processo

de desenvolvimento
81
Modelo de classes no processo de

desenvolvimento
Em um desenvolvimento dirigido a casos de
uso, aps a descrio dos casos de uso,

possvel iniciar a identificao de classes.
As classes identificadas so refinadas para
retirar inconsistncias e redundncias.
As classes so documentadas e o diagrama
de classes inicial construdo, resultando no
modelo de classes de domnio.
82

desenvolvimento
Inconsistncias nos modelos devem ser
verificadas e corrigidas.
As construes do modelo de casos de uso
e do modelo de classes so retroativas uma
sobre a outra.
Na realizao de uma sesso CRC, novos

casos de uso podem ser identificados
Pode-se identificar a necessidade de
modificao de casos de uso preexistentes.
83

desenvolvimento
Detalhes so adicionados aos modelos,
medida que o problema entendido.
84
Diagrama de objetos
85
Diagrama de objetos
Alm do diagrama de classes, A UML define
um segundo tipo de diagrama estrutural, o

diagrama de objetos.
Pode ser visto com uma instncia de
diagramas de classes
Representa uma fotografia do sistema em
um certo momento.
exibe as ligaes formadas entre objetos

conforme estes interagem e os valores dos
seus atributos.
86
Notao para Diagrama de objetos

Formato
Exemplo
nomeClasse
Pedido
nomeObjeto: NomeClasse
umPedido: Pedido
87
Exemplo (Diagrama de objetos)
88
Exemplo (Diagrama de objetos)
89
Diagrama de objetos
Alm do diagrama de classes, A UML define
um segundo tipo de diagrama estrutural, o

diagrama de objetos.
Pode ser visto com uma instncia de
diagramas de classes
Representa uma fotografia do sistema em
um certo momento.
exibe as ligaes formadas entre objetos

conforme estes interagem e os valores dos
seus atributos.
90

Cap 05 Bezerra

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cap 05 Bezerra

Enviado por

Direitos autorais:

Formatos disponíveis

Princpios de Anlise e

Copyright 2002, 2003 Eduardo Bezerra

perspectiva do sistema a partir de um ponto

Copyright 2002, 2003

Aspectos dinmico e esttico

orientado a objetos fornecida atravs de

Essa colaborao pode ser vista sob o

aspecto dinmico e sob o aspecto

aspecto esttico o diagrama de classes.

Descrever um mtodo para identificao das classes

Copyright 2002, 2003

medida que o sistema desenvolvido,

Trs nveis sucessivos de abstrao:

classes no domnio do negcio em questo. No leva

Copyright 2002, 2003

Modelo de classes de domnio

pelo sistema a ser desenvolvido, sem

Copyright 2002, 2003

Copyright 2002, 2003

Notao para uma classe

mximo trs compartimentos exibidos.

Copyright 2002, 2003

Exemplo (classe ContaBancria)

Copyright 2002, 2003

podem se relacionar uns com os outros,

embora as associaes sejam representadas

Copyright 2002, 2003

Notao para uma associao

ligando as classes cujos objetos se relacionam.

Copyright 2002, 2003

inferior e superior da quantidade de objetos

Copyright 2002, 2003

Copyright 2002, 2003

Copyright 2002, 2003

Copyright 2002, 2003

associao entre duas classes: muitos para

Copyright 2002, 2003

Em um extremo No outro extremo

Muitos para muitos

Copyright 2002, 2003

Copyright 2002, 2003

indica a necessidade (ou no) da existncia

Copyright 2002, 2003

Nome de associao, direo de leitura

associao no diagrama de classes, a UML

Copyright 2002, 2003

Exemplo (Nome de associao,

Copyright 2002, 2003

Utilizada para representar conexes que

guardam uma relao todo-parte entre si.

Agregaes so assimtricas: se um objeto A

Copyright 2002, 2003

uma das perguntas a seguir for respondida

Copyright 2002, 2003

Notao para uma agregao

classes relacionadas, com um diamante (losango)

Copyright 2002, 2003

associao, ao invs de estar ligada a outras

Notao para uma classe

Representada pela notao utilizada para

uma classe. A diferena que esta classe

Copyright 2002, 2003

existente entre objetos de n classes.

Copyright 2002, 2003