Você está na página 1de 90

Princpios de Anlise e Projeto Orientados a Objetos com UML

Eduardo Bezerra Editora CAMPUS


Copyright 2002, 2003 Eduardo Bezerra 1

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

Copyright 2002, 2003 Eduardo Bezerra

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 Eduardo Bezerra

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.


Copyright 2002, 2003 Eduardo Bezerra 4

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.
Copyright 2002, 2003 Eduardo Bezerra 5

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.


Copyright 2002, 2003 Eduardo Bezerra 6

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.

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

Notao para uma classe


Representada atravs de uma caixa com no

mximo trs compartimentos exibidos. Notao utilizada depende do nvel de abstrao desejado.

Copyright 2002, 2003 Eduardo Bezerra

10

Exemplo (classe ContaBancria)

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

12

Notao para uma associao


Representada atravs de um segmento de

reta ligando as classes cujos objetos se relacionam. Exemplos:

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

14

Multiplicidades
Nome Apenas Um Zero ou Muitos Um ou Muitos Zero ou Um Intervalo Especfico Simbologia 1..1 (ou 1) 0..* (ou *) 1..* 0..1 li..ls

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

18

Conectividade X Multiplicidade
Conectividade Um para um Um para muitos Em um extremo 0..1 1 0..1 1 * 1..* 0..* No outro extremo 0..1 1 * 1..* 0..* * 1..* 0..*

Muitos para muitos

Copyright 2002, 2003 Eduardo Bezerra

19

Exemplo (conectividade)

Copyright 2002, 2003 Eduardo Bezerra

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.
Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra 22

Exemplo (Nome de associao, direo de leitura e papis)

Copyright 2002, 2003 Eduardo Bezerra

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.
Copyright 2002, 2003 Eduardo Bezerra 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.

Copyright 2002, 2003 Eduardo Bezerra

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?

Copyright 2002, 2003 Eduardo Bezerra

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:

Copyright 2002, 2003 Eduardo Bezerra

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.
Copyright 2002, 2003 Eduardo Bezerra 28

Notao para uma classe associativa


Representada pela notao utilizada para

uma classe. A diferena que esta classe ligada a uma associao. Exemplo:

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

30

Exemplo (associao ternria)

Copyright 2002, 2003 Eduardo Bezerra

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


Copyright 2002, 2003 Eduardo Bezerra 32

Exemplo (associao reflexiva)


Superviso

supervisor

1 *

Empregado supervisionado

Copyright 2002, 2003 Eduardo Bezerra

33

Identificando as classes iniciais


Copyright 2002, 2003 Eduardo Bezerra 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.

Copyright 2002, 2003 Eduardo Bezerra

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.


Copyright 2002, 2003 Eduardo Bezerra 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..
Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra 38

Responsabilidades e colaboradores
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.
Copyright 2002, 2003 Eduardo Bezerra 39

Responsabilidades e colaboradores
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.
Copyright 2002, 2003 Eduardo Bezerra 40

Responsabilidades e colaboradores

Copyright 2002, 2003 Eduardo Bezerra

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.


Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra

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).
Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra 46

Objetos de Fronteira
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.
Copyright 2002, 2003 Eduardo Bezerra 47

Objetos de Fronteira
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.

Copyright 2002, 2003 Eduardo Bezerra

48

Objetos de Fronteira
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.
Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra 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.


Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra

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.
Copyright 2002, 2003 Eduardo Bezerra 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


Copyright 2002, 2003 Eduardo Bezerra 54

Diviso de responsabilidades
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.

Copyright 2002, 2003 Eduardo Bezerra

55

Diviso de responsabilidades
Tipo de mudana Onde mudar

Mudanas em relao interface grfica, ou em relao comunicao com outros sistemas. Mudanas nas informaes manipuladas pelo sistema Mudanas em funcionalidades complexas (lgica do negcio)
Copyright 2002, 2003 Eduardo Bezerra

Fronteira

Entidade

Controle

56

Diviso de responsabilidades
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.
Copyright 2002, 2003 Eduardo Bezerra 57

Diviso de responsabilidades
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
Copyright 2002, 2003 Eduardo Bezerra 58

Diviso de responsabilidades

entidade

fronteira

controle

entidade

entidade
Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra 60

Partindo para a identificao


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.


Copyright 2002, 2003 Eduardo Bezerra 61

Partindo para a identificao


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.

Copyright 2002, 2003 Eduardo Bezerra

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


Copyright 2002, 2003 Eduardo Bezerra 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.

Copyright 2002, 2003 Eduardo Bezerra

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.
Copyright 2002, 2003 Eduardo Bezerra 65

Carto CRC

Nome da classe (especialidade) Responsabilidades 1 responsabilidade 2 responsabilidade ... n-sima responsabilidade Colaboradores 1 colaborador 2 colaborador .. n-simo colaborador

Copyright 2002, 2003 Eduardo Bezerra

66

Exemplo (Carto CRC)


ContaBancria (entidade) Responsabilidades 1.Conhecer o seu cliente. 2.Conhecer o seu nmero. 3.Conhecer o seu saldo. 4.Manter um histrico de transaes. 5.Aceitar saques e depsitos. Colaboradores Cliente HistricoTransaes

Copyright 2002, 2003 Eduardo Bezerra

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.
Copyright 2002, 2003 Eduardo Bezerra 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.

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

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.

Copyright 2002, 2003 Eduardo Bezerra

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.


Copyright 2002, 2003 Eduardo Bezerra 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

Copyright 2002, 2003 Eduardo Bezerra

73

Construo do modelo de classes de domnio


Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra 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.

Copyright 2002, 2003 Eduardo Bezerra

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)

Copyright 2002, 2003 Eduardo Bezerra

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


Copyright 2002, 2003 Eduardo Bezerra 78

Documentando o modelo de 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.
Copyright 2002, 2003 Eduardo Bezerra 79

Documentando o modelo de 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.

Copyright 2002, 2003 Eduardo Bezerra

80

Modelo de classes no processo de desenvolvimento


Copyright 2002, 2003 Eduardo Bezerra 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.

Copyright 2002, 2003 Eduardo Bezerra

82

Modelo de classes no processo de 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.

Copyright 2002, 2003 Eduardo Bezerra

83

Modelo de classes no processo de desenvolvimento


Detalhes so adicionados aos modelos,

medida que o problema entendido.

Copyright 2002, 2003 Eduardo Bezerra

84

Diagrama de objetos
Copyright 2002, 2003 Eduardo Bezerra 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.
Copyright 2002, 2003 Eduardo Bezerra 86

Notao para Diagrama de objetos


Formato nomeClasse nomeObjeto: NomeClasse Exemplo Pedido umPedido: Pedido

Copyright 2002, 2003 Eduardo Bezerra

87

Exemplo (Diagrama de objetos)

Copyright 2002, 2003 Eduardo Bezerra

88

Exemplo (Diagrama de objetos)

Copyright 2002, 2003 Eduardo Bezerra

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.
Copyright 2002, 2003 Eduardo Bezerra 90