Projeto de Software Orientado a Objeto

Prévia do material em texto

ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 1 
Aula 05: Projeto de Software Orientado a Objeto ........................................................................ 2 
Introdução ............................................................................................................................. 2 
Conteúdo ................................................................................................................................ 3 
Projeto do software ........................................................................................................... 3 
Detalhamento dos aspectos dinâmicos ........................................................................ 3 
Refinamento dos aspectos estáticos e estruturais ...................................................... 4 
Projeto da arquitetura ....................................................................................................... 5 
Persistência de objetos ..................................................................................................... 5 
Projeto de interface gráfica com usuário...................................................................... 5 
Projeto de algoritmos ....................................................................................................... 6 
Padrões de Projeto ............................................................................................................ 6 
Interações ............................................................................................................................ 6 
Modelagem de classes de projeto .................................................................................. 8 
Passando da análise ao projeto: classes........................................................................ 9 
Classes: detalhes do projeto .......................................................................................... 10 
Derivação do diagrama de classes de projeto ........................................................... 12 
Modelos de interação na construção do modelo conceitual de classes .............. 13 
Reutilização: padrões, bibliotecas e componentes ................................................... 16 
Responsabilidades ........................................................................................................... 18 
Padrões GRASP ................................................................................................................. 19 
Padrão CREATOR (criador) ............................................................................................ 20 
Padrão INFORMATION EXPERT (especialista na informação) ................................ 21 
LOW COUPLING, CONTROLLER e HIGH COHESION .............................................. 22 
Referências........................................................................................................................... 23 
Exercícios de fixação ......................................................................................................... 23 
Chaves de resposta ..................................................................................................................... 28 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 2 
Introdução 
A fase ou disciplina de análise está voltada à identificação e análise dos 
requisitos dos diversos usuários dos sistemas, ou seja, voltada ao entendimento 
e modelagem do problema do negócio ao qual o sistema está relacionado. 
 
O modelo de casos de uso está intimamente relacionado aos requisitos 
funcionais do sistema e modelo conceitual de classes para evidenciar as classes 
relacionadas ao problema. Além das classes, são identificados alguns atributos 
que caracterizam a entidade do negócio. 
 
A fase ou disciplina de projeto visa adicionar detalhes ao modelo de classes, de 
forma que esse passe a representar aspectos de projeto. Tal ação possibilita a 
definição da arquitetura do sistema, seus componentes e a relação entre eles. 
 
Nesta aula, focaremos a transição da análise para o projeto, mostrando os 
refinamentos necessários ao modelo de classes e considerando as interações 
(diagramas de sequência e/ou comunicação) entre os objetos na realização de 
um caso de uso e alguns padrões de projeto. 
 
Objetivo: 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 3 
1. Caracterizar o projeto de software e suas atividades; 
 
2. Definir padrões de projeto e reconhecer sua utilidade na definição do 
diagrama de classes de projeto. 
Conteúdo 
Projeto do software 
A fase ou disciplina de projeto de software visa especificar como o software vai 
funcionar, sendo ele voltado a uma arquitetura e a um ambiente físico 
específico. O projeto visa estabelecer alternativas de solução, de forma que os 
requisitos funcionais sejam atendidos e que sejam também respeitadas as 
restrições definidas pelos requisitos não funcionais. 
 
Conforme definido em Princípios de análise e projeto de sistemas com 
UML, de Eduardo Bezerra, as principais atividades realizadas durante o projeto 
de software são: 
 
 Detalhamento dos aspectos dinâmicos. 
 Persistência de objetos. 
 Padrões de software. 
 Refinamento dos aspectos estáticos e estruturais. 
 Projeto de interface gráfica com usuário. 
 Projeto da arquitetura. 
 Projeto de algoritmos. 
 
A seguir, conheça cada uma dessas atividades. 
 
Detalhamento dos aspectos dinâmicos 
• Aspectos dinâmicos dos objetos dizem respeito ao comportamento desses na 
troca de mensagens para cumprir com suas responsabilidades. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 4 
• Embora o estudo dos aspectos dinâmicos inicie na fase ou disciplina de 
análise, é na fase de projeto que ele se intensifica, pois é quando nos 
preocupamos com o detalhamento das colaborações nas quais cada classe 
participa. 
 
• A UML disponibiliza os modelos de interação (sequência ou comunicação), o 
diagrama de estados e o diagrama de atividades. 
 
Refinamento dos aspectos estáticos e estruturais 
• Refinamento do modelo conceitual de classes acrescenta atributos e métodos 
que melhor definam as responsabilidades. 
 
• Pode haver classe de análise que precise ser representada por mais de uma 
classe de projeto e vice-versa (embora isso seja mais difícil). 
 
• São revistos e definidos tipos para os atributos. 
 
• São definidas as navegabilidades das associações entre classes. 
 
• Refinamento dos relacionamentos de associações, que podem vir a ser 
composição/agregação, generalização/especialização, classes de associação e 
dependências. 
 
• Devem ser considerados aspectos como coesão e acoplamento, garantindo 
maior independência entre as classes. Deve ser considerada ainda a correta 
aplicação do conceito de encapsulamento. 
 
• Destaque deve ser dado à fatoração de classes através dos conceitos de 
herança (relacionamento de generalização e especialização entre classes) e 
polimorfismo. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 5 
Projeto da arquitetura 
A arquitetura lógica, conforme já citamos em nossas aulas, diz respeito à 
divisão do software em camadas, incluindo aqui o modelo MVC e o modelo em 
camadas de apresentação, domínio, persistência etc. O diagrama de pacotes é 
o modelo disponibilizado pela UML para representação da arquitetura lógica. 
 
A arquitetura física diz respeito à localização física dos componentes de 
software em diferentes nós de processamento (processadores). Nos dias de 
hoje, é muito comum essa distribuição de componentes em nós, são os 
chamados sistemas distribuídos. 
 
Aspectos relevantes a serem considerados são: subsistemas;interfaces; 
camadas de software, como controle e dependência entre subsistemas. 
 
A UML disponibiliza o diagrama de componentes para representar os 
componentes do sistema e a dependência entre eles, bem como o diagrama de 
implantação, o qual apresenta os nós de processamento e a relação entre eles. 
 
Persistência de objetos 
• Diz respeito à forma como os objetos são armazenados de forma persistente, 
em geral em banco de dados, que podem ser relacionais, objetos relacionais ou 
de objetos. 
 
• Quando a persistência ocorre em bancos de dados relacionais ou objeto 
relacional, deve-se elaborar estratégia de migração do modelo de classes para 
o modelo relacional ou objeto relacional. 
 
Projeto de interface gráfica com usuário 
• Definição das telas com as quais os atores interagem, com base nos casos de 
uso. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 6 
• Definição dos relatórios e formulários de apoio ao sistema. 
 
• Devem ser considerados aspectos de usabilidade e ainda as restrições 
estabelecidas nos requisitos não funcionais. 
 
Projeto de algoritmos 
Consiste na definição da lógica e das estruturas de dados necessárias à 
definição dos algoritmos contidos nos métodos das classes. 
 
Conforme a complexidade dos algoritmos, podem ser definidos formalmente, 
com textos ou ainda informalmente. 
 
UML disponibiliza diagrama de atividades com a finalidade de expressar 
algoritmos complexos ou que tenham ações em paralelo. 
 
Padrões de Projeto 
Padrões de software têm sido bastante usados em projetos de software na 
tentativa de desenhar sistemas mais consistentes, com maior reuso. 
 
Os padrões são usados nas fases e disciplinas de análise e de projeto. 
 
Interações 
Os diagramas de interação são extremamente valiosos, pois vamos entender e 
raciocinar em detalhes sobre quais mensagens enviar, para quem e em 
que ordem. Podemos, nesse momento, refletir também sobre quais objetos 
realmente precisam existir, quais as responsabilidades de cada um e como 
interagem. É o momento de verificarmos se podemos aplicar algum padrão de 
projeto dentro do princípio de aplicação de boas práticas. 
 
Em geral, já aprendemos que: 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 7 
 
 
 
Toda mensagem que chega a um objeto no diagrama de sequência ou 
comunicação vai representar uma operação da classe, ou seja, um método na 
classe que recebe a mensagem. 
 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 8 
Observe que ao objeto Cliente, chega uma mensagem de nome Procurar 
Cliente (Id Cliente), ou seja, essa será a assinatura de um método da classe, 
conforme especificado na classe Cliente. 
 
 
 
Cliente 
+ Procurar Cliente (Ident Cliente : int) : boolean 
 
Modelagem de classes de projeto 
As classes de projeto são aquelas necessárias para implementar as 
funcionalidades do sistema definidas na análise, considerando as restrições 
imputadas pelos requisitos não funcionais. Veja alguns exemplos de situações 
que nos fazem acrescentar classes ao modelo conceitual, dando origem ao 
modelo de classes de projeto. 
 
• Classes que sirvam de base para implementação do mecanismo de herança, 
as chamadas classes abstratas; 
• Controle de segurança (autorização e autenticação de acesso); 
• Registro de ações realizadas no sistema (guardam-se os logs de acesso); 
• Acesso e armazenamento (consistência) dos dados; 
• Classes de interface com usuário e classes de controle, seguindo-se o padrão 
MVC (model-view-controller). 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 9 
Cada situação relatada implica na necessidade de novas responsabilidades do 
sistema, que demanda novas classes a serem projetadas. 
 
Além de novas classes, vamos também, nesse momento, refinar as classes 
definidas no modelo conceitual de classes no que se refere a: 
 
• Visibilidade de atributos e métodos; 
• Detalhes das assinaturas dos métodos, como, por exemplo, os argumentos 
adequados, o tipo de dado que retorna; 
• Análise da possibilidade de uso da herança; 
• Identificação de novos métodos pela análise das interações dos diagramas de 
sequência e/ou comunicação; 
• Substituição de relacionamentos de associações por outros mais 
semanticamente adequados, como, por exemplo: agregação – composição – 
classe de relacionamento – dependência. 
 
Passando da análise ao projeto: classes 
Veja uma classe típica de um modelo conceitual de classes, onde são 
apresentados os atributos e métodos obtidos diretamente do diagrama de casos 
de uso (ou de outra técnica), sendo poucos detalhes apresentados. 
 
• O nome da classe, que representa algo relevante para o negócio; 
• Os nomes dos principais atributos, a partir dos dados recuperados da 
especificação textual dos casos de uso; 
• Os nomes de possíveis métodos derivados de casos de uso. 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 10 
Classes: detalhes do projeto 
• Estereotipo da classe(<<entity>>) 
 
• Refinamento dos atributos: 
 • Padrão: visibilidade/nome: tipo = valor inicial. 
 • Visibilidade: representada pelo sinal de menos (-) antes de cada nome de 
atributo. No caso o menos, (-) indica uma visibilidade privada ao atributo. 
 • Nome: em geral, é o mesmo do modelo conceitual de classes. 
 • Tipo: representa o tipo de dado dos atributos. No caso, string. 
 • Valor inicial: seria o valor de inicialização de um atributo quando da criação 
do objeto. Não foi usado nesse exemplo. 
 
Refinamento dos métodos: 
 • Padrão: visibilidade/nome (parâmetros): tipo/retorno. 
 • Visibilidade: representada pelo sinal de mais (+) antes de cada nome. No 
caso, o (+) indica uma visibilidade pública ao método. 
 • Nome: o nome dos métodos. Se o método já existia no modelo conceitual de 
classes, pode-se usar o mesmo nome. Se o método foi descoberto por um 
diagrama de interação (sequência ou comunicação), deve-se usar o mesmo 
nome usado nesses diagramas. 
 • Tipo/retorno: representado por VOID após o nome Incluir Fornecedor e 
Boolean para o método pesquisar fornecedor. VOID indica que a função não 
retorna nenhum tipo de dado, sendo, portanto, um procedimento, e não uma 
função. 
 
• Novos métodos descobertos pelos diagramas de interação 
(sequência ou comunicação), por exemplo: 
 • + Pesquisar Fornecedor. 
 
• Assinatura completa do método, contendo: 
 • + Pesquisar Fornecedor (cnpj: string): boolean. 
 • Visibilidade: + (pública). 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 11 
 • Nome: Pesquisar Fornecedor. 
 • Parâmetros: Cnpj: string. 
 • Tipo de dado que retorna: boolean. 
 • Ou seja, é uma função que retorna um valor booleano (V ou F), se encontrou 
ou não o fornecedor referenciado pelo parâmetro CNPJ, que é do tipo string. 
 
• Novas classes são acrescentadas, por exemplo: 
 • EnderecoFornc – na medida em que o fornecedor, com suas filiais, possui 
mais de um endereço que deve ser tratado no sistema. O relacionamento 
indicado foi de composição, pois a vida (criação e destruição) dos objetos da 
classe Endereco está diretamente relacionada à vida dos respectivos objetos 
da classe FornecedorE. 
 
• Inclusão da navegabilidade (seta chegando na classe 
EnderecoFornc): 
 • Conforme elemento apresentado, também é obtido pela elaboração e análise 
dos diagramas de interação. A navegabilidade indica a direção da interação, ou 
seja, no exemplo visto, apenas objetos da classe FornecedorE podem enviar 
mensagem a objetos da classe EndereçoFornc. 
 
Na imagem a seguir, vemos a representação da classe Fornecedor em umdiagrama de classes de projeto, derivado do modelo conceitual de classes e 
contendo detalhes de projeto. 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 12 
Derivação do diagrama de classes de projeto 
No diagrama conceitual de classes, não há preocupação na identificação exata 
dos relacionamentos. De uma forma geral, são indicados como associações. Na 
elaboração do diagrama conceitual de classes, temos que nos preocupar com a 
melhor forma de implementar. 
 
Considere o seguinte trecho de um diagrama conceitual de classes: 
 
 
 
Veremos mais exemplos de derivação de diagrama de classes de projeto com 
base no diagrama conceitual de classes e algumas decisões de implementação. 
 
Veja um dos possíveis trechos de diagrama de classes de projeto: 
 
 
1. Inclusão da classe Item Pedido, pois é necessário conhecer os produtos 
que pertencem a um pedido. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 13 
 
2. Assim sendo, o pedido passa a ser composto de Item Pedido, pelo 
relacionamento de composição (a vida de Item Pedido depende de pedido, ou 
seja, é criada e destruída por objetos da classe Pedido). E a classe Item 
Pedido refere-se à classe Produto. Foram adicionadas as multiplicidades dos 
novos relacionamentos identificados. 
 
3. Como as vendas podem ter descontos unitários de produto, adicionou-se o 
atributo Desconto Unit à classe Item Pedido. 
 
4. Outra decisão de projeto foi a inclusão dos atributos Valor Pedido e 
Impostos Pedido, que vão armazenar o total do pedido e o total de impostos 
a serem recolhidos por pedido. Tal decisão deu-se pela necessidade de uma lei 
vigente de informar tais dados ao fisco. 
 
 5 - Na classe ProdutosE foi incluído o atributo Perc Imposto, que visa 
informar o percentual de imposto daquele produto na venda. Esse atributo é a 
base para que se possa armazenar o atributo Impostos Pedido, que soma o 
valor de todos os impostos de todos os itens constantes no pedido. 
 
 
Modelos de interação na construção do modelo conceitual de 
classes 
Vamos demonstrar agora a utilidade dos modelos de interação para a 
construção do modelo conceitual de classes. Para tal, vamos construir um 
diagrama de sequência, tomando por base: 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 14 
• O trecho de diagrama de casos de uso; 
• A especificação textual do caso de uso “registrar pedido”; 
• O trecho do diagrama de classes de projeto. 
 
Todos os exemplos foram vistos anteriormente neste curso. Veja a seguir o 
diagrama de sequência. 
 
Utilidade dos modelos de interação para a construção do modelo 
conceitual de classes: diagrama de sequência 
 
 
 
CASO DE USO: REGISTRAR PEDIDO 
 
Objetivo: registrar os pedidos solicitados pelos clientes. 
Ator: atendente. 
 
Cenário principal 
1. Atendente informa Id Cliente. 
2. Sistema localiza cliente. 
3. Para cada item a ser inserido são feitos tais passos: 
3.1. Atendente informa Id Produto. 
3.2. Sistema localiza produto. 
3.3. Atendente informa quantidade de produto. 
3.4. Sistema valida quantidade de produto. 
3.5. Sistema registra item do pedido. 
4. Atendente confirma dados do pedido. 
5. Sistema registra pedido. 
 
Cenários alternativos 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 15 
 2.a. Cliente não cadastrado: 
 1. Sistema informa “Cliente não cadastrado”. 
 2. <<Extends Incluir Cliente>>. 
 
 3.a. Produto não cadastrado: 
 1. Sistema informa “Produto não cadastrado”. 
 2. Sistema retorna ao passo 3.1 do cenário principal. 
 
 4.a. Sem estoque suficiente: 
 1. Sistema informa “Não há estoque suficiente do produto para a 
qtde informada”. 
 2. Sistema retorna ao passo 3.3. do cenário principal. 
 
Com base nos diagramas e especificações apresentados, o diagrama de 
sequência do cenário principal do caso de uso “registrar pedido” pode ficar tal 
como apresentado a seguir (possuindo outras soluções). 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 16 
 
O diagrama de sequência apresentado conta a história do caso de uso 
“registrar pedido” mostrando as classes que interagem e quais mensagens são 
trocadas entre elas. Dessa solução, uma das possíveis, observe: 
 
 O método “Inicializar Pedido”, da classe “PedidoE” vai iniciar o 
pedido, gerando o número do pedido através do método “Gera 
NumPedido”, também da classe “PedidoE”, e ainda criando o 
objeto “Itens Pedido”, que vai armazenar os itens do pedido 
inicializado através do método “Criar ItemPed”, que tem como 
parâmetro o “Num Pedido” que acabou de ser gerado. 
 Observe o loop, quadrado que circunda desde o item “Pedido” 
informado pelo atendente até o retorno do método “Incluir Item 
Pedido” (“Num Pedido”, “Id Produto”, “Qtde Produto”). Ele indica 
que todas as entradas de dados e todos os métodos com seus 
respectivos retornos são repetidos, conforme indicado na 
especificação textual do cenário principal do caso de uso em 
questão (“registrar pedido”). 
 Observe que, a cada produto e respectiva quantidade informados 
pelo atendente, e após verificações de produto existente e 
quantidade em estoque, o item do pedido é registrado pelo 
método “Incluir Item Pedido” (“Num Pedido”, “Id Produto”, “Qtde 
Produto”) da classe “Itens Pedido”. 
 Ao final, após o fim do loop, o pedido é confirmado pelo 
atendente, quando o pedido é finalizado (registro efetivamente 
inserido). 
 
Reutilização: padrões, bibliotecas e componentes 
O projetista do software tem sempre em mente a possibilidade de 
reutilização de classes e de soluções já existentes, de forma a obter vantagens 
quanto ao tempo de desenvolvimento (solução já pronta) e confiabilidade (uso 
e testes já realizados). 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 17 
As principais fontes de reutilização de código são: 
 
Padrões de projeto 
• Um padrão de software é uma solução para um problema recorrente, dentro 
de um contexto específico. A ideia é conceber soluções a partir de outras já 
vivenciadas, similares, que foram documentadas e, principalmente, aprovadas. 
• Um padrão de software, de forma geral, aumenta a produtividade na medida 
em que o projetista não precisa “reinventar a roda”. 
• A solução apontada pelo padrão serve de ponto de partida para o problema 
com o qual o projetista se depara. 
• São formas de reuso abstratas, na medida em que descrevem a essência da 
solução de problemas comuns e recorrentes. 
• Padrões não são classes e nem componentes, mas ajudam na construção 
desses, orientando a melhor forma de agrupamento dos elementos, baseado 
em experiências anteriores. 
• Existem padrões para soluções de análise e de projeto. 
• É uma forma de transferência de conhecimento: os mais experientes criam os 
padrões, e os mais novos fazem uso. 
 
Biblioteca de classes 
• Corresponde a uma coleção de classes que possuem uma determinada 
finalidade. 
• É uma forma de reuso mais concreta por meio da qual classes já prontas 
podem ser usadas. 
• Exemplo: os ambientes das plataformas JAVA e .NET disponibilizam 
bibliotecas de classes reutilizáveis. 
 
Componentes 
• São uma unidade de software que pode ser usada na construção de 
diferentes sistemas. 
• Compreendem um conjunto de objetos que colaboram para oferecer serviços, 
mas também podem requisitar serviços. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 18 
 Existe uma área de pesquisa denominada “desenvolvimento baseado em 
componentes” (component based developer – CBD). A ideia é a construção de 
componentesque possam ser usados em diversos contextos, em diversos 
sistemas. Assim, o desenvolvimento fica, com o tempo, cada vez mais baseado 
no reuso de componentes existentes. 
• Os componentes ficam armazenados em repositórios de componentes. 
• Componentes podem ser comercializados. 
 
Responsabilidades 
Uma das formas mais clássicas de pensar sobre projeto de objetos em um 
software diz respeito a responsabilidades, papéis e colaborações. 
 
A UML define responsabilidade: “um contrato ou obrigação de um classificador”. 
Responsabilidade tem relação com o que o objeto precisa fazer para exercer 
seu papel no contexto; e, basicamente, pode ser de dois tipos: fazer e 
conhecer: 
• Fazer algo em prol da colaboração, seja criando um objeto, calculando, 
controlando demais objetos etc. 
• Conhecer dados e objetos relacionados. 
 
As responsabilidades dos objetos são identificadas durante a fase ou disciplina 
de projeto de software. 
 
A ideia de colaboração está intimamente relacionada com o conceito de 
responsabilidade. Responsabilidades são implementadas por métodos que 
atuam por si só ou colaboram com métodos de objetos relacionados. Os 
diagramas de interação, por sua vez, são extremamente úteis para atribuir 
responsabilidades às classes. 
 
Veja o diagrama de sequência elaborado na seção anterior. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 19 
 
 
Observe que: 
• A classe PedidoE é responsável por criar Itens Pedido (responsabilidade de 
fazer). 
• A classe PedidoUE é responsável por conhecer o seu total (responsabilidade 
de conhecer). Sobre essa responsabilidade, para conhecer o seu total, a classe 
faz uso do método Obter TotalPed (), mas não o faz isso sozinha. Ela precisa 
de colaboração da classe Itens Pedido através do método Obter Sub Total 
Ped (), pois quem conhece o total de cada linha de item do pedido é a própria 
classe Itens Pedido. 
 
Padrões GRASP 
Existem padrões de projetos que ajudam na atribuição de responsabilidades, 
fundamentando o raciocínio que deve ser aplicado para tal. Padrões GRASP 
(general responsibility and assignment software patterns – padrões gerais de 
atribuição de responsabilidade em projeto) definem nove princípios, nove 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 20 
padrões, que representam conhecimento explícito que pode ser aplicado em 
projetos. 
 
Dentre os nove padrões GRASP, falaremos dos cinco principais (exemplificando 
a aplicação dos dois mais populares).: 
 
Padrão CREATOR (criador) 
 
 
Nome: CREATOR. 
Problema: quem CRIA o objeto X? 
Solução (conselho): atribuir à classe B a responsabilidade de criar um 
objeto da classe A, se uma das afirmativas abaixo for verdade. 
- B contém A ou B agrega A de forma composta (composição). 
- B registra A. 
- B usa A. 
- B contém os dados iniciais de A. 
 
Vamos observar a aplicação desse padrão no pequeno estudo de casos que 
fizemos na seção anterior. Veja que a classe PedidoE cria objetos de Itens 
Pedido, conforme método <<Create>>; Criar ItemPed (Num Pedido). 
 
Observe que no diagrama de classes isso se reflete no relacionamento de 
composição entre PedidoE e Itens Pedido. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 21 
 
 
Padrão INFORMATION EXPERT (especialista na informação) 
Um dos mais elementares padrões é o especialista na informação. 
• Nome: INFORMATION EXPERT. 
• Problema: qual o princípio básico para atribuir responsabilidades a objetos? 
• Solução (sugestão): atribua a responsabilidade à classe que tenha 
informação necessária para satisfazê-la. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 22 
Possui uma responsabilidade precisa de informação sobre: outros objetos, o 
estado do próprio objeto, informação que o objeto pode derivar etc. 
 
A aplicação desse padrão pode ser vista no estudo de caso da seção anterior, 
conforme trecho do diagrama de sequência apresentado: quem seria 
responsável por obter o total de um pedido. Quem conhece o total de um 
pedido é a própria classe Pedido, logo o método Obter Total Ped() deve ficar 
na classe PedidoE, ou seja, ela é a especialista na informação. Para conhecer 
o total do pedido é preciso saber o total de cada linha de pedido, o que no 
modelo analisado é feito pelo método Obter Sub Total Ped(), da classe 
Itens Pedido. 
 
LOW COUPLING, CONTROLLER e HIGH COHESION 
Padrão LOW COUPLING (acoplamento baixo) 
Nome: acoplamento baixo. 
Problema: como apoiar dependência baixa, baixo impacto de modificação e 
aumento de reuso? 
Solução: atribuir responsabilidade de modo que o acoplamento permaneça 
baixo. Use esse princípio para avaliar alternativas. 
Acoplamento é uma medida que avalia o quão forte um elemento está 
conectado, tem conhecimento ou depende de outros elementos. Uma classe 
com acoplamento baixo (fraco) não é dependente de muitos elementos, o que 
é positivo. 
 
Padrão CONTROLLER (controlador) 
Nome: controlador. 
Problema: qual é o primeiro objeto, além da classe boundary (interface com 
usuário), que recebe e controla uma operação do sistema? 
Operação do sistema: principais eventos de entrada do sistema. 
Solução: atribui a responsabilidade a uma classe, conforme estas opções: 
• Controladora do sistema ou subsistema como um todo. 
• Controladora do caso de uso dentro do qual ocorreu um evento. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 23 
Um controlador é o primeiro objeto, além da interface do usuário, responsável 
por receber ou tratar uma mensagem de operação do sistema. 
 
Padrão HIGH COHESION (coesão alta) 
Nome: coesão alta. 
Problema: como manter os objetos inteligíveis e gerenciáveis? 
Solução: atribuir responsabilidade de forma que a coesão permaneça alta. 
Classes com coesão baixa, em geral, assumem responsabilidades que são de 
outros objetos, fazem muitas coisas e não estão relacionadas. 
 
Referências 
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3. ed. 
Elsevier, 2015. 
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e projeto 
orientados a objetos e ao desenvolvimento iterativo. 3. ed. Bookman, 2007. 
 
Exercícios de fixação 
Questão 1 
No que se refere às atividades de projeto orientado a objetos, assinale a única 
alternativa errada. 
a) Análise dos requisitos e modelo conceitual de classes. 
b) Modelagem das interações e identificação de responsabilidades das 
classes. 
c) Projeto de arquitetura do software. 
d) Projeto de persistência dos dados. 
e) Projeto de interface gráfica do usuário. 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 24 
Questão 2 
Leia as afirmativas a seguir referentes às atividades inerentes ao projeto de 
objetos. 
I. O diagrama conceitual de classes já traz as classes completas nas quais 
teremos a definição dos atributos. 
II. Refinamento das classes, com inserção de classes de software (de projeto). 
III. Inserção de métodos nas classes, com atribuições de responsabilidades. 
Com base em sua análise, assinale a única alternativa correta. 
a) Estão corretas apenas II e III 
b) Está correta apenas I 
c) Estão corretas I, II e III 
d) Estão corretas apenas I e II 
e) Estão corretas apenas I e III 
 
Questão 3 
Sobre os relacionamentos entre classe, assinale a única alternativa falsa. 
a) A navegabilidade indica a direção em que um objeto pode enviar 
mensagens a outro objeto. 
b) No diagrama conceitual de classes, em geral, representa-se o 
relacionamento entre classes usando a associação. 
c) Na fase ou disciplina de projeto, devemos analisar possíveis mecanismos 
de herançaentre as classes. 
d) Na fase ou disciplina de projeto, ainda não devemos representar 
relacionamento de composição entre as classes, o que somente será 
representado na implementação do código. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 25 
e) Novos métodos são descobertos ao modelarmos os diagramas de 
interação. 
 
Questão 4 
Sobre o diagrama de sequência, analise as assertivas a seguir. 
I. O diagrama de sequência mostra como os objetos colaboram para a 
realização de um cenário de uso (parte de um caso de uso). 
II. Toda mensagem que chega a um objeto no diagrama de sequência 
representa uma operação da classe, ou seja, um método na classe que recebe 
a mensagem. 
III. Novos métodos descobertos na elaboração do diagrama de sequência 
demandam atualização frequente do diagrama de classes. 
Com base em sua análise, assinale a alternativa correta. 
 
a) Está correta apenas I 
b) Estão corretas I, II e III 
c) Estão corretas apenas I e II 
d) Estão corretas apenas II e III 
e) Estão corretas apenas I e III 
 
Questão 5 
Analise as duas assertivas a seguir e a relação entre elas. 
I. No modelo de classes de projeto podemos incluir novos atributos nas classes. 
... porque... 
II. No modelo conceitual de classes não representamos atributos. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 26 
Com base em sua análise, assinale a resposta correta quanto à assertividade de 
cada uma e sobre a relação entre elas. 
a) As duas assertivas estão corretas, e a segunda justifica a <primeira 
class=""></primeira> 
b) As duas assertivas estão corretas, e a segunda não justifica a primeira. 
c) As duas assertivas estão erradas. 
d) A assertiva I está correta, e a assertiva II está errada. 
e) A assertiva I está errada, e a assertiva II está correta. 
 
Questão 6 
Assinale a alternativa incorreta quanto às formas de reutilização. 
a) Padrões de projeto representam reuso de soluções recorrentes. 
b) Biblioteca de classes representa soluções em nível de implementação. 
c) Componentes representam reaproveitamento de código. 
d) O desenvolvimento baseado em componentes consiste na construção de 
componentes que possam ser usados em diversos contextos, em 
diversos sistema. 
e) Padrão de projeto consiste num reuso imediato e pode ser comprado de 
empresas desenvolvedoras. 
 
Questão 7 
No que se refere à análise de classes, relacionamentos e atributos para constar 
no diagrama de classes, analise estas assertivas: 
I. O padrão especialista da informação diz que a responsabilidade deve ser 
atribuída à classe que conhece a informação. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 27 
II. O padrão create ajuda a descobrir os objetos que criam outros e indica 
relacionamento de composição. 
III. O padrão acoplamento alto visa atribuir responsabilidade de forma que o 
acoplamento permaneça elevado. 
a) Estão corretas apenas II e III 
b) Estão corretas apenas I, II e III 
c) Estão corretas I, II , III e IV 
d) Está correta apenas III 
e) Estão corretas apenas I e II 
 
Questão 8 
Assinale a única alternativa incorreta no que se refere ao padrão create. 
a) Atribuir à classe B a responsabilidade de criar um objeto da classe A, se 
B agrega A de forma composta. 
b) Atribuir à classe B a responsabilidade de criar um objeto da classe A, se 
B registra A. 
c) Atribuir à classe B a responsabilidade de criar um objeto da classe A, se 
B usa A. 
d) Atribuir à classe B a responsabilidade de criar um objeto da classe A, se 
B contém dados iniciais de A. 
e) Atribuir à classe B a responsabilidade de criar um objeto da classe A, se 
A usa B. 
 
Questão 9 
Qual o problema resolvido pelo padrão controlador? 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 28 
a) Qual é o primeiro objeto, além da classe boundary (interface com 
usuário), que recebe e controla uma operação do sistema? 
b) Como apoiar dependência baixa, baixo impacto de modificação e 
aumento de reuso? 
c) Qual o princípio básico para atribuir responsabilidades a objetos? 
d) Quem cria o objeto X? 
e) Como manter os objetos inteligíveis e gerenciáveis? 
 
Questão 10 
Analise as duas assertivas a seguir e a relação entre elas. 
I. Padrões de projeto são uma forma de explicitar o conhecimento. 
... porque... 
II. Formaliza soluções de análise ou projeto já encontradas por profissionais 
mais experientes. 
a) As duas assertivas estão corretas, e a segunda justifica a primeira. 
b) As duas assertivas estão corretas, e a segunda não justifica a primeira. 
c) As duas assertivas estão erradas. 
d) A assertiva I está correta, e a assertiva II está errada. 
e) A assertiva I está errada, e a assertiva II está correta. 
 
Questão 1 - A 
Justificativa: Análise dos requisitos e modelagem conceitual de classes são 
atividades da fase ou disciplina de projetos. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 29 
Questão 2 - A 
Justificativa: O diagrama conceitual de classes, em geral, apresenta apenas os 
nomes dos atributos; e, na fase ou disciplinas de projeto, acrescentamos 
visibilidade e tipo de dados a fim de refiná-lo. 
 
Questão 3 - D 
Justificativa: Na fase ou disciplinas de análise, em geral, os relacionamentos 
são representados por associações. Já no modelo de classes de projeto ou 
classes de software, pode-se representar, se útil for, todos os tipos de 
relacionamento entre classes. 
 
Questão 4 - B 
Justificativa: I – verdade; II – verdade; e III – verdade. 
 
Questão 5 - D 
Justificativa: O modelo RUP modela os casos de uso na disciplina de análise e 
os realiza nas disciplinas de projeto e implementação – e, por esse motivo, está 
baseado em casos de uso. 
 
Questão 6 - E 
Justificativa: Padrões não são concretos e não são comercializados, tal como 
componentes e classes prontas. 
 
Questão 7 - E 
Justificativa: O padrão chama-se acoplamento baixo e visa garantir que as 
classes tenham baixo acoplamento. 
 
Questão 8 - E 
Justificativa: A responsabilidade deve ser atribuída a B, se B usa A – e não o 
contrário, como diz o enunciado. 
 
Questão 9 - A 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 30 
Justificativa: I – falso, porque devemos, por simplificação, representar apenas 
as associações. 
II – os atributos derivados podem ser representados, mas não há 
obrigatoriedade nisso. 
III – verdadeiro, pois mostra as classes do domínio do problema. 
IV – verdade, pois são classes de software. 
 
Questão 10 - A 
Justificativa: As duas assertivas são verdadeiras, e o conhecimento contido nos 
padrões de projeto, detectados por profissionais mais experientes, torna-se 
explícito para que novatos possam usá-lo.