Análise e Projeto Orientado a Objetos

Prévia do material em texto

ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
Aula 01: Analise e Projeto Orientado a Objetos ........................................................................... 2 
Introdução ............................................................................................................................. 2 
Conteúdo ................................................................................................................................ 3 
Modelagem orientada a objetos e processo RUP ....................................................... 3 
Tipos de ênfase .................................................................................................................. 4 
Atividades de análise ......................................................................................................... 4 
UML: diferentes perspectivas .......................................................................................... 5 
Processos iterativos e incrementais ............................................................................... 6 
RUP (Rational Unified Process) ........................................................................................ 8 
Arquitetura do sistema ................................................................................................... 13 
Decomposição do sistema ............................................................................................ 14 
Arquitetura em camadas ................................................................................................ 15 
Arquitetura MVC (model, view and controller) ........................................................... 17 
MVC: camadas .................................................................................................................. 18 
MVC: funcionamento do padrão .................................................................................. 19 
MVC: vantagens e desvantagens .................................................................................. 20 
Quadro comparativo ....................................................................................................... 20 
Aprenda Mais ....................................................................................................................... 22 
Referências........................................................................................................................... 22 
Exercícios de fixação ......................................................................................................... 22 
Chaves de resposta ..................................................................................................................... 28 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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: 
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 
visando ao uso de determinadas tecnologias, e demonstram como o sistema 
deve fazer. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
 
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. 
 
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. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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). 
 
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 deimplantação. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
 
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 
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. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
 
 
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. 
 
 
 
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. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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. 
 
 
 
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 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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; 
• 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. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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 
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; 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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: 
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); 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
4. São feitos testes para aferir se os componentes do software 
satisfazem os casos de uso selecionados para a iteração. 
 
 
 
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. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
 
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; 
• 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 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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. 
 
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. 
 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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 
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 
 
 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
 
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 bastante conhecido 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 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
requerida na forma de apresentação das informações também poderá afetar a 
lógica do negócio. 
 
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 
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 
 
 
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 
• 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. 
 
 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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/ 
 
 
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. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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. 
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. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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. 
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... 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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 
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. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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 
 
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. 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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 (interfacese 
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 
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. 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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. 
 
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. 
 
 
 
 ANÁLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL 
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. 
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.