guia de modelagem

Prévia do material em texto

Guia para Modelagem de Classes de Projeto
Metodologia CELEPAR
Agosto 2009
Sumário de Informações do Documento
Documento: guiaModelagemDiagramaClasses.odt   Número de páginas: 29
Versão Data Mudanças Autor
1.0 ­­
Criação.
Este documento contém algumas orientações extraídas do guia 
ORIENTAÇÕES   PARA     DOCUMENTAR   A   FASE   DE 
PROJETO(documento elaborado por autores do GIC e   da  
GTI)  da versão 1.0 da metodologia CELEPAR.
Danielle Mayer
1.0 21/08/09 Revisão
Danielle Mayer, Marcos 
Chiarello, Cleverson Budel,  
Willian Medeiros
1.0 17/11/2009 Alterando     exemplos   com   a   correção   após   a   primeira   turma   de 
treinamento.
Danielle Mayer
Sumário
 1 Introdução.........................................................................................................................................4
2 Principais Conceitos .........................................................................................................................4
 2.1 GRASP: Padrões de Princípios Gerais para a Atribuição de Responsabilidades.....................4
 2.1.1 Especialista na Informação (Information Expert) ............................................................4
 2.1.2 Criador  (Creator)..............................................................................................................6
 2.1.3 Acoplamento  Fraco (Baixo Acoplamento – Low Coupling)...........................................7
 2.1.4 Coesão Alta  .....................................................................................................................9
 2.1.5 Controlador (Controler)..................................................................................................10
 2.2 Arquitetura de software..........................................................................................................11
 2.2.1 Padrão MVC...................................................................................................................11
 2.2.2 Padrão Fachada...............................................................................................................12
 3 Arquitetura lógica Adotada............................................................................................................14
 3.1 Camada de Controle................................................................................................................14
 3.1.1 Classe Controle...............................................................................................................14
 3.2 Camada de Visualização.........................................................................................................16
 3.2.1 Classes Tela.........................................................................................................................16
 3.3 Camada de Modelo.................................................................................................................17
 3.3.1 Classe Serviço.................................................................................................................17
 3.3.2 Classe Domínio...............................................................................................................20
 3.3.3 Classe de Persistência.....................................................................................................21
 3.3.4 Classe DTO (Data Transfer Objects)..............................................................................24
 4 Tratamento de Domínios ...............................................................................................................25
 5 Tipos de dados Recomendados:   ..................................................................................................27
 6 Checklist de elaboração..................................................................................................................28
4
 1  INTRODUÇÃO
Durante a fase de projeto há uma ênfase na definição dos objetos de software (projeto de 
objetos),  como  eles colaboram  para a satisfação dos requisitos e como se dará a persistência dos 
mesmos.  Neste  contexto  encontram­se os  diagramas  de  interação  e as  classes  de projeto,  estas 
vislumbradas   sob a ótica de uma arquitetura lógica.
Este documento tratará dos conceitos inerentes aos padrões arquiteturais e de projeto que 
norteiam a modelagem do diagrama de classes de projeto.
2 PRINCIPAIS CONCEITOS 
Fundamentalmente, o projeto de objetos exige o conhecimento de princípios de atribuição 
de responsabilidades, padrões de projetos e  arquiteturais.
Um padrão de projeto nomeia, abstrai e identifica os aspectos­chave de uma estrutura de 
projeto comum para torná­la útil para a criação de um projeto orientado a objetos reutilizável. O 
padrão de projeto identifica as classes e  instâncias participantes,  seus papéis,  colaborações   e a 
distribuição de responsabilidades. Cada padrão de projeto focaliza um problema ou tópico particular 
de projeto orientado a objetos, descreve quando e se ele pode ser aplicado em função de outras 
restrições de projetos e as conseqüências, custos e benefícios de sua utilização.
Nos próximos  tópicos  será   apresentado os  principais  padrões  GRASP,  os  conceitos  de 
arquitetura de software,  o padrão arquitetural MVC e o padrão FACHADA.
 2.1  GRASP: Padrões de Princípios Gerais para a Atribuição de Responsabilidades
Os padrões GRASP descrevem princípios fundamentais de projeto baseado em objetos e 
atribuições de responsabilidade aos mesmos.
 2.1.1  Especialista na Informação (Information Expert) 
É o padrão mais usado na atribuição de responsabilidade. Determina quem é o especialista 
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
5
em determinada informação, ou seja, a classe que tem a informação necessária para satisfazer tal 
responsabilidade ou que sabe como obter tal informação.
Problema: Qual é o princípio básico de atribuição de responsabilidades a objetos?
Solução:  Atribuir   a   responsabilidade   ao   objeto   que   tem   a   informação   necessária   para 
satisfazê­la. Este padrão é um princípio básico, usado continuamente no projeto orientado a 
objetos  na atribuição  de responsabilidades.  Ele  expressa a  “intuição” comum de que os 
objetos fazem coisas relacionadas com a informação que têm.
Exemplo:  Em um sistema de vendas, onde existem as classes Venda e ItemVenda, a classe 
responsável por manter o total de uma venda seria a classe Venda,  pois Venda é que detém 
o conhecimento sobre todos os seus itens de venda.  A classe ItemVenda não deve ter a 
responsabilidade de guardar o total de uma venda porque só conhece o valor do seu item.
Benefícios: 
● O encapsulamento  de   informações  é  mantido,  uma vez que  os  objetos  usam sua 
própria   informação  para   executar   tarefas,   favorecendo  o  acoplamento   fraco,   que 
conduz a sistemas mais robustos e fáceis de manter.
● O   comportamento   está   distribuído   entre   as   classes   que   têm   as   informações 
necessárias; assim são estimuladas definições   de classes “leves”, de maior coesão, 
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 1: Exemplo do uso do padrão Especialista
6
mais fáceis de compreender e manter.  
Contra­indicação:    Existem     situações   em   que   uma   solução   sugerida   pelo   padrão 
Especialista é indesejável,  devido ao problema de acoplamento e coesão. Um exemplo disso 
é tratar a persistência dos dados na classe do próprio domínio, analisando somente o padrão 
Especialista essa seria uma solução correta, mas analisando o fator coesão verifica­se que a 
classe de domínio não estará mais focada na parte pura da aplicação, ela terá que tratar os 
serviços técnicos ligados a banco de dados o  que diminuiria  sua coesão. Além disso, deve­
se   levar   em   consideraçãoo   princípio   básico   de   arquitetura:   projetar   para   obter   uma 
separação dos  principais   interesses  do sistemas,  como por  exemplo,  manter  a   lógica  da 
aplicação em um lugar (objetos de software de domínio) e a lógica relacionada com banco 
de dados em outro lugar ( como um subsistema separado para serviços de persistência).
 2.1.2  Criador  (Creator)
A criação de objetos é uma das atividades mais comuns em um sistema orientado a objetos. 
Desta forma, é útil ter um princípio geral para a atribuição de responsabilidades de criação.  Com 
essas   responsabilidades  bem atribuídas,  o  projeto   apresentará   acoplamento   fraco,  mais   clareza, 
encapsulamento e reutilização.
Este padrão  define qual classe deve ser responsável por criar instâncias de outras classes. 
A classe criadora deve ser aquela que possui a outra como parte dela ou que esteja fortemente 
associada a ela.
Problema: Quem deve ser responsável pela criação de uma nova instância de uma classe?
Solução:   Atribua à classe B a responsabilidade de criar uma instância da classe A se uma 
das seguintes condições for verdadeira:
● B agrega objetos de A;
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
7
● B contém objetos de A;
● B registra instâncias de objetos de A;
● B usa, de maneira muito próxima, objetos de A;
● B  tem os dados de iniciação que serão passados para A quando ele for criado 
(portanto, B é uma Classe Especialista com respeito à criação de A);
● B é um criador de objetos de A.
Se mais de uma opção for aplicável, prefira uma classe B que agrega ou comtém a 
classe A. 
Contra­indicação:   Muitas vezes, a criação é  uma tarefa complexa,  que exige o uso de 
instâncias recicladas por motivos de desempenho, eventualmente criando uma instância de 
uma família de classes similares com base no valor de alguma propriedade externa, e assim 
por diante.  Nesses casos, é aconselhável delegar a criação para uma classe auxiliar chamada 
Fábrica   (do  padrão  de   projeto  GOF   [GoF  Factory])   ao   invés   do   sugerido   pelo   padrão 
Criador.
Benefícios:  
Favorece  o acoplamento  fraco,   implicando em menor dependência  para a manutenção e 
maiores oportunidades de reutilização. O acoplamento não é aumentado pois a classe criada 
provavelmente já é visível para a classe criadora, por causa das associações existentes que 
motivaram sua escolha como criador. 
 2.1.3  Acoplamento  Fraco (Baixo Acoplamento – Low Coupling)
Acoplamento é a medida de quão fortemente um elemento está conectado a, tem conhecimento de 
ou depende de outros elementos.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
8
Uma classe com acoplamento fraco significa que ela não depende de muitas outras. Já uma classe 
com o acoplamento alto (ou forte) é mais difícil de reutilizar, pois seu uso depende da reutilização 
de outras classes da qual ela depende e também é mais sensível a mudanças nas classes associadas a 
ela.
Problema: Como favorecer a dependência baixa, o pequeno impacto à mudança e aumentar 
a reutilização? 
Solução: Atribuir uma responsabilidade de maneira que o acoplamento permaneça fraco.
O Acoplamento  Fraco favorece o projeto de classes que são mais   independentes,  o que 
reduz  o   impacto   de  mudanças.    Ele   não  pode   ser   considerado   isoladamente  de  outros 
padrões, como o Especialista e o Coesão Alta, mas, em vez disso, precisa ser incluído como 
um entre vários princípios de projetos que influenciam uma escolha na atribuição de uma 
responsabilidade.
Não   há   medida   absoluta   que   determine   quando   o   acoplamento   é   muito   forte.   O 
desenvolvedor deve avaliar o grau atual de acoplamento e julgar se o seu aumento trará 
problemas. Em geral, as classes que são genéricas por natureza, e com alta probabilidade de 
reutilização, deveriam ter acoplamento especialmente fraco.
Contra­Indicação: Não deve­se exagerar ao projetar visando o mais baixo acoplamento, 
essa prática exige bom senso. Aconselha­se que o projetista avalie suas decisões de reduzir o 
acoplamento e a encapsular coisas concentrando­se nos pontos passíveis de evolução e alta 
instabilidade. 
Benefícios:  Atribuir uma responsabilidade de maneira que o acoplamento permaneça fraco 
traz como benefício:
● O elemento não será afetado por mudanças em outros;
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
9
● É simples de entender isoladamente;
● É conveniente para reutilização.
 2.1.4  Coesão Alta  
Coesão é a medida de quão fortemente relacionadas e focalizadas são as responsabilidades 
de uma classe. 
Uma classe   com baixa  coesão  acaba   se   responsabilizando  por  mais   coisas  do  que  ela 
realmente   deveria   ser   responsável.   Classes   assim   acabam   oferecendo   dificuldade   para   o   seu 
entendimento e manutenção, sendo assim,  mais difíceis de reutilizar por não terem o foco definido. 
Problema: Como manter a complexidade sob controle? 
Solução: Atribuir uma responsabilidade de forma que a coesão permaneça alta. 
Como regra prática, uma classe com coesão alta tem um número relativamente pequeno de 
métodos, com funcionalidades altamente relacionadas, e não executa muito trabalho. Se a 
tarefa for grande, ela irá colaborar com outros objetos para dividir o esforço.
O nível de coesão não pode ser considerado isoladamente de outras responsabilidades e de 
outros princípios, como o Especialista e o Acoplamento Fraco.  Má coesão geralmente traz 
mau acoplamento, e vice­versa. São interdependentes.
Contra­Indicação:  Existem alguns poucos casos nos quais se justifica uma coesão mais 
baixa.  Um deles é  o agrupamento de responsabilidades  ou de código em uma classe ou 
componente  para  simplificar  a  manutenção  por  uma pessoa,  claro  que,   tal  agrupamento 
também  pode   piorar   a  manutenção.    Outro   caso   é   quando   existem   objetos   servidores 
distribuídos.  Por causa de sobrecarga e  das  implicações  de desempenho associadas  com 
objetos e  comunicações remotos, algumas vezes, é melhor criar uma quantidade menor de 
objetos   servidores   maiores,   menos   coesos,   que   forneçam   uma   interface   para   muitas 
operações.
Benefícios:   Atribuir uma responsabilidade de maneira que a coesão permaneça alta traz 
como benefício:
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
10
● Mais clareza e facilidade de compreensão no projeto;
● Simplificação da manutenção e do acréscimo de melhorias;
● Favorecimento do acoplamento fraco.
 2.1.5  Controlador (Controler)
Padrão que define a classe responsável por tratar um acontecimento externo ao sistema e 
que desencadeia alguma ação do mesmo. É o padrão responsável por tratar eventos do sistema.
Problema:  Quem deve ser responsável por tratar um evento de sistema? 
Um evento de entrada de um sistema é um evento gerado por um ator externo. Ele está 
associado com operações do sistema.
Um Controlador é um objeto da interface (mas não da interface com o usuário), responsável 
por   receber   ou   tratar   um  evento  do   sistema.  Um Controlador   define   o  método   para   a 
operação do sistema.
Solução: Atribuir a responsabilidade de receber ou tratar uma mensagem de um evento do 
sistema a uma classe que represente uma das seguintes escolhas:
●  Represente todo o sistema, o dispositivo ou subsistemas (controlador 
fachada);
● Represente um cenário de um caso de uso dentro do qual ocorra o evento do 
sistema. Deve­se usar, normalmente, uma classe controladora para todos os 
eventos do sistema no mesmo cenário   de caso de uso (poderia ser para   o 
mesmo caso de uso)
Benefícios:  
● Aumento  das  possibilidades  de   reutilização   e  de   interfaces  plugáveis: 
Delegar  a responsabilidade  de uma operação de sistemaa um controlador 
apóia a reutilização da lógica em aplicações futuras e, uma vez que a lógica 
não   está   presa  à   camada  de   interface,   esta  pode   ser   substituída  por  uma 
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
11
interface diferente.
● Conhecer o estado do caso de uso:    Identificar o estado da atividade e das 
operações dentro do caso de uso em processamento, caso se queira garantir 
que as operações do sistema ocorram em uma seqüência válida.
 2.2  Arquitetura de software
Para a  atribuição de responsabilidades  e  o  estabelecimento  de  interações  entre  objetos, 
habilidade central para o desenvolvimento orientado a objetos,  além dos padrões GRASP, citados 
anteriormente, devemos nos preocupar com a  interface com o usuário ou ao acesso aos recursos, 
como um banco de dados, aspectos importantes mapeados na arquitetura adotada.
Os   sistemas   são     tipicamente   compostos   de  muitos   pacotes   lógicos,   como   pacote   de 
interface com o usuário, pacote de acesso a banco de dados, etc. Cada pacote agrupa um conjunto 
de responsabilidades coesas guiados pela arquitetura lógica definida.
“Uma   arquitetura   é   o   conjunto   de   decisões   significativas   sobre   a   organização   de   um 
sistema de software,  a   seleção dos  elementos  estruturais  e  as   interfaces  das  quais  o   sistema é 
composto, junto com seu comportamento especificado nas colaborações entre estes elementos, a 
composição   desses   elementos   estruturais   e   comportamentais   em   subsistemas   progressivamente 
maiores e o estilo arquitetural que guia sua organização – esses elementos e suas interfaces, suas 
colaborações   e   sua   composição.”   (The   Unified   Modeling   Language   User   Guide   –   Booch, 
Rumbaugh e Jacobson ).
Resumidamente a   arquitetura lógica, descreve o sistema em termos de sua organização 
conceitual em camadas, pacotes, principais frameworks, classes, interfaces e subsistemas.
Há   várias  melhores   práticas   para   o   projeto   de   arquitetura   lógica,   entre   eles   podemos 
destacar o padrão MVC e o padrão Fachada.
 2.2.1  Padrão MVC
É um padrão de arquitetura que  consiste em dividir a aplicação em três partes: a lógica de 
negócios (Model), a  interface do usuário (View) e o fluxo da aplicação (Control).
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
12
● Modelo (Model):  Representa a camada que contém os processos de negócio da aplicação, 
encapsulando   dados   e   comportamento   independente   da   apresentação   (camada   de 
visualização).
● Visualização (View):  É  a camada de apresentação ao usuário. Esta camada  não deve ter 
responsabilidades   sobre   qualquer   lógica   ligada   ao   domínio,   devendo   ser   responsável 
somente  por   tarefas   relacionadas  com a   interface  do  usuário   como entrada  de  dados   e 
apresentação de resultados.
● Controle (Controller): Representa a camada responsável pela forma como a aplicação reage 
aos   estímulos   do  usuário,   determina   o   fluxo   de   apresentação   servindo   de   camada 
intermediária entre as camadas de visualização e modelo.
 2.2.2  Padrão Fachada
Padrão cujo objetivo é fornecer uma interface unificada para um conjunto de interfaces em 
um subsistema1.  Fachada define uma interface de nível mais alto que torna o subsistema mais fácil 
de ser usado.
Estruturar   um   sistema   em   subsistemas   ajuda   a   reduzir   a   complexidade.  Um objetivo 
comum de todos os projetos é minimizar a comunicação e as dependências entre subsistemas. Uma 
maneira de atingir este objetivo é introduzir um objeto fachada, o qual fornece uma interface única 
e simplificada para os recursos e facilidades mais gerais de um subsistema.
A fachada normalmente não deve expor muitas operações de baixo nível.  É desejável que 
a fachada exponha um pequeno número de operações de alto nível – serviços não refinados. Quando 
1 Subsistema: Grupo independente de classes que colaboram para cumprir um conjunto de responsabilidades.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura  2:   Diagrama   exemplificando   a   relação 
entre Model, View e Controller.
13
uma fachada expõe muitas operações de baixo nível, tende a se tornar não­coesa.
O padrão GRASP Controlador, utiliza o conceito do padrão Fachada. Escolher um objeto 
que represente todo o sistema ou organização para ser um controlador é um tipo de Fachada.
● Estrutura:
Participantes:
● Fachada: 
­ Conhece quais as classes do subsistema responsáveis pelo atendimento de 
uma solicitação;
­ Delega solicitações de clientes a objetos apropriados do subsistema.
● Classes de Subsistema: 
 ­ Implementam a funcionalidade do subsistema;
 ­ Encarregam­se do trabalho atribuído a  elas pelo objeto Fachada;
 ­ Não têm conhecimento da fachada; isto é, elas não mantêm referências para 
a mesma.
Colaborações:
● Os   clientes   se   comunicam   com   um   subsistema   através   do   envio   de 
solicitações para a Fachada, a qual as repassa para os objetos apropriados do 
subsistema.  Embora  os  objetos  do subsistema executem o  trabalho  real,  a 
fachada   pode   ter   que   efetuar   trabalho   próprio   dela   para   traduzir   a   sua 
interface para as interfaces de subsistemas;
● Os clientes que usam a fachada não tem que acessar os objetos do subsistema 
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 3: Exemplo do padrão Façade 
14
diretamente.
 3  ARQUITETURA LÓGICA ADOTADA
Esta   arquitetura   está   baseada   nos   padrões  MVC  (Model,   View,   Controller)  e   Fachada.     Seu 
principal objetivo fornecer subsídios para uma modelagem indepentente de plataforma(tecnologia).
 3.1  Camada de Controle
Representa a forma como a aplicação reage aos estímulos do usuário, determina o fluxo de 
apresentação servindo de camada intermediária entre as camadas de visualização e modelo.
 3.1.1  Classe Controle
As classes de controle são aquelas que recebem as solicitações da camada de visão e as 
transferem para a camada de modelo.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 4: Aquitetura Lógica Adotada
15
Padronização sugerida:
1. Classe Controle: Geralmente é associada a cada caso de uso,  contendo os  métodos 
de controle necessários ao funcionamento do mesmo. Atribuir a esta o estereótipo<< 
Controle>>  do perfil(RUPAnalysis) 
2. Métodos:  
■ É   aconselhável   que   cada   classe   controle   possua   um   método   de 
carregamento(Carregar<nome   da   tela>)   ex:CarregarPlanejamento.   Este 
método tem por objetivo o carregamento da tela inicial do respectivo cenário2 
de caso de uso;
■ Métodos da classe controle devem disparar a chamada de métodos da classe 
serviço da camada modelo;
■ Os   métodos   serão   identificados   durante   a   elaboração   do   diagrama   de 
seqüência desta fase.
■ Propriedade Documentação:   Se necessário, utilizar esta propriedade para 
informar   maiores   detalhes   do   método,   como   por   exemplo,   os   campos 
(informações) de tela que serão populados por este método – conforme figura 
6
Observação:   Evitar a citação de nomes de outros métodos na propriedade 
documentação,   a   chamada   de   métodos   deve   estar   sempre   explícita   no 
diagrama   de   seqüência.   Desta   forma,   alterações   na   sua   assinatura   são 
efetivadas automaticamente em todos os diagramas do projeto.
3. Exemplo: 
2Um cenário, ou instância de um caso de uso, é a descrição de uma das maneiras pelas quais um caso de uso um pode 
ser realizado. Normalmente há diversos cenários para um mesmo caso de uso
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
16
 3.2  Camada de Visualização
Representa basicamente a interface com o usuário. É utilizada parareceber a entrada dos 
dados e apresentar o resultado.
 3.2.1  Classes Tela
As  classes de tela são aquelas que recebem o evento do ator externo e repassam para a 
camada de controle. 
Padronização Sugerida:   Presente no documento Guia para Modelagem de Interações.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 6: Propriedade Documentação do método da classe Controle
Figura 5: Classe de Controle
17
Exemplo:
 3.3  Camada de Modelo
Representa  a  camada  que  contém os  processos  de  negócio  da  aplicação,  encapsulando 
dados e comportamento independente da apresentação (camada de visualização).
Esta  camada  conterá  classes  de  serviço,  classes  de  domínio,    classes  de persistência  e 
classes DTO.
 3.3.1  Classe Serviço
Classe cujo objetivo é fornecer uma interface para os recursos e facilidades mais gerais de 
um subsistema.
Classe Serviço X Classes de Domínio: A classe serviço, como ponto único de acesso para 
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 7: Classes de Tela
18
um   subsistema3,   deve   redirecionar   a   requisição   de   um   serviço   para   a(s)   classe(s)   de 
domínio(s)  o que o implementa.  Dessa forma, as classes que usam os serviços (como a 
classe de controle ou outras aplicações) não precisam se preocupar em conhecer as demais 
classes da camada de modelo que compõem a aplicação. Este tipo de classe  normalmente 
não deve expor muitas operações de baixo nível.  É desejável que a  exponha um pequeno 
número de operações de alto nível.
Classe Serviço X Classe de Persistência:
A classe de Serviço deve se preocupar também com o ciclo de vida do objeto (carregar, 
manipular) disparando as chamadas aos serviços técnicos de persistência.
Padronização Sugerida:
1. Criação da classe: Criar uma classe de serviço para cada subsistema e adicionar o 
estereótipo <<Servico>>. 
● Padrão de Nomenclatura:   XxxxFacade onde:  
Xxxx – é o nome da classe de fachada.
Facade – palavra fixa para indicar a utilização do padrão Fachada.
2. Métodos (Capacidades):
■ Os   métodos   serão   identificados   durante   a   elaboração   do   diagrama   de 
seqüência desta fase;
■ Métodos da classe serviço devem disparar a chamada de métodos das classes 
de domínio e persistência;
■ Propriedade Documentação:   Se necessário, utilizar esta propriedade para 
informar maiores detalhes do método.
○ Mensagens:  Mensagens   lançadas  por     estes  métodos  devem  estar 
descritas na referida propriedade Documentação.
Observação:   Evitar a citação de nomes de outros métodos na propriedade 
3 Subsistema: Grupo independente de classes que colaboram para cumprir um conjunto de responsabilidades.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
19
documentação,   a   chamada   de   métodos   deve   estar   sempre   explícita   no 
diagrama   de   seqüência.   Desta   forma,   alterações   na   sua   assinatura   são 
refletidas automaticamente em todos os diagramas do projeto.
3. Vínculo   com   classes   de   domínio   <<Entidade>>:  Crie,   se   necessário,   um 
relacionamento de dependência entre a classe <<Servico>>  e as classes de domínio 
aos quais esta classe representa.
4. Vínculo com classes de persistência <<Persistência>>:  Crie,  se  necessário,  um 
relacionamento   de   dependência   entre   a   classe   <<Servico>>     e   as   classes   de 
persistências os quais esta classe se comunica.
5. Vínculo   com     classes   de   controle   <<Controle>>:  Crie,   se   necessário,   um 
relacionamento  de  dependência  entre  a  classe    controle   e  as  classes  de  serviços 
acessadas por ela.
Exemplo:
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 8: Exemplo de Diagrama de Classes de Serviço e seus relacionamentos
20
 3.3.2  Classe Domínio
O  modelo   de  Domínio,   na   fase   de   análise,   identificou   os   conceitos   relacionados   aos 
requisitos do sistema e analisou o problema sob a perspectiva conceitual.
Agora  na  fase  de projeto  o modelo  de domínio  deve  representar  as  classes  de  projeto 
preocupando­se   com   o   domínio   da   solução,   desta   forma,   as   classes   de   domínio   devem   ser 
complementadas com as operações necessárias à execução do sistema em questão.
Padronização Sugerida:
1. Deve­se   atribuir   a   cada   classe   de   domínio   o   estereótipo<<Entidade>>  do 
perfil(RUPAnalysis) 
2. Métodos: 
■ Os   métodos   serão   identificados   durante   a   elaboração   do   diagrama   de 
seqüência desta fase;
■ Métodos desta classe tratam as regras de negócio do domínio, ou seja, não 
devem representar regras de negócio da aplicação, como controlar o ciclo de 
vida de objetos (carregar, manipular – camada de persistência). Para criação 
destes métodos observe os conceitos dos padrões GRASP;
■ Propriedade   Documentação:    Utilizar   esta   propriedade   para   informar 
maiores detalhes do método. 
○ Mensagens:  Mensagens   lançadas  por     estes  métodos  devem  estar 
descritas na referida propriedade Documentação.
Observação:   Evitar a citação de nomes de outros métodos na propriedade 
documentação,   a   chamada   de   métodos   deve   estar   sempre   explícita   no 
diagrama   de   seqüência.   Desta   forma,   alterações   na   sua   assinatura   são 
efetivadas automaticamente em todos os diagramas do projeto.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
21
3. Exemplo:
 3.3.3  Classe de Persistência
Classe cujo objetivo é tratar os   serviços técnicos de persistência de dados. Estas classes 
estão amparadas pelo padrão de projeto DAO (Data Access Object).
DAO (Data Access Object) ­ é um padrão para persistência de dados que permite separar 
regras de de acesso das regras de negócio. Numa aplicação que utilize a arquitetura MVC, todas as 
funcionalidades de bancos de dados, tais como obter as conexões, mapear objetos para tipos de 
dados SQL ou executar comandos SQL, devem ser feitas por classes de DAO.
Padronização Sugerida:
1. Criação da classe: Criar uma classe de persistência para cada classe de domínio que 
seja persistente e adicionar o estereótipo <<Persistência>>. 
● Padrão de Nomenclatura:   XxxxDAO onde:  
Xxxx – é o nome da classe de persistência.
DAO  – palavra fixa para  indicar  a utilização do padrão DAO para 
persistência
2. Métodos:
■ Os   métodos   serão   identificados   durante   a   elaboração   do   diagrama   de 
seqüência desta fase.
■ Propriedade  Documentação:  Utilizar  esta  propriedade  para  especificar  o 
método. 
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 9: Exemplo de Classes de Dominio na fase de Projeto
22
○ Mensagens:  Mensagens   lançadas  por     estes  métodos  devem  estar 
descritas na referida propriedade Documentação.
○ Paginação:  Para os métodos que realizem pesquisas,  informar se as 
mesmas devem ser paginadas.
Observação:  Métodos   padrões   como  salvar,   alterar,   excluir,   listar, 
obter e verificarExistencia não precisam ser especificados na propriedae 
documentação.
3. Vínculo com classes de domínio:  Crie um relacionamento de dependência entre a 
classe <<Persistência>>  e as classes de domínio aos quais esta classe representa.
4. Palavras Reservadas:
Visto que alguns métodos tem funcionalidades semelhantes, a nomenclatura destes 
foi padronizada para evitar sobreposições de definições de métodos e para agilizar a 
fase de projeto.
Os   seguintes   métodos   serão   considerados  métodos   do   tipo   padrão   e   não   será 
necessário especificá­los, na fase de projeto, bastando apenas referenciá­los:
• salvar, alterar, excluir, listar, obter e verificarExistencia
Por   conseqüência   os   nomes   destes   métodos   deverão   ser   considerados   como 
PALAVRASRESERVADAS e não poderão ser utilizados para identificar métodos 
com   características   especificas   de   uma   determinada   aplicação.   Também   como 
complemento  a   este  padrão  quaisquer  métodos  que  não  estejam enquadrados  no 
mesmo serão considerados como particulares da aplicação, deverão ser especificados 
e descritos da mesma forma que os demais.
PALAVRA Função 
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
23
salvar salvar ( objeto ) = inclui o objeto como registro.
alterar alterar ( objeto ) = altera registro de acordo com o objeto
excluir excluir   (   objeto   )   =   exclui   o   registro   correspondente   ao 
objeto.
listar listar ( ) = retorna todos os registros.
listar(objeto)   =  retorna   todos   os   registros   conforme   o(s)   filtro(s) 
informados no objeto.
Listar   (qtdPag,   numPag)   =   retorna   uma   lista   de   registros   paginados 
conforme os parâmetros.
listar(objeto, numPag, qdtPag) = retorna uma lista de registros  conforme 
o(s)   filtro(s)   informados   no   objeto     e     paginados     conforme   os 
parâmetros numPag/qtdPag.
listar(String[]) =  retorna todos os registros ordernados de acordo com o 
parâmetro.
listar(objeto,  String[])= retorna    uma lista de registros   conforme o(s) 
filtro(s) informados no objeto e  ordernados de acordo com o parâmetro.
listar(objeto, String[],  numPag, qdtPag) = retorna  uma lista de registros 
conforme o(s) filtro(s) informados no objeto,  ordernados e paginados de 
acordo com os demais parâmetros.
observação:  o  parâmetro  String[]  refere­se  a  um Array  de  pares  de 
string contendo os campos para ordenacao. Ex: [“nome”, “asc”, “idade”, 
“desc”]
verificarExistencia verificarExistencia(objeto)   :   boolean   =   retorna   verdadeiro/falso  
conforme o(s) filtro(s) informados no objeto.
obter obter ( id ) = obtém / retorna um objeto conforme o id do  
registro.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
24
5. Exemplo:
Figura 10: Exemplo de classe de persitência
 3.3.4  Classe DTO (Data Transfer Objects)
Classe caracterizada  por  armazenar   informações  que são  transferidas  entre  as camadas. 
Classes deste tipo são estruturas do armazenamento de dados contendo informações em formato 
específico que geralmente são utilizadas para generalizar a busca e o retorno de dados. 
Padronização Sugerida:
1. Padrão de Nomenclatura: XxxxDTO onde:  
Xxxx – é o nome da classe.
DTO  – palavra fixa para  indicar a utilização do padrão 
DTO.
Observação:  Essas classes são utilizadas apenas em situações muito específicas onde, por 
exemplo,  seja necessário mesclar informações de várias entidades para a emissão de um 
relatório. Use o bom senso.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
25
 4  TRATAMENTO DE DOMÍNIOS 
Domínio é uma abstração para possibilidades discretas com significado para o usuário. Por 
exemplo, um atributo indicador cujos valores possíveis sejam ATIVO ou INATIVO, um atributo 
sexo cujos valores possíveis sejam MASCULINO ou FEMININO,  caracterizam­se como domínios 
pois possuem um número fixo de possibilidades para preenchimento.
Na fase de projeto, deve­se decidir, se os domínios a serem utilizados serão tabelados ou 
não.    Se existe a possibilidade de um valor de domínio ser utilizado muitas vezes em consultas e 
relatórios, ou que estes valores possam crescer durante a vida do sistema, talvez seja útil que este 
domínio seja  tabelado,  pois o mesmo poderá   ser  utilizado diretamente  em queries  SQL. Sendo 
tabelado deverá ser representado no diagrama de classes de projeto como uma classe de domínio 
<<Entidade> .
Para os domínios não tabelados, domínios constantes, sua utilização dar­se­á diretamente 
na  codificação,   sendo   assim,   sugere­se   que   todas   as   constantes   devem   ser  modeladas   como 
enumerações.
Enumeração:  é uma classe com uma lista de constantes (literais de enumeração), por exemplo:
public enum TipoVeiculo {
CARRO,
MOTO,
CAMINHAO,
ONIBUS,
CARRETA,
BICICLETA
}
Normalmente, os códigos de uma enumeração começam em zero, conforme a linguagem de 
programação utilizadas, e são incrementados a cada nova constante adicionada. Se isso não for o 
desejado, é possível informar os códigos específicos para cada constante. Os nomes das constantes 
também são “imprimíveis”  e  podem ser  utilizados  para  montar  caixas  de seleção   (combobox), 
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
26
etiquetas (labels) e relatórios.
A   representação   no   diagrama   de   classe   dar­se­á   por   uma   classe   com   o   esteriótipo 
enumeração previsto pela UML2.   O fato de se modelar uma classe de enumeração, favorece no 
sentido de que esta pode ser compartilhada por mais de uma classe.
Exemplo 1: 
Neste exemplo a classe Veiculo tem um atributo do tipoVeiculo da classe 
enumeração TipoVeiculo.  A enumeração neste caso está considerando que as 
literais começam em 0 e são incrementadas a cada literal.
Exemplo 2:
Neste  exemplo  foram definidos  valores  específicos  para cada  constante,  e 
neste   caso,   deve­se   declarar   um   atributo   referente   ao   valor   da   instância 
representada pela constante e declarar seu valor entre parênteses ao lado de 
cada constante.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 11: Exemplo de Classe de Enumeração
Figura 12: Exemplo de Classe Enumeração
27
 5  TIPOS DE DADOS RECOMENDADOS:   
Para   fins   de   padronização   e   independência   de   plataforma   tecnológica   sugere­se   os 
seguintes  tipos de dados utilizados na modelagem:
● Character;
● Boolean;
● Date;
● DateTime;
● Decimal;
● File;
● Image;
● Integer;
● Money;
● String;
● Void.
Estes tipos de dados poderão ser utilizados tanto na declaração de atributos quanto nos 
parâmetros de métodos.
Observação:  
1 ­ Para representação de coleção de objetos como atributos utilize a multiplicidade presente no 
relacionamento entre as classes.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 13: Exemplo de multiplicidade no relacionamento
28
2 - Para representação de listas em assinatura de método utilize a multiplicidade do 
parâmetro ou do retorno.
 6  CHECKLIST DE ELABORAÇÃO
CHECKLIST
 O nome da cada classe deve iniciar com a primeira letra maiúscula.
 Os   nomes   de   objetos   utilizados   nas   operações,   devem   iniciar   com   letra  
minúscula. Exemplo: cliente, listaFornecedo.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
Figura 15: Exemplo de representação de 
listas em assinatura de método
Figura 14: Exemplo de 
multiplicidade no 
relacionamento – visão 
do relacionamento como 
atributo
29
CHECKLIST
 Utilizar o tipo void para as operações que não possuírem retorno.
 Cada   classe   representa  um pequeno,   consistente   e   exclusivo   conjunto  de 
responsabilidades.
 Verificar   se   existem classes  que  atendem aos   requisitos   comportamentais  
estabelecidos pelas realizações de casos de uso.
 Verificar se não existem duas classes com a mesma finalidade.
 O nome de cada operação ou atributo é descritivo e compreensível e deve ser  
um verbo no infinitivo.
 Os parâmetros de cada operação devem estar corretos em termos de número,  
nome e tipo.
 Cada operação deve ser usada pelo menos por uma realização de caso de 
uso?
 Verificar as  multiplicidades dos relacionamentos.
METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
	 1 Introdução
	2	Principais Conceitos 
	 2.1 GRASP: Padrões de Princípios Gerais para a Atribuição de Responsabilidades
	 2.1.1 Especialista na Informação (Information Expert) 
	 2.1.2 Criador (Creator)
	 2.1.3 Acoplamento Fraco (Baixo Acoplamento – Low Coupling)
	 2.1.4 Coesão Alta 
	 2.1.5 Controlador (Controler)2.2 Arquitetura de software
	 2.2.1 Padrão MVC
	 2.2.2 Padrão Fachada
	 3 Arquitetura lógica Adotada
	 3.1 Camada de Controle
	 3.1.1 Classe Controle
	 3.2 Camada de Visualização
	 3.2.1 Classes Tela
	 3.3 Camada de Modelo
	 3.3.1 Classe Serviço
	 3.3.2 Classe Domínio
	 3.3.3 Classe de Persistência
	 3.3.4 Classe DTO (Data Transfer Objects)
	 4 Tratamento de Domínios 
	 5 Tipos de dados Recomendados: 
	 6 Checklist de elaboração