Análise Orientada A Objetos

Apresentao ................................................................................................................................
4
Aula 01: Analise e Projeto Orientado a Objetos ........................................................................... 6
Introduo ............................................................................................................................. 6
Contedo................................................................................................................................ 7
Modelagem orientada a objetos e processo RUP ....................................................... 7
Tipos de nfase .................................................................................................................. 8
Atividades de anlise ......................................................................................................... 8
UML: diferentes perspectivas .......................................................................................... 9
Processos iterativos e incrementais ............................................................................. 10
RUP (Rational Unified Process) ...................................................................................... 12
Arquitetura do sistema ................................................................................................... 16
Decomposio do sistema ............................................................................................ 18
Arquitetura em camadas ................................................................................................ 18
Arquitetura MVC (model, view and controller) ........................................................... 20
MVC: camadas.................................................................................................................. 21
MVC: funcionamento do padro .................................................................................. 22
MVC: vantagens e desvantagens .................................................................................. 23
Quadro comparativo ....................................................................................................... 23
Aprenda Mais....................................................................................................................... 24
Referncias........................................................................................................................... 25
Exerccios de fixao ......................................................................................................... 25
Chaves de resposta ..................................................................................................................... 30
Aula 02: Projeto da Arquitetura Lgica e Modelo MVC .............................................................. 32

Introduo ........................................................................................................................... 32
Contedo.............................................................................................................................. 33
Arquitetura lgica ............................................................................................................ 33
A organizao das partes de um sistema ................................................................... 34
Acoplamento e coeso ................................................................................................... 34
Arquitetura lgica com UML: pacotes ......................................................................... 35
UML: diagrama de pacotes ............................................................................................ 36
Diagrama conceitual de classes .................................................................................... 39
Classes conceituais.......................................................................................................... 40
ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL
Derivando Classes Conceituais dos Casos de uso .................................................... 44

Classes Conceituais Candidatas ................................................................................... 45
Como encontrar as associaes relevantes ............................................................... 46
Que atributos especificar?.............................................................................................. 48
Referncias........................................................................................................................... 51
Aula 05: Projeto de Software Orientado a Objeto ...................................................................... 58

Introduo ........................................................................................................................... 58
Contedo.............................................................................................................................. 59
Projeto do software ......................................................................................................... 59
Detalhamento dos aspectos dinmicos ...................................................................... 60
Refinamento dos aspectos estticos e estruturais .................................................... 60
Projeto da arquitetura ..................................................................................................... 61
Persistncia de objetos ................................................................................................... 61
Projeto de interface grfica com usurio.................................................................... 62
Projeto de algoritmos ..................................................................................................... 62
Padres de Projeto .......................................................................................................... 62
Interaes.......................................................................................................................... 62
Modelagem de classes de projeto ................................................................................ 64
Passando da anlise ao projeto: classes...................................................................... 65
Classes: detalhes do projeto .......................................................................................... 66
Derivao do diagrama de classes de projeto ........................................................... 68
Modelos de interao na construo do modelo conceitual de classes .............. 69
Reutilizao: padres, bibliotecas e componentes ................................................... 72
Responsabilidades ........................................................................................................... 74
Padres GRASP ................................................................................................................. 75
Padro CREATOR (criador) ............................................................................................ 76
Padro INFORMATION EXPERT (especialista na informao) ................................ 77
LOW COUPLING, CONTROLLER e HIGH COHESION .............................................. 78

Referncias........................................................................................................................... 79
Aula 06: Implementao e Arquitetura do Software .................................................................. 86
Introduo ........................................................................................................................... 86
Contedo.............................................................................................................................. 87
Diagramas de componentes ......................................................................................... 87
Componentes ................................................................................................................... 88
Interfaces ........................................................................................................................... 89
Componentes e interfaces ............................................................................................. 90
Diagrama de implantao .............................................................................................. 93
N ....................................................................................................................................... 94
Caminhos de comunicao (conexes)...................................................................... 95
Exemplos de diagrama de implantao ...................................................................... 95
Referncias........................................................................................................................... 97
Chaves de resposta ................................................................................................................... 103
Conteudista ............................................................................................................................... 105
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 execuo das fases e consequentemente das atividades.
Independente do processo e metodologia de desenvolvimento usadas, as fases
de Anlise de sistemas e de Projeto de Sistemas sempre estaro presentes, as
vezes com nomes parecidos, no exatamente esses, mas estaro presentes. A
fase de anlise compreende o entendimento de uma realidade e para tal
usamos modelos que representem o negcio. Na fase de projeto, pensamos em
como melhor atender ao negcio estudado, com base nas tecnologias
existentes.
Com o desenvolvimento de sistemas sob a tica da orientao a objetos, no
diferente e as fases de Anlise 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.
Os diagramas UML desenvolvidos na fase de Anlise so revistos e refinados na

fase de projeto, com incremento de elementos que representem as tecnologias
especficas a serem usadas.
Na fase de projeto, definimos, dentre outros aspectos, a arquitetura do
software, ou seja quais so seus subsistemas e partes e como essas se

relacionam entre si, para prover a melhor soluo para aquele negcio. Dentro
da definio da arquitetura precisamos entender e definir as integrao das
partes de forma a garantir a reusabilidade, onde nos valemos de padres
arquiteturais, de desenvolvimento em camadas, de padres de projeto e
princpios para reutilizao de cdigo.
Sendo assim, essa disciplina tem como objetivos:
1. Proporcionar conhecimento dos conceitos de anlise e projeto orientado a
objetos.
2. Mostrar o conceito de arquitetura lgica do software atravs 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 definio da arquitetura do
software, o que inclui: princpios de coeso e acoplamento, padres de projeto,

desenvolvimento em camadas, padres de controle da arquitetura.
5. Entender como possvel o refinamento de diagramas da UML,
especialmente o diagrama de classes.
6. Entender a utilidade da modelagem dos diagramas de sequencia e estados
para definio da arquitetura de software a ser usada e refinamento do
diagrama de classes.
7. Apresentar dois novos diagramas da UML: diagrama de componentes e de

implantao, ajudando na definio da arquitetura do software e infra estrutura
necessrias.
Introduo
Nesta aula, sero apresentados conceitos relevantes para dar embasamento s
atividades de anlise e projeto orientado a objetos.
O desenvolvimento orientado a objetos demanda que, nas atividades de
anlise, tenhamos a preocupao com o que o sistema far, enquanto nas
atividades de anlise 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 necessrias ao processo de desenvolvimento usado nas
empresas, independentemente de modelo e tecnologia.
Para isso, disponibilizam-se diagramas sob trs 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, no
objetivam definir todos os requisitos no incio 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:
1. Fundamentar as principais caractersticas 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.
Contedo
Modelagem orientada a objetos e processo RUP
Anlise e projeto orientados a objeto
As atividades de anlise de um sistema tm por objetivo entender o domnio do
problema enfatizando a sua investigao e as necessidades dos usurios do
sistema, que, por sua vez, demandaro os requisitos do sistema, ou seja, aquilo
que o sistema precisa fazer para atender a essas necessidades.
A anlise visa definir o que o sistema deve fazer. Durante a anlise, a nfase
est em encontrar e descrever as entidades do domnio do problema que sejam
relevantes ao sistema que se pretende construir.
Atividades de projeto enfatizam uma soluo conceitual que satisfaa os
requisitos e no a implementao em si. As atividades de projeto so realizadas
visando ao uso de determinadas tecnologias, e demonstram como o sistema
deve fazer.
Ateno
Na anlise, nos preocupamos em fazer a coisa certa, j no
projeto focamos em faa certo a coisa. A anlise omite
aspectos de como fazer e proporciona um panorama geral da
funcionalidade do sistema.
Tipos de nfase
A anlise orientada a objetos foca em encontrar ou descrever os objetos do
domnio do problema.
J o projeto orientado a objetos prioriza a definio dos objetos do software e
a forma como eles colaboram para atender aos requisitos definidos pela
anlise.
Em ltima instncia, durante a implementao ou programao, os objetos do
projeto so implementados, ou seja, desenvolvidos em uma linguagem de
programao orientada a objetos.
Atividades de anlise
As atividades de anlise denotam a soluo conceitual dada ao problema,
mas sem considerar aspectos da implementao, tais como a linguagem a ser
utilizada
sistema
gerenciador
de
banco
de
dados.
Preocupa-se
principalmente com os casos de uso e as classes do domnio do problema e

seus relacionamentos.
A separao entre anlise e projeto tnue, j que esse resultado de
sucessivos refinamentos do modelo conceitual de anlise.
Nas atividades de anlise, geralmente, alm dos casos de uso, desenvolvemos
o modelo de classes conceitual, o qual contm apenas as classes de negcio
(ou entidade) e os relacionamentos entre elas.
Nesse tipo de atividade, o diagrama de classes ser refinado com a insero de
novos elementos (classes, mtodos, 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 situao do mundo real,
do domnio do problema;
Perspectiva de especificao: os diagramas (usando as mesmas notaes da
perspectivas) descrevem componentes do software, sem relao com alguma
implementao (linguagem de programao) especfica;
Perspectiva de implementao: os diagramas descrevem como implementar
em uma linguagem especfica.
interessante destacarmos que, dentro do contexto da UML, temos:
Diagramas especficos da perspectiva conceitual, como diagramas de casos de
uso e diagramas de pacotes;
Diagramas especficos da perspectiva de especificao, como diagramas de
componentes;
Diagramas especficos da perspectiva de implementao, como diagramas de
implantao.
Ateno
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 anlise, o diagrama conceitual
de classes pode ser derivado do diagrama de casos de uso,
retratando as classes de negcio (tambm chamadas de classes
de entidade).
Na fase de projeto, o mesmo diagrama de classes pode ser
refinado com a insero dos relacionamentos entre as classes,

de novos mtodos, de novos atributos, de parmetros nas
chamadas dos mtodos, da visibilidade dos atributos e mtodos,
e ainda a insero de novas classes, chamadas classes de
projeto. Novas classes tambm podem ser inseridas no diagrama
de classes de projeto. E, na fase de implementao, o mesmo
diagrama de classes pode receber classes especficas de
implementao na respectiva linguagem de programao.
Processos iterativos e incrementais

Nos Processos iterativos, o ciclo de vida do sistema dividido em uma srie
de mini projetos, curtos, preferenciamente de duraco fixa (por exemplo 3
meses), denominados iteraes. Cada iterao contm um subconjunto das
funcionalidades do sistema. Em cada iterao temos as atividades de
Levantamento de Requisitos, Anlise de Requisitos, projeto, implementao,
testes e implantao, conforme ilustrado pela imagem a seguir.
O ciclo de vida iterativo baseado em incrementos sucessivos do sistema, pelas

iteraes do processo. A cada iterao, um pedao do software
incrementado, da o nome processo iterativo e incremental.
10
A grande questo dos processos iterativos que neles no se pensam e nem se

implementam todos os requisitos de uma vez. Cada iterao 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. Programao e testes tm incio

enquanto a anlise 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 so grandes e
complexos ou, ainda, aqueles que se relacionam intrinsecamente com outros
vo sendo tratados e complementados ao longo de vrias iteraes. Em
contrapartida, os requisitos mais simples podem ser finalizados numa iterao
apenas.
Com isso a crena que, em projetos iterativos incrementais, no incio, haja
uma maior concentrao em requisitos e anlise, em comparao as atividades
de projeto, implementao e testes. A medida em que a modelagem j estiver
avanada e o conhecimento do domnio do problema conhecido e dominado e
comum que seja menor o tempo gasto com requisitos e anlise, conforme
ilustrado pela imagem a seguir.
11
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
tcnicas,
mtodos
procedimentos
para
garantir
desenvolvimento de software com qualidade, controlando os recursos ao longo

do projeto.
O RUP um processo genrico, complexo, que deve ser adaptado realidade
de cada empresa que deseja us-lo como processo de desenvolvimento de
software. Dentre suas principais caractersticas, 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 so implementados sob o paradigma da orientao
a objetos;
O RUP dividido em 4 fases;
12
As fases so segmentadas em iteraes;

E as atividades so realizadas pelo auxilio de disciplinas.
A imagem exibida ilustra a diviso do RUP em fases, iteraes e disciplinas. A

seguir voc conhecer outras caractersticas especficas do Rational Unified
Process.
Detalhes do processo RUP
O RUP guiado ou orientado por casos de uso da UML:
1. Os requisitos so modelados sob a forma de casos de uso;
2. Durante anlise, projeto e implementao, os casos de uso so
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
so
usados
para
planejamento
acompanhamento de cada iterao.

O RUP centrado na arquitetura do software, pois:
1. A arquitetura definida logo nas primeiras iteraes, servindo
para organizar o desenvolvimento (por exemplo: alocaco de
13
recursos humanos, materiais e referentes ao tempo) e, sobretudo,

para oportunizar o reaproveitamento de cdigo;
2. A arquitetura descreve como os casos de uso sero realizados.
As 4 fases do RUP so:
1. Concepo:
a. Estabelece
escopo
viabilidade
(econmica,
operacional, tecnolgica e de cronograma) do projeto

decidindo sobre a continuidade ou no do processo de
desenvolvimento;
b. Define os casos de uso mais crtico, com base em anlise
de riscos;
c. Define quantas iteraes sero necessrias.
2. Elaborao:
a. Compreende as atividades de levantamento e anlise de
requisitos, alm do projeto da arquitetura do software;
b. Especificao e detalhamento dos casos de uso;
c. Projeto da arquitetura do software;
d. Planejamento da fase de construo.
3. Construo:
a. Desenvolvimento e testes, dentro do conceito de iteraes,
a fim de contemplar todos os requisitos necessrios,
quando, aps homologao, so considerados prontos;
b. Priorizao do reuso;
c. Ao final da fase, o sistema deve estar apto para a transio
ao usurio.
4. Transio:
14
a. Treinamento dos usurios (opcional, conforme contrato de

trabalho) e implantao no ambiente do usurio.
Abaixo, os marcos base em cada fase do RUP:
A cada iterao do RUP, poderemos observar:

1. So identificados e especificados os casos de uso mais relevantes
(mediante anlise de riscos), e so selecionados os casos de uso
de maior risco;
2. So realizadas atividades de anlise e projeto, tomando-se por
base a arquitetura da aplicao;
3. So implementados os casos de uso que realizam os requisitos,
dentro da arquitetura proposta (projetada);
4. So feitos testes para aferir se os componentes do software
satisfazem os casos de uso selecionados para a iterao.
15
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 negcio, requisitos, projeto, implemetao, testes e

implantao. As disciplinas de apoio visam apoiar o desenvolvimento sob o
ponto de vista do projeto e incluem: gesto e configurao de mudanas (nos
requisitos, na arquitetura), e gerncia 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 negcios, requisitos e anlise/design so usados
diagramas da UML, tais como: casos de uso, classes, sequncia, comunicao,
estados, atividades, componentes, dentre outros.
Arquitetura do sistema
O que ?
Em linhas gerais, a arquitetura do sistema abrange as decises sobre a
organizao do software, que incluem:
Definio da estrutura (elementos estruturais) e interface do software;
16
Especificao do comportamento do sistema, que demanda colaboraes

entre os elementos estruturais;
Definio de um estilo arquitetnico.
O projeto arquitetnico do software compreende duas vertentes:
Arquitetura lgica
A arquitetura lgica corresponde decomposio hierrquica do sistema em
mdulos lgicos ou subsistemas e especificao da interface e dependncia
entre esses mdulos. Com o uso da UML, a arquitetura lgica definida atravs
do diagrama de pacotes.
Arquitetura fsica
A arquitetura fsica corresponde decomposio do sistema em mdulos
fsicos, chamados componentes em UML, e definio de interface e
dependncia entre os componentes (em UML, usamos o diagrama de
componentes). Alm disso, devemos definir tambm a topologia de hardware
(equipamentos e conexes), onde os componentes de software sero
executados (usamos, em UML, o diagrama de implantao).
Ateno
Sejam elas lgicas ou fsicas, as decises a serem tomadas para
definir uma arquitetura incluem:
Decomposio do sistema em partes ou subsistemas;
Escolha de uma estrutura de comunicao e controle entre as
partes dos subsistemas;
Definio entre as interfaces entre as partes dos subsistemas;
Determinao de oportunidades e estratgias para reuso.
17
Decomposio do sistema
A decomposio do sistema pode ser efetivada de duas formas, no
excludentes: em camadas ou parties, conforme imagem a seguir.
Arquitetura em camadas
Frequentemente, o desenvolvimento em camadas tem sido usado na tentativa
de separar cdigo, facilitar a manuteno e fomentar o reuso. Inicialmente, no
existia essa ideia; o sistema era monoltico e misturava cdigo de interface
com a lgica e o acesso e armazenamento dos dados, ou seja, todas as
funcionalidades eram misturadas em uma nica camada.
Depois, evolumos para duas camadas, na medida em se desenvolviam em
separado os cdigos para acesso e armazenamento de dados processo
chamado de persistncia. O objetivo dessa separao era manter o uso de
diversos aplicativos acessando a mesma base de dados. Ainda assim, o cdigo,
que em sua maioria continha funcionalidades de interface com usurio e lgica
do negcio, continuava confuso, de difcil entendimento e manuteno, pois
permanecia em uma nica camada.
Na medida em que aplicativos da internet comearam a ser desenvolvidos, essa
estrutura teve que evoluir para uma arquitetura de trs camadas, pois era
muito lento esperar que os componentes da camada de interface + lgica do
18
negcio carregassem na mquina do cliente. A arquitetura de trs camadas

apresenta as camadas de:
Apresentao contempla a interface com o usurio e a apresentao das
informaes;
Lgica do negcio, lgica da aplicao ou aplicao contm as
tarefas e regras pertinentes ao negcio;
Persistncia contm funcionalidades de acesso a dados e sua persistncia.
Veja a seguir o desenvolvimento em 1, 2 e 3 camadas.
As imagens abaixo ilustram, respectivamente, o desenvolvimento em 1 camada
(cdigo monoltico), 2 camadas (cenrio de 2 camadas fsicas) e 3 camadas
(cenrio de 3 camadas fsicas).
19
Atualmente, o desenvolvimento pode demandar uma arquitetura de N

camadas, tambm chamada de sistema distribudo, com especializaes de
algumas camadas, por exemplo:
Podemos segmentar a camada de aplicao em mais de 1

camada: separando aspectos inerentes ao domnio e aspectos de
servios;
Podemos dividir a camada de dados;
Podemos dividir a camada de lgica de negcio, separando uma

camada de servios para web (servidor web).
Cabe ressaltar que sistemas pequenos no precisam ser desenvolvidos em

camadas, embora possam; mas os controles necessrios no compensam.
Arquitetura MVC (model, view and controller)

O MVC um padro de arquitetura de software bastante conhecido e
usado. Seu principal objetivo separar o cdigo da apresentao
(interfaces e relatrios) da lgica do negcio (da aplicao). Tal juno
deixa a aplicao vulnervel a mudanas, na medida em que uma mudana
requerida na forma de apresentao das informaes tambm poder afetar a
lgica do negcio.
20
A camada de apresentao equivale ao view, e a camada de lgica do negcio

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 lgica de negcio diferente, estaremos
duplicando cdigo.
Imagine um site de vendas na internet, o qual podemos acessar por intermdio
de um PC, celular ou tablet; a lgica do negcio sempre a mesma, o que
varia a forma de mostrar os dados na interface do usurio.
MVC: camadas
O modelo MCV (model, view and controller) possui as seguintes camadas:
Modelo de negcio (model) contm as regras do negcio e os dados
necessrios. Encapsula os dados e o comportamento, sem preocupao da
forma como mostr-los. o corao da aplicao, sendo responsvel por tudo
que a aplicao vai fazer em termos de armazenamento, manipulao e
gerao dos dados.
Viso (view) responsvel pela interao com usurio e pela apresentao
das vises dos dados do negcio, sem qualquer preocupao em como os
dados foram obtidos. Controla e mapeia as aes.
Controle (controller) faz a intermediao entre as camadas de viso e
modelo comandando o fluxo de obteno, encaminhamento e apresentao dos
dados. Por meio do controle define-se o comportamento da apresentao,
interpretando-se aes do usurio e mapeando-se chamadas do modelo.
21
MVC: funcionamento do padro

O funcionamento do padro MVC pode ocorrer de duas formas:
O controle interpreta os comandos de entrada de dados e eventos do usurio;
O controle chama as aes necessrias do modelo de negcios.
As alteraes no modelo derivadas das aes do modelo de negcios so
enviadas camada de viso, podendo ter o controle (parte b da imagem) como
intermedirio ou no (parte a da imagem). No caso do controle intermediar, ele
seleciona a viso apropriada.
Conforme ilustrado na figura a seguir, o padro MVC bastante usado em

aplicaes que rodam sob a internet:
Um servio chamado a partir de diferentes clientes;
A lgica do negcio a mesma;
Os servidores no so necessariamente mquinas virtuais.
22
MVC: vantagens e desvantagens

Dentre as vantagens pelo uso e aplicao do modelo MVC, podemos
citar:
Possibilita facilmente a incluso de novos clientes atravs da criao de novo
visualizador e seus respectivos controles;
Ao gerenciar mltiplos visualizadores com o mesmo modelo, facilitam-se a
incluso de novas funcionalidades, os testes e a manuteno da aplicao;
Viabiliza o desenvolvimento em paralelo, pois modelo, visualizador e controle
so independentes.
Dentre as desvantagens do modelo:
Demanda mais complexidade e maior tempo de anlise e modelagem do
sistema;
Requer mo de obra especializada com conhecimento no modelo e sua
implementao;
No aconselhvel para pequenas aplicaes.
Quadro comparativo
Tecendo um comparativo entre o modelo em camadas, especificamente o de
trs camadas e o modelo MVC, temos a expor que:
23
O MVC est associado arquitetura da aplicao, do ponto de vista da

comunicao entre os componentes;
A arquitetura em camadas est relacionada com a arquitetura do sistema,
pela qual a responsabilidade se divide em camada de apresentao, negcio e
acesso a dados;
Os dois modelos se complementam e podem coexistir,
conforme ilustra a imagem a seguir;
O modelo MVC tambm pode ser aplicado em sistemas desenvolvidos sob a
arquitetura de 1 e 2 camadas;
O modelo MVC no se preocupa com aspectos de persistncia dos dados.
Aprenda Mais
Material complementar
Para saber mais sobre o assunto, acesse e leia os contedos 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/
24
Referncias
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com
UML. 2. ed. Campus, 2006. [Captulo 1.]
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usurio. 2. ed. Rio de
Janeiro: Elsevier, 2005. [Captulos 1 e 2.]
FOWLER, M. UML essencial: um breve guia para a linguagem-padro de
modelagem de objetos. 3. ed. Porto Alegre: Artmed, 2005.
Exerccios de fixao
Questo 1
No que se refere s atividades de anlise e projeto orientado a objetos, assinale
a nica alternativa errada.
a) A fase de anlise visa determinar como as coisas sero implementadas.
b) A fase de projeto enfatiza os objetos de software e a forma como eles
sero interligados.
c) A fase de anlise foca no desenvolvimento do modelo de negcios e,
para tal, usa o modelo de casos de uso da UML.
d) Na anlise, preocupamo-nos em fazer a coisa certa, e, no projeto,
focamos em fazer certo a coisa.
e) Na fase de anlise, desenvolvemos o diagrama conceitual de classes com
as classes do negcio. Na fase de projeto, refinamos esse modelo de
classes com a incluso de novos elementos.
Questo 2
No que se refere s perspectivas dos diagramas UML, analise as alternativas a
seguir.
I. Os diagramas especficos da perspectiva conceitual so diagramas de casos
de uso e diagramas de pacotes.
25
II. Os diagramas especficos da perspectiva de especificao so, por exemplo,

diagramas de componentes.
III. Diagramas especficos da perspectiva de implementao, como diagramas
de sequncia.
Com base em sua anlise, assinale a nica alternativa correta:
a) Esto corretas apenas I e II
b) Est correta apenas I
c) Esto corretas I, II e III
d) Esto corretas apenas II e III
e) Esto corretas apenas I e III
Questo 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
sistemas
implementados
sob
qualquer
paradigma:
estruturado e orientado a objetos.

e) O RUP dividido em quatro fases: concepo, elaborao, construo e
transio.
Questo 4
Sobre a estrutura do modelo RUP, analise as assertivas.
I. Cada fase e segmentado em iteraes.
II. Cada fase pode ter, no mximo, duas iteraes.
26
III. A cada iterao podemos demandar duas ou trs disciplinas, sejam de

engenharia ou de apoio.
Com base em sua anlise, assinale a alternativa correta.
a) Est correta apenas I
b) Esto corretas I, II e III
c) Esto corretas apenas I e II
Questo 5
Analise as duas assertivas a seguir e a relao entre elas.
I. O modelo RUP baseado em casos de uso.
... porque...
II. Durante anlise, projeto e implementao, os casos de uso so modelados e
realizados.
Com base em seu entendimento, assinale a resposta correta quanto
assertividade de cada uma e sobre a relao entre elas.
a) As duas assertivas esto corretas, e a segunda justifica a primeira.
b) As duas assertivas esto corretas, e a segunda no justifica a primeira.
c) As duas assertivas esto 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.
Questo 6
27
Em linhas gerais, a arquitetura abrange as decises sobre a organizao do
software. Assinale a nica alternativa que no est includa dentre essas

decises.
a) Definio da estrutura (elementos estruturais) do software.
b) Especificao do comportamento do sistema.
c) Definio de um estilo arquitetnico.
d) Definio da interface do software.
e) Definio do que o sistema deve fazer.
Questo 7
O projeto de arquitetura do software compreende a arquitetura fsica e lgica.
Com base nesse conceito, analise as assertivas a seguir.
I. A arquitetura lgica corresponde decomposio hierrquica do sistema em
mdulos lgicos ou subsistemas.
II. A arquitetura lgica definida atravs do diagrama de pacotes.
III. A arquitetura fsica corresponde decomposio do sistema em mdulos
fsicos.
IV. A arquitetura fsica definida pelo diagrama de componentes e de
implantao da UML.
Com base em sua anlise, assinale a nica alternativa correta.
a) Esto corretas apenas II e III
b) Esto corretas apenas I, II e III
c) Esto corretas I, II , III e IV
d) Esto corretas apenas I e IV
e) Esto corretas apenas I e II
28
Questo 8
No que se refere ao modelo de arquitetura de software em camadas, assinale a
nica alternativa errada.
a) As principais motivaes para a diviso em camadas so: separar cdigo
(negcio, da interface), facilitar a manuteno e fomentar o reuso.
b) Trs o nmero mximo de camadas possveis.
c) O modelo em trs camadas surgiu com o advento da internet, pois era
demorado esperar que os componentes da camada de interface e lgica
do negcio fossem carregados na mquina do cliente.
d) A arquitetura de trs camadas contempla as camadas de apresentao,
lgica do negcio e persistncia.
e) Sistemas pequenos no precisam ser desenvolvidos em camadas.
Questo 9
Sobre o modelo MVC (model, view and controller), analise as assertivas a
seguir.
I. Seu principal objetivo separar o cdigo da apresentao (interfaces e
relatrios) da lgica do negcio (da aplicao).
II. A principal motivao o desenvolvimento, hoje, demandar interfaces para
diferentes dispositivos mas a lgica da aplicao a mesma.
III. O modelo MVC no se preocupa com persistncia.
IV. O modelo MVC idntico ao modelo em trs camadas.
a) Esto corretas apenas I, II e III
b) Esto corretas I, II, III e IV
c) Esto corretas apenas I, II e IV
29
d) Esto corretas apenas I e II

e) Esto corretas apenas III e IV
Questo 10
O modelo MVC no aconselhvel a pequenas aplicaes.
... porque...
II. Demanda mais complexidade e maior tempo de anlise e modelagem do
sistema.
Com base em sua anlise, assinale a resposta correta quanto assertividade de
cada uma e sobre a relao entre elas.
Questo 1 - A
Justificativa: Na fase de anlise, deve-se definir o que fazer. O como fazer
definido na fase de projeto do processo de desenvolvimento do software.
Questo 2 - A
Justificativa: O diagrama de sequncia no representa a perspectiva de
implementao, e sim o diagrama de implantao.
30
Questo 3 - D
Justificativa: O modelo RUP destina-se exclusivamente ao desenvolvimento de
sistemas sob o paradigma orientado a objetos.
Questo 4 - A
Justificativa: Cada fase pode ter N iteraes, dependendo do tamanho do
projeto. A cada iterao, pode-se demandar tantas disciplinas quantas forem
necessrias fase e iterao.
Questo 5 - E
Justificativa: O modelo RUP modela os casos de uso na disciplina de anlise e
os realiza nas disciplinas de projeto e implementao, e, por esse motivo, est
baseado em casos de uso.
Questo 6 - E
Justificativa: A definio do que o sistema deve fazer responsabilidade das
atividades de requisitos e anlise, no sendo uma deciso para definio da
arquitetura.
Questo 7 - C
Justificativa: Todas as assertivas definem corretamente o que se faz e que
diagramas da UML so usados.
Questo 8 - B
Justificativa: Em tese, no h limites para o nmero mximo de camadas. H
modelos hoje usando mais de trs camadas.
Questo 9 - A
Justificativa: O modelo em camadas e o modelo MVC no so a mesma coisa. O
modelo MCV, por exemplo, no se preocupa com a persistncia; j o modelo
em trs camadas sim. Logo, a diviso dos cdigos nas camadas diferenciado.
31
Alm disso, o modelo MVC tambm pode ser aplicado em sistemas

desenvolvidos sob a arquitetura de uma e duas camadas.
Questo 10 - A
Justificativa: Se a aplicao pequena, no compensa o custo de anlise e
modelagem mais complexas, alm da necessidade de mo de obra
especializada.
Introduo
O desenvolvimento em camadas vem sendo usado fortemente pelos
desenvolvedores de software, na tentativa de obter produtos mais coesos,
menos acoplados, mais reutilizveis e de manuteno menos problemtica.
A arquitetura lgica de um sistema a ser desenvolvido envolvem decises
estratgicas que envolve dentre outros aspectos: a escolha da modularizao
do sistema, da estrutura de comunicao e controle entre os subsistemas, a
escolha da estratgia de persistncia, oportunidades de reuso de software, bem
como atendimento a requisitos de desempenho, custo, mobilidade, uso de
padres.
A definio da arquitetura da aplicao, envolve o conhecimento de conceitos
como coeso, acoplamento, princpios para reuso do software, bem como o de
padres 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 dependncias.
32
Abordaremos ainda o conceito de diagrama conceitual de classes e como

deriva-lo com base no diagrama de casos de uso e das respectivas
especificaes textuais de cada caso de uso.
Objetivo:
1. Fundamentar as principais caractersticas e 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.
Contedo
Arquitetura lgica
Conforme estudamos na aula 1, a arquitetura lgica corresponde
decomposio hierrquica do sistema em mdulos lgicos ou subsistemas, bem
como a especificao da interface e dependncia entre esses mdulos. Com o
uso da UML, a arquitetura lgica definida atravs do diagrama de pacotes
como parte do modelo de projetos. Ento, vamos definir o conceito de
arquitetura lgica:
Arquitetura lgica a organizao, em geral, de casos de uso, classes e/ou
componentes em pacotes, subsistemas e camadas. lgica, pois, nesse
momento, no h, ainda, comprometimento de como esses elementos sero
implantados. Estudamos tambm na aula 1 o desenvolvimento em camadas,
cuja finalidade organizar a aplicao visando a uma diviso de cdigo
eficiente que favorece a manuteno e o reuso do software. Uma arquitetura
lgica no precisa ser organizada em camadas, mas isso torna-se muito
comum.
33
A organizao das partes de um sistema

Quando falamos em arquitetura de um sistema, falamos de sua organizao em
partes, das relaes de dependncias entre as partes e da forma como
dividimos os elementos do sistema entre as partes. Quando falamos de partes,
referimo-nos a subsistemas, mdulos, pacotes, classes, componentes, mtodos
de uma classe ou qualquer outra forma de organizar os elementos de um
sistema.
Existem dois conceitos relevantes que esto diretamente relacionados ao
conceito de arquitetura de software: acoplamento e coeso. Veremos, a
seguir, as caractersticas de cada um.
Acoplamento e coeso
O acoplamento diz respeito dependncia entre as partes, a forma como
esto relacionadas ou acopladas. Partindo do prprio 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 interdependncia entre as partes. Dessa forma,
os sistemas devem ser organizados para ter baixo acoplamento ou baixa
dependncia.
O alto acoplamento entre as partes pode gerar:
Dificuldade de alterao no sistema, uma vez que existe dependncia
entre as partes. A alterao em uma parte pode demandar reflexos em outras
partes que dela dependem.
Dificuldade de reutilizao, uma vez que depende da presena de outras
partes.
34
J o princpio da coeso diz respeito ao grau de dependncias entre os

elementos internos das partes do sistema. Podemos dizer que a coeso 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 coeso, ou seja,
que a afinidade entre as funcionalidades seja alta.
Uma parte com baixa coeso faz muitas coisas no relacionadas, tendendo aos
seguintes problemas:
Dificuldade de entendimento das partes e, consequentemente, do

sistema;
Dificuldade de reutilizao, na medida em que a parte no faz uma

tarefa nica;
Dificuldade de manuteno.
Arquitetura lgica 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 relao com o modelo de trs camadas, poderamos ter as
camadas de IU (interface com usurio), domnio (lgica da aplicao ou lgica
do negcio) e BD (acesso e persistncia a dados), sendo representadas cada
uma por um pacote.
Segundo a UML, a diviso em pacotes livre, podendo ser usado o critrio
desejado. Um critrio muito empregado a diviso de um sistema grande em
pacotes funcionais, ou seja, diviso em diferentes pacotes das funcionalidades
dos subsistemas.
Um diagrama de pacotes fornece mecanismos de agrupar qualquer elemento
UML: classes, casos de uso, componentes, ns, outros pacotes etc. A hierarquia
de pacotes tambm possvel.
35
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 representao de pacote na UML, onde sua identificao se
d pelo seu nome, no caso, Pacote.
O diagrama de pacotes mostra os pacotes e as dependncias entre eles.
Os relacionamentos de dependncia no so transitrios e resumem as
dependncias entre os contedos dos pacotes. A dependncia 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 dependncia (seta pontilhada).
Uma modificao no elemento independente poder afetar o elemento
dependente. Uma dependncia 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
36
representando Control; e Modelo representando o modelo da lgica do

negcio.
Esta imagem da sequncia mostra a diviso em pacotes sob o enfoque do

desenvolvimento em camadas evidenciando a dependncia do pacote de
Apresentao em relao ao pacote Lgica do negcio e a dependncia
deste em relao ao pacote Base de dados.
Conforme ilustrado na imagem abaixo, o sistema de uma loja dividido em trs

pacotes: Gerenciar compras, Gerenciar vendas e Gerenciar financeiro:
37
Conforme ilustrado na figura abaixo, o pacote de nome Gerenciar financeiro,

um dos pacotes do sistema de loja (da imagem apresentada) contm 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.
Ateno
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 diviso em
pacotes, na fase de projeto, quando o diagrama conceitual de
38
classes ser refinado com vistas definio do diagrama de

classes de projeto.
Os exemplos aqui apresentados visam esclarecer que no
existem regras para o particionamento do sistema em pacotes,
podendo ser usado o critrio que melhor se adequar s
necessidades do sistema e de suas especificidades.
Diagrama conceitual de classes

O diagrama conceitual de classes de negcio deriva dos casos de uso e contm
as classes inerentes ao negcio, correspondendo ao modelo de domnio. A
aplicao da UML para diagrama de classes a um modelo de domnio produz
um modelo de perspectiva conceitual que resulta na identificao de um
conjunto de classes conceituais, fundamentais na anlise orientada a objetos.
Para criar um modelo de domnio, identifique as classes conceituais, desenhe-as
como classes em diagrama de classes, em seguida acrescente atributos,
associaes e multiplicidades.
As classes de negcio e domnio do problema.
Relaes entre essas classes. oportuno representar associaes e, na fase
de elaborao do diagrama de classes de projeto, analisar melhor e identificar o
melhor relacionamento para cada classe.
Atributos das classes conceituais.
Em geral, as operaes (assinatura do mtodo) no so definidas, mas
oportuno relacionar mtodos (sem assinaturas completas: lista de parmetros)
derivados de casos de uso.
Multiplicidade.
39
Classes conceituais
Craig Larman, em seu livro Utilizando UM e Padres, discute trs formas de
descobrir as classes conceituais inerentes a um modelo de domnio.
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 tcnicas, recomendo a leitura do livro.
Aqui abordaremos a terceira, que pressupe a elaborao do diagrama e
descries dos casos de uso previamente.
Como identificar classes analisando substantivos ou frases nominais nas
especificaes de casos de uso, especialmente, pelo modelo completo de
especificao de caso de uso?
Consideremos uma iterao do processo RUP e o caso de uso Vender
produtos referente venda em uma loja, conforme diagrama e especificaes
a seguir.
A seguir voc ver a especificao textual do caso de uso Vender Produtos.
40
Casos de usos
Ator(es): caixa, cliente.
Pr-condio: produtos devidamente cadastrados.
CASO DE USO: VENDER PRODUTOS
Cenrio principal
1. Caixa inicia uma nova venda.
2. Caixa informa identificao do cliente.
3. Sistema localiza cliente.
4. Para cada item da venda so 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 unitrio 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 carto.
8. Sistema registra dados da venda.
9. Sistema imprime o recibo da venda.
Cenrios alternativos
3.1. a) Cliente no cadastrado:
1. Extends cadastrar cliente.
2. Sistema retorna ao passo 2 do cenrio principal.
4.2. a) Item de venda no localizado:
1. Sistema informa O item de venda no est cadastrado.
41
2. Sistema retorna ao passo 4.1. do cenrio principal.

CASO DE USO: CADASTRAR CLIENTE
Cenrio principal
1. Caixa informa dados do cliente*.
2. Sistema insere dados do cliente.
*CPF, nome, endereo (rua, nmero, complemento, bairro, cidade, UF),
telefone celular, telefone residencial.
CASO DE USO: PAGAR DINHEIRO
Cenrio 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
Cenrio principal
1. Caixa informa os dados do cheque (banco, agncia, conta e
nmero do cheque).
2. Sistema registra o pagamento em cheque.
CASO DE USO: PAGAR CARTO
Cenrio principal
1. Caixa informa os dados do carto (administradora,
nmero de carto, validade de carto e dgitos de
segurana).
42
2. Sistema valida compra com administradora de carto.

3. Sistema registra o pagamento com carto.
2. a) Administradora no autoriza:
1. Sistema informa Compra no autorizada pela Adm do carto.
2. Sistema retorna ao passo 1 do cenrio principal.
Os substantivos ou frases nominais que esto em negrito so candidatos a:
classes conceituais ou atributos dessas classes. Uma desvantagem dessa
abordagem a impreciso da linguagem natural, na medida em que diferentes
frases nominais podem representar a mesma classe conceitual ou atributo em
funo da ambiguidade. Por isso, importante combinar com a tcnica 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
Transaes de negcios:
So fundamentais.
Inicie
com
esse
Venda, pagamento, reserva, locao

grupo
de etc.
classes.
Transaes de linhas de item:
As transaes, em geral, vm
descritas com linhas de item.
Prossiga
identificando
Itens de venda.
esse
grupo de classes.
43
Produtos ou servios relacionados com

uma transao ou com uma linha de
item da transao:
Esses devem ser identificados
Produto.
na sequncia das transaes de

linhas de item.
Onde a transao registrada?
Registradora, livro dirio.
Papis de pessoas ou organizaes

relacionadas transao (atores, nos
casos de uso):
Caixa,
cliente,
loja,
vendedor,
Geralmente, precisamos saber atendente.

as
partes
envolvidas
na
transao.
Local da transao, local do servio.
Loja, aeroporto.
Outros sistemas colaboradores.
Sistema de autorizao de crdito.

Dinheiro, cheque, carto, linha de
Instrumentos financeiros.
Registro
de
finanas,
contrato.
crdito.
trabalho,
Recibo, livro dirio, livro-caixa.
Derivando Classes Conceituais dos Casos de uso

Analisando a especificao do casos de uso Vender produtos, temos:
Os substantivos ou frases nominais que esto em negrito so candidatos a:
classes conceituais ou atributos dessas classes. Uma desvantagem dessa
abordagem a impreciso da linguagem natural, na medida em que diferentes
frases nominais podem representar a mesma classe conceitual ou atributo em
funo da ambiguidade. Por isso, importante combinar com a tcnica da lista
de categoria das classes.
44
Classes Conceituais Candidatas

Pode-se identificar classes analisando frases nominais e substantivos da
descrio dos casos de uso e da lista de categorias de classes. Veja abaixo as
suas definies:
Caixa: devemos saber a qualquer momento qual caixa registrou determinada
venda.
Venda: o cerne do sistema, o qual contm 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
unitrio do produto) relativos aos itens vendidos.
Pagamento: armazena os dados de pagamento, que podem ser de trs
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, agncia, conta e nmero do
cheque);
Pagamento Carto: dados do carto (administradora, nmero do carto,
validade do carto e dgitos de segurana).
Recibo de venda: contm os dados da venda e do pagamento. Em geral,
relatrios no devem ser considerados no modelo de domnio, pois as
informaes nele contidas so derivadas de outras classes. Porm, devemos
considerar tambm a relevncia do relatrio dentro da regra de negcio.
Recibos de venda, em geral, tm o papel de dar direito de troca ao comprador,
o que seria uma razo para mostrar o recibo de venda como uma classe do
45
modelo de domnio nesse caso, a devoluo de itens no tratada (seja pelo

sistema como um todo ou apenas por essa iterao).
Como encontrar as associaes relevantes
Associaes entre classes. Existem vrios tipos de relacionamentos entre

classes, mas as associaes podem servir em qualquer situao. Os demais
relacionamentos mostraro melhor a semntica da relao entre classes,
favorecendo a vida do programador. Mas nesse momento esse detalhe no
relevante, devendo ser deixado para o modelo de projeto de classes. A ideia
aqui relacionar as classes relevantes para a implementao dos requisitos.
46
Alm das associaes, identificaremos tambm:

Nome das associaes: geralmente, devemos usar o formato <Classe> +
verbo + <Classe>, segundo o qual o verbo cria o sentido lgico. 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 trs modalidades
expressas nos casos de uso. Nesse caso, usamos a expresso pode ser, de
forma a expressar que o pagamento pode ser em dinheiro ou em carto ou,
ainda, em cheque.
Multiplicidade indica quantas instncias de cada classe esto envolvidas em
cada associao. A anlise da multiplicidade deve ser realizada a cada par de
classes participante da associao. Exemplo:
1) O caixa pode registrar nenhuma (0) ou vrias (*) vendas. Em contrapartida,

a venda s pode ser registrada por um caixa.
2) Uma venda pode conter um ou vrios (*) 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 (instncia
nica) pode representar um item de venda.
4) Uma venda tem um pagamento. E o pagamento refere-se a apenas uma
venda.
47
5) A venda pode ser realizada por apenas um cliente. E o cliente pode realizar
nenhuma (0) ou vrias vendas (*).
6) O pagamento pode ser (1) ou no (0) em dinheiro, da mesma forma que o
pagamento pode ser (1) ou no (0) em carto. E o pagamento tambm pode
ser (1) ou no (0) em cheque.
Que atributos especificar?

O que exatamente so os atributos?
Atributos: dados relacionados s classes candidatas que podemos observar
das especificaes dos casos de uso (vide elementos em negrito nas
especificaes).
Identificao do cliente;
Identificao do item de venda;
Nome do produto;
Valor unitrio;
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 carto.
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 so do

tipo simples (inteiro, lgica, double, data, hora, string).
48
Ateno: modelo de classe no modelo de dados; assim sendo, no existem,

em classes, os conceitos de chave primria e chave estrangeira, que migra a
chave primria para a tabela que contm a cardinalidade N.
Em classes, apenas seus prprios atributos devem existir; Chave (primria ou
estrangeira) um conceito de banco de dados relacional e no se aplica a
classes.
Algumas consideraes 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 no explicitasse a data, usual que
armazenemos a data da realizao da venda, para efeitos contbeis. O valor da
venda, em tese, seria um atributo derivado, ou seja, que pode ser obtido
mediante clculos. Porm, nesse momento, optamos por mant-lo como
atributo. O mesmo vale para impostos.
49
3. Item de venda: embora a especificao de caso de uso no 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 identificao, alm de dados como
nome e valor unitrio de venda.
5. Pagamento: valor a pagar tambm trata-se de um atributo derivado, mas se
decidiu em mant-lo, pois, muitas vezes, descontos podem ser dados (embora
no tenhamos considerado nesse momento o atributo de desconto na venda).
6. Dinheiro: armazenar o histrico da transao para eventual conferncia de
caixa, futura.
7. Carto: por questes de sigilo e respeito informao pessoal do cliente,
no podemos armazenar os dgitos de segurana.
Ateno
A ltima imagem do diagrama de classes seria uma verso final
do Diagrama Conceitual de Classes, considerando o universo de
casos de uso da iterao corrente de um suposto processo RUP
aplicado a um sistema de gesto de uma loja.
Um ltimo comentrio refere-se corretude de um modelo
conceitual de classes. Em tese, no existe modelo de domnio
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 comunicao entre usurios e
desenvolvedores.
50
Referncias
LARMAN, C. Modelos de domnio. In: LARMAN, C. Utilizando UML e
padres: uma introduo anlise e ao projeto orientados a objetos e ao
desenvolvimento iterativo. 3. ed. Bookman, 2007.
Exerccios de fixao
Questo 1
No que se refere s atividades de anlise e projeto orientado a objetos, assinale
a nica alternativa errada.
a) A fase de anlise visa determinar como as coisas sero implementadas.
b) A fase de projeto enfatiza os objetos de software e a forma como eles
sero interligados.
c) A fase de anlise foca no desenvolvimento do modelo de negcios e,
para tal, usa o modelo de casos de uso da UML.
d) Na anlise, preocupamos em fazer a coisa certa, e, no projeto,
focamos em faa certo a coisa.
e) Na fase de anlise, desenvolvemos o diagrama conceitual de classes com
as classes do negcio. Na fase de projeto, refinamos esse modelo de
classes com a incluso de novos elementos.
Questo 2
No que se refere s perspectivas dos diagramas UML, analise as alternativas a
seguir.
I. Os diagramas especficos da perspectiva conceitual so diagramas de casos
de uso e diagramas de pacotes.
II. Os diagramas especficos da perspectiva de especificao so, por exemplo,
diagramas de componentes.
51
III. Exemplo de um diagrama especfico da perspectiva de implementao:

diagrama de sequncia.
a) Esto corretas apenas I e II.
b) Est correta apenas I.
c) Esto corretas I, II e III.
d) Esto corretas apenas II e III.
e) Esto corretas apenas I e III.
Questo 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
sistemas
implementados
sob
qualquer
paradigma:
estruturado e orientado a objetos.

e) O RUP dividido em quatro fases: concepo, elaborao, construo e
transio.
Questo 4
Sobre a estrutura do modelo RUP analise estas assertivas:
I. Cada fase segmentada em iteraes.
II. Cada fase pode ter no mximo duas iteraes.
III. A cada iterao podemos demandar duas ou trs disciplinas, sejam de
engenharia ou de apoio.
52

a) Est correta apenas I.
b) Esto corretas I, II e III.
c) Esto corretas apenas I e II.
d) Esto corretas apenas II e III.
e) Esto corretas apenas I e III.
Questo 5
I. O modelo RUP baseado em casos de uso.
... porque...
II. Durante a anlise, projeto e implementao, os casos de uso so modelados
e realizados.
Questo 6
Assinale a alternativa incorreta no que se refere ao modelo conceitual de
classes.
53
a) Apresenta as classes envolvidas no domnio do negcio.

b) Apresenta os atributos mais relevantes ao caso de uso em questo.
c) Apresenta as associaes entre as classes.
d) Apresenta as multiplicidades das associaes entre as classes.
e) Apresenta os mtodos das classes.
Questo 7
No que se refere anlise de classes, aos relacionamentos e atributos para
constar no diagrama de classes, analise as assertivas abaixo.
I. Devemos considerar todos os tipos de relacionamentos possveis 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 domnio do
problema, tendo cuidado com atributos derivados.
IV. Devemos representar atributos-chave, tal qual fazemos no modelo
relacional de dados.
a) Esto corretas apenas II e III.
b) Esto corretas apenas I, II e III.
c) Esto corretas I, II , III e IV.
d) Est correta apenas III.
e) Esto corretas apenas I e II.
Questo 8
Assinale a nica alternativa correta.
54
a) Diagrama conceitual de classes deve considerar as especificaes de

casos de uso e o diagrama de casos de uso, alm de uma lista de
categoria de classes conceituais.
b) Diagrama conceitual de classes representa mtodos e sua visibilidade.
c) Diagrama conceitual de classes deve representar as mesmas classes que
o modelo de classes de projeto.
d) No devemos representar atributos no modelo de classes de domnio.
e) Devemos desenhar diagrama conceitual de classes apenas para grandes
projetos.
Questo 9
Analise se cada assertiva verdadeira ou falsa:
I. Devemos representar no modelo conceitual os relacionamentos de agregao
e composio.
II. Temos, necessariamente, que apresentar os atributos derivados no
diagrama conceitual de classes.
III. O diagrama conceitual de classes um modelo de domnio.
IV. Classes de persistncia no devem ser consideradas em modelos conceitual
de classes.
Com base em sua anlise, assinale a nica alternativa correta, que mostra a
sequncia 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.
55
Questo 10
I. O modelo conceitual de classes refinado a cada iterao, quando um
conjunto de requisitos considerado.
... porque...
II. O diagrama conceitual de classes no considera as classes de projeto.
Questo 1 - A
Justificativa: Na fase de anlise, deve-se definir o que fazer. O como fazer
considerado na fase de projeto do processo de desenvolvimento do software.
Questo 2 - A
Justificativa: O diagrama de sequncia no representa a perspectiva de
implementao, e sim o diagrama de implantao.
Questo 3 - D
Justificativa: O modelo RUP destina-se exclusivamente ao desenvolvimento de
sistemas sob o paradigma orientado a objetos.
56
Questo 4 - A
Justificativa: Cada fase pode ter N iteraes, dependendo do tamanho do
projeto. A cada iterao, pode-se demandar tantas disciplinas quantas forem
necessrias fase e iterao.
Questo 5 - A
Justificativa: O modelo RUP modela os casos de uso na disciplina de anlise,
realiza-os nas disciplinas de projeto e implementao e, por esse motivo, est
Questo 6 - E
Justificativa: O diagrama conceitual de classes no apresenta mtodos, pois
nesse modelo nenhuma operao definida.
Questo 7 - D
Justificativa: I falsa, pois devemos considerar apenas as associaes;
II falsa, pois devemos considerar apenas as classes do domnio, chamadas
classes de entidade que sejam relevantes para a representao do problema;
III correta;
e IV falsa, porque no existe o modelo de chave no modelo de classes (cada
classe tem apenas os atributos que lhe pertencem efetivamente).
Questo 8 - A
Justificativa: A segunda afirmativa falsa, pois o diagrama conceitual no
mostra mtodos; a terceira afirmativa falsa, pois as classes de software no
so apresentadas no modelo conceitual, sendo representadas no diagrama de
classes de projeto; a quarta tambm 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.
Questo 9 - B
57
Justificativa: I falsa, pois devemos, por simplificao, representar apenas as

associaes;
II os atributos derivados podem ser representados, mas no h
obrigatoriedade;
III verdadeira, pois mostra as classes do domnio do problema;
IV verdadeira, pois so classes de software.
Questo 10 - B
Justificativa: As duas assertivas so verdadeiras, porm a justificativa para a
primeira o fato de o modelo conceitual ser construdo com base em todos os
casos de uso e, a cada iterao, um conjunto de casos de uso ser considerado.
A cada iterao, novas classes so acrescidas ao modelo.
Introduo
A fase ou disciplina de anlise est voltada identificao e anlise dos
requisitos dos diversos usurios dos sistemas, ou seja, voltada ao entendimento
e modelagem do problema do negcio ao qual o sistema est relacionado.
O modelo de casos de uso est intimamente relacionado aos requisitos
funcionais do sistema e modelo conceitual de classes para evidenciar as classes
relacionadas ao problema. Alm das classes, so identificados alguns atributos
que caracterizam a entidade do negcio.
A fase ou disciplina de projeto visa adicionar detalhes ao modelo de classes, de
forma que esse passe a representar aspectos de projeto. Tal ao possibilita a
definio da arquitetura do sistema, seus componentes e a relao entre eles.
Nesta aula, focaremos a transio da anlise para o projeto, mostrando os
refinamentos necessrios ao modelo de classes e considerando as interaes
58
(diagramas de sequncia e/ou comunicao) entre os objetos na realizao de

um caso de uso e alguns padres de projeto.
Objetivo:
1. Caracterizar o projeto de software e suas atividades;
2. Definir padres de projeto e reconhecer sua utilidade na definio do
diagrama de classes de projeto.
Contedo
Projeto do software
A fase ou disciplina de projeto de software visa especificar como o software vai
funcionar, sendo ele voltado a uma arquitetura e a um ambiente fsico
especfico. O projeto visa estabelecer alternativas de soluo, de forma que os
requisitos funcionais sejam atendidos e que sejam tambm respeitadas as
restries definidas pelos requisitos no funcionais.
Conforme definido em Princpios de anlise e projeto de sistemas com
UML, de Eduardo Bezerra, as principais atividades realizadas durante o projeto
de software so:
Detalhamento dos aspectos dinmicos.
Persistncia de objetos.
Padres de software.
Refinamento dos aspectos estticos e estruturais.
Projeto de interface grfica com usurio.
Projeto da arquitetura.
Projeto de algoritmos.
A seguir, conhea cada uma dessas atividades.
59
Detalhamento dos aspectos dinmicos

Aspectos dinmicos dos objetos dizem respeito ao comportamento desses na
troca de mensagens para cumprir com suas responsabilidades.
Embora o estudo dos aspectos dinmicos inicie na fase ou disciplina de
anlise, na fase de projeto que ele se intensifica, pois quando nos
preocupamos com o detalhamento das colaboraes nas quais cada classe
participa.
A UML disponibiliza os modelos de interao (sequncia ou comunicao), o
diagrama de estados e o diagrama de atividades.
Refinamento dos aspectos estticos e estruturais

Refinamento do modelo conceitual de classes acrescenta atributos e mtodos
que melhor definam as responsabilidades.
Pode haver classe de anlise que precise ser representada por mais de uma
classe de projeto e vice-versa (embora isso seja mais difcil).
So revistos e definidos tipos para os atributos.
So definidas as navegabilidades das associaes entre classes.
Refinamento dos relacionamentos de associaes, que podem vir a ser
composio/agregao, generalizao/especializao, classes de associao e
dependncias.
Devem ser considerados aspectos como coeso e acoplamento, garantindo
maior independncia entre as classes. Deve ser considerada ainda a correta
aplicao do conceito de encapsulamento.
60
Destaque deve ser dado fatorao de classes atravs dos conceitos de

herana (relacionamento de generalizao e especializao entre classes) e
polimorfismo.
Projeto da arquitetura
A arquitetura lgica, conforme j citamos em nossas aulas, diz respeito
diviso do software em camadas, incluindo aqui o modelo MVC e o modelo em
camadas de apresentao, domnio, persistncia etc. O diagrama de pacotes
o modelo disponibilizado pela UML para representao da arquitetura lgica.
A arquitetura fsica diz respeito localizao fsica dos componentes de
software em diferentes ns de processamento (processadores). Nos dias de

hoje, muito comum essa distribuio de componentes em ns, so os
chamados sistemas distribudos.
Aspectos relevantes a serem considerados so: subsistemas; interfaces;
camadas de software, como controle e dependncia entre subsistemas.
A UML disponibiliza o diagrama de componentes para representar os
componentes do sistema e a dependncia entre eles, bem como o diagrama de
implantao, o qual apresenta os ns de processamento e a relao entre eles.
Persistncia de objetos
Diz respeito forma como os objetos so armazenados de forma persistente,
em geral em banco de dados, que podem ser relacionais, objetos relacionais ou
de objetos.
Quando a persistncia ocorre em bancos de dados relacionais ou objeto
relacional, deve-se elaborar estratgia de migrao do modelo de classes para
o modelo relacional ou objeto relacional.
61
Projeto de interface grfica com usurio

Definio das telas com as quais os atores interagem, com base nos casos de
uso.
Definio dos relatrios e formulrios de apoio ao sistema.
Devem ser considerados aspectos de usabilidade e ainda as restries
estabelecidas nos requisitos no funcionais.
Projeto de algoritmos
Consiste na definio da lgica e das estruturas de dados necessrias
definio dos algoritmos contidos nos mtodos das classes.
Conforme a complexidade dos algoritmos, podem ser definidos formalmente,
com textos ou ainda informalmente.
UML disponibiliza diagrama de atividades com a finalidade de expressar
algoritmos complexos ou que tenham aes em paralelo.
Padres de Projeto
Padres de software tm sido bastante usados em projetos de software na
tentativa de desenhar sistemas mais consistentes, com maior reuso.
Os padres so usados nas fases e disciplinas de anlise e de projeto.
Interaes
Os diagramas de interao so extremamente valiosos, pois vamos entender e
raciocinar em detalhes sobre quais mensagens enviar, para quem e em
que ordem. Podemos, nesse momento, refletir tambm sobre quais objetos
realmente precisam existir, quais as responsabilidades de cada um e como
62
interagem. o momento de verificarmos se podemos aplicar algum padro de

projeto dentro do princpio de aplicao de boas prticas.
Em geral, j aprendemos que:
Toda mensagem que chega a um objeto no diagrama de sequncia ou

comunicao vai representar uma operao da classe, ou seja, um mtodo na
classe que recebe a mensagem.
63
Observe que ao objeto Cliente, chega uma mensagem de nome Procurar

Cliente (Id Cliente), ou seja, essa ser a assinatura de um mtodo da classe,
conforme especificado na classe Cliente.
Cliente
+ Procurar Cliente (Ident Cliente : int) : boolean
Modelagem de classes de projeto

As classes de projeto so aquelas necessrias para implementar as
funcionalidades do sistema definidas na anlise, considerando as restries
imputadas pelos requisitos no funcionais. Veja alguns exemplos de situaes
que nos fazem acrescentar classes ao modelo conceitual, dando origem ao
modelo de classes de projeto.
Classes que sirvam de base para implementao do mecanismo de herana,
as chamadas classes abstratas;
Controle de segurana (autorizao e autenticao de acesso);
Registro de aes realizadas no sistema (guardam-se os logs de acesso);
Acesso e armazenamento (consistncia) dos dados;
Classes de interface com usurio e classes de controle, seguindo-se o padro
MVC (model-view-controller).
64
Cada situao relatada implica na necessidade de novas responsabilidades do

sistema, que demanda novas classes a serem projetadas.
Alm de novas classes, vamos tambm, nesse momento, refinar as classes
definidas no modelo conceitual de classes no que se refere a:
Visibilidade de atributos e mtodos;
Detalhes das assinaturas dos mtodos, como, por exemplo, os argumentos
adequados, o tipo de dado que retorna;
Anlise da possibilidade de uso da herana;
Identificao de novos mtodos pela anlise das interaes dos diagramas de
sequncia e/ou comunicao;
Substituio de relacionamentos de associaes
por
outros
mais
semanticamente adequados, como, por exemplo: agregao composio

classe de relacionamento dependncia.
Passando da anlise ao projeto: classes

Veja uma classe tpica de um modelo conceitual de classes, onde so
apresentados os atributos e mtodos obtidos diretamente do diagrama de casos
de uso (ou de outra tcnica), sendo poucos detalhes apresentados.
O nome da classe, que representa algo relevante para o negcio;
Os nomes dos principais atributos, a partir dos dados recuperados da
especificao textual dos casos de uso;
Os nomes de possveis mtodos derivados de casos de uso.
65
Classes: detalhes do projeto

Estereotipo da classe(<<entity>>)
Refinamento dos atributos:
Padro: visibilidade/nome: tipo = valor inicial.
Visibilidade: representada pelo sinal de menos (-) antes de cada nome de
atributo. No caso o menos, (-) indica uma visibilidade privada ao atributo.
Nome: em geral, o mesmo do modelo conceitual de classes.
Tipo: representa o tipo de dado dos atributos. No caso, string.
Valor inicial: seria o valor de inicializao de um atributo quando da criao
do objeto. No foi usado nesse exemplo.
Refinamento dos mtodos:
Padro: visibilidade/nome (parmetros): tipo/retorno.
Visibilidade: representada pelo sinal de mais (+) antes de cada nome. No
caso, o (+) indica uma visibilidade pblica ao mtodo.
Nome: o nome dos mtodos. Se o mtodo j existia no modelo conceitual de
classes, pode-se usar o mesmo nome. Se o mtodo foi descoberto por um
diagrama de interao (sequncia ou comunicao), deve-se usar o mesmo
nome usado nesses diagramas.
Tipo/retorno: representado por VOID aps o nome Incluir Fornecedor e
Boolean para o mtodo pesquisar fornecedor. VOID indica que a funo no
retorna nenhum tipo de dado, sendo, portanto, um procedimento, e no uma
funo.
Novos
mtodos
descobertos
pelos
diagramas
de
interao
(sequncia ou comunicao), por exemplo:

+ Pesquisar Fornecedor.
Assinatura completa do mtodo, contendo:
+ Pesquisar Fornecedor (cnpj: string): boolean.
Visibilidade: + (pblica).
66
Nome: Pesquisar Fornecedor.

Parmetros: Cnpj: string.
Tipo de dado que retorna: boolean.
Ou seja, uma funo que retorna um valor booleano (V ou F), se encontrou
ou no o fornecedor referenciado pelo parmetro CNPJ, que do tipo string.
Novas classes so acrescentadas, por exemplo:
EnderecoFornc na medida em que o fornecedor, com suas filiais, possui
mais de um endereo que deve ser tratado no sistema. O relacionamento
indicado foi de composio, pois a vida (criao e destruio) dos objetos da
classe Endereco est diretamente relacionada vida dos respectivos objetos
da classe FornecedorE.

Incluso
da
navegabilidade
(seta
chegando
na
classe
EnderecoFornc):
Conforme elemento apresentado, tambm obtido pela elaborao e anlise
dos diagramas de interao. A navegabilidade indica a direo da interao, ou
seja, no exemplo visto, apenas objetos da classe FornecedorE podem enviar
mensagem a objetos da classe EndereoFornc.
Na imagem a seguir, vemos a representao da classe Fornecedor em um
diagrama de classes de projeto, derivado do modelo conceitual de classes e
contendo detalhes de projeto.
67
Derivao do diagrama de classes de projeto

No diagrama conceitual de classes, no h preocupao na identificao exata
dos relacionamentos. De uma forma geral, so indicados como associaes. Na
elaborao do diagrama conceitual de classes, temos que nos preocupar com a
melhor forma de implementar.
Considere o seguinte trecho de um diagrama conceitual de classes:
Veremos mais exemplos de derivao de diagrama de classes de projeto com

base no diagrama conceitual de classes e algumas decises de implementao.
Veja um dos possveis trechos de diagrama de classes de projeto:
1. Incluso da classe Item Pedido, pois necessrio conhecer os produtos

que pertencem a um pedido.
68
2. Assim sendo, o pedido passa a ser composto de Item Pedido, pelo

relacionamento de composio (a vida de Item Pedido depende de pedido, ou
seja, criada e destruda por objetos da classe Pedido). E a classe Item
Pedido refere-se classe Produto. Foram adicionadas as multiplicidades dos
novos relacionamentos identificados.
3. Como as vendas podem ter descontos unitrios de produto, adicionou-se o
atributo Desconto Unit classe Item Pedido.
4. Outra deciso de projeto foi a incluso dos atributos Valor Pedido e
Impostos Pedido, que vo armazenar o total do pedido e o total de impostos
a serem recolhidos por pedido. Tal deciso deu-se pela necessidade de uma lei
vigente de informar tais dados ao fisco.
5 - Na classe ProdutosE foi includo o atributo Perc Imposto, que visa
informar o percentual de imposto daquele produto na venda. Esse atributo a
base para que se possa armazenar o atributo Impostos Pedido, que soma o
valor de todos os impostos de todos os itens constantes no pedido.
Modelos de interao na construo do modelo conceitual de

classes
Vamos demonstrar agora a utilidade dos modelos de interao para a
construo do modelo conceitual de classes. Para tal, vamos construir um
diagrama de sequncia, tomando por base:
O trecho de diagrama de casos de uso;
69
A especificao textual do caso de uso registrar pedido;

O trecho do diagrama de classes de projeto.
Todos os exemplos foram vistos anteriormente neste curso. Veja a seguir o
diagrama de sequncia.
Utilidade dos modelos de interao para a construo do modelo
conceitual de classes: diagrama de sequncia
CASO DE USO: REGISTRAR PEDIDO

Objetivo: registrar os pedidos solicitados pelos clientes.
Ator: atendente.
Cenrio principal
1. Atendente informa Id Cliente.
2. Sistema localiza cliente.
3. Para cada item a ser inserido so feitos tais passos:
3.1. Atendente informa Id Produto.
3.2. Sistema localiza produto.
3.3. Atendente informa quantidade de produto.
3.4. Sistema valida quantidade de produto.
3.5. Sistema registra item do pedido.
4. Atendente confirma dados do pedido.
5. Sistema registra pedido.
2.a. Cliente no cadastrado:
70
1. Sistema informa Cliente no cadastrado.

2. <<Extends Incluir Cliente>>.
3.a. Produto no cadastrado:
1. Sistema informa Produto no cadastrado.
2. Sistema retorna ao passo 3.1 do cenrio principal.
4.a. Sem estoque suficiente:
1. Sistema informa No h estoque suficiente do produto para a
qtde informada.
2. Sistema retorna ao passo 3.3. do cenrio principal.
Com base nos diagramas e especificaes apresentados, o diagrama de
sequncia do cenrio principal do caso de uso registrar pedido pode ficar tal
como apresentado a seguir (possuindo outras solues).
71
O diagrama de sequncia apresentado conta a histria do caso de uso

registrar pedido mostrando as classes que interagem e quais mensagens so
trocadas entre elas. Dessa soluo, uma das possveis, observe:
O mtodo Inicializar Pedido, da classe PedidoE vai iniciar o

pedido, gerando o nmero do pedido atravs do mtodo Gera
NumPedido, tambm da classe PedidoE, e ainda criando o
objeto Itens Pedido, que vai armazenar os itens do pedido
inicializado atravs do mtodo Criar ItemPed, que tem como
parmetro o Num Pedido que acabou de ser gerado.
Observe o loop, quadrado que circunda desde o item Pedido

informado pelo atendente at o retorno do mtodo Incluir Item
Pedido (Num Pedido, Id Produto, Qtde Produto). Ele indica
que todas as entradas de dados e todos os mtodos com seus
respectivos
retornos
so
repetidos,
conforme
indicado
na
especificao textual do cenrio principal do caso de uso em

questo (registrar pedido).
Observe que, a cada produto e respectiva quantidade informados

pelo atendente, e aps verificaes de produto existente e
quantidade em estoque, o item do pedido registrado pelo
mtodo Incluir Item Pedido (Num Pedido, Id Produto, Qtde
Produto) da classe Itens Pedido.
Ao final, aps o fim do loop, o pedido confirmado pelo

atendente, quando o pedido finalizado (registro efetivamente
inserido).
Reutilizao: padres, bibliotecas e componentes

O projetista do software tem sempre em mente a possibilidade de
reutilizao de classes e de solues j existentes, de forma a obter vantagens
quanto ao tempo de desenvolvimento (soluo j pronta) e confiabilidade (uso
e testes j realizados).
As principais fontes de reutilizao de cdigo so:
72
Padres de projeto
Um padro de software uma soluo para um problema recorrente, dentro
de um contexto especfico. A ideia conceber solues a partir de outras j
vivenciadas, similares, que foram documentadas e, principalmente, aprovadas.
Um padro de software, de forma geral, aumenta a produtividade na medida
em que o projetista no precisa reinventar a roda.
A soluo apontada pelo padro serve de ponto de partida para o problema
com o qual o projetista se depara.
So formas de reuso abstratas, na medida em que descrevem a essncia da
soluo de problemas comuns e recorrentes.
Padres no so classes e nem componentes, mas ajudam na construo
desses, orientando a melhor forma de agrupamento dos elementos, baseado
em experincias anteriores.
Existem padres para solues de anlise e de projeto.
uma forma de transferncia de conhecimento: os mais experientes criam os
padres, e os mais novos fazem uso.
Biblioteca de classes
Corresponde a uma coleo de classes que possuem uma determinada
finalidade.
uma forma de reuso mais concreta por meio da qual classes j prontas
podem ser usadas.
Exemplo: os ambientes das plataformas JAVA e .NET disponibilizam
bibliotecas de classes reutilizveis.
Componentes
So uma unidade de software que pode ser usada na construo de
diferentes sistemas.
Compreendem um conjunto de objetos que colaboram para oferecer servios,
mas tambm podem requisitar servios.
73
Existe uma rea de pesquisa denominada desenvolvimento baseado em

componentes (component based developer CBD). A ideia a construo de
componentes que possam ser usados em diversos contextos, em diversos
sistemas. Assim, o desenvolvimento fica, com o tempo, cada vez mais baseado
no reuso de componentes existentes.
Os componentes ficam armazenados em repositrios de componentes.
Componentes podem ser comercializados.
Responsabilidades
Uma das formas mais clssicas de pensar sobre projeto de objetos em um
software diz respeito a responsabilidades, papis e colaboraes.

A UML define responsabilidade: um contrato ou obrigao de um classificador.
Responsabilidade tem relao com o que o objeto precisa fazer para exercer
seu papel no contexto; e, basicamente, pode ser de dois tipos: fazer e
conhecer:
Fazer algo em prol da colaborao, seja criando um objeto, calculando,
controlando demais objetos etc.
Conhecer dados e objetos relacionados.
As responsabilidades dos objetos so identificadas durante a fase ou disciplina
de projeto de software.
A ideia de colaborao est intimamente relacionada com o conceito de
responsabilidade. Responsabilidades so implementadas por mtodos que
atuam por si s ou colaboram com mtodos de objetos relacionados. Os
diagramas de interao, por sua vez, so extremamente teis para atribuir
responsabilidades s classes.
Veja o diagrama de sequncia elaborado na seo anterior.
74
Observe que:
A classe PedidoE responsvel por criar Itens Pedido (responsabilidade de
fazer).
A classe PedidoUE responsvel por conhecer o seu total (responsabilidade
de conhecer). Sobre essa responsabilidade, para conhecer o seu total, a classe
faz uso do mtodo Obter TotalPed (), mas no o faz isso sozinha. Ela precisa
de colaborao da classe Itens Pedido atravs do mtodo Obter Sub Total
Ped (), pois quem conhece o total de cada linha de item do pedido a prpria
classe Itens Pedido.
Padres GRASP
Existem padres de projetos que ajudam na atribuio de responsabilidades,
fundamentando o raciocnio que deve ser aplicado para tal. Padres GRASP
(general responsibility and assignment software patterns padres gerais de
atribuio de responsabilidade em projeto) definem nove princpios, nove
75
padres, que representam conhecimento explcito que pode ser aplicado em

projetos.
Dentre os nove padres GRASP, falaremos dos cinco principais (exemplificando
a aplicao dos dois mais populares).:
Padro CREATOR (criador)
Nome: CREATOR.
Problema: quem CRIA o objeto X?
Soluo (conselho): atribuir classe B a responsabilidade de criar um
objeto da classe A, se uma das afirmativas abaixo for verdade.
- B contm A ou B agrega A de forma composta (composio).
- B registra A.
- B usa A.
- B contm os dados iniciais de A.
Vamos observar a aplicao desse padro no pequeno estudo de casos que
fizemos na seo anterior. Veja que a classe PedidoE cria objetos de Itens
Pedido, conforme mtodo <<Create>>; Criar ItemPed (Num Pedido).
Observe que no diagrama de classes isso se reflete no relacionamento de
composio entre PedidoE e Itens Pedido.
76
Padro INFORMATION EXPERT (especialista na informao)

Um dos mais elementares padres o especialista na informao.
Nome: INFORMATION EXPERT.
Problema: qual o princpio bsico para atribuir responsabilidades a objetos?
Soluo (sugesto): atribua a responsabilidade classe que tenha
informao necessria para satisfaz-la.
77
Possui uma responsabilidade precisa de informao sobre: outros objetos, o

estado do prprio objeto, informao que o objeto pode derivar etc.
A aplicao desse padro pode ser vista no estudo de caso da seo anterior,
conforme trecho do diagrama de sequncia apresentado: quem seria
responsvel por obter o total de um pedido. Quem conhece o total de um
pedido a prpria classe Pedido, logo o mtodo Obter Total Ped() deve ficar
na classe PedidoE, ou seja, ela a especialista na informao. Para conhecer
o total do pedido preciso saber o total de cada linha de pedido, o que no
modelo analisado feito pelo mtodo Obter Sub Total Ped(), da classe
Itens Pedido.
LOW COUPLING, CONTROLLER e HIGH COHESION

Padro LOW COUPLING (acoplamento baixo)
Nome: acoplamento baixo.
Problema: como apoiar dependncia baixa, baixo impacto de modificao e
aumento de reuso?
Soluo: atribuir responsabilidade de modo que o acoplamento permanea
baixo. Use esse princpio para avaliar alternativas.
Acoplamento uma medida que avalia o quo forte um elemento est
conectado, tem conhecimento ou depende de outros elementos. Uma classe
com acoplamento baixo (fraco) no dependente de muitos elementos, o que
positivo.
Padro CONTROLLER (controlador)
Nome: controlador.
Problema: qual o primeiro objeto, alm da classe boundary (interface com
usurio), que recebe e controla uma operao do sistema?
Operao do sistema: principais eventos de entrada do sistema.
Soluo: atribui a responsabilidade a uma classe, conforme estas opes:
Controladora do sistema ou subsistema como um todo.
Controladora do caso de uso dentro do qual ocorreu um evento.
78
Um controlador o primeiro objeto, alm da interface do usurio, responsvel

por receber ou tratar uma mensagem de operao do sistema.
Padro HIGH COHESION (coeso alta)
Nome: coeso alta.
Problema: como manter os objetos inteligveis e gerenciveis?
Soluo: atribuir responsabilidade de forma que a coeso permanea alta.
Classes com coeso baixa, em geral, assumem responsabilidades que so de
outros objetos, fazem muitas coisas e no esto relacionadas.
Referncias
BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. 3. ed.
Elsevier, 2015.
LARMAN, C. Utilizando UML e padres: uma introduo anlise e projeto
orientados a objetos e ao desenvolvimento iterativo. 3. ed. Bookman, 2007.
Exerccios de fixao
Questo 1
No que se refere s atividades de projeto orientado a objetos, assinale a nica
alternativa errada.
a) Anlise dos requisitos e modelo conceitual de classes.
b) Modelagem das interaes e identificao de responsabilidades das
classes.
c) Projeto de arquitetura do software.
d) Projeto de persistncia dos dados.
e) Projeto de interface grfica do usurio.
79
Questo 2
Leia as afirmativas a seguir referentes s atividades inerentes ao projeto de
objetos.
I. O diagrama conceitual de classes j traz as classes completas nas quais
teremos a definio dos atributos.
II. Refinamento das classes, com insero de classes de software (de projeto).
III. Insero de mtodos nas classes, com atribuies de responsabilidades.
b) Est correta apenas I
Questo 3
Sobre os relacionamentos entre classe, assinale a nica alternativa falsa.
a) A navegabilidade indica a direo em que um objeto pode enviar
mensagens a outro objeto.
b) No diagrama conceitual de classes, em geral, representa-se o
relacionamento entre classes usando a associao.
c) Na fase ou disciplina de projeto, devemos analisar possveis mecanismos
de herana entre as classes.
d) Na fase ou disciplina de projeto, ainda no devemos representar
relacionamento de composio entre as classes, o que somente ser
representado na implementao do cdigo.
80
e) Novos mtodos so descobertos ao modelarmos os diagramas de

interao.
Questo 4
Sobre o diagrama de sequncia, analise as assertivas a seguir.
I. O diagrama de sequncia mostra como os objetos colaboram para a
realizao de um cenrio de uso (parte de um caso de uso).
II. Toda mensagem que chega a um objeto no diagrama de sequncia
representa uma operao da classe, ou seja, um mtodo na classe que recebe
a mensagem.
III. Novos mtodos descobertos na elaborao do diagrama de sequncia
demandam atualizao frequente do diagrama de classes.

Questo 5
I. No modelo de classes de projeto podemos incluir novos atributos nas classes.
... porque...
II. No modelo conceitual de classes no representamos atributos.
81

a) As duas assertivas esto corretas, e a segunda justifica a <primeira
class=""></primeira>
Questo 6
Assinale a alternativa incorreta quanto s formas de reutilizao.
a) Padres de projeto representam reuso de solues recorrentes.
b) Biblioteca de classes representa solues em nvel de implementao.
c) Componentes representam reaproveitamento de cdigo.
d) O desenvolvimento baseado em componentes consiste na construo de
componentes que possam ser usados em diversos contextos, em
diversos sistema.
e) Padro de projeto consiste num reuso imediato e pode ser comprado de
empresas desenvolvedoras.
Questo 7
No que se refere anlise de classes, relacionamentos e atributos para constar
no diagrama de classes, analise estas assertivas:
I. O padro especialista da informao diz que a responsabilidade deve ser
atribuda classe que conhece a informao.
82
II. O padro create ajuda a descobrir os objetos que criam outros e indica
relacionamento de composio.
III. O padro acoplamento alto visa atribuir responsabilidade de forma que o
acoplamento permanea elevado.
b) Esto corretas apenas I, II e III
c) Esto corretas I, II , III e IV
d) Est correta apenas III
e) Esto corretas apenas I e II
Questo 8
Assinale a nica alternativa incorreta no que se refere ao padro create.
a) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
B agrega A de forma composta.
b) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
B registra A.
c) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
B usa A.
d) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
B contm dados iniciais de A.
e) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
A usa B.
Questo 9
Qual o problema resolvido pelo padro controlador?
83
a) Qual o primeiro objeto, alm da classe boundary (interface com

usurio), que recebe e controla uma operao do sistema?
b) Como apoiar dependncia baixa, baixo impacto de modificao e
aumento de reuso?
c) Qual o princpio bsico para atribuir responsabilidades a objetos?
d) Quem cria o objeto X?
e) Como manter os objetos inteligveis e gerenciveis?
Questo 10
I. Padres de projeto so uma forma de explicitar o conhecimento.
... porque...
II. Formaliza solues de anlise ou projeto j encontradas por profissionais
mais experientes.
Questo 1 - A
Justificativa: Anlise dos requisitos e modelagem conceitual de classes so
atividades da fase ou disciplina de projetos.
84
Questo 2 - A
Justificativa: O diagrama conceitual de classes, em geral, apresenta apenas os
nomes dos atributos; e, na fase ou disciplinas de projeto, acrescentamos
visibilidade e tipo de dados a fim de refin-lo.
Questo 3 - D
Justificativa: Na fase ou disciplinas de anlise, em geral, os relacionamentos
so representados por associaes. J no modelo de classes de projeto ou
classes de software, pode-se representar, se til for, todos os tipos de
relacionamento entre classes.
Questo 4 - B
Justificativa: I verdade; II verdade; e III verdade.
Questo 5 - D
Justificativa: O modelo RUP modela os casos de uso na disciplina de anlise e
os realiza nas disciplinas de projeto e implementao e, por esse motivo, est
Questo 6 - E
Justificativa: Padres no so concretos e no so comercializados, tal como
componentes e classes prontas.
Questo 7 - E
Justificativa: O padro chama-se acoplamento baixo e visa garantir que as
classes tenham baixo acoplamento.
Questo 8 - E
Justificativa: A responsabilidade deve ser atribuda a B, se B usa A e no o
contrrio, como diz o enunciado.
Questo 9 - A
85
Justificativa: I falso, porque devemos, por simplificao, representar apenas

as associaes.
II os atributos derivados podem ser representados, mas no h
obrigatoriedade nisso.
III verdadeiro, pois mostra as classes do domnio do problema.
IV verdade, pois so classes de software.
Questo 10 - A
Justificativa: As duas assertivas so verdadeiras, e o conhecimento contido nos
padres de projeto, detectados por profissionais mais experientes, torna-se
explcito para que novatos possam us-lo.
Introduo
Nesta aula, trataremos da arquitetura fsica do software desenvolvida sob o
paradigma da orientao a objetos, especificamente com auxilio da UML,
denominada modelo de implementao, que, por sua vez, decomposto em
dois diagramas: componentes e implantao.
O diagrama de implantao visa mostrar a arquitetura fsica dos ns (de
processamento), onde o sistema ser executado, e as conexes entre eles; ou
seja, apresenta infraestrutura, servidores e demais dispositivos necessrios ao
funcionamento do sistema.
O diagrama de componentes mostra a diviso do sistema em componentes de
software e a relao entre eles. A juno dos dois diagramas, que opcional,
permite-nos saber o poder de processamento e capacidade de memria e
discos dos ns envolvidos, na medida em que definimos componentes que
rodaro em cada um.
86
Objetivo:
1. Discriminar o diagrama de componentes e seus elementos;
2. Discriminar o diagrama de implantao e seus elementos;
3. Relacionar os diagramas de componentes e implantao;
4. Aplicar, atravs de exemplos, a construo e integrao entre os diagramas
de componentes e implantao.
Contedo
Diagramas de componentes
O que so e o que fazem?
Diagramas de componentes mostram os componentes de um sistema e

suas dependncias.
Diagramas de componentes so teis para modelagem da arquitetura

fsica de um software, apresentando os componentes fsicos, suas
interfaces e dependncias.
Os diagramas de componentes permitem o desenvolvimento baseado em

componentes, onde um software dividido em componentes e interfaces
reutilizveis e substituveis.
Imagine um sistema de home theater composto por componentes que podem

ser facilmente conectados uns aos outros e substitudos a qualquer momento:
projetor, receiver, caixas de som (frontal, lateral, subwoofer). Se qualquer
elemento queimar, poderemos substitu-lo por um igual ou equivalente (com as
mesmas interfaces).
87
A ideia do uso de componentes em software a mesma: conjunto de

componentes com interfaces bem definidas que podem ser integrados a
qualquer sistema e substitudo sempre que necessrio.
Componentes
A UML define componente como:
Um componente representa uma parte modular de um sistema que encapsula

seu contedo e cuja manifestao substituvel dentro de um ambiente. Um
componente define seu comportamento em termos de interfaces fornecidas e
requeridas. Como tal, um componente serve como um tipo, cuja conformidade
definida por essas interfaces fornecidas e requeridas.
Um componente pode ser definido como uma caixa-preta onde so
especificadas as suas interfaces para que outros componentes possam usar
seus servios sem conhecer detalhes de como esses servios esto sendo
implementados. Ou seja, o componente encapsula (protege) o seu contedo e
seu comportamento definido em funo de prover e requerer servios atravs
de suas interfaces.
88
Ateno
O desejo que o componente possa ser independente e
intercambivel.
Em um sistema baseado em componentes, cada componente
tem uma finalidade, ou seja, presta um servio e para tal
demanda o uso de outros componentes.
A imagem a seguir mostra a representao do componente na UML. O
componente tem um nome: Componente.
A ideia construir sistemas como um conjunto de componentes, que so

partes substituveis; deve-se poder reutiliz-los em muitos sistemas.
Os componentes devem ter interfaces que propiciem grande flexibilidade e
adaptao em muitos sistemas. Componentes podem, inclusive, ser criados de
outros componentes. Veja, a seguir, sobre interfaces.
Interfaces
Interfaces so elementos que definem um conjuntos de operaes que outros
elementos, como classes ou componentes, devem implementar.
Em diagramas de componentes, existem dois tipos de interfaces:
Interfaces
fornecidas:
descrevem
os
servios
oferecidos
outros
componentes. Um componente pode declarar quantas interfaces fornecidas

forem necessrias. O smbolo de uma interface fornecida o crculo
apresentado esquerda do componente, conforme imagem a seguir.
89
Interfaces requeridas: so as interfaces usadas pelo componente quando ele

solicita servios de outros componentes. Um componente pode ter vrias
interfaces requeridas. O smbolo da interface requerida um semicrculo
apresentado direita do componente, conforme imagem a seguir.
Ateno
Um mesmo componente pode tanto fornecer como requerer
interfaces. O relacionamento entre os componentes e as
interfaces a essncia dos sistemas.
Componentes e interfaces
O usurio do servio de um componente deve conhecer bem a sintaxe das
interfaces do componente. Analogamente ao exemplo dado inicialmente, as
interface so as conexes possveis entre o receiver do home theater e os
dispositivos (projetor, caixas, DVD, TV etc.).
Para usarmos um DVD precisamos saber as possveis conexes (HDMI, DVI
etc.). Para usar um componente precisamos saber as possveis interfaces.
Existem duas maneiras de representar o relacionamento entre componentes e
interface, conforme as duas imagens a seguir.
Na representao abaixo, o componente que usa a interface se conecta ao
outro componente por meio do relacionamento de dependncia.
90
O componente que fornece a interface conectado a ela pelo relacionamento

de realizao (entre o componente fornecedor e a interface). O componente
que usa a interface (componente usurio) a ela conectado pelo
relacionamento de dependncia (entre o componente usurio e a interface). O
relacionamento de dependncia determina que um componente pode usar os
servios ou depender de outro elemento do sistema.
Na imagem a seguir, temos o exemplo do componente Login Usurio, onde

<<build Component>> um esteretipo. Esse componente tem:
Duas interfaces providas, ou seja, servios prestados ao usurio (validar
usurio e validar senha);
Uma interface requerida, ou seja, servio que precisa usar (conexo).
Abaixo, tem-se um exemplo de diagrama de componentes necessrios ao

servio de caixa eletrnico (agncias bancrias e banco 24 h).
91
Gerenciador de Caixa Eletrnico: gerencia o uso e aguarda pelos eventos

dos correntistas, ao interagir com o caixa eletrnico.
Criptografia: criptografa os dados de forma que trafeguem em segurana at
os servidores da empresa.
Controlador Caixa Eletrnico: age como interface entre o caixa eletrnico e
as camadas da aplicao, residentes nos servidores, que daro a reposta a cada
solicitao do cliente.
Firewall: filtra os acessos verificando se a chamada ao Gerenciador de Contas

confivel e ocorre de acordo com os parmetros de comunicao da empresa.
Gerenciador de Contas: gerencia acessos aos dados da conta e sua
movimentao solicitando a descriptografia dos dados e identificando o que o
cliente solicitou no caixa eletrnico.
Descriptografia: responsvel por descriptografar dados criptografados na
origem deixando-os no estado original.
92
SGBD: faz o acesso base de dados, conforme solicitao do cliente.

Repare que a soluo da tela anterior permite flexibilidade em futuras
mudanas.
Se alterarmos a tcnica de criptografia ou desejarmos ampliar as
possiblidades com novas tcnicas, basta substituir ou adicionar novos
componentes de criptografia e descriptografia;
Se quisermos trocar o software de firewall, basta substituirmos o respectivo
componente;
Se mudarmos de banco de dados, basta substituirmos o componente
responsvel pelo acesso aos dados.
Diagrama de implantao
Mostra o layout fsico de um sistema, revelando quais partes do software so
executadas em quais partes do hardware (FOWLER). Enfoca a estrutura fsica
sobre a qual o software vai executar. Define como as mquinas estaro
conectadas e atravs de quais protocolos se comunicaro.
Seus elementos so os ns e as conexes entre eles.
Conexes representam um caminho de comunicao entre os ns, assim

como as associaes possuem nome e multiplicidade.
Um diagrama de implantao mostra o local onde os componentes e

artefatos so utilizados no sistema em funcionamento.
93
N
Um n, em um diagrama de implantao, representa um recurso computacional
de
um
sistema,
como
servidores,
impressoras,
terminais
remotos,
computadores pessoais, dentre outros. Em geral, o n identificado por um

nome que o descreve, conforme imagem a seguir.
Podemos
representar
em
diagramas
de
implantao
existncia
de
componentes dentro de um n, conforme exemplo abaixo.
Nesse caso, representamos a relao de dependncia entre os componentes.
Ateno
A possibilidade de representar os componentes que vo executar
em um n positiva, no sentido de possibilidade de definio da
configurao do n, tanto em termos de capacidade de
94
processamento
como
de
memria
principal
memria
secundria (discos).
Caminhos de comunicao (conexes)

Os ns em um diagrama de implantao so conectados por caminhos de
comunicao, que um relacionamento de associao no qual podem constar
multiplicidade, papel e nome do relacionamento (em geral, pelo tipo de
protocolo de comunicao). Nesse caso, a associao representa uma conexo
fsica entre os ns.
Abaixo, um exemplo de dois ns representando um sistema cliente-servidor,
onde o caminho de comunicao o protocolo TCP/IP atravs da internet.
Exemplos de diagrama de implantao

A imagem a seguir apresenta um diagrama de implantao com seus
elementos bsicos:
Ns: Tablet do Vendedor, CPU do Vendedor, CPU do Gerente, Servidor de
Aplicaes, Servidor de BD e Impressora;
Caminhos de comunicao: TCP/IP e Porta USB conectam CPU do
Vendedor e Impressora.
95
Abaixo, temos exemplo do diagrama de implantao para o sistema de caixa

eletrnico, o mesmo que elaboramos para o diagrama de componentes (nesta
aula, em seo anterior).
O refinamento do diagrama mostra os componentes que vo executar em cada

um dos ns. Repare que conhecer os componentes que cada n precisar
executar permite compreender a capacidade de cada um, tanto em termos de
processamento (processador), memria (RAM), disco e outras configuraes.
96
Ateno
Por fim, cabe ressaltar que o diagrama de implantao deve
fazer parte dos manuais para instalao e operacionalizao dos
sistemas (BEZERRA, 2015).
Referncias
BOOCH, G; RUMBAUGH, J; JACOBSON, I. UML: guia do usurio. 2. ed. Rio de
Janeiro: Campus, 2006.
BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. 3. ed.
Elsevier, 2015.
LARMAN, C. Utilizando UML e padres: uma introduo anlise e projeto
orientados a objetos e ao desenvolvimento iterativo. 3. ed. Bookman, 2007.
97
Exerccios de fixao
Questo 1
No que se refere ao diagrama de componentes, assinale a alternativa errada.
a) Mostra os componentes e sua localizao fsica em termos de ns e onde
se encontram
b) Mostra os componentes do sistema
c) Mostra as relaes entre eles
d) Apresenta as interfaces requeridas
e) Apresenta as interfaces fornecidas
Questo 2
No que se refere ao diagrama de componentes e seus elementos, assinale a
alternativa correta.
I. Uma interface fornecida apresenta os detalhes para que um componente
possa usar o servio fornecido por outro.
II. Um componente um elemento modular e substituvel.
III. Um componente s pode ter uma interface oferecida.
b) Est correta apenas II
98
Questo 3
Assinale a alternativa que apresenta o correto elemento associado ao seguinte
conceito: representa uma parte modular de um sistema que encapsula seu
contedo e cuja manifestao substituvel dentro de um ambiente.
a) Objeto
b) Interface requerida
c) Classe
d) Componente
e) Software
Questo 4
Sobre o diagrama de componentes, analise as assertivas.
I. O diagrama de componentes deve ser usado em integrao com o diagrama
de casos de uso na modelagem do domnio do problema.
II. O usurio do servio de um componente deve conhecer bem a sintaxe de
suas interfaces.
III. Os componentes podem relacionar-se por relacionamentos de dependncia.
99
Questo 5
I. O diagrama de componentes possui ao menos uma interface fornecida.
... porque...
II. Um componente deve manter-se independente e isolado dos demais.
Questo 6
Assinale a alternativa que completa a seguinte afirmativa: Segundo Fowler, o
diagrama de _____________ mostra o layout fsico de um sistema, revelando
quais partes do software so executadas em quais partes do hardware.
a) Componentes
b) Atividade
c) Pacote
d) Sequncia
e) Implantao
100
Questo 7
No que se refere ao diagrama de implantao, analise as assertivas.
I. Ns e caminhos de conexo so dois dos elementos do diagrama.
II. Os ns podem ser servidores, estaes, impressoras, mquinas leitoras de
digitais.
III. Os caminhos de comunicao sempre sero o protocolo TCP/IP, j que o
caminho sempre ser sob a internet.
b) Esto todas corretas
c) Est correta apenas III
e) Esto corretas I e III
Questo 8
Sobre os diagramas de implantao da UML (unified modeling language), teis,
especialmente, na fase de projeto de software, incorreto afirmar:
a) direcionado para a distribuio, entrega e instalao das partes que
formam o sistema fsico.
b) um conjunto de ns conectados, no qual um n nica e
exclusivamente uma estao ou servidor.
c) Envolvem a topologia do sistema, descrevendo a estrutura do hardware.
d) Pode ser integrado ao diagrama de componentes, mostrando que
componentes executam em que n.
101
Questo 9
A UML uma linguagem que possibilita a modelagem nas diversas fases de um
processo de desenvolvimento de software. Na fase de projeto, definidos a
arquitetura e componentes do software, ganham destaque os diagramas de
componentes e de implantao. Com base nesses dois diagramas, analise as
assertivas a seguir.
I. O diagrama de implantao modela os aspectos fsicos do sistema,
mostrando a organizao do hardware.
II. O diagrama de componentes mostra as dependncias entre os elementos do
hardware que sustentaro o software.
III. O ideal que um componente desenvolvido possa ser usado em vrios
sistemas.
Assinale a nica opo correta, com base em sua anlise das assertivas.
a) Apenas as assertivas I e III esto corretas
b) Apenas a assertiva III est correta
c) Apenas a assertiva I est correta
d) Apenas as assertivas I e II esto corretas
e) Apenas as assertivas II e III esto corretas
Questo 10
Um diagrama de implantao define aspectos fsicos do sistema, onde cada n
representa
um
dispositivo
fsico
com
memria
ou
capacidade
de
processamento. J o diagrama de componentes apresenta mdulos de software

(arquivos .dll, .exe, .com, .bat, .htm e outros executveis) necessrios para
executar a aplicao. Com base nesse contexto apresentado, responda:
a) possvel integrar esses dois diagramas mostrando para cada n os
componentes que nele executariam?
102
b) Caso a resposta seja sim, explique a vantagem em integrarmos os dois

diagramas dessa forma?
Questo 1 - A
Justificativa: O diagrama que mostra a localizao fsica o diagrama de
implantao. O diagrama de componentes mostra os componentes, o
relacionamento entre eles e suas interfaces.
Questo 2 - B
Justificativa: I falsa, pois uma interface fornecida descreve os servios
oferecidos a outros componentes;
II verdade;
III falso, pois um componente pode ter tantas interfaces quantas forem
necessrias.
Questo 3 - D
Justificativa: Esse o conceito de componente, a ideia de sistemas baseados
em componentes e integrao entre eles atravs de interfaces bem definidas.
Questo 4 - D
Justificativa: I falso, pois diagramas de componentes descrevem a arquitetura
do software e suas partes, que so os componentes;
II verdade; e
III verdade.
Questo 5 - D
Justificativa: I verdade;
II falsa, pois um componente deve integrar-se aos demais, sendo usurio do
servio de outros e/ou oferendo servio aos outros.
103
Questo 6 - E
Justificativa: o diagrama de implantao que mostra o layout fsico do
ambiente onde o sistema vai executar.
Questo 7 - D
II verdade;
III falsa, pois nem todo caminho de comunicao ser sob o protocolo
TCP/IP, e nem todo caminho ser sob a internet. Por exemplo, entre um
computador e uma impressora poder ser o caminho Porta USB.
Questo 8 - B
Justificativa: Muitos outros elementos podem ser n, cujo conceito um
recurso computacional de um sistema.
Questo 9 - A
II falsa, pois o diagrama de componentes mostra apenas dependncia de
software;
III verdade, pois essa a essncia de um componente.
Questo 10 - A
Justificativa: 1. Sim, possvel.
2. Seria til para conhecermos as demandas de processamento do software que
rodaro em cada n e, assim, definirmos a capacidade de processamento,
memria e disco de cada n.
104
Marcelo Vasques de Oliveira graduado em Processamento de dados pela

Pontifcia Universidade Catlica do Rio de Janeiro (1989). Bacharel em
Administrao de Empresas pela Universidade Estcio S (2014). Mestre em
Computao Aplicada e Automao pela Universidade Federal Fluminense
(2003).
Coordenador e Professor do curso de Bacharelado em Sistemas de
Informao EAD da Universidade Estcio de S. Coordenador e professor do

curso de Ps Graduao em Engenharia de Software EAD da Universidade
Estcio de S. Professor dos cursos de CST em Gesto de Tecnologia da
Informao, CST em Anlise e Desenvolvimento de Sistemas, CST em Jogos
Digitais e CST em Redes de Computadores tanto no ensino presencial como no
ensino a distncia. Professor do curso de Ps Graduao (especializao) em
Anlise Projeto e Desenvolvimento de Sistemas, na modalidade presencial e do
curso de Comunicao em Mdias Digitais e Marketing em Mdias Digitais na
modalidade a distncia. Diretor de TI em empresa privada na rea de Protesto
de Ttulos. Experincia em gesto de tecnologia e desenvolvimento de software
para empresas privadas. reas de interesse: Sistemas de Informao,
Desenvolvimento de Sistemas, Programao de Computadores, Banco de Dados
e Educao a distncia.
Currculo Lattes: http://lattes.cnpq.br/8301437147999898
105

Análise Orientada A Objetos

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Análise Orientada A Objetos

Enviado por

Direitos autorais:

Formatos disponíveis

Apresentao ................................................................................................................................

Aula 02: Projeto da Arquitetura Lgica e Modelo MVC .............................................................. 32

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

Derivando Classes Conceituais dos Casos de uso .................................................... 44

Aula 05: Projeto de Software Orientado a Objeto ...................................................................... 58

LOW COUPLING, CONTROLLER e HIGH COHESION .............................................. 78

Aula 06: Implementao e Arquitetura do Software .................................................................. 86

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

O desenvolvimento de sistemas requer um conjunto de atividades, dispostas

Modelling Languagem), com seus diagramas em suas diferentes perspectivas,

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

Os diagramas UML desenvolvidos na fase de Anlise so revistos e refinados na

software, ou seja quais so seus subsistemas e partes e como essas se

software, o que inclui: princpios de coeso e acoplamento, padres de projeto,

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

7. Apresentar dois novos diagramas da UML: diagrama de componentes e de

software orientado a objetos, disponibiliza diagramas a serem empregados em

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

1. Fundamentar as principais caractersticas e os pilares do paradigma

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

principalmente com os casos de uso e as classes do domnio do problema e

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

UML: diferentes perspectivas

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

refinado com a insero dos relacionamentos entre as classes,

Processos iterativos e incrementais

O ciclo de vida iterativo baseado em incrementos sucessivos do sistema, pelas

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

A grande questo dos processos iterativos que neles no se pensam e nem se

Programming), o SCRUM, dentre outros. Programao e testes tm incio

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

RUP (Rational Unified Process)

software que visa ao desenvolvimento orientado a objeto e que baseado na

desenvolvimento de software com qualidade, controlando os recursos ao longo

software. Dentre suas principais caractersticas, destacam-se:

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

As fases so segmentadas em iteraes;

A imagem exibida ilustra a diviso do RUP em fases, iteraes e disciplinas. A

acompanhamento de cada iterao.

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

recursos humanos, materiais e referentes ao tempo) e, sobretudo,

operacional, tecnolgica e de cronograma) do projeto

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

a. Treinamento dos usurios (opcional, conforme contrato de

A cada iterao do RUP, poderemos observar:

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

O RUP traz, ainda, o conceito de disciplina que agrupa atividades afins,

software: modelagem de negcio, requisitos, projeto, implemetao, testes e

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

Especificao do comportamento do sistema, que demanda colaboraes

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

negcio carregassem na mquina do cliente. A arquitetura de trs camadas

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL

Atualmente, o desenvolvimento pode demandar uma arquitetura de N

Podemos segmentar a camada de aplicao em mais de 1

Podemos dividir a camada de dados;

Podemos dividir a camada de lgica de negcio, separando uma

Cabe ressaltar que sistemas pequenos no precisam ser desenvolvidos em

Arquitetura MVC (model, view and controller)

ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL