Apostila Analise orientada a objetos e projeto arquitetural

Prévia do material em texto

ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 1 
Apresentação ................................................................................................................................ 4 
Aula 01: Analise e Projeto Orientado a Objetos ........................................................................... 6 
Introdução ............................................................................................................................. 6 
Conteúdo ................................................................................................................................ 7 
Modelagem orientada a objetos e processo RUP ....................................................... 7 
Tipos de ênfase .................................................................................................................. 8 
Atividades de análise ......................................................................................................... 8 
UML: diferentes perspectivas .......................................................................................... 9 
Processos iterativos e incrementais ............................................................................. 10 
RUP (Rational Unified Process) ...................................................................................... 12 
Arquitetura do sistema ................................................................................................... 16 
Decomposição do sistema ............................................................................................ 18 
Arquitetura em camadas ................................................................................................ 18 
Arquitetura MVC (model, view and controller) ........................................................... 20 
MVC: camadas .................................................................................................................. 21 
MVC: funcionamento do padrão .................................................................................. 22 
MVC: vantagens e desvantagens .................................................................................. 23 
Quadro comparativo ....................................................................................................... 23 
Aprenda Mais ....................................................................................................................... 24 
Referências........................................................................................................................... 25 
Exercícios de fixação ......................................................................................................... 25 
Chaves de resposta ..................................................................................................................... 30 
 
Aula 02: Projeto da Arquitetura Lógica e Modelo MVC .............................................................. 32 
Introdução ........................................................................................................................... 32 
Conteúdo .............................................................................................................................. 33 
Arquitetura lógica ............................................................................................................ 33 
A organização das partes de um sistema ................................................................... 34 
Acoplamento e coesão ................................................................................................... 34 
Arquitetura lógica com UML: pacotes ......................................................................... 35 
UML: diagrama de pacotes ............................................................................................ 36 
Diagrama conceitual de classes .................................................................................... 39 
Classes conceituais.......................................................................................................... 40 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 2 
Derivando Classes Conceituais dos Casos de uso .................................................... 44 
Classes Conceituais Candidatas ................................................................................... 45 
Como encontrar as associações relevantes ............................................................... 46 
Que atributos especificar? .............................................................................................. 48 
Referências........................................................................................................................... 51 
Exercícios de fixação ......................................................................................................... 51 
Chaves de resposta ..................................................................................................................... 56 
 
Aula 05: Projeto de Software Orientado a Objeto ...................................................................... 58 
Introdução ........................................................................................................................... 58 
Conteúdo .............................................................................................................................. 59 
Projeto do software ......................................................................................................... 59 
Detalhamento dos aspectos dinâmicos ...................................................................... 60 
Refinamento dos aspectos estáticos e estruturais .................................................... 60 
Projeto da arquitetura ..................................................................................................... 61 
Persistência de objetos ................................................................................................... 61 
Projeto de interface gráfica com usuário.................................................................... 62 
Projeto de algoritmos ..................................................................................................... 62 
Padrões de Projeto .......................................................................................................... 62 
Interações .......................................................................................................................... 62 
Modelagem de classes de projeto ................................................................................ 64 
Passando da análise ao projeto: classes...................................................................... 65 
Classes: detalhes do projeto .......................................................................................... 66 
Derivação do diagrama de classes de projeto ........................................................... 68 
Modelos de interação na construção do modelo conceitual de classes .............. 69 
Reutilização: padrões, bibliotecas e componentes ................................................... 72 
Responsabilidades ........................................................................................................... 74 
Padrões GRASP ................................................................................................................. 75 
Padrão CREATOR (criador) ............................................................................................ 76 
Padrão INFORMATION EXPERT (especialista na informação) ................................ 77 
LOW COUPLING, CONTROLLER e HIGH COHESION .............................................. 78 
Referências...........................................................................................................................79 
Exercícios de fixação ......................................................................................................... 79 
Chaves de resposta ..................................................................................................................... 84 
 
Aula 06: Implementação e Arquitetura do Software .................................................................. 86 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 3 
Introdução ........................................................................................................................... 86 
Conteúdo .............................................................................................................................. 87 
Diagramas de componentes ......................................................................................... 87 
Componentes ................................................................................................................... 88 
Interfaces ........................................................................................................................... 89 
Componentes e interfaces ............................................................................................. 90 
Diagrama de implantação .............................................................................................. 93 
Nó ....................................................................................................................................... 94 
Caminhos de comunicação (conexões) ...................................................................... 95 
Exemplos de diagrama de implantação ...................................................................... 95 
Referências........................................................................................................................... 97 
Exercícios de fixação ......................................................................................................... 98 
Chaves de resposta ................................................................................................................... 103 
Conteudista ............................................................................................................................... 105 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 4 
O desenvolvimento de sistemas requer um conjunto de atividades, dispostas 
em fases, sendo essas relacionadas e estruturadas de acordo com a 
metodologia que usamos no processo de desenvolvimento. Ou seja, será a 
metodologia que dirá a forma como a equipe de desenvolvimento trabalhará, a 
ordem de execução das fases e consequentemente das atividades. 
 
Independente do processo e metodologia de desenvolvimento usadas, as fases 
de Análise de sistemas e de Projeto de Sistemas sempre estarão presentes, as 
vezes com nomes parecidos, não exatamente esses, mas estarão presentes. A 
fase de análise compreende o entendimento de uma realidade e para tal 
usamos modelos que representem o negócio. Na fase de projeto, pensamos em 
como melhor atender ao negócio estudado, com base nas tecnologias 
existentes. 
 
Com o desenvolvimento de sistemas sob a ótica da orientação a objetos, não é 
diferente e as fases de Análise e Projeto tem o mesmo significado acima 
descritos e tem e usam, em geral, a linguagem de modelagem UML (Unified 
Modelling Languagem), com seus diagramas em suas diferentes perspectivas, 
atendendo a diversas fases das metodologias de desenvolvimento, de forma 
independente. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 5 
Os diagramas UML desenvolvidos na fase de Análise são revistos e refinados na 
fase de projeto, com incremento de elementos que representem as tecnologias 
específicas a serem usadas. 
 
Na fase de projeto, definimos, dentre outros aspectos, a arquitetura do 
software, ou seja quais são seus subsistemas e partes e como essas se 
relacionam entre si, para prover a melhor solução para aquele negócio. Dentro 
da definição da arquitetura precisamos entender e definir as integração das 
partes de forma a garantir a reusabilidade, onde nos valemos de padrões 
arquiteturais, de desenvolvimento em camadas, de padrões de projeto e 
princípios para reutilização de código. 
 
Sendo assim, essa disciplina tem como objetivos: 
1. Proporcionar conhecimento dos conceitos de análise e projeto orientado a 
objetos. 
 
2. Mostrar o conceito de arquitetura lógica do software através do diagrama de 
pacotes da UML. 
 
3. Aplicar os conceitos de camadas em projetos de software, bem como do 
modelo MCV (model, view and controller). 
 
4. Apresentar os conceitos fundamentais para a definição da arquitetura do 
software, o que inclui: princípios de coesão e acoplamento, padrões de projeto, 
desenvolvimento em camadas, padrões de controle da arquitetura. 
 
5. Entender como é possível o refinamento de diagramas da UML, 
especialmente o diagrama de classes. 
 
6. Entender a utilidade da modelagem dos diagramas de sequencia e estados 
para definição da arquitetura de software a ser usada e refinamento do 
diagrama de classes. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 6 
7. Apresentar dois novos diagramas da UML: diagrama de componentes e de 
implantação, ajudando na definição da arquitetura do software e infra estrutura 
necessárias. 
 
Introdução 
Nesta aula, serão apresentados conceitos relevantes para dar embasamento às 
atividades de análise e projeto orientado a objetos. 
 
O desenvolvimento orientado a objetos demanda que, nas atividades de 
análise, tenhamos a preocupação com o que o sistema fará, enquanto nas 
atividades de análise o foco será em como fazer. 
 
A UML (Unified Modeling Language), como ferramenta de modelagem para 
software orientado a objetos, disponibiliza diagramas a serem empregados em 
todas as atividades necessárias ao processo de desenvolvimento usado nas 
empresas, independentemente de modelo e tecnologia. 
 
Para isso, disponibilizam-se diagramas sob três diferentes perspectivas, cada 
qual com sua finalidade. 
 
O desenvolvimento orientado a objetos se adequa bem a modelos iterativos 
incrementais, que, em contrapartida, considerados os modelos em cascata, não 
objetivam definir todos os requisitos no início do projeto. 
Dentre esses modelos iterativos e incrementais, destaca-se o modelo RUP 
(Rational Unified Process), inicialmente criado pela empresa Rational e, depois, 
comprado pela IBM. 
 
Objetivo: 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 7 
1. Fundamentar as principais características e os pilares do paradigma 
orientado a objetos, discutindo os principais conceitos inerentes aos processos 
de desenvolvimento de sistemas; 
 
2. Caracterizar o processo de desenvolvimento iterativo e incremental 
apresentando o processo de desenvolvimento que usaremos em nossas aulas. 
Conteúdo 
Modelagem orientada a objetos e processo RUP 
Análise e projeto orientados a objeto 
 
As atividades de análise de um sistema têm por objetivo entender o domínio do 
problema enfatizando a sua investigação e as necessidades dos usuários do 
sistema, que, por sua vez, demandarão os requisitos do sistema, ou seja, aquilo 
que o sistema precisa fazer para atender a essas necessidades. 
 
A análise visa definir o que o sistema deve fazer. Durante a análise, a ênfase 
está em encontrar e descrever as entidades do domínio do problema que sejam 
relevantes ao sistema que se pretende construir. 
 
Atividades de projeto enfatizam uma solução conceitual que satisfaça os 
requisitos e não a implementação em si. As atividades de projeto são realizadas 
visandoao uso de determinadas tecnologias, e demonstram como o sistema 
deve fazer. 
 
 
Atenção 
 Na  análise,  nos  preocupamos  em  “fazer a coisa certa”,   já  no  
projeto   focamos   em   “faça certo a coisa”.   A   análise   omite  
aspectos de como fazer e proporciona um panorama geral da 
funcionalidade do sistema. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 8 
Tipos de ênfase 
A análise orientada a objetos foca em encontrar ou descrever os objetos do 
domínio do problema. 
 
Já o projeto orientado a objetos prioriza a definição dos objetos do software e 
a forma como eles colaboram para atender aos requisitos definidos pela 
análise. 
 
Em última instância, durante a implementação ou programação, os objetos do 
projeto são implementados, ou seja, desenvolvidos em uma linguagem de 
programação orientada a objetos. 
 
Atividades de análise 
As atividades de análise denotam a solução conceitual dada ao problema, 
mas sem considerar aspectos da implementação, tais como a linguagem a ser 
utilizada e o sistema gerenciador de banco de dados. Preocupa-se 
principalmente com os casos de uso e as classes do domínio do problema e 
seus relacionamentos. 
 
A separação entre análise e projeto é tênue, já que esse é resultado de 
sucessivos refinamentos do modelo conceitual de análise. 
 
Nas atividades de análise, geralmente, além dos casos de uso, desenvolvemos 
o modelo de classes conceitual, o qual contém apenas as classes de negócio 
(ou entidade) e os relacionamentos entre elas. 
Nesse tipo de atividade, o diagrama de classes será refinado com a inserção de 
novos elementos (classes, métodos, atributos, multiplicidade, visibilidade e 
outros). 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 9 
UML: diferentes perspectivas 
A UML disponibiliza um conjunto de diagramas sob diferentes 
perspectivas, destacando-se: 
 
•  Perspectiva  conceitual:  os  diagramas  descrevem  uma  situação  do  mundo  real, 
do domínio do problema; 
•  Perspectiva  de  especificação:  os  diagramas  (usando  as  mesmas  notações  da  
perspectivas) descrevem componentes do software, sem relação com alguma 
implementação (linguagem de programação) específica; 
•   Perspectiva   de   implementação: os diagramas descrevem como implementar 
em uma linguagem específica. 
 
É interessante destacarmos que, dentro do contexto da UML, temos: 
 
•  Diagramas  específicos  da  perspectiva  conceitual,  como  diagramas  de  casos  de  
uso e diagramas de pacotes; 
•  Diagramas específicos da perspectiva de especificação, como diagramas de 
componentes; 
•  Diagramas  específicos  da  perspectiva  de  implementação,  como  diagramas  de  
implantação. 
 
 
Atenção 
 É importante ressaltar que diagramas podem ser modelados 
inicialmente sob uma perspectiva e, posteriormente, refinados e 
modelados sob outras perspectivas, como, por exemplo, o 
diagrama de classes. Na fase de análise, o diagrama conceitual 
de classes pode ser derivado do diagrama de casos de uso, 
retratando as classes de negócio (também chamadas de classes 
de entidade). 
 
Na fase de projeto, o mesmo diagrama de classes pode ser 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 10 
refinado com a inserção dos relacionamentos entre as classes, 
de novos métodos, de novos atributos, de parâmetros nas 
chamadas dos métodos, da visibilidade dos atributos e métodos, 
e ainda a inserção de novas classes, chamadas classes de 
projeto. Novas classes também podem ser inseridas no diagrama 
de classes de projeto. E, na fase de implementação, o mesmo 
diagrama de classes pode receber classes específicas de 
implementação na respectiva linguagem de programação. 
 
Processos iterativos e incrementais 
Nos Processos iterativos, o ciclo de vida do sistema é dividido em uma série 
de mini projetos, curtos, preferenciamente de duracão fixa (por exemplo 3 
meses), denominados iterações. Cada iteração contém um subconjunto das 
funcionalidades do sistema. Em cada iteração temos as atividades de 
Levantamento de Requisitos, Análise de Requisitos, projeto, implementação, 
testes e implantação, conforme ilustrado pela imagem a seguir. 
 
 
 
O ciclo de vida iterativo é baseado em incrementos sucessivos do sistema, pelas 
iterações do processo. A cada iteração, um pedaço do software é 
incrementado, daí o nome processo iterativo e incremental. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 11 
 
 
A grande questão dos processos iterativos é que neles não se pensam e nem se 
implementam todos os requisitos de uma vez. Cada iteração vai tratar um 
subconjunto dos requisitos. Esse é um conceito-chave em processos que 
implementam ciclo de vida iterativo incremental, tais como PU (Processo 
Unificado, com destaque para o RUP, da Rational, hoje IBM), o XP (Extreme 
Programming), o SCRUM, dentre outros. Programação e testes têm início 
enquanto a análise de requisitos ainda está em curso, de forma bem distinta 
dos processos que implementam ciclo de vida em cascata. 
 
O modelo é chamado incremental porque os requisitos são grandes e 
complexos ou, ainda, aqueles que se relacionam intrinsecamente com outros 
vão sendo tratados e complementados ao longo de várias iterações. Em 
contrapartida, os requisitos mais simples podem ser finalizados numa iteração 
apenas. 
 
Com isso a crença é que, em projetos iterativos incrementais, no início, haja 
uma maior concentração em requisitos e análise, em comparação as atividades 
de projeto, implementação e testes. A medida em que a modelagem já estiver 
avançada e o conhecimento do domínio do problema conhecido e dominado e 
comum que seja menor o tempo gasto com requisitos e análise, conforme 
ilustrado pela imagem a seguir. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 12 
 
 
RUP (Rational Unified Process) 
O RUP (Rational Unified Process) é um processo de desenvolvimento de 
software que visa ao desenvolvimento orientado a objeto e que é baseado na 
UML (Unified Modeling Language). Hoje, pertence à IBM, que adquiriu a 
empresa Rational. 
 
O RUP é considerado um processo unificado, na medida em que agrega um 
conjunto de técnicas, métodos e procedimentos para garantir o 
desenvolvimento de software com qualidade, controlando os recursos ao longo 
do projeto. 
 
O RUP é um processo genérico, complexo, que deve ser adaptado à realidade 
de cada empresa que deseja usá-lo como processo de desenvolvimento de 
software. Dentre suas principais características, destacam-se: 
 
•  É  iterativo  e  incremental;; 
•  Centrado  e  guiado  por  casos  de  usos  da  UML;; 
•  Baseado  na  arquitetura do software a ser desenvolvido; 
•  Destina-se a sistemas que são implementados sob o paradigma da orientação 
a objetos; 
•  O  RUP  é  dividido  em  4  fases;; 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 13 
•  As  fases  são  segmentadas  em  iterações;; 
•  E  as  atividades  são  realizadas  pelo  auxilio  de  disciplinas. 
 
 
 
A imagem exibida ilustra a divisão do RUP em fases, iterações e disciplinas. A 
seguir você conhecerá outras características específicas do Rational Unified 
Process. 
Detalhes do processo RUP 
O RUP é guiado ou orientado por casos de uso da UML: 
1. Os requisitos são modelados sob a forma de casos de uso; 
2. Durante análise, projeto e implementação, os casos de uso são 
modelados e realizados; 
3. Durante os testes, é aferido se o sistema realiza o que está 
definido nos casos de uso; 
4. Os casos de uso são usados para planejamento e 
acompanhamento de cada iteração. 
 
O RUPé centrado na arquitetura do software, pois: 
1. A arquitetura é definida logo nas primeiras iterações, servindo 
para organizar o desenvolvimento (por exemplo: alocacão de 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 14 
recursos humanos, materiais e referentes ao tempo) e, sobretudo, 
para oportunizar o reaproveitamento de código; 
2. A arquitetura descreve como os casos de uso serão realizados. 
 
As 4 fases do RUP são: 
 
1. Concepção: 
a. Estabelece o escopo e a viabilidade (econômica, 
operacional, tecnológica e de cronograma) do projeto 
decidindo sobre a continuidade ou não do processo de 
desenvolvimento; 
b. Define os casos de uso mais crítico, com base em análise 
de riscos; 
c. Define quantas iterações serão necessárias. 
 
2. Elaboração: 
a. Compreende as atividades de levantamento e análise de 
requisitos, além do projeto da arquitetura do software; 
b. Especificação e detalhamento dos casos de uso; 
c. Projeto da arquitetura do software; 
d. Planejamento da fase de construção. 
 
3. Construção: 
a. Desenvolvimento e testes, dentro do conceito de iterações, 
a fim de contemplar todos os requisitos necessários, 
quando, após homologação, são considerados prontos; 
b. Priorização do reuso; 
c. Ao final da fase, o sistema deve estar apto para a transição 
ao usuário. 
 
4. Transição: 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 15 
a. Treinamento dos usuários (opcional, conforme contrato de 
trabalho) e implantação no ambiente do usuário. 
 
Abaixo, os marcos base em cada fase do RUP: 
 
 
 
A cada iteração do RUP, poderemos observar: 
1. São identificados e especificados os casos de uso mais relevantes 
(mediante análise de riscos), e são selecionados os casos de uso 
de maior risco; 
2. São realizadas atividades de análise e projeto, tomando-se por 
base a arquitetura da aplicação; 
3. São implementados os casos de uso que realizam os requisitos, 
dentro da arquitetura proposta (projetada); 
4. São feitos testes para aferir se os componentes do software 
satisfazem os casos de uso selecionados para a iteração. 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 16 
O RUP traz, ainda, o conceito de disciplina que agrupa atividades afins, 
logicamente relacionadas a uma área de interesse. As disciplinas se dividem em 
disciplinas de engenharia e disciplinas de apoio ou suporte; aquelas de 
engenharia compreendem os fluxos de atividades relacionadas à engenharia do 
software: modelagem de negócio, requisitos, projeto, implemetação, testes e 
implantação. As disciplinas de apoio visam apoiar o desenvolvimento sob o 
ponto de vista do projeto e incluem: gestão e configuração de mudanças (nos 
requisitos, na arquitetura), e gerência de projeto e ambiente. 
 
Cada área de interesse ou disciplina tem, associada a ela, um ou mais 
“modelos”   que   se   integram,   conforme   ilustrado   na   imagem   a   seguir.   Nas  
disciplinas de modelagem de negócios, requisitos e análise/design são usados 
diagramas da UML, tais como: casos de uso, classes, sequência, comunicação, 
estados, atividades, componentes, dentre outros. 
 
 
Arquitetura do sistema 
O que é? 
 
Em linhas gerais, a arquitetura do sistema abrange as decisões sobre a 
organização do software, que incluem: 
 
•  Definição  da  estrutura  (elementos  estruturais)  e  interface  do  software; 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 17 
•   Especificação   do   comportamento   do   sistema,   que   demanda   colaborações  
entre os elementos estruturais; 
•  Definição  de  um  estilo  arquitetônico. 
 
O projeto arquitetônico do software compreende duas vertentes: 
 
Arquitetura lógica 
A arquitetura lógica corresponde à decomposição hierárquica do sistema em 
módulos lógicos ou subsistemas e à especificação da interface e dependência 
entre esses módulos. Com o uso da UML, a arquitetura lógica é definida através 
do diagrama de pacotes. 
 
Arquitetura física 
A arquitetura física corresponde à decomposição do sistema em módulos 
físicos, chamados componentes em UML, e à definição de interface e 
dependência entre os componentes (em UML, usamos o diagrama de 
componentes). Além disso, devemos definir também a topologia de hardware 
(equipamentos e conexões), onde os componentes de software serão 
executados (usamos, em UML, o diagrama de implantação). 
 
 
Atenção 
 Sejam elas lógicas ou físicas, as decisões a serem tomadas para 
definir uma arquitetura incluem: 
 
•  Decomposição do sistema em partes ou subsistemas; 
•  Escolha  de  uma  estrutura  de  comunicação  e  controle  entre  as  
partes dos subsistemas; 
•  Definição  entre  as  interfaces  entre  as  partes  dos  subsistemas;; 
•  Determinação  de  oportunidades  e  estratégias  para  reuso. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 18 
Decomposição do sistema 
A decomposição do sistema pode ser efetivada de duas formas, não 
excludentes: em camadas ou partições, conforme imagem a seguir. 
 
 
 
Arquitetura em camadas 
Frequentemente, o desenvolvimento em camadas tem sido usado na tentativa 
de separar código, facilitar a manutenção e fomentar o reuso. Inicialmente, não 
existia essa ideia; o sistema era monolítico e misturava código de interface 
com a lógica e o acesso e armazenamento dos dados, ou seja, todas as 
funcionalidades eram misturadas em uma única camada. 
 
Depois, evoluímos para duas camadas, na medida em se desenvolviam em 
separado os códigos para acesso e armazenamento de dados – processo 
chamado de persistência. O objetivo dessa separação era manter o uso de 
diversos aplicativos acessando a mesma base de dados. Ainda assim, o código, 
que em sua maioria continha funcionalidades de interface com usuário e lógica 
do negócio, continuava confuso, de difícil entendimento e manutenção, pois 
permanecia em uma única camada. 
 
Na medida em que aplicativos da internet começaram a ser desenvolvidos, essa 
estrutura teve que evoluir para uma arquitetura de três camadas, pois era 
muito lento esperar que os componentes da camada de interface + lógica do 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 19 
negócio   “carregassem”  na  máquina  do  cliente.  A  arquitetura  de   três  camadas  
apresenta as camadas de: 
 
•  Apresentação – contempla a interface com o usuário e a apresentação das 
informações; 
•   Lógica do negócio, lógica da aplicação ou aplicação – contém as 
tarefas e regras pertinentes ao negócio; 
•  Persistência – contém funcionalidades de acesso a dados e sua persistência. 
 
Veja a seguir o desenvolvimento em 1, 2 e 3 camadas. 
 
As imagens abaixo ilustram, respectivamente, o desenvolvimento em 1 camada 
(código monolítico), 2 camadas (cenário de 2 camadas físicas) e 3 camadas 
(cenário de 3 camadas físicas). 
 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 20 
 
Atualmente, o desenvolvimento pode demandar uma arquitetura de N 
camadas, também chamada de sistema distribuído, com especializações de 
algumas camadas, por exemplo: 
 
 Podemos segmentar a camada de aplicação em mais de 1 
camada: separando aspectos inerentes ao domínio e aspectos de 
serviços; 
 Podemos dividir a camada de dados; 
 Podemos dividir a camada de lógica de negócio, separando uma 
camada de serviços para web (servidor web). 
 
Cabe ressaltar que sistemas pequenos não precisam ser desenvolvidos em 
camadas, embora possam; mas os controles necessários não compensam. 
 
Arquitetura MVC (model, view and controller) 
O MVC é um padrão de arquitetura de software bastanteconhecido e 
usado. Seu principal objetivo é separar o código da apresentação 
(interfaces e relatórios) da lógica do negócio (da aplicação). Tal junção 
deixa a aplicação vulnerável a mudanças, na medida em que uma mudança 
requerida na forma de apresentação das informações também poderá afetar a 
lógica do negócio. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 21 
 
A camada de apresentação equivale ao view, e a camada de lógica do negócio 
chama-se business model. O desenvolvimento, atualmente, demanda que a 
interface funcione em diversos dispositivos distintos: celulares, tablets, 
computadores, notebooks, dentre outros. 
Assim sendo, precisamos de diversas interfaces ou camadas de interfaces. Se 
em cada uma delas tivermos uma lógica de negócio diferente, estaremos 
duplicando código. 
 
Imagine um site de vendas na internet, o qual podemos acessar por intermédio 
de um PC, celular ou tablet; a lógica do negócio é sempre a mesma, o que 
varia é a forma de mostrar os dados na interface do usuário. 
 
MVC: camadas 
O modelo MCV (model, view and controller) possui as seguintes camadas: 
 
•  Modelo de negócio (model) – contém as regras do negócio e os dados 
necessários. Encapsula os dados e o comportamento, sem preocupação da 
forma como mostrá-los. É o coração da aplicação, sendo responsável por tudo 
que a aplicação vai fazer em termos de armazenamento, manipulação e 
geração dos dados. 
 
• Visão (view) – responsável pela interação com usuário e pela apresentação 
das visões dos dados do negócio, sem qualquer preocupação em como os 
dados foram obtidos. Controla e mapeia as ações. 
 
•  Controle (controller) – faz a intermediação entre as camadas de visão e 
modelo comandando o fluxo de obtenção, encaminhamento e apresentação dos 
dados. Por meio do controle define-se o comportamento da apresentação, 
interpretando-se ações do usuário e mapeando-se chamadas do modelo. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 22 
MVC: funcionamento do padrão 
O funcionamento do padrão MVC pode ocorrer de duas formas: 
 
•  O  controle  interpreta  os  comandos  de  entrada  de  dados  e  eventos  do  usuário;; 
•  O  controle  “chama”  as  ações  necessárias  do  modelo  de  negócios. 
•   As   alterações   no   modelo   derivadas   das   ações   do   modelo de negócios são 
enviadas à camada de visão, podendo ter o controle (parte b da imagem) como 
intermediário ou não (parte a da imagem). No caso do controle intermediar, ele 
seleciona a visão apropriada. 
 
 
 
Conforme ilustrado na figura a seguir, o padrão MVC é bastante usado em 
aplicações que rodam sob a internet: 
 
•  Um  serviço  é  “chamado”  a  partir  de  diferentes  clientes;; 
•  A  lógica  do  negócio  é  a  mesma;; 
•  Os  servidores  não  são  necessariamente  máquinas  virtuais. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 23 
 
 
MVC: vantagens e desvantagens 
Dentre as vantagens pelo uso e aplicação do modelo MVC, podemos 
citar: 
 
•  Possibilita  facilmente  a  inclusão  de  novos  clientes  através  da  criação  de  novo  
visualizador e seus respectivos controles; 
•   Ao   gerenciar   múltiplos   visualizadores   com   o  mesmo  modelo,   facilitam-se a 
inclusão de novas funcionalidades, os testes e a manutenção da aplicação; 
•  Viabiliza  o  desenvolvimento  em  paralelo,  pois  modelo,  visualizador  e  controle  
são independentes. 
 
Dentre as desvantagens do modelo: 
 
•   Demanda   mais   complexidade   e   maior   tempo   de análise e modelagem do 
sistema; 
•   Requer   mão   de   obra   especializada   com   conhecimento   no   modelo   e   sua  
implementação; 
•  Não  é  aconselhável  para  pequenas  aplicações. 
 
Quadro comparativo 
Tecendo um comparativo entre o modelo em camadas, especificamente o de 
três camadas e o modelo MVC, temos a expor que: 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 24 
•   O   MVC   está   associado   à   arquitetura   da   aplicação,   do   ponto   de   vista   da  
comunicação entre os componentes; 
•   A   arquitetura   em   camadas   está   relacionada   com   a   arquitetura   do   sistema,  
pela qual a responsabilidade se divide em camada de apresentação, negócio e 
acesso a dados; 
•  Os  dois  modelos  se  complementam  e  podem  coexistir, 
 conforme ilustra a imagem a seguir; 
•  O  modelo  MVC  também  pode  ser  aplicado  em  sistemas  desenvolvidos  sob  a  
arquitetura de 1 e 2 camadas; 
•  O  modelo  MVC  não  se  preocupa  com  aspectos  de  persistência  dos  dados. 
 
 
 
Aprenda Mais 
 
 
Material complementar 
 
Para saber mais sobre o assunto, acesse e leia os conteúdos dos sites 
indicados: 
 http://www-01.ibm.com/software/br/rational/ 
 
 http://www.ibm.com/developerworks/rational/library/content/03Ju
ly/1000/1251/1251_bestpractices_TP026B.pdf 
 
 http://www.uml.org/ 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 25 
Referências 
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com 
UML. 2. ed. Campus, 2006. [Capítulo 1.] 
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de 
Janeiro: Elsevier, 2005. [Capítulos 1 e 2.] 
FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de 
modelagem de objetos. 3. ed. Porto Alegre: Artmed, 2005. 
 
Exercícios de fixação 
Questão 1 
No que se refere às atividades de análise e projeto orientado a objetos, assinale 
a única alternativa errada. 
a) A fase de análise visa determinar como as coisas serão implementadas. 
b) A fase de projeto enfatiza os objetos de software e a forma como eles 
serão interligados. 
c) A fase de análise foca no desenvolvimento do modelo de negócios e, 
para tal, usa o modelo de casos de uso da UML. 
d) Na análise, preocupamo-nos   em   “fazer   a   coisa   certa”,   e,   no   projeto,  
focamos  em  “fazer  certo  a  coisa”. 
e) Na fase de análise, desenvolvemos o diagrama conceitual de classes com 
as classes do negócio. Na fase de projeto, refinamos esse modelo de 
classes com a inclusão de novos elementos. 
 
Questão 2 
No que se refere às perspectivas dos diagramas UML, analise as alternativas a 
seguir. 
I. Os diagramas específicos da perspectiva conceitual são diagramas de casos 
de uso e diagramas de pacotes. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 26 
II. Os diagramas específicos da perspectiva de especificação são, por exemplo, 
diagramas de componentes. 
III. Diagramas específicos da perspectiva de implementação, como diagramas 
de sequência. 
Com base em sua análise, assinale a única alternativa correta: 
a) Estão corretas apenas I e II 
b) Está correta apenas I 
c) Estão corretas I, II e III 
d) Estão corretas apenas II e III 
e) Estão corretas apenas I e III 
 
Questão 3 
Sobre o RUP (Rational Unified Process), assinale a única alternativa errada. 
a) É iterativo e incremental. 
b) Centrado e guiado por casos de usos da UML. 
c) Baseado na arquitetura do software a ser desenvolvido. 
d) Destina-se a sistemas implementados sob qualquer paradigma: 
estruturado e orientado a objetos. 
e) O RUP é dividido em quatro fases: concepção, elaboração, construção e 
transição. 
 
Questão 4 
Sobre a estrutura do modelo RUP, analise as assertivas. 
I. Cada fase e segmentado em iterações. 
II. Cada fase pode ter, no máximo, duas iterações. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 27 
III. A cada iteração podemos demandar duas ou três disciplinas, sejam de 
engenharia ou de apoio. 
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. O modelo RUP é baseado em casos de uso. 
... porque... 
II. Durante análise, projeto e implementação, os casos de uso são modelados e 
realizados. 
Com base em seu entendimento, 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. 
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 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 28 
Em linhas gerais, a arquitetura abrange as decisões sobre a organização do 
software. Assinale a única alternativa que não está incluída dentre essas 
decisões. 
a) Definição da estrutura (elementos estruturais) do software. 
b) Especificação do comportamento do sistema. 
c) Definição de um estilo arquitetônico. 
d) Definição da interface do software. 
e) Definição do que o sistema deve fazer. 
 
Questão 7 
O projeto de arquitetura do software compreende a arquitetura física e lógica. 
Com base nesse conceito, analise as assertivas a seguir. 
I. A arquitetura lógica corresponde à decomposição hierárquica do sistema em 
módulos lógicos ou subsistemas. 
II. A arquitetura lógica é definida através do diagrama de pacotes. 
III. A arquitetura física corresponde à decomposição do sistema em módulos 
físicos. 
IV. A arquitetura física é definida pelo diagrama de componentes e de 
implantação da UML. 
Com base em sua análise, assinale a única alternativa correta. 
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ão corretas apenas I e IV 
e) Estão corretas apenas I e II 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 29 
Questão 8 
No que se refere ao modelo de arquitetura de software em camadas, assinale a 
única alternativa errada. 
a) As principais motivações para a divisão em camadas são: separar código 
(negócio, da interface), facilitar a manutenção e fomentar o reuso. 
b) Três é o número máximo de camadas possíveis. 
c) O modelo em três camadas surgiu com o advento da internet, pois era 
demorado esperar que os componentes da camada de interface e lógica 
do negócio fossem carregados na máquina do cliente. 
d) A arquitetura de três camadas contempla as camadas de apresentação, 
lógica do negócio e persistência. 
e) Sistemas pequenos não precisam ser desenvolvidos em camadas. 
 
Questão 9 
Sobre o modelo MVC (model, view and controller), analise as assertivas a 
seguir. 
I. Seu principal objetivo é separar o código da apresentação (interfaces e 
relatórios) da lógica do negócio (da aplicação). 
II. A principal motivação é o desenvolvimento, hoje, demandar interfaces para 
diferentes dispositivos – mas a lógica da aplicação é a mesma. 
III. O modelo MVC não se preocupa com persistência. 
IV. O modelo MVC é idêntico ao modelo em três camadas. 
Com base em sua análise, assinale a única alternativa correta. 
a) Estão corretas apenas I, II e III 
b) Estão corretas I, II, III e IV 
c) Estão corretas apenas I, II e IV 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 30 
d) Estão corretas apenas I e II 
e) Estão corretas apenas III e IV 
 
Questão 10 
Analise as duas assertivas a seguir e a relação entre elas. 
O modelo MVC não é aconselhável a pequenas aplicações. 
... porque... 
II. Demanda mais complexidade e maior tempo de análise e modelagem do 
sistema. 
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. 
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: Na fase de análise, deve-se definir o que fazer. O como fazer é 
definido na fase de projeto do processo de desenvolvimento do software. 
 
Questão 2 - A 
Justificativa: O diagrama de sequência não representa a perspectiva de 
implementação, e sim o diagrama de implantação. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 31 
 
Questão 3 - D 
Justificativa: O modelo RUP destina-se exclusivamente ao desenvolvimento de 
sistemas sob o paradigma orientado a objetos. 
 
Questão 4 - A 
Justificativa: Cada fase pode ter N iterações, dependendo do tamanho do 
projeto. A cada iteração, pode-se demandar tantas disciplinas quantas forem 
necessárias à fase e à iteração. 
 
Questão 5 - E 
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: A definição do que o sistema deve fazer é responsabilidade das 
atividades de requisitos e análise, não sendo uma decisão para definição da 
arquitetura. 
 
Questão 7 - C 
Justificativa: Todas as assertivas definem corretamente o que se faz e que 
diagramas da UML são usados. 
 
Questão 8 - B 
Justificativa: Em tese, não há limites para o número máximo de camadas. Há 
modelos hoje usando mais de três camadas. 
 
Questão 9 - A 
Justificativa: O modelo em camadas e o modelo MVC não são a mesma coisa. O 
modelo MCV, por exemplo, não se preocupa com a persistência; já o modelo 
em três camadas sim. Logo, a divisão dos códigos nas camadas é diferenciado. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 32 
Além disso, o modelo MVC também pode ser aplicado em sistemas 
desenvolvidos sob a arquitetura de uma e duas camadas. 
 
Questão 10 - A 
Justificativa: Se a aplicação é pequena, não compensa o custo de análise e 
modelagem mais complexas, além da necessidade de mão de obra 
especializada. 
 
Introdução 
O desenvolvimento em camadas vem sendo usado fortemente pelos 
desenvolvedores de software, na tentativa de obter produtos mais coesos, 
menos acoplados, mais reutilizáveis e de manutenção menos problemática. 
 
A arquitetura lógica de um sistema a ser desenvolvido envolvem decisões 
estratégicas que envolve dentre outros aspectos: a escolha da modularização 
do sistema, da estrutura de comunicação e controle entre os subsistemas, a 
escolha da estratégia de persistência, oportunidades de reuso de software, bem 
como atendimento a requisitos de desempenho, custo, mobilidade, uso de 
padrões. 
 
A definição da arquitetura da aplicação, envolve o conhecimento de conceitos 
como coesão, acoplamento, princípios para reuso do software, bem como o de 
padrões de arquitetura de software, a exemplo do modelo MVC (Model, View 
and controller) e o desenvolvimento em camadas. 
 
Abordaremos ainda o diagrama de pacotes da UML que prevê o conceito de 
Pacote (package) para agrupar elementos e pode ser usado para evidencias os 
sistemas e suas dependências. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 33 
Abordaremos ainda o conceito de diagrama conceitual de classes e como 
deriva-lo com base no diagrama de casos de uso e das respectivas 
especificações textuais de cada caso de uso. 
 
Objetivo: 
1. Fundamentar as principais característicase os pilares do paradigma 
orientado a objeto; 
 
2. Discutir os principais conceitos inerentes aos processos de desenvolvimento 
de sistemas; 
 
3. Caracterizar o processo de desenvolvimento iterativo e incremental; 
 
4. Apresentar o processo de desenvolvimento que usaremos em nossas aulas. 
Conteúdo 
Arquitetura lógica 
Conforme estudamos na aula 1, a arquitetura lógica corresponde à 
decomposição hierárquica do sistema em módulos lógicos ou subsistemas, bem 
como a especificação da interface e dependência entre esses módulos. Com o 
uso da UML, a arquitetura lógica é definida através do diagrama de pacotes 
como parte do modelo de projetos. Então, vamos definir o conceito de 
arquitetura lógica: 
 
Arquitetura lógica é a organização, em geral, de casos de uso, classes e/ou 
componentes em pacotes, subsistemas e camadas. É lógica, pois, nesse 
momento, não há, ainda, comprometimento de como esses elementos serão 
implantados. Estudamos também na aula 1 o desenvolvimento em camadas, 
cuja finalidade é organizar a aplicação visando a uma divisão de código 
eficiente que favorece a manutenção e o reuso do software. Uma arquitetura 
lógica não precisa ser organizada em camadas, mas isso torna-se muito 
comum. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 34 
A organização das partes de um sistema 
Quando falamos em arquitetura de um sistema, falamos de sua organização em 
partes, das relações de dependências entre as partes e da forma como 
dividimos os elementos do sistema entre as partes. Quando falamos de partes, 
referimo-nos a subsistemas, módulos, pacotes, classes, componentes, métodos 
de uma classe ou qualquer outra forma de organizar os elementos de um 
sistema. 
 
Existem dois conceitos relevantes que estão diretamente relacionados ao 
conceito de arquitetura de software: acoplamento e coesão. Veremos, a 
seguir, as características de cada um. 
 
Acoplamento e coesão 
O acoplamento diz respeito à dependência entre as partes, a forma como 
estão relacionadas ou acopladas. Partindo do próprio conceito de sistema, 
temos que sistema é um conjunto de partes independentes, cada qual 
realizando seu trabalho, que juntas colaboram para um objetivo maior, em 
comum. Ou seja, as partes devem ser independentes ou pouco dependentes. 
 
O acoplamento mede o grau de interdependência entre as partes. Dessa forma, 
os sistemas devem ser organizados para ter baixo acoplamento ou baixa 
dependência. 
 
O alto acoplamento entre as partes pode gerar: 
•  Dificuldade de alteração no sistema, uma vez que existe dependência 
entre as partes. A alteração em uma parte pode demandar reflexos em outras 
partes que dela dependem. 
•  Dificuldade de reutilização, uma vez que depende da presença de outras 
partes. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 35 
Já o princípio da coesão diz respeito ao grau de dependências entre os 
elementos internos das partes do sistema. Podemos dizer que a coesão mede, 
por exemplo, o grau de afinidade entre as funcionalidades de cada parte do 
sistema. As funcionalidades de uma parte devem levar ao desenvolvimento de 
apenas uma tarefa, e, nesse caso, devemos perseguir a alta coesão, ou seja, 
que a afinidade entre as funcionalidades seja alta. 
 
Uma parte com baixa coesão faz muitas coisas não relacionadas, tendendo aos 
seguintes problemas: 
 
 Dificuldade de entendimento das partes e, consequentemente, do 
sistema; 
 Dificuldade de reutilização, na medida em que a parte não faz uma 
tarefa única; 
 Dificuldade de manutenção. 
 
Arquitetura lógica com UML: pacotes 
O diagrama de pacotes pode ser utilizado, por exemplo, para segmentar um 
sistema em camadas. Cada camada poderia ser representada por um pacote. 
Fazendo uma relação com o modelo de três camadas, poderíamos ter as 
camadas de IU (interface com usuário), domínio (lógica da aplicação ou lógica 
do negócio) e BD (acesso e persistência a dados), sendo representadas cada 
uma por um pacote. 
 
Segundo a UML, a divisão em pacotes é livre, podendo ser usado o critério 
desejado. Um critério muito empregado é a divisão de um sistema grande em 
pacotes funcionais, ou seja, divisão em diferentes pacotes das funcionalidades 
dos subsistemas. 
 
Um diagrama de pacotes fornece mecanismos de agrupar qualquer elemento 
UML: classes, casos de uso, componentes, nós, outros pacotes etc. A hierarquia 
de pacotes também é possível. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 36 
UML: diagrama de pacotes 
A  UML  define  o  diagrama  de  pacotes  como  sendo  aquele  que  “disponibiliza  um  
conjunto  de  elementos  agrupados”.  Esses  elementos  podem  ser  casos  de  uso,  
classes, diagramas e até outros pacotes. O agrupamento de classes é o mais 
comum. Vejamos a representação de pacote na UML, onde sua identificação se 
dá  pelo  seu  nome,  no  caso,  “Pacote”. 
 
O diagrama de pacotes mostra os pacotes e as dependências entre eles. 
Os relacionamentos de dependência não são transitórios e resumem as 
dependências entre os conteúdos dos pacotes. A dependência evidencia o 
acoplamento entre os pacotes. 
 
 
 
A imagem a seguir mostra um diagrama de pacotes contendo os pacotes 
“Pacote  3”  e  “Pacote  4”  e  o  relacionamento  de  dependência (seta pontilhada). 
Uma modificação no elemento independente poderá afetar o elemento 
dependente. Uma dependência é representada como mostrado abaixo, uma 
seta   tracejada   apontando   para   o   item   independente,   ou   seja,   o   “Pacote   3”  
depende  de  “Pacote  4”. 
 
 
 
A seguinte imagem apresenta a estrutura de pacotes representando o modelo 
MVC   com   os   pacotes   de   nome:   “Interface”   representando   View;;   “Controle”  
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 37 
representando Control;;   e   “Modelo”   representando   o   modelo   da   lógica   do  
negócio. 
 
 
 
Esta imagem da sequência mostra a divisão em pacotes sob o enfoque do 
desenvolvimento em camadas evidenciando a dependência do pacote de 
“Apresentação”   em   relação   ao   pacote   “Lógica   do   negócio”   e   a   dependência  
deste  em  relação  ao  pacote  “Base  de  dados”. 
 
Conforme ilustrado na imagem abaixo, o sistema de uma loja é dividido em três 
pacotes:  “Gerenciar  compras”,  “Gerenciar  vendas”  e  “Gerenciar  financeiro”: 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 38 
 
 
Conforme  ilustrado  na  figura  abaixo,  o  pacote  de  nome  “Gerenciar  financeiro”,  
um dos pacotes do sistema de loja (da imagem apresentada) contém os 
pacotes  de  nome  “Pagamentos”,  “Recebimentos”  e  “Fluxo  de  caixa”. 
 
 
 
Em diagrama de pacotes, um pacote pode conter outros pacotes, ou seja, 
pode-se representar uma hierarquia de pacotes. 
 
 
Atenção 
 Cabe ressaltar que o diagrama de pacotes pode ser usado em 
qualquer fase do processo de modelagem do sistema e tem por 
objetivo organizar os modelos. Muitos já iniciam modelando os 
casos de uso em pacotes; mas o uso mais comum é a divisão em 
pacotes, na fase de projeto, quando o diagrama conceitual de 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 39 
classes será refinado com vistas à definição do diagrama de 
classes de projeto. 
 
Os exemplos aqui apresentados visam esclarecer que não 
existem regras para o particionamento do sistema em pacotes, 
podendo ser usado o critério que melhor se adequar às 
necessidades do sistema e de suas especificidades. 
 
Diagrama conceitual de classes 
O diagrama conceitual de classes de negócio deriva dos casos de uso e contém 
as classesinerentes ao negócio, correspondendo ao modelo de domínio. A 
aplicação da UML para diagrama de classes a um modelo de domínio produz 
um modelo de perspectiva conceitual que resulta na identificação de um 
conjunto de classes conceituais, fundamentais na análise orientada a objetos. 
Para criar um modelo de domínio, identifique as classes conceituais, desenhe-as 
como classes em diagrama de classes, em seguida acrescente atributos, 
associações e multiplicidades. 
 
•  As  classes  de  negócio  e  domínio  do  problema. 
 
•  Relações  entre  essas  classes.  É  oportuno representar associações e, na fase 
de elaboração do diagrama de classes de projeto, analisar melhor e identificar o 
melhor relacionamento para cada classe. 
 
•  Atributos  das  classes  conceituais. 
 
•   Em   geral,   as   operações   (assinatura   do   método)   não   são   definidas, mas é 
oportuno relacionar métodos (sem assinaturas completas: lista de parâmetros) 
derivados de casos de uso. 
 
•  Multiplicidade. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 40 
 
Classes conceituais 
Craig Larman, em seu livro Utilizando UM e Padrões, discute três formas de 
descobrir as classes conceituais inerentes a um modelo de domínio. 
 
1. Reusar o modificar modelos existentes; 
 
2. Usar uma lista de categorias de classes conceituais; 
 
3. Identificar substantivos ou frases nominais. 
 
Caso queiram aprofundar-se nas demais técnicas, recomendo a leitura do livro. 
Aqui abordaremos a terceira, que pressupõe a elaboração do diagrama e 
descrições dos casos de uso previamente. 
 
Como identificar classes analisando substantivos ou frases nominais nas 
especificações de casos de uso, especialmente, pelo modelo completo de 
especificação de caso de uso? 
 
Consideremos   uma   iteração   do   processo   RUP   e   o   caso   de   uso   “Vender  
produtos”  referente  à  venda  em  uma  loja,  conforme  diagrama  e  especificações  
a seguir. 
 
 
A seguir você verá a especificação textual do caso de uso Vender Produtos. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 41 
 
Casos de usos 
Ator(es): caixa, cliente. 
Pré-condição: produtos devidamente cadastrados. 
 
CASO DE USO: VENDER PRODUTOS 
 
Cenário principal 
1. Caixa inicia uma nova venda. 
2. Caixa informa identificação do cliente. 
3. Sistema localiza cliente. 
4. Para cada item da venda são feitos tais passos: 
4.1. Caixa informa identificador do item de venda. 
4.2. Sistema localiza item de venda em produtos. 
4.3. Sistema mostra nome do produto, valor unitário obtido de produtos. 
4.4. Sistema calcula e mostra total parcial da venda. 
5. Sistema calcula e exibe o total da venda e os impostos. 
6. Caixa informa forma de pagamento. 
7. Conforme forma de pagamento: 
DIN: Extends pagar dinheiro. 
CHQ: Extends pagar cheque. 
CAR: Extends pagar cartão. 
8. Sistema registra dados da venda. 
9. Sistema imprime o recibo da venda. 
 
Cenários alternativos 
3.1. a) Cliente não cadastrado: 
 1. Extends cadastrar cliente. 
 2. Sistema retorna ao passo 2 do cenário principal. 
 
4.2. a) Item de venda não localizado: 
 1. Sistema informa  “O  item  de  venda  não  está  cadastrado”. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 42 
 2. Sistema retorna ao passo 4.1. do cenário principal. 
 
CASO DE USO: CADASTRAR CLIENTE 
 
Cenário principal 
1. Caixa informa dados do cliente*. 
2. Sistema insere dados do cliente. 
*CPF, nome, endereço (rua, número, complemento, bairro, cidade, UF), 
telefone celular, telefone residencial. 
 
CASO DE USO: PAGAR DINHEIRO 
 
Cenário principal 
1. Caixa informa a quantia de dinheiro entregue pelo 
cliente. 
2. Sistema apresenta o valor do troco. 
3. Caixa entrega o valor do troco ao cliente. 
4. Sistema registra o pagamento em dinheiro. 
 
CASO DE USO: PAGAR CHEQUE 
 
Cenário principal 
1. Caixa informa os dados do cheque (banco, agência, conta e 
número do cheque). 
2. Sistema registra o pagamento em cheque. 
 
CASO DE USO: PAGAR CARTÃO 
 
Cenário principal 
1. Caixa informa os dados do cartão (administradora, 
número de cartão, validade de cartão e dígitos de 
segurança). 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 43 
2. Sistema valida compra com administradora de cartão. 
3. Sistema registra o pagamento com cartão. 
 
Cenários alternativos 
 2. a) Administradora não autoriza: 
 1.  Sistema  informa  “Compra  não  autorizada  pela  Adm  do  cartão”. 
 2. Sistema retorna ao passo 1 do cenário principal. 
 
Os substantivos ou frases nominais que estão em negrito são candidatos a: 
classes conceituais ou atributos dessas classes. Uma desvantagem dessa 
abordagem é a imprecisão da linguagem natural, na medida em que diferentes 
frases nominais podem representar a mesma classe conceitual ou atributo em 
função da ambiguidade. Por isso, é importante combinar com a técnica da lista 
de categoria das classes. 
 
Antes de definirmos as classes conceituais, observaremos a lista de categorias 
de classes conceituais abaixo, que é uma lista modificada com base na lista 
apresentada por Craig Larman. 
 
Categoria de classe conceitual Exemplos 
Transações de negócios: 
 São fundamentais. 
 Inicie com esse grupo de 
classes. 
Venda, pagamento, reserva, locação 
etc. 
Transações de linhas de item: 
 As transações, em geral, vêm 
descritas com linhas de item. 
 Prossiga identificando esse 
grupo de classes. 
Itens de venda. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 44 
Produtos ou serviços relacionados com 
uma transação ou com uma linha de 
item da transação: 
 Esses devem ser identificados 
na sequência das transações de 
linhas de item. 
Produto. 
Onde a transação é registrada? Registradora, livro diário. 
Papéis de pessoas ou organizações 
relacionadas à transação (atores, nos 
casos de uso): 
 Geralmente, precisamos saber 
as partes envolvidas na 
transação. 
Caixa, cliente, loja, vendedor, 
atendente. 
Local da transação, local do serviço. Loja, aeroporto. 
Outros sistemas colaboradores. Sistema de autorização de crédito. 
Instrumentos financeiros. 
Dinheiro, cheque, cartão, linha de 
crédito. 
Registro de finanças, trabalho, 
contrato. 
Recibo, livro diário, livro-caixa. 
 
Derivando Classes Conceituais dos Casos de uso 
Analisando  a  especificação  do  casos  de  uso  “Vender  produtos”,  temos: 
 
Os substantivos ou frases nominais que estão em negrito são candidatos a: 
classes conceituais ou atributos dessas classes. Uma desvantagem dessa 
abordagem é a imprecisão da linguagem natural, na medida em que diferentes 
frases nominais podem representar a mesma classe conceitual ou atributo em 
função da ambiguidade. Por isso, é importante combinar com a técnica da lista 
de categoria das classes. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 45 
Classes Conceituais Candidatas 
Pode-se identificar classes analisando frases nominais e substantivos da 
descrição dos casos de uso e da lista de categorias de classes. Veja abaixo as 
suas definições: 
 
Caixa: devemos saber a qualquer momento qual caixa registrou determinada 
venda. 
Venda: é o cerne do sistema, o qual contém os dados da venda. 
 
Cliente: representa o cliente da loja, quem fez a compra. 
 
Item de venda: está diretamente relacionado à venda e conterá cada item 
vendido. 
 
Produtos: é uma classe descritiva, que conterá os dados (nome e valor 
unitário do produto) relativos aos itens vendidos.Pagamento: armazena os dados de pagamento, que podem ser de três 
formas. Para cada forma, teremos dados distintos a serem considerados 
(conforme os respectivos casos de uso de extends): 
•  Pagamento Dinheiro: valor dado para pagamento e troco; 
•  Pagamento Cheque: dados do cheque (banco, agência, conta e número do 
cheque); 
•  Pagamento Cartão: dados do cartão (administradora, número do cartão, 
validade do cartão e dígitos de segurança). 
 
Recibo de venda: contém os dados da venda e do pagamento. Em geral, 
relatórios não devem ser considerados no modelo de domínio, pois as 
informações nele contidas são derivadas de outras classes. Porém, devemos 
considerar também a relevância do relatório dentro da regra de negócio. 
Recibos de venda, em geral, têm o papel de dar direito de troca ao comprador, 
o que seria uma razão para mostrar o recibo de venda como uma classe do 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 46 
modelo de domínio – nesse caso, a devolução de itens não é tratada (seja pelo 
sistema como um todo ou apenas por essa iteração). 
 
Como encontrar as associações relevantes 
 
Associações entre classes. Existem vários tipos de relacionamentos entre 
classes, mas as associações podem servir em qualquer situação. Os demais 
relacionamentos mostrarão melhor a semântica da relação entre classes, 
favorecendo a vida do programador. Mas nesse momento esse detalhe não é 
relevante, devendo ser deixado para o modelo de projeto de classes. A ideia 
aqui é relacionar as classes relevantes para a implementação dos requisitos. 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 47 
Além das associações, identificaremos também: 
•  Nome das associações: geralmente, devemos usar o formato <Classe> + 
verbo + <Classe>, segundo o qual o verbo cria o sentido lógico. Exemplo: o 
caixa registra a venda; o cliente realiza a venda; e assim por diante. No caso da 
forma de pagamento, ela pode acontecer em uma das três modalidades 
expressas  nos  casos  de  uso.  Nesse  caso,  usamos  a  expressão   “pode  ser”,  de  
forma a expressar que o pagamento pode ser em dinheiro ou em cartão ou, 
ainda, em cheque. 
 
Multiplicidade indica quantas instâncias de cada classe estão envolvidas em 
cada associação. A análise da multiplicidade deve ser realizada a cada par de 
classes participante da associação. Exemplo: 
 
 
1) O caixa pode registrar nenhuma (0) ou várias (*) vendas. Em contrapartida, 
a venda só pode ser registrada por um caixa. 
2) Uma venda pode conter um ou vários (*) itens de venda. Em contrapartida, 
um item de venda refere-se a apenas uma venda. 
3) Um item de venda refere-se a um produto apenas. E um produto (instância 
única) pode representar um item de venda. 
4) Uma venda tem um pagamento. E o pagamento refere-se a apenas uma 
venda. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 48 
5) A venda pode ser realizada por apenas um cliente. E o cliente pode realizar 
nenhuma (0) ou várias vendas (*). 
6) O pagamento pode ser (1) ou não (0) em dinheiro, da mesma forma que o 
pagamento pode ser (1) ou não (0) em cartão. E o pagamento também pode 
ser (1) ou não (0) em cheque. 
 
Que atributos especificar? 
O que exatamente são os atributos? 
 
Atributos: dados relacionados às classes candidatas que podemos observar 
das especificações dos casos de uso (vide elementos em negrito nas 
especificações). 
 
•  Identificação do cliente; 
•  Identificação do item de venda; 
•  Nome do produto; 
•  Valor unitário; 
•  Total parcial da venda; 
•  Total da venda; 
•  Impostos; 
•  Forma de pagamento; 
•  Dados do pagamento em dinheiro; 
•  Dados do pagamento em cheque; 
•  Data do pagamento em cartão. 
 
Devemos considerar os atributos que representem algo significante para as 
classes, dados relevantes que precisam ser armazenados. Opcionalmente 
podemos representar nesse momento: 
 
 Visibilidade: (-) para atributos privados; 
 Tipos de dado: nesse momento, apenas se consideram os que são do 
tipo simples (inteiro, lógica, double, data, hora, string). 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 49 
 
Atenção: modelo de classe não é modelo de dados; assim sendo, não existem, 
em classes, os conceitos de chave primária e chave estrangeira, que migra a 
chave primária para a tabela que contém a cardinalidade N. 
 
Em classes, apenas seus próprios atributos devem existir; Chave (primária ou 
estrangeira) é um conceito de banco de dados relacional e não se aplica a 
classes. 
 
 
 
Algumas considerações relevantes devem ser feitas sobre o modelo conceitual 
de classes, no que concerne aos atributos: 
 
1. Caixa: precisamos identificar a caixa que registra a venda. 
 
2. Venda: embora o caso de uso não explicitasse a data, é usual que 
armazenemos a data da realização da venda, para efeitos contábeis. O valor da 
venda, em tese, seria um atributo derivado, ou seja, que pode ser obtido 
mediante cálculos. Porém, nesse momento, optamos por mantê-lo como 
atributo. O mesmo vale para impostos. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 50 
3. Item de venda: embora a especificação de caso de uso não possa ser 
informada, bem como quantidade de um mesmo item de venda, optamos por 
deixar esse atributo, pois semanticamente ele faz sentido. 
 
4. Produto: consideramos que terá uma identificação, além de dados como 
nome e valor unitário de venda. 
 
5. Pagamento: valor a pagar também trata-se de um atributo derivado, mas se 
decidiu em mantê-lo, pois, muitas vezes, descontos podem ser dados (embora 
não tenhamos considerado nesse momento o atributo de desconto na venda). 
 
6. Dinheiro: armazenar o histórico da transação para eventual conferência de 
caixa, futura. 
 
7. Cartão: por questões de sigilo e respeito à informação pessoal do cliente, 
não podemos armazenar os dígitos de segurança. 
 
 
Atenção 
 A última imagem do diagrama de classes seria uma versão final 
do Diagrama Conceitual de Classes, considerando o universo de 
casos de uso da iteração corrente de um suposto processo RUP 
aplicado a um sistema de gestão de uma loja. 
 
Um último comentário refere-se à corretude de um modelo 
conceitual de classes. Em tese, não existe modelo de domínio 
correto, na medida em que é um entendimento do problema sob 
a ótica de quem modelou. Deve, claro, representar a realidade e 
ser, antes de tudo, um modelo de comunicação entre usuários e 
desenvolvedores. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 51 
Referências 
LARMAN, C. Modelos de domínio. In: LARMAN, C. Utilizando UML e 
padrões: uma introdução à análise e ao 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 análise e projeto orientado a objetos, assinale 
a única alternativa errada. 
a) A fase de análise visa determinar como as coisas serão implementadas. 
b) A fase de projeto enfatiza os objetos de software e a forma como eles 
serão interligados. 
c) A fase de análise foca no desenvolvimento do modelo de negócios e, 
para tal, usa o modelo de casos de uso da UML. 
d) Na   análise,   preocupamos   em   “fazer   a   coisa   certa”,   e,   no   projeto,  
focamos  em  “faça  certo  a  coisa”. 
e) Na fase de análise, desenvolvemos o diagrama conceitual de classes com 
as classes do negócio. Na fase de projeto, refinamos esse modelo de 
classes com a inclusão de novos elementos. 
 
Questão 2 
No que se refere às perspectivas dos diagramas UML, analise as alternativas a 
seguir. 
I. Osdiagramas específicos da perspectiva conceitual são diagramas de casos 
de uso e diagramas de pacotes. 
II. Os diagramas específicos da perspectiva de especificação são, por exemplo, 
diagramas de componentes. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 52 
III. Exemplo de um diagrama específico da perspectiva de implementação: 
diagrama de sequência. 
Com base em sua análise, assinale a única alternativa correta. 
a) Estão corretas apenas I e II. 
b) Está correta apenas I. 
c) Estão corretas I, II e III. 
d) Estão corretas apenas II e III. 
e) Estão corretas apenas I e III. 
 
Questão 3 
Sobre o RUP (Rational Unified Process) assinale a única alternativa errada. 
a) É iterativo e incremental. 
b) Centrado e guiado por casos de usos da UML. 
c) Baseado na arquitetura do software a ser desenvolvido. 
d) Destina-se a sistemas implementados sob qualquer paradigma: 
estruturado e orientado a objetos. 
e) O RUP é dividido em quatro fases: concepção, elaboração, construção e 
transição. 
 
Questão 4 
Sobre a estrutura do modelo RUP analise estas assertivas: 
I. Cada fase é segmentada em iterações. 
II. Cada fase pode ter no máximo duas iterações. 
III. A cada iteração podemos demandar duas ou três disciplinas, sejam de 
engenharia ou de apoio. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 53 
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. O modelo RUP é baseado em casos de uso. 
... porque... 
II. Durante a análise, projeto e implementação, os casos de uso são modelados 
e realizados. 
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. 
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 no que se refere ao modelo conceitual de 
classes. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 54 
a) Apresenta as classes envolvidas no domínio do negócio. 
b) Apresenta os atributos mais relevantes ao caso de uso em questão. 
c) Apresenta as associações entre as classes. 
d) Apresenta as multiplicidades das associações entre as classes. 
e) Apresenta os métodos das classes. 
 
Questão 7 
No que se refere à análise de classes, aos relacionamentos e atributos para 
constar no diagrama de classes, analise as assertivas abaixo. 
I. Devemos considerar todos os tipos de relacionamentos possíveis no modelo 
conceitual de classes. 
II. Devemos considerar as classes de software no modelo conceitual de classes. 
III. Devemos considerar apenas atributos relevantes para o domínio do 
problema, tendo cuidado com atributos derivados. 
IV. Devemos representar atributos-chave, tal qual fazemos no modelo 
relacional de dados. 
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 correta. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 55 
a) Diagrama conceitual de classes deve considerar as especificações de 
casos de uso e o diagrama de casos de uso, além de uma lista de 
categoria de classes conceituais. 
b) Diagrama conceitual de classes representa métodos e sua visibilidade. 
c) Diagrama conceitual de classes deve representar as mesmas classes que 
o modelo de classes de projeto. 
d) Não devemos representar atributos no modelo de classes de domínio. 
e) Devemos desenhar diagrama conceitual de classes apenas para grandes 
projetos. 
 
Questão 9 
Analise se cada assertiva é verdadeira ou falsa: 
I. Devemos representar no modelo conceitual os relacionamentos de agregação 
e composição. 
II. Temos, necessariamente, que apresentar os atributos derivados no 
diagrama conceitual de classes. 
III. O diagrama conceitual de classes é um modelo de domínio. 
IV. Classes de persistência não devem ser consideradas em modelos conceitual 
de classes. 
Com base em sua análise, assinale a única alternativa correta, que mostra a 
sequência correta de V ou F. 
a) I-F; II-F; III-V; IV-V. 
b) I-F; II-F; III-V; IV-F. 
c) I-F; II-V; III-V; IV-V. 
d) I-V; II-F; III-V; IV-V. 
e) I-F; II-F; III-F; IV-V. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 56 
 
Questão 10 
Analise as duas assertivas a seguir e a relação entre elas. 
I. O modelo conceitual de classes é refinado a cada iteração, quando um 
conjunto de requisitos é considerado. 
... porque... 
II. O diagrama conceitual de classes não considera as classes de projeto. 
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: Na fase de análise, deve-se definir o que fazer. O como fazer é 
considerado na fase de projeto do processo de desenvolvimento do software. 
 
Questão 2 - A 
Justificativa: O diagrama de sequência não representa a perspectiva de 
implementação, e sim o diagrama de implantação. 
 
Questão 3 - D 
Justificativa: O modelo RUP destina-se exclusivamente ao desenvolvimento de 
sistemas sob o paradigma orientado a objetos. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 57 
Questão 4 - A 
Justificativa: Cada fase pode ter N iterações, dependendo do tamanho do 
projeto. A cada iteração, pode-se demandar tantas disciplinas quantas forem 
necessárias à fase e à iteração. 
 
Questão 5 - A 
Justificativa: O modelo RUP modela os casos de uso na disciplina de análise, 
realiza-os nas disciplinas de projeto e implementação e, por esse motivo, está 
baseado em casos de uso. 
 
Questão 6 - E 
Justificativa: O diagrama conceitual de classes não apresenta métodos, pois 
nesse modelo nenhuma operação é definida. 
 
Questão 7 - D 
Justificativa: I – falsa, pois devemos considerar apenas as associações; 
II – falsa, pois devemos considerar apenas as classes do domínio, chamadas 
classes de entidade que sejam relevantes para a representação do problema; 
III – correta; 
e IV – falsa, porque não existe o modelo de chave no modelo de classes (cada 
classe tem apenas os atributos que lhe pertencem efetivamente). 
 
Questão 8 - A 
Justificativa: A segunda afirmativa é falsa, pois o diagrama conceitual não 
mostra métodos; a terceira afirmativa é falsa, pois as classes de software não 
são apresentadas no modelo conceitual, sendo representadas no diagrama de 
classes de projeto; a quarta também é falsa, pois devemos representar 
atributos; e, por fim, o conceito de diagrama conceitual de classe independe do 
tamanho do projeto, e sim do processo usado no desenvolvimento do software. 
 
Questão 9 - B 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 58 
Justificativa: I – falsa, pois devemos, por simplificação, representar apenas as 
associações; 
II – os atributos derivados podem ser representados, mas não há 
obrigatoriedade; 
III – verdadeira, pois mostra as classes