ANALISE

PROJETO
Selecionar Projeto
Desenvolver Diagramas de Fluxo de Dados Fsicos
I Desenvolver Diagramas de Relacionamentos de Entidades
Fsicas
I Projetar Arquitetura
I Selecionar Hardware e Software
I Desenvolver Cenrios de Uso
1 Projetar Estrutura de Interface
] Projetar Padres de Interface
] Projetar Prottipo de Interface
] Avaliar Interface de Usurio
1 Projetar Interface de Usurio
] Selecionar Formato de Armazenamento de Dados
] Desnormalizar Diagrama de Relacionamento de Entidades
] Otimizar Armazenamento de Dados
3 Dimensionar Armazenamento de Dados
] Desenvolver Diagrama de Estrutura de Programa
] Desenvolver Especificao de Programa

ANALISE PROJETO
PLANEJAMENTO
 CAPITULO 9

PROJETO DE
ARQUITETURA

U m componente importante da fase de projeto o projeto de arquitetura, que descreve hardware,

software e ambiente de rede do sistema. O projeto de arquitetura resultado principalmente
dos requisitos no-funcionais, como requisitos operacionais, de desempenho, de segurana, polti-
cos e culturais. O documento final do projeto de arquitetura inclui o projeto de arquitetura e a espe-
cificao de hardware e software.

OBJETIVOS

Compreender os componentes fundamentais de um sistema de informaes.

Compreender as arquiteturas baseadas em servidor, baseadas em cliente e baseadas em
cliente-servidor.
Compreender como os requisitos operacionais, de desempenho, de segurana, culturais e
polticos afetam o projeto de arquitetura.
Familiarizar-se com a criao de um projeto de arquitetura.
Familiarizar-se com a criao de uma especificao de hardware e software.

ESTRUTURA DO CAPITULO

Introduo Requisitos de Desempenho

Elementos de um Projeto de Arquitetura
Componentes Arquitetnicos
Arquiteturas Baseadas em Servidor
Arquiteturas Baseadas em Cliente
Arquiteturas Cliente-Servidor
Camadas Cliente-Servidor
Criando um Projeto de Arquitetura
Requisitos Operacionais
Requisitos de Segurana
Requisitos Culturais e Polticos
Projetando a Arquitetura
Especificao de Hardware e Software
Aplicao dos Conceitos CD Selections
Criando um Projeto de Arquitetura
Especificao de Hardware e Software
Resumo

IMPLEMENTAO
INTRODUO
No ambiente atual, a maioria dos sistemas de informaes disseminada por meio de dois ou mais
computadores. Um sistema baseado na Web, por exemplo, ser executado no navegador em seu
computador pessoal, mas interagir com o servidor Web (e possivelmente com outros computa-
dores) por meio da Internet. Um sistema que opere inteiramente dentro da rede de uma empresa
pode ter um programa em Visual Basic instalado em seu computador, mas interagir com um ser-
vidor de banco de dados em algum lugar na rede. Portanto, uma etapa importante da fase de pro-
jeto a criao do projeto de arquitetura, o esquema de como o sistema ser distribudo pelos
computadores e quais hardwares e softwares sero usados para cada computador (p. ex., Win-
dows, Linux).
A maioria dos sistemas construda para usar os hardwares e softwares existentes na empresa;
assim, freqentemente a arquitetura atual e a infra-estrutura de hardware e software restringem a
opo. Outros fatores, como padres empresariais, acordos de licenciamento de uso local existen-
tes e relaes produto-fornecedor, tambm podem decretar qual arquitetura, hardware e software
a equipe de projeto deve desenvolver. Entretanto, muitas empresas hoje em dia dispem de mui-
tas infra-estruturas ou esto procurando abertamente projetos-piloto para testarem novas arquite-
turas, hardwares e softwares, permitindo que uma equipe de projeto selecione uma arquitetura
baseada em outros fatores importantes.
Projetar uma arquitetura pode ser muito difcil e, portanto, muitas empresas contratam consul-
tores especializados ou atribuem a tarefa a analistas muito experientes.1 Neste captulo, examina-
remos os fatores mais importantes no projeto de arquitetura, mas importante lembrar que pre-
ciso alguma experincia para fazer isso bem. Os requisitos no-funcionais desenvolvidos anteri-
ormente na fase de anlise (veja o Captulo 4) desempenham um papel importante no projeto de
arquitetura. Esses requisitos so reexaminados e refinados em requisitos mais detalhados que in-
fluenciam a arquitetura do sistema. Neste captulo, explicaremos primeiro com que finalidade os
projetistas analisam as arquiteturas de aplicaes e descreveremos as trs arquiteturas principais:
arquitetura baseada em servidor, arquitetura baseada em cliente e arquitetura cliente-servidor.
Depois, examinaremos como os requisitos no-funcionais definidos de forma mais generalizada
na fase de anlise so refinados em requisitos mais especficos, e as implicaes deles sobre o
projeto de arquitetura. Finalmente, apreciaremos como os requisitos e a arquitetura podem ser
usados para desenvolver as especificaes de hardware e software que definem exatamente quais
outros hardwares e softwares (p. ex., sistemas de banco de dados) so necessrios para dar suporte
ao sistema de informaes em desenvolvimento.

ELEMENTOS DE UM PROJETO DE ARQUITETURA

O objetivo de um projeto de arquitetura determinar quais partes da aplicao sero atribudas a

quais hardwares. Nesta seo, discutiremos primeiro os componentes arquitetnicos principais
do software para compreendermos como esse conjunto pode ser dividido em partes diferentes.
Depois, discutiremos rapidamente os tipos mais importantes de hardwares sobre o qual o software
pode ser executado. Embora haja inmeras formas de os componentes de software serem execu-
tados nos componentes de hardware, h trs arquiteturas de aplicao principais em uso hoje em
dia: arquiteturas baseadas em servidor, arquiteturas baseadas em cliente e arquiteturas cliente-
servidor. A arquitetura mais comum a cliente-servidor, assim nos concentraremos nela.

Componentes Arquitetnicos
Os componentes arquitetnicos mais importantes de qualquer sistema so os softwares e os
hardwares. Os componentes de software mais importantes do sistema em desenvolvimento tm
de ser identificados e, em seguida, alocados para os vrios componentes de hardware em que o

'Para obter mais informaes sobre projeto de arquitetura, consulte o Zachman Institute em www.zifa.com.
 Projeto de Arquitetura 237

sistema operar. Cada um desses componentes pode ser combinado de diversas maneiras dife-
rentes.
Todos os sistemas de software podem ser divididos em quatro funes bsicas. A primeira a
armazenagem de dados. A maioria dos sistemas de informaes requer que os dados sejam arma-
zenados e recuperados, seja em um pequeno arquivo, como um campo memo produzido por um
processador de texto, seja em um grande banco de dados, como um que armazene registros cont-
beis de uma empresa. Essas so as entidades de dados documentadas nos diagramas de relaciona-
mentos de entidades (ERDs). A segunda funo a lgica de acesso aos dados, o processamento
exigido para acessar os dados, que freqentemente significa consultas a banco de dados em
Structured Query Language (SQL). A terceira funo a lgica de aplicao, que a lgica do-
cumentada nos diagramas de fluxo de dados (DFDs), casos de uso e requisitos funcionais. A quar-
ta funo a lgica de apresentao, a exibio das informaes para o usurio e a aceitao dos
comandos do usurio (a interface com o usurio). Essas quatro funes (armazenagem de dados,
lgica de acesso aos dados, lgica de aplicao e lgica de apresentao) so os blocos bsicos de
construo de qualquer sistema de informaes.
Os trs componentes principais de hardware de um sistema so os computadores cliente, os
servidores e a rede que os conecta. Os computadores cliente so os dispositivos de entrada/sada
empregados pelos usurios, e normalmente so computadores de mesa ou laptops, mas tambm
podem ser dispositivos manuais, telefones celulares, terminais com finalidades especiais, e assim
por diante. Os servidores normalmente so computadores grandes, usados para abrigar softwares
e hardwares que podem ser acessados por algum que tenha permisso. Os servidores podem se
apresentar em diversos tamanhos: mainframes (muito grandes, computadores poderosos custan-
do geralmente milhes de dlares), minicomputadores (computadores grandes custando centenas
de milhares de dlares) e microcomputadores (computadores pequenos de mesa, como os que voc
usa, podendo custar $50 mil ou mais). A rede que conecta os computadores pode variar em velo-
cidade de uma conexo lenta, via telefone celular ou modem que deve ser discado, a redes frame
relay sempre ativas de velocidade mdia, a conexes rpidas de banda larga, como circuitos de
modem via cabo, DSL ou TI sempre ativos, e ainda a circuitos Ethernet, T3 ou ATM, sempre
ativos de alta velocidade.2

Arquiteturas Baseadas em Servidor

As arquiteturas de computao pioneiras foram as baseadas em servidor, com o servidor (normal-
mente um computador mainframe central) executando as quatro funes da aplicao. Os clientes
(normalmente terminais) permitiam que os usurios trocassem mensagens com o computador
servidor. Os clientes simplesmente capturavam o que era digitado e enviavam ao servidor para ser
processado, aceitando instrues do servidor sobre o que exibir (Figura 9-1).

Hospedeiro do Servidor
(computador mainframe)
Cliente/(terminal)

?s9t

Lgica de apresentao
Lgica de aplicao
FIGURA 9-1 Lgica de acesso aos dados
Arquitetura Baseada em Servidor Armazenamento de dados

2
Para obter mais informaes sobre redes, consulte Networking in the Internet Age, de Alan Dennis, John Wiley & Sons,
2002.
238 Captulo Nove

Essa arquitetura simples geralmente funciona muito bem. A aplicao desenvolvida e arma-
zenada em um computador, e todos os dados esto no mesmo computador. H um ponto de con-
trole pelo qual todas as mensagens trafegam por um servidor central. O problema fundamental
com as redes baseadas em servidor que este deve processar todas as mensagens. Como as de-
mandas por mais e mais aplicaes crescem, muitos computadores servidores ficam sobrecarre-
gados e incapazes de processar rapidamente todas as demandas dos usurios. O tempo de resposta
se torna mais lento, e os gerentes de redes so forados a gastar cada vez mais dinheiro para atu-
alizar o computador servidor. Infelizmente, as atualizaes incluem muitos adicionais e so caras
(em torno de $500 mil); difcil atualizar "um pouco".

Arquiteturas Baseadas em Cliente

Com as arquiteturas baseadas em cliente, os clientes so microcomputadores em uma rede da rea
local e o computador servidor um servidor na mesma rede. A aplicao nos computadores cliente
responsvel pela lgica de apresentao, pela lgica de aplicao e pela lgica de acesso aos dados; o
servidor simplesmente armazena os dados (Figura 9-2). Em sistemas muito simples, de apenas um
usurio, os dados podem permanecer no prprio computador cliente, e nenhum servidor usado.
Essa arquitetura simples freqentemente funciona muito bem. Entretanto, conforme as deman-
das por mais e mais aplicaes crescem, os circuitos de rede podem ficar sobrecarregados. O proble-
ma fundamental nas redes baseadas em clientes que todos os dados no servidor devem trafegar
para o cliente para serem processados. Por exemplo, suponha que o usurio deseje exibir uma lista
de todos os empregados com seguro de vida da empresa. Todos os dados no banco de dados devem
trafegar a partir do servidor, em que o banco de dados est armazenado, pela rede at o cliente, que,
em seguida, examina cada registro para ver se h correspondncia com os dados solicitados pelo
usurio. Isso pode sobrecarregar tanto a rede quanto a capacidade dos computadores cliente.

Arquiteturas Cliente-Servidor
A maioria das empresas, hoje em dia, est mudando para as arquiteturas cliente-servidor, que
tenta equilibrar o processamento entre o cliente e o servidor. Nessas arquiteturas, o cliente res-

Cliente Servidor
(microcomputador) (microcomputador)

Lgica de apresentao Armazenamento de dados

FIGURA 9 - 2 Lgica de aplicao
Arquitetura Baseada em Cliente Lgica de acesso aos dados

Cliente
(microcomputador)

FIGURA 9-3
Arquitetura Cliente-Servidor. Fonte:
Business Data Communications and
Networking, de Jerry Fitzgerald e Alan
Dennis, 65 ed, p. 75. Copyright 1 9 9 9
por John Wiley & Sons, Inc. Usado com Lgica de apresentao Lgica de armazenagem dos dados
permisso. Lgica de aplicao Armazenamento de dados
 Projeto de Arquitetura 239

ponsvel pela lgica de apresentao, enquanto o servidor responsvel pela lgica de acesso aos
dados e pela armazenagem de dados. A lgica da aplicao pode residir no cliente, no servidor ou
ser dividida entre ambos (Figura 9-3). Quando o cliente tem a maior parte ou toda a lgica de
apresentao (como na Figura 9-3) denominado cliente gordo. Se o cliente contm apenas a funo
da apresentao e a maior parte da funo da aplicao reside no servidor, ele denominado cli-
ente magro. Por exemplo, muitos sistemas baseados na Web so projetados com o navegador Web
executando a lgica de apresentao e somente o mnimo da lgica de aplicao usando lingua-
gens de programao como Java, enquanto o servidor Web mantm a lgica de aplicao, a lgica
de acesso aos dados e a armazenagem de dados.
As arquiteturas cliente-servidor apresentam quatro benefcios importantes. Primeiro, elas so
redimensionveis. Isso significa que fcil aumentar ou diminuir as capacidades de armazena-
gem e processamento dos servidores. Se um servidor fica sobrecarregado, voc simplesmente
adiciona outro servidor a fim de que muitos servidores sejam usados para executar a lgica de
aplicao, a lgica de acesso aos dados ou a armazenagem de dados. O custo para atualizar mais
gradual, e voc pode fazer isso em etapas menores (em torno de $5 mil), em vez de gastar cente-
nas de milhares de dlares para atualizar um servidor mainframe.
Segundo, as arquiteturas cliente-servidor podem dar suporte a muitos tipos diferentes de clien-
tes e servidores. possvel conectar computadores que usem sistemas operacionais diferentes para
que os usurios possam escolher qual tipo de computador preferem (p. ex., combinar computado-
res Windows e Apple Macintosh na mesma rede). Voc no fica restrito a um fornecedor, como
freqente nos casos de redes baseadas em servidor. O middleware um tipo de software projetado
para fazer a converso de informaes entre softwares de fornecedores diferentes. O middleware
instalado nos computadores cliente e servidor. O software do cliente se comunica com o
middleware, que pode reformatar a mensagem em uma linguagem-padro possvel de ser com-
preendida pelo middleware que auxilia o software do servidor.
Terceiro, para as arquiteturas cliente magro-servidor que usam padres da Internet simples
separar claramente a lgica de apresentao, a lgica de aplicao e a lgica de acesso aos dados
e projetar cada uma para ser um pouco independente. Por exemplo, a lgica da apresentao pode
ser projetada em HTML ou XML para especificar como a pgina aparecer na tela (p. ex., cores,
fontes, ordem dos itens, palavras especficas usadas, botes de comando, tipo de listas de seleo,
e assim por diante; veja o Captulo 10). Declaraes simples de programa so usadas para vincu-
lar partes da interface a mdulos especficos da lgica de aplicao que executam vrias funes.
Esses arquivos HTML ou XML que definem a interface podem ser alterados sem afetar a lgica
da aplicao. Da mesma maneira, possvel alterar a lgica de aplicao sem alterar a lgica de
apresentao ou os dados, que esto armazenados em bancos de dados acessados por meio de
comandos SQL.
Finalmente, como no existe apenas um computador servidor processando todos os programas,
a rede geralmente mais confivel. No h nenhum ponto central de falha que interromper o
funcionamento de toda a rede se ele falhar, como existe nas arquiteturas baseadas em servidor. Se
qualquer servidor falhar em um ambiente cliente-servidor, a rede pode continuar a funcionar usando
todos os demais servidores.
As arquiteturas cliente-servidor tambm apresentam algumas limitaes crticas, sendo a mais
importante a sua complexidade. Todas as aplicaes no processamento cliente-servidor tm duas
partes, o software no cliente e o software no servidor. Escrever esse software mais complicado
que escrever o software tradicional exclusivo usado nas arquiteturas baseadas em servidor. Atua-
lizar a rede com uma nova verso do software ainda mais complicado. Nas arquiteturas basea-
das em servidor h um local onde o software armazenado; para atualiz-lo, voc simplesmente
o substitui em seu local de armazenagem. Com as arquiteturas cliente-servidor voc deve fazer a
atualizao em todos os clientes e servidores.
Muitos debates sobre arquiteturas baseadas em servidor versus cliente-servidor visam o custo.
Um dos grandes argumentos das redes baseadas em servidor na dcada de 1980 era que proporci-
onavam economia. Os fabricantes de grandes mainframes argumentavam que era mais barato
manter servios em um grande mainframe que em uma srie de computadores menores. A revolu-
o do microcomputador mudou isso. Desde a dcada de 1980 o custo de microcomputadores tem
cado continuamente, enquanto o desempenho tem crescido significativamente. Hoje, o hardware
do microcomputador mais de 1.000 vezes mais barato que o hardware do mainframe para a mes-
ma capacidade instalada de processamento.
240 Captulo Nove

FIGURA 9-4 Servidor de banco de dados

Arquitetura Cliente-Servidor de Trs Cliente Servidor de aplicao (microcomputador,
(microcomputador) (microcomputador) minicomputador ou mainframe)
Camadas. Fonte: Business Doto
Communications and Networking, de
Jerry Fitzgerald e Alan Dennis, 6g ed, p.
75. Copyright 1 9 9 9 por John Wiley &
Sons, Inc. Usado com permisso.

Lgica de apresentao Lgica de aplicao Lgica de acesso aos dados

Armazenamento de dados

Camadas Cliente-Servidor
H muitas maneiras de dividir a lgica da aplicao entre o cliente e o servidor. A Figura 9-3 mostra
uma das mais comuns. Nesse caso, o servidor responsvel pelos dados e o cliente responsvel
pela apresentao e pela aplicao. Isso denominado arquitetura de duas camadas, porque usa
apenas dois conjuntos de computadores, clientes e servidores.
Uma arquitetura de trs camadas usa trs conjuntos de computadores, como mostrado na Fi-
gura 9-4. Nesse caso, o software no computador cliente responsvel pela lgica da apresenta-
o, um (ou mais) servidor de aplicao responsvel pela lgica da aplicao e um (ou mais)
servidor de banco de dados separado responsvel pela lgica de acesso aos dados e pela armaze-
nagem de dados.
Uma arquitetura de n camadas usa mais de trs conjuntos de computadores. Nesse caso, o cli-
ente responsvel pela apresentao, um (ou mais) servidor de banco de dados responsvel pela
lgica de acesso aos dados e pela armazenagem de dados, e a lgica da aplicao distribuda por
dois ou mais conjuntos de servidores diferentes. A Figura 9-5 mostra um exemplo de uma arqui-
tetura de n camadas de um software denominado Consensus @nyWARE.3 O Consensus
@nyWARE tem quatro componentes principais. O primeiro o navegador Web no computador
cliente, empregado por um usurio para acessar o sistema e efetuar comandos (lgica da apresen-
tao). O segundo componente um servidor Web que responde s solicitaes do usurio forne-
cendo pginas e elementos grficos em HTML (lgica da aplicao) ou enviando a solicitao ao
terceiro componente (um conjunto de 28 programas escritos na linguagem de programao C) em
outro servidor de aplicao que executa diversas funes (lgica da aplicao). O quarto compo-
nente um servidor de banco de dados que armazena todos os dados (lgica de acesso aos dados
e armazenagem de dados). Cada um desses quatro componentes est separado, facilitando a dis-
tribuio dos componentes diferentes em servidores diferentes e a diviso da lgica da aplicao
em dois servidores diferentes.
A vantagem principal de uma arquitetura cliente-servidor de n camadas, comparada a uma ar-
quitetura de duas camadas (ou uma de trs camadas comparada a uma de duas camadas), que ela
divide inteiramente o processamento que ocorre para equilibrar melhor a carga nos servidores di-
ferentes; ela mais redimensionvel. Na Figura 9-5 temos trs servidores separados, uma confi-
gurao que oferece mais capacidade do que se tivssemos usado uma arquitetura de duas cama-
das com apenas um servidor. Se descobrirmos que o servidor de aplicao est muito sobrecarre-
gado, podemos simplesmente substitu-lo por um servidor mais eficiente ou apenas instalar mais
alguns servidores de aplicao. Inversamente, se descobrirmos que o servidor de banco de dados
est sendo subutilizado podemos armazenar dados de outra aplicao nele.
H duas desvantagens importantes em uma arquitetura de n camadas comparada a uma ar-
quitetura de duas camadas (ou uma de trs camadas comparada a uma de duas camadas). Pri-
meira, a configurao impe uma carga maior sobre a rede. Se voc comparar as Figuras 9-3,
9-4 e 9-5 ver que o modelo de n camadas requer mais comunicao entre os servidores; isso
gera mais trfego na rede, assim preciso usar uma rede de capacidade mais alta. Segunda,
muito mais difcil programar e testar softwares em arquiteturas de n camadas do que em arqui-

3
0 Consensus @nyWARE foi desenvolvido originariamente por Alan Dennis durante sua permanncia na Universidade
da Gergia. Pode ser consultado na Web em www.softbicycle.com.
 Projeto de Arquitetura 241

FIGURA 9 - 5 Cliente Servidor Web

Arquitetura Cliente-Servidor de Quatro (microcomputador) (microcomputador)
Camadas. Fonte: Business Data
Communicotions and Networking, de
Jerry Fitzgerald e Alan Dennis, 6 ed, p.
76. Copyright 1 9 9 9 por John Wiley &
Sons, Inc. Usado com permisso.

Lgica de apresentao

Servidor de banco de dados

(microcomputador,
minicomputador ou mainframe)

Lgica de aplicao Lgica de acesso aos dados

Armazenamento de dados

teturas de duas camadas, porque muitos dispositivos tm de se comunicar para concluir a tran-
sao de um usurio.

CRIANDO UM PROJETO DE ARQUITETURA

O projeto de arquitetura especifica a arquitetura como um todo e a disposio de softwares e
hardwares que sero usados. O projeto de arquitetura um processo muito complexo, que fre-

CONCEITOS 9-A UMA IMENSA ARQUITETURA CLIENTE-SERVIDOR

EM AO
Toda primavera, a Monster.com, um dos maiores sites de
empregos dos Estados Unidos, com uma mdia de mais de trs
milhes de visitas por ms, experimenta um grande aumento no
trfego. Aaron Braham, vice-presidente de operaes, atribui o
aumento de demanda a estudantes de faculdades que incremen-
tam suas atividades de busca por trabalho conforme se aproxi-
mam da graduao.
A Monster.com usa uma arquitetura cliente-servidor de trs
camadas que possui 150 servidores W e b e 30 servidores de
banco de dados em seu site principal, em Indianpolis, e plane-
ja passar para 4 0 0 durante o prximo ano por meio do cresci-
mento gradual do site principal e adicionando um novo site com
servidores em Maynard, Massachusetts, ainda em tempo de apro-
veitar o grande movimento da primavera. O W e b site principal
tem um conjunto de dispositivos de equilbrio de carga que en-
caminham as solicitaes da W e b aos diferentes servidores, de-
pendendo do grau de congestionamento deles.
Braham diz que o principal desafio que 9 0 % do trfego
no provm de simples solicitaes de pginas W e b , mas pre-
cisamente de solicitaes de pesquisas (p. ex., quais empre-
gos na rede esto disponveis no Novo Mxico) que requerem
mais processamento e acesso aos servidores de banco de da-
dos. A Monster.com possui mais de 3 5 0 . 0 0 0 postagens de
empregos e mais de trs milhes de currculos em arquivo, es-
palhados pelos seus servidores de banco de dados. Diversas
cpias de cada postagem e dos currculos so mantidas em
diversos bancos de dados para melhorar a velocidade de aces-
so e fornecer redundncia no caso de um servidor parar de
funcionar, e assim s o fato de manter os servidores de banco
de dados em sincronia, para que contenham dados corretos,
j um desafio.
Fonte: "Resume Influx Tests Mettle of Job Sites Scalability",
Internetweek, May 20, 2000, de Christine Zimmerman.
PERGUNTAS:
1. Quais os dois ou trs principais requisitos no-funconais que
tm influenciado a arquitetura de aplicao da Monster.com?
2. Quais alternativas voc acha que a Monster.com levou em
conta?
242 Captulo Nove

qentemente fica a cargo de projetistas e consultores experientes, mas ciaremos uma idia do pro-
jeto aqui.
Cada uma das arquiteturas de computao discutidas anteriormente tem suas vantagens e des-
vantagens. A maioria das empresas est tentando mudar para arquiteturas cliente-servidor por razes
de custo; assim, no caso de no haver nenhuma razo convincente para escolher uma outra arqui-
tetura, o custo normalmente sugere a arquitetura cliente-servidor.
A criao de um projeto de arquitetura comea com os requisitos no-funcionais. A primeira
etapa refinar os requisitos no-funcionais em requisitos mais detalhados que so, ento, usados
para ajudar a selecionar a arquitetura a ser usada (baseada em servidor, baseada em cliente ou cli-
ente-servidor) e quais componentes de software sero colocados em cada mquina. Em uma ar-
quitetura cliente-servidor algum tambm tem de decidir se ser usada uma arquitetura de duas
camadas, de trs camadas ou de n camadas. Depois, os requisitos no-funcionais e o projeto de
arquitetura sero usados para desenvolver a especificao de hardware e software.
H quatro tipos principais de requisitos no-funcionais que podem ser importantes ao se proje-
tar a arquitetura: requisitos operacionais, de desempenho, de segurana e culturais/polticos. Des-
creveremos cada um e, em seguida, explicaremos como eles podem afetar o projeto de arquitetura.

Requisitos Operacionais
Os requisitos operacionais especificam o ambiente (ou ambientes) operacional em que o sistema
deve ser executado e como ele pode mudar ao longo do tempo. Isso normalmente se refere a sis-
temas operacionais, softwares e sistemas de informaes com os quais o sistema deve interagir, mas
ocasionalmente tambm incluir o ambiente fsico, se ele for importante para a aplicao (p. ex., um
ambiente barulhento de fbrica, no qual nenhum alerta audvel pode ser ouvido). A Figura 9-6 resu-
me as quatro reas principais do requisito operacional e fornece alguns exemplos de cada um.

Requisitos do Ambiente Tcnico Os requisitos do ambiente tcnico especificam os tipos de hardwares

e softwares em que o sistema funcionar. Esses requisitos normalmente enfocam o software do

,, Tipo de Requisito Definio Exemplos

Requisitos do Requisitos de hardwares, softwares e O sistema operar no ambiente W e b

Ambiente Tcnico redes especiais impostos por requisitos com o Internet Explorer.
empresariais Todos os locais do escritrio tero uma
conexo de rede sempre ativa para
permitir atualizaes de bancos de
dados em tempo real.
Uma verso do sistema ser fornecida
para clientes que se conectam Internet
por meio de um PDA de tela pequena.

Requisitos de Integrao A capacidade que o sistema ter para O sistema deve ser capaz de importar
de Sistemas operar com outros sistemas e exportar planilhas do Excel.
O sistema far a leitura e a gravao
para o banco de dados de estoque
principal no sistema de estoque.
Requisitos de A capacidade que o sistema ter para O sistema deve ser capaz de trabalhar
Portabilidade operar em outros ambientes em verses futuras do Internet Explorer.
O sistema pode precisar operar com
dispositivos manuais, como um Palm.
Requisitos de Alteraes operacionais esperadas O sistema deve ser capaz de assimilar
Atualizao s quais o sistema deve ser capaz mais uma fbrica com aviso prvio de
de se adaptar seis meses.
Novas verses do sistema sero
lanadas a cada seis meses.

FIGURA 9-6
Requisitos Operacionais
 Projeto de Arquitetura 243

sistema operacional (p. ex., Windows, Linux), o software do sistema de banco de dados (p. ex.,
Oracle) e outros softwares do sistema (p. ex., Internet Explorer). Ocasionalmente, pode haver re-
quisitos de hardwares especficos que imponham importantes limitaes ao sistema, como a ne-
cessidade de operar em um PDA ou telefone celular com um visor muito pequeno.

Requisitos de Integrao de Sistemas Os requisitos de integrao de sistemas so aqueles que exigem

que o sistema opere com outros sistemas de informaes, dentro ou fora da empresa. Normalmente
esses requisitos especificam as interfaces pelas quais os dados sero trocados com os outros sistemas.

Requisitos de Portabilidade Os sistemas de informaes nunca permanecem inalterados. As necessi-

dades das empresas e as tecnologias operacionais mudam, assim os sistemas de informaes que do
suporte e so desenvolvidos com base nelas tambm devem poder se adaptar a essas mudanas. Os
requisitos de portabilidade definem como os ambientes operacionais tcnicos podem evoluir ao lon-
go do tempo e como o sistema deve responder (p. ex., o sistema deve ser executado em todas as ver-
ses atuais e futuras do Windows). Os requisitos de portabilidade tambm se referem a possveis mo-
dificaes nos requisitos empresariais que determinaro modificaes do ambiente tcnico. Por exem-
plo, no futuro os usurios podem desejar acessar um Web site a partir de seus telefones celulares.

Requisitos de Atualizao Os requisitos de atualizao especificam as modificaes dos requisi-

tos empresariais que podem ser antecipadas. Nem todas as mudanas so previsveis, mas algu-
mas so. Por exemplo, suponha que uma pequena empresa tenha somente uma instalao predial,
mas esteja planejando a construo de uma segunda nos prximos cinco anos. Todos os sistemas
de informaes devem ser escritos para facilitar o controle de cada prdio separadamente, seja
para o sistema de pessoal, oramentrio ou de estoque. O requisito de atualizao tenta antecipar
os requisitos futuros para que os sistemas projetados hoje sejam mantidos com facilidade se e quando
esses futuros requisitos aparecerem. Os requisitos de atualizao tambm podem definir o ciclo
de atualizao do sistema, como a freqncia com que novas verses sero lanadas.

Requisitos de Desempenho
Os requisitos de desempenho enfocam as questes de desempenho, como tempo de resposta, ca-
pacidade e confiabilidade. A Figura 9-7 resume trs reas principais do requisito de desempenho
e oferece alguns exemplos.

Tipo de Requisito Definio Exemplos .

Requisitos d e V e l o c i d a d e
O tempo no qual o sistema tem de
executar suas funes
O tempo de resposta tem de ser menor que sete
segundos para qualquer transao pela rede.
O banco de dados do estoque tem de ser
atualizado em tempo real.
Os pedidos sero transmitidos para a fbrica a
cada 30 minutos.

Requisitos d e C a p a c i d a d e O nmero total e mximo de usurios Haver um mximo de 100-200 usurios

e o volume de dados esperado simultneos em momentos de pico de uso.
Uma transao tpica exigir a transmisso de
10K de dados.
O sistema armazenar dados sobre
aproximadamente 5 . 0 0 0 clientes para um total
de quase 2MB de dados.

Requisitos de A proporo de tempo que o sistema O sistema deve estar disponvel 24 X 7,

Disponibilidade e estar disponvel para os usurios com exceo da manuteno agendada.
Confiabilidade e o ndice tolervel de falhas devido A manuteno agendada no exceder um
aos erros perodo de seis horas a cada ms.
O sistema ter desempenho de 99% de tempo
de funcionamento.

FIGURA 9 - 7
Requisitos de Desempenho
Requisitos de Velocidade Os requisitos de velocidade so exatamente o que querem dizer: o grau
de velocidade que o sistema deve ter para operar. Primeiramente, o tempo de resposta do sistema:
quanto tempo o sistema leva para responder a uma solicitao do usurio. Embora todo mundo
prefira agilidade nos tempos de resposta, com o sistema respondendo imediatamente a cada soli-
citao do usurio, essa no a prtica. Poderamos projetar esse sistema, mas seria muito caro. A
maioria dos usurios compreende que certas partes de um sistema respondero rapidamente, en-
quanto outras sero mais lentas. Aquelas aes que so executadas localmente no computador do
usurio devem ser quase imediatas (p. ex., digitao, arrastar e soltar), enquanto outras que reque-
rem comunicao por uma rede podem ter tempos de resposta maiores (p. ex., uma solicitao
Web). Em geral, tempos de resposta menores que sete segundos so considerados aceitveis quando
se requer uma comunicao por uma rede.
O segundo aspecto dos requisitos de velocidade quanto tempo leva para as transaes em
uma parte do sistema serem refletidas em outras partes. Por exemplo, com que rapidez um item se
tornar indisponvel para venda a outra pessoa aps ter sido comprado por algum? Se o estoque
no for atualizado imediatamente, outra pessoa poder efetuar um pedido do mesmo item, desco-
brindo somente depois que ele est fora de estoque. Ou com que rapidez, aps um pedido ter sido
feito, ele enviado ao depsito para ser selecionado no estoque e despachado? Nesse caso, algum
atraso poderia ter pouco impacto.

Requisitos de Capacidade Os requisitos de capacidade tentam prever a quantos usurios o sistema

ter de dar suporte, tanto no total quanto simultaneamente. Os requisitos de capacidade so im-
portantes na compreenso do tamanho dos bancos de dados, da capacidade de processamento ne-
cessria, e assim por diante. O requisito mais importante normalmente o nmero mximo de
usurios simultneos, porque isso tem um impacto direto na capacidade de processamento do(s)
computador(es) necessria para dar suporte ao sistema.
Freqentemente mais fcil prever o nmero de usurios de sistemas internos projetados para
dar suporte aos prprios empregados de uma empresa do que prever o nmero de usurios de sis-
temas voltados para o cliente externo, especialmente aqueles baseados na Web. Como o site
weather.com estima o nmero mximo de usurios que buscar informaes sobre o tempo si-
multaneamente? Isso mais arte do que cincia; portanto, geralmente a equipe fornece um inter-
valo de estimativas, com intervalos mais amplos para indicar uma estimativa menos precisa.

Requisitos de Disponibilidade e Confiabilidade Os requisitos de disponibilidade e confiabilidade

enfocam at que ponto os usurios podem presumir que o sistema estar disponvel para o uso
deles. Embora alguns sistemas sejam planejados para ser usados apenas durante a semana de tra-
balho de 40 horas, alguns sistemas so projetados para ser usados por pessoas ao redor do mundo.
Para esses sistemas, os membros da equipe de projeto precisam considerar como a aplicao pode
ser operada, suportada e mantida 24 X 7 (especificamente, 24 horas por dia, sete dias por sema-
na). Esse requisito 24 X 7 significa que os usurios podem precisar de ajuda ou ter perguntas a
fazer a qualquer momento, e um suporte tcnico que esteja disponvel oito horas por dia no dar
suporte apropriadamente. Tambm importante considerar que a confiabilidade necessria no
sistema. Um sistema que requeira alta confiabilidade (p. ex., um dispositivo mdico ou tronco te-
lefnico) precisa de muito mais planejamento e testes que um sistema que no tenha essas neces-
sidades de alta confiabilidade (p. ex., um sistema pessoal, catlogos Web).
E mais difcil prever os altos e baixos na utilizao do sistema quando ele tem um pblico
mundial. Normalmente so feitos backups das aplicaes nos fins de semana ou tarde da noite,
quando os usurios no esto mais acessando o sistema. Essas atividades de manuteno tero de
ser repensadas se estiverem no nvel mundial. Em particular, o desenvolvimento de interface com
a Web tem aumentado a necessidade de dar suporte ao requisito 24 X 7 porque, por padro, a
Web pode ser acessada por qualquer pessoa a qualquer momento. Por exemplo, os desenvolvedo-
res de uma aplicao para a Web para uma cadeia americana de lojas de roupas ficaram surpresos
quando o primeiro pedido aps entrarem no ar chegou do Japo.

Requisitos de Segurana
A segurana a capacidade de proteger o sistema de informaes contra distrbios e perda de
dados, causados por uma ao intencional (um hacker ou um ataque terrorista) ou um aconteci-
 Projeto de Arquitetura 245

CONCEITOS 9-B A IMPORTNCIA DO PLANEJAMENTO DA CAPACIDADE

EM AO
No final de 1997, a Oxford Health Plans contabilizou uma para mais de $ 4 0 0 milhes, e os pagamentos devidos a cola-
perda de $ 1 20 milhes em seus livros. O inesperado crescimento boradores importavam em mais de $ 6 5 0 milhes. Erros no pla-
da empresa foi sua runa, porque o sistema, que estava planeja- nejamento da infra-estrutura podem custar muito mais que os
do originalmente para suportar os 21 7 . 0 0 0 membros da empre- hardwares, softwares e equipamentos de rede sozinhos.
sa, tinha de satisfazer as necessidades de um grupo que exce-
dia 1,5 milho. Fonte: "Management: How New Technology was Oxford's Nemesis",
Os usurios do sistema descobriram que processar a inscri- The Wall Street Journal, December 11,1997, p. A. 1, de Ron
Winslow e George Anders.
o de um novo membro levava 15 minutos, em vez dos seis
segundos propostos. Alm disso, os problemas relacionados aos
PERGUNTA:
computadores deixaram a Oxford impossibilitada de enviar fa-
Se voc fosse o encarregado do projeto da Oxford, quais fa-
turas a muitos de seus clientes, alm de impedi-la de localizar os
tos teria considerado ao planejar a capacidade do sistema?
pagamentos de centenas de mdicos e hospitais. Em menos de
um ano, os pagamentos no cobrados de clientes triplicaram

mento aleatrio (falha de disco, tempestades). A segurana essencialmente responsabilidade do

grupo de operaes o pessoal responsvel por instalar e operar controles de segurana, como
firewalls, sistemas de deteco de intruso e backups de rotina e operaes de recuperao. Entre-
tanto, os desenvolvedores de novos sistemas devem garantir que os requisitos de segurana do
sistema produzam precaues razoveis para evitar problemas; os desenvolvedores de sistema so
responsveis pela garantia de segurana dentro dos prprios sistemas de informaes.
A segurana um problema sempre crescente no mundo globalizado de hoje pela Internet. His-
toricamente, a maior ameaa segurana tem vindo do interior da prpria empresa. Desde o in-
cio da dcada de 1980, quando o FBI comeou pela primeira vez a manter estatsticas de crimes
de informtica e as firmas de segurana comearam a conduzir levantamentos sobre esses crimes,
os empregados de empresas tm sido responsveis pela grande maioria das ocorrncias. Durante
anos, 80% das invases, roubos e sabotagens tm sido cometidos por pessoas de dentro das em-
presas, deixando apenas 20% para os hackers externos s empresas.
Em 2001, isso mudou. Dependendo do levantamento que voc ler, o percentual de incidentes
atribudos a hackers externos em 2001 estar entre 50% e 70% de todos os incidentes, significan-
do que o maior risco que as empresas esto enfrentando agora vem de fora. Embora uma parte
dessa inverso possa ser devida melhor segurana interna e ao melhor entendimento com os em-
pregados para evitar problemas de segurana, grande parte se deve simplesmente a um aumento
de atividade por parte dos hackers externos.
O desenvolvimento de requisitos de segurana normalmente comea com alguma avaliao do
valor agregado ao sistema e de seus dados. Isso ajuda a localizar sistemas extremamente impor-
tantes para que o pessoal de operaes esteja ciente dos riscos. A segurana interna dos sistemas
normalmente se concentra em especificar quem pode acessar quais dados, identificar a necessida-
de de criptografia e autenticao e assegurar que as aplicaes evitem a propagao de vrus; veja
a Figura 9-8.

Valor Agregado ao Sistema Os equipamentos de informtica no so o patrimnio mais importan-

te de uma empresa: o que importa realmente so os dados dessa empresa. Por exemplo, suponha
que algum destrua um mainframe avaliado em $10 milhes. O mainframe poderia ser substitu-
do simplesmente comprando-se um novo equipamento. Seria caro, mas o problema estaria resol-
vido em algumas semanas. Agora, suponha que algum destrua todos os registros dos estudantes
de sua universidade para que ningum saiba nada sobre as disciplinas cursadas por algum ou suas
respectivas notas. O custo excederia em muito as despesas destinadas a substituir um computador
de $10 milhes. Somente as aes judiciais excederiam facilmente essa quantia, e o custo de pes-
soal para encontrar e digitar novamente os registros em papel seria enorme e, certamente, levaria
mais do que algumas semanas.
Em alguns casos, o prprio sistema de informaes tem um valor agregado que tambm exce-
de em muito o custo dos equipamentos. Por exemplo, para um banco que opere pela Internet e que
no possua nenhuma agncia fsica o Web site um sistema crtico de misso. Se ele ficar inope-
246 Captulo Nove

Tipo de Requisito Definio Exemplos

Estimativas de Valor Valor agregado estimado do sistema O sistema no crucial para o

Agregado ao Sistema
Requisitos de Controle Limitaes sobre quem pode acessar
de Acesso
e seus dados funcionamento da empresa, mas sua
paralisao teve um custo estimado em
$ 5 0 . 0 0 0 por hora no ltimo demonstrativo.
Uma perda total de todos os dados do
sistema tem um custo estimado em
$ 2 0 milhes.
Somente os gerentes de departamento
quais dados podero alterar os itens do estoque em
seus prprios departamentos.
Os operadores de telemarketing podero
ler e criar itens no arquivo de clientes, mas
no podero alter-los ou exclu-los.

Requisitos de Define quais dados e onde sero Os dados sero criptografados no

Criptografia e criptografados e se ser necessrio computador do usurio para o W e b site
Autenticao autenticar o acesso do usurio para proporcionar segurana realizao
de pedidos.
Ser exigida a autenticao para os
usurios que efetuarem logon fora do
ambiente do escritrio.
Requisitos de Controle Requisitos para controlar a difuso Todos os arquivos atualizados sero
de Vrus de vrus verificados em busca de vrus antes de
serem salvos no sistema.

FIGURA 9 - 8
Requisitos de Segurana

rante, o banco no poder conduzir os negcios com seus clientes. Uma aplicao crtica de mis-
so um sistema de informaes que seja literalmente crucial para a sobrevivncia da empresa.
uma aplicao que no pode se permitir falhar, e se falhar o pessoal de operaes parar tudo para
solucionar o problema. As aplicaes cruciais para o funcionamento em geral so claramente iden-
tificadas; portanto, a importncia delas no negligenciada.
Mesmo os distrbios temporrios no servio podem ter custos significativos. O custo de distrbi-
os no Web site principal de uma empresa ou nas redes locais e backbones que do suporte s opera-
es de vendas por telefone freqentemente medido em milhes. A Amazon.com, por exemplo,
tem receitas de mais de U$ 10 milhes por hora; assim, se o Web site da empresa ficar inoperante por
uma hora, ou mesmo uma frao de hora, acarretar um custo de milhes de dlares em perda de
receita. As empresas que efetuam menos vendas por meio de comrcio eletrnico ou via telefone
possuem custos menores, mas levantamentos recentes que sugerem perdas de $100.000 a $200.000
por hora no so incomuns para os principais sistemas de informaes voltados ao cliente.

Requisitos de Controle de Acesso Alguns dados armazenados no sistema precisam ser mantidos
em sigilo; alguns dados precisam de controles especiais sobre quem est autorizado a alter-los
ou exclu-los. Registros de pessoal, por exemplo, deveriam estar disponveis para leitura somente
para o departamento de pessoal e para o supervisor dos empregados; as alteraes deveriam ficar
a cargo somente do departamento de pessoal. Os requisitos de controle de acesso especificam quem
pode acessar quais dados e que tipo de acesso permitido: se o indivduo pode criar, ler, atualizar
e/ou excluir os dados. Os requisitos reduzem a chance de um usurio autorizado do sistema exe-
cutar aes no-autorizadas.

Requisitos de Criptografia e Autenticao Uma das melhores maneiras de evitar acesso no-auto-
rizado a dados a criptografia, que um meio de distinguir informaes pelo uso de algoritmos
matemticos (ou frmulas). A criptografia pode ser usada para proteger dados armazenados em
bancos de dados ou dados que so transmitidos por uma rede provenientes de um banco de dados
para um computador. H dois tipos fundamentalmente diferentes de criptografia: simtrica e assi-
mtrica. Um algoritmo de criptografia simtrica (como o Data Encryption Standard [DES] ou
 Projeto de Arquitetura 247

CONCEITOS 9-C UMA INTERRUPO NO FORNECIMENTO DE ENERGIA CUSTA UM MILHO DE DLARES

EM AO
A Lithonia Lighting, localizada nos arredores de Atlanta, o
maior fabricante mundial de acessrios de iluminao, com mais
de $1 bilho em vendas anuais. Uma tarde, o transformador de
energia que alimentava a matriz da empresa explodiu, deixan-
do todo o complexo do escritrio, incluindo a central de dados
da empresa, sem energia eltrica. O sistema auxiliar de ener-
gia da central de dados imediatamente entrou em funcionamen-
to, e manteve operacionais as partes crticas do centro de da-
dos, isso, porm, foi insuficiente para acionar todos os sistemas,
e assim o sistema que d suporte s vendas para todos os agen-
tes, concessionrios e distribuidores da Lithonia Lighting no nor-
te do pas teve de ser desativado.
O transformador foi substitudo rapidamente, e a energia foi
restabelecida. Entretanto, a paralisao de trs horas do siste-
ma de vendas custou $1 milho em vendas potencialmente per-
didas. Infelizmente, no incomum que o custo de um distrbio
venha a representar centenas ou milhares de vezes o custo dos
componentes que falharam.
PERGUNTA:
O que voc recomendaria para evitar perdas semelhantes no
futuro?

Advanced Encryption Standard [AES]) uma criptografia em que a chave usada para criptografar
uma mensagem a mesma usada para decifr-la, o que significa que essencial proteger a chave,
e que uma chave separada deve ser usada para cada pessoa ou empresa com quem o sistema com-
partilha informaes (ou uma outra pessoa poder ler todos os dados).
Um algoritmo de criptografia assimtrica (como a criptografia de chave pblica) uma
criptografia em que a chave usada para criptografar os dados (denominada chave pblica) dife-
rente da chave usada para decriptograf-los (denominada chave privada). Mesmo que algum
conhea a chave pblica, uma vez que os dados estejam criptografados no podem ser decifrados
sem a chave privada. A criptografia de chave pblica reduz imensamente o problema de gerenci-
amento de chaves. Cada usurio possui sua chave pblica que usada para criptografar mensa-
gens enviadas a ele. Essas chaves pblicas so amplamente divulgadas (p. ex., listadas em um
diretrio no estilo de um catlogo telefnico) por isso elas so chamadas de chaves "pblicas".
A chave privada, ao contrrio, mantida em segredo (por isso chamada de chave "privada").
A criptografia de chave pblica tambm permite autenticaes (ou assinaturas digitais). Quando
um usurio envia uma mensagem para outro difcil provar legalmente quem realmente enviou a
mensagem. A prova legal importante em muitas comunicaes, como transferncias bancrias e
pedidos de compra/venda em moeda corrente e comercializao de aes, o que normalmente re-
quer assinaturas legais. Os algoritmos de criptografia de chave pblica so reversveis, o que signi-
fica que o texto criptografado com qualquer uma das duas chaves pode ser decifrado pela outra. Nor-
malmente criptografamos com a chave pblica e deciframos com a chave privada. Porm, possvel
fazer o inverso: criptografar com a chave privada e decifrar com a chave pblica. Visto que a chave
privada secreta, somente o usurio real poderia us-la para criptografar uma mensagem. Portanto,
uma assinatura digital ou seqncia de autenticao usada como uma assinatura legal em muitas
transaes financeiras. Essa assinatura normalmente o nome da parte signatria interessada mais
outra informao exclusiva da mensagem (p. ex., data, hora ou montante em dlares). Essa assinatu-
ra e a outra informao so criptografadas pelo remetente usando a chave privada. O destinatrio usa
a chave pblica do remetente para decifrar o bloco de assinatura e compara o resultado ao nome e ao
contedo de outra chave no restante da mensagem para assegurar uma correlao.
O nico problema com essa abordagem assegurar que a pessoa ou empresa que enviou o
documento com a chave privada correta realmente quem afirma ser. Qualquer pessoa pode pos-
tar uma chave pblica pela Internet sem que haja uma maneira segura de saber quem ela realmen-
te . Por exemplo, seria possvel uma pessoa afirmar ser da "Empresa A", quando na realidade
um impostor.
nessa situao que a infra-estrutura da chave pblica (PKI, public key infrastructure) se tor-
na importante.4 A PKI um conjunto de hardwares, softwares, empresas e polticas projetado para
fazer com que a criptografia de chave pblica funcione na Internet. A PKI comea com uma au-
toridade de certificao, AC (CA, certificate authority), que um rgo confivel que pode ga-

bara obter mais informaes sobre a PKI, consulte www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-06.txt.

rantir a autenticidade da pessoa ou empresa que esta usando a autenticao (p. ex., VeriSign). Uma
pessoa que queira usar uma AC registra-se nela e tem de apresentar alguma prova de identidade.
H diversos nveis de certificao, variando de uma simples confirmao de endereo de correio
eletrnico vlido a uma verificao completa em estilo policial com uma entrevista pessoal. A
AC emite um certificado digital, que a chave pblica do requisitante criptografada por meio de
uma chave privada da AC como prova de identificao. Depois, esse certificado anexado ao correio
eletrnico do usurio ou s transaes Web junto com as informaes de autenticao. O destina-
trio, ento, verifica o certificado decriptografando-o com a chave pblica da AC e tambm
deve entrar em contato com a AC para se assegurar de que o certificado do usurio no tenha sido
revogado pelo rgo de autenticao.
Os requisitos de criptografia e autenticao especificam quais desses requisitos so necessri-
os para quais dados. Por exemplo, dados confidenciais, como nmeros de cartes de crdito de
clientes, sero armazenados no banco de dados na forma criptografada ou a criptografia ser usa-
da para registrar pedidos pela Internet provenientes do Web site da empresa? Os usurios sero
obrigados a usar um certificado digital, alm de uma senha-padro?

Requisitos de Controle de Vrus O problema de segurana individual mais comum vem do vrus.
Estudos recentes tm mostrado que quase 90% das empresas sofrem uma infeco por vrus a cada
ano. Os vrus provocam situaes indesejveis algumas inofensivas (como mensagens incon-
venientes), algumas srias (como a destruio de dados). Sempre que um sistema permite que dados
sejam importados ou carregados a partir do computador de um usurio, h a possibilidade de uma
infeco por vrus. Muitos sistemas requerem que todos os sistemas de informaes que permi-
tem a importao ou carga de arquivos de usurios verifiquem esses arquivos em busca de vrus
antes de armazen-los no sistema.

Requisitos Culturais e Polticos

Os requisitos culturais e polticos so aqueles especficos para os determinados pases onde o sis-
tema ser usado. No ambiente empresarial globalizado de hoje as empresas esto expandindo seus
sistemas para atingirem usurios em todos os cantos do mundo. Embora isso possa fazer muito
sentido sob o ponto de vista comercial, seu impacto sobre o desenvolvimento da aplicao no
deve ser subestimado. Outra parte ainda importante do projeto da arquitetura do sistema com-
preender os requisitos culturais e polticos internacionais do sistema; veja a Figura 9-9.

Requisitos Multilnges A primeira e mais bvia diferena entre as aplicaes usadas em uma regio
e aquelas projetadas para uso global o idioma. As aplicaes internacionais freqentemente tm
requisitos multilnges, o que significa que devem prever o uso por usurios que falem idiomas di-
ferentes ou escrevam usando caracteres diferentes do ingls (p. ex., caracteres com acentos, cirlico,
japons). Um dos aspectos mais desafiadores em projetar sistemas internacionais obter uma boa
traduo das mensagens no idioma original para um novo idioma. As palavras freqentemente tm
significados similares, mas podem transmitir significados ligeiramente diferentes quando so tradu-
zidas, assim importante usar tradutores qualificados em traduo de termos tcnicos.
O outro desafio o espao da tela. Em geral, as mensagens no idioma ingls normalmente
consomem de 20% a 30% menos letras que suas congneres no idioma francs ou espanhol. Pro-
jetar sistemas internacionais requer alocar mais espao de tela para as mensagens do que poderia
ser usado na verso em ingls.
Alguns sistemas so projetados para manipular diversos idiomas dinamicamente, para que
usurios em pases diferentes possam usar idiomas diferentes ao mesmo tempo; isto , o mesmo
sistema admite diversos idiomas diferentes simultaneamente (um sistema multilnge simultneo).
Outros sistemas contm partes separadas que so escritas em cada idioma e devem ser reinstaladas
antes que um idioma especfico possa ser usado; isto , cada idioma servido por uma verso
diferente do sistema para que qualquer instalao use apenas um idioma (especificamente, um
sistema multilnge discreto). Qualquer uma dessas abordagens pode ser eficiente, mas essa fun-
cionalidade deve ser projetada para o sistema bem antes da implementao.

Requisitos de Personalizao Para aplicaes internacionais, a equipe de projeto precisar dar al-
guma ateno aos requisitos de personalizao: o quanto da aplicao ser gerenciado por um
 Projeto de Arquitetura 249

Tipo de Requisito Definio Exemplos

Requisitos M u l t i l n g e s O idioma em que o sistema O sistema operar em ingls, francs

precisar operar e espanhol.
Requisitos de A especificao de quais aspectos Os gerentes nos pases podero definir
Personalizao do sistema podem ser alterados novos campos no banco de dados de
pelos usurios locais produtos para capturar informaes
especficas sobre o pas.
Os gerentes nos pases podero alterar
o formato do campo do nmero telefnico
no banco de dados de clientes.
Tornando Explcitas as Indicar explicitamente as normas Todos os campos de data estaro
N o r m a s Implcitas implcitas que diferem de pas explicitamente identificados, informando
para pas que se encontram no formato ms-dia-ano.
Todos os campos referentes a peso
estaro explicitamente identificados
informando que esto expressos em
quilogramas.

Requisitos Legais As leis e os regulamentos que As informaes pessoais sobre os

impem os requisitos no sistema
clientes no podem ser transferidas
dos pases da Unio Europia para
os Estados Unidos.
E contra a lei federal dos Estados Unidos
divulgar informaes sobre quem alugou
qual vdeo; portanto, o acesso ao histrico
de vdeos alugados pelos clientes
permitido apenas aos gerentes regionais.

FIGURA 9-9
Requisitos Culturais e Polticos

CONCEITOS 9-D DESENVOLVENDO SISTEMAS MULTILNGES

EM AO
Tive a oportunidade de desenvolver dois sistemas multilnges.
O primeiro foi um sistema de suporte deciso com finalidade
especfica para ajudar a programar pedidos em fbricas de pa-
pel denominado BCW-Trim. O sistema foi instalado em dezenas
de fbricas de papel no Canad e nos Estados Unidos, e foi pro-
jetado para operar em ingls ou em francs. Todas as mensa-
gens eram armazenadas em arquivos separados (um definido
em ingls, outro definido em francs), com o programa escrito
para usar variveis inicializadas para o texto em ingls ou em
francs. Os arquivos do idioma apropriado foram includos quan-
do o sistema foi compilado para produzir a verso em francs
ou em ingls.
O segundo programa foi um sistema criado por um grupo de
trabalho denominado GroupSystems, para o qual projetei diver-
sos mdulos. O sistema foi traduzido em dezenas de idiomas,
incluindo francs, espanhol, portugus, alemo, finlands e
croata. Esse sistema permite que o usurio alterne vontade entre
idiomas, armazenando mensagens em arquivos simples de tex-
to. Esse projeto muito mais flexvel, porque cada instalao
individual pode revisar as mensagens vontade. Sem essa abor-
dagem, improvvel que houvesse demanda suficiente para jus-
tificar o desenvolvimento de verses para dar suporte a idiomas
menos usados normalmente (p. ex., o croata).
Alan Pennie
PERGUNTAS:
1. Como voc decidiria admitir usurios que falam idiomas di-
ferentes do ingls no sistema?
2. Voc criaria recursos multilnges para qualquer aplicao
que estivesse disponvel para pessoas que no falassem o
idioma ingls? Pense nos W e b sites que existem hoje em dia.

grupo central e o quanto ser gerenciado localmente. Por exemplo, algumas empresas permitem
que as subsidirias em alguns pases personalizem a aplicao omitindo ou adicionando certos
recursos. Essa deciso traz equilbrio entre flexibilidade e controle, porque a personalizao fre-
qentemente dificulta a criao e a manuteno da aplicao pela equipe de projeto. Isso tambm
significa que o treinamento pode diferir entre partes diferentes da empresa, e a personalizao pode
criar problemas quando o pessoal se desloca de um local para outro.
Normas Implcitas Muitos pases possuem normas implcitas que no so compartilhadas interna-
cionalmente. importante para o projetista da aplicao tornar explcitas essas suposies, por-
que do contrrio elas podem gerar confuses. Nos Estados Unidos, a norma implcita para digitar
uma data o formato de data mm/dd/aa; porm, no Canad e na maioria dos pases europeus a
norma implcita dd/mm/aa. Quando voc estiver projetando sistemas internacionais crucial
reconhecer essas normas implcitas e torn-las explcitas, para que os usurios em pases diferen-
tes no fiquem confusos. A moeda corrente em uso outro item que s vezes negligenciado no
projeto do sistema; sistemas de aplicao internacionais devem especificar a moeda corrente que
est sendo usada para inserir e apresentar informaes.

Requisitos Legais Os requisitos legais so aqueles impostos pelas leis e regulamentos de gover-
nos. Os desenvolvedores de sistemas s vezes se esquecem de levar em conta os regulamentos
legais, mas, infelizmente, agir dessa forma vem a ser um risco, porque a ignorncia das leis no
nenhuma justificativa. Por exemplo, em 1997 um tribunal francs condenou o Gergia Institute of
Technology por violar a lei do idioma francs. O Gergia Tech operava uma pequena faculdade
na Frana que oferecia cursos de vero para estudantes americanos. As informaes no servidor
Web da faculdade estavam principalmente em ingls, porque as aulas eram ministradas em in-
gls, o que violou a lei que obriga o francs a ser o idioma predominante em todos os servidores
de Internet na Frana. Considerando formalmente os regulamentos legais, era pouco provvel que
tivessem sido negligenciados.

Projetando a Arquitetura
Em muitos casos, quando orientados pelos requisitos empresariais, os requisitos do ambiente tc-
nico podem simplesmente definir a arquitetura da aplicao. Nesse caso, a opo simples: os
requisitos empresariais predominam sobre outras consideraes. Por exemplo, os requisitos em-
presariais podem especificar que o sistema precisa operar por meio da Web usando o navegador
Web do cliente. Nesse caso, a arquitetura da aplicao deve ser cliente magro-servidor. Esses re-
quisitos empresariais ocorrem com maior probabilidade em sistemas projetados para dar suporte
a clientes externos. Sistemas internos tambm podem impor requisitos empresariais, mas normal-
mente no so to restritos.
No caso de os requisitos do ambiente tcnico no exigirem a escolha de uma arquitetura especfi-
ca, ento os outros requisitos no-funcionais se tornam importantes. Mesmo em casos em que os re-
quisitos empresariais conduzem a arquitetura ainda importante persistir e refinar os requisitos no-
funcionais restantes, porque eles sero importantes nas etapas posteriores do projeto e nas fases de
implementao. A Figura 9-10 resume a relao entre os requisitos e as arquiteturas recomendadas.

Requisitos Operacionais Os requisitos de integrao de sistemas podem ocasionar uma arquitetura

sobre outra, dependendo da arquitetura e do projeto do sistema (ou sistemas) com o qual o sistema
precisa se integrar. Por exemplo, se o sistema tem de se integrar com um sistema de computador
de mesa (p. ex., o Excel), ento isso pode sugerir uma arquitetura de cliente magro ou cliente gordo-
servidor, enquanto tiver de se integrar com um sistema baseado em servidor; ento uma arquitetu-
ra baseada em servidor pode ser mais indicada. Os sistemas que possuem requisitos de portabili-
dade amplos tendem a se adaptar melhor a uma arquitetura cliente magro-servidor, porque mais
simples escrever para padres baseados na Web (HTML, XML), que ampliam o alcance do siste-
ma para outras plataformas, em vez de tentar escrever e reescrever extensas lgicas de apresenta-
o para plataformas diferentes nas arquiteturas baseadas em servidor, baseadas em cliente ou
baseadas em cliente gordo-servidor. Os sistemas com amplos requisitos de atualizao podem no
se adaptar bem s arquiteturas baseadas em cliente ou em cliente magro-servidor por causa da
necessidade de reinstalar softwares nos computadores de mesa.

Requisitos de Desempenho Falando genericamente, os sistemas de informaes que tm requisitos

de alto desempenho se adaptam melhor s arquiteturas cliente-servidor. As arquiteturas cliente-
servidor so mais facilmente redimensionveis, o que significa que respondem melhor s necessi-
dades variveis de capacidade e, portanto, permitem que a empresa afine melhor os hardwares aos
requisitos de velocidade do sistema. As arquiteturas cliente-servidor que tm diversos servidores
em cada camada devem ser mais confiveis e ter maior disponibilidade, porque se um servidor
 Projeto de Arquitetura 251

FIGURA 9 - 1 0
Requisitos No-funcionais e suas Baseada I Baseada Cliente Cliente
Requisitos em em Magro- Gordo-
Implicaes no Projeto de Arquitetura Servidor I Cliente Servidor Servidor

Requisitos Operacionais

Requisitos de Integrao de Sistemas

Requisitos de Portabilidade

Requisitos de Atualizao

Requisitos de Desempenho

Requisitos de Velocidade

Requisitos de Capacidade

^uisitos de Disponibilidade/Confiabilidade

Requisitos de Segurana

Valor Agregado ao Sistema

Requisitos de Controle de Acesso

Requisitos de Criptografia/Autenticao

Requisitos de Controle de Vrus

Requisitos Culturais/Polticos

Requisitos Multilnge

ficar inoperante as solicitaes simplesmente so passadas para outros servidores e os usurios

podem nem mesmo notar (embora o tempo de resposta possa piorar). Na prtica, entretanto, a
confiabilidade e a disponibilidade dependem imensamente do hardware e do sistema operacional,
e os computadores baseados no Windows tendem a apresentar menores confiabilidade e disponi-
bilidade que os computadores Linux ou mainframes.

Requisitos de Segurana Falando genericamente, as arquiteturas baseadas em servidor tendem a

ser mais seguras porque todos os softwares esto em um local e os sistemas operacionais de ma-
inframes so mais seguros que os sistemas operacionais de microcomputadores. Por essa razo,
sistemas de alto valor agregado tm mais possibilidades de ser encontrados em computadores
mainframes, mesmo que o mainframe seja usado como um servidor em uma arquitetura cliente-
servidor. No mundo de hoje, dominado pela Internet, as ferramentas de autenticao e criptografia
para arquiteturas cliente-servidor baseadas na Internet so mais avanadas que aquelas para ar-
quiteturas baseadas em servidor baseado em mainframe. Os vrus so problemas potenciais em
todas as arquiteturas, porque se propagam facilmente em computadores de mesa. Se os sistemas
baseados em servidor podem reduzir as funes residentes nos computadores de mesa, ento po-
dem ser mais seguros.

Requisitos Culturais e Polticos Conforme os requisitos culturais e polticos se tornam mais impor-
tantes, a capacidade de separar a lgica de apresentao da lgica de aplicao e dos dados se torna
igualmente importante. Essa separao facilita o desenvolvimento da lgica de apresentao ein
idiomas diferentes, ao mesmo tempo em que mantm inalterados a lgica de aplicao e os dados.
Tambm facilita a personalizao da lgica de apresentao para usurios diferentes e a alterao
252 Captulo Nove

9-1 SISTEMA DE MATRCULAS EM DISCIPLINAS DE UNIVERSIDADE

VEZ
Imagine o sistema de matrculas em disciplinas de sua univer- requisitos operacionais, de desempenho, de segurana e cultu-
sidade. Primeiro, desenvolva um conjunto de requisitos no-fun- rais e polticos. Depois crie um projeto de arquitetura que satis-
cionais se o sistema fosse ser desenvolvido hoje. Considere os faa esses requisitos.

9-2 SISTEMA DE APRENDIZADO ELETRNICO GLOBAL

VEZ
Muitas empresas multinacionais proporcionam cursos de nais para esse sistema. Considere os requisitos operacionais, de
aprendizado global baseados na Internet para seus emprega- desempenho, de segurana e culturais e polticos. Depois crie
dos. Primeiro, desenvolva um conjunto de requisitos no-funcio- um projeto de arquitetura que satisfaa esses requisitos.

dela para atender melhor s normas culturais. medida que a lgica de apresentao proporciona
acesso aplicao e aos dados, tambm facilita a implementao de diferentes verses que habi-
litam e desabilitam recursos exigidos por leis e regulamentos em diferentes pases. Essa separa-
o a mais simples nas arquiteturas cliente magro-servidor, e assim sistemas com muitos requi-
sitos culturais e polticos freqentemente usam arquiteturas cliente magro-servidor. Assim como
com os requisitos de integrao de sistemas, o impacto dos requisitos legais depende da natureza
especfica dos requisitos, mas em geral os sistemas baseados em clientes tendem a ser menos fle-
xveis.

ESPECIFICAO DE HARDWARE E SOFTWARE

A fase de projeto tambm o momento de comear a seleo e a aquisio de hardwares e softwa-

res que sero necessrios ao futuro sistema. Em muitos casos, o novo sistema simplesmente ser
executado no equipamento existente na empresa. Outras vezes, porm, novos hardwares e soft-
wares (normalmente para servidores) tm de ser comprados. A especificao de hardware e soft-
ware um documento que descreve quais hardwares e softwares so necessrios para dar suporte
aplicao. A aquisio de hardwares e softwares realmente deve ser deixada para o departamen-
to de compras ou para a rea da empresa que trate de interesses patrimoniais; porm, a equipe de
projeto pode usar a especificao de hardware e software para transmitir as necessidades do pro-
jeto para as pessoas apropriadas. H diversas etapas envolvidas na criao do documento. A Figu-
ra 9-11 mostra um exemplo de especificao de hardware e software.
Primeiro, voc precisar definir o software que ser executado em cada componente. Isso nor-
malmente comea com o sistema operacional (Windows, Linux) e inclui qualquer software de uso
especial no cliente e nos servidores (p. ex., banco de dados Oracle). Isso deve considerar qualquer
custo adicional, como treinamento tcnico, manuteno, garantias ampliadas e acordos de licen-
ciamento (ou seja, uma licena de uso local de um software pronto), custos relativos a hardwares
e softwares que devem ser considerados durante o processo de aquisio. Novamente, as necessi-
dades que voc lista so influenciadas pelas decises que so tomadas nas outras atividades da
fase de projeto.
Depois, voc deve criar uma lista dos hardwares que sero necessrios para operar o futuro
sistema. Em geral, a lista pode incluir equipamentos como servidores de banco de dados, servidores
de rede, dispositivos perifricos (impressoras, scanners), dispositivos de backup, componentes de
armazenagem e qualquer outro componente de hardware que seja necessrio para executar uma
aplicao. Nesse momento, voc deve observar a quantidade de cada item que ser necessria.
Finalmente, voc precisa descrever, o mais detalhadamente possvel, os requisitos mnimos de
cada componente de hardware. Muitas empresas tm listas-padro de hardwares e softwares que
 Projeto de Arquitetura 253

Servidor Servidor de Servidor de

Cliente- Web Aplicao Banco d e D a d o s
Padro Padro Padro Padro |

Sistema Windows Windows Windows Windows

Operacional Internet Explorer
Software Componentes do Servidor W e b IIS Linguagem C Servidor SQL
Especial Active X Components Componentes Componentes Componentes
Adobe Acrobat Reader da Internet da Internet da Internet

Hardware Unidade de disco Unidade de disco Unidade de disco Unidade de disco

rgido de 10 giga rgido de 40 giga rgido de 40 giga rgido de 2 0 0 giga
Pentium Pentium Pentium RAID
Monitor de 17 Pentium Quad
polegadas

Rede Preferencialmente Ethernet dual Ethernet dual Ethernet dual

banda larga de lOOMbps de 1 OOMbps de 1 OOMbps
sempre ativa
Dial-up a 5Kbps
possveis com
alguma perda
de desempenho

FIGURA 9 - 1 1
Exemplo de uma Especificao de
Hardware e Software

devem ser usados; assim, em muitos casos essa etapa envolve simplesmente selecionar itens nas
listas. Outras vezes, porm, a equipe est operando em territrio novo e no est restrita neces-
sidade de selecionar em uma lista aprovada. Nesses casos, a equipe de projeto deve transferir es-
ses requisitos conforme o grau de capacidade de processamento, o grau de espao de armazena-
gem e qualquer recurso especial que deva ser includo. Essa etapa fica mais fcil quando se ex-
periente; entretanto, h sugestes que podem ajud-lo a descrever as necessidades de hardwares;
veja a Figura 9-12.

APLICAO DOS CONCEITOS CD SELECT10NS

Criando um Projeto de Arquitetura

Alec Adams, analista de sistemas snior e gerente de projeto do sistema de Internet da CD
Selections, percebeu que os hardwares, softwares e redes que operariam a nova aplicao precisa-
riam estar integrados infra-estrutura atual da CD Selections. Ele comeou usando os requisitos

Funes e Recursos Quais funes e recursos especficos so necessrios (p. ex., tamanho de
monitor, recursos de software)
Desempenho O grau de rapidez de operao de hardwares e softwares (p. ex., processador,
nmero de gravaes por segundo em banco de dados)
Bancos de Dados e Sistemas Preexistentes O grau de interao de hardwares e softwares com
os sistemas preexistentes (p. ex., isso pode ser gravado nesse banco de dados)
Estratgias de Hardwares e Sistemas Operacionais Quais so os planos de migrao futuros
(p. ex., o objetivo dispor de todo o equipamento de um mesmo fornecedor)
Custo de Propriedade Quais so os custos alm da compra (p. ex., custos adicionais de licena,
manuteno anual, custos de treinamento, custos salariais)
Preferncias de Polticas As pessoas tm hbitos e so resistentes a mudanas, portanto as
modificaes devem ser minimizadas
FIGURA 9 - 1 2 Desempenho do Fornecedor Alguns fornecedores tm reputaes ou perspectivas futuras que no
Fatores na Seleo de Hardwares e condizem com os hardwares ou softwares especficos que vendem no momento
Softwares
254 Captulo Nove

9-3 SISTEMA DE MATRCULAS EM DISCIPLINAS DE UNIVERSIDADE

VEZ

Desenvolva uma especificao de hardware e software para o sistema de matrculas em disciplinas de universidade descrito em
"Sua Vez 9 - 1 " .

I VEZ
I 9-4 SISTEMA DE APRENDIZADO ELETRNICO GLOBAL

Desenvolva uma especificao de hardware e software para o sistema de aprendizado eletrnico global descrito em "Sua Vez
9-2".

no-funcionais de alto nvel desenvolvidos na fase de anlise (veja a Figura 4-13, no Captulo 4)
e conduzindo uma sesso JAD e uma srie de entrevistas com gerentes no departamento de mar-
keting e gerentes de trs lojas para aprimorar os requisitos no-funcionais com mais riqueza de
detalhes. A Figura 9-13 mostra alguns dos resultados. A necessidade operacional clara de uma
arquitetura baseada na Web exigiu uma arquitetura cliente magro-servidor.
A CD Selections tinha um grupo de arquitetura formal responsvel por gerenciar a arquitetura
da CD Selections e sua infra-estrutura de hardware e software. Portanto, Alec organizou uma reu-
nio com a equipe de projeto e o grupo de arquitetura. Durante a reunio, ele confirmou que a CD
Selections ainda estava caminhando em direo a uma arquitetura final cliente-servidor, embora
o mainframe central ainda existisse como o servidor principal de muitas aplicaes baseadas em
servidor.
Eles discutiram o sistema de Internet e decidiram que ele deveria ser construdo usando uma
arquitetura cliente magro-servidor de trs camadas. Todos concordavam que era difcil saber nes-
se ponto exatamente quanto trfego esse Web site receberia e qual capacidade o sistema exigiria,
mas uma arquitetura cliente-servidor permitiria que a CD Selections aperfeioasse facilmente o
sistema conforme fosse necessrio.
No final da reunio, concordou-se que uma arquitetura cliente-servidor de trs camadas era a
melhor configurao para a parte do sistema relativa Internet. Os usurios utilizariam seus com-
putadores pessoais executando um navegador Web como o cliente. Um servidor de banco de da-
dos armazenaria os bancos de dados do sistema de Internet, enquanto um servidor de aplicao
abrigaria o software de servidor Web e o software de aplicao para operar o sistema.
O sistema de reservas j estava construdo, usando uma arquitetura cliente-servidor de duas
camadas; portanto, a parte do sistema responsvel pelas reservas satisfazia aquela arquitetura. Um
segundo sistema cliente-servidor de duas camadas habilitaria o pessoal no departamento de mar-
keting a manter as informaes sobre os materiais promocionais. Esse sistema teria uma aplica-
o para os microcomputadores do pessoal que trabalha no grupo de vendas pela Internet, que se
comunicaria diretamente com o servidor de banco de dados e permitiria ao pessoal atualizar as
informaes. O servidor de banco de dados teria um programa separado para trocar dados com o
sistema de pedidos especiais, com o sistema de estoque de CDs e com os bancos de dados de in-
formaes de CDs da CD Selections no mainframe da empresa.
Dado que a interface com a Web alcanaria um grupo geograficamente disperso, a equipe de
projeto percebeu que precisava planejar o suporte do sistema para 24 X 7. Ela agendou uma reu-
nio para conversar com o grupo de operaes de sistemas da CD Selections e discutiu como po-
deriam ser capazes de dar suporte ao sistema de Internet fora do horrio comercial padro.

Especificao de Hardware e Software

O grupo de arquitetura e a equipe de projeto decidiram que os nicos componentes que precisa-
vam ser adquiridos para o projeto eram um servidor de banco de dados, um servidor Web e cinco
 Projeto de Arquitetura 255

1. Requisitos Operacionais

Ambiente Tcnico 1.1 O sistema funcionar por meio do ambiente Web com Internet Explorer e Real Audio.
1.2 Os clientes precisaro apenas do IE e do RA em seus computadores.
Integrao de Sistemas 1.3 O sistema de Internet lera informaes do banco de dados principal de informaes de CDs,
que contm informaes sobre CDs (p. ex., ttulo, artista, nmero de identificao, preo,
quantidade em estoque). O sistema de Internet no gravar informaes no banco de dados
principal de informaes de CDs.
1.4 O sistema de Internet transmitir pedidos de CDs novos no sistema de pedidos especiais e
contar com esse sistema para concluir os pedidos especiais gerados.
O sistema de Internet lera e gravar no banco de dados principal de estoque.
Um novo mdulo para o sistema de reservas ser escrito para gerenciar as "reservas"
geradas pelo sistema de Internet. Os requisitos desse novo mdulo sero documentados
como parte do sistema de Internet porque so necessrios para que ele funcione.

Portabilidade 1.7 O sistema precisar estar em dia com a evoluo dos padres Web, especialmente aqueles
pertencentes a formatos de msica.
Atualizao 1.8 Nenhum requisito especial de atualizao foi proposto.

2. Requisitos de Desempenho

Velocidade 2.1 Os tempos de resposta devem ser menores que sete segundos.
2.2 O banco de dados de estoque deve ser atualizado em tempo real.
2.3 As reservas devem ser enviadas ao estoque no prazo de cinco minutos.
Capacidade 2.4 Haver um mximo de usurios simultneos variando entre 20 e 50 no horrio de pico.
2.5 O sistema dar suporte a transmisses de udio de at 40 usurios simultneos.
2.6 O sistema enviar at 5K de dados para cada loja diariamente.
2.7 O banco de dados de reservas exigir de 10 a 20K de espao em disco por loja.
Disponibilidade e Confiabilidade 2.8 O sistema deve estar disponvel 24 horas por dias, 7 dias por semana.
2.9 O sistema ter 9 9 % de desempenho de funcionamento.

3. Requisitos de Segurana

Valor Agregado ao Sistema 3.1 Nenhum requisito especial de valor agregado ao sistema foi proposto.
Controle de Acesso 3.2 Apenas os gerentes de lojas podero anular reservas.
Criptografia/Autenticao 3.3 Nenhum requisito especial de criptografia/autenticao foi proposto.
Controle de Vrus 3.4 Nenhum requisito especial de controle de vrus foi proposto.

4. Requisitos Culturais/Polticos

Multilnge 4.1 Nenhum requisito multilnge especial foi proposto.

Personalizao 4.2 Nenhum requisito especial de personalizao foi proposto.
Normas Implcitas 4.3 Nenhum requisito especial de normas implcitas foi proposto.
Legais 4.4 Nenhum requisito legal especial foi proposto.

FIGURA 9 - 1 3
Requisitos No-funcionais Selecionados
para a CD Selections

novos computadores clientes para o grupo de marketing que manter os materiais promocionais.
Eles desenvolveram uma especificao de hardware e software para aqueles componentes e a re-
passaram para o departamento de compras iniciar o processo de aquisio.

RESUMO
Arquiteturas de Aplicaes
Todos os sistemas de software podem ser divididos em quatro funes bsicas: armazenagem de
dados, lgica de acesso aos dados (p. ex., SQL), lgica de aplicao (que a lgica documentada
nos DFDs, casos de uso e requisitos funcionais) e a lgica de apresentao (a interface com o
usurio). H trs arquiteturas fundamentais de computao que dispem essas funes em com-
putadores diferentes. Nas arquiteturas baseadas em servidor, o servidor executa todas as funes.
Nas arquiteturas baseadas em cliente, os computadores clientes so responsveis pela lgica de
apresentao e pela lgica de acesso aos dados, com os dados sendo armazenados em um servidor
256 Captulo Nove

de arquivos. Nas arquiteturas cliente-servidor, o cliente responsvel pela lgica de apresentao

e o servidor responsvel pela lgica de acesso aos dados e armazenagem de dados. Nas arquite-
turas cliente magro-servidor, o servidor executa a lgica de aplicao, enquanto nas arquiteturas
cliente gordo-servidor, a lgica de aplicao compartilhada entre os servidores e os clientes. Em
uma arquitetura cliente-servidor de duas camadas h dois grupos de computadores: um cliente e
um conjunto de servidores. Em uma arquitetura cliente-servidor de trs camadas, h trs grupos
de computadores: um cliente, um conjunto de servidores de aplicaes e um conjunto de servido-
res de bancos de dados.

Projeto de Arquitetura
A criao de projetos de arquitetura comea com os requisitos no-funcionais. Os requisitos ope-
racionais especificam o ambiente operacional no qual o sistema deve ser executado e como po-
dem se modificar com o decorrer do tempo (especificamente, ambiente tcnico, integrao se sis-
temas, portabilidade e sustentabilidade). Os requisitos de desempenho enfocam questes de de-
sempenho, como velocidade, capacidade, disponibilidade e confiabilidade do sistema. Os requi-
sitos de segurana tentam proteger o sistema de informaes de distrbios e perdas de dados (p.
ex., valor agregado ao sistema, controle de acesso, criptografia e autenticao e controle de v-
rus). Os requisitos culturais e polticos so aqueles especficos para os pases onde o sistema ser
usado (ou seja, multilnge, personalizao, normas implcitas e legais).

Especificao de Software e Hardware

A especificao de hardware e software um documento que descreve quais hardwares e softwa-
res so necessrios para compor o sistema. Quando um documento de especificao criado, os
equipamentos que so necessrios para compor o futuro sistema so listados e, em seguida, des-
critos com a maior riqueza de detalhes possvel. Depois, as aplicaes que sero executadas em
cada componente so registradas juntamente com qualquer custo adicional, como treinamento
tcnico, manuteno, garantias ampliadas e acordos de licenciamentos. Embora a equipe de pro-
jeto possa sugerir produtos ou fornecedores especficos, em ltima instncia a especificao de
hardware e software retorna s pessoas encarregadas pelas compras.

TERMOS IMPORTANTES
24 X 7 Criptografia de chave pblica Requisitos de desempenho
Algoritmo de criptografia assimtrico Especificao de hardware e software Requisitos de disponibilidade e
Algoritmo de criptografia simtrico Funes confiabilidade
Armazenagem de dados Lgica de acesso aos dados Requisitos de integrao de sistemas
Arquitetura baseada em cliente Lgica de aplicao Requisitos de personalizao
Arquitetura baseada em servidor Lgica de apresentao Requisitos de portabilidade
Arquitetura cliente-servidor Mainframe Requisitos de segurana
Arquitetura de duas camadas Microcomputador Requisitos de velocidade
Arquitetura de n camadas Middleware Requisitos do ambiente tcnico
Arquitetura de trs camadas Minicomputador Requisitos legais
Autenticao Normas implcitas Requisitos multilnges
Autoridade de certificao, AC (CA, Projeto de arquitetura Requisitos operacionais
certificate authority) Rede Servidor
Chave privada Redimensionvel Sistema crucial para o funcionamento
Chave pblica Requisitos culturais e polticos Sistema multilnge discreto
Cliente gordo Requisitos de atualizao Sistema multilnge simultneo
Cliente magro Requisitos de capacidade Tempo de resposta
Componente arquitetnico Requisitos de controle de acesso Terminal
Computador cliente Requisitos de controle de vrus Valor agregado ao sistema
Controle Requisitos de criptografia e autenticao Vrus
Criptografia

PERGUNTAS
1. Quais so as quatro funes gerais de qualquer sistema de
informaes?
2. Quais so os trs componentes de hardware principais de
uma arquitetura de aplicao?
3. Descreva dois exemplos de um servidor.
4. Compare e cite as diferenas entre as arquiteturas baseadas
em servidor, baseadas em cliente e cliente-servidor.
5. Qual o maior problema com as arquiteturas baseadas em
servidor?
6. Qual o maior problema com as arquiteturas baseadas em
cliente?
7. Descreva os principais benefcios e limitaes de arquitetu-
ras cliente-servidor.
8. Descreva as diferenas entre arquiteturas cliente-servidor
de duas camadas, de trs camadas e de n camadas.
9. Defina redimensionvel. Por que esse termo importante
para os desenvolvedores de sistemas?
10. Descreva os elementos na criao de um projeto de arquite-
tura.
11. Por que a equipe de projeto deve considerar a arquitetura da
aplicao existente na empresa ao projetar a arquitetura?
EXERCCIOS
A. Usando a Web (ou revistas especializadas), localize um sis-
tema que seja executado em um ambiente baseado em servi-
dor. Baseado no que aprendeu, por que voc acha que a em-
presa optou por esse ambiente?
B. Usando a Web (ou revistas especializadas), localize um sis-
tema que seja executado em um ambiente cliente-servidor.
Baseado no que aprendeu, por que voc acha que a empresa
optou por esse ambiente?
C. Usando a Web (ou revistas especializadas), localize alguns
mainframes, minicomputadores e microcomputadores. Com-
pare-os em termos de preo, velocidade, memria disponvel
e armazenagem em disco. Voc encontra grandes diferenas
de preo quando so levados em conta os desempenhos dos
equipamentos?
D. Voc foi selecionado para encontrai" a melhor arquitetura clien-
te-servidor para um sistema de entrada de pedidos baseado na
Web que est sendo desenvolvido por L.L. Bean. Escreva um
pequeno memorando descrevendo ao gerente de projeto suas
razes para selecionar uma arquitetura de n camadas em vez de
uma arquitetura de duas camadas. No memorando, d uma idia
sobre quais componentes da arquitetura voc incluiria.
E. Pense no sistema que sua universidade usa atualmente para
os servios vocacionais (colocao no mercado profissional)
e imagine que voc esteja encarregado de substituir esse sis-
MINICASOS
1. A equipe de projeto de desenvolvimento de sistemas na es-
cola de golfe Birdie Masters tem trabalhado para definir o
Projeto de Arquitetura 257
12. Descreva os principais requisitos no-funcionais e como eles
influenciam o projeto de arquitetura.
13. Por que til definir os requisitos no-funcionais de forma
mais detalhada, mesmo que os requisitos do ambiente tc-
nico determinem uma arquitetura especfica?
14. Quais custos adicionais associados a hardwares e softwares
podem precisar ser includos na especificao de hardware
e software?
15. Quem, em ltima instncia, est encarregado de adquirir
hardwares e softwares para o projeto?
16. Na sua opinio, quais so os trs erros mais comuns come-
tidos por analistas iniciantes na arquitetura de projeto e na
especificao de hardware e software?
17. H algum requisito no-funcional que influencie mais que
outros o projeto de arquitetura e a especificao de hardwa-
re e software?
18. Na sua opinio, quais so as questes de segurana mais
importantes de um sistema?
tema por um novo. Descreva por qual arquitetura do novo
sistema voc se decidiria usando os critrios apresentados
neste captulo. De quais informaes voc precisar antes de
fazer uma comparao fundamentada das alternativas?
F. Localize uma empresa de produtos de varejo na Web e leia
atentamente sua descrio (para que voc tenha uma boa idia
das localizaes geogrficas da empresa e de suas filiais). Ima-
gine que a empresa est para criar uma nova aplicao para
dar suporte a lojas de varejo pela Web. Crie um projeto de
arquitetura que represente os locais em que voc incluiria com-
ponentes que dessem suporte a essa aplicao.
G. Imagine que sua me uma agente imobiliria e que tenha
decidido automatizar suas tarefas dirias usando um laptop.
Considere as possveis necessidades de hardware e software
e crie uma especificao que os descreva. A especificao
deve ser desenvolvida para ajudar sua me a comprar por conta
prpria o equipamento e o software.
H. Imagine que o departamento de admisses em sua universi-
dade disponha de uma aplicao baseada na Web para que os
estudantes possam solicitar a admisso online. Recentemen-
te, houve um esforo visando admitir mais estudantes estran-
geiros na universidade. O que voc recomenda incluir na apli-
cao para assegurar que ela d suporte a esse requisito de
mbito global?
projeto de arquitetura de um novo sistema. O principal enfo-
que do projeto um sistema de operaes funcionando em
2S8 Captulo Nove
rede para a sede da escola e suas filiais, permitindo que cada
filial registre e recupere facilmente toda transao de dados
do grupo. Outro elemento do sistema o uso da Internet para
permitir que possveis e atuais alunos consultem as turmas
disponveis, agendem aulas e se matriculem em turmas em
qualquer instalao da Birdie Master, alm de manter um perfil
da evoluo do aluno uma anlise confidencial do desen-
volvimento das habilidades para o golfe de cada aluno.
A equipe de projeto vem considerando a possibilidade de
globalizao do sistema, o que deve ser levado em conta no
projeto de arquitetura. O plano de expanso da escola para o
mercado japons, que mostra uma grande procura por golfe,
continua de p. A primeira filial japonesa da escola est pla-
nejada para abrir experimentalmente cerca de seis meses aps
a data final de concluso do projeto do sistema. Logo, im-
portante que as questes relativas subsidiria internacional
sejam tratadas agora, durante o projeto.
Prepare um conjunto de requisitos no-funcionais, inclu-
indo requisitos operacionais, de desempenho, de segurana,
culturais e polticos. Muitas informaes esto incompletas,
mas faa o melhor que puder.
2. Jerry o gerente de projeto de uma equipe que desenvolve
um sistema de gerenciamento de lojas de varejo para uma
cadeia de lojas de material esportivo. A matriz da empresa
em Las Vegas, e a cadeia possui 27 filiais por toda a re-
gio de Nevada, Utah e Arizona. Algumas cidades possuem
diversas lojas. As lojas sero interligadas por um dos trs
servidores regionais, e os servidores regionais sero interli-
gados matriz da empresa em Las Vegas. Os servidores re-
gionais tambm sero interligados. Cada loja de varejo ser
equipada com configuraes semelhantes de dois terminais
de vendas baseados em PC em rede com um servidor de ar-
quivos local. Jerry tem de desenvolver o projeto de arquite-
tura e a especificao de hardware e software de um mode-
lo de rede que documentar a estrutura geogrfica desse sis-
tema. Ele nunca encarou um sistema dessa magnitude an-
tes, e est um pouco inseguro sobre como comear. Que con-
selhos voc lhe daria?
3. A Java Master uma agncia de recolocao profissional que
tem escritrios no norte da Califrnia. A Java Master opera
como uma agncia que faz a conexo entre suas empresas cli-
entes e especialistas em softwares independentes (normalmen-
te denominados "contratantes") com avanadas qualificaes
em desenvolvimento Web e Java para contratos de curto pra-
zo. A empresa est desenvolvendo um sistema baseado na
Web que permitir que as empresas clientes listem as neces-
sidades de trabalho e os bancos de dados de contratantes in-
dependentes. Os contratantes independentes tambm podem
postar currculos e disponibilidades e pesquisar os bancos de
dados de trabalhos disponveis. Tanto os contratantes quanto
as empresas pagam taxas para usufrurem o servio. Alguns
contratantes e empresas preferem permanecer annimos at
que se encontrem pessoalmente. Desenvolva os requisitos no-
funcionais e o projeto de arquitetura do sistema.
228 Captulo Oito

FIGURA 8-16
Matriz CRU D Preliminar dos Processos de 1.1 Encontrar 1.2 Fornecer 1.3 1.4 Colocar 1.5 Finalizar
CDs informaes Encontrar CD no compras
Registro e Solicitaes
de CD loja carrinho de
compras
Tabela CD
cd_numerodeestoque R R
cd titulo R R
cd artista R R
cd_categoria R R
cd statusdavenda R R
cd ultimaatualizacao
Tabela MATPRO
matjipo R
mat_numerodeidentificacao
mat descrio
mat email
mat contedo R
cd_numerodeestoque R
for nome
mat_ultimaatualizacao
Tabela ESTOQUE
est numerodoitem R
estjoja R
est_cep R
cd__numerodeestoque R
res identificao
est ultimaatualizacao
Tabela RESERVA
resjdentificacao CRUD
res_data CRUD
c!i_email CRUD
res_ultimaatualizacao CRUD

depsito de dados. Quando um depsito de dados atualizado de alguma maneira por um proces-
so, ento os dados devem trafegar no depsito de dados do processo. Veja a Figura 8-15 e observe
como a matriz CRUD reflete o que visto no modelo de processos.
A Figura 8-16 mostra um exemplo de uma matriz CRUD preliminar que foi criada para os
processos de registro de solicitaes do sistema de pedidos da CD Selections mostrados na Figu-
ra 8-7. Examine os modelos de processos originais e observe como os primeiros trs processos
so meramente leitura de informaes de depsitos de dados. Isso ilustrado na matriz CRUD
colocando-se um "R" (read=\er) nas intersees relevantes da matriz. Voc pode dizer como os
dados so usados pelos processos restantes?
Uma vez que os DFDs e ERDs tenham sido convertidos em modelos fsicos que descrevem
exatamente como o sistema ser criado e uma matriz CRUD tenha sido criada para mostrar como
os processos usam os dados, a equipe de projeto pode se concentrar no restante das tcnicas e ta-
refas da fase de projeto que sero apresentadas do Captulo 10 ao 12. Todos os documentos da
fase de projeto sero usados para criar a especificao do sistema, que usada pelos programado-
res para construir o sistema durante a implementao.

RESUMO
A Fase de Projeto
A fase de projeto a fase do SDLC em que o plano grfico do novo sistema desenvolvido, e
contm muitas etapas que orientam a equipe de projeto ao longo de todo o planejamento exata-
mente como o sistema precisa ser construdo. Os requisitos que foram identificados na fase de
 Projeto de Sistema 229

anlise servem como entradas primrias para as atividades de projeto. O documento principal da
fase de projeto a especificao do sistema, que inclui os modelos fsicos de processos e de da-
dos, o relatrio de arquitetura, as especificaes de hardware e software, o projeto da interface, o
projeto de depsitos de dados e o projeto do programa.

Estratgias de Projeto
Durante a fase de projeto a equipe tambm precisa considerar trs abordagens para criar o novo
sistema, incluindo desenvolver uma aplicao personalizada domstica; comprar um sistema pron-
to e personaliz-lo; e contar com um fornecedor, desenvolvedor ou provedor de servios externo
para construir e/ou dar suporte ao sistema. O desenvolvimento personalizado permite que os
desenvolvedores sejam flexveis e criativos na maneira de resolver problemas operacionais e de-
senvolver conhecimento tcnico e funcional dentro da empresa. Muitas empresas, porm, tm
um pessoal de desenvolvimento que j est totalmente comprometido em atender enormes de-
mandas de solicitaes de sistemas e simplesmente no tem tempo para se dedicar a um projeto
para o qual um sistema ser construdo desde o princpio. Pode ser muito mais eficiente comprar
programas que tenham sido criados, testados e aprovados, e um sistema pronto pode ser compra-
do e instalado em um perodo de tempo relativamente curto, quando comparado a uma soluo
personalizada. Podem ser usadas solues alternativas para satisfazer s necessidades que no
sejam tratadas pela aplicao comprada pronta. A terceira estratgia terceirizar o projeto e pa-
gar um fornecedor, desenvolvedor ou provedor de servios para criar o sistema. Esta pode ser
uma boa alternativa de abordagem do novo sistema; entretanto, existem custos que precisam ser
considerados. Se decidir deixar a criao de um novo sistema nas mos de outra pessoa, a empre-
sa poder comprometer informaes confidenciais ou perder o controle sobre o desenvolvimen-
to futuro.

Estratgia do Projeto
Cada uma das estratgias discutidas h pouco tem suas vantagens e desvantagens, e nenhuma delas
inerentemente melhor que as outras. Portanto, importante considerar questes como a singula-
ridade de necessidades operacionais do sistema, a existncia de qualificao suficiente na empre-
sa disponvel para construir o sistema e a importncia das qualificaes do projeto para a empre-
sa. Alm disso, a existncia de bom gerenciamento de projeto e o tempo disponvel para desen-
volver a aplicao so importantes no processo de seleo.

Selecionando uma Estratgia de Projeto

Finalmente, a deciso deve ser tomada em relao ao tipo especfico de sistema que precisa ser
projetado. Uma matriz de alternativas pode ajudar a equipe de projeto a tomar essa deciso, apre-
sentando informaes sobre a viabilidade de algumas solues candidatas de uma forma em que
possam ser facilmente comparadas. A solicitao de propostas e a solicitao de informaes so
duas maneiras de obter informaes precisas sobre as alternativas. Nesse ponto, a equipe decide
exatamente quem executar cada parte da fase de projeto e quais aplicaes sero usadas.

Os Diagramas Fsicos de Fluxo de Dados e de Relacionamento de Entidades

Um aspecto importante da parte inicial do projeto a mudana dos diagramas lgicos de fluxo de
dados (DFDs) e de relacionamento de entidades (ERDs) para os diagramas fsicos, que mostram
os detalhes de implementao e indicam como o sistema final funcionar. Os DFDs fsicos inclu-
em depsitos de dados que se referem a tabelas de arquivos e de banco de dados, aes de progra-
mas ou humanas que executam processos, e o meio de transferncia fsica dos fluxos de dados.
Eles mostram o limite homem-mquina, que ilustra quais partes do sistema so automatizadas e
quais so manuais.
Os ERDs fsicos contm referncias a como os dados sero armazenados em uma tabela de
arquivo ou de banco de dados, e os metadados so includos para descrever os componentes do
modelo de dados. Os dois modelos podem refletir decises de projeto (p. ex., criar um depsito
temporrio de dados, criar um campo para registrar quando um registro foi inserido ou alterado
pela ltima vez) que afetaro a implementao fsica do sistema.
A matriz CRUD pode ser criada para mostrar exatamente como os dados so criados e usados
pelos processos no sistema. As informaes na matriz CRUD so teis para validar os modelos
fsicos de processos e de dados e para fornecer informaes para o projeto do programa que ser
descrito no Captulo 12.
230 Captulo Oito

TERMOS IMPORTANTES
Acordo de tempo indeterminado Fase de projeto Requisitos do sistema
Chave externa Integrao de sistemas Software pronto
Chave primria Integridade referencial Solicitao de informaes (RFI, request
Contrato de preo fixo Limite homem-mquina for informatior)
Contrato de valor agregado Matriz CRUD Solicitao de proposta (RFP, request for
Desenvolvimento personalizado Matriz de alternativas proposal)
Diagrama lgico de fluxo de dados Modelo de dados fsico Soluo alternativa
Diagrama lgico de relacionamento de Modelo de processos fsico Terceirizao
entidades Planejamento de recursos de empresas
Especificao do sistema (ERP, enterprise resource planning)

PERGUNTAS
1. Quais so as atividades principais que ocorrem durante a fase
de projeto do ciclo de vida do desenvolvimento de sistemas
(SDLC)?
2. Qual o documento principal da fase de projeto? O que ele
inclui?
3. Compare e cite as diferenas entre as atividades de anlise
e de projeto. Qual a relao entre os fatos que ocorrem na
anlise e os que ocorrem no projeto?
4. Quais situaes so mais apropriadas para uma estratgia de
projeto de desenvolvimento personalizado?
5. Quais so os problemas em usar uma abordagem de compra
de software pronto para construir um novo sistema? Como
esses problemas podem ser tratados?
6. Por que as empresas investem em sistemas de planejamen-
to de recursos de empresas (ERP)?
7. Quais so os prs e os contras de se usar uma soluo alter-
nativa?
8. Quando a terceirizao considerada uma boa estratgia de
projeto? Quando no apropriada?
9. Quais so as diferenas entre os contratos de terceirizao
de tempo indeterminado, preo fixo e valor agregado?
10. Qual a relao entre a matriz de alternativas e a anlise de
viabilidade?
11. O que uma solicitao de propostas (RFP)? Como difere
de uma solicitao de informaes (RFI)?
12. Por que voc acha que a maioria das empresas parte do prin-
cpio de que ser usada uma estratgia de desenvolvimento
personalizada ao considerarem um novo sistema pela pri-
meira vez? Essa uma boa premissa?
13. Podemos eliminar ou reduzir a fase de anlise quando j
sabemos que ser usado um software comprado pronto em
detrimento da terceirizao ou do desenvolvimento perso-
nalizado? Explique.
14. Por que a integrao de sistemas est se tornando mais co-
mum?
15. Qual a finalidade de criar os modelos lgicos antes dos
modelos fsicos?
16. Quais so as diferenas entre o diagramas de fluxo de da-
dos (DFD) lgico e o fsico?
17. Quais so as diferenas entre o diagrama de relacionamen-
to de entidades (ERD) lgico e o fsico?
18. O que um limite homem-mquina?
19. Que tipos de metadados so includos no repositrio CASE
de um ERD fsico?
20. Descreva as finalidades de chaves primrias e chaves exter-
nas.
21. Quais so algumas das decises relacionadas ao sistema que
podem resultar em uma alterao para o DFD ou o ERD f-
sico?
22. O que uma matriz CRUD? Como est relacionada aos
modelos de processos e de dados?

EXERCCIOS
A. Desenhe o diagrama fsico de fluxo de dados nvel 0 (DFD)
para o sistema de consultrio de dentista a seguir e compare -
o ao modelo lgico que voc criou no Captulo 6. Quando no-
vos pacientes so atendidos pela primeira vez, preenchem um
formulrio de informaes do paciente solicitando seus no-
mes, endereos, telefones e um histrico mdico resumido,
informaes que so armazenadas no arquivo de informaes
de pacientes. Quando um paciente liga para agendar uma con-
sulta ou alterar uma existente, a recepcionista verifica o ar-
quivo de consultas para encontrar um horrio disponvel. Uma
vez que um horrio satisfatrio para o paciente tenha sido
encontrado, a consulta agendada. Se for a primeira consul-
ta, feito um lanamento de dados incompleto no arquivo de
pacientes; a informao completa ser coletada quando o pa-
ciente chegar para a consulta. Como as consultas so marca-
das geralmente com muita antecedncia, a recepcionista en-
via um lembrete por correio eletrnico para cada paciente duas
semanas antes da consulta.
B. Crie um DFD fsico nvel 0 para a situao a seguir e compa-
re-o com o modelo lgico que voc criou no Captulo 6. A
empresa A Real Estate Inc. (AREI) vende casas. As pessoas
que querem vender suas casas assinam um contrato com a
 Projeto de Sistema 231

AREI e fornecem informaes sobre a residncia. Essas in-

formaes so armazenadas no banco de dados da AREI, e
um subconjunto dessas informaes enviado para o servio
municipal de listagens diversificadas usado por todos os agen-
tes imobilirios. A AREI trabalha com dois tipos de compra-
dores potenciais. Alguns tm interesse em uma casa especfi-
ca. Nesse caso, a AREI imprime as informaes de seu ban-
co de dados e o agente imobilirio as utiliza como suporte na
mostra da casa ao comprador (um processo fora do escopo do
sistema a ser modelado). Outros compradores procuram acon-
selhamento na AREI para encontrar uma casa que atenda s
suas necessidades. Nesse caso, o comprador preenche um for-
mulrio de informaes do comprador que inserido em um
banco de dados de compradores, e os agentes imobilirios
usam essas informaes para procurar no banco de dados da
AREI e no servio de listagens diversificadas casas que aten-
dam aos requisitos. Os resultados dessas pesquisas so impres-
sos e usados como suporte para os agentes imobilirios mos-
trarem as casas aos compradores.
C. Desenhe um DFD fsico nvel 0 para o sistema a seguir e com-
pare-o com o modelo lgico que voc criou no Captulo 6. A
empresa A Video Store (AVS) gerencia vrias locadoras de
vdeo bem conhecidas. Antes que um vdeo possa ser coloca-
do na prateleira, ele deve ser catalogado e inserido no banco
de dados de vdeos. Todo cliente precisa ter um carto de cli-
ente vlido da AVS para alugar um vdeo. Os clientes podem
alugar vdeos por trs dias a cada vez. Sempre que um cliente
alugar um vdeo, o sistema ter de verificar se ele no tem ne-
nhum vdeo pendente. Se isso ocorrer, os vdeos pendentes
tero de ser devolvidos e uma taxa extra dever ser paga an-
tes que o cliente possa alugar mais vdeos. Da mesma forma,
se o cliente tiver devolvido os vdeos pendentes sem ter pago
a taxa extra esta ter de ser quitada antes que novos vdeos
possam ser alugados. Toda manh, o gerente da locadora
imprime um relatrio que lista os vdeos pendentes; se um
vdeo estiver dois ou mais dias atrasado o gerente entrar em
contato com o cliente para lembr-lo da devoluo do vdeo.
Se um vdeo for devolvido danificado, o gerente o remover
do banco de dados de vdeos e, em algumas situaes, poder
cobrar do cliente. Montar
Matricular Horrio do Criar Criar
D. Como o seguinte ERD seria alterado para incorporar a deci- Estudante Estudante Estudante Transcrio Fatura
so de projeto listada a seguir?
Depsito de ciados CRUD R R
O analista deseja controlar a identificao de usurio de estudante
qualquer pessoa que altere a nota de uma disciplina. Depsito de dados CRUD
Um depsito de dados adicionado no DFD fsico para que disciplina
Depsito de dados CRUD CRUD
as informaes relativas s disciplinas do semestre atual faturamento
possam ser armazenadas temporariamente durante o per- Depsito de dados CRUD
odo de cancelamento e incluso de novas disciplinas, an- nota

MINICASOS
1. Susan, presidente da MOTO, Inc., uma firma de gerenciamen-
to de recursos humanos, est refletindo sobre o sistema de ge-
renciamento de cliente que sua empresa comprou h quatro
anos. Naquela poca a firma tinha acabado de passar por uma
importante fase de crescimento, e a mistura de procedimen-
tos automatizados e manuais que tinham sido usados para
gerenciar as contas de clientes se tornou difcil de controlar.
Susan e Nancy, a chefe do departamento de SI, pesquisaram
e selecionaram esse sistema que est em uso atualmente. Su-
san tinha ouvido falar sobre o software em uma conferncia
profissional que assistiu e, pelo menos a princpio, ele funci-
onou muito bem para a firma. Alguns de seus procedimentos