Modelagem de classes

Prévia do material em texto

Princípios de Análise 
e Projeto de Sistemas 
com UML 
2ª edição 
Eduardo Bezerra 
 
Editora Campus/Elsevier 
Capítulo 5 
Modelagem de Classes de Análise 
“O engenheiro de software amador está sempre à procura da 
mágica, de algum método sensacional ou ferramenta cuja 
aplicação promete tornar trivial o desenvolvimento de software. 
Ë uma característica do engenheiro de software profissional 
saber que tal panacéia não existe” -Grady Booch 
Tópicos 
• Diagrama de Classes 
 
• Responsabilidade e Colaboração 
 
• Identificação das Classes Iniciais 
 
• Construção do Modelo de Classes de Domínio 
 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 3 
Tópicos 
• Diagrama de Classes 
 
• Responsabilidade e Colaboração 
 
• Identificação das Classes Iniciais 
 
• Construção do Modelo de Classes de Domínio 
 
 
 Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 4 
Introdução 
• O modelo de casos de uso fornece uma perspectiva do sistema 
do ponto de vista externo. 
 
• Externamente os atores visualizam resultados de cálculos, 
relatórios, confirmações de requisições; 
 
• Internamente os objetos colaboram entre si para formar os 
resultados que são visíveis ao usuário externo; 
 
• Essa colaboração pode ser vista do aspecto dinâmico e 
estrutural estático. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 5 
Introdução 
• O aspecto dinâmico descreve as trocas de mensagens entre 
os objetos e sua reação com eventos que ocorrem no sistema. 
 
• O aspecto estrutural estático mostra como o sistema está 
organizado internamente; 
– Estático refere-se ao fato de não possuir relação com o tempo 
– Estrutural refere-se ao fato das estruturas das classes e das relações 
entre elas serem representadas. 
 
• O diagrama que representa o aspecto estrutural estático de um 
sistema OO é o diagrama de classes. O modelo de classes 
consiste no diagrama e na descrição textual associada. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 6 
Modelo de Classes 
• O modelo de classes evolui durante o desenvolvimento do 
sistema; 
 
• Há três níveis: 
– Modelo de classes de domínio – Representa as classes no domínio do 
negócio, é construído ainda na análise e não leva em consideração as 
restrições da tecnologia utilizada. 
– Modelo de classes de especificação – Consiste na adição de detalhes 
específico no modelo de domínio. É feita no projeto. 
– Modelo de classes de implementação – É uma extensão do modelo de 
especificação, corresponde a implementação das classes em uma 
linguagem de programação. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 7 
Nomenclatura Utilizada 
• Padrão adotado no livro texto. Os termos não apresentam 
espaços em branco e preposições. 
 
• Para nome de classes e relacionamentos, palavras iniciam em 
maiúsculo: Cliente, ItemPedido, Pedido... 
 
• Para nome de atributos e nomes de operações (Exceto 
siglas), a primeira letra em minúsculo e as demais iniciais em 
maiúsculo: quantidade, precoUnitario, CPF, nome, 
dataNascimento... 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 8 
Diagrama de Classes 
Classes 
• São representadas através de uma caixa com no máximo três 
compartimentos. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 9 
Nome 
Atributos 
Operações 
Nome 
Nome 
Atributos 
Nome 
Operações 
Nome 
Atributos 
Operações 
Possíveis notações 
Diagrama de Classes 
• Exemplos de representação de uma mesma classe. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 10 
ContaBancaria 
ContaBancaria 
numero 
saldo 
dataAbertura 
ContaBancaria 
numero 
saldo 
dataAbertura 
criar(); 
bloquear(); 
desbloquear(); 
creditar(); 
debitar(); 
Diagrama de Classes 
Relacionamento entre objetos (associação) 
• Representa o relacionamento entre objetos de duas classes; 
 
• Uma associação é representada através de um segmento de reta 
ligando as classes. 
 
• Exemplo: um cliente compra produtos. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 11 
Cliente Produto 
Diagrama de Classes 
Relacionamento entre objetos (associação) – Multiplicidade 
• As associações permitem representar limites inferior e superior 
da quantidade de objetos o outro pode estar associado; 
 
• Esses limites são chamados de multiplicidade. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 12 
Nome Simbologia 
Apenas um 1..1 ou 1 
Zero ou muitos 0..* ou * 
Um ou muitos 1..* 
Zero ou um 0..1 
Intervalo específico i..j 
Diagrama de Classes 
Relacionamento entre objetos (associação) – Multiplicidade 
• Um cliente pode estar associado a vários pedidos 
 
 
• Uma corrida pode ter de 2 a 6 velocistas. 
 
 
• Pode haver outras multiplicidades, exemplo: 1,3,5..9,11 
significa que as a multiplicidade é: {1,3,5,6,7,8,9,11} 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 13 
Cliente Pedido 
1 0..* 
Velocista Corrida 
2..6 1 
Diagrama de Classes 
Relacionamento entre objetos (associação) – Multiplicidade 
• As associações podem ser agrupadas em três grandes tipos: 
“muitos para muitos”, “um para muitos”, “um para um”. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 14 
Conectividade Multiplicidade de um 
extremo 
Multiplicidade do outro 
extremo 
Um para um 0..1 ou 1 0..1 ou 1 
Um para muitos 0..1 ou 1 * ou 1..* ou 0..* 
Muitos para muitos * ou 1..* ou 0..* * ou 1..* ou 0..* 
Diagrama de Classes 
Relacionamento entre objetos (associação) – Multiplicidade 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 15 
Empregado Departamento 
1 0..1 
Empregado Departamento 
0..* 1 
Empregado Projeto 
0..* 1..* 
Um para um 
Um para muitos 
Muitos para muitos 
Diagrama de Classes 
Nome de associação, direção de leitura e papeis. 
• O nome da associação é posicionado na linha da associação; 
• A direção de leitura informa como a associação deve ser lida. 
• Os papéis de cada objeto em um relacionamento pode ser 
representado. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 16 
Diagrama de Classes 
Nome de associação, direção de leitura e papeis. 
• São muito úteis quando o significado de uma associação é 
difícil de compreender. 
• Auxilia em situações em que há múltiplas associações entre as 
mesmas classes. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 17 
Diagrama de Classes 
Agregação e Composição 
• São tipos especiais de associação, que representam 
relacionamentos todo-parte. 
 
• Agregação: Relação de dependência fraca: A existência do 
objeto-parte faz sentido sem o objeto-todo; É representado por 
um losango branco. 
 
• Composição: Relação de dependência forte: O objeto-parte 
não existe sem o objeto-todo. É representado por um losango 
preto. 
 
 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 18 
Diagrama de Classes 
Agregação e Composição 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 19 
Agregação 
Composição 
Diagrama de Classes 
Classes associativas 
• São classes que estão ligadas a associações, em vez de outras 
classes; 
• Mais comum em associações muitos para muitos 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 20 
Diagrama de Classes 
Classes associativas 
• Mais um exemplo: Consertos em automóveis são realizados 
por funcionários,mas é necessário saber que especialidade foi 
utilizada; 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 21 
Diagrama de Classes 
Classes Associativas 
• Uma classe associativa é um elemento híbrido: classe e 
associação; 
• Normalmente opta-se por remover essa classe e inserir uma 
classe ordinária com multiplicidade 1 para muitos. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 22 
Diagrama de Classes 
Associação ternária 
• São necessárias para associar elementos de três classes 
distintas; 
• São representadas como na figura abaixo. 
• Não são muito utilizadas. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 23 
Diagrama de Classes 
Associação ternária 
• Pode ainda haver uma utilização mútua de classes associativas 
e associação ternária. 
 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 24 
Diagrama de Classes 
Associações reflexivas 
• Também chamadas de auto associação; 
• Associa objetos de uma mesma classe. 
• Os papéis são importantes para facilitar a leitura; 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 25 
Tópicos 
• Diagrama de Classes 
 
• Responsabilidade e Colaboração 
 
• Identificação das Classes Iniciais 
 
• Construção do Modelo de Classes de Domínio 
 
 
 Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 26 
Identificando Classes Iniciais 
• Quando buscamos identificar as classes, estamos procurando 
os objetos que irão compor o sistema. 
 
• A identificação das classes se divide em duas etapas que são 
intercaladas: 
– Identificação das classes candidatas 
– Eliminação das classes desnecessárias 
 
• Existem dois métodos principais para identificar as classes de 
domínio: 
– Método dirigido a dados 
– Método dirigido a responsabilidades (será estudado) 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 27 
Responsabilidades e Colaboradores 
Responsabilidades 
• Em OO, os objetos encapsulam dados e comportamentos; 
 
• As responsabilidades são as obrigações que um objeto tem 
para com o sistema. 
 
• Através das responsabilidades, um objeto colabora com outros 
para alcançar os objetivos do sistema. 
 
• Na prática, é algo que o objeto faz. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 28 
Responsabilidade e Colaboradores 
Responsabilidade 
• Considerando um objeto cliente: 
– Ele conhece seu nome, endereço, telefone... 
 
• Considerando um pedido: 
– Ele conhece sua data de realização, ele também sabe calcular seu valor 
total. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 29 
Responsabilidade e Colaboração 
Colaboração 
• Algumas vezes um objeto tem responsabilidades que ele não 
consegue cumprir sozinho; 
 
• Deve haver colaboração com outros objetos; 
 
• Por exemplo na impressão da fatura de um pedido: 
– O objeto Pedido informa o seu valor total 
– O objeto Cliente o seu nome 
– Cada objeto ItemPedido a quantidade e o subtotal 
– Cada objeto Produto informa seu nome e preço unitário 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 30 
Responsabilidade e Colaboração 
• Resumindo... 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 31 
Objetos 
Responsabilidades 
O que o objeto conhece 
+ 
O que o objeto faz 
Colaboradores 
O padrão de comunicação 
entre os objetos 
Possuem 
Precisam de 
Realizadas por 
Categorias de Responsabilidade 
• Os objetos podem ser categorizados de acordo com o tipo de 
responsabilidade; 
 
• Os objetos podem ser divididos em (Proposto por Ivan 
Jacobson): 
– Objetos de entidade 
– Objetos de controle 
– Objetos de fronteira 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 32 
Categorias de Responsabilidade 
Objetos de Entidade 
• É um repositório para alguma informação manipulada pelo 
sistema; 
 
• Normalmente armazenam informações persistentes no sistema; 
 
• Os atores não possuem acesso direto a esses objetos; 
 
• Normalmente participam de vários casos de uso 
 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 33 
Categorias de Responsabilidade 
Objetos de Entidade 
• Algumas responsabilidades típicas: 
– Informar valores de seus atributos a objetos de controle 
– Realizar cálculos simples, normalmente com a colaboração de objetos 
de entidade; 
– Criar e destruir objetos todo-parte 
 
• Eles devem conhecer os elementos da sua criação. Por 
exemplo, um cliente deve conhecer nome, telefone, endereço... 
 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 34 
Categorias de Responsabilidade 
Objetos de Fronteira 
• Traduzem eventos gerados por um ator em eventos relevantes 
ao sistema; 
 
• São responsáveis por apresentar os resultados de uma iteração 
em algo que possa ser entendido pelo ator; 
 
• Permitem a comunicação com o mundo exterior; 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 35 
Categorias de Responsabilidade 
Objetos de Fronteira 
• As classes de fronteira normalmente fazem: 
– Notificam aos objetos de controle os eventos gerados externamente ao 
sistema; 
– Notificam aos atores o resultado de interações entre objetos internos. 
 
• Já as responsabilidades de conhecer, normalmente estão 
voltadas a propriedades da interface de comunicação. 
 
• No início os objetos de fronteira esses objetos são abstraídos. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 36 
Categorias de Responsabilidade 
Objetos de Controle 
• Servem como uma ponte entre os objetos de fronteira e os de 
entidade; 
 
• Decidem o que o sistema faz quando ocorre um evento externo 
relevante; 
 
• São bastante acoplados à lógica da aplicação. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 37 
Categorias de Responsabilidade 
Objetos de Controle 
• Responsabilidades de fazer típicas: 
– Realizar monitorações, a fim de responder a eventos externos ao 
sistema; 
– Coordenar a realização de um caso de uso através do envio de 
mensagens a objetos de fronteira e de entidade; 
– Assegurar que as regras de negócio estão sendo seguidas; 
– Coordenar a criação de associação entre objetos de entidade; 
 
• As responsabilidades de conhecer são usados para manter 
valores acumulados ou derivados durante a realização de um 
caso de uso, ou manter informações de estado dele. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 38 
Divisão de Responsabilidades 
• As categorias propostas por Jacobson implica que cada objeto 
é especialista em um de três tipos de tarefas: 
– Se comunicar com atores : Fronteira 
– Manter informações do sistema: Entidade 
– Coordenar a realização de um caso de uso: Controle 
 
• Auxilia na resposta a mudanças: 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 39 
Tipo de mudança Onde mudar 
Mudanças na interface do sistema (interface gráfica ou 
comunicação com outros sistema) 
Objetos de fronteira 
Mudanças nas informações manipuladas pelo sistema Objetos de entidade 
Mudanças em funcionalidades complexas (vários objetos) Objetos de controle 
Divisão de Responsabilidades 
• Como exemplo, consideremos uma loja de aluguel de carros; 
 
• O sistema necessita ser atualizado para que os clientes possam 
utilizar o sistema via internet; 
 
• Os objetos que precisam ser modificados nesse caso são os de 
fronteira; 
 
• A mudança é complexa, mas somente um subconjunto dasclasses seria modificado. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 40 
Divisão de Responsabilidades 
• Continuando o exemplo, esse sistema deve ter como classes de 
entidade: Carro, Aluguel, etc. 
 
• Deve também na classe de controle, uma lógica para calcular o 
valor total das locações feitas por um cliente; 
 
• Caso haja uma mudança na lógica, somente as classes de 
controle serão alteradas. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 41 
Divisão de Responsabilidades 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 42 
<<Fronteira>> <<Controle>> 
<<Entidade>> 
<<Entidade>> 
<<Entidade>> 
Tópicos 
• Diagrama de Classes 
 
• Responsabilidade e Colaboração 
 
• Identificação das Classes Iniciais 
 
• Construção do Modelo de Classes de Domínio 
 
 
 Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 43 
Identificação das Classes Iniciais 
• Os casos de uso podem ser usados como base para o 
desenvolvimento de um sistema; 
 
• É lógico, pois a existência de uma classe só faz sentido se ela 
participar de alguma forma de um comportamento visível do 
sistema; 
 
• O modelador analisa cada caso de uso e identifica as classes 
candidatas a desempenhar responsabilidades nas categorias: 
fronteira, controle e entidade. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 44 
Identificação das Classes iniciais 
• A descrição dos casos de uso são estudados para identificar as 
classes candidatas. 
 
• Todos os fluxos são analisados (principal, alternativos e 
exceção); 
 
• Na análise, os substantivos e locuções equivalentes são 
destacados e são removidos os sinônimos. Os nomes restante 
são classes candidatas. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 45 
Identificação das Classes Iniciais 
• Para identificar as responsabilidades de fazer, deve-se 
identificar os verbos que representam ações. 
• O substantivo da frase representa a classe que possui essa 
responsabilidade; 
 
• Vantagem: Abordagem simples; 
• Desvantagem: Depende da descrição dos casos de uso, e a 
linguagem natural omite alguns aspectos; 
• Solução: Após a análise, modelar CRC. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 46 
Modelagem CRC 
• Classe Responsabilidades e Colaboradores: Proposta em 1989; 
 
• Não faz parte da UML; 
 
• Na modelagem CRC os usuários, modeladores, projetistas, 
programadores trabalham juntos; 
 
• Utilizam cartões simples. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 47 
• Utiliza pequenos cartões onde constam o nome da classe e sua 
especialidade (fronteira, entidade ou controle), na esquerda são 
listadas suas responsabilidades e na direita os colaboradores. 
Modelagem CRC 
Nome da Classe (especialidade) 
Responsabilidades Colaboradores 
1ª responsabilidade 1º colaborador 
2ª responsabilidade 2º colaborador 
... ... 
nª responsabilidade mº colaborador 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 48 
• Exemplo 
Modelagem CRC 
ContaBancaria (entidade) 
Responsabilidades Colaboradores 
1 – Conhecer o seu cliente Cliente 
2 – Conhecer o seu número Historico 
3 – Conhecer o seu saldo HistoricoTransacoes 
4 – Manter um histórico de transações 
5 – Aceitar saques e depósitos 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 49 
Modelagem CRC 
Dicas para atribuição de responsabilidades: 
 
• Associar responsabilidades com base na especialidade da 
classe: 
– Fronteira 
– Entidade 
– Controle 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 50 
Modelagem CRC 
Dicas para atribuição de responsabilidades: 
 
• Distribuir a inteligência do sistema; 
• Não sobrecarregar uma ou um conjunto de classes; 
 
– Exemplo: Um objeto Pedido tem a responsabilidade de saber o seu 
valor total implica que ele deve saber os subtotais de cada item; 
 
– Solução: Cada objeto ItemPedido é responsável por calcular seu 
subtotal, com a ajuda de um objeto Produto 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 51 
Modelagem CRC 
Dicas para atribuição de responsabilidades: 
 
• Agrupar responsabilidades conceitualmente relacionadas 
 
– Responsabilidades relacionadas devem ser mantidas em uma classe; 
 
– Não “espalhar” as responsabilidades; 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 52 
Modelagem CRC 
Dicas para atribuição de responsabilidades: 
 
• Evitar responsabilidades redundantes: 
 
– Não repetir responsabilidades, criar uma nova classe ou escolher uma 
das classes para persistir a informação; 
 
– Lembrando-se da dica anterior... 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 53 
Tópicos 
• Diagrama de Classes 
 
• Responsabilidade e Colaboração 
 
• Identificação das Classes Iniciais 
 
• Construção do Modelo de Classes de Domínio 
 
 
 Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 54 
Criação do Modelo de Classes de 
Domínio 
• Após identificar classes e responsabilidades, deve-se verificar 
incoerências e inconsistências; 
 
• Depois devem ser definidas responsabilidades e colaborações 
entre as classes; 
 
• Esse modelo resumido comporá as classes de domínio. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 55 
Criação do Modelo de Classes de 
Domínio 
Definição das Prioridades de uma Classe 
 
• Após identificar as responsabilidades para atributos, deve-se 
verificar se os atributos: 
– Guardam valores atômicos 
 
– Não contém estrutura interna (complementa a anterior) 
 
– Aplica-se a todos os objetos da classe. Exemplo: É incoerente um 
atributo salário na classe Pessoa. 
 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 56 
Criação do Modelo de Classes de 
Domínio 
• É comum mapear responsabilidades de conhecer como 
atributos, mas as vezes uma associação é mais indicada. Ex.: 
 
– Atributo nomeCliente na classe Pedido, poderia ser trocada por uma 
associação entre Cliente e Pedido; 
– Se há a relação, não necessita de um atributo na classe fazendo 
referência. Confusão com o modelo relacional. 
 
 
 
 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 57 
Criação do Modelo de Classes de 
Domínio 
• É comum também no início definir um identificador para as 
classes. 
 
• No modelo de classes de domínio, não é necessário. 
 
• Isso não quer dizer que atributos que são identificadores 
naturais não possam ser definidos: 
– CPF 
– Código de um produto ou pedido 
– Número de matrícula 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 58 
Criação do Modelo de Classes de 
Domínio 
• Os atributos dependem do contexto: 
 
– Para um sistema de recursos humanos, uma Pessoa possui matrícula, 
nome, salário, data de contratação. 
 
– Para um sistema que guarda informações criminais: fotografia, peso, 
altura... 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 59 
Criação do Modelo de Classes de 
Domínio 
 
• As responsabilidades de fazer são as operações: 
 
• No início é difícil de identificar todas as operações; 
 
• Os diagramas de interação ajudam a identificar; 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 60 
Criação do Modelo de Classes de 
Domínio 
Associações e agregações 
 
• Se uma classe colabora com outra, deve haver relacionamentosentre elas; 
 
• As agregações são identificadas quando percebe-se uma 
relação todo-parte entre elementos das classes; 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 61 
Criação do Modelo de Classes de 
Domínio 
Classes associativas 
• Surgem quando há uma responsabilidade de saber que não 
pode ser atribuída a uma das classes; 
• Muitas pessoas trabalham em muitos projetos: 
– Quantas horas uma pessoa trabalha em cada projeto? Não pode ser 
atribuído a pessoa, nem a projeto; 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 62 
Criação do Modelo de Classes de 
Domínio 
Documentando o modelo de classes 
• Após identificar classes, responsabilidades e colaboradores, os 
mesmos devem ser organizados em um documento; 
 
• Na diagramação, as associações devem poder ser lidas da 
esquerda para direita ou de baixo para cima; 
 
• Podem ser definidos estereótipos para as classes: 
<<fronteira>>, <<entidade>> e <<controle>> 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 63 
Criação do Modelo de Classes de 
Domínio 
Documentando o modelo de classes 
 
• A construção de um único diagrama para todas as classes pode 
ser complexo; 
 
• Uma alternativa é criar uma VCP (Visão de Classes 
Participantes) para cada caso de uso; 
 
• As VCPs podem ser juntadas para formar um único diagrama, 
se ficar muito grande pode-se esconder as classes de fronteira 
ou até as de controle. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 64 
Criação do Modelo de Classes de 
Domínio 
Documentando o modelo de classes 
 
• Além do diagrama, deve haver uma documentação textual; 
 
• Pode-se utilizar os cartões CRC, com a adição de um pequeno 
texto para descrever a classe; 
 
• A medida que o desenvolvimento evolui, novos detalhes são 
adicionados. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 65 
Criação do Modelo de Classes de 
Domínio 
• Após construir o modelo de classes de domínio, deve-se 
retornar aos casos de uso para verificar inconsistências; 
 
• Há uma estrita relação entre os casos de uso e as classes de 
domínio: 
 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 66 
Criação do Modelo de Classes de 
Domínio 
• A construção do diagrama de classes é um processo 
incremental; 
 
• É necessário um pouco de experiência dos modeladores; 
 
• As classes de domínio sofrerão mudanças, principalmente 
quando adiciona-se aspectos dinâmicos: Diagrama de 
Interações e Diagrama de Estados 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 67 
Estudo de Caso 
• Páginas 130 a 137 do livro texto. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 68 
Exercício 
• Construir o modelo de casos de uso, e o modelo de classes de 
domínio para um caixa eletrônico. Considere inicialmente os 
casos de uso: Realizar Saque e Realizar Depósito. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 69 
Referências 
• BEZERRA, Eduardo. Princípios de Análise e Projeto de 
Sistemas com UML. Rio de Janeiro: Editora Campus, 2006. 
Princípios de Análise e Projeto de Sistemas com UML - 2ª edição 70