Notas Aula Projeto Sistemas 5

UFES - Universidade Federal do Esprito Santo
Projeto de Sistemas de
Software
Notas de Aula
Ricardo de Almeida Falbo

E-mail: falbo@inf.ufes.br
2015
ndice
Captulo 1 - Introduo
1.1 A Fase de Projeto

1.2 A Organizao deste Texto
2
4
Captulo 2 O Projeto de Software
2.1 Princpios de Projeto

2.2 Qualidade do Projeto de Software
2.3 Projeto e Atributos de Qualidade
2.4 Projeto de Software e Padres (Patterns)
2.5 Documentao de Projeto
Captulo 3 Arquitetura de Software
3.1 O que uma Arquitetura de Software
3.2 Classes de Sistemas
3.3 Estilos Arquitetnicos
3.4 Padres Arquitetnicos para Projeto de Sistemas de Informao
3.5 Projeto de Sistemas de Informao Distribudos
3.6 Aplicaes Web e Tecnologias Relacionadas
3.7 Tticas para Tratar Atributos de Qualidade
3.8 O Processo de Projeto de Software
3.9 Detalhando os Componentes da Arquitetura de Software
Captulo 4 Projeto da Lgica de Negcio
4.1 Diagramas de Interao
4.2 Padres Arquitetnicos para o Projeto da Lgica de Negcio
4.3 Projeto da Lgica de Domnio do Problema
4.4 Projeto da Lgica de Aplicao
Captulo 5 Projeto da Interface com o Usurio
5.1 O Padro ModeloVisoControlador
5.2 O Processo de Projeto da Interface com o Usurio
5.3 Projeto da Viso
5.4 Projeto do Controle de Interao
5.5 Design Patterns no Projeto da Interface com o Usurio
Captulo 6 Projeto da Gerncia de Dados
6.1 O Modelo Relacional
6.2 Mapeamento Objeto-Relacional
6.3 Padres Arquitetnicos para o Projeto da Camada de Gerncia de Dados
6.4 Frameworks de Persistncia
6
9
11
17
18
21
21
25
28
31
34
41
50
58
60
66
67
70
72
75
82
83
85
87
93
94
97
98
101
105
107
Captulo 7 Projeto de Classes e Avaliao da Qualidade do Projeto de Software 110

7.1 Projetando Atributos e Associaes
7.2 Projetando Mtodos
7.3 Avaliando a Qualidade do Documento de Projeto
Anexo A Padres de Projeto
A.1 O Catlogo de Gamma et al. (1995)
110
111
112
115
116
Projeto de Sistemas de Software: Notas de Aula

Captulo 1 Introduo
O desenvolvimento de software um processo que envolve atividades tcnicas,
gerenciais e de garantia da qualidade. No que concerne s atividades tcnicas,
tipicamente o processo de software inicia-se com o Levantamento de Requisitos,
quando os requisitos do sistema a ser desenvolvido so preliminarmente capturados e
organizados. Uma vez capturados, os requisitos devem ser modelados, avaliados e
documentados. A Modelagem Conceitual uma atividade essencial no processo de
Engenharia de Requisitos e cuida da elaborao de modelos descrevendo o qu o
software tem de fazer (e no como faz-lo). At este momento, a nfase est sobre o
domnio do problema e no se deve pensar na soluo tcnica, computacional, a ser
adotada.
Os requisitos podem ser funcionais ou no funcionais. Requisitos funcionais,
como o prprio nome indica, apontam as funes que o sistema deve prover e como o
sistema deve se comportar em determinadas situaes. J os requisitos no funcionais
descrevem restries sobre as funes a serem providas, restries essas que limitam as
opes para criar uma soluo para o problema, tais como restries de tempo e de
recursos, ou restries s quais o sistema como um todo (ou mesmo o projeto de
desenvolvimento) est sujeito. H, ainda, as regras de negcio, as quais so derivadas
do domnio de aplicao e podem restringir requisitos funcionais existentes ou
estabelecer como clculos especficos devem ser realizados, refletindo fundamentos do
domnio de aplicao.
Com os requisitos pelo menos parcialmente capturados e especificados na forma
de modelos, pode-se comear a trabalhar no domnio da soluo. Muitas solues so
possveis para o mesmo conjunto de requisitos e elas so intrinsecamente ligadas a uma
dada plataforma de implementao (linguagem de programao, mecanismo de
persistncia a ser adotado etc). Alm disso, requisitos no funcionais so, muitas vezes,
conflitantes e a escolha de quais atributos de qualidade sero mais atentamente
considerados tem tambm um forte impacto na escolha da soluo. Assim, ao se
considerar alternativas de soluo, todos esses aspectos tm de ser levados em conta.
A fase de projeto tem por objetivo definir e especificar uma soluo a ser
implementada. uma fase de tomada de deciso, tendo em vista que muitas solues
so possveis. Alm disso, o projeto um processo de refinamento. Inicia-se com o
projeto da arquitetura do sistema, que visa descrever a estrutura de nvel mais alto da
aplicao, identificando seus principais elementos ou componentes1 e como eles se
relacionam uns com os outros. Uma vez definida a arquitetura, o projeto passa a se
1
Grande parte dos trabalhos na literatura trata os blocos primrios de construo de uma arquitetura de
software como componentes. Contudo, conforme apontam Bass, Clements e Kazman (2003), este
termo vem sendo cada vez mais estreitamente associado ao movimento de Desenvolvimento Baseado em
Componentes DBC (GIMENES; HUZITA, 2005), onde assume uma conotao mais restrita. Assim,
neste texto procura-se utilizar o termo elemento para atribuir um carter mais geral. Quando usado, o
termo componente tem tambm essa concepo mais geral, tendo em vista que este texto no aborda
diretamente o DBC.

concentrar no detalhamento de cada um desses elementos, at atingir o nvel de

unidades de implementao (p.ex., classes no desenvolvimento orientado a objetos).
Uma vez especificado o projeto dos elementos da arquitetura, pode dar-se incio
implementao, quando as unidades de software do projeto detalhado so
implementadas e testadas individualmente. Gradativamente, os elementos vo sendo
integrados e testados (teste de integrao), at se obter o sistema, quando o todo deve
ser testado (teste de sistema).
Por fim, uma vez testado no ambiente de desenvolvimento, o software pode ser
colocado em produo. Usurios devem ser treinados, o ambiente de produo deve ser
configurado e o sistema deve ser instalado e testado, agora pelos usurios no ambiente
de produo (testes de homologao ou aceitao). Caso o software demonstre prover as
capacidades requeridas, ele pode ser aceito e a operao iniciada.
Este texto aborda a fase de projeto, concentrando-se no projeto de software.
1.1 A Fase de Projeto

O objetivo da fase de projeto (ou design) produzir uma soluo para o
problema identificado e modelado nas fases de levantamento e anlise de requisitos,
incorporando a tecnologia aos requisitos e projetando o que ser construdo na
implementao. Sendo assim, necessrio conhecer a tecnologia disponvel e os
ambientes de hardware e software onde o sistema ser desenvolvido e implantado.
Durante o projeto, deve-se decidir como o problema ser resolvido, comeando em um
alto nvel de abstrao, prximo da anlise, e progredindo sucessivamente para nveis
mais detalhados at se chegar a um nvel de abstrao prximo da implementao.
O projeto de software encontra-se no ncleo tcnico do processo de
desenvolvimento de software e aplicado independentemente do modelo de ciclo de
vida e paradigma adotados. iniciado assim que os requisitos do software tiverem sido
modelados e especificados pelo menos parcialmente e a ltima atividade de
modelagem. Por outro lado, corresponde primeira atividade que leva em conta
aspectos tecnolgicos (PRESSMAN, 2006).
Enquanto a fase de anlise pressupe que a tecnologia perfeita (capacidade
ilimitada de processamento, com velocidade instantnea, capacidade ilimitada de
armazenamento, custo zero e no passvel de falha), a fase de projeto envolve a
modelagem de como o sistema ser implementado com a adio dos requisitos
tecnolgicos e de carter no funcional. Assim, como bem disse Mitch Kapor, citado
por Pressman (2006), o projeto onde voc se instala com um p em dois mundos o
mundo da tecnologia e o mundo das pessoas e objetivos humanos e voc tenta juntar
os dois. A Figura 1.1 procura ilustrar esta situao. O projeto , portanto, a fase do
processo de software na qual os requisitos, as necessidades do negcio e as
consideraes tcnicas se juntam na formulao de um produto ou sistema de software
(PRESSMAN, 2006).

Domnio do
Problema
Mundo Real
Anlise e
Especificao
de Requisitos
(o qu)
Projeto
(como)
Domnio da
Soluo
Mundo
Computacional
Implementao
Figura 1.1 A Fase de Projeto

Conforme mencionado anteriormente, o projeto um processo de refinamento.
Inicialmente, o projeto representado em um nvel alto de abstrao, enfocando a
estrutura geral do sistema. Definida a arquitetura, o projeto passa a tratar do
detalhamento de seus elementos. Esses refinamentos conduzem a representaes de
menores nveis de abstrao, at se chegar ao projeto de algoritmos e estruturas de
dados. Assim, independentemente do paradigma adotado, o processo de projeto envolve
as seguintes atividades:
Projeto da Arquitetura do Software: visa definir os elementos estruturais do

software e seus relacionamentos.
Projeto dos Elementos da Arquitetura: visa projetar em um maior nvel de

detalhes cada um dos elementos estruturais definidos na arquitetura, o que
envolve a decomposio de mdulos em outros mdulos menores.
Projeto Detalhado: tem por objetivo refinar e detalhar os elementos mais

bsicos da arquitetura do software: as interfaces, os procedimentos e as
estruturas de dados. Deve-se descrever como se dar a comunicao entre os
elementos da arquitetura (interfaces internas), a comunicao do sistema em
desenvolvimento com outros sistemas (interfaces externas) e com as pessoas
que vo utiliz-lo (interface com o usurio), bem como se devem projetar
detalhes de algoritmos e estruturas de dados.
Tendo em vista que a orientao a objetos um dos paradigmas mais utilizados

atualmente no desenvolvimento de sistemas, este texto aborda o projeto de software
orientado a objetos. Alm disso, o foco deste texto so os sistemas de informao.
Considerando essa classe de sistemas, de maneira geral, os seguintes elementos esto
presentes na arquitetura de um sistema:

Lgica de Negcio: o elemento da arquitetura que trata da lgica de

negcio apoiada pelo sistema, englobando tanto aspectos estruturais (classes
de domnio derivadas dos modelos conceituais estruturais da fase de anlise),
quanto comportamentais (classes de lgica de aplicao, que tratam das
funcionalidades descritas pelos casos de uso).
Interface com o Usurio: o elemento da arquitetura que trata da interao

humano-computador. Envolve tanto as interfaces propriamente ditas (objetos
grficos responsveis por receber dados e comandos do usurio e apresentar
resultados), quanto o controle da interao, abrindo e fechando janelas,
habilitando ou desabilitando botes etc (WAZLAWICK, 2004).
Persistncia: o elemento da arquitetura responsvel pelo armazenamento e

recuperao de dados em memria secundria (classes que representam e
isolam os depsitos de dados do restante do sistema).
Esses elementos so os principais elementos discutidos neste texto.
1.2 A Organizao deste Texto

Este texto procura oferecer uma viso geral do Projeto de Software, discutindo
as principais atividades desse processo e como realiz-las. Nos captulos que se seguem,
os seguintes temas so abordados:
Captulo 2 O Projeto de Software: discute princpios gerais de projeto e

como eles se aplicam ao projeto de software, caractersticas de um bom
projeto de software, atributos de qualidade de software que devem ser
considerados no projeto de software, reutilizao no projeto de software por
meio de padres (patterns) e a documentao do projeto de software.
Captulo 3 Arquitetura de Software: define o que arquitetura de software,

apresenta alguns padres arquitetnicos, discute o impacto de atributos de
qualidade no projeto da arquitetura e tticas para trat-los, bem como aborda
a documentao da arquitetura de software.
Captulo 4 Projeto da Lgica de Negcio: concerne ao projeto dos

elementos da arquitetura que tratam da lgica de negcio apoiada pelo
sistema. Dois componentes principais so abordados neste captulo: o
Componente de Domnio do Problema, que se refere aos elementos
responsveis por tratar diretamente as informaes relevantes, capturadas na
modelagem estrutural da fase de anlise, e o Componente de Gerncia de
Tarefas, que concerne aos elementos responsveis por tratar as
funcionalidades descritas pelos casos de uso, modelados e descritos na fase
de especificao de requisitos.
Captulo 5 Projeto da Interface com o Usurio: aborda o projeto da

interface do sistema computacional com seus usurios. Dois componentes
principais so discutidos neste captulo: o Componente de Apresentao (ou
Viso), que se refere s interfaces propriamente ditas (objetos grficos
responsveis por receber dados e comandos do usurio e apresentar
resultados), e o Componente de Controle de Interao, que diz respeito ao

controle da interao com o usurio, envolvendo aspectos relacionados

ativao de comandos, controle e sequncia da interao.
Captulo 6 Projeto da Persistncia: trata do armazenamento e recuperao

de dados em um mecanismo de persistncia. Como os bancos de dados
relacionais so atualmente o principal mecanismo de persistncia utilizado
no desenvolvimento de sistemas de informao, este captulo apresenta
brevemente o Modelo Relacional, discutindo questes relativas ao
mapeamento objeto-relacional. Alm disso, abordado tambm o uso de
frameworks de mapeamento objeto-relacional no projeto da persistncia. O
captulo encerra com o projeto do Componente de Gerncia de Dados,
responsvel por isolar o mecanismo de persistncia dos demais elementos da
arquitetura do sistema.
Captulo 7 Projeto de Classes e Avaliao da Qualidade do Projeto de

Software: discute o projeto detalhado de classes, seus atributos, associaes e
mtodos, bem como aspectos relacionados avaliao da qualidade do
projeto de software.
Alm dos captulos anteriormente citados, este texto contm, ainda, um anexo:
Anexo A Padres de Projeto: apresenta alguns padres de projeto (design

patterns) propostos por Gamma et al. (1995).
Referncias do Captulo
BASS, L., CLEMENTS, P., KAZMAN, R., Software Architecture in Practice, Second
edition, Addison Wesley, 2003.
GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J.M., Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
GIMENES, I. M. S., HUZITA, E. H. M., Desenvolvimento Baseado em Componentes:
Conceitos e Tcnicas, Cincia Moderna, 2006.
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, Prentice Hall, 2 edio,
2004.
PRESSMAN, R.S., Engenharia de Software, McGraw-Hill, 6 edio, 2006.
WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a
Objetos, Elsevier, 2004.


O projeto o processo criativo de transformar uma especificao de um
problema em uma especificao de uma soluo. No projeto de software utilizam-se a
especificao e os modelos de requisitos gerados na fase de anlise e especificao de
requisitos. A partir dos requisitos, muitas solues so possveis e, portanto, muitos
projetos diferentes podem ser produzidos. Uma soluo considerada adequada ao
problema, se ela satisfizer a todos os requisitos especificados (PFLEEGER, 2004).
Assim, o projeto tambm uma atividade de tomada de deciso. Em suma, aps ter
analisado o problema, pode-se decidir como projetar uma soluo.
Em funo das limitaes da tecnologia e outras restries, vrias decises
devem ser tomadas de modo a tratar requisitos no funcionais. A tecnologia passvel
de falhas e muitos so os impactos de sua imperfeio, tais como necessidade de uso de
diferentes processadores, necessidade de distribuio e comunicao, necessidade de
redundncia (i.e., repetio de dados e atividades, e incluso de dados derivados, tais
como totalizadores) e necessidade de incluso de novas atividades e funes, acrescidas
em funo de requisitos no funcionais (p.ex., funes de autenticao e autorizao,
requeridas por motivo de segurana contra acessos indevidos).
Este captulo discute princpios gerais de projeto e a importncia dos requisitos
no funcionais nessa fase do processo de desenvolvimento de software. A Seo 2.1
discute princpios gerais de projeto e sua aplicao ao projeto de software. A Seo 2.2
aborda caractersticas de qualidade de um bom projeto de software. A Seo 2.3 trata da
estreita relao entre o projeto e os requisitos no funcionais que definem atributos de
qualidade para o sistema em desenvolvimento. A Seo 2.4 introduz o tema reutilizao
no projeto de software, com destaque para os padres (patterns). Finalmente, a Seo
2.5 trata da documentao das atividades do projeto de software.
2.1 Princpios de Projeto

Seja o exemplo do projeto de uma casa. Obviamente, a construo de uma casa
comea com o levantamento dos requisitos do dono da casa, o que inclui, dentre outros,
a definio do nmero e tipo dos cmodos (quartos, salas, banheiros etc), tipos de
servios a serem providos (p.ex., haver um sistema central de ar condicionado? Haver
um sistema de aquecimento solar?), estilo da casa (rstico, moderno) etc. Restries
tambm devem ser levantadas, dentre elas: custos e prazos, rea disponvel para a
construo, acessibilidade (p.ex., a casa pode ter mais de um pavimento?), restries
legais (p.ex., legislao vigente do Plano Diretor Urbano) etc.
Projetar uma casa prover uma soluo para o problema colocado, procurando
satisfazer os requisitos do dono da casa (o cliente) e as restries levantadas. Muitos
projetos so possveis. Arquitetos diferentes (ou at o mesmo arquiteto) daro solues
diferentes e o cliente escolher aquela que melhor satisfizer a todos os requisitos
especificados, incluindo as restries.

Assim, de maneira geral, um projeto deve:
considerar abordagens alternativas com base nos requisitos do problema,

restries e conceitos de projeto;
ser rastrevel sua especificao;
no reinventar a roda, isto , reutilizar solues;
exibir uniformidade (estilo) e integrao (interfaces bem definidas entre

componentes da coisa a ser construda);
ser estruturado para acomodar mudanas;
ser passvel de avaliao da qualidade;
ser revisado para minimizar erros.
Alm disso, em geral, um modelo de projeto deve:
prover uma viso da totalidade da coisa a ser construda;
decompor o todo em partes e prover diferentes vises da coisa;
refinar e descrever com mais detalhes cada parte ou viso da coisa, de modo
a prover orientao para a construo de cada detalhe.
No exemplo do projeto de uma casa, plantas baixas e maquetes (ou desenhos em

trs dimenses) podem ser usadas para prover uma viso geral da casa, segundo
perspectivas diferentes, interna e externa, respectivamente. O todo pode ser decomposto
em partes e modelos especficos podem ser construdos, como plantas baixas para o
primeiro piso e para o segundo piso. Diferentes vises podem ser trabalhadas, tais como
um projeto tratando apenas do sistema eltrico da casa e outro tratando do sistema
hidrulico. Por fim, informaes mais detalhadas devem ser providas para cada parte ou
viso da casa, tal como o clculo estrutural para a fundao (lajes, colunas etc) ou o
detalhamento do projeto eltrico, contendo informaes sobre a fiao, dutos etc.
As caractersticas citadas anteriormente valem tanto para o projeto de uma casa,
quanto para o projeto de um sistema de software. Colocando-os de forma mais
especfica, o projeto de software deve:
considerar abordagens alternativas com base nos requisitos (funcionais e no

funcionais) e conceitos de projeto de software;
estar relacionado aos modelos de anlise e especificao de requisitos e

deve ser a eles rastreado;
no reinventar a roda, isto , reutilizar componentes, frameworks, padres

e outras solues que se mostraram eficazes em outros projetos, sobretudo
aqueles similares ao sistema em desenvolvimento;
exibir uniformidade (estilo) e integrao (interfaces entre componentes);
ser estruturado para acomodar mudanas (alterabilidade);
ser passvel de avaliao da qualidade;
ser revisado para minimizar erros.

Alm disso, o projeto de software deve:
minimizar a distncia conceitual e semntica entre o software e o mundo

real. Os modelos de projeto devem ser facilmente compreensveis, tendo em
vista que seu propsito comunicar informaes para profissionais
responsveis pela codificao, teste e manuteno;
acomodar circunstncias no usuais. Se necessrio abortar o processamento,

faz-lo de modo elegante;
apresentar nvel de abstrao superior ao cdigo fonte, afinal, projeto no

codificao.
Por fim, modelos de projeto tambm devem ser construdos com o objetivo de
prover uma viso geral do sistema a ser construdo, bem como uma variedade de vises
mais especficas de seus elementos, de modo a guiar a implementao. Um modelo da
arquitetura do sistema pode ser usado para prover uma viso geral da organizao do
sistema. Modelos especficos podem detalhar os diversos elementos da arquitetura.
Diferentes diagramas podem ser usados para prover diferentes vises desses elementos,
tais como diagramas de classes para uma viso estrutural e diagramas de sequncia para
uma viso comportamental. Por fim, devem-se projetar as classes que compem cada
um dos elementos da arquitetura, definindo detalhes de como implementar atributos,
associaes e mtodos.
Alm dos princpios gerais de projeto, Hooker (1996, apud PRESSMAN, 2006)
enumera sete princpios gerais da Engenharia de Software que se aplicam tambm ao
projeto de software. So eles:
Um sistema de software existe para fornecer valor aos clientes e usurios.

Todas as decises, inclusive as de projeto, devem ser tomadas tendo isso em
mente.
Todo projeto de software deve ser to simples quanto possvel, sem, no

entanto, descartar caractersticas de qualidade importantes em nome da
simplicidade.
O comprometimento com a viso arquitetural do sistema essencial para o

sucesso do projeto de software.
Os modelos elaborados na fase de projeto sero usados posteriormente por

desenvolvedores responsveis pela implementao, teste e manuteno do
sistema. Assim, esses modelos devem ser claros, no ambguos e fceis de
entender.
Um sistema com um longo tempo de vida tem mais valor. Contudo, para ter
vida longa, um sistema deve ser projetado para acomodar mudanas.
A reutilizao pode ajudar a poupar tempo e esforo, bem como aumentar a

qualidade do sistema em desenvolvimento. Para conseguir um bom nvel de
reutilizao, necessrio planejar o reso com antecedncia. Na fase de
projeto, padres arquitetnicos e padres de projeto detalhado (design
patterns) so bastante maduros e documentados. Conhec-los e comunicar
essas e outras oportunidades de reso para os membros da organizao
vital.

Raciocinar clara e completamente antes de realizar uma ao quase sempre

produz melhores resultados. Aprender com os erros tambm importante.
Assim, ao raciocinar sobre uma deciso de projeto, solues anteriores
devem ser pesquisadas.
Por fim, uma vez que a fase de projeto essencialmente uma atividade de
modelagem, princpios da modelagem gil (AMBLER, 2004) tambm se aplicam.
Dentre eles, merecem destaque:
Seja econmico. No crie mais modelos do que voc precisa. Seja capaz de
declarar um objetivo para cada modelo criado.
Procure produzir modelos mais simples.
Construa modelos de modo que sejam passveis de mudanas.
Obtenha feedback to logo quanto possvel.
2.2 Qualidade do Projeto de Software

Um bom projeto de software de qualidade deve apresentar determinadas
caractersticas de qualidade, tais como facilidade de entendimento, facilidade de
implementao, facilidade de realizao de testes, facilidade de modificao e traduo
correta das especificaes de requisitos e de anlise (PFLEEGER, 2004). Para se obter
bons projetos, necessrio considerar alguns aspectos intimamente relacionados com a
qualidade de projeto (design), dentre eles (PRESSMAN, 2006):
Nveis de Abstrao: a abstrao um dos modos fundamentais pelos quais os

seres humanos enfrentam a complexidade. Assim, um bom projeto deve
considerar vrios nveis de abstrao, comeando com em um nvel mais alto,
prximo da fase de anlise. medida que se avana no processo de projeto, o
nvel de abstrao deve ser reduzido. Dito de outra maneira, o projeto deve ser
um processo de refinamento, no qual o projeto vai sendo conduzido de nveis
mais altos para nveis mais baixos de abstrao.
Modularidade: um bom projeto deve estruturar um sistema como mdulos ou

componentes coesos e fracamente acoplados. A modularidade o atributo
individual que permite a um projeto de sistema ser intelectualmente gerencivel.
A estratgia dividir para conquistar reconhecidamente til no projeto de
software, pois mais fcil resolver um problema complexo quando o mesmo
dividido em partes menores e, por conseguinte, mais facilmente gerenciveis.
Ocultao de Informaes: o conceito de modularidade leva o projetista a uma

questo fundamental: at que nvel a decomposio deve ser aplicada? Em
outras palavras, quo modular deve ser o software? O princpio da ocultao de
informaes sugere que os mdulos / componentes sejam caracterizados pelas
decises de projeto que cada um deles esconde dos demais. Mdulos devem ser
projetados e especificados de modo que as informaes neles contidas (dados e
algoritmos) sejam inacessveis a outros mdulos, sendo necessrio conhecer
apenas a sua interface. Ou seja, a ocultao de informao trabalha
encapsulando detalhes que provavelmente sero alterados de forma
independente, em mdulos distintos. A interface de um mdulo revela apenas

10
aqueles aspectos considerados improvveis de mudar (BASS; CLEMENTS;

KAZMAN, 2003).
Independncia Funcional: a independncia funcional uma decorrncia direta

da modularidade e dos conceitos de abstrao e ocultao de informaes. Ela
obtida pelo desenvolvimento de mdulos com finalidade nica e pequena
interao com outros mdulos. Isto , mdulos devem cumprir uma funo bem
estabelecida, minimizando interaes com outros mdulos. Mdulos
funcionalmente independentes so mais fceis de entender, desenvolver, testar e
alterar. Efeitos colaterais causados pela modificao de um mdulo so
limitados e, por conseguinte, a propagao de erros reduzida. A independncia
funcional pode ser avaliada usando dois critrios de qualidade: coeso e
acoplamento. A coeso se refere s relao entre as responsabilidades atribudas
a um mdulo. Uma classe, p.ex., dita coesa quando tem um conjunto pequeno
e focado de responsabilidades e aplica seus atributos e mtodos especificamente
para implementar essas responsabilidades. J o acoplamento diz respeito ao grau
de interdependncia entre dois mdulos. O objetivo minimizar o acoplamento,
isto , tornar os mdulos to independentes quanto possvel. Idealmente, classes
de projeto em um subsistema deveriam ter conhecimento limitado de classes de
outros subsistemas. Coeso e acoplamento so interdependentes e, portanto, uma
boa coeso deve conduzir a um pequeno acoplamento. A Figura 2.1 procura
ilustrar este fato.
Fbrica de
Refrigerantes
Baixa Coeso
Alto
Acoplamento
Vila Velha
Conjunto
Habitacional da
Siderrgica
Fbrica de
Refrigerantes
Serra
Trfego Intenso
Fbrica de
Garrafas
Plsticas
Alta Coeso
Baixo
Acoplamento
Vila Velha
Fbrica de
Garrafas
Plsticas
Siderrgica
Siderrgica
Serra
Pouco Trfego
Figura 2.1 Coeso e Acoplamento
Conjunto
Habitacional
da Siderrgica

11
2.3 Projeto e Atributos de Qualidade

Conforme citado anteriormente, a fase de projeto responsvel por incorporar
requisitos tecnolgicos aos requisitos essenciais. Assim, o projetista deve estar atento
aos critrios de qualidade que o sistema ter de atender. As consideraes de negcio
determinam as caractersticas de qualidade que devem ser acomodadas em um sistema.
Essas caractersticas de qualidade vo alm das funcionalidades, ainda que estejam
fortemente relacionadas a elas. De fato, funcionalidades e atributos de qualidade so
ortogonais. Muitos sistemas so reconstrudos no porque so funcionalmente
deficientes (os substitutos so frequentemente idnticos funcionalmente aos sistemas
antigos), mas sim porque so difceis de manter, portar, escalar ou porque so muito
lentos ou inseguros (BASS; CLEMENTS; KAZMAN, 2003). Isso mostra a importncia
de considerar atentamente os requisitos no funcionais durante a fase de projeto,
incorporando-os, j no incio do projeto, arquitetura do sistema.
So muitos os atributos de qualidade que potencialmente podem ser importantes
para um sistema. Por exemplo, o modelo de qualidade de produtos de software definido
na norma ISO/IEC 25010, utilizado como referncia para a avaliao de produtos de
software, define oito caractersticas de qualidade para produtos de software,
desdobradas em subcaractersticas (ISO/IEC, 2011):
Adequao Funcional: grau em que o produto prov funes que satisfazem s

necessidades explcitas e implcitas, quando usado em condies especificadas.
Inclui subcaractersticas que evidenciam a existncia de um conjunto de funes
e suas propriedades especficas, a saber:
Completude Funcional: capacidade do produto de software de prover um
conjunto apropriado de funes para tarefas e objetivos do usurio
especificados. Refere-se s necessidades declaradas. Um produto no qual
falte alguma funo requerida no apresenta este atributo de qualidade.
Correo Funcional (ou Acurcia): grau em que o produto de software
fornece resultados corretos e precisos, conforme acordado. Um produto
que apresente dados incorretos, ou com a preciso abaixo dos limites
definidos como tolerveis, no apresenta este atributo de qualidade.
Aptido Funcional: capacidade do produto de software de facilitar a
realizao das tarefas e objetivos do usurio. Refere-se s necessidades
implcitas.
Confiabilidade: grau em que o produto executa as funes especificadas com um

comportamento consistente com o esperado, por um perodo de tempo. A
confiabilidade est relacionada com os defeitos que um produto apresenta e
como este produto se comporta em situaes consideradas fora do normal. Suas
subcaractersticas so:
Maturidade: uma medida da frequncia com que o produto de software
apresenta defeitos ao longo de um perodo estabelecido de tempo.
Refere-se, portanto, capacidade do produto de software de evitar falhas
decorrentes de defeitos no software, mantendo sua operao normal ao
longo do tempo.

12
Disponibilidade: capacidade do produto de software de estar operacional

e acessvel quando seu uso for requerido.
Tolerncia a falhas: capacidade do produto de software de operar em um
nvel de desempenho especificado em casos de defeitos no software ou
no hardware. Esta subcaracterstica tem a ver com a forma como o
software reage quando ocorre uma situao externa fora do normal
(p.ex., conexo com a Internet interrompida).
Recuperabilidade: capacidade do produto de software de se colocar
novamente em operao, restabelecendo seu nvel de desempenho
especificado, e recuperar os dados diretamente afetados no caso de uma
falha.
Usabilidade: grau em que o produto apresenta atributos que permitem que o

mesmo seja entendido, aprendido e usado, e que o tornem atrativo para o
usurio. Tem como subcaractersticas:
Reconhecimento da Adequao: grau em que os usurios reconhecem
que o produto de software adequado para suas necessidades.
Inteligibilidade: refere-se facilidade de o usurio entender os conceitoschave do produto e aprender a utiliz-lo, tornando-se competente em seu
uso.
Operabilidade: refere-se facilidade do usurio operar e controlar o
produto de software.
Proteo contra Erros do Usurio: capacidade do produto de software de
evitar que o usurio cometa erros.
Esttica da Interface com o Usurio: capacidade do produto de software
de ser atraente ao usurio, lhe oferecendo uma interface com interao
agradvel.
Acessibilidade: capacidade do produto de software ser utilizado por um
amplo espectro de pessoas, incluindo portadores de necessidades
especiais e com limitaes associadas idade.
Eficincia de Desempenho: capacidade de o produto manter um nvel de

desempenho apropriado em relao aos recursos utilizados em condies
estabelecidas. Inclui subcaractersticas que evidenciam o relacionamento entre o
nvel de desempenho do software e a quantidade de recursos utilizados, a saber:
Comportamento em Relao ao Tempo: capacidade do produto de
software de fornecer tempos de resposta e de processamento apropriados,
quando o software executa suas funes, sob condies estabelecidas.
Utilizao de Recursos: capacidade do produto de software de usar tipos
e quantidades apropriados de recursos, quando executa suas funes, sob
condies estabelecidas.
Capacidade: refere-se ao grau em que os limites mximos dos parmetros
do produto de software (p.ex., itens que podem ser armazenados, nmero
de usurios concorrentes etc.) atendem s condies especificadas.

13
Segurana: grau em que informaes e dados so protegidos contra o acesso por

pessoas ou sistemas no autorizados, bem como grau em que essas informaes
e dados so disponibilizados para pessoas ou sistemas com acesso autorizado.
Tem como subcaractersticas:
Confidencialidade: garantir acesso a quem tem autorizao para tal.
Integridade: impedir ao acesso a quem no tem autorizao para tal.
No Repdio: garantia de que a ocorrncia de aes ou eventos possa ser
provada, evitando-se questionamentos futuros.
Responsabilizao: aes realizadas por uma pessoa ou sistema devem
poder ser rastreadas de modo a comprovar por quem foram feitas.
Autenticidade: capacidade de o sistema avaliar a identidade de um
usurio ou recurso.
Compatibilidade: capacidade do produto de software de trocar informaes com

outras aplicaes e/ou compartilhar o mesmo ambiente de hardware ou software.
Suas subcaractersticas so:
Coexistncia: capacidade do produto de software de coexistir com outros
produtos de software independentes, em um ambiente compartilhando
recursos comuns.
Interoperabilidade: capacidade do produto de software de interagir com
outros sistemas especificados, trocando e usando as informaes
trocadas.
Manutenibilidade: capacidade do produto de software de ser modificado. Tem

como subcaractersticas:
Modularidade: o produto de software deve possuir componentes coesos e
fracamente acoplados, de modo que uma modificao em um
componente tenha impacto mnimo em outros componentes.
Reusabilidade: capacidade dos componentes do produto de software
serem utilizados na construo de outros componentes ou sistemas.
Analisabilidade: capacidade do produto de software de permitir o
diagnstico de deficincias ou de causas de falhas, bem como a
identificao das partes a serem modificadas.
Modificabilidade: grau em que o produto de software pode ser
modificado sem introduzir novos defeitos ou degradar a qualidade do
produto, permitindo que uma modificao seja eficazmente
implementada.
Testabilidade: capacidade do produto de software de permitir que,
quando modificado, seja testado para determinar se as alteraes foram
propriamente realizadas e no introduziram efeitos colaterais.
Portabilidade: refere-se capacidade do software ser transferido de um ambiente

de hardware ou software para outro. Tem como subcaractersticas:

14
Adaptabilidade: capacidade do produto de software de ser adaptado para

diferentes ambientes especificados, sem necessidade de aplicao de
outras aes ou meios alm daqueles fornecidos para essa finalidade pelo
prprio software.
Capacidade para ser instalado (instalabilidade): avalia a facilidade de se
instalar (e desinstalar) o produto de software em um ambiente
especificado.
Capacidade de substituio (substituibilidade): capacidade do produto de
software de ser usado em substituio a outro produto de software
especificado, com o mesmo propsito e no mesmo ambiente. Considera,
tambm, a facilidade de atualizar uma nova verso.
Alm das caractersticas de qualidade que se aplicam diretamente ao sistema,
ditas atributos de qualidade de produto, Bass, Clements e Kazman (2003) listam outras
caractersticas relacionadas a metas de negcio, dentre elas: tempo para chegar ao
mercado (time to market), custo-benefcio, tempo de vida projetado para o sistema,
mercado alvo, cronograma de implementao e integrao com sistemas legados.
Um problema chave para o projeto definir prioridades para tratar requisitos no
funcionais conflitantes. Por exemplo, normalmente ao se melhorar o desempenho de
uma poro de um sistema est-se diminuindo a sua capacidade de acomodar mudanas.
Ou seja, torna-se mais difcil alterar o sistema. Assim, uma importante atividade do
projeto de sistemas avaliar os requisitos no funcionais e rever os desejos
incompatveis do cliente. A base para essa deciso deve ser a importncia relativa das
vrias caractersticas levantadas para o sistema em questo (BLAHA; RUMBAUGH,
2006).
Deve-se observar que, embora os requisitos no funcionais tenham cunho
tecnolgico, eles, assim como os requisitos funcionais, devem ser levantados junto aos
clientes e usurios. Dentre outras, as seguintes informaes devem ser levantadas:
Qual a localizao geogrfica dos usurios? H necessidade de transporte de
dados?
Quais so problemas operacionais existentes nas atividades dos usurios? Qual
ser o ambiente de hardware e software de produo? H restries tcnicas
(novo ambiente?) ou ambientais (temperatura, etc.)?
Qual a frequncia de disparo das operaes do sistema? Qual o tempo de
resposta esperado para cada uma delas?
Qual o volume de dados esperado (inicial, estimativa de crescimento e poltica
de esvaziamento)?
H restries de confiabilidade (tempo mnimo entre falhas)?
H restries de segurana (classes de usurios e acesso)?
Quais as caractersticas desejadas para a interface com o usurio?
Assim como os requisitos funcionais, os requisitos no funcionais (RNFs)
precisam ser especificados. Essa especificao deve ser tal que o RNF seja passvel de
avaliao. No basta dizer coisas como o sistema deve ser fcil de manter ou o

15
sistema deve ter uma interface com o usurio amigvel. O que significa fcil de
manter ou interface amigvel? Os RNFs tm de ser especificados de forma tal que
seja possvel posteriormente avaliar se os mesmos foram atendidos ou no.
Uma forma de especificar requisitos no funcionais prover uma descrio
associada a um critrio de aceitao. Este ltimo deve ser testvel e, para tal, medidas
objetivas devem ser providas.
A ISO/IEC 91262 pode ser uma boa fonte de medidas. As partes 2 (Medidas
Externas) (ISO/IEC, 2003a) e 3 (Medidas Internas) (ISO/IEC, 2003b) dessa norma
apresentam diversas medidas que podem ser usadas para especificar objetivamente os
RNFs. Nessas partes da norma, medidas so sugeridas para as diversas subcaractersticas descritas na Parte 1, indicando, dentre outros nome e propsito da
medida, mtodo de aplicao e frmula, e como interpretar os valores da medida.
Seja o exemplo em que um sistema tem como requisito no funcional ser fcil de
aprender. Este requisito poderia ser especificado conforme mostrado na Tabela 2.1.
Tabela 2.1 Especificao de Requisito No Funcional.
RNF01 A funcionalidade Efetuar Locao de Item deve ser fcil de aprender.
Medida:
(ISO/IEC,
2003a)
Descrio: Facilidade de aprender a realizar uma tarefa em uso

Propsito:
Quanto tempo o usurio leva para aprender a realizar uma

tarefa especificada eficientemente?
Mtodo de Observar o comportamento do usurio desde quando ele

Aplicao: comea a aprender at quando ele comea a operar
eficientemente a funcionalidade.
Medio:
Critrio de
Aceitao:
T = soma do tempo de operao do usurio at que ele

consiga realizar a tarefa em um tempo especificado (tempo
requerido para aprender a operao para realizar a tarefa).
T <= 15 minutos, considerando que o usurio est operando o sistema

eficientemente quando a tarefa Efetuar Locao realizada em um
tempo inferior a 2 minutos.
A Tabela 2.2 mostra exemplos de medidas que podem ser usadas para a
especificao e avaliao de requisitos no funcionais, algumas delas extradas e
adaptadas de (ISO/IEC, 2003a).
A famlia de normas ISO/IEC 9126 encontra-se em fase de transio para a nova famlia de normas, a
ISO/IEC 25000 - Software Product Quality Requirement and Evaluation (SQuaRE). Em especial,
medidas para a qualidade de produtos e sistemas so objeto da futura norma ISO/IEC 25023.
Tabela 2.2 Exemplos de Medidas para a Especificao e Avaliao de RNFs

Subcaracterstica
de Qualidade
Medida
Propsito da Medida
Procedimento de Medio
Frmula de
Medio
Interpretao do
valor medido
Fonte de
Entrada para
Medio
Interoperabilidade
Consistncia de
interface
(protocolo)
Quo corretamente os
protocolos de interface
foram implementados?
X=NPIC/NPIT
0 <= X <= 1. Quanto

mais prximo de 1,
mais consistente.
Responsabilizao
Auditabilidade
de acesso
Quo auditvel o login de

acesso?
X=NALC/NART
0 <= X <= 1. Quanto

mais prximo de 1,
mais auditvel.
Maturidade
Tempo mdio
entre falhas
Quanto tempo o produto

de software opera sem
apresentar falhas?
Contar o nmero de protocolos de interface corretamente

implementados (NPIC) conforme definido nas especificaes e
comparar com o nmero total de protocolos de interface a
serem implementados (NPIT) como definido nas especificaes.
Contar o nmero de tipos de acesso que esto sendo logados
corretamente (NALC) conforme definido nas especificaes e
comparar com o nmero total de tipos de acesso que so
requeridos (NART) como definido nas especificaes.
Calcular o tempo mdio at a falha (TMAF) e o tempo mdio de
reparo (TMR), e somar, obtendo o tempo mdio entre falhas.
X=TMAF+TMR
0 <= X. Quanto maior

o valor mais maduro.
Disponibilidade
Probabilidade de
estar disponvel
Qual a probabilidade do
produto de software estar
disponvel?
Calcular o tempo mdio at a falha (TMAF) e o tempo mdio de

reparo (TMR), derivando a probabilidade conforme a frmula de
medio dada.
X= TMAF /
(TMAF+TMR)
0 <= X <= 1. Quanto

mais prximo de 1,
mais disponvel.
Reconhecimento
da Adequao
Funes
Evidentes
Contar o nmero de funes evidentes para o usurio (NFE) e

comparar com o nmero de funes total (NFT).
X=NFE/NFT
0 <= X <= 1. Quanto

mais prximo de 1,
melhor.
Inteligibilidade
Inteligibilidade
de funes
Contar o nmero de funes de interface com o usurio

facilmente compreensveis pelo usurio (NFIC) e comparar com
o nmero de funes de interface com o usurio total (NFIT).
X=NFIC/NFIT
0 <= X <= 1. Quanto

mais prximo de 1,
melhor.
Projeto de IU
Operabilidade
Checagem de
validade de
entrada
Habilidade de
desfazer
Qual a proporo de
funes do produto de
software que esto
evidentes para os usurios?
Qual a proporo de
funes do produto de
software corretamente
entendidas pelos usurios?
Qual a proporo de itens
de entrada que checa se os
dados so vlidos?
Qual a proporo de
funes que podem ser
desfeitas?
Especificao de
requisitos,
Design, Cdigo
fonte
Especificao de
requisitos,
Design, Cdigo
fonte
Registros de
falhas e de
controle de
alteraes.
Registros de
falhas e de
controle de
alteraes.
Especificao de
requisitos,
Projeto de IU
Contar o nmero de itens de entrada com checagem de validade

(NIEC) e comparar com o nmero de itens de entrada passveis
de serem checados (NIEPC).
Contar o nmero funes que podem ser desfeitas pelo usurio
aps completadas (NFU) e comparar com o nmero total de
funes (NTF).
X=NIE/NIEPC
0 <= X <= 1. Quanto

mais prximo de 1,
melhor.
0 <= X <= 1. Quanto
mais prximo de 1,
melhor.
Especificao de
requisitos,
Projeto de IU
Especificao de
requisitos,
Projeto de IU
Operabilidade
X=NFU/NTF

17
2.4 Projeto de Software e Padres (Patterns)

Todo projeto de desenvolvimento , de alguma maneira, novo, na medida em
que se quer desenvolver um novo sistema, seja porque ainda no existe um sistema para
resolver o problema que est sendo tratado, seja porque h aspectos indesejveis nos
sistemas existentes. Isso no quer dizer que o projeto tenha que ser desenvolvido a partir
do zero. Muito pelo contrrio. A reutilizao um aspecto fundamental no
desenvolvimento de software e em especial na fase de projeto. Muitos sistemas
previamente desenvolvidos so similares ao sistema em desenvolvimento e h muito
conhecimento que pode ser reaplicado para solucionar questes recorrentes no projeto
de software. Os padres (patterns) visam capturar esse conhecimento, procurando tornlo mais geral e amplamente aplicvel, desvinculando-o das especificidades de um
determinado projeto ou sistema.
Um padro uma soluo testada e aprovada para um problema geral.
Diferentes padres se destinam a diferentes fases do ciclo de vida: anlise, projeto da
arquitetura, projeto detalhado e implementao. Um padro vem com diretrizes sobre
quando us-lo, bem como vantagens e desvantagens de seu uso. Um padro j foi
cuidadosamente considerado por outras pessoas e aplicado diversas vezes na soluo de
problemas anteriores de natureza similar. Assim, tende a ser uma soluo de qualidade,
com maiores chances de estar correto e estvel do que uma soluo nova, especfica,
ainda no testada (BLAHA; RUMBAUGH, 2006). Um padro normalmente tem o
formato de um par nomeado problema/soluo, que pode ser utilizado em novos
contextos, com orientaes sobre como utiliz-lo nessas novas situaes (LARMAN,
2007).
O objetivo de um padro de projeto registrar uma experincia no projeto de
software que possa ser efetivamente utilizada por projetistas. Cada padro
sistematicamente nomeia, explica e avalia uma importante situao de projeto que
ocorre repetidamente em sistemas (GAMMA et al., 1995).
Um projetista familiarizado com padres pode aplic-los diretamente a
problemas sem ter que redescobrir as abstraes e os objetos que as capturam. Uma vez
que um padro aplicado, muitas decises de projeto decorrem automaticamente.
Em geral, um padro tem os seguintes elementos (GAMMA et al., 1995)
(BUSCHMANN et al., 1996):
Nome: identificao de uma ou duas palavras, utilizada para nomear o
padro.
Contexto: uma situao que d origem a um problema.
Problema: explica o problema que surge repetidamente no dado contexto.
Soluo: descreve uma soluo comprovada para o problema, incluindo os
elementos que compem o projeto, seus relacionamentos, responsabilidades e
colaboraes. importante observar que um padro no descreve um
particular projeto concreto ou implementao. Um padro prov uma
descrio abstrata de um problema de projeto e como uma organizao geral
de elementos resolve esse problema.
Consequncias: so os resultados e os comprometimentos feitos ao se aplicar
o padro.

18
No que concerne aos padres relacionados fase de projeto, h trs grandes

categorias a serem consideradas:
Padres Arquitetnicos: definem uma estrutura global do sistema. Um

padro arquitetnico indica um conjunto pr-definido de pacotes, especifica
as suas responsabilidades e inclui regras e orientaes para estabelecer os
relacionamentos entre eles. So aplicados na atividade de projeto da
arquitetura de software e de seus elementos, e podem ser vistos como
modelos (templates) para arquiteturas de software concretas (BUSCHMANN
et al., 1996).
Padres de Projeto (Design Patterns): atendem a uma situao especfica de

projeto, mostrando classes e relacionamentos, seus papis e suas
colaboraes e tambm a distribuio de responsabilidades. Um padro de
projeto descreve uma estrutura recorrente de componentes que se
comunicam, a qual resolve um problema de projeto geral dentro de um
particular contexto (GAMMA et al., 1995).
Idiomas: representam o nvel mais baixo de padres, endereando aspectos

tanto de projeto quanto de implementao. Um idioma um padro de baixo
nvel, especfico de uma linguagem de programao, descrevendo como
implementar aspectos particulares de componentes ou os relacionamentos
entre eles, usando as caractersticas de uma dada linguagem de programao
(BUSCHMANN et al., 1996).
2.5 Documentao de Projeto

Uma vez que o projeto de software encontra-se no ncleo tcnico do processo de
desenvolvimento, sua documentao tem grande importncia para o sucesso de um
projeto e para a manuteno futura do sistema. Diferentes interessados vo requerer
informaes diferentes e a documentao de projeto crucial para a comunicao.
Analistas, projetistas e clientes vo precisar negociar para estabelecer prioridades entre
requisitos conflitantes; programadores e testadores vo utilizar essa documentao para
implementar e testar o sistema; gerentes de projeto vo usar informaes da
decomposio do sistema para definir e alocar equipes de trabalho; mantenedores vo
recorrer a essa documentao na hora de avaliar e realizar uma alterao, dentre outros
usos.
Uma vez que o projeto um processo de refinamento, a sua documentao
tambm deve prover representaes em diferentes nveis de abstrao. Alm disso, o
projeto de um sistema uma entidade complexa que no pode ser descrita em uma
nica perspectiva. Ao contrrio, mltiplas vises so essenciais e a documentao deve
abranger aquelas vises consideradas relevantes. De fato, como muitas vises so
possveis, a documentao uma atividade que envolve a escolha das vises relevantes
e a documentao das vises selecionadas (BASS; CLEMENTS; KAZMAN, 2003). A
escolha das vises dependente de vrios fatores, dentre eles, do tipo de sistema sendo
desenvolvido, dos atributos de qualidade considerados e do pblico alvo da
documentao de projeto. Diferentes vises realam diferentes elementos de um
sistema. De maneira geral, o documento de projeto deve conter (BASS; CLEMENTS;
KAZMAN, 2003):

19
Informaes gerenciais, tais como verso, responsveis, histrico de alteraes;
Uma descrio geral do sistema;
Uma lista das vises consideradas e informaes acerca do mapeamento entre

elas;
Para cada viso, deve-se ter:

Uma representao bsica da viso, que pode ser grfica, tabular ou
textual, sendo a primeira a mais usual, sobretudo na forma de um
diagrama UML. Se for usada uma representao grfica no
padronizada, deve-se ter uma legenda explicando a notao ou
simbologia usada.
Uma descrio sucinta dos elementos presentes na viso.
Ainda que no seja possvel advogar em favor de uma viso ou um conjunto de

vises, Bass, Clements e Kazman (2003) consideram trs grupos de vises que
tipicamente devem ser levadas em considerao, a saber:
Viso de Mdulos: os elementos considerados nessa viso so mdulos. Um

mdulo uma unidade de implementao, qual atribuda uma
responsabilidade funcional. Essa viso inclui, dentre outras, estruturas de
decomposio (mdulos decompostos em submdulos) e uso (um mdulo usa
outro mdulo);
Viso de Componente e Conector (C&C): os elementos considerados nessa

viso so componentes de tempo de execuo (as unidades de computao) e
conectores (veculos de comunicao entre componentes).
Viso de Alocao: mostra o relacionamento entre elementos de software e

elementos do ambiente externo no qual o software est sendo criado ou
executado. Estruturas de alocao incluem aspectos relacionados com
implantao (mostrando como componentes de tempo de execuo so alocados
a unidades de hardware), implementao (mostrando como mdulos so
mapeados para estruturas de arquivos) e designao de trabalho (mostrando as
equipes responsveis por implementar e integrar mdulos).
Alm das informaes anteriormente relacionadas, uma especificao de projeto
deve:
contemplar todos os requisitos contidos na especificao de requisitos, sendo

que, muitas vezes, podem ser levantados novos requisitos, sobretudo requisitos
no funcionais, durante a fase de projeto;
ser um guia legvel e compreensvel para aqueles que vo codificar, testar e

manter o software.
prover um quadro completo do software, segundo uma perspectiva de

implementao.

20
Leitura Complementar
Em (PRESSMAN, 2006), o Captulo 9 Engenharia de Projeto aborda vrios
dos temas discutidos neste captulo, com destaque para as sees 9.2 (Processo de
Projeto e Qualidade de Projeto), 9.3 (Conceitos de Projeto) e 9.5 (Projeto de Software
Baseado em Padro).
Em (PFLEEGER, 2004), o Captulo 5 Projetando o Sistema tem uma boa
discusso sobre decomposio, modularidade e nveis de abstrao (sees 5.2 e 5.4),
bem como acerca de caractersticas de um bom projeto (seo 5.5).
Em (BASS; CLEMENTS; KAZMAN, 2003), o Captulo 4 Understanding
Quality Attributes discute atributos de qualidade de sistemas de software e como
especificar requisitos especficos desses atributos na forma de cenrios. J o Captulo 2
What is Software Architecture? em sua seo 2.5, faz uma boa discusso sobre
vises para representar arquiteturas de software. Essas vises so posteriormente
exploradas no Captulo 9, que trata da documentao de arquiteturas de software.
No que se refere a padres, Buschmann e colegas tm uma coleo de cinco
volumes intitulados Pattern-Oriented Software Architecture (POSA) que apresentam
diversos padres arquitetnicos. Em especial, o Volume 1 - A System of Patterns
(BUSCHMANN et al., 1996) apresenta uma boa discusso sobre padres e categorias
de padres da fase de projeto. No que se refere aos padres de projeto (design patterns),
Gamma et al. (1995) apresentam um dos catlogos mais conhecidos e referenciados.
AMBLER, S.W., Modelagem gil, Artmed, 2004.
BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML
2, Elsevier, 2006.
BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P., STAL, M.,
Pattern-Oriented Software Architecture: A System of Patterns, Volume 1, Wiley,
1996.
ISO/IEC 9126-1, Software Engineering - Product Quality - Part 1: Quality Model, 2001.
ISO/IEC TR 9126-2:2003, Software Engineering Product Quality Part 2: External
Metrics, 2003.
ISO/IEC TR 9126-3:2003, Software Engineering Product Quality Part 3: Internal
Metrics, 2003.
LARMAN, C., Utilizando UML e Padres, 3 edio, Bookman, 2007.
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall,
2 edio, 2004.

21

medida que os sistemas computacionais crescem em tamanho e complexidade,
as tcnicas relacionadas ao projeto de estruturas de dados e algoritmos, tais como
decomposio modular de programas, tipos abstratos de dados e programao orientada
a objetos, no so mais suficientes para lidar com os problemas envolvendo o projeto de
software no nvel de sistema. Passa a ser necessrio considerar um nvel de organizao
relativo arquitetura do software (MENDES, 2002). A arquitetura de software refere-se
s estruturas de grandes sistemas de software. A viso arquitetnica de um sistema
abstrata, retirando de cena detalhes de implementao, algortmicos e de representao
de dados e procurando se concentrar no comportamento e interao entre elementos
considerados caixas pretas (BASS; CLEMENTS; KAZMAN, 2003).
O projeto da arquitetura envolve, dentre outras, questes relativas organizao
e estrutura geral do sistema, seleo de alternativas de projeto, atribuio de
funcionalidades a elementos de projeto e atendimento a atributos de qualidade
(requisitos no funcionais) (MENDES, 2002).
Este captulo trata do projeto da arquitetura de software. A Seo 3.1 discute o
que arquitetura de software, os fatores que influenciam o seu projeto, os interessados
na arquitetura e a importncia de sua representao. A Seo 3.2 apresenta algumas
classes de sistemas, as quais podem ser associadas a certos estilos arquitetnicos. A
Seo 3.3 apresenta alguns estilos arquitetnicos. A Seo 3.4 discute aspectos
especficos do projeto de sistemas de informao e enumera alguns padres
arquitetnicos que podem ser usados no projeto dessa classe de sistemas. A Seo 3.5
trata da relao entre atributos de qualidade (requisitos no funcionais) e a arquitetura e
apresenta algumas tticas que podem ser usadas para incorporar esses atributos a
sistemas de software. A Seo 3.6 apresenta um processo para conduzir o projeto da
arquitetura de software. Finalmente, a Seo 3.7 comenta brevemente sobre o projeto de
componentes da arquitetura, apontando como o restante deste texto se posiciona em
relao a essa questo.
3.1 O que Arquitetura de Software?

De acordo com Bass, Clements e Kazman (2003), a arquitetura de software de um
sistema computacional refere-se sua estrutura, consistindo de elementos de software,
propriedades externamente visveis desses elementos e os relacionamentos entre eles. A
arquitetura define elementos de software (ou mdulos) e envolve informaes sobre
como eles se relacionam uns com os outros. Uma arquitetura pode envolver mais de um
tipo de estrutura, com diferentes tipos de elementos e de relacionamentos entre eles. A
arquitetura omite certas informaes sobre os elementos que no pertencem s suas
interaes. As propriedades externamente visveis indicam as suposies que os demais
elementos podem fazer sobre um elemento, tais como servios providos e caractersticas
de qualidade esperadas. Assim, uma arquitetura antes de tudo uma abstrao de um
sistema que suprime detalhes dos elementos que no afetam como eles so usados,

22
como se relacionam, como interagem e como usam outros elementos. Na maioria das
vezes, a arquitetura usada para descrever aspectos estruturais de um sistema.
Em quase todos os sistemas modernos, elementos interagem com outros por meio
de interfaces que dividem detalhes sobre um elemento em partes pblica e privada. A
arquitetura est preocupada com a parte pblica dessa diviso. Detalhes privados,
aqueles que tm a ver somente com a implementao interna, no so arquiteturais
(BASS; CLEMENTS; KAZMAN, 2003).
At o projeto arquitetnico, aspectos relacionados ao hardware e plataforma de
implementao ainda no foram tratados, j que a fase de anlise no se preocupa com a
tecnologia a ser usada na soluo, mas somente com o domnio do problema (viso de
mundo real). Este o momento para resolver como um modelo ideal vai executar em
uma plataforma restrita. importante realar que no existe a soluo perfeita. O
projeto da arquitetura uma tarefa de negociao, onde se faz compromissos entre
solues sub-timas. O modelo de arquitetura mapeia os requisitos essenciais da fase de
anlise em uma arquitetura tcnica. Uma vez que muitas arquiteturas diferentes so
possveis, o propsito do projeto arquitetnico escolher a configurao mais adequada.
Normalmente, o projeto da arquitetura discutido luz dos requisitos do sistema,
ou seja, necessrio conhecer minimamente os requisitos do sistema para se poder
projetar a sua arquitetura. Contudo, deve-se considerar o projeto arquitetnico como
algo mais abrangente, envolvendo aspectos tcnicos, sociais e de negcio. Todos esses
fatores (e no somente os requisitos) influenciam a arquitetura de software. A
arquitetura, por sua vez, afeta o ambiente da organizao (incluindo ambientes tcnico,
social e de negcio), o qual vai influenciar arquiteturas futuras, criando um ciclo de
realimentao contnua. Por exemplo, se os projetistas encarregados do projeto de um
novo sistema obtiveram bons resultados em projetos de sistemas anteriores usando uma
particular abordagem de arquitetura, ento natural que eles tentem a mesma
abordagem em um novo projeto. Por outro lado, se suas experincias anteriores com
essa abordagem foram desastrosas, os projetistas vo relutar em tent-la outra vez,
mesmo que ela se apresente como uma soluo adequada. Assim, as escolhas so
guiadas, tambm, pela formao e experincia dos projetistas (BASS; CLEMENTS;
KAZMAN, 2003).
Outro fator que afeta a escolha da arquitetura o ambiente tcnico (ou plataforma
de implementao) corrente. Muitas vezes, h para esse ambiente um conjunto
dominante de padres, prticas e tcnicas que aceito pela comunidade de arquitetos ou
pela organizao de desenvolvimento. Por fim, a arquitetura influenciada tambm pela
estrutura e natureza da organizao de desenvolvimento (BASS; CLEMENTS;
KAZMAN, 2003).
Assim, no projeto da arquitetura de software, projetistas so influenciados por
requisitos para o sistema, estrutura e metas da organizao de desenvolvimento,
ambiente tcnico disponvel e por sua prpria experincia e formao. Alm disso, os
relacionamentos entre metas de negcio, requisitos de sistemas, experincia dos
projetistas, arquiteturas e sistemas implantados geram diversos laos de realimentao
que podem ser gerenciados pela organizao. Esse ciclo de realimentao, ilustrado na
Figura 3.1, atua, dentre outros, das seguintes maneiras (BASS; CLEMENTS;
KAZMAN, 2003):

Estrutura da
Organizao
23
1. Informaes para
EAP e alocao de
recursos
Requisitos
3. Novas oportunidades,
reso, qualidade
2. Introduo em um
novo segmento de
mercado
Metas da
Organizao
Arquitetura
4. Novas
experincias
Formao e
Experincia dos
Projetistas
Figura 3.1 A Arquitetura de Software e suas Influncias.

1. A arquitetura afeta a estrutura da organizao de desenvolvimento. Ao
prescrever uma estrutura para um sistema, a arquitetura prescreve tambm as
unidades de software a serem implementadas (ou obtidas) e integradas para
formar o sistema. Essas unidades formam a base para o desenvolvimento da
Estrutura Analtica do Projeto (EAP) e para a alocao de equipes e pessoas s
unidades da EAP.
2. A arquitetura pode afetar as metas da organizao de desenvolvimento, uma
vez que um sistema bem sucedido, construdo a partir dela, pode habilitar a
organizao a estabelecer uma base em uma particular rea de mercado.
3. A arquitetura pode afetar os requisitos do cliente para novos sistemas, ao dar
ao cliente a oportunidade de receber um sistema baseado na mesma arquitetura
de maneira mais econmica, rpida e confivel do que se o mesmo sistema
tivesse que ser desenvolvido a partir do zero.
4. O processo de construir o sistema baseado na arquitetura afeta a experincia
do projetista.
Muitas pessoas tm interesse na arquitetura de software, tais como clientes,
usurios finais, desenvolvedores, gerentes de projeto e mantenedores. Alguns desses
interesses so conflitantes e o projetista frequentemente tem de mediar conflitos at
chegar configurao que atenda de forma mais adequada a todos os interesses. Neste
contexto, a arquitetura de software importante principalmente porque (BASS;
CLEMENTS; KAZMAN, 2003):
Representa uma abstrao do sistema que pode ser usada para compreenso
mtua, negociao, consenso e comunicao entre os interessados. A
arquitetura prov uma linguagem comum na qual diferentes preocupaes
podem ser expressas, negociadas e resolvidas em um nvel que seja
intelectualmente gerencivel.
Manifesta as primeiras decises de projeto. Essas decises definem restries

sobre a implementao e a estrutura do projeto. A implementao tem de ser
dividida nos elementos prescritos pela arquitetura. Os elementos tm de
interagir conforme o prescrito e cada elemento tem de cumprir sua

24
responsabilidade conforme ditado pela arquitetura. Tambm a estrutura do

projeto, e s vezes at a estrutura da organizao como um todo, torna-se
amarrada estrutura proposta pela arquitetura. Neste sentido, a arquitetura
pode ajudar a obter estimativas e cronogramas mais precisos, bem como pode
ajudar na prototipagem do sistema. Alm disso, a extenso na qual o sistema
vai ser capaz de satisfazer os atributos de qualidade requeridos
substancialmente determinada pela arquitetura. Particularmente a
manutenibilidade fortemente afetada pela arquitetura. Uma arquitetura
reparte possveis alteraes em trs categorias: locais (confinadas em um
nico elemento), no locais (requerem a alterao de vrios elementos, mas
mantm intacta a abordagem arquitetnica subjacente) e arquitetnicas
(afetam a estrutura do sistema e podem requerer alteraes ao longo de todo o
sistema). Obviamente, alteraes locais so as mais desejveis e, portanto,
uma arquitetura efetiva deve propiciar que as alteraes mais provveis sejam
as mais fceis de fazer.
Constituem um modelo relativamente pequeno e intelectualmente

compreensvel de como o sistema estruturado e como seus elementos
trabalham em conjunto. Alm disso, esse modelo transfervel para outros
sistemas, em especial para aqueles que exibem requisitos funcionais e no
funcionais similares, promovendo reso em larga escala. Um desenvolvimento
baseado na arquitetura frequentemente enfoca a composio ou montagem de
elementos que provavelmente foram desenvolvidos separadamente, ou at
mesmo de forma independente. Essa composio possvel porque a
arquitetura define os elementos que devem ser incorporados ao sistema. Alm
disso, a arquitetura restringe possveis substituies de elementos, tomando
por base a forma como eles interagem com o ambiente, como eles recebem e
entregam o controle, que dados consomem e produzem, como acessam esses
dados e quais protocolos usam para se comunicar e compartilhar recursos.
importante que o projetista seja capaz de reconhecer estruturas comuns

utilizadas em sistemas j desenvolvidos, de modo a compreender as relaes existentes
e desenvolver novos sistemas como variaes dos sistemas existentes. O entendimento
de arquiteturas de software existentes permite que os projetistas avaliem alternativas de
projeto. Neste contexto, uma representao da arquitetura essencial para permitir
descrever propriedades de um sistema complexo, bem como uma anlise da arquitetura
proposta (MENDES, 2002).
Muitas vezes, arquiteturas so representadas na forma de diagramas contendo
caixas (representando elementos) e linhas (representando relacionamentos). Entretanto,
tais diagramas no dizem muita coisa sobre o que so os elementos e como eles
cooperam para realizar o propsito do sistema e, portanto, no capturam importantes
informaes de arquitetura (BASS; CLEMENTS; KAZMAN, 2003). Por exemplo, em
uma viso de decomposio de mdulos, importante distinguir quando um mdulo
decomposto em outros mdulos e quando um mdulo simplesmente usa outros
mdulos. J em uma arquitetura cliente-servidor, importante apontar quando um
mdulo considerado cliente e quando ele considerado servidor. Assim, idealmente, a
representao de uma arquitetura deve incorporar informaes acerca dos tipos dos
elementos e dos relacionamentos. Alm disso, conforme discutido no Captulo 2,
mltiplas vises podem ser usadas para representar diferentes aspectos da arquitetura.

25
3.2 Classes de Sistemas

Sistemas similares muito provavelmente tero arquiteturas similares. Se h
solues bem estabelecidas para certas classes de sistemas, no h razo para reinventar
a roda. O melhor procurar reutilizar alguma dessas solues.
Sistemas podem ser classificados de muitas formas diferentes. Blaha e Rumbaugh
(2006) listam seis tipos de sistemas, sendo que um dado sistema pode se enquadrar em
mais de uma dessas categorias. As classes de sistemas listadas so:
Sistemas de Transformao (ou Processamento) em Lote: so organizados como
uma srie de mdulos conectados sequencialmente. O sistema recebe as entradas
(todas de uma s vez) e realiza uma srie de transformaes sobre os dados, at
produzir uma resposta, sem haver qualquer interao com o mundo exterior
durante todo o processamento. O aspecto mais importante do projeto de um
sistema desta natureza a definio de uma srie lgica de etapas de
processamento. Ex.: compiladores, sistema de folha de pagamento.
Sistemas de Transformao Contnua: similares aos sistemas de transformao
em lote no que se refere ao fato de serem organizados como uma srie de
mdulos conectados sequencialmente, os sistemas de transformao contnua
recebem entradas continuamente e calculam sadas de maneira incremental. Ex.:
sistemas de processamento de sinais, sistemas de monitoramento de processos.
Sistemas de Interface Interativa: so dominados por interaes com agentes
externos, tais como pessoas e dispositivos. Como os agentes externos so
independentes do sistema, este no pode control-los, ainda que possa solicitar
respostas deles. Para sistemas desta natureza, recomenda-se isolar as classes de
interface das classes de aplicao, bem como se recomenda o uso de classes
predefinidas (p.ex., fornecidas por sistemas de gerenciamento de interfaces com
o usurio) para o projeto da interao.
Sistemas de Simulao Dinmica: modelam ou controlam objetos do mundo real
e, portanto, o desempenho pode ser um fator crtico. Em um mundo ideal, um
nmero arbitrrio de processadores paralelos executaria a simulao em uma
analogia exata situao do mundo real. Na prtica, preciso adequar-se aos
recursos disponveis. Etapas discretas so usadas para aproximar processos
contnuos. Ex.: simulao de fenmenos atmosfricos, modelos econmicos,
jogos.
Sistemas de Tempo Real: so sistemas interativos com fortes restries de
tempo, frequentemente projetados para operarem prximos de seus limites. O
projeto de um sistema de tempo real um processo complexo e envolve aspectos
relacionados priorizao e coordenao de tarefas, bem como tratamento de
interrupes. Desempenho um fator determinante e os fatores portabilidade e
manutenibilidade normalmente so sacrificados em detrimento do primeiro. Ex.:
sistemas de controle de processos industriais, sistemas de monitoramento de
pacientes em hospitais etc.
Sistemas Gerenciadores de Transaes: so sistemas cuja funo principal
armazenar e recuperar dados. Normalmente lidam com vrios usurios
realizando operaes ao mesmo tempo e precisam proteger seus dados contra
acesso no autorizado (segurana) e perda acidental (recuperabilidade). So

26
geralmente construdos sobre um sistema gerenciador de banco de dados. Neste

tipo de sistema, determinar a unidade de transao (i.e., o conjunto de recursos
que precisa ser trabalhado como uma transao) um importante aspecto de
projeto, j que transaes so completamente bem-sucedidas ou completamente
fracassadas. Ex.: sistemas de venda de passagens areas, sistemas de controle de
estoque, sistemas bancrios etc.
Uma classe de sistemas muito importante, que combina algumas das classes
descritas anteriormente, a classe dos Sistemas de Informao. O principal objetivo
dessa classe de sistemas o gerenciamento de informaes (MENDES, 2002). Sistemas
de Informao (SIs) so responsveis por coletar, manipular e preservar grandes
quantidades de informaes complexas (SHAW; GARLAN, 1996). Fowler (2003)
enumera as seguintes caractersticas para SIs:
SIs geralmente envolvem grandes quantidades de dados e a sua gerncia

uma parte importante do sistema. Assim, bancos de dados so frequentemente
utilizados. Alm disso, esses dados precisam ser armazenados por vrios anos
e durante esse tempo, muitas alteraes nos programas que os manipulam vo
ocorrer. muito provvel que haja diversas alteraes, inclusive, na estrutura
dos dados para acomodar novas pores de informao.
Usurios tipicamente acessam os dados concorrentemente.
H uma grande quantidade de interfaces com o usurio para tratar os dados. O

perfil dos usurios varia de ocasional a regular e normalmente eles no
dominam profundamente a tecnologia. Assim, os dados tm de ser
apresentados em muitos diferentes meios para diferentes propsitos.
Um SI geralmente precisa estar integrado com outros SIs da organizao. Os

vrios sistemas so construdos em diferentes momentos, usando diferentes
tecnologias. Esta situao agravada quando os SIs precisam estar integrados
com sistemas de organizaes parceiras. Mesmo unificando a tecnologia de
integrao, h problemas advindos de diferenas nos processos de negcio e
na semntica dos dados (dissonncia conceitual).
Regras de negcio so impostas e necessrio lidar com diversas condies

que, muitas vezes, estabelecem relaes umas com as outras, de modos at
surpreendentes. Diversos casos especficos tornam um SI muito complexo.
Alm disso, essas regras certamente mudaro ao longo do tempo.
Dadas essas caractersticas, pode-se perceber que SIs enquadram-se em algumas

das classes anteriormente apresentadas. A maior parte dos sistemas de informao so
sistemas gerenciadores de transao com interface interativa e um componente vital
para esse tipo de sistema o banco de dados no qual transaes so realizadas, o que
envolve operaes de insero, remoo, consulta e atualizao (MENDES, 2002).
Atributos de segurana, confiabilidade, usabilidade, eficincia e compatibilidade devem
ser considerados atentamente no projeto desse tipo de sistema. Como esto associados a
processos de negcio de organizaes, sistemas de informao esto sujeitos tambm a
modificaes frequentes e a manutenibilidade tambm um atributo de qualidade
importante para essa classe de sistemas.
Quanto plataforma em que executam, sistemas podem ser classificados em
aplicaes desktop, aplicaes web e aplicaes mveis. Aplicaes desktop executam

27
em estaes de trabalho (computadores, notebooks) e podem utilizar os recursos dessas

mquinas. Como consequncia, podem explorar uma rica variedade de controles de
interface com o usurio. Aplicaes desktop podem executar em uma nica mquina
(standalone) ou em vrias mquinas (aplicaes distribudas). Uma aplicao web, por
sua vez, uma aplicao de software que utiliza a Web, por meio de um navegador
(browser), como ambiente de execuo. O escopo e a complexidade das aplicaes Web
variam muito: de pequena escala e tempo de desenvolvimento curto (algumas semanas),
a aplicativos corporativos de grande escala, distribudos atravs da Internet ou via
intranets e extranets (MURUGESAN; GINIGE, 2008). J aplicaes mveis so
aplicativos de software desenvolvidos para dispositivos mveis de menor capacidade de
processamento, tais como smartphones. Podem executar via Web (e, portanto, neste
caso so tambm aplicaes web) ou como clientes especficos de uma certa plataforma
mvel (p.ex., iPhone, Blackberry, Android, Windows Mobile). Neste ltimo caso, uma
aplicao cliente desenvolvida para um sistema operacional pode no ser portvel para
outros.
Uma caracterstica marcante da plataforma desktop em relao s demais a
maior riqueza das interfaces com o usurio. As aplicaes web tradicionais so baseadas
na apresentao de pginas HTML para o usurio, via um navegador, o que permite
uma interao um pouco menos flexvel. Contudo, mais recentemente, com o
surgimento das chamadas Aplicaes Ricas para Internet (Rich Internet Applications RIAs), possibilitado por tecnologias de desenvolvimento como AJAX (Asynchronous
Javascript and XML), aplicaes Web tambm podem exibir uma interao com o
usurio avanada e sofisticada (CASTELEYN et al., 2009).
Aplicaes Web podem ser classificadas de diversas maneiras, no havendo uma
classificao nica e amplamente aceita. Murgesan e Ginige (2008) propem a seguinte
categorizao das aplicaes Web com base em sua funcionalidade:
Informativas: visam apresentar informao. Ex.: Jornais online, catlogos de

produtos, classificados online, website de um museu ou uma enciclopdia
online.
Interativas: envolvem uma maior interao com o usurio, tais como formulrios
de inscrio, apresentao de informaes personalizadas, jogos online etc.
Transacional: envolvem transaes, tais como comrcio eletrnico (solicitao

de bens e servios), homebaking, reservas de passagens areas etc.
Orientadas ao Fluxo de Trabalho (Workflow): seguem um fluxo de trabalho bem

definido, normalmente definido por um processo de negcio. Exemplos incluem
gesto de estoque, gerenciamento da cadeia de fornecimento etc.
Ambientes de Trabalho Colaborativo: incluem sistemas de auditoria distribuda,

ferramentas de design colaborativo etc.
Comunidades e mercados online: incluem grupos de discusso, sistemas de

recomendao etc.
Pressman e Lowe (2009), por sua vez, propem outras categorias de aplicaes
web, que incluem aplicaes informativas, de download, orientadas a transaes,
orientadas a servios, de acesso a bases de dados, data warehousing, portais, dentre
outras.

28
3.3 Estilos Arquitetnicos

Conforme discutido no Captulo 2, a reutilizao um aspecto-chave para se obter
um bom projeto de software. No que refere ao reso no projeto da arquitetura de
software, estilos e padres arquitetnicos so importantes ferramentas. Muitos autores
consideram estilos e padres como diferentes termos para designar o mesmo conceito,
tal como Gorton (2006). Outros consideram estilos e padres conceitos diferentes, como
o caso de Albin (2003). Neste texto, vamos trat-los como conceitos distintos, ainda
que ambos se refiram captura de conhecimento relevante relativo a uma soluo
genrica para um problema relacionado arquitetura de software.
Um estilo arquitetnico define um vocabulrio de tipos de elementos e tipos de
relacionamentos, e um conjunto de restries sobre como eles podem ser combinados
(SHAW; GARLAN, 1996). Padres arquitetnicos tambm estabelecem tipos de
elementos e de relacionamentos entre eles, mas sua apresentao segue uma forma bem
definida, indicando nome, contexto, problema, soluo e consequncias. Especialmente
a soluo define estratgias para tratar o problema, o que no acontece com os estilos
arquitetnicos. Assim, normalmente, estilos tm uma apresentao mais livre e so
descritos de maneira mais abstrata que padres arquitetnicos.
Shaw e Garlan (1996) propuseram uma taxonomia de estilos arquitetnicos que
considera cinco categorias principais, contendo algum grau de sobreposio entre elas:
Sistemas de Fluxo de Dados: so caracterizados pelo modo como dados se

movem atravs do sistema (ALBIN, 2003). O estilo dutos e filtros (pipes
and filters) classificado nesta categoria.
Sistemas de Chamada e Retorno: so caracterizados por um modelo de

ativao que envolve a linha principal de controle que realiza invocaes
explcitas de operaes (ALBIN, 2003), tal como ocorre com chamadas de
subrotinas na programao estruturada ou a invocao de operaes em
sistemas orientados a objetos. O estilo camadas (layers) classificado nesta
categoria, bem como o estilo parties (partitions).
Componentes Independentes: este estilo fia-se na invocao implcita de

operaes, ou seja, a invocao de uma operao desacoplada de sua
execuo, de modo que os componentes chamador e chamado podem existir
em processos separados e possivelmente distribudos em processadores
distintos (ALBIN, 2003). O estilo invocao implcita classificado nesta
categoria.
Mquinas Virtuais: uma mquina virtual desenvolvida em software,

contendo uma mquina de interpretao, uma memria contendo o cdigo a
ser interpretado, uma representao do estado da mquina de interpretao e
uma representao do estado corrente do programa (SHAW e GARLAN,
1996). Interpretadores e sistemas baseados em regras so estilos que se
enquadram nesta categoria.
Repositrios: esta categoria envolve um repositrio de dados compartilhado

para a passagem de informaes. Diferentes estilos baseados em repositrio
variam em termos de estilos de ativao e comunicao (ALBIN, 2003).
Exemplos de estilos nessa categoria incluem os estilos baseado em bancos de
dados e quadro-negro.

29
Estilos arquitetnicos podem ser combinados de vrias maneiras. Por exemplo,

um componente de um sistema organizado em um estilo pode ter sua estrutura interna
desenvolvida em um estilo completamente diferente. Outra opo permitir que um
nico componente use uma mistura de conectores arquitetnicos diferentes. Por
exemplo, um componente pode acessar uma base de dados como parte de sua interface,
mas interagir atravs de dutos com outros componentes do sistema (SHAW; GARLAN,
1996). Vale ressaltar que sempre uma boa opo considerar a combinao de estilos
durante o projeto de uma arquitetura. Assim, uma arquitetura pode combinar diferentes
estilos em partes distintas de um sistema, de modo a exibir diferentes atributos de
qualidade (ALBIN, 2003). A seguir, alguns estilos arquitetnicos so apresentados.
Dutos e Filtros
O estilo dutos e filtros (pipes and filters) considera a existncia de uma rede
pela qual dados fluem de uma extremidade (origem) at a outra (destino). O fluxo de
dados se d atravs dos dutos e os dados sofrem transformaes nos filtros. Um duto
prov uma forma unidirecional de fluxo de dados, atuando como um condutor entre dois
componentes, do componente origem para o componente destino (MENDES, 2002).
Assim, os componentes so denominados filtros e os conectores, dutos (SHAW;
GARLAN, 1996). A canalizao de programas no sistema operacional Unix, o modelo
clssico de compiladores e sistemas de folha de pagamento so exemplos de uso do
estilo dutos e filtros. A Figura 3.2 ilustra esse estilo arquitetnico.
Filtros
Dutos
Figura 3.2 Estilo Dutos e Filtros (adaptado de (SHAW; GARLAN, 1996)).

No estilo dutos e filtros, cada componente (filtro) possui um conjunto de
entradas e um conjunto de sadas. Um componente l dados de suas entradas e produz
dados em suas sadas, realizando alguma transformao local. Os filtros tm de ser
entidades independentes e no podem compartilhar estado (informaes internas) com
outros filtros. Alm disso, um filtro no conhece os filtros anteriores e posteriores no
fluxo. A especificao de um filtro define apenas o que requerido nos dutos de entrada
e garantir o que vai ser produzido nos dutos de sada, sem, no entanto, identificar os
componentes nas extremidades desses dutos. Uma especializao comum desse estilo
so os chamados pipelines, que restringem a topologia para sequncias lineares de
filtros. Quando em um pipeline, cada filtro processa a sua entrada como um todo, temse um estilo de transformao em lote sequencial (batch sequential) (SHAW;
GARLAN, 1996).
O estilo dutos e filtros possui diversas propriedades interessantes, dentre elas
(SHAW; GARLAN, 1996):

30
Permite que o projetista compreenda o comportamento geral de um sistema

como uma composio simples dos comportamentos dos filtros individuais.
Facilita o reso. Quaisquer dois filtros podem ser conectados, desde que eles
estejam de acordo em relao aos dados sendo transmitidos entre eles.
Facilita a manuteno e o crescimento. Novos filtros podem ser adicionados

a um sistema existente, bem como filtros podem ser substitudos por outros
melhores ou atualizados.
Suporta execuo concorrente. Cada filtro pode ser implementado como uma
tarefa separada e potencialmente executada em paralelo com outros filtros.
Entretanto, h tambm desvantagens, tais como (SHAW; GARLAN, 1996):
Apesar dos filtros poderem processar dados de forma incremental, eles so

inerentemente independentes e, portanto, o projetista deve pensar cada filtro
como provendo uma transformao completa dos dados de entrada para
dados de sada.
Devido a seu carter transformacional, este estilo no cai bem para tratar
aplicaes interativas.
Camadas
No estilo em camadas, um sistema organizado hierarquicamente, como um
conjunto ordenado de camadas, cada uma delas construda em funo das camadas
inferiores e fornecendo servios para as camadas superiores. O conhecimento
unidirecional, i.e., uma camada conhece as camadas inferiores, mas no tem qualquer
conhecimento sobre as camadas superiores. H uma relao cliente-servidor entre uma
camada usuria de servios e suas camadas inferiores, provedoras de servios (BLAHA;
RUMBAUGH, 2006). Cada camada acrescenta um nvel de abstrao sobre a camada
inferior (MENDES, 2002). Arquiteturas de redes, tal como a arquitetura de Internet
TCP/IP, so bons exemplos de sistemas em camadas.
Uma arquitetura em camadas pode ser fechada, quando uma camada construda
apenas em funo da camada imediatamente inferior, ou aberta, quando uma camada
pode usar recursos de quaisquer camadas inferiores. A arquitetura fechada reduz a
dependncia entre as camadas, permitindo que alteraes sejam feitas mais facilmente.
J a arquitetura aberta reduz a necessidade de redefinir operaes em vrios nveis, o
que tende a resultar em melhor desempenho. Por outro lado, mudanas em uma camada
podem afetar qualquer camada acima, tornando a arquitetura menos robusta e
comprometendo a manutenibilidade do sistema (BLAHA; RUMBAUGH, 2006). A
Figura 3.3 ilustra arquiteturas em camadas fechada e aberta.

31
Camadas
Geralmente
chamadas de
procedimento
Arquitetura Fechada
Arquitetura Aberta
Figura 3.3 Estilo em Camadas.

Arquiteturas em camadas apresentam diversas propriedades interessantes, dentre
elas (SHAW; GARLAN, 1996):
Apoiam o projeto baseado em nveis crescentes de abstrao, permitindo dividir

um problema complexo em camadas, tratando de diferentes preocupaes.
Tratam bem a manutenibilidade e a possibilidade de crescimento, especialmente

as arquiteturas fechadas, pois alteraes em uma camada afetam apenas a
camada adjacente superior.
Apoiam o reso e diferentes implementaes da mesma camada podem ser

usadas alternativamente, desde que provejam as mesmas interfaces para as
camadas superiores.
Como qualquer estilo, a arquitetura em camadas apresenta tambm algumas

desvantagens, dentre elas:
Nem todos os sistemas so facilmente estruturados em camadas, sendo muitas

vezes difcil encontrar os nveis de abstrao corretos. Mesmo quando isso
possvel, consideraes de desempenho podem colocar obstculos, sobretudo
para o uso de uma arquitetura fechada (SHAW; GARLAN, 1996). Neste caso, o
desempenho poder ficar comprometido face necessidade de uma solicitao
externa ter de passar por diversas camadas para ser tratada (MENDES, 2002).
Pode no ser fcil definir o nmero adequado de camadas. Esse nmero

depender no s da funcionalidade a ser provida pelo sistema, mas tambm dos
requisitos no funcionais desejados (MENDES, 2002).
Parties
Outra forma de estruturar sistemas por meio de parties. Parties dividem
um sistema verticalmente em subsistemas fracamente acoplados, cada um fornecendo,
normalmente, um tipo de servio. Este o caso, por exemplo, de sistemas operacionais,
que possuem parties para controle de arquivos, gerncia de memria, controle de
processo etc. As parties podem ter algum conhecimento acerca das outras, mas esse
conhecimento no profundo e evita maiores dependncias de projeto. Ao contrrio das
camadas, que variam em seu nvel de abstrao, as parties simplesmente dividem um
sistema em partes, todas tendo um nvel de abstrao semelhante. Outra diferena entre

32
camadas e parties que as camadas dependem umas das outras, enquanto as parties
podem ser tanto independentes como dependentes e eventualmente mutuamente
dependentes (BLAHA; RUMBAUGH, 2006). A Figura 3.4 ilustra o estilo em parties.
Nesta figura, as parties 1 e 2 so mutuamente dependentes, enquanto a Partio 2
dependente da Partio 3. J as Parties 3 e 4 so parties independentes.
Parties dependentes
Partio 1
Partio 2
Partio 3
Parties mutuamente dependentes
Partio 4
Parties independentes
Figura 3.4 Parties.

Normalmente, o uso de parties simplesmente no suficiente para estruturar
um sistema. Uma boa opo combinar parties e camadas: as camadas podem ser
divididas em parties ou, como mais comum, as parties podem ser divididas em
camadas.
Invocao Implcita
O estilo arquitetnico invocao implcita (ou baseado em eventos) requer que
os componentes interessados em um evento registrem-se a fim de receb-lo.
Componentes podem tanto registrar interesse em receber eventos quanto em divulgar
eventos (MENDES, 2002). A ideia por trs da invocao implcita a de que um
componente pode anunciar um ou mais eventos, enquanto outros componentes podem
registrar interesse por um evento, associando um procedimento a ele. Quando um
evento anunciado, o prprio sistema invoca todos os procedimentos registrados para o
evento. Assim, o anncio de um evento implicitamente provoca a invocao de
procedimentos em outros componentes (SHAW; GARLAN, 1996).
A Figura 3.5 ilustra o estilo invocao implcita. Como mostra a figura, um
componente registrado como anunciante de um evento anuncia o evento, o qual
capturado pelo mecanismo de difuso de eventos. Esse mecanismo responsvel por
difundir o evento para todos os componentes que registraram interesse no mesmo
(componentes ouvintes), invocando os procedimentos associados. Deste modo, o
componente anunciante no invoca diretamente os procedimentos dos componentes
ouvintes, tornado esses componentes dissociados uns dos outros. A invocao de
procedimentos feita implicitamente pelo mecanismo de difuso de eventos.

33
Componente
Ouvinte 1
Componente
Anunciante
evento
Mecanismo
de Difuso de
Eventos
Invocao de procedimento
registrado, passando evento
Componente
Ouvinte n
Figura 3.5 Estilo Invocao Implcita.

Um bom exemplo de aplicao do estilo invocao implcita ocorre no
tratamento de excees, i.e., tratamento de falhas que acontecem em tempo de
execuo. Se durante a execuo do sistema uma falha ocorre, uma exceo (evento)
gerada com a informao do erro. Essa exceo encaminhada para o mecanismo de
difuso de eventos que a encaminha para os componentes responsveis por trat-la.
Deste modo, o mecanismo de difuso de eventos pode ser usado em todo o sistema, a
fim de lidar com a ocorrncia de excees, oferecendo suporte confiabilidade
(MENDES, 2002).
Os eventos so assncronos, o que permite que o componente anunciante
continue realizando alguma outra computao aps o envio do evento. Alm disso, o
componente anunciante desconhece a identidade dos componentes ouvintes. Assim, este
estilo arquitetnico prov suporte manutenibilidade, desde que a insero e a remoo
de componentes sejam fceis de serem realizadas (MENDES, 2002). Componentes
podem ser introduzidos no sistema simplesmente registrando-os como ouvintes de
eventos do sistema. Componentes podem, tambm, ser substitudos por outros
componentes, sem afetar as interfaces de outros componentes do sistema (SHAW;
GARLAN, 1996).
Contudo, uma vez que o componente anunciante desconhece os componentes
ouvintes, eles no podem fazer suposies acerca da ordem de processamento, nem
mesmo sobre que processamento vai ocorrer como resultado de seus eventos. Esta a
principal desvantagem da invocao implcita. Devido a isto, a maioria dos sistemas de
invocao implcita tambm inclui invocao explcita como uma forma de interao
complementar (SHAW; GARLAN, 1996).
Sistemas Baseados em Regras
Sistemas baseados em regras so sistemas de apoio deciso que procuram
representar o modo de raciocnio e o conhecimento utilizado por especialistas na
resoluo de problemas no seu mbito de especialidade. Existe, portanto, um
paralelismo entre esses sistemas e a forma como os especialistas humanos atingem um
alto nvel de desempenho na resoluo de problemas, na medida em que estes conhecem
muito bem as suas reas de especializao (CARDOSO; MARQUES, 2007).
Os problemas solucionados por um sistema baseado em regras so, tipicamente,
aqueles resolvidos por um especialista humano e que podem ser expressos mediante um
conjunto de regras bem definido para analisar o problema, tais como planejamento,
diagnstico e interpretao de dados (CARDOSO; MARQUES, 2007).

34
A principal diferena entre um sistema baseado em regras e um sistema

desenvolvido usando uma abordagem tradicional (procedimental ou funcional) est na
maneira como o conhecimento sobre o domnio do problema codificado. Em
aplicaes tradicionais, o conhecimento sobre o domnio do problema codificado tanto
nas instrues propriamente ditas quanto nas estruturas de dados. J na abordagem de
regras, todo o conhecimento relativo ao domnio do problema codificado
exclusivamente nas estruturas de dados. Nenhum conhecimento armazenado nas
instrues ou nos programas propriamente ditos.
Um sistema baseado em regras utiliza regras explcitas para expressar o
conhecimento do domnio de um problema e permite, atravs da confrontao do
conhecimento existente em fatos conhecidos sobre um determinado problema, inferir
novos fatos a partir dos existentes.
A arquitetura geral de um sistema baseado em regras compreende dois
componentes principais: um conjunto de declaraes totalmente dependentes do
domnio do problema, chamado de base de conhecimento, e um programa independente
do domnio do problema (apesar de altamente dependente das estruturas de dados),
chamado mquina de inferncia.
A base de conhecimento , tipicamente, divida em base de regras e base de fatos.
A base de regras contm regras que definem como derivar informaes a partir dos
fatos, enquanto os fatos so informaes acerca do estado do domnio. As regras
assumem a forma: Se condio ento ao, em que a condio descreve uma
determinada situao que, se verdadeira, desencadeia a ao como consequncia.
A mquina (ou motor ou mecanismo) de inferncia responsvel por efetuar o
processamento, sendo ela independente do conhecimento do domnio do problema.
Alm desses componentes principais, um sistema baseado em regras possui,
ainda, uma memria, que armazena temporariamente fatos iniciais e concluses
intermedirias, e uma interface com o usurio, a partir da qual se introduzem novos
fatos do problema e se recebem os resultados ou concluses retiradas pelo sistema
(CARDOSO; MARQUES, 2007). A Figura 3.6 ilustra a arquitetura de sistemas
baseados em regras.
Fatos e regras
Interface com
o Usurio
Memria
Mecanismo
de Inferncia
Figura 3.6 Estilo Baseado em Regras.
Base de
Conhecimento

35
3.4 Padres Arquitetnicos para Projeto de Sistemas de Informao

Conforme discutido no Captulo 2, um padro descreve um problema que ocorre
diversas vezes e o ncleo central de uma soluo para esse problema. Padres esto
enraizados na prtica. Ou seja, eles no so ideias originais, mas sim observaes do
que funciona na prtica. Assim, padres no so inventados, mas descobertos
(FOWLER, 2003).
Padres so um ponto de partida e no um fim em si. De incio, no necessrio
saber detalhes sobre os diversos padres. importante ter uma viso geral dos mesmos
para saber que problemas eles resolvem e como eles resolvem, de modo a selecion-los
quando forem aplicveis. Uma vez reconhecida a necessidade de se aplicar o padro,
tem-se de descobrir como aplic-lo ao problema especfico que se tem em mos. Muito
dificilmente ser possvel aplicar um padro cegamente. Padres so artefatos semiprontos, o que implica na necessidade de completar a soluo no contexto especfico do
projeto. Padres so relativamente independentes, mas no so isolados uns dos outros,
sobretudo os padres arquitetnicos. Muitas vezes, um padro leva a outros ou um
padro s aplicvel se outro estiver envolvido (FOWLER, 2003).
Em (FOWLER, 2003), apresentado um conjunto de padres para o projeto de
Sistemas de Informao (SIs) que, conforme aponta o prprio autor, podem ser
razoavelmente bem caracterizados como arquitetnicos, na medida em que representam
decises relativas estrutura dos sistemas.
Conforme discutido anteriormente, Sistemas de Informao (SIs) so sistemas
usados para prover informaes para apoiar processos de negcio das organizaes e
apresentam como caractersticas marcantes: grandes quantidades de dados que precisam
ser armazenados por longos perodos de tempo, usurios acessando o sistema de
maneira concorrente por meio de interfaces com o usurio e regras de negcio que
devem ser consideradas para que o sistema satisfaa as necessidades de seus usurios
O estilo subjacente aos padres apresentados por Fowler o estilo em camadas.
Assim, a maior parte dos padres apresentados refere-se a como decompor SIs em
camadas e como essas camadas trabalham em conjunto. Contudo, h tambm padres
de projeto (design patterns) utilizados para realizar a arquitetura. Assim, no h em
(FOWLER, 2003) uma clara separao entre padres arquitetnicos e design patterns.
No que se refere organizao de SIs em camadas, componentes podem ser
agrupados em trs camadas lgicas principais, ilustradas na Figura 3.7:
Camada de Apresentao ou de Interface com o Usurio: sua funo

tratar a interao entre o usurio e o sistema. As responsabilidades principais
dessa camada so exibir informaes para os usurios e interpretar comandos
do usurio em aes da lgica de negcio e da persistncia de dados.
Camada de Lgica de Negcio: contm as funcionalidades que apoiam os

processos de negcio. Conceitos do domnio, regras de negcio,
processamentos e clculos so encontrados nesta camada.
Camada de Persistncia ou de Gerncia de Dados: prov acesso a dados

corporativos. sua responsabilidade gerenciar requisies concorrentes de
acesso s bases de dados, assim como a sincronizao de elementos de dados
distribudos.

36
If ....
Then ....
Else ....
If ....
Then ....
Else ....
Camada de
Lgica do
Negcio
Camada de
Interface com o
Usurio
Camada de
Gerncia de
Dados
Figura 3.7 Camadas Lgicas Tpicas em Sistemas de Informao

Algumas vezes as camadas so dispostas de modo que a camada de lgica de
negcio oculta completamente a camada de gerncia de dados da interface com o
usurio (arquitetura fechada). Mais frequentemente, contudo, a camada de apresentao
acessa a gerncia de dados diretamente (arquitetura aberta). Ainda que menos pura, a
segunda abordagem tende a funcionar melhor na prtica (FOWLER, 2003).
Deve-se realar, ainda, que geralmente um sistema especfico pode possuir
vrios pacotes de cada um desses trs grandes tipos. Uma aplicao pode ser projetada
para ser manipulada pelos usurios tanto por meio de uma interface com o usurio rica,
quanto por uma interface de linha de comando, tendo, portanto, diferentes pacotes de
interface com o usurio para cada um dos propsitos (FOWLER, 2003).
Ainda que seja possvel identificar os trs tipos de camadas discutidos
anteriormente, a questo de como separ-las depende de quo complexa a aplicao.
Via de regra, a seguinte regra sobre dependncias deve ser respeitada: as camadas de
negcio e de gerncia de dados no devem ser dependentes da camada de apresentao.
Isso torna mais fcil substituir e modificar uma camada de apresentao (FOWLER,
2003).
Os padres apresentados em (FOWLER, 2003) so organizados de acordo com
essas camadas. Assim, h grupos de padres relativos :
Camada da Lgica de Negcio: padres nesse grupo tratam da organizao

das funcionalidades na camada de lgica de negcio. So eles: Script de
Transao (Transaction Script), Modelo de Domnio (Domain Model),
Mdulo Tabela (Table Module) e Camada de Servio (Service Layer). Alguns
desses padres so discutidos no Captulo 4, que aborda o projeto da lgica de
negcio.
Camada de Apresentao: padres nesse grupo enfocam a separao dos

objetos de interfaces grficas (viso) do controle da interao com o usurio.
Exemplos so os padres Modelo Viso Controlador (Model View Controller)
e Controlador de Aplicao (Application Controller). Alm disso, h padres
mais focados na viso (p.ex., Template View) e outros mais voltados para o

37
projeto de controladores (p.ex., Controlador Frontal ou, em ingls, Front

Controller). Alguns desses padres so discutidos no Captulo 5, que trata do
projeto da interao com o usurio.
Camada de Gerncia de Dados: padres nesse grupo se referem ao

mapeamento objeto relacional, j que a tecnologia dominante de banco de
dados para Sistemas de Informao a dos bancos de dados relacionais. H,
dentre outros, padres relativos a como a lgica de negcio conversa com os
bancos de dados, bem como padres relacionados a como mapear estruturas
do mundo de objetos (p.ex., associaes e herana) para bancos de dados
relacionais. Alguns desses padres so discutidos no Captulo 6, que trata do
projeto da gerncia de dados.
Alm desses trs grupos, Fowler (2003) discute, ainda, outros dois grupos, um
relativo a padres que buscam tratar problemas de concorrncia e outro envolvendo
padres enfocando o problema de estado de sesses.
Os padres apresentados em (FOWLER, 2003) tm a seguinte estrutura: nome,
inteno (que busca resumir um padro em uma ou duas sentenas), esboo (uma
representao visual do padro, geralmente na forma de um diagrama UML), problema,
soluo, quando usar o padro e leitura adicional (apontando outras discusses acerca
do padro).
Alm do catlogo de padres apresentado em (FOWLER, 2003), que enfoca o
projeto de sistemas de informao em camadas, outro catlogo bastante interessante o
conhecido como POSA (Pattern Oriented Software Architecture) (BUSCHMANN et
al., 1996). Este , na verdade, um conjunto de catlogos de propsito mais geral,
enfocando diversos aspectos e envolvendo tanto padres arquitetnicos como padres
de projeto, idiomas e linguagens de padres.
3.5 Projeto de Sistemas de Informao Distribudos

Tipicamente, SIs, sobretudo de mdio a grande porte, so aplicaes distribudas
e utilizam arquiteturas ditas cliente-servidor. Nessa arquitetura, componentes assumem
os papis de clientes e servidores de servios. Um servidor um componente que fica
em estado de espera, aguardando a solicitao de um servio por um ou mais clientes. O
servidor pode trabalhar de forma sncrona ou assncrona. Os clientes, por sua vez,
podem ser vistos como processos independentes, i.e., a execuo de seu processo no
interfere em outros (MENDES, 2002).
O estilo em camadas a base para as arquiteturas cliente-servidor. De fato, a
noo de camadas tornou-se mais aparente nos anos 1990 com o surgimento dos
sistemas cliente-servidor, ainda sob a marca do paradigma estruturado. Eles eram
sistemas em duas camadas, em que o cliente tratava a interface com o usurio e a lgica
de negcio, e o servidor era usualmente um banco de dados relacional. Contudo,
medida que a lgica de negcio foi ficando mais complexa, essa soluo foi sendo
objeto de muitas crticas. Uma alternativa passou a ser colocar a lgica de negcio no
servidor, tipicamente na forma de stored procedures. Entretanto, stored procedures
tinham mecanismos limitados de estruturao, levando tambm a muitos problemas.
Com o surgimento da orientao a objetos, passou-se a considerar sistemas em trs
camadas (FOWLER, 2003).

38
Ao longo do tempo, a arquitetura cliente-servidor tem evoludo, existindo

atualmente uma gama de variaes. Todas elas, contudo, compartilham a ideia de haver
funcionalidades compartilhadas entre clientes e servidores. Geralmente, clientes tratam
as solicitaes dos usurios, transformando-as em algum protocolo e as transmitindo
para um servidor. O servidor processa as solicitaes e retorna respostas para o cliente.
Por fim, o cliente envia as respostas para o usurio (MENDES, 2002).
Primordialmente, o termo cliente-servidor usado para descrever software que
executa em mais de um hardware, de modo a realizar uma tarefa de negcio. A
separao de hardware uma caracterstica marcante em aplicaes cliente-servidor. A
distncia entre processadores remotos varia desde computadores localizados na mesma
sala ou prdio, at aqueles localizados em diferentes prdios, cidades ou mesmo
espalhados pelo planeta. Entretanto, em relao arquitetura de software, o termo pode
ser usado para descrever diferentes componentes de software se comunicando uns com
os outros, ainda que rodando em uma mesma mquina (RUBLE, 1997). No projeto da
arquitetura de software, est-se falando de camadas lgicas, cujo objetivo dividir o
sistema em pacotes separados para reduzir o acoplamento entre diferentes partes do
sistema. A separao em camadas lgicas til mesmo se essas camadas estiverem
todas rodando na mesma mquina fsica. Contudo, h situaes em que a estrutura fsica
do sistema faz a diferena (FOWLER, 2003).
Considerando o mapeamento de camadas lgicas em camadas fsicas, um uso
bastante comum de arquiteturas cliente-servidor consiste em explorar o poder dos
computadores pessoais para gerenciar interfaces grficas com o usurio, mantendo os
servios e dados do negcio em servidores. Em sua forma mais simples, a arquitetura
cliente-servidor envolve mltiplos clientes fazendo requisies para um nico servidor,
como ilustra a Figura 3.8, o que caracteriza uma arquitetura em duas camadas (two-tier).
Clientes
Servidor
Figura 3.8 Arquitetura de hardware cliente-servidor em duas camadas.

A Figura 3.9 mostra uma arquitetura cliente-servidor em trs camadas, na qual
mquinas-cliente esto conectadas via rede a um servidor de aplicao que, por sua vez,
se comunica com um servidor de dados. Essa arquitetura pode ser, ainda, estendida para
n camadas (n-tier).

39
Clientes
Servidor de Dados
Servidor de
Aplicao
Figura 3.9 Arquitetura de hardware cliente-servidor em trs camadas.

A primeira gerao de ferramentas populares de desenvolvimento de aplicaes
cliente-servidor com interfaces grficas assumia uma arquitetura de hardware de duas
camadas e encorajava uma abordagem de projeto arquitetnico de software do tipo
cliente pesado, onde a lgica do negcio era totalmente amarrada camada de
apresentao da aplicao, o que provocava srios problemas de manutenibilidade.
Essas mesmas ferramentas evoluram e, em um segundo momento, passaram a ficar
mais em linha com uma filosofia do tipo servidor pesado, onde a lgica de negcio
fortemente mapeada no servidor de dados. Hoje, contudo, reconhece-se a necessidade
de separar a camada de lgica do negcio das demais camadas. Essa separao traz
vrias vantagens, dentre elas (RUBLE, 1997):
Reusabilidade: Classes de negcio tendem a ser complexas e podem

desempenhar diferentes papis dentro dos sistemas corporativos. A meta
criar classes que garantam as regras de negcio para uma particular classe de
negcio e reutiliz-las em todos os contextos que lidem com a mesma.
Portabilidade: ao se mover a lgica de negcio para uma camada separada,

permite-se tirar proveito de diferentes plataformas de hardware e software,
sem ter que reescrever grandes pores do cdigo.
Manutenibilidade: o fato da lgica de negcio estar concentrada em uma

camada nica da arquitetura de software facilita a localizao das alteraes
e evolues a serem feitas no sistema. O mesmo pode se dizer em relao
interface com o usurio e gerncia de dados.
preciso, portanto, escolher onde cada uma das camadas lgicas vai rodar
(camadas fsicas). De maneira geral, a gerncia de dados ficar no servidor. A exceo
ficar por conta de situaes em que necessrio duplicar dados para permitir operao
desconectada (FOWLER, 2003).
No que se refere camada de apresentao, a deciso depende principalmente do
tipo desejado de interface com o usurio. Com a difuso do uso da Web como
plataforma para o desenvolvimento de sistemas de informao, a opo mais simples
rodar tudo no servidor, cabendo ao cliente apenas a apresentao de uma interface

40
HTML (front end) rodando em um navegador Web. Essa soluo facilita a manuteno
e a implantao de novas verses, mas no permite operao desconectada e
compromete a rapidez com que o sistema reconhece uma solicitao do usurio
(responsiveness), uma vez que a solicitao tem de trafegar, ida e volta, para o servidor
(FOWLER, 2003). Alm disso, interfaces mais ricas podem no ser possveis. Para
tratar esses problemas, surgiram as Aplicaes Ricas para Internet (Rich Internet
Applications RIAs), discutidas na Seo 3.6.
Por fim, em relao camada de domnio, pode-se rodar tudo no cliente (cliente
pesado), tudo no servidor (servidor pesado) ou dividi-la. Rodar tudo no servidor a
melhor opo do ponto de vista da manutenibilidade. Dividir a lgica de negcio entre o
servidor e o cliente traz uma dificuldade adicional na manutenibilidade do sistema:
saber onde certa poro da aplicao est rodando. Neste caso, devem-se isolar as
pores que vo rodar no cliente em mdulos autocontidos que sejam independentes das
outras partes do sistema.
Levando-se em considerao os aspectos discutidos anteriormente, o projeto de
sistemas de informao distribudos envolve questes adicionais, dentre elas (RUBLE,
1997):
a definio de requisitos de distribuio geogrfica do sistema,
a definio das mquinas clientes, servidoras e da configurao e nmero de

camadas de hardware cliente-servidor,
a localizao dos processos,
a localizao dos dados fsicos e as estratgias de sincronizao para dados

distribudos geograficamente.
Para responder a essas (e outras) questes, importante levantar algumas

informaes a cerca de (RUBLE, 1997):
volumes de dados, frequncia de disparo de casos de uso e expectativas de

tempos de resposta para os mesmos;
topologia geogrfica do negcio e necessidades de distribuio geogrfica da

computao, incluindo a necessidade de distribuio de dados e de processos
nos diferentes locais.
A seguir, alguns aspectos importantes para o projeto de sistemas de informao

distribudos so discutidos.
3.5.1 Efetuando Estimativas
Determinar a arquitetura mais apropriada para um sistema de informao
distribudo envolve a quantificao da capacidade de computao necessria para o
problema. O modelo de anlise prov a base necessria para a realizao de estimativas
dos requisitos de computao do sistema final. Assim, uma atividade do projeto de SIs
consiste em completar as informaes de anlise, fazendo estimativas importantes
acerca do modelo estrutural e do modelo de casos de uso.

41
Estimativas sobre o Modelo Estrutural

A realizao de estimativas sobre o modelo conceitual estrutural (diagrama de
classes) importante para a definio da arquitetura, sobretudo no que concerne
escolha de tticas a serem aplicadas (vide Seo 3.7). Uma importante estimativa o
tamanho da base de dados do sistema. Essa informao til para apoiar a definio de
quais estratgias adotar em relao ao armazenamento e a comunicao de dados.
Para se estimar o tamanho da base de dados de um sistema, duas informaes
so essenciais: o tamanho de uma instncia de uma classe (para cada classe) e o nmero
estimado de instncias que podero ser acumuladas ao longo do tempo. Para determinar
o tamanho de um objeto, devem-se observar os tipos de dados de atributo da classe. J a
estimativa do nmero de instncias esperadas no to simples. Algumas classes, tais
como Pedido e Itens de Pedido, tm potencial de crescimento ilimitado. Para essas
classes, o modelo de casos de uso pode dizer quais casos de uso criam instncias das
mesmas. Para estimar o tamanho das bases de dados relativas a essas classes,
necessrio saber quo frequentemente o caso de uso ocorre e o perodo de reteno da
informao na base de dados.
Em suma, as seguintes informaes para cada classe do modelo estrutural devem
ser coletadas:
tamanho estimado de uma instncia, calculado pelo somatrio dos tipos de

dados de cada atributo,
taxa de ocorrncia dos casos de uso que criam novas instncias da classe,
perodo de reteno.
Essas estimativas so usadas para estimar os recursos necessrios para armazenar

adequadamente os dados. Mesmo se espao em disco no for um problema para o
projeto, elas so teis para tratar outros aspectos, como aspectos relacionados
comunicao de dados e distribuio geogrfica de dados.
Uma vez que importante saber que tipo de operao um caso de uso pode
realizar em uma classe, til produzir uma matriz CRUD (Create, Retrieve, Update,
Delete - Criar, Recuperar, Atualizar, Eliminar) Caso de Uso x Classe, mostrando se, por
ocasio da ocorrncia do caso de uso, o sistema vai criar, atualizar, recuperar ou
eliminar instncias da classe. A Figura 3.10 mostra um exemplo de matriz CRUD Caso
de Uso x Classe.
Classes
Casos de Uso
Cliente
Pedido
Item de Pedido
Efetuar pedido
Cancelar pedido
RD
RD
Alterar pedido
RU
CRUD
Figura 3.10 Exemplo de uma Matriz CRUD Caso de Uso x Classe.

42
Estimativas sobre o Modelo de Casos de Uso

Um modelo de casos de uso captura as funcionalidades de um sistema segundo
uma perspectiva externa, isto , dos usurios. Em um modelo de casos de uso, alguns
casos de uso so mais crticos do que outros em termos do negcio da organizao.
Alm disso, cada caso de uso pode ter requisitos no funcionais especficos.
No que se refere a desempenho, pode ser importante levantar informaes acerca
da frequncia de ocorrncia (ou disparo) e o tempo de resposta desejado para um caso
de uso. O objetivo identificar os casos de uso crticos, j que eles sero objeto de
ateno especial. Para esses, devem ser levantadas informaes sobre a frequncia
mdia de ocorrncia, a taxa de pico e o perodo de tempo do pico.
Se a ocorrncia dos eventos for uniforme ao longo do tempo, a frequncia mdia
de disparo aponta para o nvel normal de operao do sistema. Para eventos irregulares,
contudo, necessrio conhecer as taxas de pico e o perodo em que esses picos ocorrem.
Alm disso, uma importante questo se coloca: o sistema tem de ser dimensionado para
tratar picos, de modo a sempre atender satisfatoriamente s necessidades dos usurios?
Se o sistema for dimensionado pela capacidade de pico, provavelmente ficar ocioso
durante grande parte do tempo. Por outro lado, se for dimensionado pela mdia, nos
momentos de pico no atender totalmente s necessidades dos usurios. Esta no uma
deciso fcil e no deve ser tomada pelo projetista. Ao contrrio, essa deciso cabe,
principalmente, ao cliente. De maneira geral, a menos que o custo seja proibitivo, a
maioria das organizaes prefere gastar mais, dimensionando o sistema pelo pico.
No necessrio analisar todos os casos de uso de um sistema. suficiente
concentrar a ateno nos principais casos de uso do negcio, aqueles com os maiores
impactos sobre o cliente, com os maiores volumes de dados e com as localizaes mais
remotas geograficamente.
3.5.2 Determinando Requisitos de Distribuio Geogrfica
Outro passo importante do projeto arquitetnico consiste em examinar a
distribuio geogrfica dos casos de uso, o que conduz naturalmente distribuio
necessria dos dados. Juntos, a frequncia de disparo dos casos de uso, volume de
dados, restries de tempo de resposta e a distribuio geogrfica do negcio formaro a
base para se determinar uma arquitetura aceitvel para o sistema em questo.
Algumas matrizes podem ser usadas para mapear o modelo de anlise na
topologia de localizaes do negcio. Uma matriz Caso de Uso x Localizao do
Negcio, como a mostrada na Figura 3.11, juntamente com uma matriz Caso de Uso x
Classe, mostrada anteriormente na Figura 3.10, permite mapear as necessidades de
distribuio geogrfica de funcionalidades e dados de um sistema.

43
Localizao
Casos de Uso
Internet
Efetuar pedido
Matriz
Filiais
Cancelar pedido
Alterar pedido
Figura 3.11 Exemplo de uma Matriz Caso de Uso x Localizao do Negcio.

Uma vez levantadas as necessidades de computao de cada localizao do
negcio, pode-se avaliar qual a melhor estratgia para a distribuio de dados. Algumas
opes so manter todos os dados em uma nica base de dados centralizada,
descentralizar completamente os dados, ou usar uma abordagem de fragmentao.
Quando a estratgia de uma nica base de dados centralizada adotada, os dados
so mantidos em um servidor de dados central e todas as aplicaes que necessitem
acess-los devem fazer suas consultas e atualizaes no servidor central. Os benefcios
so numerosos, tais como: (i) os dados esto sempre atualizados e no h redundncia;
(ii) o projeto mais simples, tendo em vista que a segurana pode ser mantida
centralmente e nenhuma rotina de sincronizao requerida; e (iii) fcil fazer cpias
de segurana dos dados. Entretanto, h tambm desvantagens, tais como: (i) no permite
operao desconectada e, portanto, a disponibilidade do sistema fortemente afetada
pela comunicao de dados e pela disponibilidade do servidor de dados; (ii) o
desempenho do sistema tambm muito dependente da velocidade de comunicao de
dados.
Uma soluo diametralmente oposta consiste em ter os dados totalmente
descentralizados e replicados. Neste caso a base de dados completamente replicada em
todos os locais que dela necessitem. Atualizaes em um local podem ser irradiadas
(broadcast) para outros locais em tempo real. So benefcios dessa estratgia: (i) o
tempo de resposta no onerado pelo trfego em rede; e (ii) a disponibilidade tambm
tem sua dependncia diminuda em relao comunicao de dados. Contudo, h
diversos problemas, dentre eles: (i) o trfego global na rede aumenta devido replicao
de dados em todos os locais; (ii) rotinas complexas de sincronizao so necessrias
para manter as vrias cpias da base de dados atualizadas; (iii) podem surgir problemas
se o mesmo registro for atualizado em dois locais; (iv) se um dos servidores cair ou o
software de replicao falhar, pode ser difcil reconstruir o conjunto dos dados e
reaplicar atualizaes na ordem correta; (v) procedimentos de backup tornam-se mais
complexos, uma vez que no se tem uma viso clara de qual a base de dados principal;
e (vi) dados completamente replicados conduzem a uma redundncia desnecessria de
dados.
Uma abordagem intermediria entre a centralizao e a replicao total a
fragmentao de dados. A distribuio dos dados otimizada, de modo que apenas os
dados necessrios para cada localidade so mantidos localmente. A fragmentao pode
ser:
Vertical: ocorre quando apenas certos elementos (classes / atributos das

classes) so fisicamente distribudos a locais remotos. Cada localidade possui

44
apenas aqueles elementos que so requeridos pelos casos de uso que l

ocorrem. Isto reduz trfego em rede, pois apenas os elementos de dados
necessrios precisam ser sincronizados com outros locais. Entretanto, essa
estratgia pode ser bastante complexa para gerenciar. Os procedimentos de
replicao devem ser capazes de sincronizar atualizaes atributo-a-atributo
em diferentes locais.
Horizontal: ocorre quando apenas certas instncias de uma classe so

fisicamente distribudas a locais remotos. Esta estratgia empregada
tipicamente quando localidades tm seus prprios dados que no so
manipulados em outras localidades. Cada localidade tem sua prpria cpia do
banco de dados. Os esquemas so idnticos, mas os dados que povoam as
bases de dados so diferentes. Geralmente, h uma base de dados principal
que contm todos os registros. Assim como a fragmentao vertical, a
fragmentao horizontal diminui o trfego na rede, eliminando transferncias
de dados desnecessrias. Contudo, o processo de sincronizao tambm de
alguma forma complicado, principalmente quando diferentes locais
compartilham registros.
Hbrida: bases de dados distribudas compartilham os mesmos tipos de

entidades lgicas, mas possuem diferentes atributos e instncias. Cada local
possui apenas os atributos e instncias que so realmente necessrios para os
eventos que ali ocorrem. fcil perceber que tal estratgia pode ser muito
difcil de gerenciar.
3.5.3 Introduzindo Novos Casos de Uso e Organizando Casos de Uso

Em decorrncia de requisitos tecnolgicos, novos casos de uso podem ser
necessrios, tais como casos de uso para apoiar atividades de segurana, limpeza,
reorganizao, cpia e restaurao de arquivos, e facilidades de ajuda (help).
bom lembrar que todo caso de uso tecnolgico projetado decorrente de um
requisito tecnolgico acrescido ao sistema, mas nem todo requisito tecnolgico
necessariamente implica na criao de um caso de uso. Alguns atributos de qualidade,
tais como desempenho e usabilidade, so tipicamente incorporados a casos de uso do
sistema j existentes.
Alm disso, til definir tarefas ou unidades de execuo, isto , conjuntos de
casos de uso agrupados em uma unidade, do ponto de vista de execuo. Alguns
critrios que podem ser usados para agrupar casos de uso em unidades de execuo
incluem:
Quando existir uma classe de usurios especfica, cujos casos de uso

autorizados sejam de seu nico acesso e interesse.
Em situaes de disperso geogrfica em que diferentes localidades tm

demandas diferentes de casos de uso.
No h memria disponvel suficiente para que o sistema como um todo

execute eficientemente.

45
Casos de uso so realizados uma nica vez (ou muito poucas vezes), tais como
converso de dados e instalao do sistema.
A principal estratgia para agrupar casos de uso em unidades de execuo consiste

em fazer um levantamento sobre o modo de utilizao do sistema, o tempo de resposta
esperado, o tamanho e nmero de casos de uso, aspectos de segurana e facilidade de
uso. Alm disso, deve-se levar em conta que essas unidades de execuo podem ser
completamente separadas, dando origem a diferentes programas executveis, ou que
elas podem apenas ter sua ligao sendo feita em tempo de execuo.
3.6 Aplicaes Web e Tecnologias Relacionadas

No incio, a World Wide Web, ou simplesmente Web, era um ambiente que
hospedava documentos hipermdia estticos, que eram entregues diretamente a um
navegador do cliente como resposta a requisies HTTP (HyperText Transfer Protocol,
protocolo utilizado na Web). Com o surgimento da tecnologia CGI (Common Gateway
Interface) e de linguagens de programao para a Web, tais como PHP, ASP e Java
Servlets / JSP, o ambiente para desenvolvimento de aplicaes para Web se tornou mais
poderoso, permitindo o desenvolvimento de aplicaes de negcio. Em pouco tempo,
grandes sistemas comearam a ser desenvolvidos para a Web. Surgia, ento, o conceito
de aplicao Web (SOUZA, 2007) (CASTELEYN et al., 2009).
De maneira simplista, uma aplicao Web consiste em um conjunto de pginas
Web para interao com o usurio, armazenando, processando e provendo informaes.
Hoje existe uma variedade de aplicaes Web, indo desde colees simples de pginas
estticas HTML at aplicaes corporativas distribudas usando a Web como plataforma
de execuo (CASTELEYN et al., 2009).
3.6.1 As Bases das Aplicaes Web
O protocolo HTTP (HiperText Transfer Protocol) o ingrediente mais bsico
sobre o qual a Web est fundamentada. Ele um protocolo de aplicaes clienteservidor que define um formato padro para especificar a requisio de recursos na
Web. Atravs dele, um usurio utilizando uma aplicao cliente (p.ex., um navegador)
pode requisitar recursos disponveis em um servidor remoto (p.ex., o servidor Web),
como ilustra a Figura 3.12. Tipicamente os recursos passados via HTTP so pginas
HTML, mas, de maneira mais geral, uma requisio pode estar relacionada a um
arquivo em qualquer formato armazenado no servidor Web ou invocao de um
programa a ser executado no lado do servidor. Uma vez que tais recursos esto
distribudos ao longo da Internet, necessrio um mecanismo de identificao que
permita localiz-los e acess-los. O identificador usado para referenciar esses recursos
uma URL (Uniform Resource Locator) (CASTELEYN et al., 2009).

46
Requisio HTTP
Cliente
(Navegador)
Recursos
Resposta HTTP
Servidor Web
Figura 3.12 Ciclo RequisioResposta de HTTP (adaptado de (CASTELEYN et

al., 2009))
Alm de gerenciar a requisio e a transferncia de recursos atravs do protocolo
HTTP, um navegador Web tambm trata da apresentao visual dos recursos. A
linguagem HTML (HyperText Markup Language) comumente usada para expressar o
contedo e a formatao visual de pginas Web. O navegador recebe como entrada o
contedo marcado, interpreta o significado das tags e transforma o contedo recebido
em um documento renderizado (CASTELEYN et al., 2009).
As primeiras pginas HTML eram caracterizadas por parcos recursos de
apresentao e interao. Entretanto, com a expanso e difuso da Web, documentos
simples logo se tornaram inadequados e novos requisitos de apresentao comearam a
surgir. Como avanos ao longo da linha de evoluo da Web podem ser citados o uso de
folhas de estilo para separar contedo e apresentao, e tecnologias para tornar clientes
Web dinmicos e capazes de suportar um conjunto mais rico de caractersticas de
apresentao e interatividade. Tais caractersticas englobam, dentre outros, a capacidade
de alterar dinamicamente as propriedades de apresentao de pginas Web e a
capacidade de executar pedaos da lgica de negcio no lado do cliente, usando
linguagens de script.
3.6.2 Aplicaes Web Dinmicas
Linguagens de script, tal como JavaScript, abriram espao para uma abordagem
de HTML dinmico. Um script de lado do cliente um programa interpretado e
executado pelo navegador quando uma pgina carregada ou quando o usurio invoca
algum evento sobre elementos de uma pgina. Eles representam a parte ativa dessa
abordagem, enquanto a linguagem de marcao HTML representa a parte esttica, a
qual est sujeita a alteraes dinmicas pela lgica do script. A combinao de scripts,
HTML e DOM (Document Object Model, uma plataforma e modelo independentes de
linguagem para representar documentos HTML e XML) ofereceu uma maneira eficaz
de implementar comportamentos dinmicos no navegador (CASTELEYN et al., 2009).
O estabelecimento de tecnologias XML e algumas extenses s arquiteturas
cliente-servidor tradicionais pavimentaram o caminho para o desenvolvimento de
pginas Web dinmicas, compostas em tempo de execuo a partir de contedo extrado
dinamicamente de uma fonte de dados, o qual usado para produzir a apresentao final
da pgina durante o voo (CASTELEYN et al., 2009).

47
A maneira mais simples de se construir dinamicamente uma pgina Web em

resposta a uma requisio HTTP deixar que o servidor HTTP delegue a recuperao
de dados dinmicos e a construo da pgina para um programa externo, que recebe
parmetros de entrada e gera uma pgina como sada. A invocao para o programa
externo ocorre quando a requisio HTTP vinda do navegador inclui uma URL
apontando para um programa ao invs de apontar para um documento esttico.
Para que o servidor se comunique com um programa externo, necessrio usar
uma interface padro, chamada Common Gateway Interface CGI. CGI permite que
um servidor Web invoque programas, chamados programas CGI, que so executados
durante o voo para dinamicamente construir a pgina. Um programa CGI pode fazer
consultas em uma base de dados para extrair os dados (que so usados, ento, para
montar a pgina HTML) e pode armazenar entradas de dados do usurio na base de
dados, inserindo ou atualizando dados nessa base. A Figura 3.13 ilustra os passos que
caracterizam a gerao dinmica de pginas com CGI (CASTELEYN et al., 2009).
Requisio
Chamada de Programa
Cliente
(Navegador)
Script CGI
Resposta
Servidor Web
Resultado
Figura 3.13 Construo dinmica de pginas Web em resposta a uma requisio

HTTP (adaptado de (CASTELEYN et al., 2009))
Primeiro, o cliente envia uma requisio HTTP para o servidor, requisitando a
execuo de um programa CGI. A requisio pode incluir dados de entrada. Usando
uma interface CGI, o servidor HTTP invoca o programa externo (i.e., o script CGI),
passando os parmetros de entrada. O programa externo, ento, constri a pgina e a
retorna como resultado para o servidor HTTP. O servidor HTTP monta a resposta
HTTP, a qual embute a pgina construda pelo programa externo, e a envia de volta ao
cliente (CASTELEYN et al., 2009).
Entretanto, a arquitetura CGI tem algumas desvantagens significativas, que a
tornam impraticvel na maioria das situaes. O principal problema o desempenho:
para cada requisio HTTP para um script CGI, o servidor Web inicia um novo
processo, o qual terminado no fim da execuo do script. A criao e a finalizao de
processos so atividades muito custosas, as quais se tornam rapidamente um gargalo.
Alm disso, o fato de terminar o processo aps a execuo do script CGI, aps cada
requisio, impede que as informaes sobre a interao com o usurio sejam mantidas
entre requisies de usurio consecutivas (a menos que elas sejam armazenadas em uma
base de dados), o que tem impacto novamente no desempenho (CASTELEYN et al.,
2009).

48
3.6.3 Extenses de Servidores Web

As limitaes da arquitetura CGI podem ser superadas pela extenso das
capacidades do servidor Web com uma mquina capaz de executar aplicaes, na qual
os programas para computar as respostas HTTP podem ser executados de maneira
eficiente, sem serem terminados aps cada requisio, e os recursos compartilhados
podem ser associados a uma ou mais aplicaes e concorrentemente acessados por
mltiplos usurios. Tal arquitetura estendida, ilustrada na Figura 3.14, tipicamente
oferece, ainda, uma memria para armazenar dados da sesso, cuja durao atravessa
mltiplas requisies HTTP (CASTELEYN et al., 2009).
Aplicaes
Requisio
Cliente
Resposta
Servidor Web
Servidor de Aplicao
Figura 3.14 Arquitetura de Servidor Web estendida (adaptado de

(CASTELEYN et al., 2009))
Um exemplo de arquitetura de servidor Web estendida a API Java Servlet, que
associa o servidor Web com uma mquina virtual Java (Java Virtual Machine JVM).
A JVM suporta a execuo de um programa Java especial, o container servlet, que por
sua vez responsvel por gerenciar dados de sesso e executar servlets Java. Servlets
Java so programas Java que podem ser invocados por requisies HTTP para
dinamicamente construir pginas. O container servlet responsvel por receber a
requisio HTTP do servidor Web, criar a sesso de usurio quando necessrio, invocar
o servlet associado requisio e passar para ele os parmetros da requisio na forma
de objetos Java (CASTELEYN et al., 2009).
O uso de scripts de lado do cliente permite construir pginas dinmicas contendo
instrues de programao dentro de templates de pgina HTML. Essas instrues so
executadas por um programa do servidor. Assim, quando uma requisio HTTP referese a um template, o seguinte processo ocorre: (i) o servidor Web encaminha o template
para a mquina de script; (ii) a mquina de script processa as instrues embutidas,
determina as partes dinmicas da pgina e as inclui no resultado, uma pgina HTML
plana; (iii) a pgina gerada retornada para o servidor Web; (iv) este, por sua vez,
encaminha a pgina para o cliente (navegador), onde apresentada (renderizada). Esse
processo completamente transparente para o navegador que recebe a pgina HTML
resultante, cujo cdigo idntico ao de uma pgina esttica. A Figura 3.15 ilustra o
processo descrito acima (CASTELEYN et al., 2009).

<HTML>
...
<%>
script code
</%>
</HTML>
Template
de Pgina
49
<HTML>
<BODY>
...
</BODY>
</HTML>
Servidor Web
Pgina
HTML
Pgina
Apresentada
Mquina de Script
Figura 3.15 Execuo de um script em template de pgina (adaptado de

(CASTELEYN et al., 2009))
A despeito da similaridade, o estilo de codificao de scripts de lado do cliente
completamente diferente do estilo de codificao de servlets. Um servlet contm
instrues para gerar a pgina inteira, enquanto um template de pgina contm HTML
regular junto com instrues de programao, as quais se limitam a computar a parte
varivel da pgina. Atualmente, existem diversas linguagens de script de lado do cliente
disponveis no mercado, dentre elas PHP, ASP e JSP. Uma pgina JSP, por exemplo,
composta por blocos de cdigo esttico e por pores de cdigo Java. Vale ressaltar,
contudo, que JSP , na verdade, uma extenso de servlets Java: na primeira vez que um
servidor Web (um container JSP) recebe uma requisio para uma pgina JSP, o
template JSP traduzido para um servlet, o qual compilado, armazenado em memria
principal e executado (CASTELEYN et al., 2009).
Ainda que os scripts de lado de cliente facilitem o desenvolvimento de
aplicaes Web dinmicas, necessrio misturar programao com contedo e
marcao. Assim, o programador e o designer grfico precisam trabalhar no mesmo
arquivo, o que limita a separao de preocupaes entre diferentes aspectos do
desenvolvimento Web: contedo esttico, apresentao (look and feel) e lgica de
programao (CASTELEYN et al., 2009).
As bibliotecas de tags de lado do cliente do um passo frente na separao de
contedo e marcao da programao de um template de pgina dinmica. A ideia por
trs dessa abordagem est em camuflar o cdigo de programao usando tags XML, as
quais podem ser inseridas como elementos de marcao regulares, mas que so
executadas por um interpretador em tempo de execuo. Em JSP, por exemplo, tags
customizadas so usadas para invocar JavaBeans, componentes Java. O cdigo do
JavaBean ocultado do desenvolvedor da pgina. Ele vai apenas invocar os mtodos
providos pelas correspondentes classes Java (CASTELEYN et al., 2009).
Existem outras tecnologias que tambm permitem a implementao de lgica de
negcio executando no lado do cliente, tais como Java applets e ActiveX. Entretanto,
enquanto as linguagens de script so integradas aos navegadores, essas tecnologias no
so integradas a eles e, portanto, no permitem HTML dinmico. Ao contrrio,
aplicaes dessa natureza representam pequenas aplicaes isoladas que so embutidas

50
na marcao HTML de uma pgina Web, baixadas quando a pgina acessada, e

executadas localmente quando a pgina exibida. A execuo de Java applets, contudo,
requer a instalao da mquina virtual Java na mquina cliente, enquanto os controles
ActiveX so suportados basicamente pelo navegador Internet Explorer (CASTELEYN
et al., 2009).
As extenses de servidor Web descritas anteriormente oferecem um eficiente
meio de implementar aplicaes Web com estado, i.e., aplicaes baseadas em HTTP
capazes de reter o estado da interao com o usurio. Informaes de estado podem ser
armazenadas no lado do cliente, na forma de cookies, ou do lado do servidor, na forma
de dados da sesso (CASTELEYN et al., 2009).
3.6.4 Arquiteturas Multicamadas de Aplicaes Web
Aplicaes Web de grande escala, tais como portais e aplicaes de comrcio
eletrnico, tipicamente esto expostas a um grande nmero de requisies concorrentes
e devem exibir um alto nvel de disponibilidade. Para tal, so necessrias arquiteturas de
software modulares e multicamadas, nas quais os diferentes componentes possam ser
facilmente replicados para aumentar o desempenho e evitar pontos de falha
(CASTELEYN et al., 2009). Assim, uma aplicao Web pode ser considerada um tipo
de sistema distribudo, com uma arquitetura cliente-servidor com as seguintes
caractersticas (DI LUCCA; FASOLINO, 2006 apud MARINHO; RESENDE, 2011):
Grande nmero de usurios distribudos;
Ambiente de execuo heterogneo composto de vrios tipos de hardware,

conexes de rede, sistemas operacionais, servidores e navegadores;
Natureza extremamente heterognea, que depende da grande variedade de

componentes que a constituem. Esses componentes podem ser escritos em
diferentes linguagens de programao e serem de natureza diferente, tais como
componentes legados e componentes de prateleira (COTS);
Habilidade de gerar componentes em tempo de execuo, de acordo com a

entrada do usurio e status do servidor.
Arquiteturas de software de aplicaes Web dessa natureza so normalmente

organizadas em trs camadas de software (CASTELEYN et al., 2009):
Camada de Apresentao: responsvel por processar as requisies vindas do

cliente e construir as pginas HTML. desenvolvida usando as extenses de
servidores Web discutidas anteriormente, as quais so capazes de construir
dinamicamente as pginas HTML a serem enviadas como resposta para o
cliente. Essas pginas so geradas tomando por base os dados produzidos
pela execuo de componentes de negcio, que esto na camada abaixo.
Camada de Lgica de Negcio: responsvel por executar componentes que

realizam a lgica de negcio da aplicao. Para tal, comunica-se com a
camada de gerncia de recursos para acessar bases de dados persistentes,
sistemas legados ou para invocar servios externos.
Camada de Gerncia de Recursos: representa o conjunto de servios

oferecidos por diferentes sistemas, tais como aqueles suportando o acesso a

51
bases de dados, a outros sistemas ou, de maneira geral, a servios Web

externos.
Para tornar real essa arquitetura de software de trs camadas, necessrio um
ambiente de execuo suportando comunicao em camadas. A Figura 3.16 mostra um
ambiente dessa natureza. O servidor Web recebe a requisio HTTP oriunda do cliente e
a transforma em uma requisio para o motor de script. Este executa o programa
associado com a URL requisitada, o qual pode incluir chamadas para componentes de
negcio hospedados no servidor de aplicao. Os componentes de negcio, por sua vez,
enviam consultas para servidores de dados, operam sobre seus resultados e geram uma
resposta para o motor de script. Os dados so integrados pelo motor de script a uma
pgina HTML, a qual enviada de volta ao cliente pelo servidor Web. O ambiente de
execuo ilustrado na Figura 3.16 tem muitas implementaes comerciais, dentre elas as
plataformas Java EE (Java Enterprise Edition) e .NET (CASTELEYN et al., 2009).
1. Requisio
HTTP
2. Requisio
de Script
3. Chamada de
Componente
4. Consulta
Servidor de
Dados
Cliente
8. Resposta
(Navegador)
HTTP
Servidor
Web
7. Pgina
HTML
Motor de
Script
6. Resposta
5. Resultados
Servidor de
Aplicao
Sistemas
Legados
Figura 3.16 Ambiente de Execuo para Arquitetura Multicamadas (adaptado

de (CASTELEYN et al., 2009))
A maior parte das aplicaes Web adota uma filosofia de cliente leve, na qual a
maior parte da lgica de negcio reside nos servidores. As aplicaes Web tradicionais
foram classificadas por Tilley e Huang (2001, apud MARINHO; RESENDE, 2011) em
trs classes com complexidade crescente:
A classe 1 constituda por aplicaes estticas implementadas em HTML e

que no tm interatividade com o usurio.
A classe 2 engloba as aplicaes Web que proveem interao do usurio com

pginas HTML dinmicas e que associam aes implementadas em scripts a
eventos gerados pelo usurio.
A classe 3 rene as aplicaes de contedo dinmico, cujas pginas podem

ser criadas em tempo de execuo, de acordo com a interao do usurio
com a aplicao.
Contudo, essas aplicaes ainda permitem uma interao pouco flexvel. Mais
recentemente, com a implementao da API XMLHttpRequest dentro da maioria dos
navegadores, scripts de lado do cliente passaram a poder fazer, tambm, requisies
HTTP para um servidor Web de maneira transparente em background e

52
independentemente da interao com o usurio. O uso combinado de JavaScript,

XMLHttpRequest, XML e DOM conhecido como AJAX (Asynchronous JavaScript
and XML). Atualmente AJAX quase um sinnimo de aplicaes Web distribudas
entre cliente e servidor. Essa tecnologia permitiu que desenvolvedores tornassem a
maior parte do HTML dinmico, j que passou a ser possvel carregar contedo do
servidor Web e adicion-lo dinamicamente pgina sendo exibida no navegador sem
que este ltimo tenha que dar um refresh ou recarregar a pgina inteira. Isso
finalmente levou a aplicaes mais ergonmicas e responsivas, ditas Aplicaes Ricas
para Internet (Rich Internet Applications - RIAs) (CASTELEYN et al., 2009).
3.6.5 Aplicaes Ricas para Internet - RIAs
O termo RIA designa uma classe de solues caracterizada pelo propsito
comum de adicionar novas caractersticas s aplicaes Web tradicionais (MARINHO;
RESENDE, 2011). Essas caractersticas incluem (CASTELEYN et al., 2009):
Interfaces com o usurio sofisticadas, incluindo facilidades do tipo arrastar e

soltar (drag & drop), animaes e sincronizao multimdia, buscando dar s
aplicaes Web uma interatividade semelhante das aplicaes desktop.
Mecanismos para minimizar a transferncia de dados entre cliente e servidor,

movendo a gerncia das camadas de apresentao e interao do servidor
para o cliente.
Armazenamento e processamento de dados tanto no lado do cliente quanto

no lado do servidor, buscando melhor utilizar a capacidade de computao
do cliente.
Do ponto de vista da distribuio de dados, nas RIAs, os dados da aplicao

podem ser armazenados tanto no cliente quanto no servidor. No caso dos dados serem
armazenados no cliente, estes so enviados ao servidor ao final de cada operao. Do
ponto de vista da distribuio da lgica de negcio, nas RIAs tanto o cliente quanto o
servidor podem realizar operaes complexas. Do ponto de vista da comunicao
cliente-servidor, as RIAs permitem tanto a comunicao sncrona quanto a comunicao
assncrona (MARINHO; RESENDE, 2011).
A distribuio de dados e funcionalidades entre cliente e servidor amplia as
caractersticas dos eventos produzidos. Estes podem ser originados, detectados e
processados de diferentes formas. Isso permite atualizao parcial de pgina
(comunicao delta), alteraes em elementos individuais da pgina (Page
Rearrangement) e alteraes na estrutura da pgina (Display Morphing). Contudo, h
um aumento do esforo de desenvolvimento, j que, conforme discutido na Seo 3.5.2,
h necessidade de replicao de dados, polticas de alocao e sincronizao, bem como
rotinas para manter a consistncia dos dados, uma vez que os clientes precisam manter
dados (MARINHO; RESENDE, 2011).
Finalmente, do ponto de vista de aprimoramento da interface com o usurio, as
RIAs possibilitam apresentao e interaes com o usurio avanadas e menor tempo de
resposta. A aplicao pode operar como aplicao de pgina nica, evitando
atualizaes da pgina inteira e permitindo carregamento progressivo de elementos da

53
pgina. Contudo, pode gerar problemas de desempenho e de compatibilidade com

navegadores (MARINHO; RESENDE, 2011).
A estrutura de pgina nica, em contraposio estrutura de mltiplas pginas
das aplicaes Web tradicionais, segue um estilo arquitetnico denominado SPIAR
(Single Page Internet Application aRchitecture). Esse estilo abstrai as caractersticas
comuns de vrios frameworks e enfatiza o desenvolvimento baseado em componentes
de interfaces com o usurio, a comunicao delta entre componentes cliente/servidor e a
notificao de mudanas de estado atravs dos componentes. A comunicao delta
aquela em que apenas informaes sobre estado so trocadas entre o cliente e o
servidor, evitando o fluxo de informaes redundantes. Segundo Mesbah e van Deursen
(MESBAH; VAN DEURSEN, 2008 apud MARINHO; RESENDE, 2011), essas
caractersticas do estilo arquitetnico SPIAR tm por objetivo a melhoria da
interatividade do usurio, a diminuio da latncia percebida pelo usurio, o aumento da
coerncia dos dados e maior facilidade de desenvolvimento.
RIAs foram concebidas primeiramente pela Adobe, quando da introduo de
produtos para autoria multimdia, como Flash (CASTELEYN et al., 2009). Atualmente,
existem vrias tecnologias (AJAX, Silverlight, Flex, AIR, Ruby on Rails, JavaFX) e
diversos patterns (p.ex., AjaxPatterns - http://ajaxpatterns.org/) disponveis para esse
tipo de aplicao (MARINHO; RESENDE, 2011).
Em suma, as aplicaes Web passaram a poder ter partes da lgica de aplicao
no lado do cliente, mudando o paradigma cliente-servidor estrito das primeiras
aplicaes Web em direo a um paradigma de sistemas distribudos em que a distino
tradicional entre clientes e servidores cada vez mais turva. A lgica de aplicao do
lado do cliente no mais apenas usada para enriquecer a camada de apresentao com
caractersticas de interfaces com o usurio dinmicas; ao contrrio, ela parte da lgica
de negcio global da aplicao (CASTELEYN et al., 2009).
Conforme discutido na Seo 3.2, o termo aplicaes web envolve diversas
subcategorias de aplicaes, tais como websites informativos, aplicaes transacionais,
e portais. Neste texto, no entanto, o foco est em uma categoria especfica de aplicaes
Web: os Sistemas de Informao Baseados na Web.
3.7 Tticas para Tratar Atributos de Qualidade

Na fase de projeto, requisitos no funcionais tm de ser incorporados ao projeto
de software, uma vez que a qualidade de um sistema de software depende fortemente de
atributos de qualidade que vo alm dos requisitos funcionais. O projetista deve estar
atento aos atributos de qualidade que o sistema ter de atender desde o incio do projeto,
ou seja, desde o projeto da arquitetura.
Conforme discutido no Captulo 2, so as consideraes de negcio que
determinam quais atributos de qualidade devero ser acomodados em um sistema. Alm
disso, esses atributos impem requisitos muitas vezes conflitantes e necessrio
estabelecer prioridades no tratamento e polticas para troca de prioridades, sabendo que,
ao se melhorar o grau de atendimento de certo atributo de qualidade, estar-se-, muitas
vezes, comprometendo o nvel de atendimento de outros.

54
Entender os atributos de qualidade e definir os nveis em que eles devem ser

atingidos muito importante. Contudo, necessrio definir como atingir esses nveis.
Assim, durante o projeto da arquitetura deve-se definir que estratgias sero aplicadas
para atingir essas metas.
Bass, Clements e Kazman (2003) enumeram um conjunto de tticas que podem
ser aplicadas para tratar certos atributos de qualidade. Uma ttica, neste contexto, uma
deciso de projeto que influencia o controle de certo atributo de qualidade. Uma coleo
de tticas define uma estratgia de projeto arquitetnico. A seguir, algumas dessas
tticas so brevemente discutidas, bem como abordagens propostas por outros autores
para tratar requisitos no funcionais.
3.7.1 Confiabilidade
Um defeito (fault) uma imperfeio do sistema e, em geral, refere-se a algo que
est implementado de maneira incorreta. Uma falha (failure) um resultado incorreto,
visvel, provocado por um defeito (KOSCIANSKI; SOARES, 2006). Uma falha ocorre
quando o sistema no entrega mais um servio consistente com sua especificao e essa
falha perceptvel ao usurio (BASS; CLEMENTS; KAZMAN, 2003). Assim, defeitos
(ou uma combinao de defeitos) podem provocar a ocorrncia de falhas. Contudo, os
defeitos podem existir sem provocarem falhas.
Recuperao e reparo so importantes aspectos para a confiabilidade. Todas as
abordagens de confiabilidade envolvem alguma combinao de redundncia,
monitorao da sade do sistema para detectar falhas e alguma forma de recuperao a
ser aplicada quando uma falha detectada (BASS; CLEMENTS; KAZMAN, 2003).
Assim, as tticas de confiabilidade apresentadas em (BASS; CLEMENTS; KAZMAN,
2003) so divididas em trs grupos: tticas de deteco de falhas, tticas de recuperao
de falhas e tticas de preveno de falhas. A Tabela 3.1 apresenta as tticas de
confiabilidade propostas por esses autores.
Tabela 3.1 Tticas de Confiabilidade (BASS; CLEMENTS; KAZMAN, 2003).

Deteco de Falha
Silvo/Eco (Ping/echo)
Um componente envia um silvo (som agudo prolongado) e espera receber um eco de volta, dentro de um tempo predefinido, do componente
sendo examinado. Ex.: clientes enviam um silvo para verificar se o servidor e o caminho de comunicao at ele esto operando dentro do limites
de desempenho esperados.
Batida de Corao
(Heartbeat)
Um componente emite mensagens peridicas (batida de corao) e outro componente as escuta. Se a batida de corao falhar, assume-se que o
componente de origem falhou e um componente de recuperao de falha notificado.
Excees (Exceptions)
Uma exceo gerada quando uma falha detectada. Um manipulador de exceo ento acionado para trat-la. O manipulador de exceo
opera dentro do mesmo processo que gerou a exceo e geralmente realiza uma transformao da falha em uma forma que possa ser processada.
Votao (Voting)
Processos rodando em processadores redundantes recebem entradas equivalentes e computam a sada que enviada para um votante (voter). Se o
votante detectar um comportamento desviante de um dado processador, ele gera uma falha no correspondente componente.
Recuperao de Falha
Redundncia Ativa
(Active Redundancy)
Componentes redundantes respondem a eventos em paralelo. Apenas a resposta de um deles utilizada (geralmente o primeiro a responder) e o
restante descartado. Em sistemas distribudos que precisam de alta disponibilidade, a redundncia pode ocorrer nos caminhos de comunicao.
Redundncia Passiva
(Passive Redundancy)
Um componente (o principal) responde aos eventos e informa os demais (os componentes em espera standbys) sobre as atualizaes de estado
que ele fez. Quando uma falha ocorre, o sistema precisa primeiro garantir que o estado de backup suficientemente recente para prosseguir.
Sobressalente (Spare)
Uma plataforma de computao sobressalente em espera configurada para substituir componentes com falha. Essa plataforma tem de ser
iniciada com a configurao apropriada e o estado recuperado. Para tal, periodicamente o estado do sistema deve ser armazenado, bem como se
devem registrar as alteraes feitas no dispositivo de persistncia.
Operao em Sombra
(Shadow Operation)
Um componente que falhou anteriormente, para voltar a executar normalmente, precisa primeiro rodar em modo sombra por um pequeno
perodo de tempo para garantir que ele tem o mesmo comportamento do componente que est funcionando correntemente.
Ressincronizao de
Estado (State
Resynchronization)
As tticas de redundncia ativa e passiva requerem que um componente sendo restaurado tenha seu estado atualizado antes de retornar ao
servio.
Ponto de Verificao /
Reverso (Checkpoint /
Rollback)
Um ponto de verificao, criado periodicamente ou em resposta a eventos especficos, registra um estado consistente. O sistema, aps a
ocorrncia de uma falha, deve ser restaurado usando um ponto de verificao de um estado consistente e um registro (log) das transaes que
ocorreram aps o ponto de verificao.
Tabela 3.1 Tticas de Confiabilidade (BASS; CLEMENTS; KAZMAN, 2003) (continuao).

Preveno de Falha
Retirada de Servio
(Removal from service)
Um componente removido do sistema em operao para ser submetido a atividades que previnam falhas antecipadamente. Ex.: reiniciar um
componente para evitar, por exemplo, estouro de pilha.
Transaes
(Transactions)
Uma transao a agregao de diversos passos sequenciais de modo que o pacote como um todo possa ser desfeito de uma s vez. Transaes
so usadas para prevenir que dados sejam afetados caso um dos passos do processo falhe, bem como para prevenir colises entre threads
simultneas acessando os mesmos dados.
Monitor de processo
(Process monitor)
Uma vez que uma falha detectada em um processo, um processo de monitoramento pode excluir o processo que no est executando e criar
uma nova instncia do mesmo.

57
3.7.2 Desempenho
Desempenho est dentre os mais importantes requisitos no funcionais. Ele
depende fortemente da interao (e do tipo da interao) existente entre os componentes
de um sistema e, portanto, est muito associado arquitetura do mesmo. Contudo,
geralmente difcil lidar com este atributo de qualidade, uma vez que ele conflita com
vrios outros, tais como confiabilidade e manutenibilidade. De maneira geral, requisitos
de desempenho impem restries relativas velocidade de operao de um sistema.
Isso pode ser especificado em termos de (MENDES, 2002):
Requisitos de tempo de resposta: especificam o tempo de resposta aceitvel para
certas funcionalidades do sistema;
Requisitos de processamento (throughput): especificam restries relativas
quantidade de processamento (p.ex., nmero de transaes) realizada em um
determinado perodo de tempo;
Requisitos de temporizao: especificam quo rapidamente o sistema deve
coletar dados de entrada de sensores, antes que novas leituras sejam feitas,
sobrescrevendo os dados anteriores;
Requisitos de recursos: estabelecem condies (memrias principal e secundria,
velocidade do processador etc.) para o bom funcionamento do sistema.
Bass, Clements e Kazman (2003) listam diversas tticas para tratar requisitos de
desempenho. O propsito dessas tticas gerar uma resposta a um evento que chega ao
sistema dentro de alguma restrio de tempo. Aps a chegada do evento, o sistema pode
estar processando sobre esse evento ou o processamento pode estar bloqueado por
alguma razo. Assim, h dois fatores principais que influenciam o tempo de resposta:
consumo de recursos e tempo de bloqueio. Recursos incluem processadores, bases de
dados, redes de comunicao e memria. Um processamento pode estar impedido de
usar um recurso devido disputa pelo mesmo, devido ao fato do recurso estar
indisponvel ou porque a computao depende do resultado de outros componentes que
no esto disponveis. Com base nessas consideraes, as tticas de desempenho
propostas so agrupadas em:
Tticas relativas demanda de recursos: visam tentar diminuir a demanda por

recursos. Como os fluxos de eventos so a fonte da demanda por recursos, essas
tticas se preocupam em diminuir a frequncia da ocorrncia de eventos ou a
quantidade de recursos consumidos por cada requisio.
Tticas relativas gerncia de recursos: visam gerenciar os recursos,

normalmente tornando mais recursos disponveis, de modo a melhorar o
desempenho.
Tticas relativas arbitragem de recursos: sempre que houver disputa por

recursos, necessrio escalon-los. Processadores, buffers e redes so
escalonados. Assim, essas tticas referem-se escolha da poltica de
escalonamento compatvel com cada recurso, visando melhorar o desempenho.
A Tabela 3.2 apresenta algumas das tticas de desempenho propostas em (BASS;

CLEMENTS; KAZMAN, 2003).
Tabela 3.2 Tticas de Desempenho (BASS; CLEMENTS; KAZMAN, 2003).

Demanda de Recursos
Aumentar a eficincia
computacional
Uma forma de diminuir o tempo de resposta consiste em aperfeioar os algoritmos usados em partes crticas do software.
Reduzir overhead
computacional
O uso de intermedirios, to importantes para a manutenibilidade, aumenta o consumo de recursos no processamento de um evento e, portanto,
remov-los pode ajudar a diminuir o tempo de resposta. Consideraes anlogas valem para camadas, sobretudo quando utilizada uma
arquitetura em camadas fechada.
Reduzir o nmero de
eventos processados
Se for possvel reduzir a frequncia de amostragem na qual variveis do ambiente so monitoradas, ento a demanda pode ser reduzida.
Quando no se tem controle sobre a chegada de eventos gerados externamente, as solicitaes podem ser tratadas com uma frequncia menor,
com perda de algumas requisies.
Gerncia de Recursos
Introduzir concorrncia
Concorrncia pode ser introduzida, processando diferentes conjuntos de eventos em diferentes linhas de controle (threads) ou criando linhas de
controle adicionais para diferentes conjuntos de atividades. Uma vez introduzida concorrncia, balancear a carga importante para explor-la
de maneira tima. Contudo, essa ttica s pode ser aplicada se as requisies puderem ser processadas em paralelo.
Manter mltiplas rplicas

de dados e servios
O propsito de uma rplica reduzir a conteno que ocorreria se todas as computaes ocorressem em um computador central. O uso de
cache e fragmentao de bases de dados so exemplos dessa ttica. Caching uma ttica na qual dados so replicados para reduzir conteno.
Uma vez que, neste contexto, os dados colocados em cache so cpias de dados existentes, manter as cpias consistentes e sincronizadas
torna-se uma responsabilidade do sistema.
Aumentar a disponibilidade
de recursos.
Processadores mais rpidos, processadores adicionais, memria adicional e redes mais rpidas so tticas para aumentar a disponibilidade de
recursos.
Arbitragem de Recursos
Escolher poltica de
escalonamento
Todas as polticas de escalonamento atribuem prioridades. Alm disso, para que um evento de mais alta prioridade seja disparado, necessrio
interromper o processo usurio corrente do recurso (preempo). Algumas polticas comuns de escalonamento so: FIFO (first-in first out),
prioridades fixas, prioridades dinmicas e escalonamento esttico.

59
3.7.3 Segurana
A segurana tem como objetivo no permitir que pessoas ou sistemas no
autorizados tenham acesso a eventos ou a dados do sistema. Para controlar o acesso,
necessrio identificar, autenticar e autorizar usurios. A identificao se d atravs de
uma forma unvoca, ou seja, que identifique apenas um usurio. A autenticao consiste
em comprovar que o usurio mesmo quem ele diz ser na identificao, sendo feita, por
exemplo, por meio de uma senha. Finalmente, a autorizao dada ao usurio, ou a uma
classe de usurios, dando acesso a determinadas funcionalidades do sistema (XAVIER;
PORTILHO, 1995).
Bass, Clements e Kazman (2003) listam algumas tticas para prover segurana,
agrupadas em tticas para resistir a ataques, tticas para detectar ataques e tticas para
recuperar o sistema de ataques. A Tabela 3.3 apresenta as tticas de segurana propostas
por esses autores.
Para tratar aspectos relativos segurana, casos de uso tm de ser adicionado ao
modelo de casos de uso do sistema, de modo a permitir a definio de classes de
usurios e seus perfis, incluso, excluso e alterao de usurios, alm, claro, das
atividades de autenticao e autorizao de usurios. Uma matriz Caso de Uso x Classe
de Usurio pode ser utilizada para documentar o nvel de autorizao adotado no
projeto, como ilustra a Figura 3.7.
Classes de Usurios
Casos de Uso
Cliente
Efetuar pedido
Gerente
Funcionrio
Cancelar pedido
Alterar pedido
Solicitar relatrio de pedidos
Figura 3.7 Exemplo de uma Matriz Caso de Uso x Classe de Usurio.

A auditoria da ocorrncia de violaes tambm requer novas funcionalidades.
Quando for necessrio um nvel maior de segurana, importante criar um
procedimento de monitorao que registre os usurios que acessaram o sistema e os
casos de uso por eles realizados. Um arquivo de histrico (log) deve ser mantido e deve
ser passvel de consulta. O mesmo ocorre em relao restaurao do estado do
sistema; ou seja, funcionalidades devem ser providas para tal.
Tabela 3.3 Tticas de Segurana (BASS; CLEMENTS; KAZMAN, 2003).

Resistir a Ataques
Autenticar usurios
Autenticao diz respeito a garantir que um usurio ou computador remoto realmente quem diz ser. Senhas, certificados digitais e identificao
biomtrica so alguns meios de se prover autenticao.
Autorizar usurios
Autorizao diz respeito a garantir que um usurio autenticado tenha o direito de acessar e modificar tanto dados quanto servios. Isso feito
normalmente provendo alguns padres de controle de acesso dentro do sistema. O controle de acesso pode ser por usurio ou classe de usurio.
Classes de usurios podem ser definidas por grupos de usurios, por papis de usurio ou por listas de indivduos.
Manter confidencialidade
dos dados
Dados devem ser protegidos contra acesso no autorizado. Confidencialidade normalmente atingida aplicando alguma forma de criptografia a
dados e links de comunicao. Criptografia prov uma proteo extra para dados mantidos em bases de dados, alm da autorizao. J links de
comunicao tipicamente no tm controles de autorizao e, portanto, a criptografia a nica proteo neste caso.
Manter integridade dos

dados
A integridade dos dados tambm deve ser garantida. Para verificar a integridade, informao redundante, tal como soma de verificao, pode ser
codificada junto aos dados.
Limitar exposio
A alocao de servios a servidores pode ser feita de modo que apenas servios limitados estejam disponveis em cada servidor.
Limitar acesso
Firewalls podem ser usados para restringir o acesso com base em fonte de mensagens ou porta de destinao. Mensagens de fontes
desconhecidas podem ser uma forma de ataque. Contudo, nem sempre possvel limitar o acesso a fontes conhecidas. Um site web pblico, por
exemplo, pode esperar receber solicitaes de fontes desconhecidas.
Detectar Ataques
Sistema de deteco de
intruso
Sistemas de deteco de intruso funcionam comparando padres de trfego de rede. No caso de deteco de mau uso, o padro de trfego
comparado com padres histricos de ataques conhecidos. Detectores de intruso tm de ter, dentre outros, algum tipo de sensor para detectar
ataques, bases de dados para registrar eventos para posterior anlise, ferramentas para anlise e um console de controle que permita ao analista
modificar aes de deteco de intruso.
Recuperar-se de Ataques
Restaurar estado
As tcnicas de recuperao de falhas sugeridas nas tticas de confiabilidade podem ser aplicadas, j que elas se propem a restaurar um estado
consistente a partir de um estado inconsistente. Ateno especial deve ser dada manuteno de cpias redundantes de dados administrativos do
sistema, tais como senhas, listas de controle de acesso, servios de nomes de domnio e dados de perfis de usurios.
Manter uma trilha de

auditoria
Uma trilha de auditoria um registro das transaes aplicadas aos dados do sistema junto com informaes de identificao. Essas informaes
podem ser usadas para trilhar as aes do agressor, apoiar reconhecimento (provendo evidncia de que uma particular requisio foi feita) e
apoiar a recuperao do sistema. Trilhas de auditoria so frequentemente alvo de ataques e, portanto, devem ser mantidas de modo confivel.

61
3.7.4 Usabilidade
A usabilidade est preocupada com o quo fcil para o usurio realizar uma
tarefa desejada e o tipo de apoio provido pelo sistema ao usurio. Envolve, dentre
outros, aspectos relativos facilidade de entender, aprender e operar o sistema.
Bass, Clements e Kazman (2003) definiram tticas para apoiar a usabilidade, as
quais so organizadas em dois grandes grupos: tticas de tempo de execuo e tticas de
tempo de projeto. As tticas de tempo de execuo, como o prprio nome indica, se
referem ao apoio ao usurio durante a execuo do sistema. Uma vez que o sistema
estiver executando, a usabilidade reforada dando feedback ao usurio sobre o qu o
sistema est fazendo e provendo ao usurio a capacidade de entrar com comandos que
permitam operar o sistema de modo mais eficiente ou corrigir erros, tais como cancelar
e desfazer (BASS; CLEMENTS; KAZMAN, 2003).
As tticas de usabilidade em tempo de execuo so agrupadas em tticas para
apoiar iniciativas do usurio e tticas para apoiar iniciativas do sistema. Quando um
usurio toma uma iniciativa, o projetista projeta a resposta como se fosse uma outra
poro de funcionalidade (ex.: cancelar e desfazer). Quando o sistema toma a iniciativa,
ele precisa apoiar-se em alguma informao sobre o usurio, a tarefa sendo executada
pelo usurio ou sobre o estado do sistema. Assim, so tticas de apoio a iniciativas do
sistema (BASS; CLEMENTS; KAZMAN, 2003):
Manter um modelo da tarefa: o modelo da tarefa usado para determinar o

contexto, de modo que o sistema pode inferir o que o usurio est tentando fazer
e prover assistncia. Ex.: sabendo que frases comeam com letras maisculas,
um editor de texto pode corrigir um texto sendo digitado.
Manter um modelo do usurio: esse modelo mantm informaes sobre o

conhecimento que o usurio tem do sistema, sobre o comportamento do usurio
etc. Esse modelo usado para prover assistncia.
Manter um modelo do sistema: esse modelo mantm informaes sobre o

comportamento esperado do sistema, de modo a dar um feedback para o usurio.
Ex.: prever o tempo necessrio para completar uma atividade.
As tticas de usabilidade de tempo de projeto esto fortemente relacionadas s

tticas de manutenibilidade. So tticas dessa natureza:
Separar a interface do restante da aplicao. Diversos padres arquitetnicos

foram desenvolvidos para implementar essa ttica, dentre eles o padro ModeloViso-Controlador (MVC) (BASS; CLEMENTS; KAZMAN, 2003).
Prover ao usurio a capacidade de entrar com comandos que permitam operar o

sistema de modo mais eficiente, tal como permitir, sempre que possvel, a
entrada por meio de seleo ao invs da digitao de campos.
3.7.5 Manutenibilidade
Para se obter sistemas fceis de manter, deve-se, dentre outros, facilitar a
localizao das alteraes (analisabilidade), a realizao das alteraes
(modificabilidade) e os testes (testabilidade).

62
Bass, Clements e Kazman (2003) definiram diversas tticas para apoiar a

manutenibilidade, organizadas de acordo com suas metas, dentre elas:
Localizao de Alteraes: tem como objetivo reduzir o nmero de mdulos que

so diretamente afetados por uma alterao. Uma ttica desse grupo consiste em
manter a coerncia semntica, procurando garantir que um mdulo trabalha em
conjunto com outros, mas sem depender excessivamente deles (independncia
funcional, alta coeso, baixo acoplamento).
Preveno de efeito cascata: tem como objetivo limitar a abrangncia de uma

modificao somente aos mdulos localizados, evitando afetar outros mdulos
no diretamente envolvidos. So exemplos de tticas desse grupo: (i) ocultao
de informao; (ii) garantia das interfaces existentes; e (iii) uso de
intermedirios, tais como repositrios para dados e padres de projeto (design
patterns) para intermediar servios (p.ex., padro fachada, mediador etc.).
Tticas de Testabilidade: visam facilitar os testes de uma poro de software.

Dentro desse grupo, merecem destaque tticas relacionadas s entradas e sadas,
tais como: (i) separar interface da implementao, o que permite a substituio
da implementao para vrios propsitos de teste, tal como o uso de stubs; (ii)
(ii) registro e reproduo, que diz respeito a capturar a informao cruzando uma
interface (entradas e sadas) durante a operao normal em algum repositrio e
utiliz-la para testes.
3.7.6 Portabilidade
Para se obter sistemas fceis de portar, deve-se, dentre outros, facilitar a
instalao, a substituio de partes do sistema e a adaptao a diferentes plataformas. As
tticas de portabilidade esto bastante relacionadas s tticas de manutenibilidade. De
fato, algumas delas so as mesmas, tal como garantir interfaces existentes, usar
intermedirios e separar a interface da aplicao. Alm disso, o uso de linguagens,
bibliotecas e mecanismos de persistncia capazes de rodar em diferentes plataformas
operacionais uma importante ttica para tratar a portabilidade.
3.8 O Processo de Projeto de Software

Projetar a arquitetura de um software requer o levantamento de informaes
relativas plataforma de computao do sistema, as quais se somaro ao conhecimento
acerca dos requisitos funcionais e no funcionais, para embasar as decises relativas
arquitetura do sistema que est sendo projetado. De maneira geral, o processo de
projetar envolve os seguintes passos:
1. Levantar informaes acerca da plataforma de computao do sistema,
incluindo linguagem de programao a ser adotada, mecanismo de
persistncia e necessidades de distribuio geogrfica.
2. Com base nos requisitos, iniciar a decomposio do sistema em subsistemas,
considerando preferencialmente uma decomposio pelo domnio do
problema. Se na fase de anlise j tiver sido estabelecida uma decomposio
inicial em subsistemas, esta dever ser utilizada. Neste momento, deve-se

63
escolher um estilo arquitetnico (ou uma combinao adequada de estilos

arquitetnicos) para organizar a estrutura geral do sistema (Seo 3.3). Um
bom ponto de partida para essa escolha pode ser a classe de sistemas qual
pertence o sistema que est sendo projetado (Seo 3.2).
3. Priorizar os atributos de qualidade e definir quais deles guiaro o projeto da
arquitetura, ditos condutores da arquitetura (Seo 2.3).
4. Para cada atributo de qualidade, identificar tticas a serem aplicadas. Uma
vez que essas tticas podem levar a conflitos, procurar balance-las,
respeitando as prioridades estabelecidas no passo anterior (Seo 3.7).
5. Estabelecer uma arquitetura base, identificando tipos de mdulos e tipos de
relacionamentos entre eles, dados essencialmente pela combinao de estilos
arquitetnicos escolhidos.
6. Alocar requisitos funcionais (casos de uso) e no funcionais aos
componentes da arquitetura.
7. Avaliar a arquitetura, procurando identificar se ela acomoda tanto os
requisitos funcionais, quanto os atributos de qualidade, dando ateno
especial aos atributos considerados "condutores da arquitetura", ou seja,
aqueles de maior prioridade.
8. Uma vez definida a arquitetura em seu nvel mais alto, passar ao projeto de
seus elementos. Padres arquitetnicos so instrumentos muito valiosos para
o projeto dos componentes da arquitetura.
importante frisar que o processo descrito acima, ainda que descrito de forma
sequencial, um processo essencialmente iterativo. Por exemplo, a priorizao dos
atributos de qualidade pode levar a alteraes na combinao de estilos arquitetnicos
escolhido no passo anterior. O mesmo pode ocorrer em relao s tticas selecionadas.
Ainda, as tticas podem demandar o levantamento de novas informaes (passo 1). Ao
se avaliar a arquitetura (passo 7), pode-se concluir que ela no est satisfatria, sendo
necessrio retomar do incio.
Uma vez que neste texto o foco recai sobre sistemas de informao, algumas
diretrizes mais especficas podem ser providas:
Passo 1: ateno especial deve ser dada questo da distribuio geogrfica,

bem como para a topologia da arquitetura de hardware a ser adotada.
Aspectos discutidos nas sees 3.5 e 3.6 devem ser observados aqui.
Passo 2: uma combinao de parties e camadas tende a ser um bom ponto

de partida para a estruturao global de sistemas de informao. Parties
podem ser derivadas a partir do domnio do problema, levando-se em conta
funcionalidades coesas, visando criao de subsistemas fracamente
acoplados. Idealmente, alguma diviso em subsistemas deve ter sido feita na
fase de anlise e, se feita da maneira correta, a mesma deve ser aqui
preservada. As parties podem ser estruturadas em camadas e novamente
um bom ponto de partida considerar camadas de Interface com o Usurio,
Domnio do Problema e Gerncia de Dados, conforme discutido na Seo
3.4.

64
3.9 Detalhando os Componentes da Arquitetura de Software

Uma vez estabelecida a arquitetura global do sistema, os passos subsequentes
referem-se ao detalhamento de seus elementos. Ainda no se trata efetivamente de um
projeto detalhado (projeto de classes), mas est-se em um nvel intermedirio onde
muitas decises so ainda de cunho arquitetnico. Assim, o uso de padres
arquitetnicos muito importante neste contexto.
Como o foco deste texto o projeto de Sistemas de Informao, os captulos que
se seguem discutem o projeto de componentes de Lgica de Negcio (Captulo 4),
Interface com o Usurio (Captulo 5) e Gerncia de Dados (Captulo 6). Alguns padres
arquitetnicos e de projeto (design patterns) teis para o projeto desses componentes
so discutidos nesses captulos.
Bass, Clements e Kazman (2003) abordam vrios dos temas discutidos neste
captulo. De fato, muitas das ideias aqui apresentadas foram extradas de (BASS;
CLEMENTS; KAZMAN, 2003). Em especial, recomenda-se a leitura dos captulos 1
(The Architecture Business Cycle), 2 (What is Software Architecture?) e 5 (Achieving
Qualities).
MENDES (2002) tambm aborda vrios dos temas discutidos neste captulo.
Deste livro, recomenda-se a leitura dos captulos 1 (Arquitetura de Software) e 2
(Estilos Arquiteturais) e da seo 6.2 (Arquiteturas de Sistemas de Informao).
FOWLER (2003) em sua introduo discute importantes questes relativas
arquitetura de sistemas de informao.
Em (SHAW; GARLAN, 1996), um livro precursor na rea de Arquitetura de
Software, o Captulo 2 Architectural Styles apresenta diversos estilos arquitetnicos.
Alm disso, o Captulo 1 Introduction discute o que arquitetura de software.
Em (BLAHA; RUMBAUGH, 2006), o Captulo 14 Projeto de Sistemas
aborda vrios dos temas discutidos neste captulo, com destaque para as sees 14.1
(Viso Geral do Projeto de Sistemas), 14.2 (Calculando o Desempenho), 14.4
(Dividindo um Sistema em Subsistemas), 14.5 (Identificando Concorrncia), 14.6
(Alocao de Subsistemas), 14.11 (Definindo Prioridades de Troca) e 14.12 (Estilos
Arquiteturais Comuns).
Em (PFLEEGER, 2004), o Captulo 5 Projetando o Sistema h uma boa
apresentao de estilos e estratgias arquiteturais (seo 5.3), bem como discusses
interessantes acerca de concorrncia (seo 5.4), identificao e tratamento de excees,
e preveno e tolerncia a falhas (seo 5.5).
Em (PRESSMAN, 2006), o Captulo 10 Projeto Arquitetural aborda vrios
dos temas discutidos neste captulo, com destaque para as sees 10.1 (Arquitetura de
Software) e 10.3 (Estilos e Padres Arquiteturais).
Por fim, no Captulo 2 de (CASTELEYN et al., 2009) Technologies, Casteleyn
e colegas fazem um timo apanhado das tecnologias relacionadas s aplicaes Web.

65
ALBIN, S.T., The Art of Software Architecture: Design Methods and Techniques, John
Wiley & Sons, 2003.
2, Elsevier, 2006.
BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P., STAL, M.,
Pattern-Oriented Software Architecture: A System of Patterns, Volume 1, Wiley,
1996.
CARDOSO, A.C., MARQUES, A.S., Sistemas Baseados em Regras, 2007. Disponvel
em http://mestradosiad.blogspot.com/2007/11/sistemas-baseados-em-regras.html.
CASTELEYN, S., DANIEL, F., DOLOG, P., MATERA, M., Engineering Web
Applications, Springer, 2009.
FOWLER, M., Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.
GORTON, I., Essential Software Architecture, Springer, 2006.
KOSCIANSKI, A., SOARES, M.S., Qualidade de Software, Novatec, 2006.
MARINHO, E.H., RESENDE, R.F., Extenso de um Metamodelo de Aplicaes
Baseadas na Web considerando jax, Anais do VII Simpsio Brasileiro de
Sistemas de Informao, Salvador, Brasil, pp. 141 152, 2011.
MENDES, A., Arquitetura de Software: desenvolvimento orientado para arquitetura,
Editora Campus, 2002.
MURUGESAN, S., GINIGE, A., Web Engineering: Introduction and Perspectives,
In: Software Engineering for Modern Web Applications: Methodologies and
Technologies, pp. 1-24, IGI Global, 2008.
PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall,
2 edio, 2004.
PRESSMAN, R.S., LOWE, D., Web Engineering: A Practitioners Approach, Mc Graw
Hill, 2009.
RUBLE, D.A., Practical Analysis and Design for Client/Server and GUI Systems,
Yourdon Press Computing Series, 1997.
SHAW, M., GARLAN, D., Software Architecture: Perspectives on an Emerging
Discipline, Prentice Hall, 1996.
XAVIER, C.M.S., PORTILHO, C., Projetando com Qualidade a Tecnologia de
Sistemas de Informao, Livros Tcnicos e Cientficos Editora, 1995.

66

A camada de lgica de negcio engloba o conjunto de classes que vai realizar
toda a lgica do sistema de informao. As demais camadas so derivadas ou
dependentes dessa camada (WAZLAWICK, 2004) e, portanto, interessante iniciar o
projeto dos componentes da arquitetura do sistema por ela.
Os modelos construdos na fase de anlise so os principais insumos para o
projeto dessa camada, em especial o modelo conceitual estrutural e o modelo de casos
de uso. Os diagramas de classes da fase de anlise so a base para a construo dos
diagramas de classes da fase de projeto. De fato, a verso inicial do modelo estrutural de
projeto (diagramas de classes de projeto) da lgica de negcio uma cpia do modelo
conceitual estrutural. Durante o projeto, esse modelo ser objeto de refinamento,
visando incorporar informaes importantes para a implementao, tais como
distribuio de responsabilidades entre as classes (definio de mtodos das classes) e
definio de navegabilidades e visibilidades. Alm disso, alteraes na estrutura do
diagrama de classes podem ser necessrias para tratar requisitos no funcionais, tais
como usabilidade e desempenho.
Para organizar a lgica de negcio, um bom ponto de partida so os padres
arquitetnicos relativos a essa camada. Fowler (2003) apresenta quatro desses padres,
a saber: Script de Transao (Transaction Script), Modelo de Domnio (Domain
Model), Mdulo de Tabelas (Table Module) e Camada de Servio (Service Layer). No
contexto do desenvolvimento de Sistemas de Informao Orientados a Objetos,
merecem destaque os padres Modelo de Domnio e Camada de Servio.
Uma questo bastante importante tratada por esses padres a distribuio de
responsabilidades ao longo das classes que compem o sistema. No mundo de objetos,
uma funcionalidade realizada atravs de uma rede de objetos interconectados,
colaborando entre si. Objetos encapsulam dados e comportamento. O posicionamento
correto do comportamento na rede de objetos um dos principais problemas a serem
enfrentados durante o projeto da lgica de negcio.
Neste contexto, pode-se observar que a lgica de negcio , na verdade,
composta por dois tipos de lgica: a lgica de domnio do problema, que tem a ver
puramente com as classes previamente identificadas na fase de anlise; e lgica da
aplicao, que se refere s funcionalidades descritas pelos casos de uso. Neste contexto,
um desafio a mais se coloca: que classes vo comportar as funcionalidades descritas
pelos casos de uso (lgica de aplicao)? Duas formas bsicas so comumente adotadas:
Distribuir as responsabilidades para a execuo dos casos de uso ao longo

dos objetos do domnio do problema: essa abordagem refletida no padro
Modelo de Domnio e considera que as funcionalidades relativas aos casos
de uso do sistema (lgica de aplicao) estaro distribudas nas classes
previamente identificadas na fase de anlise.

67
Considerar que a lgica de negcio , na verdade, composta por dois

componentes: o Componente de Domnio do Problema, que tem a ver
puramente com as classes previamente identificadas na fase de anlise e que
trata apenas da lgica de domnio; e o Componente de Gerncia de Tarefas,
que se refere s funcionalidades descritas pelos casos de uso e trata, portanto,
da lgica de aplicao. Esta segunda opo a essncia do padro Camada
de Servio.
Seja qual for a opo escolhida, para apoiar a definio dos mtodos das classes,
pode ser til elaborar diagramas de interao.
Este captulo discute o projeto da camada de lgica de negcio. A Seo 4.1
discute brevemente os diagramas de interao, dando destaque aos diagramas de
sequncia, que sero usados posteriormente ao longo do captulo para apoiar a definio
de mtodos das classes. A Seo 4.2 apresenta sucintamente os padres arquitetnicos
Modelo de Domnio e Camada de Servio. A Seo 4.3 trata do projeto da lgica de
domnio do problema, discutindo as alteraes e refinamentos a serem feitos nos
diagramas de classes da anlise para incorporar as decises de projeto. Finalmente, a
Seo 4.4 trata do projeto da lgica de aplicao, que lida com a lgica dos casos de
uso.
4.1 Diagramas de Interao

Os diagramas de interao da Linguagem de Modelagem Unificada (Unified
Modeling Language UML) (BOOCH; RUMBAUGH; JACOBSON, 2006) so
utilizados para modelar aspectos dinmicos dos sistemas, com nfase na distribuio de
responsabilidades entre classes e no fluxo de controle ao longo das classes.
A modelagem de aspectos dinmicos de sistemas pode ser feita construindo-se
roteiros de cenrios (p.ex., fluxos de eventos de casos de uso, fragmentos deles ou
operaes) que envolvem a interao entre certos objetos de interesse e as mensagens
trocadas entre eles. Na UML, a modelagem desses roteiros feita com o uso dos
diagramas de interao (BOOCH; RUMBAUGH; JACOBSON, 2006).
Tipicamente, um diagrama de interao ilustra o comportamento de um grupo de
objetos colaborando para a realizao de um dado caso de uso, mostrando um nmero
de instncias concretas ou prototpicas de classes e as mensagens que so trocadas entre
elas no contexto do caso de uso. H dois tipos de diagramas de interao: diagramas de
sequncia e diagramas de comunicao. Os diagramas de sequncia do nfase
ordenao temporal das mensagens, enquanto os diagramas de comunicao do nfase
organizao estrutural dos objetos. Esses dois tipos de diagramas so semanticamente
equivalentes. Ou seja, possvel converter um no outro sem perda de informao
(BOOCH; RUMBAUGH; JACOBSON, 2006). Neste texto, so abordados somente os
diagramas de sequncia, discutidos a seguir.
4.1.1 - Diagramas de Sequncia
Um diagrama de sequncia um diagrama de interao que d nfase
ordenao temporal das mensagens. Ele organizado ao longo de dois eixos. Os objetos
que participam da interao so colocados no eixo horizontal, na parte superior do
diagrama. O objeto que inicia a interao colocado esquerda e os objetos

68
subordinados vo aparecendo direita. Quando um diagrama de sequncia modela um

cenrio de execuo de um caso de uso iniciado por um ator, tipicamente uma instncia
desse ator o objeto mais esquerda no diagrama. As mensagens que os objetos enviam
e recebem so colocadas ao longo do eixo vertical, na ordem cronolgica de envio, de
cima para baixo. Isso proporciona ao leitor uma clara identificao do fluxo de controle
ao longo do tempo. A Figura 4.1 mostra um exemplo de diagrama de sequncia,
ilustrando seus principais elementos de modelagem.
objetos
mensagem de
criao
parmetros
linha de vida
tempo
mensagens sncronas
mensagem de retorno
mensagem de
destruio
chamada
local
destruio de
objeto
mensagem assncrona
foco de controle
Figura 4.1 Diagrama de Sequncia: Elementos de Modelagem (adaptado de

(BOOCH; RUMBAUGH; JACOBSON, 2006)).
Como ilustra a figura acima, um objeto mostrado como um retngulo com uma
linha vertical pontilhada anexada. Essa linha chamada de linha de vida do objeto e
representa a existncia do objeto durante a interao. Cada mensagem representada
por uma seta direcionada entre as linhas de vida dos objetos emissor e receptor da
mensagem. A ordem temporal na qual as mensagens so trocadas mostrada de cima
para baixo. Opcionalmente, nmeros antes das mensagens so usados para indicar a sua
ordem. Cada mensagem rotulada com pelo menos o nome da mensagem.
Adicionalmente, pode incluir tambm parmetros e alguma informao de controle, tal
como uma condio de guarda ([condio]), indicando que a mensagem s enviada se
a condio for verdadeira.
H diferentes tipos de mensagens (BOOCH; RUMBAUGH; JACOBSON,
2006):

69
Uma mensagem de criao indica que o objeto receptor est sendo criado
naquele momento. Assim, ao contrrio dos demais objetos, ele aparece
nivelado na altura do envio da mensagem e no na parte superior do
diagrama.
Uma mensagem sncrona de chamada invoca uma operao no objeto

receptor, passando o controle para esse objeto. Um objeto pode enviar uma
mensagem para ele mesmo, resultando em uma chamada local de uma
operao.
Uma mensagem assncrona envia um sinal para o objeto receptor, mas o

objeto emissor continua sua prpria execuo. O objeto receptor recebe o
sinal e decide de forma independente o que fazer. A representao de
mensagens assncronas ligeiramente diferente da representao de
mensagens sncronas. A primeira tem uma seta fina, enquanto a segunda tem
uma seta grossa.
Uma mensagem de retorno indica uma resposta a uma mensagem sncrona

(retorno de chamada) e no uma nova mensagem. Para diferenciar,
mensagens de retorno so simbolizadas por uma linha tracejada com uma
seta fina. A mensagem de retorno pode ser omitida, j que h um retorno
implcito aps qualquer chamada. Contudo, muitas vezes til mostrar os
valores de retorno.
Por fim, uma mensagem de destruio elimina um objeto, deixando o mesmo

de existir. Assim, mensagens de destruio so acompanhadas do smbolo de
destruio de objeto.
O foco de controle mostra o perodo durante o qual um objeto est

desempenhando uma ao, diretamente ou por meio de um procedimento subordinado.
Ele mostrado como um retngulo estreito sobre a linha de vida do objeto. A parte
superior do retngulo alinhada com o incio da ao; a parte inferior alinhada com a
sua concluso e pode ser delimitada por uma mensagem de retorno (BOOCH;
RUMBAUGH; JACOBSON, 2006).
Durante a modelagem do comportamento de um sistema, muitas vezes
importante mostrar fluxos condicionais, laos e a execuo concorrente de sequncias.
Para modelar essas situaes, operadores de controle podem ser utilizados. Um
operador de controle apresentado como uma regio retangular no diagrama de
sequncia, contendo um rtulo no canto superior esquerdo, informando o tipo de
operador de controle. Os tipos mais comuns so (BOOCH; RUMBAUGH;
JACOBSON, 2006):
Execuo opcional (rtulo opt): o corpo do operador de controle executado

somente se a condio de guarda na entrada do operador for verdadeira.
Execuo alternativa (rtulo alt): o corpo do operador de controle dividido

em sub-regies por linhas horizontais tracejadas, sendo que cada sub-regio
representa um ramo condicional e executada somente se sua condio de
guarda for verdadeira.

70
Execuo paralela (rtulo par): o corpo do operador de controle dividido

em sub-regies por linhas horizontais tracejadas, sendo que cada sub-regio
representa uma computao paralela (concorrente).
Execuo iterativa (rtulo loop): o corpo do operador de controle

executado repetidamente enquanto a condio de guarda na entrada do
operador for verdadeira. A condio de guarda testada no incio de cada
iterao.
Mensagens trocadas entre objetos em um diagrama de sequncia devem ser

mapeadas como operaes na classe do objeto receptor da mensagem. Assim, toda
mensagem que chega a um objeto aponta para a necessidade de um mtodo com mesma
assinatura na classe desse objeto, contribuindo de maneira decisiva para a identificao
de mtodos nas classes.
4.2 Padres Arquitetnicos para o Projeto da Lgica de Negcio

Um importante aspecto do projeto da Camada de Lgica de Negcio diz respeito
organizao das classes e distribuio de responsabilidades entre elas, o que vai definir,
em ltima instncia, os mtodos de cada classe dessa camada.
Os diagramas de classes da fase de anlise so modelos conceituais estruturais e,
como tal, trazem importantes informaes sobre os objetos que abstraem entidades do
mundo real, os quais so elementos chave da lgica de negcio. Os modelos de caso de
uso descrevem as funcionalidades que o sistema dever prover e, portanto, tm
informaes igualmente relevantes sobre a lgica de negcio, mas sob um prisma
funcional. Em essncia, os casos de uso devero dar origem a operaes e consultas do
sistema, que geralmente vo estar disponveis para acesso a partir da interface do
sistema com o mundo externo. Assim, pode-se dividir a lgica de negcio em dois tipos
principais: a lgica de domnio do problema, que tem a ver puramente com as classes
previamente identificadas na fase de anlise; e lgica de aplicao, que se refere s
funcionalidades descritas pelos casos de uso. Como consequncia, importante definir
onde posicionar os mtodos que vo cumprir esses diferentes tipos de responsabilidades
em um modelo de classes de projeto.
Fowler (2003) apresenta alguns padres para organizar a lgica de negcio, a
saber: Script de Transao (Transaction Script), Modelo de Domnio (Domain Model),
Mdulo de Tabelas (Table Module) e Camada de Servio (Service Layer). Neste texto,
cujo foco o desenvolvimento de Sistemas de Informao Orientados a Objetos,
merecem destaque os padres Modelo de Domnio e Camada de Servio.
Em ambos os casos, til ter uma classe que vai representar o sistema como um
todo, dita uma classe controladora do sistema3 (WAZLAWICK, 2004). Essa classe
servir como uma fachada para receber requisies da interface com o usurio e
direcion-las para os objetos capazes de trat-las. Contudo, dependendo do padro
arquitetnico adotado, esse tratamento das requisies ser ligeiramente diferente.
O padro Modelo de Domnio preconiza que o modelo de classes do domnio
incorpore tanto dados quanto comportamento. As classes de domnio identificadas na
3
Uma classe controladora de sistema um controlador no sentido usado no padro Modelo-VisoControlador (MVC) discutido no Captulo 5.

71
Anlise de Requisitos so as responsveis por tratar tanto a lgica de domnio quanto a

lgica de aplicao (casos de uso). Assim, dados e processos so combinados
(FOWLER, 2003) e pode-se dizer que o padro Modelo de Domnio captura a essncia
da orientao a objetos.
De forma resumida, no padro Modelo de Domnio, tanto a lgica de domnio
quanto a lgica de aplicao so atribudas s classes do domnio do problema, sendo
que diferentes classes podem ter partes da lgica de aplicao que so relevantes a elas.
Vale ressaltar que esta pode no ser uma boa soluo sob uma perspectiva de
manutenibilidade, j que uma alterao em uma funcionalidade (caso de uso) pode
afetar diversas classes e, assim, pode ser difcil de ser incorporada.
J na abordagem do padro Camada de Servio, um conjunto de classes
gerenciadoras de casos de uso4 fica responsvel por tratar a lgica de aplicao,
controlando o fluxo de eventos dentro do caso de uso. Grande parte da lgica de
negcio ainda fica a cargo das classes do domnio do problema, cabendo aos
gerenciadores de casos de uso apenas centralizar o controle sobre a execuo do caso de
uso. Assim, a camada de servio construda, de fato, sobre a camada de domnio.
A motivao principal para esse padro o fato de algumas funcionalidades
(casos de uso) no serem facilmente distribudas nas classes de domnio do problema,
principalmente aquelas que operam sobre vrias classes. Assim, criam-se classes
gerenciadoras de casos de uso (gerenciadores ou coordenadores de tarefas),
responsveis pela realizao de tarefas (casos de uso). Tipicamente, esses gerenciadores
de tarefas agem como aglutinadores, unindo outros objetos para dar forma a um caso de
uso. Consequentemente, gerenciadores de tarefa so normalmente encontrados
diretamente a partir dos casos de uso. Os tipos de funcionalidade tipicamente atribudos
a gerenciadores de tarefa incluem comportamento relacionado a transaes e sequncias
de controle especficas de um caso de uso.
O padro Camada de Servio (FOWLER, 2003) define uma fronteira da lgica
de negcio usando uma camada de servios que estabelece um conjunto de operaes
disponveis e coordena as respostas do sistema para cada uma das operaes. A camada
de servio encapsula a lgica de negcio do sistema, controlando transaes e
coordenando respostas na implementao de suas operaes. A argumentao em favor
desse padro que misturar lgica de domnio e lgica de aplicao nas mesmas classes
torna essas classes menos reutilizveis transversalmente em diferentes aplicaes, bem
como pode dificultar a manuteno da lgica de aplicao, uma vez que a lgica dos
casos de uso no diretamente perceptvel em nenhuma classe.
A identificao das operaes necessrias na camada de servio fortemente
apoiada nos casos de uso do sistema. Uma opo considerar que cada caso de uso vai
dar origem a uma classe de servios, dita classe gerenciadora de caso de uso. Por
exemplo, um caso de uso de cadastro, envolvendo funcionalidades de incluso,
alterao, consulta e excluso, pode ser mapeado em uma classe com operaes para
tratar essas funcionalidades. Contudo, no h uma prescrio clara, apenas heursticas.
Para uma aplicao relativamente pequena, pode ser suficiente ter uma nica classe
provendo todas as operaes. Para sistemas maiores, compostos de vrios subsistemas,
pode-se ter uma classe por subsistema (FOWLER, 2003).
4
Classes gerenciadoras de caso de uso so classes que centralizam as interaes no contexto de casos de
uso especficos e no so consideradas controladores no sentido usado no padro MVC.

72
No se deve confundir uma abordagem de Camada de Servios com uma

abordagem de Modelo de Domnio Anmico (Anemic Domain Model) (FOWLER,
2003a), na qual os objetos do domnio do problema apresentam comportamento vazio.
Nessa abordagem, as classes de anlise so divididas em classes de dados (ditos objetos
de valor Value Objects VOs) e classes de lgica (ditos objetos de negcio Business
Objects BOs), que separam o comportamento do estado dos objetos. Os VOs tm
apenas o comportamento bsico para alterar e manipular seu estado (mtodos construtor
e destrutor e mtodos get e set). Os BOs ficam com os outros comportamentos, tais
como clculos, validaes e regras de negcio. De maneira geral, a abordagem de
Modelo de Domnio Anmico deve ser evitada, sendo, por isso, considerada um antipadro. Essa abordagem tem diversos problemas. Primeiro, no h encapsulamento, j
que dificilmente um VO vai ser utilizado apenas por um BO. Segundo, a vantagem de
se ter um modelo de domnio rico anulada, j que a proximidade com as abstraes do
mundo real destruda. No mundo real no existe lgica de um lado e dados de outro,
mas sim ambos combinados em um mesmo conceito. Outro problema a manuteno
de um sistema construdo desta maneira. Os BOs possuem um acoplamento muito alto
com os VOs e a mudana em um afeta drasticamente o outro (FRAGMENTAL, 2007).
Uma maneira de se implementar o padro Camada de Servio consiste em ter uma
ou mais classes gerenciadoras de casos de uso (veja discusso na Seo 4.4), as quais
encapsulam a lgica da aplicao. Para realizar um caso de uso, a classe gerenciadora de
caso de uso invoca mtodos da camada de domnio do problema, tal como ocorre no
padro Modelo de Domnio. A diferena entre os dois padres reside, neste caso, no
fato da classe gerenciadora de tarefa centralizar o controle do caso de uso, evitando
delegar responsabilidades a classes que no tm como trat-las.
4.3 Projeto da Lgica de Domnio do Problema

No projeto orientado a objetos, os modelos conceituais estruturais (diagramas de
classes) produzidos na fase de anlise esto diretamente relacionados lgica de
domnio do problema e podem ser incorporados a um Componente de Domnio do
Problema (CDP). Como ponto de partida para a elaborao do diagrama de classes do
CDP, deve-se utilizar uma cpia do diagrama de classes de anlise. A partir dessa cpia,
alteraes sero feitas para incorporar as decises de projeto. Vale ressaltar que o
trabalho deve ser efetuado em uma cpia, mantendo o modelo conceitual original
intacto para efeito de documentao e manuteno do sistema.
Para se poder conduzir o projeto do CDP de maneira satisfatria, algumas
informaes acerca da plataforma de implementao so essenciais, dentre elas a
linguagem de programao e o mecanismo de persistncia de objetos a serem adotados.
Alm disso, informaes relativas aos requisitos no funcionais e suas prioridades so
igualmente vitais para se tomar decises importantes relativas ao projeto do CDP.
As alteraes bsicas a serem incorporadas em um diagrama de classes do CDP
so:
Alterao de informaes relativas a tipos de dados de atributos: Na fase de
anlise, comum especificar tipos de dados gerais para atributos. Na fase de projeto,
contudo, os atributos devem ser mapeados em variveis de um tipo de dados provido
pela linguagem de implementao. Alm disso, muitas vezes, atributos podem dar

73
origem a novas classes (ou tipos de dados enumerados) para atender a requisitos de
qualidade, tais como usabilidade, manutenibilidade e reusabilidade.
Adio de navegabilidades nas associaes: Na fase de anlise, as associaes
so consideradas navegveis em todas as direes. O mesmo no ocorre na fase de
projeto, quando se pode definir que certas associaes so navegveis apenas em um
sentido, indicando que apenas um dos objetos ter uma referncia para o outro (ou para
colees de objetos, no caso de associaes com multiplicidade *). Esta deciso deve
ser feita, sobretudo, considerando os usos frequentes das funcionalidades do sistema e
requisitos no funcionais, com destaque para desempenho, mesmo que ele no seja um
atributo condutor da arquitetura. Alm disso, essa definio pode ser influenciada,
dentre outros, pelo mecanismo de persistncia de objetos a ser adotado.
Adio de informaes de visibilidade de atributos e associaes: De maneira
geral, na fase de anlise no se especifica a visibilidade de atributos e associaes.
Como discutido anteriormente, as associaes so tipicamente consideradas navegveis
e visveis em todas as direes. J os atributos so considerados pblicos. Porm essa
no uma boa estratgia para a fase de projeto. Conforme discutido no Captulo 2,
ocultar informaes um importante princpio de projeto. Assim, atributos s devem
poder ser acessados pela prpria classe ou por suas subclasses. Uma classe no deve ter
acesso aos atributos de uma classe a ela associada. Como consequncia disso, cada
classe deve ter operaes para consultar (tipicamente nomeadas como get) e atribuir /
alterar valor (normalmente nomeada como set) de cada um de seus atributos e
associaes navegveis. Essas operaes, contudo, no precisam ser mostradas no
diagrama de classes, visto que elas podem ser deduzidas pela prpria existncia dos
atributos e associaes (WAZLAWICK, 2004).
Adio de mtodos s classes: Muitas vezes, as classes de um diagrama de
classes de anlise no tm informao acerca das suas operaes. Mesmo quando elas
tm essa informao, ela pode ser insuficiente, tendo em vista que no projeto que se
decide efetivamente como abordar a distribuio de responsabilidades para a realizao
de funcionalidades. Assim, durante o projeto do CDP ateno especial deve ser dada
definio de mtodos nas classes. Para apoiar esta etapa, diagramas de sequncia podem
ser utilizados para modelar a interao entre objetos na realizao de funcionalidades do
sistema. A escolha de um padro arquitetnico para o projeto da lgica de negcio
tambm tem influncia na distribuio de responsabilidades, conforme discutido na
Seo 4.2. Vale ressaltar que j se assume que algumas operaes, consideradas bsicas,
existem e, portanto, no precisam ser representadas no diagrama de classes. Essas
operaes so as operaes de criao e destruio de instncias, alm das operaes de
consulta e atribuio / alterao de valores de atributos e associaes, conforme
discutido no item anterior. No diagrama de classes devem aparecer apenas os mtodos
que no podem ser deduzidos (WAZLAWICK, 2004).
Eliminao de classes associativas: Caso o diagrama de classes de anlise
contenha classes associativas, recomenda-se substitu-las por classes normais, criando
novas associaes. Isso importante, pois as linguagens de programao no tm
construtores capazes de implementar diretamente esses elementos de modelo.
Alm das alteraes bsicas a que todos os diagramas de classes do CDP estaro
sujeitos, outras fontes de alterao incluem:

74
Reutilizar projetos anteriores e classes j programadas: importante que na

fase de projeto seja levada em conta a possibilidade de se reutilizar classes j projetadas
e programadas (desenvolvimento com reso), bem como a possibilidade de se
desenvolver classes para reutilizao futura (desenvolvimento para reso). Tipicamente,
ajustes feitos para incorporar tais classes envolvem alteraes na estrutura do modelo,
podendo atingir hierarquias de generalizao-especializao, de modo a tratar as classes
do domnio do problema como subclasses de classes de bibliotecas pr-existentes.
Tambm ao incorporar um padro de projeto (design pattern), muito provavelmente a
estrutura do diagrama de classes de projeto sofrer alteraes.
Ajustar hierarquias de generalizao-especializao: muitas vezes, as
hierarquias de herana da fase de anlise no so adequadas para a fase de projeto.
Dentre os fatores que podem provocar mudanas na hierarquia de herana destacam-se:
o
Ajustar hierarquias de generalizao-especializao para adequao ao

mecanismo de herana suportado pela linguagem de programao a ser
usada na implementao: se, por exemplo, o modelo de anlise envolve
herana mltipla e a linguagem de implementao no oferece tal
recurso, alteraes no modelo so necessrias. Quando se estiver
avaliando hierarquias de classes para eliminar relaes de herana
mltipla, deve-se considerar se uma abordagem de delegao no mais
adequada do que o estabelecimento de uma relao de herana.
Ajustar hierarquias de generalizao-especializao para aproveitar

oportunidades decorrentes da definio de operaes: as definies de
operaes nas classes podem tambm conduzir a alteraes na hierarquia
de generalizao-especializao. De fato, pode ser que durante a fase de
anlise no sejam exploradas todas as oportunidades de herana. til
reexaminar o diagrama de projeto procurando observar se determinadas
classes tm comportamento parcialmente comum, abrindo-se espao para
a criao de uma superclasse encapsulando as propriedades (atributos e
operaes) compartilhadas, abstraindo o comportamento comum. A
criao de interfaces tambm pode ser interessante para garantir uma
separao da interface contratual de uma classe de sua implementao.
Conforme discutido anteriormente, a reutilizao pode ser um fator
motivador para a criao de novas superclasses. Contudo, deve-se tomar
cuidado com a refatorao da hierarquia de classes. Criar uma nova
classe para abstrair comportamento comum somente se justifica quando
h, de fato, uma relao de subtipo entre as classes existentes e a nova
classe criada; ou seja, pode-se dizer que a subclasse semanticamente
um subtipo da superclasse. No se deve alterar a hierarquia de classes
simplesmente para herdar uma parte do comportamento, quando as
classes envolvidas no guardam entre si uma relao efetivamente de
subtipo, em uma abordagem dita herana de implementao (BLAHA;
RUMBAUGH, 2006).
Ajustar o modelo para melhorar o desempenho: Visando melhorar o

desempenho do sistema, o projetista pode alterar o diagrama de classes do CDP para
melhor acomodar os ajustes necessrios. Atributos e associaes redundantes podem ser
adicionados para evitar recomputao, bem como podem ser criadas novas classes para
registrar estados intermedirios de um processo.

75
Ajustar o modelo para facilitar o projeto de interfaces com o usurio

amigveis: com o objetivo de incorporar o atributo de qualidade usabilidade, pode ser
importante considerar novas classes (ou tipos enumerados de dados) que facilitem a
apresentao de listas para seleo do usurio.
Ajustar o modelo para incorporar aspectos relacionados segurana: tticas
como autenticao e autorizao requerem novas funcionalidades que, por sua, vez,
requerem novas classes do CDP. Em casos como esse, pode ser til separar as classes
relativas a essas funcionalidades em um novo pacote, visando ao reso.
Alm dos ajustes discutidos anteriormente, vrios deles relacionados a atributos
de qualidade (a saber, reusabilidade, desempenho, usabilidade e segurana), o CDP
pode ser alterado, ainda, para comportar outros requisitos no funcionais, tais como
testabilidade, confiabilidade etc.
O CDP um componente obrigatrio, tanto quando se adota o padro Modelo de
Domnio quanto quando se adota o padro Camada de Servio. No padro Modelo de
Domnio, o CDP a prpria camada de lgica de negcio, tendo em vista que no h
classes gerenciadoras de tarefas (gerenciadoras de casos de uso). No caso do padro
Camada de Servio, alm do CDP, a camada de lgica de negcio tem outro
componente, o Componente de Gerncia de Tarefas.
4.4 Projeto da Lgica de Aplicao

Conforme discutido anteriormente, dependendo do padro arquitetnico
adotado, a lgica de aplicao projetada de maneira distinta. No padro Modelo de
Domnio, a lgica de aplicao distribuda nos objetos do domnio do problema; no
padro Camada de Servio, um novo componente, o Componente de Gerncia de
Tarefas (CGT), fica responsvel por tratar a lgica de aplicao, controlando os fluxos
de eventos dos casos de uso. Em ambos os casos, o projeto da lgica de aplicao est
intimamente ligado ao modelo de casos de uso.
4.4.1 Projeto da Lgica de Aplicao no Padro Modelo de Domnio
Wazlawick (2004) prope uma maneira interessante de projetar a lgica de
aplicao usando o padro Modelo de Domnio. Essa abordagem consiste em considerar
uma classe controladora do sistema no modelo de domnio do problema, relacionando-a
a todos os conceitos independentes, correspondentes aos cadastros do sistema, ou seja,
os elementos a serem cadastrados para a operao do sistema5. O fluxo de controle
sempre inicia em uma instncia da classe controladora. Essa classe recebe as requisies
da interface e, para trat-las, o controlador invoca mtodos que tratam a lgica de
aplicao posicionados nas classes do domnio do problema, em uma abordagem
chamada de delegao.
A delegao consiste em capturar uma operao que trata uma mensagem em um
objeto e reenviar essa mensagem para um outro objeto associado ao primeiro que seja
5
Vale ressaltar que, embora a classe controladora de sistema seja modelada no diagrama de classes do
domnio do problema, ela corresponde, de fato, ao pacote de interface com o usurio, tendo em vista que
ela um controlador no sentido adotado pelo padro MVC.

76
capaz de tratar a requisio. Neste caso, a execuo delegada para objetos do domnio
do problema, procurando efetuar uma cadeia de delegao sobre as linhas de
visibilidade das associaes j existentes, at se atingir um objeto capaz de atender
requisio. Novas linhas de visibilidade s devem ser criadas quando isso for
estritamente necessrio. Deste modo, mantm-se fraco o acoplamento entre as classes,
conforme preconiza o padro de projeto Acoplamento Fraco (LARMAN, 2004).
Assim, partindo-se do controlador do sistema, deve-se identificar qual o objeto a
ele relacionado que melhor pode tratar a requisio e delegar essa responsabilidade a
ele. Esse objeto, por sua vez, vai colaborar com outros objetos para a realizao da
funcionalidade.
De maneira geral, um objeto s deve mandar mensagens para outros objetos que
estejam a ele associados ou que foram passados como parmetro no mtodo que est
sendo executado. Nessa abordagem, deve-se evitar obter um objeto como retorno de um
mtodo (visibilidade local) para mandar mensagens a ele (WAZLAWICK, 2004),
conforme apontado pelo padro no fale com estranhos (LARMAN, 2004).
Seja o exemplo de uma locadora de vdeo, cujo modelo de projeto do domnio
do problema parcialmente apresentado na Figura 4.2.
Figura 4.2 Diagrama de Classes parcial do CDP de um sistema de videolocadora.

Neste exemplo, o modelo de casos de uso possui o caso de uso Efetuar Locao,
cuja descrio do fluxo de eventos principal a seguinte:
1. O atendente informa o cliente que deseja efetuar a locao.
2. Para cada item a ser locado
2.1 - O atendente informa o item a ser locado.
2.2 - O sistema calcula o valor de locao do item. O valor da locao de um
item dado pelo tipo de mdia do item. Cada tipo de mdia tem um
valor de locao associado. Um acrscimo de 50% do valor da locao
do tipo de mdia deve ser aplicado no caso do filme do item ser um
lanamento.
2.3 - O sistema calcula a data de devoluo prevista. A data de devoluo
prevista definida em funo do filme do item ser lanamento ou no.

77
Lanamentos tm prazo de um dia; filmes do catlogo tm trs dias de

prazo.
2.4 - Caso deseje, o atendente poder alterar a data de devoluo prevista e o
valor de locao de um item locado.
2.5 - O sistema adiciona o valor de locao do item locado ao valor da
locao.
3. A locao registrada com a data corrente como data de locao.
Este caso de uso possui, ainda, um fluxo alternativo para o passo 1, a saber:
Cliente est em dbito: Uma mensagem de erro exibida, informando que h

itens locados pelo cliente em atraso e apresentando dados desses itens. O
fluxo de eventos abortado.
No diagrama da Figura 4.2, apenas as classes Cliente, Filme e TipoMidia so

conceitos independentes. Assim, a classe controladora de sistema (Videolocadora) deve
ser relacionada a essas classes e deve possuir um mtodo efetuarLocacao que
simplesmente vai delegar a responsabilidade de realizar o caso de uso Efetuar Locao
para uma delas. Dentre essas trs classes, Cliente aparece como a opo natural para
comportar o mtodo efetuarLocacao, uma vez que nesse caso de uso so informados o
cliente e os itens a serem locados.
O fluxo de controle inicia na instncia da classe controladora Videolocadora, a
qual recebe a requisio da interface para efetuar uma locao, informando o cliente e
os itens a serem locados. Para trat-la, o controlador invoca o mtodo efetuarLocacao
da classe Cliente, que efetivamente realiza a lgica de aplicao. Para tal, o objeto
Cliente colabora com outros objetos para a realizao da funcionalidade, como mostra o
diagrama de sequncia da Figura 4.3. Vale ressaltar que as colaboraes nesse diagrama
ocorrem sobre as linhas de visibilidade das associaes j existentes (veja Figura 4.2).
Figura 4.3 Diagrama de Sequncia Caso de Uso Efetuar Locao Padro Modelo de Domnio
4.4.2 Projeto da Lgica de Aplicao no Padro Camada de Servio

No padro Camada de Servio, um novo componente, o Componente de
Gerncia de Tarefas (CGT), fica responsvel por tratar a lgica de aplicao,
controlando os fluxos de eventos dos casos de uso. Esse componente define classes
gerenciadoras de tarefas (ou gerenciadoras de casos de uso).
Quando o padro Camada de Servio aplicado, a camada de lgica de negcio
dividida em duas outras camadas. A Camada de Domnio do Problema (CDP) e, sobre
ela, a Camada de Gerncia de Tarefa.
Em um esboo preliminar, pode-se atribuir um gerenciador de tarefas para cada
caso de uso, sendo que os seus fluxos de eventos principais do origem a operaes da
classe que representa o caso de uso (classe gerenciadora de caso de uso ou classe de
aplicao). Deste modo, a manutenibilidade pode ser facilitada, uma vez que, detectado
um problema em um caso de uso, fcil identificar a classe que trata do mesmo.
Uma soluo diametralmente oposta consiste em definir uma nica classe de
aplicao para todo o sistema. Neste caso, os fluxos de eventos de todos os casos de uso
do origem a operaes dessa classe. Fica evidente que, exceto para sistemas muito
pequenos, essa classe tende a ter muitas operaes e ser extremamente complexa e,
portanto, essa opo tende a no ser prtica.
Normalmente, uma soluo intermediria entre as duas anteriormente
apresentadas conduz a melhores resultados. Nessa abordagem, casos de uso complexos
so designados a classes de gerncia de tarefas especficas. Casos de uso mais simples e
de alguma forma relacionados so tratados por uma mesma classe de gerncia de
tarefas.
No caso da aplicao do padro Camada de Servio, no h restries de que a
classe gerenciadora de tarefa obtenha um objeto como retorno de um mtodo
(visibilidade local) e mande mensagens a ele. Assim, a classe gerenciadora de tarefa
pode ter referncia a diversos objetos do domnio, tipicamente aqueles envolvidos na
realizao do caso de uso correspondente. A Figura 4.4 mostra o exemplo discutido
anteriormente, projetado agora usando o padro Camada de Servio.
Da mesma forma que no Padro Modelo de Domnio, o fluxo de controle inicia
na instncia da classe controladora Videolocadora, a qual recebe a requisio da
interface para efetuar uma locao, informando o cliente e os itens a serem locados.
Para trat-la, o controlador invoca o mtodo efetuarLocacao da classe controladora de
caso de uso AplLocacao, que trata da lgica de aplicao relacionada ao caso de uso
Efetuar Locao. Essa classe controla a sequncia do caso de uso, colaborando com os
objetos do Componente de Domnio do Problema para a realizao da funcionalidade,
como mostra o diagrama de sequncia da Figura 4.4.
O conjunto de tarefas a serem apoiadas pelo sistema oferece um recurso bastante
til para a definio das janelas, menus e outros componentes de interface com o
usurio necessrios para cada uma dessas tarefas. Assim os projetos dos componentes
de gerncia de tarefa e de apresentao (veja Captulo 5) esto bastante relacionados e
devem ser realizados conjuntamente, uma vez que, muitas vezes, so as tarefas que
determinam a necessidade de elementos de interface com o usurio para sua execuo.
Figura 4.4 Diagrama de Sequncia Caso de Uso Efetuar Locao Padro Camada de Servio

81
Descries detalhadas dos principais elementos de modelagem de diagramas de
interao (diagramas de sequncia e de comunicao) da UML podem ser encontradas
no Captulo 19 de (BOOCH; RUMBAUGH; JACOBSON, 2006) Diagramas de
Interao. Wazlawick (2004), por sua vez, discute em seu Captulo 7 Projeto da
Camada de Domnio como elaborar um diagrama de comunicao. Sua abordagem
para elaborao desses diagramas segundo um padro de Modelo de Domnio pode ser
facilmente estendida para diagramas de sequncia, tendo em vista que esses diagramas
so semanticamente equivalentes.
No Captulo 7 de (WAZLAWICK, 2004) Projeto da Camada de Domnio,
alm da tima apresentao acerca da elaborao de diagramas de comunicao, outros
aspectos do projeto da Lgica de Negcio so discutidos, incluindo modelos de domnio
ricos e padres de projeto associados, possveis modificaes a serem feitas nos
diagramas de classes de projeto, delegao e envio de informaes de diagramas de
comunicao para diagramas de classes de projeto.
Em (FOWLER, 2003), o Captulo 2 Organizing Domain Logic discute a
organizao da camada de lgica de negcio. Os padres discutidos nesse captulo so
posteriormente apresentados em detalhes no Captulo 9 Domain Logic Patterns.
Em (BLAHA; RUMBAUGH, 2006), o Captulo 15 Projeto de Classes
aborda vrios dos temas discutidos neste captulo, com destaque para as sees 15.3
(Realizando Casos de Uso), 15.7 (Otimizao do Projeto), 15.9 (Ajuste da Herana) e
15.10 (Organizando um Projeto de Classes).
2, Elsevier, 2006.
BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usurio, 2a edio,
Elsevier Editora, 2006.
FOWLER,
M.,
Anemic
Domain
Model,
2003a.
Disponvel
em
http://www.martinfowler.com/bliki/AnemicDomainModel.html. ltimo acesso em
06.05.2010.
FRAGMENTAL Bliki, Evitando VOs e BOs, 2007. Disponvel em
http://www.fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs. ltimo
acesso em 06.05.2010.
LARMAN, C., Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development, Third Edition, Addison Wesley,
2004.

82

Sistemas, em especial os sistemas de informao, so desenvolvidos para serem
utilizados por pessoas. Assim, um aspecto fundamental no projeto de sistemas a
interface com o usurio (IU). O projeto da IU estabelece uma forma de comunicao
entre as pessoas e o sistema computacional. A IU define como um usurio comandar o
sistema e como o sistema apresentar as informaes a ele.
Um dos princpios fundamentais para um bom projeto de software a separao
da apresentao (camada de IU) da lgica de negcio (camada de LN). Essa separao
importante por diversas razes, dentre elas (FOWLER, 2003):
O projeto de IU e o projeto da LN tratam de diferentes preocupaes. No

primeiro, o foco est nos mecanismos de interao e em como dispor uma
boa IU. O segundo concentra-se em conceitos e processos do negcio.
Usurios podem querer ver as mesmas informaes de diferentes maneiras

(p.ex., usando diferentes interfaces, tais como interfaces ricas de sistemas
desktop, interfaces de aplicaes Web tradicionais, interfaces de linha de
comando etc.). Neste contexto, separar a IU da LN permite o
desenvolvimento de mltiplas apresentaes.
Objetos no visuais so geralmente mais fceis de testar do que objetos

visuais. Ao separar objetos da LN de objetos de IU, possvel testar os
primeiros sem envolver os ltimos.
Dada a importncia dessa separao, importante usar algum padro

arquitetnico que trabalhe essa separao, tal como o padro Modelo-Viso-Controlador
(MVC) (FOWLER, 2003).
A camada de IU envolve dois tipos de funcionalidades:
Viso: refere-se aos objetos grficos usados na interao com o usurio;
Controle de Interao: diz respeito ao controle da lgica da interface,

envolvendo a ativao dos objetos grficos (p.ex., abrir ou fechar uma janela,
habilitar ou desabilitar um item de menu etc.) e o disparo de aes.
Este captulo discute o projeto da camada de interface com o usurio. Deve-se

realar, contudo, que o foco deste texto recai sobre aspectos arquitetnicos do projeto da
camada de IU. Apenas consideraes de cunho geral so feitas em relao ao projeto da
interao humano-computador, tema que, por si s, requer outra disciplina. Assim, a
Seo 5.1 apresenta o padro MVC. A Seo 5.2 d uma viso geral do processo de
projeto de IU. A Seo 5.3 trata do Projeto da Viso, discutindo brevemente tticas
relacionadas ao projeto dos objetos grficos de interao humano-computador. A Seo
5.4 trata do Projeto do Controle de Interao, que lida com a lgica de interface.

83
Finalmente, a Seo 5.5 discute como alguns padres de projeto (design patterns)
podem ser empregados no projeto da IU.
5.1 O Padro Modelo-Viso-Controlador

O padro Modelo-Viso-Controlador (MVC) considera trs papis relacionados
interao humano-computador. O modelo refere-se aos objetos que representam
alguma informao sobre o negcio e corresponde, de fato, a objetos da camada de
Lgica de Negcio. A viso refere-se entrada e exibio de informaes na IU.
Qualquer requisio tratada pelo terceiro papel: o controlador. Este pega a entrada do
usurio, envia uma requisio para a camada de lgica de negcio, recebe sua resposta e
solicita que a viso se atualize conforme apropriado. Assim, a IU uma combinao de
viso e controlador (FOWLER, 2003). Em outras palavras, elementos da viso
representam informaes de modelo e as exibem ao usurio, que pode enviar, por meio
da viso, requisies ao sistema. Essas requisies so tratadas pelo controlador, que as
repassa para classes do modelo. Uma vez alterado o estado dos elementos do modelo, o
controlador pode, se apropriado, alterar elementos de viso a serem exibidos ao usurio.
Assim, o controlador situa-se entre o modelo e a viso, isolando-os um do outro.
Neste ponto importante distinguir os controladores do padro MVC das classes
gerenciadoras de caso de uso do Componente de Gerncia de Tarefas (cgt). Estas
ltimas representam classes da lgica de negcio (lgica de aplicao) que encapsulam
e centralizam o tratamento de casos de uso. J um controlador do padro MVC um
controlador de interao, ou seja, ele controla a lgica de interface, abrindo e fechando
janelas, habilitando ou desabilitando botes, enviando requisies etc.
O padro MVC trabalha dois tipos de separao. Primeiro, separa a apresentao
(viso) da lgica de negcio (modelo), conforme advogado pelas boas prticas de
projeto. Segundo, mantm tambm separados o controlador e a viso. Essa segunda
separao (entre a viso e o controlador) menos importante que a primeira (entre a
viso e a lgica de negcio). Vrios sistemas tm um nico controlador por viso e, por
isso, a separao entre a viso e o controlador muitas vezes no feita. Em sistemas de
interfaces ricas desktop ela muitas vezes desprezada. Contudo, em interfaces Web,
essa separao comum, j que a parte de viso front end naturalmente separada do
controlador. De fato, a maioria dos padres de projeto de interfaces Web baseada
nesse princpio (FOWLER, 2003). A Figura 5.1 mostra um diagrama de pacotes
ilustrando o padro MVC.
A separao entre viso e controlador d origem a dois tipos de classes que
podem ser organizados em dois pacotes na camada de interface com o usurio: o
Componente de Interao Humana (cih), que responsvel pelas interfaces com o
usurio propriamente ditas (janelas, painis, botes, menus etc.) e representa a viso no
modelo MVC; e o Componente de Controle de Interao (cci), que responsvel por
controlar a interao, recebendo requisies da interface, disparando operaes da
lgica de negcio e atualizando a viso com base no retorno dessas operaes. O cci ,
portanto, o controlador do modelo MVC.

84
Figura 5.1 O Padro MVC.

importante frisar que, mesmo quando se opta por no fazer a separao fsica
em pacotes de viso e controlador, til ter classes distintas para desempenhar esses
papis. As classes controladoras de interao devem ser marcadas com o esteretipo
<<control>> para diferenci-las das classes de viso, que devem ser marcadas com o
esteretipo <<boundary>>. A Figura 5.2 mostra a notao especfica da UML para
esses dois esteretipos.
Figura 5.2 Notao da UML para os Objetos da Camada de IU.

No que se refere interao entre as camadas de IU e Lgica de Negcio
(modelo), ela se d de maneiras distintas em funo do padro arquitetnico adotado
nesta ltima. Quando o padro Modelo de Domnio adotado, os controladores de
interao enviam as requisies diretamente para os objetos do domnio do problema
(cdp), uma vez que, neste caso, no existem objetos gerenciadores de tarefa (cgt).
Quando o padro Camada de Servio adotado, as requisies dos controladores de
interao so enviadas para os objetos gerenciadores de tarefas (cgt). A Figura 5.3
ilustra o modo de interao entre essas camadas nos dois padres.
Embora a Figura 5.3 mostre os pacotes de viso (Componente de Interao
Humana cih) e de controle de interao (Componente de Controle de Interao cci)
fisicamente separados, essa separao fsica muitas vezes no empregada, conforme
discutido anteriormente, havendo um nico pacote ciu (Componente de Interface com o
Usurio). O que essa figura procura ressaltar que, mesmo habitando o mesmo pacote,
so as classes controladoras de interao que requisitam servios da camada de lgica
de negcio. Em outras palavras, so as classes controladoras de interao que disparam
a lgica de aplicao.
Outro ponto a ser destacado acerca da Figura 5.3 que ela considera que apenas
os objetos controladores de interao se comunicam com objetos da lgica de negcio.
Contudo, essa abordagem pode ser flexibilizada. bastante comum que os prprios
objetos de viso (cih) se comuniquem com objetos da lgica de negcio, mas apenas
para montar os objetos grficos e no para requisitar servios.

85
Figura 5.3 Interao entre Camadas de IU e LN.

O projeto da camada de IU fortemente relacionado ao projeto da lgica de
aplicao e ambos so apoiados pelo modelo de casos de uso. Assim, sobretudo quando
o padro Camada de Servio adotado, uma boa estratgia elaborar um nico
diagrama de classes envolvendo as classes do cgt e as classes do ciu. Quando essa
estratgia adotada, bastante importante usar as notaes especializadas da UML para
classes controladoras de interao e classes de interface, mostradas na Figura 5.2, de
modo a destacar os tipos das diferentes classes no diagrama.
5.2 O Processo de Projeto da Interface com o Usurio

O projeto de interface com o usurio envolve no apenas aspectos de tecnologia
(facilidades para interfaces grficas, multimdia, etc.), mas principalmente o estudo das
pessoas. Quem o usurio? Como ele aprende a interagir com um novo sistema? Como
ele interpreta uma informao produzida pelo sistema? O que ele espera do sistema?
Estas so apenas algumas das muitas questes que devem ser levantadas durante o
projeto da interface com o usurio (PRESSMAN, 2006).
O princpio bsico para o projeto de IU o seguinte: Conhea o usurio e as
tarefas (PRESSMAN, 2006). Assim, importante ter modelos tanto do usurio quanto
das tarefas que os mesmos vo desempenhar no sistema. Os modelos de casos de uso
tm precisamente essas informaes. As tarefas so os casos de uso; os usurios so
agrupados em atores. Assim, o modelo de casos de uso a base principal para o projeto
da IU. De maneira geral, o projeto de interfaces com o usurio envolve os seguintes
passos:

86
1. Definir as funcionalidades acessveis a partir da IU do sistema: este passo

visa estabelecer como as tarefas que as pessoas fazem normalmente no
contexto do sistema (casos de uso) podem ser mapeadas em um conjunto
similar (mas no necessariamente idntico) de tarefas a serem implementadas
no contexto da interface humano-computador. Deve-se definir, tambm, o
fluxo global da interao, aglutinando os diversos casos de uso na forma de
um ou mais aplicativos.
2. Estabelecer o perfil dos usurios: A interface do sistema deve ser adequada
ao nvel de habilidade dos seus futuros usurios. Assim, necessrio
estabelecer o perfil desses potenciais usurios e classific-los segundo
aspectos como nvel de habilidade, nvel na organizao e membros em
diferentes grupos. Uma classificao possvel considera os seguintes grupos
(PRESSMAN, 2006):
Usurio Novato: no conhece a dinmica de interao requerida para
utilizar a interface eficientemente (conhecimento sinttico; p.ex., no
sabe como atingir uma funcionalidade desejada) e conhece pouco a
semntica da aplicao, isto , entende pouco as funes e objetivos
do sistema, ou no sabe bem como usar computadores em geral;
Usurio conhecedor, mas espordico: possui um conhecimento
razovel da semntica da aplicao, mas tem relativamente pouca
lembrana das informaes sintticas necessrias para utilizar a
interface;
Usurio conhecedor e frequente: possui bom conhecimento tanto
sinttico quanto semntico e busca atalhos e modos abreviados de
interao.
3. Considerar princpios gerais de projeto de IU, tais como facilidades de ajuda,
mensagens de erro, tipos de comandos, entre outros, de modo a prover uma
IU adequada para os perfis de usurios estabelecidos. Este passo pode ser
visto como a definio de quais tticas de usabilidade devem ser aplicadas no
projeto da IU de um sistema.
4. Construir prottipos e, em ltima instncia, implementar as interfaces do
sistema, usando ferramentas apropriadas. A prototipagem abre espao para
uma abordagem iterativa de projeto de interface com o usurio, como mostra
a Figura 5.4. Nessa abordagem, utilizando diversos prottipos construdos
iterativamente, o usurio avalia a adequao da IU para o uso em seus
processos de negcio. Em uma abordagem de prototipagem, imprescindvel
o uso de ferramentas para a construo de interfaces, provendo facilidades
para manipulao de janelas, menus, botes, comandos etc.
5. Avaliar o resultado: A construo de prottipos feita com a participao de
apenas uns poucos usurios. Uma vez que se obtm o projeto considerado
completo da IU, idealmente, deve-se avaliar seu resultado para o conjunto (ou
uma amostra significativa) de usurios. Para tal, pode ser til coletar dados
qualitativos e quantitativos por meio, p.ex., de questionrios distribudos a
uma amostra significativa de usurios.

87
Projeto
Preliminar
Construo do
1 Prottipo da IU
o
Avaliao do
Usurio
Construo de novo
Prottipo da IU
Modificaes do Projeto
de Interface
Estudo da Avaliao
pelo Projetista
Projeto de Interface Completo
Figura 5.4 - Abordagem Iterativa para o Projeto de Interface com o Usurio

(adaptado de (PRESSMAN, 2006)).
5.3 Projeto da Viso

A poro do sistema que lida com a viso da interface com o usurio deve ser
mantida to independente e separada do restante da arquitetura do software quanto
possvel. Aspectos de interface com o usurio provavelmente sero alvo de alteraes
ao longo da vida do sistema e essas alteraes devem ter um impacto mnimo nas
demais partes do sistema.
A viso trata do projeto da interao humano-computador, definindo formato de
janelas, formulrios, relatrios, entre outros. Conforme discutido anteriormente, durante
o projeto da viso, muito til construir prottipos, de modo a apoiar a escolha e o
desenvolvimento dos mecanismos de interao a serem usados.
O ponto de partida para o projeto da viso o modelo de casos de uso, incluindo
as descries de atores e casos de uso. Com base nos casos de uso, deve-se projetar uma
hierarquia de comandos, definindo barras de menus, menus pull-down, cones etc., que
levem execuo dos casos de uso, quando acionados pelo usurio. A hierarquia de
comandos deve respeitar convenes e estilos existentes com os quais o usurio j esteja
familiarizado. Note que a hierarquia de comandos , de fato, um meio de apresentar ao
usurio as vrias funcionalidades disponveis no sistema. Assim, a hierarquia de
comandos deve permitir o acesso aos casos de uso do sistema.
Uma vez definida a hierarquia de comandos, as interaes detalhadas entre o
usurio e o sistema devem ser projetadas. Neste momento, til observar atentamente
tticas de usabilidade, discutidas mais frente na Seo 5.3.1.

88
Normalmente, no necessrio projetar as classes bsicas de interfaces grficas

com o usurio. Existem vrios ambientes de desenvolvimento de interfaces oferecendo
classes reutilizveis (janelas, cones, botes etc.) e, portanto, basta especializar essas
classes e instanciar os objetos que possuem as caractersticas apropriadas para o
problema em questo. Ainda assim, muito til desenvolver classes gerais de viso
visando uniformidade da apresentao e ao reso. Essas classes podem ser
organizadas em hierarquias de classes, de modo que, no projeto de um sistema
especfico, o projeto da sua viso seja realizado por meio da especializao de classes
de viso j existentes ao invs de ter de se compor todas as classes de viso a partir de
componentes bsicos de interface providos pelo ambiente de desenvolvimento.
O projeto detalhado das classes de viso do sistema pode ser mais facilmente
compreendido pela visualizao das prprias telas, sendo pouco til indicar os atributos
de uma classe de viso em um diagrama de classes. Para compreender a estrutura
interna de uma classe de viso, mais indicado prover o layout correspondente.
Entretanto, ainda til mostrar em um diagrama de classes as classes de viso e as suas
relaes de especializao com outras classes de viso e, sobretudo, as suas associaes
com as classes controladoras de interao, o que permite capturar como se dar
efetivamente o tratamento da interao humano-computador do sistema.
5.3.1 Tticas de Usabilidade
Diversas tticas relativas usabilidade podem ser aplicadas durante o projeto de
IU. Algumas dessas tticas incluem: (i) proviso de facilidades de ajuda, (ii)
apresentao de mensagens de aviso e de erro significativas, (iii) oferta de diferentes
tipos de comandos, adequados para diferentes perfis de usurio e (iv) viso do estado do
sistema quando em processamento.
Facilidade de Ajuda
Ajuda fundamental para os usurios, sobretudo para os novatos ou para aqueles
conhecedores do problema, mas usurios espordicos do sistema. Para projetar
adequadamente facilidades de ajuda, necessrio definir vrios aspectos, dentre eles: (i)
quando a ajuda estar disponvel e para que funes do sistema ou campos da IU; (ii)
como ativar (boto, tecla de funo, menu etc.); (iii) onde apresentar (janela separada,
local fixo da tela etc.); (iv) como retornar interao normal (boto, tecla de funo);
(v) como estruturar a informao (estrutura plana, hierrquica, hipertexto).
Em relao s funes do sistema, importante prover ajuda ao usurio para que
este esclarea o objetivo de uma funcionalidade do sistema, qual a sua sequncia de
passos (fluxo do caso de uso) e em que passo ele est no momento (e, por conseguinte,
como chegou at ali). P.ex., como ilustra a Figura 5.5, em um sistema de compra de
passagens areas, importante identificar para o usurio quais os passos a serem
realizados e em que passo o usurio se encontra em um dado momento.
Figura 5.5 Exemplo de ajuda relativa sequncia de passos de uma funo.
Em relao aos campos da IU, importante informar o significado de campos
no bvios para o usurio, como preench-los e, eventualmente, onde obter a

89
informao para seu preenchimento. P.ex., em um sistema de registro de empregados

domsticos para emisso de guia de recolhimento de impostos, importante dizer o que
significa o campo NIT, como preench-lo e onde obter essa informao. Alm disso,
para campos que so apresentados no mundo real geralmente formatados (p.ex., datas,
CPF etc.) importante dizer como os mesmos devem ser preenchidos. P.ex., em
sistemas que requerem o preenchimento de CPF, deve-se informar a forma de
preenchimento (apenas nmeros ou com uso de separadores).
Em relao a como ativar as facilidades de ajuda, h diferentes maneiras de se
prover acesso s facilidades de ajuda. Quando a ajuda pontual (p.ex., o significado de
um campo ou a sua formatao), a informao pode estar prontamente disponvel na
prpria interface ou pode-se disponibilizar um recurso de ajuda (p.ex., um boto ou um
campo sensvel presena do mouse) prximo ao elemento para o qual se deseja prover
a ajuda. Para facilidades de ajuda mais sofisticadas, que envolvem muitas informaes
(tal como um help completo do sistema) normalmente usam-se botes, itens de menu e
teclas de funo (p.ex., F1) ou uma combinao desses recursos. A Figura 5.6 ilustra
alguns exemplos de formas de se ativar facilidades de ajuda.
Figura 5.6 Exemplos de formas de ativar facilidades de ajuda

No que se refere a onde apresentar, facilidades de ajuda mais complexas (p.ex.,
ajuda para todo sistema) tipicamente so apresentadas em janelas separadas, ativadas
por itens de menu, botes ou teclas de funo, como ilustra a Figura 5.7. Para
informao mais simples, pode-se usar uma janela pop-up ou apresentar a ajuda em um
local fixo na tela. Para ajuda sobre campos, pode-se prover instruo prxima ao campo,
disponibilizar a informao quando da passagem do mouse ou prover um boto de ajuda
ao lado do campo. No caso de ajuda sobre a formatao de campos, alm das opes
anteriores, pode-se prover a informao na prpria descrio do campo, ou at mesmo
j prover a formao. A Figura 5.8 ilustra algumas dessas possibilidades.
Quando uma facilidade de ajuda provida em outro objeto de interface (p.ex.,
janela separada ou janela pop-up), preciso definir como retornar interao normal.
Janelas pop-up tipicamente tm botes para fech-las. Janelas separadas podem usar os
mecanismos tpicos de encerramento (veja Figura 5.7). Outra opo fazer uso de teclas
de funo (p.ex., ESC para retornar interao normal).
Por fim, para facilidades de ajuda com contedo complexo, importante definir
como estruturar a informao. Algumas opes so estruturas planas, hierrquicas e
hipertextos, as quais podem ser combinadas, como no caso da Figura 5.7.

90
Figura 5.7 Exemplo de ajuda de todo sistema.
Figura 5.8 Exemplos de formas de apresentao de ajuda para campos

Mensagens de Erro e Avisos
Mais at do que a ajuda, as mensagens de erro e avisos so fundamentais para
uma boa interao humano-computador. Ao definir mensagens de erro e avisos
considere as seguintes diretrizes:
Descreva o problema com um vocabulrio passvel de entendimento pelo

usurio.

91
Sempre que possvel, proveja assistncia para recuperar um erro.
Quando for o caso, indique as consequncias negativas de uma ao.
Para facilitar a percepo da mensagem por parte do usurio, pode ser til
que a mesma seja acompanhada de uma dica visual (p.ex., destacar o campo
em que o preenchimento apresentou problema) ou sonora.
Tipos de Comandos
Diferentes grupos de usurios tm diferentes necessidades de interao. Em
muitas situaes til prover aos usurios mais de uma forma de interao. Nestes
casos, necessrio definir e avaliar:
Quais funes tero mais de uma forma de interao (p.ex., um item de menu
e um comando correspondente);
Qual ser a forma do comando. Controle de sequncia (p.ex., ^Q), teclas de

funo (p.ex., F1) e comandos digitados so opes tipicamente combinadas
com itens de menu;
Quo difcil aprender e lembrar o comando;
Os padres a serem adotados: Devem ser adotados padres uniformes para

todo sistema. Esses padres devem estar em conformidade com outros
padres, tais como o definido pelo sistema operacional e por produtos de
software tipicamente utilizados pelos usurios.
Progresso do Processamento
importante mostrar o progresso do processamento para os usurios,
principalmente para eventos com tempo de resposta longo ou com grande variao de
tempos de resposta. A Figura 5.9 ilustra uma janela de progresso de processamento.
Figura 5.9 Exemplos de interface informando o progresso do processamento

5.3.2 Diretrizes para o Projeto da Viso
Levando-se em conta princpios gerais de projeto de IU, algumas orientaes
adicionais devem ser consideradas, dentre elas:
Seja consistente. Use formatos consistentes para seleo de menus, entrada

de comandos, apresentao de dados etc.
Oferea retorno significativo ao usurio.

92
Pea confirmao para aes destrutivas, tais como aes para apagar ou
sobrepor informaes ou para terminar a seo corrente do aplicativo.
Permita reverso da maioria das aes (funo Desfazer).
Reduza a quantidade de informao que precisa ser memorizada entre

aes.
Busque eficincia no dilogo (movimentao, teclas a serem apertadas).
Trate possveis erros do usurio. O sistema deve se proteger de erros,

casuais ou no, provocados pelo usurio.
Classifique atividades por funo e organize geograficamente a tela de

acordo. Menus do tipo pull-down so uma boa opo.
Proveja facilidades de ajuda sensveis ao contexto.
Use verbos de ao simples ou frases curtas para nomear funes e

comandos.
No que se refere apresentao de informaes, considere as seguintes

diretrizes:
Mostre apenas informaes relevantes ao contexto corrente.
Use formatos de apresentao que permitam assimilao rpida da

informao, tais como grficos e figuras.
Use rtulos consistentes, abreviaturas padro e cores previsveis.
Produza mensagens de erro significativas.
Projete adequadamente o layout de informaes textuais. Leve em

considerao o bom uso de letras maisculas e minsculas, identao,
agrupamento de informaes etc.
Separe diferentes tipos de informao. Painis podem ser usados para este
fim.
Use formas de representao anlogas s do mundo real para facilitar a

assimilao da informao. Para tal considere o uso de figuras, cores etc.
No que se refere entrada de dados, considere as seguintes diretrizes:
Minimize o nmero de aes de entrada requeridas e possveis erros. Para

tal considere a seleo de dados a partir de um conjunto pr-definido de
valores de entrada, o uso de valores default etc.
Mantenha consistncia entre apresentao e entrada de dados; ou seja,

mantenha as mesmas caractersticas visuais, dentre elas tamanho do texto,
cor e localizao.
Permita ao usurio customizar a entrada para seu uso, quando possvel,

dando-lhe liberdade para definir comandos customizados, dispensar
algumas mensagens de aviso e verificaes de aes, dentre outros.

93
Flexibilize a interao, permitindo afin-la ao modo de entrada preferido do

usurio (comandos, botes, plug-and-play, digitao etc.).
Desative comandos inapropriados para o contexto das aes correntes.
Proveja ajuda significativa para assistir as aes de entrada de dados.
Nunca requeira que o usurio entre com uma informao que possa ser
adquirida automaticamente pelo sistema ou computada por ele.
5.4 Projeto do Controle de Interao

O projeto do Controle de Interao visa definir as classes responsveis por
controlar a interao (ativar/desativar objetos de viso) e enviar requisies para os
objetos da Lgica de Negcio.
Em sistemas rodando em plataforma desktop, deve haver pelo menos uma classe
controladora, dita classe controladora de sistema, representando o sistema como um
todo. Os objetos dessa classe representam as vrias sesses (execues) do sistema.
Neste contexto, necessrio levar em conta quantos executveis devem ser gerados para
o sistema. Se mais do que um executvel for necessrio, cada executvel ter de dar
origem a uma classe controladora. Esta, contudo, apenas uma abordagem possvel.
Conforme discutido na Seo 5.1, a interao entre controladores e objetos da
lgica de negcio se d de maneiras distintas em funo do padro arquitetnico
adotado no projeto da lgica de negcio. Quando o padro Modelo de Domnio
adotado, os controladores de interao esto associados diretamente com os objetos do
domnio do problema (cdp). Conforme discutido na Seo 4.4.1, uma abordagem
interessante consiste em relacionar a classe controladora do sistema (ou uma classe
controladora responsvel por parte da funcionalidade do sistema) com os objetos
independentes do cdp. Vale destacar que o conceito de objeto independente pode ser
analisado no contexto do subsistema, i.e., se um objeto no depende de outros objetos
no contexto do subsistema em questo, ento ele pode ser considerado independente
neste subsistema e estar ligado ao controlador.
Quando o padro Camada de Servio adotado, os controladores esto
associados a objetos gerenciadores de tarefas (cgt). Analogamente ao projeto do
Componente de Gerncia de Tarefas (cgt) (ver Seo 4.4.2), possvel definir um
nmero arbitrrio de controladores de interao. Uma opo definir um nico
controlador para todo o sistema (controlador de sistema), o qual fica responsvel por
gerenciar a interao de toda aplicao. Assim como ocorre no projeto do cgt, essa
opo tende a ser inadequada, pois a classe controladora de sistema pode ficar muito
complexa. Uma opo diametralmente oposta consiste em definir um controlador de
interao para cada caso de uso. Em aplicaes desktop, adicionalmente, necessrio
ter ainda, pelo menos, uma classe controladora de sistema (ou uma classe controladora
para cada executvel). Contudo, normalmente, uma soluo intermediria entre as duas
anteriormente apresentadas conduz a melhores resultados. Alm disso, deve-se
considerar que, uma vez que as classes controladoras de interao tendem a ser mais
simples que as classes do cgt, no necessrio adotar a mesma estratgia usada na cgt.
Assim, ainda que haja uma analogia entre o projeto do controle de interao e o projeto

94
do cgt, as motivaes so diferentes e a escolha dos controladores de interao pode ser

diferente da escolha dos gerenciadores de tarefas.
5.5 Design Patterns no Projeto da Interface com o Usurio

Alguns padres de projeto (design patterns) so bastante utilizados para tratar
problemas recorrentes no projeto da IU, dentre eles os padres Decorador, Observador e
Comando.
O padro Decorador (Decorator) anexa responsabilidades adicionais a um objeto
dinamicamente, permitindo estender sua funcionalidade (GAMA et al., 1995). Ele
utilizado por frameworks decoradores de interface para automatizar a tarefa de manter
uma aplicao Web tradicional6 com a mesma aparncia, ou seja, cabealho, rodap,
barra de navegao, esquema de cores e demais elementos grficos de layout integrados
num mesmo projeto de apresentao. Esse tipo de framework funciona segundo o
padro de projeto Decorador, se posicionando como um filtro entre uma requisio do
cliente e um servidor Web, como ilustra a Figura 5.10 (SOUZA, 2005).
Figura 5.10 Funcionamento de um framework Decorador (SOUZA, 2005).

O padro Observador (Observer) define uma dependncia um-para-muitos entre
objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes so
notificados e atualizados automaticamente (GAMMA et al., 1995). Ele uma boa opo
para separar aspectos de apresentao dos respectivos dados da aplicao, permitindo o
6
i.e., uma aplicao Web que no se enquadra no conceito de Aplicao Rica para Internet, conforme
discutido no Captulo 3.

95
uso de mltiplas representaes. Por exemplo, os mesmos dados estatsticos podem ser
apresentados em formato de um grfico de barras ou em uma planilha, usando
apresentaes diferentes. O grfico de barras e a planilha devem ser independentes.
Contudo, eles tm de se comportar consistentemente, isto , quando um usurio alterar a
informao na planilha, o grfico de barras deve refletir a troca imediatamente e viceversa, como ilustra a Figura 5.11 (GAMMA et al., 1995). Na soluo proposta pelo
padro observador, a apresentao atua como um observador do domnio do problema:
sempre que o domnio do problema alterado, ele envia um evento e a apresentao
atualiza a informao (FOWLER, 2003).
50
30
20
X
a = 50%
b = 30%
c = 20%
notificao de alterao
pedido de alterao
Figura 5.11 Aplicao do padro Observador (adaptado de (GAMA et al., 1995)).

Finalmente, o padro Comando (Command) encapsula uma requisio como um
objeto, permitindo parametrizar clientes com diferentes requisies e desfazer
operaes. Em interfaces com o usurio, objetos grficos (p.ex., botes e menus),
quando acionados, devem disparam requisies para a execuo de funcionalidades do
sistema. Entretanto, essas requisies no podem ser implementadas diretamente nos
objetos grficos, pois somente a aplicao deve saber efetivamente o que deve ser feito.
O padro Comando permite que os objetos grficos faam requisies de objetos no
especificados, tornando a requisio em si um objeto. Esse objeto pode ser armazenado
e repassado como qualquer outro objeto.
Em (FOWLER, 2003), o Captulo 4 Web Presentation discute diversos
aspectos do projeto da interface com o usurio de aplicaes Web. Os padres
discutidos nesse captulo so posteriormente apresentados em detalhes no Captulo 14
Web Presentation Patterns.
Em (PRESSMAN, 2006), o Captulo 12 Projeto de Interface com o Usurio
discute princpios gerais do projeto da IU (Seo 12.1) e o processo de anlise, projeto e
avaliao de IU (sees 12.2 a 12.5).

96
O Captulo 9 de (WAZLAWICK, 2004) Projeto da Camada de Interface, trata

do projeto da camada de Interface com o Usurio focalizando aspectos da navegao do
sistema e controle de segurana.
O catlogo de padres de projeto de Gamma et al. (1995) descreve, dentre
outros, os trs padres de projeto citados neste captulo, a saber os padres Comando,
Observador e Decorador.
Souza (2005) apresenta um mtodo para o projeto de sistemas de informao
Web baseado no uso de frameworks. A Seo 2.3 de sua dissertao apresenta diversos
frameworks tipicamente utilizados no desenvolvimento de sistemas de informao Web
e o Captulo 4 apresenta o mtodo proposto pelo autor, com destaque para modelos de
navegao.
SOUZA, V.E.S., FrameWeb: um Mtodo baseado em Frameworks para o Projeto de
Sistemas de Informao Web, Dissertao de Mestrado, Programa de PsGraduao em Informtica, UFES, Universidade Federal do Esprito Santo, 2005.

97

A maioria dos sistemas requer alguma forma de armazenamento de dados. Para
tal, h vrias alternativas, dentre elas a persistncia em arquivos e bancos de dados. Em
especial os sistemas de informao envolvem grandes quantidades de dados e fazem uso
de sistemas gerenciadores de bancos de dados (SGBDs). H diversos tipos de SGBDs,
dentre eles os relacionais e os orientados a objetos, sendo os primeiros os mais
utilizados atualmente no desenvolvimento de sistemas de informao.
Quando SGBDs Relacionais so utilizados, necessrio um mapeamento entre
as estruturas de dados dos modelos orientado a objetos e relacional, de modo que
objetos possam ser armazenados em tabelas. Dentre as principais diferenas entre esses
modelos, destacam-se as diferentes formas como objetos e tabelas tratam ligaes e na
ausncia do mecanismo de herana no modelo relacional. Essas diferenas levam
necessidade de transformaes das estruturas de dados entre objetos e tabelas, tratadas
como mapeamento objeto-relacional.
Alm das diferenas estruturais, outros aspectos tm de ser tratados durante o
projeto da persistncia, dentre eles o modo como a camada de lgica de negcio se
comunica com o banco de dados, o problema comportamental que diz respeito a como
obter vrios objetos do banco e como salv-los, e o tratamento de conexes com o
banco de dados e transaes (FOWLER, 2003).
importante enfatizar que muitos desses problemas so tratados por frameworks
de persistncia de objetos em bancos de dados relacionais (ou frameworks de
mapeamento objeto-relacional), tal como o Hibernate7. Os desenvolvedores desses
frameworks tm despendido muitos esforos trabalhando nesses problemas e tais
ferramentas so bem mais sofisticadas do que a maioria das solues especficas que
podem ser construdas pelos prprios desenvolvedores em um projeto especfico.
Contudo, mesmo quando um framework de mapeamento objeto-relacional (O/R)
utilizado, importante estar ciente dos padres usados. Boas ferramentas de
mapeamento O/R do vrias opes de mapeamento para um banco de dados e esses
padres ajudam a entender quando selecionar as diferentes opes (FOWLER, 2003).
Por fim, deve-se enfatizar que um bom projeto do mecanismo de persistncia
deve levar em conta a ideia de separao entre interface com o usurio, lgica de
negcio e persistncia, conforme discutido no Captulo 3. Assim, o presente captulo
visa discutir os principais aspectos relacionados ao projeto da persistncia de objetos em
bancos de dados relacionais, primando pelo isolamento do banco de dados, de modo que
seja possvel, por exemplo, a substituio de um SGBD relacional por outro ou at
mesmo por um outro tipo de SGBD.
Este captulo est estruturado da seguinte forma: a Seo 6.1 apresenta
sucintamente o modelo relacional, que constitui a base dos SGBDs relacionais; a Seo
7
http://www.hibernate.org/

98
6.2 discute o mapeamento objeto-relacional; a Seo 6.3 discute padres arquitetnicos

para o projeto da camada de persistncia; e finalmente a Seo 6.4 fala sobre
frameworks de persistncia.
6.1 O Modelo Relacional

Em um modelo de dados relacional, os conjuntos de dados so representados por
tabelas de valores. Cada tabela, denominada de relao, bidimensional, sendo
organizada em linhas e colunas. Esse modelo est fortemente baseado na teoria
matemtica sobre relaes, da o nome relacional. Os principais conceitos do modelo
relacional so os seguintes:
Tabela ou Relao: tabela de valores bidimensional organizada em linhas e
colunas. A Figura 6.1 mostra um exemplo de uma tabela Funcionrios.
Matrcula
0111
0208
0789
1589
Nome
Marcos
Rita
Mnica
Mrcia
CPF
17345687691
56935101129
81176628911
91125769120
Dt-Nasc
11/04/66
21/02/64
01/11/70
20/10/80
Figura 6.1 Tabela Funcionrios.

Linha ou Tupla: representa uma entidade de um conjunto de entidades. Ex: A
funcionria Mnica do conjunto de funcionrios.
Coluna: representa um atributo de uma entidade. Ex.: Matrcula, Nome, CPF,
Dt-Nasc.
Clula: Item de dado da linha i, coluna j. Ex.: Rita (linha 2, coluna 2).
Chave Primria: coluna ou combinao de colunas que possui a propriedade
de identificar de forma nica uma linha da tabela e que utilizada para
estabelecer associaes entre entidades via transposio de chave.
Chave Estrangeira ou Transposta: a forma utilizada para associar linhas de
tabelas distintas. A chave primria de uma tabela transposta como uma
coluna na outra tabela, onde considerada uma chave estrangeira. A Figura 6.2
ilustra um relacionamento 1:N entre as tabelas Departamentos e Funcionrios,
indicando que um departamento pode lotar vrios funcionrios, enquanto um
funcionrio tem de estar lotado em um departamento.
Departamentos
Cdigo
Nome
INF
Informtica
LET
Letras
MAT
Matemtica
Matrcula
0158
5295
7712
Funcionrios
Nome
Jos
Ricardo
Rosane
Cod-Depto
MAT
INF
INF
Chave Estrangeira
Figura 6.2 Exemplo de ligao entre tabelas, por meio de chave estrangeira.

99
Tabelas Associativas: usadas para representar relacionamentos n-para-n entre

tabelas. No exemplo da Figura 6.3, uma pessoa pode ter interesse em vrios
assuntos, enquanto um assunto pode ser de interesse de vrias pessoas. A tabela
Interesses uma tabela associativa, sendo suas duas colunas chaves transpostas
de outras tabelas.
Pessoas
CPF
Nome
96100199 Jos
83467187 Maria
02765140 Luiza
Interesses
CPF-Pessoa CdigoAssunto
96100199
COMP
96100199
MUS
02765140
ENG
Assuntos
Cdigo
Nome
ENG
COMP
MUS
Engenharia
Computao
Msica
Figura 6.3 Exemplo de Tabela Associativa.

O modelo relacional tem diversas propriedades que precisam ser respeitadas, a
saber:
Cada tabela possui um nome, o qual deve ser distinto do nome de qualquer
outra tabela da base de dados.
Nenhum campo parte de uma chave primria pode ser nulo.
Cada clula de uma relao pode ser vazia (exceto os campos de chaves
primrias) ou, ao contrrio, pode conter no mximo um nico valor.
No h duas linhas iguais.
A ordem das linhas irrelevante.
Cada coluna tem um nome, o qual deve ser distinto dos demais nomes das
colunas de uma mesma tabela.
Usando-se os nomes para se fazer referncia s colunas, a ordem destas

torna-se irrelevante.
Os valores de uma coluna so retirados todos de um mesmo conjunto,

denominado domnio da coluna.
Duas ou mais colunas distintas podem ser definidas sobre um mesmo

domnio.
Um campo que seja chave estrangeira (ou parte dela) s pode assumir valor
nulo ou um valor para o qual exista um registro na tabela onde ele chave
primria.
Muitas vezes, durante o projeto de bancos de dados relacionais, til representar

graficamente as tabelas e as ligaes entre elas. Para tal, um Diagrama Relacional pode
ser desenvolvido, representando as ligaes entre tabelas de um modelo relacional. A
Figura 6.4 mostra um exemplo de um fragmento de um diagrama relacional e suas
tabelas correspondentes.

100
Diagrama Relacional
#Dep #FunChefet
#Fun
Departamentos
Funcionrios
Tabelas do Modelo Relacional

Departamentos
Cdigo Nome
Matrcula-Chefe
INF Informtica 00877
MAT Matemtica 06001
QUI Qumica
13888
Funcionrios
Matrcula
Nome
13888
Jorge
00877
Dede
06001
Pedro
Figura 6.4 Exemplo de Diagrama Relacional e as respectivas tabelas

Nesse exemplo a coluna Matrcula de Funcionrios foi considerada a chave
primria da tabela Funcionrios e foi transposta para a relao Departamentos. O
contrrio tambm poderia ser feito, isto , transpor a chave primria de Departamentos
para Funcionrios. A primeira opo mais indicada, porque h poucos funcionrios
que so chefes, enquanto todos os departamentos tm chefes. Assim, a coluna
Matrcula-Chefe no ter valores vazios e, portanto, ela mais densa do que seria a
coluna resultante da transposio da chave primria de Departamentos para a tabela
Funcionrios.
Em um Diagrama Relacional so representados os seguintes elementos:
Tabelas: so representadas por retngulos, com uma referncia chave

primria em cima da tabela.
#Fun
c
Funcionrios
Relacionamentos: so representadas por linhas contnuas, associadas aos

smbolos abaixo:
Cardinalidade
Relacionamento
(0,1)
(1,1)
(0,N)
(1,N)
Chaves estrangeiras: quando uma chave transposta no fizer parte da chave

primria da relao destino, a mesma representada em cima do retngulo
da relao destino com um subscrito t, como ilustra a Figura 6.4.

101
Colunas que no so chaves primrias ou estrangeiras no so representadas nos

diagramas, mas sim em um dicionrio de tabelas do modelo relacional.
Outra opo para representar diagramas relacionais utilizar um perfil UML.
Neste caso, tabelas so representadas como classes com o esteretipo <<table>>, tabelas
associativas so representadas como classes com o esteretipo <<association table>> e
colunas so representadas como atributos. Quando uma coluna chave primria (ou
parte da chave primria), ela estereotipada com <<pk>>. Quando uma coluna chave
estrangeira (ou parte da chave estrangeira), ela estereotipada com <<fk>>. A Figura
6.5 mostra o exemplo da Figura 6.4 usando o perfil UML descrito.
Figura 6.5 Exemplo de Diagrama Relacional usando Perfil UML.

Ainda que no exemplo anterior as chaves primrias tenham sido escolhidas
dentre atributos das entidades (Departamentos e Funcionrios), essa no
necessariamente a melhor escolha. Muito pelo contrrio. Para trabalhar bem a
manutenibilidade dos sistemas resultantes, sobretudo quando se utiliza o paradigma
orientado a objetos, mais interessante utilizar como chave primria de uma tabela uma
coluna criada exclusivamente para este fim, sem nenhum significado no domnio do
problema e, portanto, uma coluna que no ser manipulada pela camada de Lgica de
Negcio, mas apenas pela camada de persistncia. Essa abordagem, alm de facilitar a
manuteno, facilita grandemente o desenvolvimento de infraestruturas genricas de
persistncia de objetos, uma vez que todas as chaves primrias so do mesmo tipo de
dados e podem ser tratadas uniformemente.
6.2 Mapeamento Objeto-Relacional

Conforme se pode observar pela Seo 6.1, h diferenas significativas entre o
modelo de classes de um projeto orientado a objetos e o modelo relacional. Uma
diferena significativa a forma como relacionamentos so tratados nos modelos de
objetos e relacional: objetos armazenam referncias a outros objetos (p.ex., endereos
de memria), enquanto bancos de dados relacionais ligam tabelas por meio de chaves
transpostas. Ainda neste contexto, objetos usam colees para tratar relacionamentos e
atributos multivalorados, enquanto clulas de uma tabela s podem ter no mximo um
valor. Outra diferena substancial o mecanismo de herana, o qual no suportado por
bancos de dados relacionais. Por outro lado, tabelas tm de ter uma chave primria,
enquanto objetos so nicos por essncia, ficando transparente para o desenvolvedor a
existncia de identificadores. Assim, para que a persistncia de objetos seja feita em um
banco de dados relacional, necessrio realizar um mapeamento entre esses dois tipos
de modelos.
O termo mapeamento objeto-relacional (O/R) usado tipicamente para
referenciar um mapeamento estrutural entre objetos que residem em memria e tabelas

102
em bancos de dados. Ele fundamental para o projeto da camada de persistncia

quando um SGBD relacional utilizado e s deve ser visvel na camada de persistncia,
isolando as demais camadas da arquitetura de software do impacto da tecnologia de
bancos de dados.
No mapeamento O/R, as seguintes questes devem ser abordadas: (i)
mapeamento de classes e objetos; (ii) mapeamento de herana; e (iii) mapeamento de
associaes entre objetos.
6.3.1 - Mapeando Classes e Objetos
Quando no h herana, cada classe tipicamente mapeada em uma tabela e
cada instncia da classe (objeto) em uma linha dessa tabela. O modelo de classes deve
ser normalizado previamente, eliminando-se atributos multivalorados. Nesse processo
de normalizao das classes, surge uma importante questo. No modelo relacional, toda
tabela tem de ter uma chave primria, isto , uma ou mais colunas, cujos valores
identificam univocamente uma linha da mesma. Objetos, por sua vez, tm identidade
prpria, independentemente dos valores de seus atributos. Assim, deve-se definir que
identificador nico deve ser usado para designar objetos no banco de dados relacional.
Uma soluo possvel consiste em observar se h um atributo na classe com a
propriedade de identificao nica e utiliz-lo, ento, como chave primria. Caso no
haja um atributo com tal caracterstica, dever ser criado um. Contudo, conforme
discutido na seo 6.1, essa abordagem no a mais indicada. De fato, ela s deve ser
utilizada quando j houver uma base de dados legada sendo utilizada por outros
sistemas.
Uma maneira mais eficaz, sobretudo para permitir a construo de componentes
mais genricos de persistncia, consiste em dar a cada objeto um atributo chamado de
identificador de objeto (id). Os ids so utilizados como chaves primrias nas tabelas do
banco de dados relacional e no devem possuir nenhum significado de negcio. Fowler
(2003) denomina essa abordagem de padro Campo de Identidade (Identity Field), no
qual o identificador salva a chave primria da correspondente linha da tabela no objeto,
de modo a manter um rastro entre o objeto em memria e sua representao como linha
de uma tabela do banco de dados.
6.3.2 - Mapeando Herana
Uma vez que os bancos de dados relacionais no suportam o mecanismo de
herana, necessrio estabelecer uma forma de mapeamento desse mecanismo. A
grande questo no mapeamento da herana diz respeito a como organizar os atributos
herdados no banco de dados. Existem trs solues principais para mapear herana em
um banco de dados relacional, a saber (AMBLER, 1998) (FOWLER, 2003):
Utilizar uma tabela para toda a hierarquia;
Utilizar uma tabela por classe concreta na hierarquia;
Utilizar uma tabela por classe na hierarquia.
No primeiro caso, a tabela derivada contm os atributos de todas as classes na

hierarquia. Fowler (2003) descreve esta soluo como o padro Herana em Tabela
nica (Single Table Inheritance). A vantagem dessa soluo a simplicidade. Alm
disso, ela suporta bem o polimorfismo e facilita a designao de ids, j que todos os

103
objetos esto em uma nica tabela. O problema fundamental dessa soluo que, se as
subclasses tm muitos atributos diferentes, haver muitas colunas que no se aplicam
aos objetos individualmente, provocando grande desperdcio de espao no banco de
dados. Alm disso, sempre que um atributo for adicionado a qualquer classe na
hierarquia, um novo atributo deve ser adicionado tabela. Isso aumenta o acoplamento
na hierarquia, pois, se um erro for introduzido durante a adio desse atributo, todas as
classes na hierarquia podem ser afetadas e no apenas a classe que recebeu o novo
atributo.
No segundo caso, utiliza-se uma tabela para cada classe concreta na hierarquia.
Cada tabela derivada para as classes concretas inclui tanto os atributos da classe quanto
os de suas superclasses. Fowler (2003) descreve essa soluo como o padro Herana
em Tabela Concreta (Concrete Table Inheritance). A grande vantagem a facilidade de
processamento sobre as subclasses concretas, j que todos os dados de uma classe
concreta esto armazenados em uma nica tabela. Da mesma forma que o caso anterior,
a designao de ids facilitada, com a vantagem de se eliminar o desperdcio de espao.
Contudo, h tambm desvantagens. Quando uma superclasse alterada, necessrio
alterar as tabelas. Alm disso, quando h muito processamento envolvendo a
superclasse, h uma tendncia de queda do desempenho da aplicao, j que passa a ser
necessrio manipular vrias tabelas ao invs de uma.
A terceira soluo a mais genrica: utiliza-se uma tabela por classe, no
importando se concreta ou abstrata. Deve haver uma tabela para cada classe e vises
para cada uma das classes derivadas (subclasses). Fowler (2003) descreve essa soluo
como o padro Herana em Tabela de Classe (Class Table Inheritance). Essa
abordagem a que prov o mapeamento mais simples entre classes e tabelas. muito
mais fcil modificar uma superclasse e acrescentar subclasses, j que necessrio
apenas alterar ou acrescentar uma tabela. Uma desvantagem o grande nmero de
tabelas no banco de dados, uma para cada classe. Alm disso, pode levar mais tempo
para acessar dados de uma classe, uma vez que pode ser necessrio acessar vrias
tabelas. Podem ser necessrias mltiplas unies (joins) de tabelas para recuperar um
nico objeto, o que usualmente reduz o desempenho (FOWLER, 2003).
6.3.3 - Mapeando Associaes
Conforme discutido na introduo desta seo, h diferenas substanciais na
forma de lidar com relacionamentos nos modelos orientado a objetos e relacional.
Assim, fundamental mapear associaes em um modelo de objetos para um modelo
relacional. Associaes 1:1 e 1:N so mapeadas por meio da transposio de chaves.
Para tal, aplica-se o padro Mapeamento de Chave Estrangeira (Foreign Key Mapping)
(FOWLER, 2003). J associaes N:N requerem uma tabela associativa, com preconiza
o padro Mapeamento de Tabela Associativa (Association Table Mapping) (FOWLER,
2003). A seguir, algumas particularidades de cada um desses tipos de associaes so
discutidas.
Associaes 1:1
O mapeamento de associaes 1:1 feito transpondo-se a chave primria de uma
tabela para a outra. Quando a associao for obrigatria nas duas extremidades
(multiplicidade mnima 1 em ambas as extremidades), pode-se escolher qualquer das
chaves para transpor. Quando a associao for opcional em pelo menos uma das duas

104
extremidades (multiplicidade mnima 0), melhor transpor a chave que dar origem a
uma coluna mais densa, isto , que ter menos valores nulos. Este o caso do exemplo
da Figura 6.5. Outro fator a ser levado em considerao a navegabilidade da
associao. Sempre que possvel, deve-se transpor a chave que facilite a navegabilidade
escolhida. Por fim, bom frisar que sempre que a associao for obrigatria
(multiplicidade mnima 1), a coluna resultante da chave transposta no poder ter
valores nulos.
Associaes 1:N
O mapeamento de associaes 1:N feito transpondo-se a chave primria da
tabela correspondente classe cuja extremidade da associao tem multiplicidade
mxima 1 para a tabela que corresponde classe cuja extremidade da associao tem
multiplicidade mxima n, como ilustra a Figura 6.6. bom lembrar que sempre que a
associao for obrigatria (multiplicidade mnima 1), a coluna resultante da chave
transposta no poder ter valores nulos, como ilustra a Figura 6.6.
Figura 6.6 Mapeando associaes 1:N.
Associaes N:N
O mapeamento de associaes N:N feito utilizando-se uma tabela associativa,
uma vez que bancos de dados relacionais no so capazes de manipular diretamente
relacionamentos N:N. A Figura 6.7 ilustra este caso. Vale frisar que, muitas vezes, as
chaves transpostas so parte da chave primria da tabela associativa. Quando este for o
caso, elas so identificadas no modelo como sendo chaves primrias, como ilustra a
Figura 6.7.
Figura 6.9 Mapeando associaes N:N.

105
Ainda que os mapeamentos anteriormente discutidos sejam vlidos, Waslawick

(2004) advoga em favor do uso de tabelas associativas para o mapeamento de quaisquer
associaes e no somente as associaes N:N. Sua argumentao a seguinte: Embora
representar associaes 1 ou 0..1 como chaves estrangeiras possa parecer interessante
em um primeiro momento, por evitar a criao de uma nova tabela para representar uma
associao, pode se tornar uma dor de cabea quando for preciso dar manuteno ao
sistema. [...]. mais cmodo deixar as associaes como elementos independentes [...]
a entreme-las na estrutura de tabelas responsveis pela representao dos conceitos.
Quando for necessrio fazer alteraes na estrutura da informao, a vantagem das
tabelas associativas evidente.
6.3 Padres Arquitetnicos para a Camada de Gerncia de Dados

A Camada de Gerncia de Dados - CGD (ou Camada de Persistncia) prov a
infraestrutura bsica para o armazenamento e a recuperao de objetos no sistema. Sua
finalidade isolar os impactos da tecnologia de gerenciamento de dados sobre a
arquitetura do software (COAD; YOURDON, 1993).
A despeito da opo de persistncia adotada (SGBD relacional, SGBD orientado
a objetos, arquivos), h uma importante questo a ser considerada no projeto da CGD:
Que classes devem suportar a persistncia dos objetos?
Uma alternativa tornar cada classe a ser persistida (tipicamente, classes do
domnio do problema), ao longo de toda a arquitetura de software, responsvel por suas
prprias atividades de persistncia. Essa abordagem descrita no padro Registro Ativo
(Active Record) (FOWLER, 2003), no qual uma classe mantm uma linha de uma tabela
ou viso do banco de dados, encapsula o acesso base de dados e adiciona lgica de
domnio o tratamento da persistncia de seus dados. Em outras palavras, esse padro
coloca a lgica de acesso a dados nas classes de domnio do problema e, portanto, no
h efetivamente uma camada de persistncia, j que no h separao entre lgica de
negcio e gerncia de dados. Obviamente, nessa abordagem, a arquitetura torna-se
completamente dependente da tecnologia de persistncia e, se, por exemplo, a
organizao migrar de um SGBD relacional para outro, essa migrao provavelmente
vai ter impactos em vrias classes do sistema. Em geral, essa abordagem
desaconselhvel, s devendo ser aplicada em aplicaes muito simples.
Uma abordagem mais elegante consiste em isolar completamente a lgica de
negcio e o banco de dados, criando uma camada responsvel pelo mapeamento entre
objetos do domnio e tabelas do banco de dados. Os padres Mapeador de Dados (Data
Mapper) (FOWLER, 2003) e Objeto de Acesso a Dados (Data Access Object - DAO)
(BAUER; KING, 2007) adotam esta filosofia, de modo que apenas uma parte da
arquitetura de software fica ciente da tecnologia de persistncia adotada. Essa parte, o
Componente de Gerncia de Dados (CGD), serve como uma camada intermediria
separando objetos do domnio de objetos de gerncia de dados. Via conexes de
mensagem, o CGD l e escreve dados, estabelecendo uma comunicao entre a base de
dados e os objetos do sistema. Qualquer cdigo SQL8 est confinado nessas classes, de
modo que no h cdigo desse tipo em outras classes da arquitetura do software.
8
SQL a abreviatura de Structured Query Language (Linguagem Estruturada de Consulta), a linguagem

de consulta dos bancos de dados relacionais.

106
6.3.1 O Padro Data Mapper

O padro Mapeador de Dados (FOWLER, 2003) prescreve uma camada de
objetos mapeadores que transferem dados entre objetos em memria e o banco de
dados, mantendo-os independentes uns dos outros e dos mapeadores em si. Os objetos
de domnio no tm qualquer conhecimento acerca do esquema do banco de dados e no
precisam de nenhuma interface para cdigo SQL. De fato, eles no precisam saber
sequer que h um banco de dados. O banco de dados, por sua vez, desconhece
completamente os objetos que o utilizam.
Em sua verso mais simples, para cada classe a ser persistida em uma tabela, h
uma correspondente classe mapeadora (ou classe sombra). Seja o exemplo da Figura
6.8. Nesse exemplo, a classe mapeadora PersonMapper intermedeia a classe Person da
lgica de negcio e o acesso a seus dados no banco de dados, na correspondente tabela
(FOWLER, 2003).
Figura 6.8 Padro Data Mapper (FOWLER, 2003).

6.3.2 O Padro DAO
O padro DAO define uma interface de operaes de persistncia, incluindo
mtodos para criar, recuperar, alterar, excluir e fazer consultas de diversos tipos, relativa
a uma particular entidade persistente, agrupando o cdigo relacionado persistncia
daquela entidade (BAUER; KING, 2007). A estrutura bsica do padro, como proposto
em (BAUER; KING, 2007), apresentada na Figura 6.9.
Seguindo esse padro, a camada de persistncia implementada por duas
hierarquias paralelas: interfaces esquerda e implementaes direita. As operaes
bsicas de armazenamento e recuperao de objetos so agrupadas em uma interface
genrica (GenericDAO) e uma superclasse genrica (no exemplo da Figura 6.9,
GenericDAOHibernate). Esta ltima implementa as operaes com uma particular
soluo de persistncia (no caso, Hibernate). A interface genrica estendida por
interfaces para entidades especficas que requerem operaes adicionais de acesso a
dados. O mesmo ocorre com a hierarquia de classes de implementao. Uma
caracterstica marcante desta soluo que possvel ter vrias implementaes de uma
mesma interface DAO (BAUER; KING, 2007).

107
Figura 6.9 Padro DAO (BAUER; KING, 2007).
6.4 Frameworks de Persistncia

Atualmente h muitos frameworks de persistncia disponveis, tais como
Hibernate, Java Data Objects JDO9 e Oracle Toplink10, todos esses para a linguagem
Java. Esses framewoks se encarregam do mapeamento objeto-relacional e tornam o
projeto da camada de persistncia mais simples.
Usando um framework dessa natureza, ao invs de obter os dados dos objetos e
mescl-los a uma string de consulta SQL a ser enviada ao SGBD relacional, o
desenvolvedor deve informar ao framework como transformar objetos/atributos em
tabelas/colunas e chamar mtodos simples, como salvar(), excluir() e recuperarPorId(),
disponveis no framework. A Figura 6.10 ilustra o funcionamento de um framework de
mapeamento O/R. Em geral, esses frameworks disponibilizam tambm uma linguagem
de consulta similar SQL, porm orientada a objetos, para que consultas possam ser
realizadas com facilidade (SOUZA, 2005). O Hibernate, por exemplo, disponibiliza a
linguagem de consulta HQL.
Usando um framework de persistncia, praticamente desnecessrio projetar
tabelas, formatos de campos e outros aspectos tpicos do projeto de bancos de dados
relacionais. Contudo, s vezes necessrio efetuar ajustes no mecanismo de persistncia
para acomodar objetos com caractersticas especiais ou satisfazer requisitos no
funcionais especficos do sistema (WAZLAWICK, 2004). Assim, muito importante
que o projetista saiba como o mapeamento tipicamente feito nesses frameworks.
http://java.sun.com/products/jdo
http://www.oracle.com/technology/products/ias/toplink
10

108
Figura 6.10 Funcionamento de framework de mapeamento O/R (SOUZA, 2005).

Usando o padro DAO em conjunto com um framework de persistncia, o
projeto da camada de persistncia se restringe definio das interfaces e classes
relativas s entidades do domnio a serem persistidas, como ilustrado na Figura 6.9.
Em 2006, dada a existncia de vrios frameworks para persistncia de objetos
Java, foi lanada Java Persistence API (JPA). A JPA permite o armazenamento de
dados em bancos de dados relacionais sem se ficar preso a um framework de
persistncia especfico. Por meio da JPA, operaes de manipulao de tabelas so
delegadas para um framework de persistncia que implemente a JPA. Realizado o
mapeamento O/R, possvel utilizar um framework, que suporte JPA (como Hibernate,
Oracle TopLink, Kodo, OpenJPA, entre outros), para fazer as devidas inseres, buscas,
excluses e alteraes nos dados da aplicao nas tabelas do banco de dados. Dessa
forma, o cdigo da aplicao fica independente de frameworks de persistncia, pois todo
o cdigo utilizado para manipular o banco de dados passa a ser da JPA (VILLELA;
SILVA, 2010).
Em (FOWLER, 2003), o Captulo 3 Mapping to Relational Databases
discute diversos aspectos do projeto da persistncia de objetos em bancos de dados
relacionais. Os padres discutidos nesse captulo so posteriormente apresentados em
detalhes nos captulos 10, 11, 12 e 13. Alm de aspectos discutidos neste texto, Fowler
trata vrios outros problemas relativos ao projeto da camada de persistncia, dentre eles
problemas relacionados com a recuperao de objetos e com conexes com o banco de
dados.
O Captulo 10 de (WAZLAWICK, 2004) Projeto da Camada de Persistncia,
trata do projeto da camada de persistncia, incluindo equivalncias entre modelos de
classes e modelos relacionais e aspectos relativos a como e quando os objetos sero
salvos e carregados do banco de dados.

109
Bauer e King (2007) discutem vrios aspectos do projeto da camada de

persistncia, indo desde mapeamento O/R at detalhes de implementao usando o
framework Hibernate.
Ainda que no discutidos neste texto, vrios dos padres de projeto propostos
em (GAMMA et al., 1995) so muito utilizados no projeto da camada de persistncia,
dentre eles os padres Procurador (Proxy) e Fbrica Abstrata (Abstract Factory).
AMBLER, S., Anlise e Projeto Orientados a Objetos. IBPI Press, 1998.
BAUER, C., KING, G., Java Persistence with Hibernate, Manning, 2007.
COAD, P., YOURDON, E., Projeto Baseado em Objetos, Editora Campus, 1993.
SOUZA, V.E.S., FrameWeb: um Mtodo baseado em Frameworks para o Projeto de
Sistemas de Informao Web, Dissertao de Mestrado, Programa de PsGraduao em Informtica, UFES, Universidade Federal do Esprito Santo, 2005.
VILLELA, M., SILVA, E., JPA 2.0 - Persistncia a Toda Prova, Java Magazine 81,
2010.

Captulo 7 Projeto de Classes e Avaliao da

Qualidade do Projeto de Software
110

Uma vez definidos e refinados todos os componentes da arquitetura de software,
deve-se passar ao projeto detalhado das classes, quando se projetam detalhadamente os
atributos, as associaes e os mtodos de cada classe. Neste momento, devero ser
definidos, dentre outros, as interfaces dos mtodos, os algoritmos usados para
implement-los e a visibilidade de atributos, associaes e mtodos.
Inicialmente, uma descrio do protocolo de cada classe deve ser estabelecida,
indicando o conjunto de mtodos da classe acessveis a objetos de outras classes, i.e. sua
interface pblica. A seguir, deve-se fazer uma descrio da implementao da classe,
provendo detalhes internos necessrios para a implementao, mas no necessrios para
a comunicao entre objetos.
Concludo o projeto de classes, a fase de projeto pode ser considerada finalizada.
Contudo, antes de dar como concluda essa fase, imprescindvel avaliar a qualidade do
Documento de Projeto (ou Especificao de Projeto), artefato contendo os modelos
produzidos e informaes relevantes acerca das decises tomadas. Na verdade, no
necessrio concluir a fase de projeto para avaliar a qualidade do que est sendo
produzido nessa fase. Essa avaliao pode, e deve, ser conduzida em pontos de controle
demarcados previamente, visando avaliar subprodutos da fase de projeto, tais como a
arquitetura de software e os modelos dos componentes da arquitetura.
Este captulo discute brevemente o projeto detalhado das classes e a avaliao da
qualidade do projeto de software como um todo. Ele est estruturado da seguinte forma:
a Seo 7.1 trata de aspectos relacionados ao projeto de atributos e associaes; a Seo
7.2 trata de aspectos relacionados ao projeto de mtodos; finalmente, a Seo 7.3
discute brevemente a avaliao do projeto de software.
7.1 Projetando Atributos e Associaes

Tipicamente, classes de um projeto orientado a objetos so diretamente
implementadas na forma de classes em uma linguagem de programao. As excees
ficam por conta de pginas Web tradicionais, caso as mesmas tenham sido projetadas
como classes do Componente de Interface com o Usurio.
Atributos e associaes so implementados como variveis de instncia da
respectiva classe. No caso de atributos monovalorados, o tipo da varivel de instncia
um tipo bsico da linguagem de programao adotada, tal como int, float e string, ou
um tipo de dado de domnio previamente estabelecido, conforme definido no projeto do
componente correspondente. No caso de associaes navegveis com multiplicidade
mxima 1, a classe de origem da associao deve ter uma varivel de instncia do tipo
da classe de destino.


111
Recomenda-se fortemente que todos os atributos e associaes sejam definidos

como privados. Como decorrncia disso, a classe deve implementar mtodos para
acessar (get) e alterar (set) os valores de seus atributos. Aconselha-se que esses mtodos
sejam nomeados com o nome do atributo/associao precedido pelas palavras get e set,
respectivamente. Esse um padro indicado, pois adotado pela maioria das
ferramentas CASE durante a gerao de cdigo. Alm disso, quando a camada de
persistncia construda usando o framework Hibernate, p.ex., essa nomeao
fundamental para o funcionamento do mecanismo de persistncia.
Wazlawick (2004) refora que, para viabilizar o funcionamento do mecanismo
de persistncia, fundamental que os atributos sejam acessados e modificados
exclusivamente pelas operaes get e set. Em hiptese alguma outro mtodo, mesmo
sendo da prpria classe, poder acessar ou modificar tais variveis diretamente.
Quando uma classe possui um atributo obrigatrio ou uma associao navegvel
de multiplicidade mnima 1, seu mtodo construtor deve ter um parmetro do tipo
definido a ser atribuda varivel de instncia correspondente, de modo a manter a
consistncia. Quando isso no ocorrer no mtodo construtor, necessrio que a criao
do objeto acontea no contexto de uma transao que envolva tambm a atribuio do
valor (mtodo set).
No caso de atributos multivalorados ou associaes navegveis com
multiplicidade mxima n, a implementao feita tipicamente por meio de uma varivel
de instncia de um tipo de uma estrutura de dados que comporte uma coleo de
elementos, tal como o tipo Conjunto (Set). Para facilitar a identificao no cdigo de
que se trata de um conjunto de valores, recomenda-se utilizar o nome da varivel no
plural. Alm disso, importante garantir que a classe usada para implementar o tipo
Conjunto tenha mtodos para adicionar e remover elementos do conjunto. Nesse caso,
os mtodos get e set so usados para obter e atribuir a coleo inteira e no um elemento
da coleo. Por fim, caso a coleo seja ordenada, deve-se utilizar uma estrutura de
dados que trabalhe a ordenao, tal como uma lista.
Quando uma associao for bidirecional, i.e., navegvel nos dois sentidos, ela
deve ser implementada em ambas as classes (seguindo as diretrizes apresentadas
anteriormente). Contudo, ateno especial deve ser dada ao controle da redundncia, de
modo a se manter a consistncia.
7.2 Projetando Mtodos

No que concerne aos mtodos, necessrio definir os tipos e estruturas de dados
para as interfaces (parmetros e retorno), bem como uma especificao do algoritmo de
cada mtodo. No caso de operaes complexas, uma boa opo dividi-las, criando
mtodos de nvel mais baixo, estes privadas classe. O projeto algortmico de uma
operao pode revelar a necessidade de variveis locais aos mtodos ou de variveis
globais classe para tratar detalhes internos. Definir as estruturas de dados a serem
utilizadas para essas variveis tambm parte do projeto detalhado dos mtodos.
Para o projeto dos algoritmos, pode-se utilizar pseudocdigo. Contudo, h que se
avaliar a utilidade de especificaes detalhadas de algoritmos e se h necessidade de
fazer essas especificaes para todos os mtodos. Como regra geral, essa estratgia s


112
deve ser aplicada a mtodos em que no intuitivo saber o que se espera deles ou
quando h regras de negcio especficas a serem tratadas.
Durante o projeto detalhado dos mtodos, deve-se levar em conta que projetistas
muitas vezes no conhecem os recursos da linguagem de programao adotada to bem
quanto os programadores. Por exemplo, as linguagens de programao oferecem uma
variedade de estruturas de dados, tais como vetores, listas, filas, pilhas, conjuntos,
mapas etc., e o projetista pode no fazer a melhor escolha em relao s estruturas a
serem utilizadas. O mesmo ocorre em relao ao projeto dos algoritmos. De fato, o
projeto de mtodos est na tnue fronteira entre o projeto detalhado e a implementao.
Assim, pode ser mais produtivo deix-lo por conta dos programadores, supervisionados
pelos projetistas.
7.3 Avaliando a Qualidade do Documento de Projeto

A qualidade de um produto de software no se atinge de forma espontnea. Ela
deve ser construda ao longo do processo de desenvolvimento de software. Para tal,
necessrio avaliar a qualidade dos diversos produtos intermedirios do processo de
software, dentre eles o Documento de Projeto de Software ou Especificao de Projeto.
O Documento de Projeto um documento valioso. Ele servir de base para as
etapas de implementao e testes. Assim, a qualidade desse documento vital para a
qualidade do produto de software resultante.
Diversos aspectos do projeto devem ser avaliados. importante lembrar que h
vrios projetos possveis que podem implementar corretamente um conjunto de
requisitos. Um bom projeto equilibra custo e benefcio, de modo a minimizar o custo
total do sistema ao longo de seu tempo de vida total. Coad e Yourdon (1993) propem
alguns critrios para avaliao da qualidade de projetos orientados a objetos, dentre
eles:
Acoplamento: conforme discutido no Captulo 2, acoplamento diz respeito ao

grau de interdependncia entre componentes de software. O objetivo
minimizar o acoplamento, isto , tornar os componentes to independentes
quanto possvel. No projeto orientado a objetos, deve ser avaliado tanto o
acoplamento entre classes como o acoplamento entre subsistemas. A meta
minimizar o nmero de mensagens trocadas e a complexidade e o volume de
informao nas mensagens.
Coeso: define como as atividades de diferentes componentes de software esto

relacionadas umas com as outras. Vale a pena ressaltar que coeso e
acoplamento so interdependentes e, portanto, uma boa coeso, geralmente,
conduz a um pequeno acoplamento. No projeto orientado a objetos, trs nveis
de coeso devem ser verificados:
o Coeso de mtodos individuais: um mtodo deve executar uma e
somente uma funo;
o Coeso de classes: atributos e operaes encapsulados em uma classe
devem ser altamente coesos, isto , devem estar estreitamente
relacionados; e


113
o Coeso de hierarquias de classes: a coeso de uma hierarquia pode ser

avaliada examinando-se at que extenso uma subclasse redefine ou
cancela atributos e mtodos herdados da superclasse. Alm disso,
fundamental garantir que subclasses so realmente especializaes das
superclasses, evitando-se a herana por convenincia.
Clareza: um projeto deve ser passvel de entendimento por programadores,

testadores e outros projetistas.
Reutilizao: bons projetos devem ser fceis de serem reutilizados e devem,

sempre que possvel, reutilizar pores de projeto previamente elaborados e
padres de projeto (padres arquitetnicos e design patterns) consagrados.
Efetivo Uso da Herana: para sistemas mdios, hierarquias de classe no devem

ter mais do que sete nveis de generalizao-especializao. Projetos com uso
intensivo de herana mltipla devem ser evitados, pois so mais difceis de
serem entendidos e, consequentemente, de serem reutilizados e mantidos.
Protocolo de Mensagens Simples: protocolos de mensagem complexos so uma

indicao comum de acoplamento excessivo entre classes. Assim, a passagem de
muitos parmetros deve ser evitada.
Mtodos Simples: os mtodos que implementam as operaes de uma classe

devem ser mantidos pequenos. Se um mtodo envolve muito cdigo, h uma
indicao de que as operaes da classe foram pobremente divididas.
Habilidade de avaliar por cenrio: importante que um projeto possa ser

avaliado a partir de um cenrio particular escolhido. Revisores devem poder
representar o comportamento de classes e objetos individuais e, assim, verificar
o comportamento dos objetos nas circunstncias desejadas. Essa caracterstica
igualmente importante para testar posteriormente o produto de software.
Assim como os demais documentos produzidos ao longo do processo de

software, o Documento de Projeto deve ser revisado. Durante uma reviso desse
documento, os seguintes aspectos devem ser observados:
Aderncia a padres de documento de projeto estabelecidos pela

organizao.
Aderncia a padres de nomenclatura estabelecidos pela organizao,

incluindo nomes de classes, atributos, mtodos, pacotes etc.
Coerncia com os modelos de anlise e de especificao de requisitos.
Do ponto de vista de coerncia entre modelos, os seguintes aspectos devem ser

observados:
As classes da Camada de Lgica de Negcio devem ser necessrias e

suficientes para cumprir as responsabilidades apontadas pelos casos de uso
do documento de especificao de requisitos, agora j com uma perspectiva
de implementao, i.e., levando-se em conta os requisitos no funcionais.


114
As classes da Camada de Interface com o Usurio devem ser necessrias e

suficientes para permitir o acesso e a realizao de todos os casos de uso do
documento de especificao de requisitos.
As classes da Camada de Gerncia de Dados devem ser necessrias e

suficientes para tratar do armazenamento e recuperao de objetos de todas
as classes persistentes do sistema (tipicamente, as classes do Componente de
Domnio do Problema).
Alteraes no decorrentes da tecnologia, mas da deteco de um erro na

especificao de requisitos ou na anlise devem ser feitas nos
correspondentes modelos de especificao e anlise de requisitos. No basta
alterar o documento de projeto. Lembre-se que fundamental manter a
coerncia entre os modelos de anlise e projeto.
Em (BLAHA; RUMBAUGH, 2006), o Captulo 15 Projeto de Classes
aborda os temas discutidos neste captulo, com destaque para a seo 15.4 (Projetando
Algoritmos).
O Captulo 8 de (WAZLAWICK, 2004) Gerao de Cdigo apresenta regras
para a gerao de cdigo a partir do Componente de Domnio do Problema e aborda
vrios dos aspectos discutidos neste captulo.
2, Elsevier, 2006.
COAD, P., YOURDON, E., Projeto Baseado em Objetos, Editora Campus, 1993.

Anexo A Padres Relativos Fase de Projeto
115
Anexo A Padres de Projeto
Projetistas experientes fazem bons projetos, normalmente reutilizando solues

que j funcionaram no passado. Quando encontram uma boa soluo, eles a reutilizam
vrias vezes. Projetistas novatos, por outro lado, tendem a resolver os problemas usando
apenas os princpios bsicos. Demora muito tempo at que os novatos ganhem
experincia e aprendam a fazer bons projetos (GAMMA et al., 1995).
Os padres (patterns) visam capturar esse conhecimento, procurando torn-lo
mais geral e amplamente aplicvel, desvinculando-o das especificidades de um
determinado projeto ou sistema. Um padro uma soluo testada e aprovada para um
problema geral e apresenta diretrizes sobre quando us-lo, bem como vantagens e
desvantagens de seu uso. Um padro j foi cuidadosamente considerado por outras
pessoas e aplicado diversas vezes na soluo de problemas anteriores de mesma
natureza. Assim, tende a ser uma soluo de qualidade, com maiores chances de estar
correto e estvel do que uma soluo nova, especfica, ainda no testada (BLAHA;
RUMBAUGH, 2006). Padres relativos fase de projeto ajudam projetistas a reutilizar
projetos bem sucedidos, ao basear novos projetos em experincias anteriores. Um
projetista familiarizado com tais padres pode aplic-los imediatamente em problemas
de projeto sem ter de redescobri-los (GAMMA et al., 1995).
Padres permitem reusar arquiteturas e projetos bem sucedidos. Um padro
sistematicamente nomeia, explica e avalia uma poro de projeto importante e
recorrente. Ao expressar abordagens comprovadas na forma de padres, esse
conhecimento torna-se acessvel a projetistas de novos sistemas (GAMMA et al., 1995).
No que se refere a padres relativos fase de projeto, h dois principais tipos de
padres: padres arquitetnicos, que definem uma estrutura global do sistema, e padres
de projeto (design patterns), que descrevem uma estrutura comumente recorrente de
componentes que se comunicam, a qual resolve um problema de projeto geral dentro de
um particular contexto (GAMMA et al., 1995).
Este anexo apresenta uma viso geral do catlogo de padres de projeto proposto
por Gamma et al. (1995), apresentando alguns dos padres propostos nesse catlogo.

116
A.1 O Catlogo de Gamma et al. (1995)

Um dos principais catlogos de padres de projeto orientado a objetos
publicados at o momento o apresentado em (GAMMA et al., 1995). A descrio dos
padres nesse catlogo consiste de:
Nome: nome dado ao padro no catlogo.
Classificao: feita segundo dois critrios: propsito e escopo. O propsito

reflete o que o padro faz, isto , sua funcionalidade. De acordo com esse
critrio, um padro pode ser: criativo (diz respeito ao processo de criao de
objetos); estrutural (lida com a composio de classes ou objetos); ou
comportamental (caracteriza os meios pelos quais classes ou objetos
interagem e distribuem responsabilidades). O escopo, por sua vez, especifica
se o padro est centrado em classes (e neste caso, faz intenso uso de
herana) ou em objetos (e, portanto, mais apoiado em associaes).
Inteno (Propsito): descreve sucintamente o que faz o padro, seu

propsito e o problema endereado.
Tambm conhecido como: apresenta outros nomes pelos quais o padro

conhecido (se houver).
Motivao: apresenta um cenrio que ilustra o problema endereado pelo

padro e como a estrutura proposta pelo padro resolve esse problema.
Aplicabilidade: trata de situaes nas quais o padro pode ser aplicado e

como reconhecer essas situaes.
Estrutura: apresenta o modelo de classes do padro e, opcionalmente,

diagramas de interao para ilustrar sequncias de requisies e colaboraes
entre objetos.
Participantes: fornece uma descrio das classes e/ou objetos que

participam do padro e suas responsabilidades.
Colaboraes: descreve como os participantes colaboram para realizar suas

responsabilidades.
Consequncias: trata dos comprometimentos e resultados quando se aplica o

padro, tanto positivos como negativos.
Implementao: discute armadilhas e sugestes na implementao do

padro, bem como tcnicas e questes especficas de linguagem.
Cdigo-Exemplo: apresenta fragmentos de cdigo em C++ ou Smalltalk que

ilustram como o padro pode ser implementado.
Usos conhecidos: apresenta exemplos de uso do padro encontrados em

sistemas reais.
Padres relacionados: faz referncia a outros padres proximamente

relacionados com o padro em questo, discutindo diferenas. Relaciona,
tambm, outros padres que devem ser utilizados juntamente com este.

117
Tendo em vista a classificao proposta por Gamma et al. (1995), possvel

apontar os objetivos gerais de cada grupo de padres. Quanto ao propsito, os
seguintes objetivos so vlidos:
Padro Criativo: abstrai o processo de instanciao (criao) de objetos,

ajudando a tornar um sistema independente de como seus objetos so
criados, compostos e representados.
o
Padro Criativo de Classe: utiliza herana para variar a classe

instanciada, adiando alguma parte da criao de objetos para subclasses.
Padro Criativo de Objeto: delega a instanciao de um objeto para outro

objeto ou adia alguma parte da criao de um objeto para outro objeto.
Padro Estrutural: diz respeito a como classes e objetos so compostos

para formar estruturas maiores.
o
o
Padro Estrutural de Classe: utiliza herana para compor classes.

Padro Estrutural de Objeto: descreve meios de compor objetos a partir
de outros objetos, visando obter nova funcionalidade. A flexibilidade
adicional da composio de objetos advm da habilidade de alterar uma
composio em tempo de execuo, o que impossvel com a
composio esttica de classes.
Padro Comportamental: diz respeito a algoritmos e a atribuio de

responsabilidades entre objetos.
o Padro Comportamental de Classe: utiliza herana para distribuir
comportamento entre classes, ou seja, para descrever algoritmos e fluxos
de controle.
o Padro Comportamental de Objeto: utiliza composio de objetos para
distribuir o comportamento. Descreve como um grupo de objetos
coopera para realizar uma tarefa que nenhum objeto poderia realizar
sozinho.
A Tabela A.1 apresenta o catlogo de padres proposto por Gamma et al. (1995).
Na sequncia, apresentada uma breve descrio de cada um dos padres.

118
Tabela A.1 Catlogo de Padres proposto em (GAMMA et al., 1995).

Propsito
Escopo
Classe
Criativo
Mtodo-Fbrica
Estrutural
Adaptador (classe)
Comportamental
Interpretador
Mtodo Modelo
Objeto
Construtor
Adaptador (objeto)
Cadeia de Responsabilidade
Fbrica Abstrata
Composto
Comando
Prottipo
Decorador
Iterador
Singular
Fachada
Mediador
Peso-Mosca
Memorial
Ponte
Observador
Procurador (Proxy)
Estado
Estratgia
Visitador
Padres de Classe:
Mtodo-Fbrica (Factory Method): define uma interface para a criao de

objetos, mas deixa que uma classe adie a instanciao para suas subclasses.
Adaptador (Adapter): converte a interface de uma classe em outra interface,

permitindo que classes trabalhem em conjunto, quando isto no seria possvel
por causa da incompatibilidade de interfaces.
Mtodo Modelo (Template Method): define o esqueleto de um algoritmo em

uma operao, adiando alguns de seus passos para as subclasses, permitindo que
as subclasses redefinam certos passos do algoritmo sem alterar sua estrutura.
Interpretador (Interpreter): Dada uma linguagem, define uma representao

para sua gramtica, junto com um interpretador que utiliza essa representao
para interpretar sentenas na linguagem.
Padres de Objetos:
Construtor (Builder): separa a construo de um objeto complexo de sua

representao de modo que o mesmo processo de construo pode criar
diferentes representaes.
Fbrica Abstrata (Abstract Factory): prov uma interface para a criao de

famlias de objetos relacionados ou dependentes, sem especificar suas classes
concretas.
Prottipo (Prototype): especifica os tipos de objetos que podem ser criados a

partir de uma instncia prototpica e cria novos objetos copiando este prottipo.

119
Singular (Singleton): garante que uma classe possui uma nica instncia e
prov um ponteiro global para acess-la.
Composto (Composite): compe objetos em estruturas de rvore para

representar hierarquias todo-parte, permitindo que clientes tratem objetos
individuais e compostos uniformemente.
Decorador (Decorator): anexa responsabilidades adicionais a um objeto

dinamicamente, permitindo estender sua funcionalidade.
Fachada (Facade): prov uma interface unificada para um conjunto de

interfaces em um subsistema. Define uma interface de nvel mais alto para o
subsistema, tornando-o mais fcil de ser usado.
Peso-Mosca (Flyweight): utiliza compartilhamento para suportar eficientemente

um grande nmero de objetos de granularidade muito fina.
Ponte (Bridge): desacopla uma abstrao de sua implementao, de modo que

ambas possam variar independentemente.
Procurador (Proxy): prov um substituto/procurador (proxy) que tem

autorizao para controlar o acesso a um objeto.
Cadeia de Responsabilidades (Chain of Responsibility): evita o acoplamento

entre o objeto emissor de uma mensagem e o receptor, dando chance para mais
de um objeto tratar a solicitao. Encadeia os objetos receptores e passa a
mensagem adiante na cadeia at que um objeto a trate.
Comando (Command): encapsula uma requisio como um objeto, permitindo,

assim, parametrizar clientes com diferentes requisies e desfazer operaes
(comando undo).
Iterador (Iterator): prov um meio de acessar sequencialmente os elementos de

um objeto agregado sem expor sua representao bsica.
Mediador (Mediator): define um objeto que encapsula como um conjunto de

objetos interage.
Memento (Memento): sem violar o encapsulamento, captura e externaliza o

estado interno de um objeto de modo que se possa posteriormente restaurar o
objeto para este estado.
Observador (Observer): define uma dependncia um-para-muitos entre objetos

de modo que quando um objeto muda de estado, todos os seus dependentes so
notificados e atualizados automaticamente.
Estado (State): permite que um objeto altere o seu comportamento quando seu
estado interno muda, fazendo parecer que o objeto mudou de classe.
Estratgia (Strategy): define uma famlia de algoritmos, encapsula cada um

deles e os torna intercambiveis. Deste modo, o algoritmo varia
independentemente dos clientes que o utlizam.
Visitador (Visitor): representa uma operao a ser executada sobre os elementos

de uma estrutura de um objeto. Permite definir uma nova operao sem alterar as
classes dos elementos sobre as quais ele opera.

120
Gamma et al. (1995) sugerem que, para se utilizar um padro do catlogo, os

seguintes passos devem ser seguidos:
1. Leia o padro uma vez para obter uma viso geral, concentrando a ateno nas
sees de Aplicabilidade e Consequncias para garantir que este o padro certo
para o seu problema.
2. Volte e estude as sees de Estrutura, Participantes e Colaboraes. Tenha a certeza
de que compreendeu as classes e objetos no padro e como se relacionam entre si.
3. Olhe a seo Cdigo de Exemplo para ver um exemplo concreto do padro em
cdigo. Isto vai ajud-lo a aprender a implementar o padro.
4. Escolha nomes para os participantes (classes e/ou objetos) do padro que sejam
significativos no contexto de sua aplicao. Os nomes em um padro de projeto so
geralmente muito abstratos para aparecerem diretamente em uma aplicao.
Contudo, til incorporar o nome do participante do padro de projeto ao seu nome
na aplicao, de modo a tornar o padro mais explcito na implementao.
5. Defina as classes.
6. Defina nomes especficos da aplicao para as operaes no padro.
7. Implemente as operaes para realizar as responsabilidades e colaboraes do
padro.
Padres de projeto no devem ser aplicados indiscriminadamente.
Frequentemente, eles alcanam flexibilidade e variabilidade atravs da introduo de
nveis adicionais de indireo que podem complicar um projeto e/ou resultar em queda
de desempenho.
Um padro de projeto s deve ser aplicado quando a flexibilidade que ele
proporciona for realmente necessria. A seo de Consequncias muito til para a
avaliao dos benefcios e obrigaes de um padro.
Padres de projeto so bastante teis para a criao de projetos robustos, aptos a
suportar mudanas, garantindo que o sistema pode ser alterado de certas maneiras. Cada
padro permite que algum aspecto da estrutura do sistema varie de forma independente
de outros aspectos, tornando o sistema mais robusto para um particular tipo de
alterao.
A seguir, so parcialmente apresentados alguns dos padres de projeto propostos
em (GAMMA et al., 1995).
A 1.1 - Fbrica Abstrata (Abstract Factory)
Classificao: Padro Criativo de Objeto
Propsito: Prover uma interface para criar famlias de objetos relacionados ou
dependentes, sem especificar suas classes concretas.
Tambm conhecido como: Kit.
Motivao: Toolkit de Interface Grfica com o Usurio, suportando diferentes
padres de apresentao (Motif, Presentation Manager,...). Cada padro de
apresentao define diferentes comportamento e aparncia para objetos de

121
interface, tais como janelas, botes, barras de scroll, etc. Para ser portvel ao
longo de diferentes padres de apresentao, uma aplicao no pode se
comprometer com um padro especfico.
Aplicabilidade:
Sistema deve ser independente de como seus produtos so criados,
compostos e representados.
Sistema deve ser configurado com uma dentre vrias famlias de produtos.
Uma famlia de produtos relacionados foi projetada para ser usada em
conjunto e esta restrio tem de ser garantida.
Estrutura:
Cliente
FbricaAbstrata
CriarProdutoA
CriarProdutoB
ProdutoAbstratoA
ProdutoA2
FbricaConcreta1
FbricaConcreta2
CriarProdutoA
CriarProdutoB
CriarProdutoA
CriarProdutoB
ProdutoA1
ProdutoAbstratoB
ProdutoB2
ProdutoB1
Participantes:
Fbrica Abstrata: declara uma interface para operaes criam objetosproduto abstratos;
Fbrica Concreta: implementa as operaes para criar objetos-produto
concretos;
Produto Abstrato: declara uma interface para um tipo de objeto produto.
Produto Concreto: implementa a interface abstrata de Produto Abstrato e
define um objeto-produto a ser criado pela Fbrica Concreta
correspondente.
Cliente: utiliza apenas as interfaces declaradas por Fbrica Abstrata e
Produto Abstrato.

122
Colaboraes: Fbrica Abstrata adia a criao de objetos-produto para suas

subclasses Fbricas Concretas.
Consequncias:
Isola classes concretas: uma vez que uma fbrica encapsula a
responsabilidade e o processo de criao de objetos-produto, ela isola
clientes das classes de implementao.
Fica mais fcil a troca de uma famlia de produtos, bastando trocar a
fbrica concreta usada pela aplicao.
Promove consistncia entre produtos. Quando objetos-produto em uma
famlia so projetados para trabalhar juntos, importante que uma
aplicao utilize apenas objetos desta famlia.
O suporte a novos tipos de produtos dificultado, j que a interface da
Fbrica Abstrata fixa o conjunto de produtos que podem ser criados. Para
suportar novos tipos de produtos, necessrio alterar a interface da fbrica,
o que envolve alteraes na Fbrica Abstrata e em todas as suas
subclasses.
Cliente
FbricaDeObjetos
Grficos
Janela
CriarJanela
CriarBarraScroll
JanelaPM
FbricaMotif
FbricaPM
CriarJanela
CriarBarraScroll
CriarJanela
CriarBarraScroll
JanelaMotif
BarraScroll
BScrollPM
BScrollMotif
A 2.2 - Mtodo Modelo (Template Method)
Classificao: Padro Comportamental de Classe.
Propsito: Definir o esqueleto de um algoritmo em uma operao, adiando

alguns passos para as subclasses.
Aplicabilidade: Para implementar apenas uma vez as partes que no variam
de um algoritmo e deixar a cargo das subclasses a implementao do
comportamento varivel.

123
Estrutura:
Participantes:
Classe Abstrata: implementa um mtodo modelo, definindo o esqueleto de
um algoritmo e define operaes primitivas abstratas que as subclasses
concretas tm de definir para implementar os passos do algoritmo;
Classe Concreta: implementa as operaes primitivas para realizar passos
do algoritmo que so especficos da subclasse.
Colaboraes: A Classe Concreta conta com a Classe Abstrata que
implementa os passos que no variam do algoritmo.
Padres Relacionados:
Mtodo Fbrica: mtodos-fbrica normalmente so chamados por
mtodos-modelo;
Estratgia: enquanto os mtodos-modelo utilizam herana para variar
partes de um algoritmo, as estratgias usam delegao para variar o
algoritmo inteiro.
A 2.3 - Procurador (Proxy)
Classificao: Padro Estrutural de Objeto
Propsito: prov um substituto/procurador que tem autorizao para controlar

o acesso ao objeto.
Tambm conhecido como: Substituto, Proxy.
Motivao: Uma razo para se controlar o acesso a um objeto tentar adiar o
alto custo de criao e inicializao deste objeto at o momento em que ele
for ser realmente utilizado. Considere um editor de texto que pode embutir
objetos grficos em um documento. Alguns desses objetos, como figuras
complexas, podem ter um alto custo de criao. Contudo, a abertura de um
documento deve ser rpida. Assim, desejvel evitar a criao de todos esses
objetos no momento em que o documento aberto, at porque muitos deles

124
no estaro visveis ao mesmo tempo. Esta restrio sugere a criao dos

objetos complexos sob demanda, isto , o objeto s ser criado no momento
em que sua imagem se tornar visvel. Mas o que colocar no documento no
lugar da imagem? E como esconder essa abordagem sem complicar a
implementao do editor? A soluo consiste em criar um outro objeto, o
procurador (proxy) da imagem, que atuar como substituto para a imagem
real. Este procurador agir exatamente como a imagem e cuidar de sua
instanciao quando a mesma for requerida. O procurador da imagem criar a
imagem real somente quando o editor de texto requisitar a ele que exiba a
imagem, atravs da operao desenhar( ). A partir da, o procurador passar
adiante as requisies subsequentes diretamente para a imagem, como ilustra
o diagrama de sequncia abaixo.
: E ditorTex to
fi gur aS ubs ti tut a :

FiguraS ubstituta
fi guraReal :
FiguraReal
desenhar( )
[figuraReal == null] c arregar( )
desenhar( )
Aplicabilidade: O padro Procurador aplicvel sempre que houver

necessidade de uma referncia mais verstil ou sofisticada do que um simples
ponteiro. A seguir so listadas algumas situaes nas quais este padro
aplicvel:
Um Procurador Remoto prov uma representao local para um objeto que
se encontra em um outro espao de endereamento.
Um Procurador Virtual cria objetos complexos sob demanda, como no
caso do exemplo da motivao.
Um Procurador de Proteo controla o acesso ao objeto original. Este tipo
de procurador amplamente utilizado quando h diferentes direitos de
acesso ao objeto original. Neste caso, o procurador serve como uma
espcie de filtro.
Um Procurador de Referncia Inteligente uma substituio para um
ponteiro simples, que realiza operaes adicionais quando o objeto
acessado. Isto pode ser til em muitas situaes, tais como:

125
contar o nmero de referncias ao objeto real, de forma tal que ele

possa ser liberado automaticamente quando no houver mais
referncias a ele;
carregar um objeto persistente para a memria quando ele for
referenciado pela primeira vez;
verificar se o objeto real no est bloqueado antes de permitir um
acesso a ele, garantindo que nenhum outro objeto poder altera-lo.
Estrutura:
Participantes:
Assunto: define uma interface comum para o ObjetoReal e para o
Procurador, de modo que o procurador possa ser usado no lugar do objeto
real;
Procurador: representa um substituto para o objeto real. Para tal, mantm
uma referncia ao objeto real, que o permite acessar este objeto. Sua
interface deve ser idntica do objeto real, de modo que possa ser por ele
substitudo. Alm disso, controla o acesso ao objeto real e pode ser
responsvel pela criao e excluso do mesmo. Outras responsabilidades
podem lhe ser atribudas em funo do tipo do procurador;
ObjetoReal: define o objeto real que o procurador representa.
Colaboraes: O procurador envia requisies para o objeto real, quando for
apropriado, dependendo do tipo de Procurador.
Consequncias: O padro Procurador introduz um nvel de indireo quando
se acessa o objeto. Essa indireo adicional tem muitos usos, dependendo do
tipo de procurador. Um Procurador Remoto, por exemplo, pode esconder o
fato de um objeto residir em um espao de endereamento diferente. Um
Procurador Virtual pode realizar otimizaes, como criar um objeto sob
demanda. Procuradores de Proteo e de Referncia Inteligente, por sua vez,
permitem tarefas adicionais de gerenciamento quando um objeto acessado.

Figura
126
0. .*
E ditorTe xto
des e nhar()
c arreg ar()
Figu raS ubst it uta
Figura Rea l
0. .*
desenhar()
carregar()
0..1
des e nhar()
c arregar()
des enhar()
{
if (figuraReal = = null)
figuraReal = carregar();
figuraReal.desenhar();
}
Padres Relacionados:
Adaptador: um adaptador prov uma interface diferente para o objeto que
ele adapta. O procurador prov a mesma interface.
Decorador: Um decorador adiciona responsabilidades a um objeto,
enquanto o procurador controla o acesso ao objeto.
A 1. 5 Observador (Observer)
Classificao: Padro Comportamental de Objeto
Propsito: define uma dependncia um-para-muitos entre objetos de modo

que quando um objeto muda de estado, todos os seus dependentes so
notificados e atualizados automaticamente.
Tambm conhecido como: Dependentes.
Motivao: uma boa opo para ferramentas de interfaces grficas com o
usurio separar aspectos de apresentao dos respectivos dados da aplicao.
As classes dos componentes de domnio do problema e de interface com o
usurio podem ser reutilizadas independentemente, assim como podem
trabalhar juntas. Por exemplo, os mesmos dados estatsticos podem ser
apresentados em formato de grfico de barras ou planilha, usando
apresentaes diferentes. O grfico de barras e a planilha devem ser

127
independentes, de modo a permitir reuso. Contudo, eles tm de se comportar

consistentemente, isto , quando um usurio altera a informao na planilha,
o grfico de barras reflete a troca imediatamente e vice-versa.
50
30
20
X
a = 50%
b = 30%
c = 20%
notificao de alterao
pedido de alterao
Este comportamento implica que a planilha e o grfico de barras so

dependentes do mesmo objeto de dados e, portanto, devem ser notificados quando
ocorre alguma mudana no estado desse objeto.
O padro Observador descreve como se estabelecem estes relacionamentos. Os
objetos principais deste padro so Sujeito e Observador. O sujeito, no exemplo o
objeto X, pode ter qualquer nmero de observadores, no caso a planilha e o grfico de
barras. Todos os observadores so notificados sempre que ocorre uma mudana no
estado do sujeito. Em resposta, cada observador ir consultar o sujeito para sincronizar
seu estado com o estado do sujeito.
Aplicabilidade: O padro Procurador aplicvel em qualquer uma das
seguintes situaes:
Quando uma abstrao possui dois aspectos, um dependente do outro.
Encapsular esses aspectos em objetos separados permite vari-los e
reutiliz-los independentemente.
Quando uma alterao em um objeto requer alteraes em outros e no se
sabe quantos objetos precisam ser alterados.
Quando um objeto deveria ser capaz de notificar outros objetos sem fazer
nenhuma suposio sobre como so esses objetos, ou seja, no se quer
esses objetos fortemente acoplados.

128
Estrutura:
S ujeito
1
0 ..* Ob servador
adic ionarObs ervador()

rem overObs ervador()
notific ar()
not ifi c ar()

{
p ara c ada observador
observador.a tualiz ar
}
atualiz ar()
S ujeitoConcreto
ObservadorConcreto
es tad o
estado
atribu ir Es tado() 1
obterE s tad o()
0..*
atualiz ar()
atualizar()
{
es tado = s ujeitoConcreto.obterE s tado
}
Participantes:
Sujeito: conhece seus observadores e prov uma interface para adicionar e
remover objetos observadores. Qualquer nmero de observadores pode
observar um sujeito.
Observador: define uma interface de atualizao para os objetos que
devem ser notificados das mudanas no sujeito.
SujeitoConcreto: armazena o estado de interesse para os observadores
concretos e envia notificaes para eles quando o seu estado alterado.
ObservadorConcreto: mantm uma referncia para um objeto
SujeitoConcreto, armazena o estado que deve ficar consistente com o
estado do sujeito e implementa a interface de atualizao do Observador,
de modo a manter seu estado consistente com o do sujeito.
Colaboraes: O sujeito concreto notifica seus observadores sempre que
ocorre uma alterao que pode tornar o estado de seus observadores
inconsistente com o seu estado. Aps ser informado de uma mudana no
sujeito concreto, um objeto ObservadorConcreto pode consultar o sujeito,
usando esta informao para reconciliar seu estado com o estado do sujeito.

: Cli ente
s ujeitoConc reto :
S ujeitoConc reto
129
ob servador1 :
ObservadorConc reto
...
obs ervadorN :
ObservadorConc reto
atribuirE s tado( )
notificar( )
atualizar( )
obterE s tado( )
...
atu aliz ar( )
obt erEs tado( )
Consequncias: O padro Observador permite variar sujeitos e observadores

independentemente. Deste modo possvel reutilizar sujeitos sem reutilizar
observadores e vice-versa. Isso permite adicionar observadores sem modificar
o sujeito ou outros observadores. Outros benefcios e obrigaes desse padro
incluem:
Acoplamento abstrato entre Sujeito e Observador: Tudo que um sujeito
sabe que ele possui uma lista de observadores, todos em conformidade
com a interface simples da classe abstrata Observador. O sujeito no
conhece a classe concreta de nenhum observador. Assim, o acoplamento
entre sujeitos e observadores abstrato e mnimo.
Suporte para comunicao broadcast: Ao contrrio de uma notificao
individual, a notificao que um sujeito envia no precisa especificar seus
receptores. A notificao enviada automaticamente para todos os objetos
interessados. Assim, a responsabilidade de um sujeito limitada apenas
notificao de seus observadores. Isso oferece liberdade de adicionar e
remover observadores a qualquer momento.
Atualizaes inesperadas: Uma vez que os observadores no tm
conhecimento da presena uns dos outros, eles podem no ser conscientes
do custo de uma alterao no sujeito. Assim, uma operao aparentemente
incua sobre o sujeito pode provocar uma atualizao em cascata para seus
observadores e objetos dependentes. Alm disso, critrios de dependncia

130
no bem definidos geralmente levam a atualizaes falsas que podem ser

difceis de propagar.
Referncias
2, Elsevier, 2006.

Notas Aula Projeto Sistemas 5

Enviado por

Dados do documento

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

Notas Aula Projeto Sistemas 5

Enviado por

Direitos autorais:

Formatos disponíveis

UFES - Universidade Federal do Esprito Santo

Ricardo de Almeida Falbo

1.1 A Fase de Projeto

Captulo 2 O Projeto de Software

2.1 Princpios de Projeto

Captulo 7 Projeto de Classes e Avaliao da Qualidade do Projeto de Software 110

Projeto de Sistemas de Software: Notas de Aula

Projeto de Sistemas de Software: Notas de Aula

UFES - Universidade Federal do Esprito Santo

concentrar no detalhamento de cada um desses elementos, at atingir o nvel de

1.1 A Fase de Projeto

Projeto de Sistemas de Software: Notas de Aula

UFES - Universidade Federal do Esprito Santo

Figura 1.1 A Fase de Projeto

Projeto da Arquitetura do Software: visa definir os elementos estruturais do

Projeto dos Elementos da Arquitetura: visa projetar em um maior nvel de

Projeto Detalhado: tem por objetivo refinar e detalhar os elementos mais

Tendo em vista que a orientao a objetos um dos paradigmas mais utilizados

Projeto de Sistemas de Software: Notas de Aula

UFES - Universidade Federal do Esprito Santo

Lgica de Negcio: o elemento da arquitetura que trata da lgica de

Interface com o Usurio: o elemento da arquitetura que trata da interao

Persistncia: o elemento da arquitetura responsvel pelo armazenamento e

Esses elementos so os principais elementos discutidos neste texto.

1.2 A Organizao deste Texto

Captulo 2 O Projeto de Software: discute princpios gerais de projeto e

Captulo 3 Arquitetura de Software: define o que arquitetura de software,

Captulo 4 Projeto da Lgica de Negcio: concerne ao projeto dos

Captulo 5 Projeto da Interface com o Usurio: aborda o projeto da

Projeto de Sistemas de Software: Notas de Aula

UFES - Universidade Federal do Esprito Santo

controle da interao com o usurio, envolvendo aspectos relacionados

Captulo 6 Projeto da Persistncia: trata do armazenamento e recuperao

Captulo 7 Projeto de Classes e Avaliao da Qualidade do Projeto de

Anexo A Padres de Projeto: apresenta alguns padres de projeto (design

Projeto de Sistemas de Software: Notas de Aula

Captulo 2 O Projeto de Software

Captulo 2 O Projeto de Software

2.1 Princpios de Projeto

Projeto de Sistemas de Software: Notas de Aula

Captulo 2 O Projeto de Software

UFES - Universidade Federal do Esprito Santo

Assim, de maneira geral, um projeto deve:

considerar abordagens alternativas com base nos requisitos do problema,

ser rastrevel sua especificao;

no reinventar a roda, isto , reutilizar solues;

exibir uniformidade (estilo) e integrao (interfaces bem definidas entre

ser estruturado para acomodar mudanas;

ser passvel de avaliao da qualidade;

ser revisado para minimizar erros.

Alm disso, em geral, um modelo de projeto deve:

prover uma viso da totalidade da coisa a ser construda;

decompor o todo em partes e prover diferentes vises da coisa;

No exemplo do projeto de uma casa, plantas baixas e maquetes (ou desenhos em

considerar abordagens alternativas com base nos requisitos (funcionais e no

estar relacionado aos modelos de anlise e especificao de requisitos e

no reinventar a roda, isto , reutilizar componentes, frameworks, padres

exibir uniformidade (estilo) e integrao (interfaces entre componentes);

ser estruturado para acomodar mudanas (alterabilidade);

ser passvel de avaliao da qualidade;

ser revisado para minimizar erros.

Projeto de Sistemas de Software: Notas de Aula

Captulo 2 O Projeto de Software

Alm disso, o projeto de software deve: