Sunteți pe pagina 1din 613

Consultor Editorial

Fernando Barceilos Ximenes


KPMG Consulting
Traduo
Dalton Conde de Alencar
Mestre em Informtica
pelo Instituto Militar de Engenharia
yrOkIz
ESSOOAO D DE O CEPCOCRHCOS
ooierrro
EDITORA AFIL lADA
P Preencha a ficha de cadastro no final deste livro
e receba gratuitamente informaes
sobre os lanamentos e promoes
da Editora Campus.
Consulte tambm nosso catlogo
completo e ltimos lanamentos em
www.campus.com.br
EDWARD YOURDON
ANLISE
ESTRUTURADA
MODERNA
TRADUO DA TERCEIRA EDIO AMERICANA
12 Tiragem
mm.
CAMPUS
SERIE YOURDON PRESS
6s 1
Do original:
Modem Structured Analysis - 3 rd Ed.
Traduo autorizada do idioma ingls da edio publicada por i- Inc.
Copyright 1989 by Prentice-Hall, Inc. ci (./ . 2-1
1990, Editora Campus Ltda.
CL
Todos os direitos reservados e protegidos pela Lei 5988 de 14/12/73.
Nenhuma parte deste livro, sem autorizao prvia por escrito da editora, poder ser
reproduzida ou transmitida sejam quais forem os meios empregados:
eletrnicos, mecnicos, fotogrficos, gravao ou quaisquer outros.
Todo o esforo foi feito para fornecer a mais completa e adequada informao. ) Contudo
a editora e o(s) autor(es) no assumem responsabilidade
pelos resultados e uso da informao fornecida. Recomendamos aos leitores testar a
informao antes de sua efetiva utilizao.
Capa
Otvio Studart
Copidesque --
Maria Cludia Ajz Goulart
Editorao Eletrnica UNIVERSt DADE ESTCIO DE S
Graphbos J
Reviso Gr ltca _______
N
Projeto Grfico -
AQuaIidade Informtica. O(D \ O O\
Rua Sete de Setembro, 111 - l6 andar
20050-002 Rio de Janeiro RJ Brasil
Telefone: (021)509-5340 FAX (021)507-1991
E-Mail: info campus.com.br
ISBN 85-7001-615-8
(Edio Original: ISBN 0-13-598624-9, Prentice-Hall, Inc., Inc., New Jersey, USA).
Ficha Catalogrfica
CIP-Brasil. Catalogao-na-fonte.
Sindicato Nacional dos Editores de Livros, RJ
Yourdon, Edward, 1944-
Y74a Anlise estruturada moderna / Eward Vourdon; traduo
Dalton Conde de Alencar. - Rio de Janeiro: Campus, 1990.
Traduo de: Modem structured analysis
Apndice
Indice
ISBN 85-7001-615-8
1. Anlise de sistemas. 2. Processamento de dados - Tcnicas estruturadas. 1. Titulo
90.0087 CDD -001 64404
CDU -681.3.02
01020304 1615141312
Todos os esforos foram feitos para assegurar a preciso absoluta das informaes
apresentada publicao. A editora responsvel pela publicao original, a Editora Campus
e o(s) autor(es) det se isentam de qualquer tipo de garantia (explcita ou no), incluindo,
sem limitao, garantias im de comercializao e de adequao a determinadas
finalidades, com relao ao cdigo-fonte elc tcnicas descritos neste livro. A Editora
CampuS e o(s) autor(es) no se responsabilizam por prol relacionados funcionalidade
do cdigo-fonte para datas a partir de 01/01/2000.
PREFCIO
O que valioso no noto
e o que nova no valioso.
Henry Peter, Lord Brougham
Tbe Edinburgh Review, 1802
Permitam-me fazer uma pergunta bastante bvia: o mundo realmente precisa de outro
livro sobre anlise de sistemas? Esta pergunta pode parecer retrica mas houve muitas
ocasies - habitualmente tarde da noite , quando trabalhando neste livro, em que eu me
perguntei, Por que devo me preocupar com isso? Que h de errado com todos os livros
que tm sido usados nos ltimos dez anos? Como posso esperar acrescentar alguma coisa
literatura existente?
claro que o julgamento do resultado ser feito por outras pessoas, no por mim. No
entanto, creio realmente que existe a necessidade de um livro que atualize parte do
material clssico sobre anlise de sistemas publicada no final dos anos 70. Quando Tom
DeMarco escreveu Structured Analysis and S Spec e Chris Gane e Trish Sarson
escreveram Structured Systems Analysis: Tools and Techncs, no haviam linguagens de
quarta gerao, nem ferramentas de prototipao disponveis para os desenvolvedores de
sistemas. Os computadores pessoais ainda no tinham sido lanados, embora j
existissem algumas das primitivas mquinas da Apple e da Radio-Shack. No havia
produtos de software baseados em estaes inteligentes que auxiliassem o analista de
sistemas na elaborao dos diagramas de fluxo de dados.
Os progressos nessas reas tiveram um grande impacto na aceitao geral da anlise
estruturada: muitos questionam se a anlise estruturada relevante em ambientes onde os
usurios podem criar suas prprias aplicaes em questo de horas ou dias, S isso j
motivo para um novo livro sobre o tema da anlise de sistemas: a bem mais poderosa
tecnologia disponvel para os analistas de sistemas e usurios alterou nosso enfoque e
perspectivas.
Alm disso, os desenvolvedores de sistemas tiveram de enfrentar problemas de sistemas
de bancos de dados e de tempo real, em acrscimo aos sistemas orientados por funo
originalmente visados pela anlise estruturada no final dos anos 70. Este livro discute os
diagramas de entidades e de transies de estado, os clssicos diagramas de fluxo de
dados e mostra como esses trs modelos podem ser integrados; essa integrao de
modelos se tornar mais e mais importante no decorrer dos prximos anos. Alguns outros
recentes desenvolvimentos na anlise estruturada - incluindo o particionamento
de eventos e a desenfatizao da modelagem do sistema fsico atual - esto includos
neste livro.
Existe ainda outra razo para se escrever mais um livro sobre an lise estruturada: a
maioria dos livros clssicos sobre anlise estruturada foi escrita para analistas de
sistemas veteranos - sem preocupao com os mais novatos, que ainda esto se iniciando
na rea. Ademais, a maioria dos livros didticos sobre anlise de sistemas escritos,
durante os ltimos dez anos, deu pouca ateno s novas tcnicas de anlise estruturada e
continuou a dedicar muitas pginas s discusses sobre cartes perfurados e sobre o
cdigo Hollerith; afora o fato de que muitos desses aspectos estejam obsoletos, o
conhecimento superficial do hardware, do software e da programao de computadores ,
geralmente, ministrado por um curso de Introduo aos Computadores, que
habitualmente precede o aprofundamento no estudo da anlise de sistemas. Este livro
tenta obter o equilbrio, reconhecendo a necessidade de algum material introdutrio para
os estudantes que tiveram um curso inicial sobre computadores mas nunca fizeram
anlise de sistemas, embora reconhecendo que os conceitos de anlise de sistemas sejam
simples o bastante para que possam ser ensinados detalhadamente nos nveis de segundo
grau e universitrio. Em face disso, a maior parte do material introdutrio est reunido
nos apndices de modo que possam ser dispensados pelos que j tm prtica do assunto.
Este livro adequado para cursos universitrios de um semestre sobre anlise de
sistemas; ele satisfaz os requisitos do curso CIS-86/5 do CIS 86 DPMA Model
Curriculum for Undergraduate Computer Informa tion Systems. Entretanto ele no
abrange ambos os tpicos de anlise e projeto de sistemas, apesar de muitos
estabelecimentos de ensino tentarem cobrir os dois assuntos em um nico semestre.
Penso que existe material suficiente para discusso nas duas reas; para um curso de um
semestre sobre projeto estruturado, sugiro que o leitor procure ou o livro Practical Guide
to Structured Systems Design, 2 edio, de Meilir Page Jones (YOURDON Press,
Englewood Cliffs, N.J., 1988), ou o livro Struc tured Design, 2 edio, de Ed Yourdon e
Larry Constantine (YOURDON Press, Eng!ewood Cliffs, N.J., 1989).
Os analistas de sistemas veteranos podem ler o primeiro captulo como orientao, e
depois saltar o restante da parte 1; os primeiros sete captulos so bsicos para os novos
estudantes. Os veteranos consideraro familiar boa parte da discusso sobre diagrama de
fluxo de dados, dicionrio de dados e coisas desse tipo; entretanto, o captulo 9 apresenta
extenses de DFD para sistemas de tempo-real que talvez sejam novos para aqueles que
tm trabalhado exclusivamente em sistemas orientados para o comrcio. O estudo sobre
diagramas de entidades- relacionamentos pode ser novo, tambm, para os mais
familiarizados com os diagramas de estruturas de dados, e a discusso sobre os
diagramas de transies de estado no captulo 13 apresenta uma nova ferramenta
importante de modelagem. de grande interesse para os veteranos, os captulos 19 e 20
apresentam uma abordagem para a elaborao do modelo bsico (tambm conhecido
como modelo lgico), que contrasta totalmente com a rgida abordagem top-down
seguida pelos analistas de sistemas durante tantos anos; a abordagem conhecida como
particionamento de eventos, baseada na obra de McMenamin e Palmer. O captulo 17
recomenda que seja eliminada a clssica abor dagem de se modelar o sistema fsico atual
do usurio esse aspecto deve ser estudado atentamente pelos analistas de sistemas cujas
tcnicas estejam baseadas em livros dos anos 70.
Entre os apndices h dois estudos de casos que mostram as diversas ferramentas e
tcnicas discutidas neste livro. O primeiro estudo de caso uma tpica aplicao
orientada para o comrcio baseada nas operaes editoriais da YOURDON Press; o
segundo um exemplo tpico de sistema de tempo-real baseado em um sistema de
controle de elevadores. Ambos so apresentados detalhadamente, embora isso aumente o
tamanho do livro: importante que os estudantes vejam um exemplo completo de uma
especificao. Esses modelos podem ser usados para discusses e exerccios em salas de
aula.
Anlise Estruturada Moderna resultado de muitos anos de experincia com centenas de
clientes de consultoria, milhares de estudantes em seminrios e dezenas de colegas na
YOURDON Inc. e outras organizaes de consultoria; devo muito a essas pessoas,
demasiadamente numerosas para que eu as possa citar pelos nomes. Contudo, h algumas
pessoas que merecem especial ateno, por terem auxiliado a tornar este livro bem
melhor do que poderia ter sido. No se pode escrever um livro hoje em dia sobre anlise
de sistemas sem reconhecer os livros pioneiros de Tom DeMarco, Chris Gane e Trish
Sarson. Sinto-me igualmente agradecido a Steve McMenamin e John Palmer, cuja obra
Essential Systems Analysis representou um impor tante passo frente da primeira
exposio da anlise estruturada; de modo semelhante, Paul Ward e Steve Mellor
apresentaram vrios conceitos e ferramentas de modelagem importantes para sistemas de
tempo-real no conjunto de trs volumes Structured Development for Real-Time Systems.
Fui grandemente beneficiado no ano passado em debates com colegas com os quais
ministrei seminrios sobre anlise estruturada nos Estados Unidos e na Inglaterra: John
Bowen, Julian Morgan, Bob Spurgeon, Nick Mandato e Alex Gersznowicz merecem
agradecimentos especiais por me mostrarem formas eloqentes de explicar os conceitos
de anlise estruturada que eu, certamente, no teria encontrado por mim mesmo.
Paralelamente, o professor Peter Brown e um grupo de seus alunos na Universidade
l)uquesne depuraram o livro utilizando-o como livro texto em um curso sobre anlise de
sistemas;
Captulo 11
Especificaes de Processos . 253
Captulo 12
Diagramas de Entidades-Relacionamentos 289
Captulo 13
Diagramas de Transies de Estado 319
Captulo 14
O Equilbrio dos Modelos 337
Captulo 15
Ferramentas Adicionais de Modelagem 353
Captulo 16
Ferramentas de Modelagem para Gerenciamento de Projetos 375
PARTE ifi
O PROCESSO DE ANLISE
Captulo 17
O Modelo Bsico 391
Captulo 18
O Modelo Ambiental 409
Captulo 19
A Construo do Modelo Comportamental Preliminar 439
Captulo 20
Como Completa: o Modelo Comportamental 453
Captulo 21
O Modelo de Implementao do Usurio .. 465
PARTE IV
PROBLEMAS DE CONTINUIDADE
Captulo 22
A Fase de Projeto 507
Captulo 23
Programao e Testes 527
Captulo 24
A Manuteno das Especificaes 553
Captulo 25
O Futuro da Anlise de Sistemas 563
APNDICES
Apndice A
Ferramentas Automatizadas 579
Apndice B
Diretrizes da Avaliao 605
Apndice C
O Clculo de Custo/Beneficio 623
Apndice D
Caminhamentos (Walkthroughs) e Inspees 645
Apndice E
Tcnicas de Entrevistas e de Coleta de Dados 655
Apndice F
Estudo de Caso: A Yourdon Press .... 671
Apndice G
Estudo de Caso: O Sistema de Elevadores 787
NDI 821

1
INTRODUO

Oprincipio e a finalizao de todos os empreendimentos humanos so desorganizados, a


construo de uma casa, a escrita de uma novela, a demolio de uma ponte e
principalmente, ofim de uma viagem.
John Galsworthy
Over the River, 1933
Neste captulo, aprenderemos:
1. Porque a anlise de sistemas interessante.
2. Porque a anlise de sistemas mais difcil do que a programao.
3. Porque importante estar familiarizado com a anlise de sistemas.
Muito bem, aqui estamos no incio de um longo livro. A perspectiva de ler um livro
tcnico assim to extenso provavelmente o assusta, mas pode servir de consolo o fato de
ser ainda mais aterrorizante quando se comea a escrever um livro assim. Felizmente,
assim como as longas caminhadas ocorrem um dia por vez, e, afinal de contas, a um
passo por vez, os livros extensos so feitos um captulo de cada vez, e, em ltima anlise,
uma sentena de cada vez.

1.1 POR QUE A ANLISE DE SISTEMAS INTERESSANTE?

Os livros longos geralmente so enfadonhos, este no o ser. Ator tunadamente, o assunto


deste livro - anlise de sistemas -
interessante. Na realidade, a anlise de sistemas mais interessante que tudo que
conheo, excetuando, talvez, sexo e certos tipos de vinhos da Austrlia. Ela , sem
dvida, mais interessante que a programao de computadores (no que a programao
seja enfadonha) por envolver o estudo das interaes entre pessoas, entre gn diferentes de
pessoas e entre computadores e organizaes.
Como disse Tom DeMarco em seu ltimo livro, StructuredAnal
and Systems Speqflcation [ 1978],
a anlise [ sistemas] frustrante, repleta de relacionamentos entre pessoas, indefinida e
difcil. Resumindo, fascinante. Depois que voc fisgado, os velhos e fceis prazeres
da construo de sistemas nunca mais sero suficientes para satisfaz-lo.
Isto pode surpreend-lo, no caso de voc ter alguma experincia em escrever programas
de computadores Programar divertido, sendo ainda um desafio intelectual; difcil
imaginar algo mais recompensador e agradvel do que ver um programa ser processado
com sucesso, prin cipalmente depois de despender vrias horas (ou dias!) expurgando-lhe
os erros. difcil imaginar que pode ser ainda mais recompensador e excitante quando
nos afastamos do computador e da programao para estudarmos o sistema completo, do
qual os programas participam. Po rm, no final deste livro, espero t-lo convencido de
que o verdadeiro desafio e a alegria real em trabalhar com sistemas de computadores
consistem em executar a anlise de sistemas.
No importa a profisso que voc decida seguir, ser sempre im portante que voc
compreenda o que a anlise de sistemas. Se voc trabalha na indstria de computadores
em algo diferente da engenharia eltrica ou projeto de hardware, h uma grande
possibilidade de que sua carreira progrida de programador para projetista de sistemas e
da para analista .de sistemas, at que voc finalmente alcance o nvel de gerncia
1.2 A QUEM ESTE LWRO DIRIGIDO
Este livro est sendo escrito para dois tipos de pessoas: uma a novata na rea da anlise
de sistemas, e a outra o analista de sistemas experiente que precisa conhecer as
ferramentas e tcnicas de modela gem de sistemas que evoluiram nos ltimos cinco a dez
anos. Muitos leitores sero estudantes universitrios da cincia dos computadores que
completaram os cursos iniciais de programao e alguns podem ser estu dantes de um
programa de treinamento comercial.
Entretanto, o livro deve ser capaz de ser lido tanto por pessoas que
terminaram seu treinamento universitrio como pelas que j estejam
2
trabalhando na indstria. Muitas pessoas na indstria computacional passam seus
primeiros anos trabalhando como programadores e, depois, so subitamente promovidas
(ou redesignadas) posio de analistas de sistemas, sem serem instrudas sobre o que
seja a anlise de sistemas ou sobre o que faz um analista de sistemas. Se voc estiver
numa situao dessas, este livro para voc. Ele tambm ser-lhe- til no caso de voc
ter comeado a trabalhar como analista de sistemas nos anos 60 ou 70 e nunca teve a
oportunidade de aprender a respeito das tcnicas da anlise estruturada, como diagramas
de fluxo de dados, diagramas de entidades- relacionamentos e dicionrios de dados.
Com mais e mais freqncia hoje em dia, as pessoas estranhas ao computador esto
descobrindo ser necessrio se familiarizar com a rea de anlise de sistemas. Se voc
um homem de negcios ou um gerente (ou um dos profissionais descritos pelo pessoal
da computao como usurios), existe uma boa possibilidade de que voc se envolva em
alguma atividade de anlise de sistemas. Haver analistas de sistemas trabalhando para
voc, despendendo tempo tentando compreender que tipo de sistema automatizado voc
deseja que eles desenvolvam. De forma semelhante, se voc for um administrador,
funcionrio, cientista, poltico ou um contador - ou exerce virtualmente qualquer outra
profis so da sociedade moderna - h grandes possibilidades de que voc venha a gastar
um tempo significativo de sua carreira interagindo com pessoas (analistas de sistemas)
que projetaro e especificaro sofistica dos sistemas aplicativos para voc. Quanto mais
voc souber sobre o que essas pessoas fazem e o que elas esperam de voc, melhor ser.
Mesmo que voc no pretenda trabalhar com um colarinho branco
- isto , mesmo que voc aspire ser um artista, um escritor, um msico ou um atleta -
voc deve saber o que significa a anlise de sistemas. As pessoas em todos os setores da
vida so afetadas pelos sistemas de informaes de todos os tipos. Ainda que voc no
pretenda construir um sistema nem mandar construir um, inevitvel que voc os utilize
em suas contas bancrias, na sua educao, em suas relaes com a Pre vidncia Social e
em praticamente todos os aspectos de suas relaes com a sociedade moderna. Como
John Gall diz em Systemant [ 1977],
Ningum, atualmente, pode evitar o contato com os sistemas. Os sistemas esto em toda
parte: sistemas grandes, sistemas pequenos, sistemas mecnicos e eletrnicos, e os
sistemas especiais compostos por associaes organizadas de pessoas. Como auto-defesa,
pre cisamos aprender a conviver com os sistemas, a control-los para que no nos
controlem. Como disse Humpty Dumpty a Alice (em bora em outro contexto): A questo
: quem dominar - isso tudo.
3
Para enfatizar ainda mais este ponto, lembre-se de que a indstria da computao
representou cerca de 8% do PNB dos Estados Unidos em 1985; por volta de 1990,
espera-se que represente em torno de 15% do PNB Quase tudo o que produzido hoje
pelas empresas americanas tm um ou mais computadores envolvidos em sua produo, e
quase todos os servios oferecidos pelo mercado de negcios americano esto baseados
ou controlados por um sistema de computao.
1.3 OQUE ESTE LWRO FAR POR voc
Como voc j deve ter percebido, um dos maiores objetivos deste livro ensinar-lhe
anlise de sistemas: o que ela e como se lida com ela. Mas no s isso, O meu
verdadeiro propsito entusiasm-lo, torn-lo to interessado em comear a praticar
anlise de sistemas que voc vai querer disparar pelas ltimas pginas do livro e comear
a trabalhar em seu primeiro projeto. Seymour Papert comenta em Mmd storms [ 1980],
Agradam-me especialmente sistemas, como um mecanismo diferen cial, que no
obedecem a uma seqncia linear de causalidades, uma vez que o movimento do eixo de
transmisso pode ser dis tribudo de vrias maneiras diferentes para as duas rodas, depen
dendo da resistncia encontrada. Lembro, de forma vivida, minha excitao em descobrir
que um sistema pode estar sujeito a leis e ser inteiramente compreensvel sem ser
rigidamente determinstico.
E como Sir Arthur Stanley Eddington disse em [ 1987],
Descobrimos que onde a cincia progrediu mais, a mente recuperou
da natureza o que j lhe havia dedicado.
Encontramos uma estranha pegada nas praias do desconhecido. Desenvolvemos
profundas teorias, uma aps a outra, para explicar sua origem. Por fim, obtivemos
sucesso na reconstruo da criatura autora da pegada. E, surpresa! Ela era nossa.
Outro propsito deste livro faz-lo compreender e considerar que vivemos em um
mundo de sistemas - e de sistemas dentro de outros sistemas, que so componentes de
sistemas ainda maiores. Assim, tudo que fazemos em nossa vida pessoal e profissional
tem impacto (muitas vezes imprevisto ou inesperado) nos diversos sistemas de que somos
parte. Esta abordagem de pensar em sistemas no vital apenas para analistas
profissionais de sistemas, mas para todos os membros da sociedade moderna.
4
Infelizmente, este livro no pode transform-lo em um experiente analista de sistemas, do
mesmo modo que um livro sobre teoria musical no pode torn-lo um pianista experiente.
No final do livro, voc dispor de bons conhecimentos tcnicos que o auxiliaro a
desenvolver modelos corretos de sistemas complexos, e voc se tornar conhecedor das
tcni cas passo a passo para executar o esforo da anlise de sistemas. Mas ainda ser
necessrio um grande volume de trabalho no mundo real para conhecer as aptides das
pessoas: como entrevistar usurios de diversos tipos para compreender a verdadeira
essncia de um sistema; como apresentar os resultados do seu trabalho de anlise de
sistemas de forma que todos possam ver os custos e beneficios reais do desenvolvimento
de um novo sistema; como distinguir os problemas dos sintomas. Como disse Barry
Bochm em sua clssica obra, Software Engineering Econo mics [ 1981]:
Cada um de ns, como engenheiros individuais de software, tem uma oportunidade de
fazer um significante impacto positivo na so ciedade, simplesmente por nos tornarmos
mais sensveis s impli caes das relaes humanas de longo alcance de nosso trabalho,
e por incorporarmos essa sensibilidade em nossos projetos e produtos de software.
necessria uma certa prtica para fazer bem isso, e para aprender
a equilibrar os aspectos das relaes humanas com os da pro gramao e com os aspectos
econmicos. O ponto principal a ser
lembrado conservar nossas prioridades firmes entre as conside raes da programao,
oramentrias e humanas.
1.4 A ORGANIZAO DESTE LIVRO
Este livro est organizado em quatro partes principais, seguidas por uma srie de
apndices. A parte 1 serve como apresentao para todo o livro; ela comea, no captulo
2, com uma introduo sobre o conceito de sistemas e sobre a natureza da anlise de
sistemas; nesse captulo, veremos que os sistemas de informao so normalmente
compostos por pessoas, hardware, software (programas de computador), procedimen tos,
dados e informaes. O captulo 3 descreve as pessoas que costu mam estar envolvidas
no desenvolvimento de um moderno sistema de informaes - usurios, gerentes, pessoal
das operaes, membros do grupo de controle da qualidade, entre Outros - bem como o
papel es pecial e as responsabilidades do analista de sistemas. O captulo 4 apre senta as
ferramentas de modelagem usadas pelo analista de sistemas, como os diagramas de fluxo
de dados, de entidades-relacionamentos e os de transies de estado. O captulo 5
apresenta os procediMentos (ou
5
metodologia) seguidos pelo analista de sistemas no desenvolvimento de um sistema.
Mesmo que voc ache que j conhece muitos desses assuntos, alguns captulos da parte 1
devem ser udos, porque do o tom para o restante do livro. O captulo 2, por exemplo,
apresenta e analisa os axio mas e princpios bsicos que podemos encontrar em todo o
trabalho da anlise de sistemas: o desenvolvimento de modelos de sistemas, a noo de
iterao, e a noo da subdiviso top-down. O captulo 6 delineia os principais problemas
que se apresentam aos analistas de sistemas atualmente: produtividade, qualidade dos
sistemas, manutenibilidade e o uso estratgico das informaes. Por fim, o captulo 7
resume as prin cipais modificaes ocorridas na rea da anlise dc sistemas nos ltimos
dez anos.
A parte II discute detalhadamente as ferramentas de modelagem de sistemas. H captulos
sobre diagramas de fluxo de dados (captulo 9), dicionrios de dados (captulo 10),
especificaes de processos (captulo 11), diagramas de entidades-relacionamentos
(captulo 12) e diagramas de transies de estado (captulo 13). Os captulos 15 e 16
abordam diversas outras ferramentas de modelagem usadas pe los analistas no estudo de
um sistema: diagramas PERT, diagramas de Gantt, fluxogramas, diagramas HIPO,
diagramas estruturais etc. Como veremos, essas ferramentas permitem a focalizao
scletiva em aspec tos isolados de um sistema cujas caractersticas sejam importantes. para
serem compreendidas: as funes que o sistema deve desem penhar, os dados que ele
deve controlar e seu comportamento tempo- dependente.
Mesmo que voc nunca veja um computador depois de ler este livro, as ferramentas de
modelagem da parte II ser-lhe-o teis no que quer que voc faa. Voc descobrir que
essas ferramentas podem ser teis para modelar (ou descrever) virtualmente qualquer tipo
de sistema:
sistemas biolgicos comerciais, ecossistemas, industriais, polticos, de fluxo de materiais
etc. Vivemos em um mundo de sistemas, e boa parte de nossa vida passada tentando
entender e lidar com os inmeros sistemas diferentes; as ferramentas de modelagem so
extremamente teis nesse aspecto.
A parte III refere-se ao processo da anlise de sistemas - isto , as etapas seguidas pelo
analista de sistemas na construo de um modelo de sistema. Ali, tambm, as
informaes que voc receber sero teis, independentemente da sua profisso; mas o
contedo definitivamente dirigido para a constm de sistemas automatizados de
informaes. Veremos que o processo ou metodologia da construo de um sistema
envolve o desenvolvimento de vrios tipos diferentes de modelos, dos quais o ltimo o
produto ou a sac da anlise de sistemas. Em muitas organizaes comerciais, esse
produto conhecido por nomes como
6
especificao funcional, ou definio de requisitos do sistema ou projeto do
sistema. Qualquer que seja o nome adotado, ele se torna a entrada para o responsvel
pela construo real do sistema - isto , pelo projeto da arquitetura geral do hardware e
software e, em ltima anlise, pela escrita e pelos testes dos programas do sistema.
Isso conduz parte IV: o que ocorre depois da anlise de sistemas. Examinaremos a
transio da anlise de sistemas para o projeto de siste mas e discutiremos resumidamente
os detalhes finais da programao e dos testes. Como a maioria dos sistemas
automatizados de informaes tem um tempo de vida de alguns anos (e muitas vezes de
algumas dcadas), estudaremos tambm a manuteno no captulo 24; porm nosso
interesse no ser a programao de manuteno, e, sim, a manu teno do produto da
anlise de sistemas. O captulo final trata do futu ro: as alteraes evolutivas na rea da
anlise de sistemas que esperamos presenciar nos anos 90 e no prximo sculo.
Os apndices no final do livro abordam problemas que podem ou no afetar seu trabalho
como analista de sistemas. O apndice A, por exemplo, trata do problema de estaes
automatizadas de trabalho baseadas em PC para a anlise de sistemas - ao qual poucos
analistas de sistemas tm acesso no final dos anos 80, mas que se tornar progres
sivamente comum nos anos 90. O apndice B discute frmulas de avalia o e mtricas
utilizadas para calcular o tamanho, a durao e o custo de um projeto. O apndice C
mostra os aspectos econmicos dos clculos de custo-beneficio. O apndice D abrange o
assunto dos caminhamentos (walkthroughs) e inspees, que so utilizadas
freqentemente na revi so dos produtos tcnicos da anlise de sistemas. O apndice E
discute as tcnicas de entrevistas e de coleta de dados, principalmente as entre vistas do
usurio com o analista de sistemas. Todos esses assuntos foram organizados em
apndices de modo a que os analistas experientes pos sam salt-los com facilidade e os
principiantes possam recorrer a eles sempre que for necessrio consultar tpicos que, com
certeza, emergiro durante os projetos do mundo real.
Os apndices F e G apresentam dois estudos de caso: um deles um sistema orientado
para a rea comercial, e o outro um sistema de tempo-real. Se voc um estudante
novato, deve, ao final de cada cap tulo, examinar esses estudos de caso para ver como
esses recm-apren didos princpios podem ser aplicados a situaes do mundo real. Na
realidade, voc deve ler a introduo e o histrico de cada estudo de caso para se
familiarizar com a natureza de cada aplicao. Cada captulo tem algumas perguntas e
exerccios para ajud-lo a rever o que foi estu dado. Alguns exerccios so rotulados
como Projeto de Pesquisa, o que significa que apresentam problemas no mencionados
diretamente no captulo mas que so relevantes no mundo real da anlise de sistemas.
Certas perguntas so dirigidas para discusso em sala de aula; no h
7
respostas certas ou erradas, embora haja respostas mais defensveis que outras!
Chega de introdues. Vamos dar a partida! Comearemos falando
a respeito da natureza dos sistemas.
REFERNCIAS
1. Tom DeMarco, Structured Analysis and Systems Speqfzcation. Englewood Cliffs, N.J.:
Prentice-Hall, 1979, pgina 6.
2. John Gal!, Systemantcs. Nova lorque: Quadrangle/The New York Times Book
Company, 1977, pgina xiii.
3. Barry Boehm, Software Engineering Economics. Englewood Cliffs, N.J.: Prentice-
Hall, 1981.
4. Seymour Papert, Mindstorms. Nova lorque: Basic Books, 1980.
5. Edward Yourdon, Nations at Risk. Englewood Cliffs, N.J.:
YOURDON Press, 1986
6. Sir Arthur Stanley Eddington, Space, Time and Gravitation: An Outline of tbe General
Theo?y. Londres: Cambridge University
Press, 1987.
PERGUNTAS E EXERCCIOS
1. Explique como a anlise de sistemas pode ser til em seu trabalho ou profisso mesmo
que voc no pretenda se tornar um pro gramador ou analista de sistemas.
2. Projeto de Pesquisa: quantas pessoas, atualmente, esto emprega das como analistas de
sistemas no Brasil? Qual .0 salrio mdio
dessas pessoas? Qual o nvel mdio de educao delas?
3. Projeto de Pesquisa: existe uma carncia de programadores e analistas de sistemas no
Brasil? Tente encontrar pesquisas que indiquem as necessidades desses profissionais para
o pas para os prximos dez anos.
4. D dez exemplos de sistemas com que voc lida ou interage em seu dia a dia.
5. Voc estudaria anlise de sistemas no caso de ainda no o ter feito? Se a sua resposta
for no, explique porque o assunto no ser til ou relevante. Encontre algum que
esteja estudando esse mesmo assunto e inicie um debate construtivo a respeito da
utilidade geral da anlise de sistemas.
6. Voc considera ser importante para as pessoas fora da rea da computao (pessoas que
no trabalham na rea da computa o como profisso) estudarem anlise de sistemas?
Quo
8
respostas certas ou erradas, embora haja respostas mais defensveis que outras!
Chega de introdues. Vamos dar a partida! Comearemos falando
a respeito da natureza dos sistemas.
REFERNCIAS
1. Tom DeMarco, Structured Analysis and Systems Spe Englewood Cliffs, N.J.: Prentice-
Hall, 1979, pgina 6.
2. John GalI, Systemantics. Nova lorque: Quadrangle/The New York Times Book
Company, 1977, pgina xiii.
3. Barry Boehm, Software Engineerng Economics. Englewood Cliffs, N.J.: Prentice-
Hall, 1981.
4. Seymour Papert, Mindstornjs. Nova Jorque: Basic Books, 1980.
5. Edward Yourdon, Nations at Risk. Englewood Cliffs, N.J.:
YOURDON Press, 1986
6. Sir Arthur Stanley Eddington, Space, Time and Gravitation An Outline of the General
Theoty. Londres: Cambridge University
Press, 1987.
PERGUNTAS E EXERCCIOS
1. Explique como a anlise de sistemas pode ser til em seu trabalho ou profisso mesmo
que voc no pretenda se tornar um pro gramador ou analista de sistemas.
2. Projeto de Pesquisa: quantas pessoas, atualmente, esto emprega das como analistas de
sistemas no Brasil? Qual ,o salrio mdio
dessas pessoas? Qual o nvel mdio de educao delas?
3. Projeto de Pesquisa: existe uma carncia de programadores e analistas de sistemas no
Brasil? Tente encontrar pesquisas que indiquem as necessidades desses profissionais para
o pas para os prximos dez anos.
4. D dez exemplos de sistemas com que voc lida ou interage em seu dia a dia.
5. Voc estudaria anlise de sistemas no caso de ainda no o ter feito? Se a sua resposta
for no, explique porque o assunto no ser til ou relevante. Encontre algum que
esteja estudando esse mesmo assunto e inicie um debate construtivo a respeito da
utilidade geral da anlise de sistemas.
6. Voc considera ser importante para as pessoas fora da rea da computao (pessoas que
no trabalham na rea da computa o como profisso) estudarem anlise de sistemas?
Quo
8
1
conhecedoras do assunto voc acha que elas seriam?
7. Por que a anlise de sistemas parece ser mais interessante que a
programao? Voc concorda com este ponto de vista?
8. O que um analista de sistemas deve aprender alm do conheci
mento tcnico de construir modelos de sistemas?
9. Por que as ferramentas de modelagem do tipo apresentado neste
livro podem ser teis no estudo de sistemas no-computacionais?
NOTAS
Se voc tem menos de 30 anos de iiade, e difcil imaginar que nunca escreveu um
programa de computador, pois quase todas as escolas e colgios agora ensinam alguma
coisa a respeito de programao de computadores. Porm, possvel que voc no tenha
escrito um programa realmente complicado. Se voc no levou pelo menos um ms
trabalhando no mesmo programa - 16 horas por dia, sonhando com ele nas 8 horas
restantes de sono intranqilo, passando vrias noites em claro, tentando eliminar aquele
ltimo erro do programa - ento voc ainda no escreveu realmente um programa
complicado. E pode no ter a sensao de que existe algo divertido em programar (a
propsito, todos na indstria lhe diro que no se deve construir programas grandes e
complexos - e que o objetivo do jogo construir
programas simples e compreensveis. Isto verdade: mas imagine
a energia mental e as noites insones gastas na criao e no desen
volvimento de algo como o programa MacPaint da Macintosh, ou a
primeira verso do Lotus 1-2-3).
2 Existem diversas outras carreiras que podem ser seguidas. Voc
pode se especializar na rea de telecomunicaes e projeto de
redes; ou pode concentrar-se no projeto de bancos de dados ou
administrao de dados. Embora a maior parte deste livro
presuma que voc se ocupe com sistemas aplicativos (folhas de
pagamento, inventrios, contabilidade ou aplicaes de tempo-
real, como orientao de msseis, comutao telefnica e controle
de processos), voc pode ocupar-se tambm, com projetos de
programao de sistemas - compiladores ou sistemas opera
cionais, por exemplo. Tudo isso possivelmente representa seu
segundo ou terceiro emprego na indstria da computao: voc
deve, provavelmente, comear como programador jnior (quando
se espera que voc saiba escrever programas relativamente
simples, ou fazer modifIcaes em programas j existentes), depois
passar a programador snior, antes dc, finalmente, ascender
posio de analista de sistemas. Nessa posio, voc dever ter
9
maiores habilitaes que um programador: alm do conhecimcni
do hardware e do software do computador, voc deve ser capaz de
se comunicar com pessoas leigas em computao e estar familia
rizado com as aplicaes comerciais dessas pessoas.
3 Para maiores detalhes sobre esse assunto e para mais explicaes
sobre o impacto dos computadores na sociedade, veja Nations at
Risk EYourdon, 19861.
10
2
A NATUREZA
DOS SISTEMAS
Finalmente colocaremos o prprio Sol no centro do Universo. Tudo isso sugerido pela
sequncia sistemtica de eventos e pela harmonia de todo o Universo, se encararmos os
fatos, como se costuma dizer, com os olhos abertos
Nicolau Coprnico
De Revolutionibus Orbium Coelestium, 1543
Neste captulo, aprenderemos:
1. O que definio de um sistema.
2. A diferena entre sistemas naturais e sistemas feitos pelo homem.
3. Os 19 principais subsistemas encontrados em todos os sistemas vivos.
4. As cinco principais razes por que alguns sistemas no devem ser automatizados.
5. Os cinco principais componentes de um sistema au tomatizado de informaes tpico.
6. A definio e as caractersticas de diversos tipos es pecficos de sistemas.
7. A definio e trs exemplos de princpios gerais de sistemas.
No podemos falar muito sobre anlise de sistemas enquanto no
tivermos uma clara idia do que seja um sistema; este o propsito des te captulo. Como
veremos, existe uma definio oficial do termo no
11
dicionrio, que parecer bastante abstrata. Existem, porm, muitos usos comuns do termo
que lhe parecero perfeitamente familiares, e existem muitos tipos comuns de sistemas
com que temos contato todos os dias.
E da?, voc pode estar perguntando a si mesmo. importante estar familiarizado com
diferentes espcies dc sistemas por pelo menos dois motivos. Primeiro, mesmo que seu
trabalho como analista se con centre em um tipo de sistema - um sistema automatizado de
informa es, computadorizado - ele normalmente far parte de um sistema maior. Desse
modo, voc pode estar trabalhando em um sistema de pagamentos, que parte de um
sistema maior de recursos humanos, que, por sua vez, parte da organizao comercial
geral (que constitui um sistema), que , por sua vez, componente de um sistema
econmico geral, e assim por diante. Ou voc pode estar trabalhando cm um siste ma de
controle de processos que parte de uma refinaria qumica, ou em um sistema
operacional que seja parte de um pacote de software de sistemas distribudo por
vendedores. Assim, para que o seu sistema tenha sucesso, preciso conhecer os outros
sistemas com os quais ele vai interagir.
Muitos dos sistemas de computadores que elaboramos so substi tuies ou novas
implementaes de sistemas no-computadorizados que j existem; alm disso, a maioria
dos sistemas computadorizados interage ou tem uma interface com vrios sistemas
existentes (alguns podem ser computadorizados e outros no). Para que nosso sistema
computadorizado seja bem-sucedido, precisamos conhecer, detalhada- mente, como o
sistema atual se comporta.
Em segundo lugar, embora muitos tipos de sistemas paream ser totalmente diferentes,
eles tm muitas semelhanas; existem princpios comuns, filosofias e teorias que se
aplicam notavelmente bem a virtual mente todos os tipos de sistemas. Assim, podemos
muitas vezes aplicar o que aprendemos sobre outros sistemas - com base em nossa
experin cia diria, bem como na experincia de cientistas e engenheiros em diversas
reas - aos sistemas que elaboramos na rea da computao. Por exemplo, um dos
importantes princpios de sistemas que primeiro foi obser vado no campo da biologia
conhecido como a lei da especia lizao; quanto mais adaptado for um organismo a um
determinado ambiente, mais dificil ser para esse organismo a adaptao a outro. Isso
ajuda a explicar o desaparecimento dos dinossauros quando o clima da Terra modificou-
se radicalmente ajuda, tambm, aos analistas de siste mas a compreenderem que se
otimizarem um sistema computadori zado de forma a tirar a mxima vantagem dc uma
determinada UCP, de uma linguagem de programao e de um sistema de gerenciamento
de banco de dados, podero vir a ter srios problemas em adaptar o sistema para ser
processado em outra UCP ou com um diferente sistema de gerenciamento de banco de
dados 2
12
Dessa maneira, se conhecermos alguma coisa da teoria geral dos sistemas, ela pode nos
ajudar a compreender melhor os sistemas compu tadorizados (automatizados) de
informaes. Isso cada dia mais impor tante, pois queremos construir sistemas estveis
e confiveis, que funcionaro bem em nossa complexa sociedade - e h, naturalmente,
muitos sistemas no-computadorizados que vm sobrevivendo por mi lhes de anos: a
humilde barata provavelmente sobreviver a iodos os sistemas computadorizados j
construdos ou a construir, e a toda a humanidade, tambm.
Assim, vamos comear com uma definio do termo bsico siste ma. Todos os livros
sobre algum aspecto de sistemas contm essa defi nio; eu escolhi o Websters New
Coilegiate Dictionary . Ele a vrias definies:
1. um grupo de itens que interagem entre si ou que sejam inter dependentes, formando
um todo unificado < - numrico>
como
a. (1) um grupo de corpos que interagem entre si sob a in fluncia de foras relacionadas
< - gravitacional >
(2) uma mistura de substncias em equilbrio ou que tende para o equilbrio < -
termodinmico >
b. (1) um grupo de rgos do corpo que desempenham, em conjunto, uma ou mais
funes vitais < o - digestivo>
(2) o corpo, considerado como uma unidade funcional.
c. um grupo de objetos ou foras naturais relacionados entre si <um - fluvial>
d. um grupo de dispositivos ou uma organizao em rede, principalmente para a
distribuio de algum produto ou servindo a um propsito comum <um - telefnico >
<um
- de aquecimento > < um - rodovirio > < um - de processamento de dados>
2. um conjunto organizado dc doutrinas, idias ou princpios, habitualmente previsto para
explicar a organizao ou o fun cionamento de um conjunto sistemtico < o - da
mecnica newtoniana >
3. a. um procedimento organizado ou estabelecido < o - de toques da digitao>
13
b. uma maneira de classificar, simbolizar ou esquematizar < um - taxonmico > < o -
decimal>
4. organizao harmoniosa ou modelo: ORDEM
5. sociedade organizada ou situao social vista como inde sejvel:
ESTABLISHMENT
2.1 TIPOS COMUNS DE SISTEMAS
Como se pode depreender da definio acima, existem muitos ti- pos diferentes de
sistemas; na verdade, quase tudo aquilo com que te mos contato em nossa vida ou um
sistema ou um componente de um sistema (ou ambas as coisas).
Significa que devemos estudar todos os tipos de sistemas, ou pre tender nos tornarmos
peritos em sistemas sociais, sistemas biolgicos e sistemas de computao? Claro que
no! Entretanto, conveniente organizar os diferentes tipos de sistemas cm categorias.
Muitos agru pamentos diferentes so possveis; na realidade, a definio do dicio nrio no
incio deste captulo apresenta uma classificao em categorias. Como nosso interesse
principal so os sistemas de processamento, vamos comear por dividir todos os sistemas
em duas categorias: siste mas naturais e sistemas feitos pelo homen
2.2 SISTEMAS NATURAIS
A maioria dos sistemas no feita por pessoas. Eles so encontra dos na natureza e, de
modo geral, servem a seus prprios propsitos. conveniente dividir esses sistemas em
duas suhcatcgorias bsicas: siste mas fisicos e sistemas vivos. Os sistemas fsicos
incluem exemplos to diferentes como:
Sistemas estelares: galxias, sistemas solares etc.
Sistemas geolgicos: rios, cadeias de montanhas etc.
Sistemas moleculares: organizaes complexas de tomos.
Os sistemas fsicos so interessantes de serem estudados porque, como humanos
intrometidos que somos, por vezes tentamos modific los. Desenvolvemos, tambm,
diversos sistemas, incluindo-se a os siste mas em computadores, que devem interagir
harmoniosamente com os
14
sistemas fsicos; dessa forma importante estarmos capacitados a mode lar esses sistemas
para nos assegurarmos que os entendemos to bem quanto possvel.
Os sistemas vivos, naturalmente, abrangem as mirades de animais e plantas em volta de
ns e tambm a espcie humana. E, como afirma James Miller em sua monumental obra,
Living Systems [ 1978], essa categoria tambm inclui hierarquias de organismos vivos
individuais, como ervas, rebanhos, tribos, grupos sociais, empresas e naes.
O estudo dos sistemas vivos j uma carreira por si prprio; uma rpida leitura da obra
de Miller permite que se perceba a extenso desse tema. O propsito deste livro no o
estudo dos sistemas vivos per se; no obstante, algumas das propriedades e caractersticas
dos sistemas vivos conhecidos podem ser utilizadas para auxiliar a ilustrar e melhor
compreender os sistemas feitos pelo homem. Muitas vezes usamos uma analogia para
entendermos melhor algo pouco familiar; entre os mais eloqentes exemplos de sistemas
vivos empregados como analogias para sistemas comerciais e organizacionais esto Brain
of the Firm de Stafford Beer [ 19721 e Tbe Heart ofEntetprise [ 19781.
Pode-se encontrar uma analogia mais elaborada no agrupamento em categorias dos 19
principais subsistemas vivos feitos por Miller. Ele argumenta que os sistemas viventes,
em nvel de clula, de rgo, de organismo, de grupo, de organizao, de sociedade ou de
sistemas inter nacionais, contm, todos, os seguintes subsistemas:
O reprodutor, que capaz de dar origem a outros sistemas se melhantes ao que ele
pertence. Em uma organizao comercial, pode ser a diviso de planejamento, que faz
novas plantas e constri novos escritrios regionais.
O delmitador que mantm coesos os componentes do sistema, que os protege dos
problemas ambientais e que impede ou permite a entrada de vrios tipos de matria-
energia e infor maes. Em uma organizao comercial, poderia consistir nas instalaes
fsicas (prdio do escritrio, fbrica etc.) e dos guar das e outros elementos da segurana
que impedem intruses no desejadas.
O ingestor, que introduz matria-energia atravs dos limites do sistema a partir do seu
ambiente. Em uma organizao comer cial, pode ser representado pelo departamento de
recebimentos ou de compras, que traz produtos in natura, material de escritrio e coisas
afins. Pode ser constitudo tambm pelo de partamento de entrada de pedidos, que recebe
pedidos verbais e escritos para os produtos e servios da empresa.
15
O distribuidor, que transporta entradas de fora do sistema ou sadas dos subsistemas em
torno do sistema para cada compo nente. Em uma organizao comercial, podem ser as
linhas telefnicas, o correio eletrnico, os mensageiros, correias trans- portadoras e vrios
outros mecanismos.
O conversor, que modifica certas entradas do sistema em formas mais adequadas para
os processos desse sistema em particular. Pode-se imaginar muitos exemplos disso em
uma organi7ao comercial tpica.
O produtor, que forma associaes estveis que garantem, du rante significativos
perodos entre entradas de matria-energia no sistema ou entre as sadas do conversor, o
material sinteti zado para crescimento, reparo dos danos ou substituio dos componentes
do sistema, ou destinado ao fornecimento de energia para movimentar ou compor as
sadas de produtos ou informaes de mercado para seu sistema de nvel superior.
O subsistema de ar de matria-enei que con serva no sistema, por diferentes perodos de
tempo, depsitos
de vrios tipos de matria-energia.
O extravasor, que envia matria-energia para fora do sistema sob a forma de produtos
ou resduos.
O moaor, que move o sistema ou setores dele em relao a uma parte do ambiente ou
todo ele ou move componentes relativa mente um ao outro.
O suportador, que mantm o correto relacionamento espacial entre os componentes do
sistema, de modo a que eles possam interagir sem vantagens uns sobre os outros ou sem
inter ferncias fsicas.
O tran.sdutor de entrada, que traz marcadores com informaes para o sistema,
modificando-os para outras formas de matria-
energia adequadas para transmisso em seu interior.
O transdutor Interno, que recebe, de outros subsistemas ou componentes do sistema,
marcadores com informaes sobre al teraes importantes nesses subsistemas ou
componentes, modificando-os para outras formas de matria-energia que pos sam ser
transmitidas em seu interior.
16
O canal e a rede, que se compem de uma nica via no espao fsico, ou de mltiplas
vias interligadas, pelas quais os marca dores com informaes so transmitidos para todas
as partes do sistema.
O decod que modifica o cdigo da entrada de informa es para ele, por intermdio do
transdutor de entrada ou do transdutor interno, em um cdigo privativo que pode ser utili
zado internamente pelo sistema.
O associador, que executa o primeiro estgio do processo de aprendizado, formando
associaes durveis entre os itens de
informao do sistema.
A memria, que executa o segundo estgio do processo de aprendizado, armazenando
diversos tipos de informaes no
sistema por diferentes perodos de tempo.
O decididor, que recebe entradas de informaes de todos os outros subsistemas e lhes
transmite sadas de informaes que
controlam todo o sistema.
O cod que modifica o cdigo das entradas de informa es para ele a partir de outros
subsistemas de processamento de informaes, de um cdigo privativo de utilizao
interna do sistema para um cdigo que possa ser interpretado por outros sistemas do
ambiente.
O transdutor de sada, que extrai do sistema marcadores com informaes, modificando
esses marcadores dentro do sistema em outras formas de matria-energia que podem ser
transmiti das pelos canais no ambiente do sistema.
As figuras 2.1 (a) e 2.1 (b) mostram um exemplo dos 19 principais subsistemas da equipe
de comunicaes de um moderno vapor; as figu ras 2.2 (a) e 2.2 (b) apresentam os
principais subsistemas do prprio navio e as figuras 2.3 (a) e 2.3 (b) mostram os
principais subsistemas de toda a Holanda. Esses modelos so vlidos por demonstrarem
que, ao examinarmos um sistema com componentes vivos, podemos encontrar os
principais subsistemas.
Lembre-se que muitos sistemas feitos pelo homem (e os automati zados) interagem com
os sistemas vivos - por exemplo, os marca-pas sos computadorizados interagem com o
corao humano. Em alguns casos, os sistemas automatizados estio sendo projetados para
substituir
17
sistemas vivOs; e em outros casos, os pesquisadores consideram os sistemas viventes
(conhecidos como computadores orgnicos) como componentes de sistemas
automatizados. Estudos sobre esse ponto de vista podem ser encontrados em [ 19831,
[ Young, 1983], [ 19851 e [ 1984]. Os sistemas vivos e os feitos pelo homem so, muitas
vezes, parte de um metassistema maior e quanto mais soubermos acerca deles melhores
analistas de sistemas seremos.
2.3 SISTEMAS FEITOS PELO HOMEM
Como vimos pela definio no incio deste captulo, alguns siste mas so construdos,
organizados e mantidos por seres humanos. Entre
eles podemos considerar:
Sistemas sociais: organizaes de leis, doutrinas, costumes etc.
Uma coleo organizada e disciplinada de idias: o sistema deci mal Dewey para a
organizao de livros em bibliotecas, o sis tema Weight-Watcher para perda dc peso etc.
Os sistemas de transporte: redes rodovirias, canais, linhas areas, petroleiros, e
semelhantes.
Sistemas de comunicaes: telefone, telex, sinais de fumaa, si nais manuais utilizados
pelos comerciantes atacadistas etc.
Sistemas de manufatura: fbricas, linhas de montagem etc.
Sistemas financeiros: contabilidade, inventrios, livros-razo, controle de estoques,
entre outros.
Hoje, a maioria desses sistemas usa computadores; na verdade, muitos deles no
poderiam sobreviver sem os computadores. Contudo, tambm importante ressaltar que
esses sistemas j existiam antes que surgissem os computadores; alguns deles, na
realidade, no esto ainda totalmente computadorizados e podem permanecer assim por
muitas dcadas mais. Outros contm um computador como componente, mas contm
tambm um ou mais componentes no-computadorizados (ou manuais).
Considere, por exemplo, a frase Joo possui um sistema que faz esse servio ou Maria
certamente tem um modo sistemtico de fa zer seu trabalho. Tais frases no implicam
necessariamente em que Maria tenha computadorizado seu trabalho ou que Joo tenha
utilizado
18
algumas das ferramentas formais de modelagem discutidas nos captulos 9 e 10 para
documentar (ou modelar) a maneira como ele pretende executar sua tarefa. Essas frases,
no entanto, certamente implicam em que Joo e Maria dividiram o servio em uma srie
de etapas separadas, cuja combinao cumpre algum propsito geral.
A questo de se um sistema feito pelo homem deve ou no ser computadorizado ser
discutida atravs de todo este livro; l no algo que deva ser tomado por certo. Como
analista de sistemas, voc naturalmente pressupe que todo sistema com que voc tiver
contato dever ser computadorizado; e o cliente ou usurio (o dono do sistema em
questo) com quem voc interagir imaginar geralmente que voc tenha tal inteno.
Como veremos nos prximos captulos, sua principal tarefa como analista de sistemas
ser analisar ou estudar o sistema para determinar-lhe a essncia: seu comportamento
exigido independente mente da tecnologia utilizada em sua implementao . Na maioria
dos casos, s estaremos em situao de decidir se faz sentido usar um com putador para
executar as funes do sistema depois de modelarmos seu comportamento bsico.
Por que alguns sistemas de informao no devem ser automati zados? Pode haver muitas
razes, mas aqui esto algumas das mais
comuns:
Custo pode ser mais barato continuar executando as funes do sistema e armazenando
as informaes manualmente. Nem sempre verdade que os computadores sejam mais
rpidos e mais baratos do que o modo antigo.
Conforto - um sistema automatizado pode ocupar espao em demasia, fazer excessivo
rudo, gerar muito calor ou consumir eletricidade demais ou, em termos gerais, a presena
de um deles pode ser uma dor de cabea. Isso est se tornando menos verdadeiro com a
penetrante influncia dos microprocessadores mas ainda um fator a considerar.
Segurana - se o sistema de informaes mantm dados im portantes e confidenciais, o
usurio pode achar que um sistema automatizado no seja suficientemente seguro,
podendo preferir manter a capacidade de conservar as informaes fisicamente protegidas
debaixo de chave.
Manutenibilidade - o usurio pode argumentar que um sis tema computadorizado de
informaes poderia ser econmi co, s que no h ningum na organizao que possa
manter o hardware e/ou o software do computador, de forma que
19
ningum estaria capacitado a reparar o sistema no caso de um defeito e no haveria quem
pudesse efetuar modificaes e melhoramentos.
PolUica - a comunidade de usurios pode achar que os com putadores so uma ameaa
a seus empregos ou que tornam seu trabalho tedioso e mecnico, ou podem ter uma
dzia de outras razes que o analista de sistemas pode considerar como irracionais. Mas
como o sistema pertence aos usurios, a opinio deles est acima de tudo. Se eles no
desejarem um sistema automatizado, faro o que for possvel para que o sistema fra casse
caso ele lhes seja imposto.
2.4 SISTEMAS AUTOMATIZADOS
A maior parte deste livro dedicada aos sistemas automatizados, isto , sistemas feitos
pelo homem, que interagem com ou so controla dos por um ou mais computadores. Voc
certamente j deve ter visto muitos exemplos diferentes de sistemas automatizados em
sua vida:
parece mesmo que quase todos os aspectos de nossa sociedade moder na esto
computadorizados. Como resultado, podemos distinguir muitos tipos diferentes de
sistemas automatizados.
Embora haja muitos tipos diferentes de sistemas automatizados,
todos tm componentes comuns:
Hardware de computadores - UCP, terminais, impressoras, uni dades de fitas magnticas
etc.
Software de computadores - programas de sistemas, como sis temas operacionais,
sistemas de bancos de dados e programas de controle de telecomunicaces, alm dos
programas aplicati vos que executam as funes desejadas pelo usurio.
Pessoas - aquelas que operam o sistema, que fornecem as en tradas e utilizam as sadas,
e as que desempenham atividades de
processamento manual em um sistema.
Dados - as informaes que o sistema conserva por um perodo de tempo.
Procedimentos - determinaes e instrues formais para a operao do sistema.
20
Subsistemas que processam matria-energia e informaes: Delimitador (Dl), parede da
estao-rdio (objeto).
Subsistemas que processam matria-energia: Ingestor (IN), garonete que leva alimentos
da cozinha para a estao-rdio; Distribuidor (DI), garom que entrega alimentos aos
membros da equipe de comunicaes; Conversor (CO), garom que corta po, carne e
queijo para sanduches; Produtor (PIO, garom que prepara sanduches e caf;
Armazenamento de Matria-Energia (AM), garom que armazena diversos tipos de
material, inclusive comida no refrigerador, casacos e chapus dos membros da equipe no
armrio, cobertores e travesseiros tambm no armrio e ferramentas e equipamentos na
cmoda; Extravasor (EX), garom que retira pratos sujos, papis usados e outros
materiais inteis da estao-rdio; Suportador (SU), cho, paredes, teto e moblia da
estao-rdio (objetos).
Subsistemas que processam informaes: Transdutor de Entrada (te), rdio- operador que
recebe mensagens pelo rdio; Transdutor Interno (ti), tripulante de servio no dia, que
apresenta relatrios ao encarregado das comunicaes a respeito da eficincia e do moral
dos membros da equipe durante seu servio; Canal e Rede (cr), todos os membros do
grupo que se intercomunicam ver balmente atravs do ar da estao-rdio; Decodificador
(dc), rdio-operador que transcreve em linguagem legvel as mensagens recebidas em
cdigo morse; Memria (me), secretrio que conserva o registro de todas as mensagens re
cebidas e transmitidas; Decididor (de), oficial encarregado das comunicaes, que chefia
a equipe de comunicaes; Codificador (cO, rdio-operador que codifica mensagens
claras em cdigo morse; Transdutor Externo (tx), rdio- operador que transmite
mensagens pelo rdio.
Figura 2.1(a): Subsistemas da equipe de comunicaes de um namo.
Uma maneira de classificar os sistemas automatizados feita pela aplicao: sistemas
industriais, sistemas de contabilidade, sistemas de defesa militar etc. Entretanto, isso no
ser muito til j que as tcnicas que discutiremos neste livro para analisar, modelar,
projetar e implemen tar sistemas automatizados so geralmente as mesmas, qualquer que
seja a aplicao .
21
7
i
F1gu 2.1 (b): Subsig de
uma equijie de comunicaj de um natio
4
00
f
0
to
1
0
22
Subsistemas que processam matria-energia e informaes: Reprodutor (Re), que
representa a organizao proprietria; Delimitador (Di), o casco do navio e o pessoal que
o guarda e trata de sua manuteno.
Subsistemas que processam matria-energia: Ingestor (IN), escotilhas para o interior do
navio e o pessoal que embarca passageiros, bagagens, e cargas; Distribuidor (DI),
passagens,conveses, escadas e camareiros, garons e carrega dores que por eles
transportam alimentos, bebidas, bagagens e vrios outros tipos de matria-energia, bem
como os passageiros que se movimentam por eles pelo navio; Conversor (CO), pessoal da
cozinha, que prepara vegetais e outros ai imentos para cozimento; Produtor (PR),
cozinheiros que preparam as refeies e padeiros que fazem po na cozinha do navio;
Armazenamento de Matria- Energia (AM), pores e tanques de combustvel do navio e
o pessoal responsvel por eles; Extravasor (EX), chamin para eliminao de resduos
gasosos, disposi tivos de descarga de lixo e esgoto para resduos lquidos e slidos e o
pessoal en carregado de verificar se esses resduos esto sendo adequadamente
eliminados; Motor (MO), mquinas, eixo propulsor, hlices e todo o casco do navio, que
transportam passageiros, tripulao e carga pelo mar, bem como os maquinistas
responsveis pela movimentao do navio; Suportador (SU), casco, bordos, anteparas
(paredes) e conveses do navio e o pessoal encarregado da manuteno desses elementos.
Subsistemas que processam informaes: Transdutor de Entrada (te), rdio- operador e
outros membros da equipe de comunicaes que recebem men sagens para o navio;
Transdutor Interno (ti), oficial que informa ao oficial mais graduado do servio sobre o
estado de diversos componentes do navio; Canal e Rede (cr), o ar entre os oficiais de
servio no passadio do navio, pelo qual eles transmitem e recebem mensagens;
Decodificador (dc), rdio-operador, da equipe de comunicaes, que decodifica
mensagens em cdigo Morse para linguagem clara, depois de serem recebidas; Memria
(me), livros de registro de viagens anteriores, cartas nuticas e o pessoal que as consulta
no compartimento de cartas; Decididor (de), o Comandante e outros oficiais do navio;
Codificador (cO, rdio-operador, da equipe de comunicaes, que codifica mensagens em
lin guagem clara para o cdigo morse para poder transmiti-las; Transdutor de Sada (is),
rdio-operador e outros membros da equipe de comunicaes que trans mitem as
mensagens do navio.
Figura 2.2 (a): Princ subsistemas de um namo
23
o
i
Figura 2.2 (b): Principa&s subszstemas de um namo
24
Figura 2.3 (a): Principais .suhsi te mas da holanda
25
4
..
Subsistemas que processam tanto matria-energia como informaes: Delimita dor ,
organizaes de defesa, guarda ou policiamento das fronteizas nacionais. Subsistemas
que processam matria-energia: Ingestor organizaes, como empresas de transportes
areos, ferrovirios ou rodovirios ou empresas de transpor tes martimos, que importam
diversas formas de matria-energia para o pais; Distribuidor
organizaes nacionais que transportam formas diversas de matria-energia por gua,
estradas, ferrovias ou pelo ar; Conversor r ii organizaes que con vertem formas brutas
de matria-energia em outras formas utiizveis pela sociedade;
Produtor , organizaes industriais que fabricam produtos para a sociedade
ou para exportao; Armazenamento de Matria-Energia organizaes como depsitos,
reservatrios e instalaes de energia eltrica que armazenam diferentes formas
de matria-energia; Extravasor organizaes que exportam produtos da Ho
landa para outros pases, ou despejam resduos no mar, e setores que deportam pessoas in
desejveis; Motor , unidades do ramo de transportes ou construes, foras armadas ou
agncias espaciais; Suportador , edifcios pblicos e a terra.
Subsistemas que processam informaes: Transdutor de Entrada ( organiza es que
recebem sinais telegrficos, por cabos, telefnicos ou de radar, ou notcias pro venientes
do exterior da Holanda; Transdutor Interno (4) , legislatura representa tiva, membros de
partidos ou organizaes de consulta da opinio pblica que recebem comunicaes e
relatrios de todos os pontos da Holanda; Canal e rede recur sos nacionais de
comunicaes; Decodificador , setor de assuntos estrangei ros que decodifica mensagens
secretas recebidas das embaixadas da Holanda em todo o
(Continua)
26
mundo; Associador instituies de ensino da lngua holandesa; Me
mria ( , biblioteca; Decididor , Rainha e o governo em Haia;
Codificador , secretrio de imprensa do governo ou redatores de discursos;
Transdutor de Saida pessoa que fala oficialmente pela Holanda.
Figura 2.3 (b): Principais subsistemas da Holanda
Vemos abaixo, uma diviso mais prtica dos sistemas automati zados:
Sistemas on-line
Sistemas de tempo-real
Sistemas de apoio deciso
Sistemas baseados no conhecimento
A seguir, vamos examinar cada um desses tipos de sistemas.
2.4.1 Sistemas On-Line
Em um livro anterior (EYourdon, 19721), define sistemas on-line do
seguinte modo:
Sistemas on-line so os que recebem entradas diretamente do local onde ele foi criado.
So tambm os sistemas em que as sadas, ou os resultados do processamento, so
dirigidas diretamente para onde sejam necessrias.
Isso habitualmente signifIca que a arquitetura de hardware de um
sistema de processamento semelhante da figura 2.4.
Uma caracterstica tpica de um sistema on-line o fato de que os dados so introduzidos
no sistema de processamento e dele recebi dos remotamente. Isto , os usurios do
sistema de processamento inte
-ragem com o computador atravs de terminais 6 que podem estar
27
localizados a centenas de milhas de distncia de outros terminais e do prprio
computador.
Outra caracterstica de um sistema on-line que os dados armaze nados, isto , os
arquivos ou bancos de dados, so habitualmente organi zados de forma tal que os dados
individuais (como um registro de reser va de passagem area ou um. registro individual
sobre uma pessoa) podem ser recuperados e/ou modificados (1) rapidamente e (2) sem
necessariamente precisar ter acesso a outros dados do sistema. Isso est em flagrante
contraste com os sistemas baich (em lotes), que eram mais comuns nas dcadas de 60 e
70. Nos sistemas de processamento em lotes, as informaes so normalmente
recuperadas na modalidade se qencial, o que significa que o sistema de processamento
l todos os registros do banco de dados, processando e atualizando os registros para os
quais haja alguma atividade. A diferena entre um Sistema on-line e um sistema batch
anloga diferena entre a procura de uma msica em um gravador de fita e em um toca-
disco; o primeiro envolve o acesso seqencial por todas as trilhas, enquanto o outro
permite o acesso alea trio a qualquer das trilhas sem que seja necessrio ouvir as
demais.
Como um sistema on-line interage diretamente com pessoas (isto , usurios humanos em
terminais), importante que o analista de sistemas planeje cuidadosamente a interface
homem-mquina . Isso quer dizer que o analista deve ter um meio de modelar todas as
mensagens poss veis que o usurio poder digitar no terminal e todas as respostas que o
sistema pode dar - e todas as respostas que o usurio pode dar s consultas do
computador, e assim por diante. Isso geralmente feito mediante a identificao de todos
os estados em que o computador e o usurio podem se encontrar e pela identificao de
todas as modifica es de estado. Um exemplo de um estado em que poderia se encontrar
o computador de um sistema de caixa automtico de um b poderia ser: O usurio
introduziu o carto de crdito e se identificou, mas ainda no me informou sua senha
confidencial. Um exemplo de uma mudan a de estado seria: Ele me disse sua senha e
agora posso procurar saber se ele deseja retirar dinheiro ou ver seu saldo. Outra
mudana de estado poderia ser: Ele tentou introduzir a senha trs vezes sem sucesso e
agora vou soar o alarme. Esses estados e modificaes de estado so normalmente
modelados nos diagramas de transies de estado, que discutiremos detalhadamente no
captulo 13.
Como os sistemas on-line geralmente precisam recuperar dados rapidamente (para
responder a consultas e comandos provenientes de terminais on-line), normalmente
muito importante projetar os arquivos e bancos de dados to eficientes quanto possvel.
Na realidade, muitas vezes verdade que os clculos executados por um sistema on-line
sejam relativamente triviais, enquanto que os dados (principalmente a estrutura e a
organizao dos dados manudos pelo sistema on-line) so bastante
28
As informaes so comutadas a partir do ponto de origem
Figura 2.4: Um sistema on-line
complexos. Por causa disso, as ferramentas de modelagem de dados discutidas no
captulo 12 so de grande importncia para o analista e para o projetista de sistemas.
A deciso de se construir um sistema on-line ou no , no contexto deste livro, uma
deciso de implementao e no algo que deva ser de terminado pelo analista de sistemas
mas sim pelos implementadores do sistema. Contudo, como essa deciso tem evidente
impacto sobre o usurio (a presena ou ausncia de terminais de vdeo etc.), trata-se de
uma deciso de implementao da qual os usurios geralmente querem participar. Na
verdade ela faz parte do modelo de implementao do usurio, que veremos no captulo
21.
2.4.2 Sistemas de Tempo-Real
Os sistemas de tempo-real so por muitos considerados como va riaes dos sistemas on-
line; na realidade, muitas pessoas usam esses termos indiferentemente. Entretanto,
importante fazer distino entre eles. Usaremos a definio encontrada em IMartin,
19671:
Os dados so organizados de modo a que possam ser recuperados rapidamente
A sada transmitida para onde for necessrio
29
Um sistema de processamento em tempo-real pode ser definido como aquele que controla
um ambiente pelo recebimento de dados, seu processamento e apresentao dos
resultados com rapidez sufi ciente para afetar o ambiente naquele momento.
A expresso, rapidez suficiente est, naturalmente, sujeita a muitas interpretaes.
Evidentemente existem muitos sistemas on-line:
sistemas bancrios, sistemas de reserva de passagens areas, sistemas de controle de
estoques - que se espera que reajam em um ou dois segun dos s mensagens digitadas no
terminal. Entretanto, na maioria dos siste mas de tempo-real, o computador deve reagir
em milissegundos e s vezes em microssegundos s entradas recebidas. Isso
caracterstico dos seguintes tipos de sistemas:
Sistemas de controle de processos - sistemas de processamento usados para monitorar e
controlar refinarias de pcirleo, proces sos da indstria qumica, operaes de moagem e
operaes mecnicas servem como exemplos.
Sistemas de caixa automtico - os caixas eletrnicos que muitos de ns usamos para
pequenos depsitos e retiradas em
um banco so exemplos.
Sistemas de obteno de dados de alia velocidade - so exem plos os sistemas de
processamento que recebem dados de te lemetria de alta velocidade de satlites em rbita,
ou computa dores que recebem macias quantidades de dados de ex perincias
laboratoriais.
Sistemas de orientao de msseis - sistemas de processamento que acompanham a
trajetria de um mssil e fazem contnuos
ajustamentos na orientao e ativao dos propulsores do mssil.
Sistemas de comutao telefnica - sistemas de processamento que monitoram voz e
transmisso de dados entre milhares de chamadas telefnicas, detectando os nmeros
discados, con dies de no-gancho e fora-do-gancho e todas as outras inmeras condies
de uma rede telefnica tpica.
Sistemas de monitora o de pacientes - sistemas de processa mento que monitoram
diversos sinais vitais de pacientes (ex., temperatura e pulso) e administram a
medicao ou soam o alarme se esses sinais vitais se alteram alm de certas condies
predeterminadas.
30
Alm da velocidade existe uma outra caracterstica que distingue sistemas de tempo-real
de sistemas on-line: esses ltimos geralmente interagem com pessoas, enquanto os
sistemas de tempo-real interagem tanto com pessoas quanto com o ambiente, que
normalmente autno mo e muitas vezes hostil. Na verdade, a preocupao principal do
analis ta de sistemas de tempo-real que, se o computador no responder com suficiente
rapidez, o ambiente ficar fora de controle - os dados que chegarem podero se perder
irremediavelmente, ou um mssil poder se desviar tanto de sua trajetria que no se
conseguir recuper-lo, ou um processo industrial poder ir pelos ares Em contraste com
isso, um sistema on-line que no reaja com suficiente rapidez nada mais far do que
tornar seus usurios impacientes e irritados. As pessoas podem explodir ou ir pelos
ares em sentido figurado se tiverem que esperar mais de trs segundos por uma resposta
de um sistema on-line, mas no em sentido literal. Isso mostrado na figura 2.5.
Em virtude de sua preocupao com resposta instantnea s entradas, um analista
trabalhando com sistemas de tempo-real est geralmente interessado com o
comportamento tempo-dependente do sistema. As ferramentas para modelagem do
comportamento tempo- dependente de sistemas sero examinadas no captulo 13.
Do ponto de vista da implementao, os sistemas de tempo-real
(bem como alguns sistemas on-line) se caracterizam pelos seguintes
aspectos:
Muitas atividades de processamento ocorrem simultaneamente.
Passagem do tempo
Figura 2.5: Um sistema de tempo-real
31
Estabelecimento de diferentes prioridades para diferentes tarefas de processamento:
algumas precisam ser executadas imedia tamente, enquanto outras podem ser postergadas
por perodos razoveis de tempo.
Interrupo de uma tarefa de processamento antes de haver ter minado de modo a que
outra, de alta prioridade, possa ser aten dida.
Comunicaes extensivas entre tarefas, principalmente quando muitas das tarefas
funcionam em diferentes aspectos de um
processo geral como um processo de controle industrial.
Acesso simultneo a dados de uso comum, tanto na memria principal como na
secundria, exigindo portanto elaborados procedimentos de hand-shaking e sinais de
trnsito para as segurar que esses dados comuns no se corrompam.
Uso dinmico e alocao da memria RAM no sistema de pro cessamento, visto no ser
econmico (mesmo nos dias atuais de memrias de baixo preo) ocupar muita memria
fixa para manipular situaes de pico de quantidade de dados.
2.4.3 Sistemas de Apoio Deciso e Sistemas de Planejamento Estratgico
A maioria dos sistemas automatizados de informaes construdos nos Estados Unidos
nos ltimos 30 anos era de sistemas operativos que auxiliam na execuo do trabalho
dirio de uma empresa. Esses siste mas, tambm conhecidos como de pmcessamento de
aes, incluem os conhecidos sistemas de pagamento, de entrada de pedidos, de contabili
dade e industriais. Nas empresas americanas, esses sistemas opera tivos foram
desenvolvidos lenta e dolorosamente, a um alto custo, e como muitos deles foram
desenvolvidos h mais de 20 anos j esto beira do desmoronamento. Em face disso,
novos sistemas operativos so conti nuamente construdos nas maiores empresas por todo
o mundo.
Na medida em que os sistemas operativos atuais prosseguem em seu rumo cambaleante,
muitas empresas esto concentrando a atuao em um novo tipo de sistema: o de apoio
deciso.Como o termo sugere, esses sistemas de processamento no tomam decises por
eles mesmos, mas auxiliam gerentes e outros profissionais funcionrios do conheci
mento de uma organizao a tomarem decises inteligentes e bem in formadas sobre
vrios aspectos da operao. Os sistemas de apoio
32
deciso so tipicamente passivos no sentido de que no funcionam de uma forma regular:
em vez disso, so utilizados de forma ad hoc quando isso se faz necessrio.
Existem vrios exemplos simples de sistemas de apoio deciso:
programas de planilhas eletrnicas (p.ex., o Lotus 1,2,3, o Multiplan da Microsoft e o
Framework da Ashton-Tate), sistemas de anlise estatstica, programas de previses
mercadolgicas e outros. Em realidade, uma caracterstica comum dos sistemas de apoio
deciso a de que eles no s recuperam e apresentam dados, mas tambm executam
diversas anlises matemticas e estatsticas sobre os dados; tm tambm a apti do, na
maioria dos casos, de apresentar as informaes sob vrias for mas grficas (tabelas,
diagramas etc.) bem como relatrios convencio nais. A figura 2.6 mostra uma tpica
planilha financeira que poderia ser utilizada por um gerente para avaliar a rentabilidade
de uma diviso da empresa; a figura 2.7 mostra um grfico tpico, que apresenta as
receitas da diviso comparadas mdia da indstria. Observe que, em ambos os casos, a
sada produzida pelo sistema no toma a deciso e, sim, fornece informaes relevantes
em formato adequado para que o gerente possa tomar a deciso.
Alguns sistemas de apoio deciso so teis para organizar e
mecanizar as normas utilizadas para se chegar a uma deciso comercial.
Projees de Lucros/Perdas
10
TRIM.
TRIM.
30
TRIM.
TRIM.
TOTAL
Vendas domsticas
Vendas internacionais
Taxa de licena
Receitas diversas
RECEITA TOTAL
400
100
25
10
535
425
150
60
10
645
250
200
50
15
515
375
125
25
10
535
1450
575
160
45
2230
Custodasvendas
Salrios
Outros custos
Aluguis
Telefone
Despesas postais
Viagens
Despesas legais
Depreciaes
Despesas diversas
DESPESA TOTAL
123
100
15
15
20
5
10
10
12
5
315
148
120
18
15
20
6
10
10
13
5
365
118
120
18
15
20
5
10
15
13
5
339
123
125
19
18
20
7
10
10
14
5
351
513
465
70
63
80
23
40
45
52
20
1371
LUCRO/PERDA
220
280
176
184
859
Figura 2.6: Uma planilha tpica
33
Receitas da Widget
12
10
8
Receita em 6 Receitas da Widget
milhes Mdia da indstria
81 82 84 85
Ano
Figura 2.7: Um tpico grfico prod uzido por um sistema de apoio deciso
Um sistema desse tipo o programa chamado Lightyear (da Lightyear, Inc.), que
funciona nos computadores pessoais compatveis com o IBM. Ele permite que o usurio
(ou mltiplos usurios) descreva os detalhes de um problema orientado para deciso; um
exemplo poderia ser o problema de decidir onde instalar um novo escritrio. Em primeiro
lugar, o usurio identifica os critrios que sero utilizados na tomada de deci so. Para o
problema da instalao do escritrio, isso poderia incluir critrios como: deve ser
acessvel por transporte pblico e no deve ser instalado em locais sujeitos a
terremotos. Alguns dos critrios so binrios no sentido de que uma falha em satisfaz-
los elimina um candi dato ou causa a automtica seleo de um candidato. Alguns dos
crit rios podem ser escalonados numericamente; por exemplo, um dos crit rios poderia
ser a taxa de imposto de renda, que toma diferentes valores numricos dependendo da
cidade e do estado onde se localiza o novo escritrio. Os prprios critrios podem ser
escalonados relativamente uns aos outros: um imposto talvez tenha um valor igual a 5 em
uma escala de 10 pontos, enquanto as instalaes comerciais convenientes prximas tm
um valor de 3. Tendo sido definidos os critrios para a tomada de deciso, vrios
candidatos podem ser avaliados e analisados; o melhor candidato ser escolhido
automaticamente pelo programa Ligh tyear. A figura 2.8 demonstra esse processo.
Nada existe de mgico nisso. O programa est simplesmente apli cando, de forma
mecnica, as normas de avaliao introduzidas pelo
usurio. Entretanto, a capacidade do sistema mais do que apenas o
34
Identificar opes alternativas
Ir
Estabelecer critrios de avaliao
Escalonar as opes alternativas
conforme critrios
4
Selecionar melhor opo
Figura 2.8: O sistema Lightyear de apoio deciso
clculo mecnico: ele obriga a usurio a emitir seu critrio, o que muitas vezes no
feito. Ele tambm oferece um recurso neutro para reunir as opinies de muitos usurios
em situaes onde importante a obteno de um consenso. Em um problema
emocionalmente sensvel como o da escolha da localizao do novo escritrio (p.ex.: a
instalao das famlias dos que tomaro a deciso), pode ser muito benfico no apenas
deter minar os critrios de deciso mas tambm determinar o escalonamento dos critrios
de cada tomador de decises. Se dois membros da comisso de instalao do escritrio
divergirem, deve ficar claro para eles qual a base da divergncia.
Os sistemas de planejamento estratgico so usados pelos diretores para avaliar e analisar
a misso da empresa. Em vez de oferecer conse lhos sobre uma deciso comercial
isolada, esses sistemas fornecem infor maes mais amplas e mais gerais sobre a situao
do mercado, as pre ferncias dos clientes, o comportamento dos competidores etc. Isso
habitualmente pertence rea do Departamento de Planejamento Estra tgico ou do
Departamento de Planejamento a Longo Prazo, embora essa possa ser uma atividade
informal desempenhada por um ou dois diretores de alto nvel.
Planejamento estratgico um conceito que se tornou popular du rante a Segunda Guerra
Mundial (embora obviamente algumas empresas j fizessem isso h muito tempo) e o
tema de muitos livros; veja ESteiner, 1979], EDrucker, 1974] e EAckoff, 19701. Os
sistemas de pla nejamento estratgico no so intrinsecamente programas de com
putador, mas uma complexa combinao de atividades e procedimentos, muitos deles
executados por pessoas utilizando informaes respigadas
35
1
de fontes externas (pesquisas de mercado e outras) e de dados internos dos sistemas
operativos da empresa e de sistemas de apoio deciso. Steiner afirma que podem existir
muitos tipos de sistemas de planejamento estratgico, dependendo do tamanho e da
natureza da organizao.
Dois modelos tpicos so retratados nas figuras 2.9 e 2.10. O siste ma de planejamento
estratgico fundamentado na anlise de intervalos tenta identificar a discrepncia entre a
posio atual da empresa (em termos de receita, lucros etc.) e a posio desejada pela
direo, acionis tas e outros.
Os sistemas de planejamento estratgico constituem outro tema e
no trataremos deles detalhadamente neste livro. Nossa nfase ser prin cipalmente sobre
os sistemas operativos e de apoio deciso.
Observe o relacionamento entre os trs diferentes tipos de sistemas examinados nesta
seo. Como mostra a figura 2.11, os sistemas operau vos representam a base sobre a
qual se fundamentam os sistemas de apoio deciso e os de planejamento estratgico. Os
sistemas operativos criam os dados exigidos pelos sistemas de nvel mais elevado, e atua
lizam continuamente esses dados.
A forma piramidal da figura 2.11 representa outra caracterstica dos
sistemas de informaes encontrados na maioria das organizaes atuais:
o tamanho dos sistemas operativos (medido em pessoas-ano, ou milhes
Figura 2.9: Um modelo de planeja rnento esiral4gico centralizado na anlise de intervalos
36
Figura 2.10: Um modelo de planejamento estratgico baseado na fora do mercado.
de comandos COBOL etc.) excede ao dos sistemas de apoio deciso e ao dos sistemas
de planejamento estratgico. Mas podemos esperar uma mudana nesse aspecto na
prxima dcada. Como j foi mencionado, muitas empresas despenderam os ltimos 30
anos construindo seus siste mas operativos. Para a maioria dessas empresas, o trabalho
est feito . Grande parte do trabalho agora em andamento em algumas dessas gran des
empresas o desenvolvimento de sistemas de apoio deciso e de planejamento
estratgico.
37
Figura 2.11: A hierarquia dos sistemas de processa mento de informao
2.4.4 Sistemas Baseados no Conhecimento
Uma expresso relativamente nova na indstria do processamento sistemas
especialistas ou sistemas baseados no conhecimento. Es ses sistemas esto associadQs
ao campo da inteligncia artificial, assim definida por Elaine Rich [ 19841:
A meta dos cientistas da computao que trabalham no campo da inteligncia artificial a
produo de programas que imitem o de sempenho humano em uma ampla variedade de
tarefas inteligen tes. No caso de alguns sistemas especialistas essa meta est prxima
de ser atingida. Nos demais casos, apesar de ainda no sabermos como construir
programas que funcionem bem por eles mesmos, emos comear a elaborar programas que
auxiliem as pessoas de forma significativa, na execuo de suas tarefas.
Os sistemas baseados no conhecimento e os sistemas especialistas foram descritos por
dois eminentes escritores do campo da inteligncia artificial, Feigenbaum e McCorduck
em [ e McCorduck, 19831 da seguinte maneira:
Os sistemas baseados no conhecimento, como bvio, contm grande quantidade de
conhecimentos variados que eles trazem para utilizao em determinada tarefa. Os
sistemas especialistas so uma espcie de sistemas baseados no conhecimento, embora os
dois nomes sejam muitas vezes empregados indistintamente.
38
Sistemas operativos
O que exatamente um sistema especialista? um programa que tem embutido o
conhecimento e a capacidade que o permitiro fun cionar como especialista. Desempenho
especialista significa, por exemplo, o nvel de desempenho de um mdico em diagnose e
teraputica, ou de doutores ou pessoas de grande experincia em exercer tarefas de
engenharia, cientficas ou administrativas. O sis tema especialista um auxilio intelectual
de alto nvel para o espe cialista humano, o que explica seu outro nome, o de assistente
inteligente.
Os sistemas especialistas so construdos habitualmente para terem a capacidade de
explicar as linhas de raciocnio que conduzem a suas decises. Alguns podem at mesmo
explicar porque rejeitaram cer tas linhas de raciocnio e escolheram outras. Essa
transparncia uma das principais caractersticas dos sistemas especialistas. Os pro
jetistas fazem todo o esforo para conseguir isso porque sabem que a utilizao de um
sistema especialista depende de sua credibilidade junto aos usurios, e a credibilidade
surge pelo fato de seu compor tamento ser transparente, explicativo.
Os sistemas especialistas ainda so imaginados como sistemas es pecializados, usando
hardware especial .e linguagens de programao tambm especiais, como LISP e
PROLOG. Entretanto, alguns sistemas especialistas simples comeam a surgir em
computadores pessoais de porte padro, e as cpsulas (shelis) de sistemas especialistas -
estrutu ras de software para o desenvolvimento de aplicaes especficas de sis temas
especialistas - j aparecem em ambientes de grande porte basea dos em COBOL.
Embora os sistemas especialistas estejam fora do escopo deste li vro, eles tornar-se-o
gradualmente um componente cada vez mais im portante do sistema tpico em que
voc trabalha como analista de sistemas. Desde o final dos anos 80 os pesquisadores vm
estudando o relacionamento entre as tcnicas clssicas de desenvolvimento de soft ware e
a inteligncia artificial; um estudo tpico desses Uacob e Fros cher, 1986]. KelIer
(IKeller, 1987]) prev um tempo no futuro prximo em que os sistemas de IA e
especialistas faro parte da atividade normal de anlise de sistemas; outros, como
lBarstow, 1987] e (Lubars e Harandi, 19871 presumem que a inteligncia artificial ser
til no auxlio aos ana listas de sistemas na documentao dos requisiI do usurio em
meados dos anos 90. Mais adiante, voltaremos a este assunto.
39
1
1
2.5 PRINCPIOS GERAIS DE SISTEMAS
Todos os exemplos vistos acima tm uma coisa em comum: todos eles so sistemas.
Embora possam ser diferentes de vrias maneiras eles compartilham muitas
caractersticas comuns. O estudo dessas caracters ticas comuns conhecido como
teona geral dos sistema?, um fasci nante tema a explorar. Para uma vista inicial do
assunto, leia EWeinberg, 19761; para um exame mais formal, consulte EBertalanffy,
19691; uma viso mais humorstica da freqentemente perversa natureza dos siste mas
pode ser encontrada no delicioso Systemantics [ 19771.
Apesar do assunto da teoria geral dos sistemas estar alm do pro psito deste livro,
existem alguns princpios gerais de particular inte resse para os que constrem sistemas
automatizados de informaes. So os seguintes:
1. Quanto mais especializado um sistema, menos capaz ele de se adaptar a
circunstncias diferentes. Isso muitas vezes usa do para descrever sistemas biolgicos
(p.ex., animais que tm dificuldade de se adaptar a novos ambientes), mas tambm se
aplica a sistemas de computador. Quanto mais um sistema for de emprego geral, menos
otimizado ele ser para uma situao especfica; porm, quanto mais um sistema for
otimi zado para uma situao especfica, menos adaptvel ele ser a novas circunstncias.
Isso um problema verdadeiro para muitos sistemas de tempo-real que precisam ser
otimizados para proporcionarem respostas suicientemente rpidas aos estmu los
externos. Mas o processo de otimizao geralmente se beneficia das idiossincrasias do
hardware de computador e do software de sistemas especiais no projeto, o que significa
que pode ser muito dificil transferir o sistema para um diferente hardware. Esse princpio
tambm importante para muitos sistemas comerciais que refletem a poltica do
usurio, que tambm pode ser extremamente especializada. Quanto mais espe cializados
forem os requisitos do usurio para um sistema de pagamento de pessoal, por exemplo,
menos provvel ser que possa ser utilizado um pacote comercial disponvel.
2. Quanto maior for um sistema, maior o nmero de seus recursos que sero destinados
manuteno diria. Novamente a Biologia o exemplo mais conhecido deste princpio:
os dinos sauros gastavam a maior parte de suas vidas diurnas enchendo se de comida para
manter suas imensas carcaas. Isso tambm se aplica a exrcitos, empresas e a muitos
outros sistemas, inclusive os sistemas automatizados que estamos estudando
40
neste livro. Um pequeno sistema de brinquedo, do tipo que pode ser desenvolvido em
uma tarde, exigir habitualmente muito pouca burocracia, enquanto um sistema grande
exigir enormes esforos nas improdutivas reas da verificao de erros, edio,
cpias, manuteno, segurana e documentao.
3. Os sistemas sempre fazem parte de sistemas maiores e sempre podem ser divididos em
sistemas menores. Esse ponto im portante por dois motivos: primeiro, ele sugere uma
bvia maneira de organizar um sistema que queremos desenvolver- pela sua diviso em
sistemas menores (veremos mais detalhes sobre isso nos ltimos captulos do livro). Mais
importante, en tretanto, que ele sugere que a definio do sistema que queremos
desenvolver arbitrria - poderamos ter escolhido um sistema ligeiramente menor ou
ligeiramente maior. A escolha do escopo de um sistema e a sua cuidadosa definio de
uma forma em que todos possam saber o que h dentro do sistema e o que h fora dele
uma atividade importante que ser discutida detalhadamente no captulo 18. Isto mais
difcil do que pode parecer: tanto os usurios como os analistas pensam muitas vezes que
os limites de um sistema so fixos e imutveis e que tudo que estiver fora desses limites
no merece ser estudado. Estou em dvida cm Lavctte Teague e Christopher Pidgeon ( e
Pidgeon, 19851) pela localizao do seguinte exemplo de sistemas dentro dc sistemas,
tirado de EEberhard, 1970]:
Uma preocupao inerente aos mtodos de projeto a natureza hierrquica da
complexidade. Essa preocupao movimenta-se em duas direes, escalada e regresso
infinita. Usarei uma
histria, O Aviso da Maaneta, para ilustrar o princpio da es calada.
Tive esta experincia em Washington, quando eu tinha dinheiro para gastar. Se eu
celebrasse um contrato com um projetista e dissesse: A maaneta da porta do meu
escritrio foi feita com pouca imaginao e com desenho muito pobre. Voc me projetaria
outra maaneta? Ele responde sim, e aps estabelecermos um preo, ele vai embora.
Uma semana mais tarde ele volta e diz: Sr. Eberhard, estive pensando sobre a maaneta.
Em primeiro lugar, precisamos decidir se uma maaneta a melhor opo para abrir e
fechar uma porta. Eu digo, timo, eu gosto de imaginao, prossiga. Ele volta outra
vez e diz, Sabe, estive pensando sobre seu problema e a nica razo para o senhor querer
uma maaneta que o senhor
41
presume que deseje uma porta para o seu escritrio. O Sr. tem certeza de que uma porta
a melhor maneira para controlar a sakla e a privacidade - No! no tenho certeza Bem,
vou pensar sobre este problema. Ele volta uma semana mais tarde e diz: O nico
motivo que temos para nos preocuparmos com o problema da passagem a sua
insistncia em ter quatro paredes em volta de seu escritrio. Tem certeza de ser essa a
melhor maneira de organizar o espao para o tipo de servio que o Sr. faz como
burocrata?. Eu digo: No! no tenho certeza. Bom, a escalada prossegue at (e isso
aconteceu literalmente com dois contratos, embora no exatamente conforme este
processo) que nosso projetista fsico regresse com a fisionomia muito sria. Sr.
Eberhard, precisamos decidir se a democracia capitalista a melhor maneira de organizar
nosso pas antes que eu possa atacar o seu problema.
No outro extremo est o problema da regresso infinita. Se aquele homem se deparasse
com o projeto da maaneta diria:
Espere. Antes de me preocupar com a maaneta, quero estudar o formato da mo
humana e o que o homem capaz de fazer com ela. Eu diria: Muito bem. Ele
retornaria e diria: Quanto mais eu penso sobre isso, surge um problema de adaptao. O
que quero estudar em primeiro lugar como o metal formado, quais so as tecnologias
para fabicar coisas metlicas de modo que eu possa conhecer os verdadeiros parmetros
para o ajuste mo. timo. Mas a ele diz: Estive estudando a constituio do metal
e tudo depende das propriedades metalrgicas. Preciso estudar metalurgia por trs ou
quatro meses para compreender melhor o problema. - timo!. Aps trs meses, ele
volta e diz: Sr. Eberhard, quanto mais estudo metalurgia mais percebo que a estrutura
atmica que est de fato no centro do problema. E, assim, nosso projetista fsico est
estudando fsica atmica a partir da maaneta. Esta uma das quatro preocupaes - a
natureza da complexidade.
4. Os sistemas crescem. Naturalmente, isso no pode ser verda deiro para todos os
sistemas ou isso violaria um princpio geral de sistemas muito conhecido: a lei da
conservao da energia. Mas, muitos dos sistemas com os quais estamos familiarizados
realmente crescem, e importante reconhecermos isso, porque muitas vezes deixamos de
considerar esse aspecto (como analistas e projetistas de sistemas) ao iniciarmos o desen
volvimento de um sistema. Um tpico sistema de informaes, por exemplo, cresce para
incluir mais software do que estava previsto originalmente, mais dados, mais funes e
mais usurios. Por exemplo, Lientz e Swanson encontraram em uma clssica avaliao de
aproximadamente 500 empresas de
42
processamento de dados em todo o pas (lLientz e Swanson, 19801), que o volume de
cdigo de um sistema automatizado cresce aproximadamente 10% ao ano, e que o
tamanho do ban co de dados cresce cerca de 5% a cada ano. Nao se pode pre sumir que
um sistema que voc tenha construdo v permanecer esttico; o custo da expanso pelo
tempo deve ser includo nos clculos do custo-beneficio, que discutiremos no captulo
5 e no a C.
2.6 RESUMO
Os analistas de sistemas na atividade de processamento de dados so vtimas freqentes
da lei da especializao acima examinada. Eles se tornam especialistas em seu prprio
campo, sem perceberem que exis tem outros tipos de construtores de sistemas e que
podem ser aplica dos alguns princpios gerais. O principal propsito deste captulo foi
ampliar seus horizontes e dar-lhe maiores perspectivas antes de mergu lharmos mais
profundamente no estudo dos sistemas automatizados de informaes.
claro que no se pode ser especialista em sistemas vivos, fsicos e em todas as formas
de sistemas feitos pelo homem em acrscimo aos sistemas automatizados de infor Porm,
como os sistemas que voc vier a construir quase sempre iro interagir com esses outros
tipos de sistemas, importante no os ignorar. Compreendendo que outros sistemas
obedecem a muitos dos mesmos princpios gerais que o sistema de processamento que
estiver produzindo, voc provavelmente ter mais sucesso no desenvolvimento de
interfaces entre o seu sistema e o mundo exterior.
REFERNCIAS
1. Edward Yourdon, Design of On-Line Computer Systems. Engle wood Cliffs, N.J.:
Prentice-Hall, 1972, p. 4.
2. James Martin, Design f Real-Time Computer Systems. Englewood Cliffs, N.J.:
Prentice-Hall, 1967.
3. James Grier MilIer, Living Systems. Nova lorque: McGraw-Hill,
1978.
4. George Steiner, Strategic Planning. Nova lorque: Free Press, 1979.
5. Peter Dru cker, Management: Tasks, Respons ibilities, Pra ctices. Nova lorque: Harper
& Row, 1974.
6. Russell L. Ackoff, A Concept of Co Planning. Nova lorque:
Wiley, 1970.
7. Stafford Beer, Brain oftbe Firm. Nova lorque: Wiley, 1972.
43
8. Stafford Beer, Tbe Heart ofEntetprise. Nova lorque: Wiley, 1978.
9. Stephen Hall, Biochips, Higb Technology, dezembro de 1983.
10. H. Garrett DeYoung, Biosensors, High Technology, novembro de
1983.
11. Nicholas Shrady, Molecular Computing, Forbes, 29 de julho de
1985.
12. David Olmos, DOD Finances Case Western Biochip Research Center,
Computerworld, 3 de setembro de 1984.
13. Elaine Rich, The Gradual Expansion of Artificial Intelligence, IEEE Computer,
maio de 1984.
14. Edward Feigenbaum e Pamela McCorduck, The Ft/ih Generation. Reading, Mass.:
Addison-Wesley, 1983.
15. R.J.K. Jacob eJ.N. Froscher, Software Engineering for .Rule-Based Software
Systems, Proceedings of the 1986 Fali Joint Computer
Conference. Washington, D.C.: IEEE Computer Society Press, 1986.
16. Robert E. Kelier, Expert Systems Technolog Development and Application.
Englewood Cliffs, N.J.: Prentice-Hall, 1987.
17. Robert Alioway e Judit.h Quillard, User Managers Systems Nce CISR Working
Paper 86. Cambridge, Mass.: MIT Sloan School Cen ter for Information Systems
Research, abril de 1982.
18. Ludwig von Bertalanffy, General Systems Theo?y. Nova lorque:
George Brazilier, 1969.
19. Gerald Wdnberg, An Introduclion lo General Systems 71.nnking. Nova lorque: Wiley,
1976.
20. John Gali, Systemantics. Nova lorque: Quadrangle/The New York Times Book
Company, 1977.
21. D.Barstow, Artificial Inteiligence and Software Engineering, Proceedings of the 9th
Internationai Software Engineering
Conference, abril de 1987.
22. M.D. Lubars e M.T. Harandi, Knowledge-Based Software Design Using Design
Schemas, Proceedngs of lhe 91h International Soft ware En Conference, abril de 1987.
23. Bennet P. Lientz e E. Burton Swanson, Software Maintenance Management, Reading,
Mass.: Addison-Wesley, 1980.
24. Lavette Teague e Christopher Pidgeon, Structured Analysis Me thods for Computer
Information Systems. Chicago: Science
Research Associates, 1985.
25. John P. Eberhard, We Ought te Know the Difference, Engne ering Methods in
Environ mental Desi,gn and Pia nning, Gary T.
Moore, ed. Cambridge, Mass.: MIT Prcss, 1970, pgs. 364-365.
44
PERGUNTAS E EXERCCIOS
1. D dois exemplos de cada uma das definies do que seja um sistema apresentadas
pelo dicionrio Websters no incio do
capitulo 2.
2. D cinco exemplos de sistemas que duraram por pelo menos 1 milho de anos e que
ainda existem nos dias atuais.
3. D cinco exemplos de sistemas feitos pelo homem que tenham durado por mais de
1.000 anos. Para cada caso, d uma breve explicao de porque duraram tanto tempo e se
podemos esperar que sobrevivam outros mil anos.
4. D cinco exemplos de sistemas no feitos pelo homem que tenham fracassado durante
sua vida. Por que fracassaram?
5. D cinco exemplos de sistemas feitos pelo homem que tenham fracassado durante sua
vida. Por que fracassaram?
6. Projeto de Pesquisa: leia Living Systems de Miller e prepare um resumo.
7. Projeto de Pesquisa: leia Bran of the Firm de Beer e faa um resumo para seus
colegas.
8. Projeto de Pesquisa: leia Tbe Heart ofEnteiprise de Beer e faa um resumo para seus
colegas.
9. Com referncia seo 2.3, d um exemplo de um sistema feito pelo homem, que, em
sua opinio, no deve ser automatizado. Por que voc acha que ele no deve ser
automatizado? O que sairia errado?
10. D um exemplo de um sistema no-automatizado que, em sua opinio, deveria s-lo.
Por que voc acha isso? Quais seriam os benefcios? E quais seriam os custos? Qual a
confiana que voc tem nos benefcios e nos custos?
11. D exemplos dos 19 subsistemas de Miller para os seguintes tipos de sistemas
automatizados:(a) pagamento de pessoal, (b) controle
de inventrio, (c) o sistema telefnico.
12. Escolha uma pequena empresa que voc conhea bem, ou um departamento ou
diviso de uma grande empresa. Prepare um inventrio dos sistemas utilizados pela
empresa que voc escolheu. Quantos deles so sistemas operativos? Quantos so sistemas
de apoio deciso? Quantos so sistemas de planejamento estratgi co? Existem outras
espcies teis de sistemas? Para ajud-lo a enfo car essa rea, consulte [ e Quillard,
19821.
13. D cinco exemplos de seu prprio conhecimento de (a) sistemas de tempo-real, (b)
sistemas on-line, (c) sistemas de apoio deci so, (d) sistemas de planejamento
estratgico e (e) sistemas espe cialistas.
45
14. A figura 2.4 mostra uma configurao tpica de hardware para um sistema on-line.
Desenhe um diagrama de uma configurao de hardware razoavelmente diferente. Faz
sentido ter-se alguns dos dados do sistema fisicamente localizados nos terminais?
Quando, no desenvolvimento de um sistema, deve isto ser discutido com o usurio?
15. D um exemplo de um sistema comercial que seja descrito como um sistema de
inteligncia artificial ou baseado no conhecimen to que, em sua opinio, no seja
honesta ou corretamente des crito. Por que voc acha que a descrio est incorreta?
16. Pode o modelo de resposta a estmulo mostrado na figura 2.5 ser aplicado a sistemas
que no sejam de tempo-real? No verdade que todos os sistemas respondem a
estmulos? O que h de especial com os sistemas de tempo-real?
17. Um sistema de apoio deciso pode realmente tomar decises? Caso negativo, por
qu? O que poderia ser feito para modificar o sistema tpico de apoio deciso de modo a
que ele pudesse tomar decises? Seria isso desejvel? O que seria relegado em troca dos
benefcios?
NOTAS
Os paleontologistas ainda discutem sobre esse problema: alguns acham que os
dinossauros se extingiram em um relativamente curto perodo de tempo, depois do
choque de um grande meteoro com a Terra, causando a formao de uma nuvem de
poeira to densa que a maior parte da vida vegetal teria morrido. Outros consideram que a
modificao foi mais gradual, processando-se durante um perodo de aproximadamente
um milho de anos. De qualquer forma, os dinossauros eram altamente adaptados a um
tipo de ambiente e mostraram-se incapazes de se adaptarem a um ambiente diverso.
2 Isso tambm pode auxiliar os analistas de sistemas a com preenderem o fenmeno das
prticas de um usurio serem to especializadas que no h como modific-las, mesmo
que sejam computadorizadas. Isso lembra ao ou analista de sistemas que se
desenvolverem um sistema computadorizado que seja altamente especializado na
aplicao atual do usurio, pode ser difcil adap t-lo quando os requisitos do usurio (e o
ambiente externo em que esse usurio opera) se modificarem ou evolufrem.
3 Websters New Coliegiate Dictionaiy, Springfield, Mass.: G.& C.
Merriam Company, 1977.
46
4 A essncia de um sistema e modelos bsicos (Ou essenciais) sero discutidos no
Captulo 17.
5 No obstante, cada aplicaco tem seu prprio vocabulrio, sua cultura e seu conjunto de
procedimentos. O usurio normalmente espera que o analista de sistemas saiba alguma
coisa sobre os deta lhes, poltica comercial e procedimentos de sua aplicao, de modo
que nem tudo precise ser explicado do princpio. Assim, se voc pretende ser um analista
de sistemas de um banco, ser pro vavelmente til aprender tudo o que for possvel sobre
as ativida des bancrias. Esta no uma via de mo-nica: os banqueiros esto
aprendendo mais e mais a respeito da tecnologia de sistemas de informao a cada dia.
6 A palavra terminal est sendo to usada hoje que no tenho certeza de que precise ser
definida. Entretanto, lembre-se de que h muitos sinnimos: vdeo(screen), estao de
trabalho (workstation), teclado (keyboard) e unidade de vdeo (display unit) esto
entre os mais comuns. Existem, tambm, abreviaturas conhecidas usadas para descrever o
dispositivo de entrada/sada com que nos comunicamos com o computador: CRT
(cathode ray tube), VDU (visual display unit) etc. Esses termos sero utilizados
indistintamente neste livro.
7 Isso s vezes mencionado como dilogo homem-mquina, ou como interface
homem-mquina. Muitas organizaes de de senvolvimento de sistemas esto adotando
as expresses interface homem-computador ou apenas interface humana para evitar
enganos desnecessrios.
8 Um dos mais interessantes exemplos de uma situao de tempo- real como essa
envolvia uma equipe de projeto cuja tarefa era acoplar um pequeno computador a uma
bomba nuclear. Quando a bomba fosse detonada (como parte de um programa de testes
subterrneos), o computador dispunha de apenas uns poucos mi crossegundos para
recolher tantos dados quantos pudesse e trans miti-los a um sistema remoto de
processamento antes que o hard ware e o software se vaporizassem na exploso. Isso
um requisito de processamento em tempo-real.
9 Existem algumas excees: as organizaes menores que ainda no computadorizaram
a maior parte das suas atividades; os antigos sistemas operativos desenvolvidos por 500
empresas nos anos 60 que esto beira da runa e os novos sistemas operativos exigidos
por fses, compras ou entradas em novos mercados e produtos; e a comunidade da
defesa tem uma lista aparentemente interminvel de novos sistemas operativos a serem
construdos. A tendncia geral, entretanto, de um vagaroso deslocamento a partir dos
siste mas operativos para os de apoio deciso.
10 Os usurios muitas vezes no apreciam esse fenmeno, e i pode ser um dos motivos
para o presente fascnio das lingi
gens de quarta gerao e ferramentas de prototipao. Pode construir rapidamente um
sistema com uma linguagem de qu gerao que se incumba das principais partes do
processamei (proporcionando, assim, imediata satisfao ao usurio), ma preciso muito
trabalho para introduzir inteligncia artificial i operaes de verificao de erros, cpias,
manuteno, seguran melhora de desempenho, documentao etc. preciso ter e aspecto
em mente para evitar ser forado pelo usurio a consti um sistema rpido e sujo
destinado ao fracasso. Para dar u idia da extenso de algo to mundano como a
documenta considere a estatstica apresentada por Capers Jones em P gramming
Productivity (Nova lorque: McGraw-Hill, 1986): 1 grande sistema de telecomunicaes
tinha 120 palavras em in para cada linha de cdigo-fonte, totalizando 30 milhes de pala
e 60.000 pginas e um grande sistema de governo tinha 200 lavras em ingls por linha de
cdigo-fonte, totalizando 125 milh de palavras e 250.000 pginas de documentao.
48
3
PARTICIPANTES
DO JOGO
DOS SISTEMAS
O mundo inteiro um pako,
Onde todos os homens e todas as mulheres so meros partic!pan:es.
Eles tm suas sadas e suas entradas;
E cada um, por sua vez, desempenha muitos papis,
Shakespeare
As You Like Ii, II, vii
Neste captulo, aprenderemos:
1. Os tipos de pessoas com quem interagimos em um projeto.
2. Os trs principais tipos de usurios, por tipo de tra balho.
3. As reaes do usurio durante o projeto dc desenvol vimento de sistemas.
4. A diferena entre os usurios novatos e experientes.
5. O papel da gerncia em um projeto de desenvol vimento de sistemas.
6. O papel do analista de sistemas em um projeto de desenvolvimento de sistemas.
7. Outros papis em um projeto de desenvolvimento de sistemas.
Como analista de sistemas voc trabalhar em projetos de desen volvimento de sistemas
com diversos tipos de pessoas. O elenco de personagens variar de projeto para projeto;
as personalidades sero extremamente diferentes umas das outras; e o nmero de pessoas
com
49
quem voc vai interagir variar de apenas uma a diversas dzias. Entre tanto, os
personagens so altamente consistentes e voc os ver muitas e muitas vezes.
Ser um analista de sistemas bem-sucedido requer mais do que o conhecimento da
tecnologia dos computadores. Entre outras coisas, requer aptides interpessoais: voc
passar boa parte do seu tempo tra balhando com outras pessoas, muitas das quais falam
uma linguagem muito diferente da sua e muitas consideraro sua linguagem da tecnolo
gia do computador aliengena e amedrontadora. Dessa forma, impor tante saber o que
essas pessoas esperam de voc e o que voc pode esperar delas.
Este captulo dedica-se s caractersticas dos principais tipos de
participantes que voc provavelmente encontrar em um tpico projeto
de desenvolvimento de sistemas, e que 5
Usurios
Gerentes
Auditores, pessoal do controle dc qualidade e mantenedores dos padres
Analistas de sistemas
Projetistas de sistemas
Programadores
Pessoal operativo
Cada um desses tipos descrito a seguir.
3.1 USURIOS
O primeiro, e de longe o mais importante, participante do jogo de sistemas algum
conhecido pelos analistas de sistemas como um u.su rio. Usurio a pessoa (ou grupo
de pessoas) para quem o sistema construdo. Ele ou ela a pessoa a quem voc
entrevistar, muitas vezes detalhadamente, para saber que caractersticas o novo sistema
dever ter para ser bem-sucedido.
Deve-se ressaltar que a maioria dos usurios no se refere a eles
mesmos como usurios; afinal, a palavra freqentemente utilizada
em um diferente contexto para indicar os consumidores de drogas. Em
50
algumas empresas, o setor de processamento de dados evita o problema com a utilizao
dos termos cliente ou proprietrio para identificar o usurio, O usurio o proprietrio
no sentido de que ele ou ela recebe, ou herda - e s vezes possui - o sistema depois de
pronto e o cliente em pelo menos dois importantes aspectos: (1) assim como em
tantas outras atividades, o cliente sempre tem razo, no importando quo exigente,
desagradvel ou ilgico ele ou ela possa parecer e (2) o cliente, afinal de contas, quem
paga pelo sistema e habitualmente tem o direito ou a possibilidade de se recusar a pagar
se ele ou ela no ficar satisfeito com o produto recebido.
Na maioria dos casos muito fcil identificar o usurio (ou usu rios): ele ,
normalmente, a pessoa que emite uma solicitao formal por um sistema. Em uma
empresa pequena isso habitualmente um proces so muito informal, podendo consistir
apenas de um telefonema do usu rio para o Analista de Sistemas Chefe, dizendo: Joo,
preciso de um novo sistema para controlar nossa campanha de comercializao Widget!.
Em uma grande empresa o incio do projeto de desen volvimento de um sistema muito
mais formal. A solicitao de levantamento e estudo de um sistema, como s vezes
chamada, transita normalmente por diversos nveis de aprovao antes que o analista de
sistemas inicie seu envolvimento, O captulo 5 se estender mais sobre esse assunto.
Entretanto, existem algumas situaes em que a identidade do ver dadeiro usurio
desconhecida, ou em que o analista de sistemas tem pouca ou nenhuma oportunidade de
interagir diretamente com ele. Um exemplo comum aquele de um sistema sendo
elaborado por uma firma de consultoria ou por uma empresa de software: a interao
entre a empresa cliente e a de consultoria pode se processar entre agentes con tratantes ou
outros setores administrativos, s vezes com clusulas expl citas de que o analista de
sistemas no pode se entender diretamente com o usurio. Mesmo que o sistema esteja
sendo desenvolvido inteira mente dentro de uma nica organizao, o verdadeiro
usurio pode nomear um porta-voz para trabalhar com o analista de sistemas porque ele
ou ela est ocupado demais com outras tarefas 1
evidente que em situaes assim existe uma forte possibilidade de mal-entendidos: o
que quer que o verdadeiro usurio queira que o sistema faa pode ser mal transmitido
para o analista de sistemas, e o que quer que o analista de sistemas imagine que est
criando para o usurio tambm pode ser mal comunicado - at que todo o sistema esteja
pronto, quando j ser tarde demais! Podemos tirar da duas concluses:
Sempre que possvel, o analista de sistemas deve tentar estabele cer contato direto com
o usurio. Mesmo que outras pessoas
51
estejam envolvidas como intermedirias (p.ex.: para lidar com problemas contratuais ou
detalhes administrativos), importante que haja reunies regulares, frente a frente com a
pessoa que ir afinal receber o sistema. Na verdade, at melhor se o usurio for um
membro de tempo integral da equipe de projeto. Em muitas organizaes, o usurio o
gerente do projeto, alguns chegam a defender a idia de que o usurio deveria fazer o
projeto.
Se no for possvel a comunicao direta com o usurio, ento a documentao
produzida pelo analista de sistemas torna-se ainda mais crtica. A parte II deste livro
dedicada a ferramentas de modelagem que podem ser utilizadas para descrever o com
portamento de um sistema de modo rigoroso e formal; funda mental usar ferramentas
desse gnero para evitar mal-entendi dos caros.
3.1.1 A Heterogeneidade dos Usu4rios
Um dos equvocos freqentemente cometidos por pessoas da rea do processamento -
principalmente pelos programadores, e s vezes por analistas de sistemas tambm,
presumir que todos os usurios so iguais. Usurio, como substantivo singular, implica
que o analista ir interagir com apenas uma pessoa; mesmo quando bvio que mais de
um usurio est envolvido, existe a tendncia de imagin-los como um grupo humano
indistinto e sem forma.
Dizer-se que um usurio diferente do outro , naturalmente, uma declarao trivial.
Sim, todos eles tm diferentes personalidades, diferen tes experincias, interesses, e
assim por diante. Mas existem algumas importantes diferenas que voc deve ter em
mente em seu trabalho como analista de sistemas. Aqui esto dois modos de classificar os
usurios:
por tipo de funo, ou por nvel de superviso;
por nvel de experincia com processamento de dados.
3.1.2 A Class dos Usurios por Tipo de Funo
Em um projeto tpico de anlise de sistemas, gasta-se um consi dervel tempo
entrevistando usurios para estabelecer os requisitos do
sistema. Mas, que usurios? De que nvel? Isso, naturalmente, depende
52
do projeto e da doutrina da empresa, mas voc, certamente, vai interagir
com trs tipos principais de funes: usurios operativos, superiores e
executivos 2
Usurios operalivos so os funcionrios burocratas, operativos e administrativos que com
mais probabilidade tero contato dirio com o novo sistema (a menos que esteja sendo
construdo um sistema de apoio deciso, caso em que voc pode ter pouco ou nenhum
contato com esse grupo). Assim, em uma grande organizao, voc pode acabar en
trevistando secretrias, agentes de seguros, guarda-livros, despachantes de cargas, pessoal
da entrada de pedidos e assistentes de todos os tamanhos, formas e cores. No caso de
um sistema de tempo-real, voc falar com usurios operativos cujos ttulos sero
engenheiros, fsicos, operrios de fbricas, pilotos, telefonistas etc. H trs coisas que
voc deve ter em mente quando trabalhar com usurios de nvel operativo:
1. Os usurios operativos so muito interessados em relao s funes que o sistema
executar - mas eles esto prova velmente mais interessados nos aspectos da interface
humana. Os exemplos sO: Que tipo de teclado terei de usar para me comunicar com o
sistema? Ele se parece com o da mquina de escrever que venho utilizando h anos? Que
tipo de terminal on line ter o sistema? Ser ofuscante? E os caracteres, sero fceis de
ler? Como o sistema me avisar se eu cometer um erro? Terei de redigitar tudo
novamente? E se eu quiser desfazer alguma coisa que eu tenha digitado pouco antes?
Quando o sistema produzir um relatrio para mim, onde ficar a in formao na pgina?
Poderei ter a data e a hora impressas no alto de cada pgina? E assim por diante. Esses
so problemas em relao aos quais o supervisor do usurio de nvel operativo pode estar
ou no ciente ou interessado, mas, como se pode imaginar, eles so essenciais para o
sucesso do sistema e devem ser tratados . Isso quer dizer que, como analista de sistemas,
voc deve ser autorizado a se comunicar diretamente com o usurio operativo, ou (bem
menos prefervel) deve ter muita certeza de que a pessoa que fala pelo usurio operativo
conhece esses problemas, que so discutidos detalhadamente como parte do modelo de
implementao para o usurio no captulo 21.
2. Os usurios operativos tendem a ter uma viso local do siste ma; tendem ainda a
conhecer apenas a especfica tarefa que executam e as pessoas com quem tm contato
direto (clientes, supervisores, colegas etc). Porm eles muitas vezes no conhe cem bem
toda a estrutura, isto , eles podem ter dificuldade em descrever como suas atividades se
encaixam na organizao
53
como um todo ou qual seja a verdadeira finalidade d organizao. Isso raramente se deve
estupidez e geralment reflete uma certa falta de interesse por parte deles. Pode tambr
ser reflexo do fato de o usurio supervisor. nada lhes ter falad sobre a estrutura geral e
preferir que eles nada saibam sobre el Uma conseqncia dessa situao que o analista
de sistema deve ser capaz de desenvolver modelos do sistema qu possibilitem tanto as
vises locais (descrio de uma pequena detalhada parte do sistema, independentemente
das outra partes) como as vises globais (vises gerais de alto nvel di todo o sistema,
evitando os detalhes).
3. Os usurios operativos tendem a imaginar os sistemas em ter mos fsicos, isto , em
termos de tecnologia de implementa usada correntemente para implementar o sistema
ou em termo da tecnologia que eles imaginam que poderia ser utilizada. A discusses
abstratas sobre funes e elementos de dados podem ser difceis. Diante disso, o
analista de sistemas pod achar necessrio conversar com o usurio exclusivamente c
termos que lhe sejam familiares. Em seguida, como ativida& separada, o analista pode
traduzir essa descrio fsica para un modelo essencial - um modelo do que o sistema
deve fazer no importando a tecnologia empregada para implement-lo Isso ser
examinado mais adiante, no captulo 17.
Os usurios supeivisores so, como o termo indica, empregado em atividades de
superviso. Eles geralmente cheflam um grupo d usurios operativos e so responsveis
por seus desempenhos (obvia mente, pode-se imaginar mais de um nvel de usurios
supervisore em uma grande organizao). Eles podem ter o ttulo de supervisore mas
tambm podem ter os de gerente, chefe de grupo, chefe de seo encarregado de setor,
maquinista-chefe e muitos outros ttulos. O aspectos importantes a serem lembrados a
respeito de usurio supervisores Sao:
Muitos deles foram originalmente usurios operativos que foran promovidos atual
posio Assim, eles geralmente conhecem c servio feito por seus subo dinados
operativos, e pode-se imagi. nar que habitualmente sin pauzem com suas necessidades,
pre ocupaes e perspectivas Isso, no entanto, nem sempre ver dadeiro. Como o
mercado, a economia e a tecnologia mudarair muito, a atividade operativa pode ser hoje
muito diferente dc que era 20 anos atrs.
54
Uma razo pela qual o usurio supervisor pode ser visto como no tendo contato com o
usurio operativo que ele ou ela muitas vezes avaliado e motivado pelo desempenho
em relao a um oramento. Em face disso, o usurio supervisor est freqentemente
mais interessado em um novo sistema de infor maes pela possibilidade de aumentar o
volume de trabalho realizado, reduzindo o custo de processamento das transaes e
diminuindo os erros no servio. Tambm pode ocorrer ao usu rio supervisor que um
novo sistema oferecer a oportunidade de monitorar o desempenho (e mesmo a atividade
de cada minuto) de cada usurio operativo. Dependendo de como isso for imple mentado,
os usurios operativos podem ter ou no a mesma perspectiva do usurio supervisor.
Em virtude da nfase na eficincia operativa comum o usurio supervisor ver o novo
sistema como um meio de reduzir o n mero de usurios operativos (por dispensas ou a
pedido) ou de evitar novos aumentos desse nmero quando o volume de ser vio crescer.
Isso no bom nem mau, porm muitas vezes o ponto focal de disputas polticas
acaloradas, em que o analista de sistemas freqentemente se v envolvido
Por esses mesmos motivos, o usurio supervisor age muitas vezes como intermedirio
entre o analista de sistemas e o usu rio operativo, argumentando que os usurios
operativos so muito ocupados para desperdiar o tempo conversando com o analista.
Afinal de contas, dir o usurio supervisor, exa tamente por estarmos to atarefados
que precisamos de um novo sistema de processamento! Como fcil imaginar, essa
uma posio muito perigosa, afinal, o usurio operativo quem est mais interessado
com a iruerface humana do sistema, e improvvel que o usurio supervisor seja capaz
de compreender essa necessidade.
O usurio supervisor muitas vezes pensa nos mesmos termos fsicos que o usurio
operativo e essa perspectiva muitas vezes to local quanto a desse ltimo. Seria de se
esperar, natu ralmente, que algum em nvel de chefia possusse uma viso mais global;
como corolrio possvel que o usurio supervisor j no se recorde de alguns detalhes
da orientao comercial executada pelos usurios operativos.
Por fim, com o usurio supervisor que voc ter seu princi pal contato dirio. Ele ou
ela quem normalmente define os
55
requisitos e a detalhada orientao comercial que o sistema de ve implementar. Ele ou ela
pode ser um membro passivo da equipe (no sentido de s participar quando entrevistado
(a)), um componente de tempo integral ou, at, como j men cionado, o gerente do
projeto.
Os usurios de nvel executivo normalmente no esto diretamente envolvidos nos
projetos de desenvolvimento de sistemas, a menos que o projeto seja to grande e to
importante que venha a ter grande impacto na organizao. No caso de um projeto
normal, entretanto, o usurio executivo est habitualmente dois ou trs nveis acima das
atividades associadas ao projeto. proporo que tiver contato com eles voc
provavelmente descobrir o seguinte a respeito deles:
Eles podem ter a iniciativa do projeto, mas provavelmente servi ro como a autoridade
financeira para as solicitaes de projetos
que se originem nos nveis inferiores da organizao.
Eles normalmente no foram usurios operativos ou, se o ti verem sido, foi a tanto
tempo que qualquer experincia que pudessem ter j est obsoleta. Dessa forma, eles no
es to em posio de ajudar a definir os requisitos do sistema pa ra os que realmente o
utilizaro diariamente. A exceo o sis tema de apoio deciso discutido no captulo 2;
tal sistema se ria normalmente mais utilizado pelos usurios executivos e supervisores.
Os usurios executivos so upicamente mais interessados nos aspectos estratgicos de
lucros e perdas a longo prazo. Dessa forma, eles normalmente esto menos preocupados
com os problemas operativos como custos reduzidos de transaes ou a conservao de
trs funcionrios burocratas do que com o que Paul Strassman chama de pagamento da
informao em lStrassman, 19851 - isto , novos mercados, novos produtos ou novas
vantagens competitivas que obtero do novo sistema.
Os usurios do nvel executivo geralmente esto mais interes sados na viso global do
sistema e, como resultado, no se in teressam pelos detalhes. Como j dissemos, isso
significa que devemos usar ferramentas de modelagem de sistemas que per mitam
oferecer uma viso geral do sistema para os usurios executivos (e para qualquer um que
dela precise) e partes deta lhadas do sistema para os usurios operativos que sejam os
peritos locais.
56
De modo semelhante, os usurios do nvel executivo so nor malmente capazes de lidar
com modelos abstratos de um sis tema; na verdade, j esto habituados a lidar com estes
modelos como os modelos financeims, mercadolgicos, organizaciona1 e de engenharia
(de novos produtos, fbricas, escritrios etc.). No estaro, na realidade, de forma alguma
interessados nos modelos fisicos do sistema e ficaro imaginando porque voc os estar
aborrecendo mostrando-lhes todas essas coisas.
Resumindo, voc pode esperar interagir com trs diferentes tipos ou nveis de usurios,
como mostrado na figura 3.1. Lembre-se que eles tm diferentes perspectivas, diferentes
interesses e prioridades e muitas vezes diferentes retrospectos. Esses trs tipos de
usurios podem ser caracterizados como mostrado na tabela 3.1.
Na discusso anterior sugeri que o usurio nem sempre est satis feito com a perspectiva
de um novo sistema. Na realidade, s vezes, ele se ope ativamente idia. Esse muitas
vczes o caso dos usurios operativos (j que so os que tero dc us-lo), mas a
resistncia tambm pode provir do usurio supervisor (uma vez que ele ou ela pode consi
derar que o sistema ter impacto negativo na eficincia ou na lucrativida de do setor do
qual ele ou ela responsvel) ou at do usurio executi vo. Como Marjorie Leeson diz
em ILeeson, 1981],
O analista que conhece a motivao bsica, porque as pessoas resis tem s modificaes e
como elas resistem s modificaes, pode ser capaz de superar algumas resistncias. A
maioria dos livros sobre ge rncia faz referncia hierarquia das necessidades do
psiclogo AH. Maslow. As cinco categorias, da prioridade mais baixa mais elevada,
So:
Necessidade Exemplos
1. Fisiolgica Alimentao, vesturio
e abrigo
2. Segurana Proteo contra perigos e
perda do emprego
3. Social Identificao com
pessoas e grupos
4. Egotista Reconhecimento, status
e importncia
5. Realizao Realizao de todo o
pessoalpotencial em criatividade
e desevolvimento pessoal
Desse modo, se voc encontrar alguns usurios apresentando resis tncia idia de um
novo sistema, voc deve considerar a possibilidade
57
de uma ou mais dessas necessidades no serem satisfeitas. difcil, natu ralmente, que
um usurio se preocupe com o nvel fisiolgico de neces sidades mas no
absolutamente surpreendente descobrir que um usu rio esteja preocupado com a perda
dc seu emprego. E tambm comum que os usurios (principalmente os operativos) se
preocupem com que o novo sistema faa com que eles no se identifiquem com seus
respec tivos grupos sociais. Eles receiam que ficaro presos a um terminal de vdeo o dia
inteiro e que passaro todo o tempo interagindo com um computador e no com outros
seres humanos, O usurio operativo que se tornou perito na execuo de uma atividade de
processamento de informaes de forma manual pode achar que um novo sistema deixar
Tabela 3.1 Caractersticas dos usu rios
Usurio Operativo
Usurio Supcrvi.sor
Usurio Executivo
Normalmente tem viso local
Pode ou no ter viso local
Tem viso global
Executa a funo do sistema
Normalmente conhece a operao
Tem iniciativa sobre o projeto
Tem viso fsica do sis tema
Orientado por consi deraes oramentrias
No tem experincia operativa
Muitas vezes age como intermedirio entre os usurios e os nveis mais elevados da
direo
Tem preocupaes estra tgicas
Usurio executivo
Usurio operativo
Figura 3.1: Os trs tipos de usu ri os
58
suas necessidades egotistas insatisfeitas; e o usurio que imaginar que o sistema poder
eliminar os aspectos de sua atividade atual tambm pode opor-se.
3.1.3 Class dos Usurios por Nvel de Experincia
Deveria ser bvio que usurios diferentes tivessem nveis de expe rincia diferentes;
infelizmente, comum que os analistas de sistemas presumam que lodos os usurios
sejam completos ignorantes em termos de processamento de dados. Isso talvez fosse algo
verdadeiro h dez anos atrs, mas provvel que lhe trouxesse grandes problemas na
maioria das organizaes modernas pode-se distinguir amadores, novatos e um pequeno
(porm aumentando rapidamente) nmero de verdadeiros peritos em processamento.
O usurio amador o que nunca viu um computador e que excla ma alta e
freqentemente que no entende nada de computadores. Esse usurio muitas vezes
um funcionrio ou comerciante de meia- idade que sobreviveu alegremente a 16 anos de
educao e a outros 10 ou 20 anos em um emprego, antes que os computadores fossem
introdu zidos. Entretanto, tambm comum encontrarmos usurios jovens que
consideram os computadores como tediosos, intimidantes ou irrelevan tes em suas vidas.
Isso apresenta um desafio para o analista de sistemas que aprecia discutir sobre acesso
on-line e dilogos homem-mquina orientados por menu e outros assuntos afins - mas,
se o analista de sistemas fizer seu sewlo corretamente, no h motivos para que o usu
rio deva ser interessado ou entendido em computadores.
Na realidade, o verdadeiro problema com o usurio amador algo mais sutil. Ele pode
sentir dificuldade em compreender a linguagem utilizada pelo analista de sistemas para
descrever os recursos, funes e caractersticas do sistema a ser construdo, ainda que a
linguagem evite a terminologia relacionada a computadores. Como veremos nas partes II
e III, a tarefa do analista de sistemas envolve a criao de alguns modelos do sistema a
ser construdo. Esses modelos so representaes formais e rigorosas de um sistema de
processamento e ao mesmo tempo so repre sentaes abstratas do sistema. A maioria dos
modelos envolve grficos (figuras) apoiados por textos detalhados e a representao geral
(neces sria para garantir uma descrio formal e rigorosa) choca os usurios com uma
matemtica complexa e portanto ilegvel. Esses usurios recor dam a dificuldade em ler a
complexa notao grfica usada na qumica orgnica ou a notao igualmente complexa
empregada no clculo dife rencial e na lgebra. Qualquer que seja o motivo, o resultado
o mesmo:
longe de entender a terminologia do processamento, se o usurio no
59
compreender o modelo do sistema, existe pouca possibilidade de ficar satisfeito com o
sistema quando ele ficar pronto .
Um segundo tipo de usurio o que costumo chamar de novato arrogante, pessoa que
j participou de um ou dois projetos de desenvol vimento de sistemas, ou (pior ainda) o
usurio que tem um computador pessoal e que escreveu um ou dois programas em (ugh!)
BASIC. Esse usurio freqentemente alardeia que sabe exatamente o que deseja que o
sistema faa e est disposto a apontar todos os erros cometidos pelo analista de sistemas
no ltimo projeto. Isso tudo timo, exceto por um detalhe: o usurio muitas vezes se
envolve demais em discusses sobre a especfica tecnologia que ser utilizada na
Implementao do sistema. Assim, o usurio pode dizer ao analista de sistemas: preciso
de um novo sistema de processamento de pedidos e gostaria que ele fosse construdo com
uma rede local interligando nossos IBM PC e acho que deveramos utilizar o dBASE-III
ou o PC-FOCUS. Essas podem eventualmente se revelarem as opes tcnicas mais
corretas, mas prematuro at consi derar o hardware, a linguagem de programao e os
pacotes de bancos de dados antes que os verdadeiros requisitos do sistema tenham sido
documentados. Na realidade, no caso extremo, a sugesto do usurio sobre os
adequados hardware e software pode se transformar em uma soluo em busca de um
problema, isto , a descoberta que existem recursos de hardware e de software sub-
utilizados que podem ser desti nados a algum outro uso.
Existem, claro, alguns usurios que realmenie conhecem anlise de sistemas, bem como
a subjacente tecnologia dos computadores (e tambm seu prprio ramo de atividades,
naturalmente!). um prazer trabalhar com essas pessoas. Na verdade, o nico problema
pode ser o de que o usurio e o analista de sistemas sintam tanto prazer em conver sar
sobre as ferramentas e as tcnicas da anlise de sistemas que esque am que o objetivo
real a elaborao de um sistema que funcione 8!
3.2 A GERNCIA
Gerncia um termo bastante vago. Na realidade, o analista de
sistemas provavelmente ter contato com vrios tipos de gerentes.
Gerentes usurios - so os gerentes encarregados de vrias pessoas da rea operativa em
que o novo sistema ser utilizado. Isso j foi discutido anteriormente. Habitualmente so
gerentes de nvel mdio que querem sistemas que produzam diversos relatrios internos e
anlises das tendncias de curto prazo. Os relatrios internos geralmente so relatrios
financeiros, operau vos, de excees, e assim por diante.
Gerentes de PED/SIG - as pessoas encarregadas do projeto de desenvolvimento do
sistema e os gerentes de nvel superior preocupados com o gerenciamento geral e a
alocao de recur sos de toda a equipe tcnica da organizao de desenvolvi mento de
sistemas.
Gerenclamento Geral - gerentes do nvel mais elevado que no esto diretamente
envolvidos em PED nem na organizao usuria. A podem ser includos o presidente
e/ou o gerente- geral da organizao e/ou a direo financeira (o controiler, o vice-
presidente de finanas etc.). Esses diretores esto normal mente mais interessados nos
sistemas de planejamento estrat gico e de apoio deciso, discutidos no capitulo 2.
Embora a alta direo necessite dos relatrios financeiros internos, seus membros
normalmente no precisam do nvel de detalhamento (principalmente na rea de
relatrios de excees) necessrio aos gerentes usurios. Alm disso do mais ateno a
infor maes externas: normas governamentais, relatrios da compe tio em seu
mercado, relatrios sobre novos mercados e pro dutos, e assim por diante.
A principal interao entre o analista de sistemas e todos esses gerentes tem a ver com os
recut que sero destinados ao projeto. tarefa do analista de sistemas identificar e
documentar os requisitos do usurio e as restries dentro das quais o sistema dever ser
construdo. Essas restries consistem normalmente em recursos: pessoal, tempo e
dinheiro. Assim, o analista de sistemas eventualmente produzir um documento que diga:
o novo sistema dve executar as funes X, Y e Z e deve ser desenvolvido em seis
meses com no mximo trs programa dores do departamento de PED a um custo mximo
de $100.000.
Obviamente a direo vai exigir uma permanente garantia de que o projeto de
desenvolvimento do sistema se manter dentro dessas restri es - sem atrasos no
cronograma estabelecido e sem ultrapassar o oramento. Porm esses problemas
pertencem gerncia do projeto, e no anlise de sistemas . Os gerentes de diversas
reas funcionais diferentes muitas vezes formam uma comisso de direo que ajuda a
dar prioridade a potenciais projetos de desenvolvimento de modo a que os projetos mais
eficientes em termos de custos sejam executados em primeiro lugar.
Existem alguns aspectos que devem ser lembrados sobre gerentes:
Quanto mais elevado for o nvel do gerente, torna-se menos
provvel que conhea ou se interesse pela tecnologia do pro
cessamento de dados. Embora isso seja uma generalizao,
61
habitualmente um pressuposto seguro em relao atual gerao de gerentes de alto
nvel. Isso no deve afet-lo como analista de sistemas (os projetistas de sistemas tm
tarefa mais rdua!), mas voc deve lembrar-se de concentrar a discusso nas
caractersticas essenciais de um sistema ao conversar com eles.
As metas e prioridades da direo podem ser conflitantes com as dos usurios,
principalmente os supervisores e operativos. A direo pode at impor um sistema aos
usurios e os forar a utiliz-lo (p.ex., se a empresa usuria tiver tido prejuzos ou no
tiver podido reagir a novas modificaes do mercado).
Uma variao do tema acima: a direo pode no conceder os recursos, verbas ou tempo
que os usurios consideram ne cessrios para a construo de um sistema eficiente. con
veniente para o analista de sistemas e para o usurio responder a isso afirmando que a
direo no compreende, mas isso muitas vezes uma deciso consciente e calculada.
Se desejar maiores detalhes sobre a poltica de proviso de recursos e es calonamentos,
veja o apndice B.
O termo gerncia (direo) implica em um grupo homogneo de pessoas que pensam do
mesmo modo. A verdade, na turalmente, normalmente muito diferente. Os gerentes tm
di ferentes vises e opinies, e muitas vezes tm metas e objetivos muito diferentes. Eles
discutem entre si e competem uns contra os outros. Assim, pode acontecer que alguns
membros da di reo sejam favorveis ao novo sistema enquanto Outros sejam
contrrios. Pior ainda a omisso que por vezes sobrevm em relao a alguns projetos;
eles finalmente terminam aps anos de lento progresso.
Tambm cmodo presumir que depois que a direo decidiu- se a respeito do projeto
de desenvolvimento de um sistema, que ele seja mantido. Mas nem sempre assim.
Foras externas organizao podem fazer com que a direo acelere o cro nograma do
projeto, retirar recursos dele, ou abandon-lo. Isso muitas vezes causa enormes problemas
aos que trabalham no projeto, inclusive voc, como analista de sistemas!
O relacionamento entre a direo e o seu projeto de desenvolvi mento de sistemas pode
depender muito da estrutura geral da direo de sua empresa, principalmente o
relacionamento entre as atividades de desenvolvimento de sistemas e o resto da
organizao. A estrutura
62
organizacional clssica mostrada na figura 3.2 (a); observe que o setor de
processamento de dados como um todo se reporta ao setor de fi nanas e contabilidade, O
motivo para isso que a maioria das grandes empresas introduziram originalmente os
computadores para auxiliarem a automatizar suas atividades contbeis (folha de
pagamento, livro-razo e contas a receber).
A partir dos anos 70, algumas empresas comearam a compreender que essa estrutura era
um tanto assimtrica. Ela virtualmente garantia que a funo de processamento de dados
seria orientada para aplicaes contbeis e haveria pouco interesse ou conhecimento em
outros setores da organizao. Quando as informaes automatizadas de processamen to
comearam a transitar pela empresa (na fabricao, no marketing e na engenharia),
algumas empresas adotaram o organograma mostrado na figura 3.2 (b). Com o grupo de
processamento de dados (ou SIG, como s vezes chamado) reportando-se diretamente
ao presidente da empre sa, torna-se claro para todos que o processamento de dados to
im portante para a sobrevivncia da empresa como a fabricao, engenha ria, vendas etc.
Entretanto, nos anos 80, algumas empresas comearam a conside rar que o setor de SIG
tinha se transformado em um imprio, com suas prprias prioridades e sua prpria
poltica. As organizaes usurias, enquanto isso, descobriram que tinham uma demanda
em permanente crescimento por novos sistemas a serem desenvolvidos pelo setor de SIG
. Isso coincide com o aparecimento e rpida proliferao dos baratos e poderosos
computadores pessoais; assim, alguns depar tamentos usurios perceberam que poderiam
desenvolver seus prprios sistemas, sem necessitar de uma funo centralizada de SIG.
Como resultado, algumas empresas agora tm uma estrutura como a da figura 3.2 (c).
Embora continue existindo um setor central de SIG para aplicaes clssicas, como
folha de pagamento e livro-razo, boa parte do processamento departamental feito por
grupos de desenvolvimento de sistemas dentro dos departamentos.
Se voc trabalha em uma organizao caracterizada pela figura 3.2 (a), voc poder
perceber que os analistas de sistemas e os usurios em vrios outros setores no so to
bons quanto deveriam. Na verdade, provvel que voc descubra que muitos dos
projetos de desenvolvi mento de sistemas so do tipo processamento de transaes que
podem ser encontrados em um departamento de contabilidade. Se sua empresa se parece
mais com a apresentada na figura 3.2 (b), ento h uma boa possibilidade de que o grupo
de desenvolvimento de sistemas tenha uma razovel visibilidade poltica na
organizao. Entretanto, pode-se perceber que existe uma crescente frustrao relativa ao
backlog de novos sistemas espera de serem desenvolvidos. E se voc estiver
trabalhando em uma organizao do tipo apresentado na figura 3.2 (c),
63
Presidente
Figura 3.2 (a): Um organograma c&
64
65
Figura 3.2 (b): Um organograma mats atual
66
Figura 3.2 (c): Desenvolvimento de sistemas no interior dos setores usurios
provvel que voc tenha muito mais contato direto com os usurios de seu sistema - na
verdade, voc talvez trate diretamente com eles. Tam bm provvel que voc venha a
trabalhar com computadores pessoais e outras pequenas redes de sistemas de
processamento adquiridos dire tamente pelo setor usurio.
3.3 AUDITORES, CONTROLE DE QUALIDADE E PADRONIZADORES
Dependendo do tamanho de seu projeto e da natureza da organi zao em que trabalha
voc pode ter ou no auditores, pessoal de controle de qualidade e/ou membros do setor
de padronizao par ticipando do projeto. Agrupei essas pessoas em uma s categoria
porque o objetivo e as perspectivas delas so em geral semelhantes, se no fo rem iguais.
O objetivo geral dessa heterognea tripulao garantir que o seu sistema ser
desenvolvido de acordo com vrios padres externos (exter nos a seu projeto): padres de
contabilidade desenvolvidos pelo setor de contabilidade de sua empresa; padres
desenvolvidos por outros se tores da organizao ou pelo cliente/usurio que receber seu
sistema; e possivelmente padres impostos por diversos setores normatizadores
governamentais.
Existem trs problemas que devem ser tratados antecipadamente
ao se lidar com auditores, controladores de qualidade ou componentes
do setor de padronizao:
1. Eles muitas vezes no se envolvem no projeto at que esteja terminado - depois que a
anlise de sistemas, o projeto e a programao tenham encerrado suas tarefas e tenha
comeado a atividade de testes formais. Nesse ponto, naturalmente, muito difcil fazer
grandes modificaes no sistema.
2. Eles muitas vezes esto habituados com uma antiga notao ou formato para a
documentao dos requisitos do sistema (p.ex.: fluxogramas). Assim, normalmente
importante asse gurar que os modelos do sistema que voc estiver desen volvendo
(recolha alguns exemplos no captulo 4) sejam compreensveis .
3. Infelizmente, os membros desse grupo esto freqentemente mais interessados na
forma do que na substncia: se seus do cumentos no estiverem exatamente corretos,
podero ser rejeitados.
67
3.4 O ANALISTA DE SISTEMAS
voci O analista de sistemas um membro essencial de qualquer projeto de
desenvolvimento de sistemas, e as sees precedentes deste captulo j lhe deram
diversos exemplos de como o analista de sistemas interage com outros participantes do
projeto.
Em um sentido lato, o analista de sistemas desempenha vrios
papis:
Arquelogo e escriba. Como analista de sistemas uma de suas principais tarefas trazer
luz os detalhes e documentar a orientao comercial que possa existir somente como
folclore tribal, passado de gerao em gerao de usurios.
Inovador. O analista de sistemas deve separar os sintomas do problema do usurio de
suas verdadeiras causas. Com o seu co nhecimento da tecnologia do processamento, o
analista deve auxiliar o usurio a explorar as novas e teis aplicaes dos computadores -
e novas maneiras para o usurio conduzir seus negcios. Embora muitos dos primeiros
sistemas de processa mento apenas perpetuaram os negcios do usurio em velocidade
eletrnica, os analistas de sistemas esto sendo hoje desafiados a auxiliar o usurio a
encontrar produtos e mercados radicalmente novos e inovantes, tornados possveis com o
com putador. Edward De Bono em Lateral Tbinking (IDe Bono, 1970]) vale ser lido pelas
interessantes novas maneiras de pensar sobre problemas.
Mediador. Como j mencionado neste captulo, o analista de sistemas que muitas
vezes se v no meio de usurios, gerentes, programadores, auditores e vrios outros
participantes - que freqentemente se desentendem entre si. Existe a tentao do analista
de sistemas tentar impor sua viso de como o sistema deva parecer ou que funes ele
deva conter. Mas a principal atribuio do analista obter um consenso, o que requer a
deli cada arte da diplomacia e da negociao!
Lder de projeto. No um papel universal, mas ocorre com su ficiente freqncia para
ser mencionado aqui. Como o analista de sistemas costuma ser mais experiente do que os
programa dores do projeto, e como ele designado para o projeto antes que os
programadores iniciem o trabalho, existe uma tendncia natural para atribuir ao analista
as responsabilidades da gerncia do projeto.
68
Isso significa que, como analista de sistemas, voc precisa de mais do que apenas a
capacidade de desenhar fluxogramas e outros diagra mas tcnicos Voc precisa ter
habilidade com as pessoas para entrevistar usurios, mediar desentendimentos e
sobreviver s inevitveis batalhas polticas que ocorrem em todos os projetos, mesmo nos
mais triviais. Vo c precisa de conhecimento de aplicaes para compreender e apreciar a
empresa do usurio. Voc precisa de habilidade em pmcessamento para compreender os
potenciais usos do hardware e do software dos computadores na empresa do usurio. E
(obviamente) voc necessita de uma mente lgica e organizada; voc precisa ser capaz de
visualizar um sistema de vrias perspectivas diferentes, ser capaz de subdividi-lo em
subsistemas de vrios nveis e de pensar em um sistema em termos abstratos e fisicos 12
Ningum disse que era uma tarefa fcil!
3.5 PROJETISTAS DE SISTEMAS
Como ficou implcito em nossas discusses anteriores, o projetista de sistemas a pessoa
(ou grupo de pessoas) que recebe a sada de seu trabalho de anlise de sistemas: a tarefa
dele transformar uma lista isenta de tecnologia dos requisitos do usurio em um projeto
arquitetural de alto-nvel que fornecer a estrutura com a qual os programadores podero
trabalhar. A natureza dessa atividade discutida no captulo 22.
Em muitos casos, o analista de sistemas e o projetista so a mesma pessoa, ou membros
do mesmo grupo unificado de pessoas. Mesmo que sejam pessoas diferentes,
importante para o analista e o projetista de sistemas permanecerem em estreito contato
durante todo o projeto. O motivo disso a realimentao que ocorre entre a anlise e o
projeto de sistemas: o analista de sistemas deve fornecer informaes suficiente mente
detalhadas para que o projetista elabore um projeto tecnologica mente bom, e o projetista
de sistemas deve fornecer informaes sufi cientemente acuradas para que o analista de
sistemas possa dizer se os requisitos do usurio que ele ou ela est documentando so
tecnologica mente viveis. Fundamentando-se nas informaes recebidas do projetis ta de
sistemas, o analista pode ter de negociar com o usurio para mo dificar seus requisitos.
3.6 PROGRAMADORES
Pode-se argumentar que no melhor dos mundos no haveria con tato entre o analista de
sistemas e o programador. Principalmente nos
grandes projetos de desenvolvimento de sistemas, os projetistas se
69
assemelham a um buffer entre os analistas de sistemas e os programadores; isto , os
analistas de sistemas entregam seus produtos (listas dos requisitos do sistema,
independentes da tecnologia) aos projetistas de sistemas que, por sua vez, entregam seus
produtos (uma descrio arquitetural dos componentes dc hardware e software que sero
utilizados para implementar o sistema) aos programadores.
Existe uma outra razo para que o analista de sistemas e os progra madores tenham pouco
ou nenhum contato entre Si: O servio muitas vezes executado de maneira estritamente
seqencial em muitos projetos de desenvolvimento de sistemas . Desse modo, a tarefa
de anlise de sistemas iniciada antes e totalmente executada antes que a tarefa de
programao comece. Isso significa que o analista de sistemas ter mina seu trabalho e
talvez j tenha sido designado para um novo proje to antes que o programador sequer
tenha iniciado sua participao no projeto.
Entretanto, provvel que haja algum contato entre os programa dores e os analistas de
sistemas pelas seguintes razes:
Em pequenos projetos, as tarefas de anlise, projeto e programa o so combinados e,
assim, pode acontecer de uma pessoa fazer o servio de anlise e de projeto de sistemas e
continuar interagindo com o programador. Pode tambm acontecer de uma pessoa
desempenhar funes do projetista de sistemas e do programador.
O analista s vezes serve como gerente do projeto, de modo que, mesmo tendo
terminado a tarefa de especificar os requisi tos do sistema, ainda continuar envolvido no
projeto e ter algum contato com os programadores.
Muitas vezes o programador quem descobre erros e ambigi dades na lista de
requisitos produzida pelo analista de sis temas, porque ele est programando onde, como
diz meu co lega Scott Guthery: o pneu toca a estrada, onde uma lista mal feita do que o
sistema deve fazer torna-se um conjunto de co mandos COBOL especficos e detalhados.
Se estiver faltando alguma coisa, ou se houver algo errado ou confuso, o programa dor
tem duas opes: pedir ao analista de sistemas melhores esclarecimentos ou perguntas ao
usurio .
Como dissemos n captulo 2, muitas empresas esto come ando a perceber que
necessrio substituir os sistemas opera tivos que foram consti h 20 anos. Na imensa
maioria desses projetos de redesei. olvimento praticamente no h
70
documentao que descreva como o sistema funciona, ou (ainda mais importante!) o que
se imagina que o sistema faa. E como os sistemas j tm 20 anos, j existe toda uma
nova gerao de usurios envolvidos; os usurios que estavam mi cialmente envolvidos
na especificao dos requisitos do sistema j se aposentaram ou mudaram de emprego e a
nova gerao de usurios tem apenas uma pequena idia dos detalhados requisi tos
normativos embutidos no sistema. Nesse momento, todas as atenes se voltam para o
programador de manuteno, que tem feito o sistema continuar funcionando nos ltimos
anos; essa pessoa tambm provavelmente um funcionrio da segun da ou terceira
gerao, no tendo tido qualquer contato com os projetistas e programadores que
construram originalmente o sistema! Como afirma Nicholas Zvegintzov (autor do artigo
Soft ware Maintenance News):
At o presente momento, o principal profissional da computao era algum que podia
aprender o suficiente sobre as necessidades das empresas para express-las na linguagem
dos computadores. No futuro, quando nossa sociedade tornar-se irreversivelmente compu
tadorizada, o principal profissional ser algum que possa aprender o suficiente sobre
sistemas computadorizados para express-los em linguagem humana. Sem essa pessoa,
teremos perdido o controle de nossa sociedade. Esse algum o engenheiro s avessas.
Os man tenedores de software so os engenheiros s avessas da sociedade.
Algumas organizaes esto cotneando a modificar suas equi pes de projeto da
estrutura vertical para uma horizontal. A dis tribuio tpica de responsabilidade (que
pressuposta em todo este livro) atribui todas as tarefas de anlise de sistemas a uma
pessoa (ou grupo de pessoas); de modo semelhante, todas as tarefas de projeto so
atribuidas ao projetista e todas as ativida des de programao so entregues ao
programador. Quando se adota essa abordagem parece de fato que os analistas de sis
temas e os programadores tm pouco contato entre si. Porm algumas organizaes
comeam a perceber que existe um con flito inerente a essa abordagem: os analistas de
sistemas so, de hbito, pessoas mais antigas e mais experimentadas dentro da
organizao e, mesmo assim, so solicitados a executar no ape nas a lista conceitual de
alto nvel dos requisitos do sistema, mas tambm os detalhes elementares de nvel inferior
dos requisitos do usurio. Igual conflito existe entre os programadores que ti picamente
so mais jovens e menos expericntes Uma soluo dar ao pessoal tcnico snior (cujo
titulo o de analistas de
71
sistemas) todas as atividades de alto nvel: anlise de sistemas de alto nvel, projetos de
alto nvel e a cod dos mdulos de nvel superior do sistema; de modo anlogo, ao pessoal
tcnico de nvel jnior so dadas atribuies de detalhes de nvel infe rior na rea da
anlise e na rea de projeto e na da programao. Quando essa abordagem seguida, os
analistas de sistemas e os programadores permanecem em estreito contato durante todo o
projeto. Na realidade, cada um deles executa parte do trabalho originalmente feito pelo
outro. Este assunto ser novamente discutido no captulo 23.
3.7 PESSOAL DE OPERAES
Assim como algum poderia argumentar que o analista de sistemas nunca teria contato
com o programador, poder-se-ia afirmar que o ana lista de sistemas no precisa ter
qualquer interao com o pessoal de operaes, que responsvel pelo centro de
processamento, pela rede de telecomunicaes, pela segurana do hardware e dos dados
do com putador, bem como pela execuo dos programas, pela montagem dos diskpacks
e pela manipulao da sada das impressoras. Tudo isso acon tece depois que um novo
sistema foi no somente analisado e projetado, mas tambm programado e testado.
Entretanto, h mais sobre isso do que se pode ver, O analista de sistemas deve conhecer
algumas das restries impostas a um novo siste ma pelo pessoal de operaes, porque
isso deve fazer parte da especifi cao detalhada produzida pelo analista de sistemas. Isto
, o analista de sistemas pode produzir um documento que diga: o novo sistema de
pedidos deve ser capaz de executar as funes X, Y e Z e, para se adaptar aos requisitos
do Departamento de Operaes, ele deve ocupar no mais que 16 megabytes de memria
do computador de grande por te. O sistema deve ser implementado com utilizao de
terminais IBM 3270 comuns interligados rede de telecomunicaes XYZ da empresa.
Em alguns casos, os detalhes operacionais do sistema podem ser uma questo de
negociao entre o usurio e o grupo de operaes do computador central. Isso
particularmente comum hoje, quando os usurios muitas vezes esto em situao de
poderem adquirir seus pr prios computadores pessoais ou minicomputadores de tamanho
adequa do para departamentos. Embora muitos desses computadores possam ser operados
pelo pessoal burocrata ou administrativo da organizao usuria (portanto no precisando
dos talentos especializados do pessoal de operaes), e embora muitos desses
computadores possam funcionar no ambiente de um escritrio normal (no precisando da
fiao especial e do equipamento de ar condicionado tpico dos mainframes), ainda
72
verdade que essas pequenas mquinas tero de se comunicar com o mainframe (p.ex.,
para descarregar parte de um banco de dados combinado, ou para transferir os resultados
do processamento departa mental), e muitas vezes verdadeiro que os pequenos PC (com
putadores pessoais) e/ou minicomputadores precisam se comunicar uns com os outros
atravs de uma rede local ou de algum dispositivo de telecomunicaes. Tudo isso
normalmente envolve interao com o pessoal de operaes; somente um sistema stand
alone realmente independente pode ser construdo sem a assistncia e aprovao daquele
pessoal.
Esses problemas operacionais so documentados em uma parte do
esforo de anlise de sistemas conhecida como modelo de implemen tao do usu Isso
ser visto detalhadamente no capitulo 21.
3.8 RESUMO
Como vimos neste captulo, o analista de sistemas um orquestra- dor, um comunicador
e um facilitador. Ficar evidente nas partes II e III que o analista de sistemas executa um
grande volume de trabalho por ele mesmo, porm ainda mais esforo feito em harmonia
com os ou tros participantes do jogo de sistemas. Como analista de sistemas, quan to
mais voc souber a respeito das pessoas com quem voc vai trabalhar, melhor voc se
sair.
Todos os participantes so pessoas e elas tm diferentes metas, di ferentes prioridades e
diferentes perspectivas. Embora elas possam estar comprometidas com o sucesso do
projeto, eles podem ter preocupaes ocultas que se opem a um ou mais aspectos desse
projeto.
As perguntas e exerccios no final deste captulo destinam-se a fazer voc pensar um
pouco mais sobre esses aspectos. Voc deve con sultar tambm o excelente livro de Block
sobre a poltica de projetos (iBiock, 1982D ou at o clssico livro de Sun Tzu sobre a arte
da guerra [ 1983].
REFERNCIAS
1. Paul Strassman, Information Payoff Nova lorque: Free Press,
1985.
2. Robert Block, The Politics of Projecis. Nova lorque: YOURDON
Press, 1982.
3. Alan BrilI, Buildin8 Controis mio Structured Systems. Nova lorque:
YOURDON Press, 1982.
4. Sun Tzu, The A of War. Nova lorque: Delacorte Press, 1983.
73
5. Edward De Bono, Lateral fl Nova lorque: Penguin Books,
1970.
6. Marjorie Leeson, Systems Analyss and Desi Chicago: Science Research Associates,
1981.
7. Lavette C. Teague, Jr., e Christopher Pidgeon, Structured Analysis Methods for
Computer Infonnation Systems. Chicago: Science Re search Associates, 1985.
PERGUNTAS E EXERCCIOS
1. Indique pelo menos um participante adicionai com quem voce espera interagir em um
projeto de desenvolvimento de sistemas.
2. Descreva um projeto no qual o analista de sistemas no teve conta to direto com o
verdadeiro usurio. Quais foram as vantagens e desvantagens dessa situao? Que
arranjos alternativos foram feitos?
3. Voc pode citar algum outro termo para usurio alm de proprie trio ou cliente?
4. Voc pode imaginar alguma situao em que o analista de sistemas no devesse falar
com o usurio?
5. Quais so as vantagens e desvantagens de o usurio ser um mem bro em tempo integral
da equipe de projeto de desenvolvimento de um sistema? Voc pode imaginar alguns
projetos especficos em que seria particularmente recomendvel que o usurio
participasse da equipe de projeto?
6. Quais so as vantagens e desvantagens de o usurio ser o gerente da equipe de projeto
de desenvolvimento de um sistema? Voc pode imaginar alguns projetos especficos em
que seria particular- mente recomendvel que o usurio gerenciasse o projeto?
7. Quais so as vantagens e desvantagens de o prprio usurio desen volver inteiramente
um sistema de informaes? Voc pode imagi nar alguns projetos em que seria
particularmente recomendvel que o usurio fosse o analista, o projetista, o programador
e o gerente?
8. Qual o conhecimento que o usurio deve ter sobre computadores e sobre software para
poder participar de uma equipe de projeto durante a fase de anlise? Qual o conhecimento
que ele deve ter a respeito das ferramentas e tcnicas da anlise de sistemas?
9. Qual o conhecimento que o usurio deve ter sobre computadores e sobre software para
poder gerenciar uma equipe de projeto de desenvolvimento de sistema? Qual o
conhecimento que ele deve ter a respeito da anlise de sistemas para poder ser um
eficiente gerente?
74
10. Qual o conhecimento que o usurio deve ter sobre computadores e sobre software
para poder desenvolver por ele mesmo todo o projeto de desenvolvimento de um
sistema? Qual o conhecimento que ele deve ter sobre anlise de sistemas?
11. Que precaues especiais voc tomaria como analista de siste mas se voc no tivesse
contato direto com o usurio? Voc acha que as ferramentas de modelagem descritas
neste livro seriam suficientes?
12. A seo 3.1.2 relaciona diversas preocupaes que o usurio ope rativo poderia ter
com um novo sistema. Apresente mais trs prov veis aspectos com que ele pode se
preocupar. Voc acha que essas preocupaes so razoveis, ou elas apenas refletem o
tpico des conhecimento do usurio sobre computadores?
13. Que responsabilidade tica ou moral tem o analista de sistemas em relao ao usurio
operativo se ele estiver convencido de que no haver dispensas de empregados, mas o
usurio est preocupado com que haja? (Veja tambm a pergunta 19).
14. Descreva as circunstncias em que os usurios operativos pode riam causar o fracasso
de um novo sistema. Voc acha que essas circunstncias so realistas? O usurio
supervisor no poderia sim plesmente determinar que o sistema fosse utilizado?
15. Quando voc acha que os problemas da interface humana devem ser discutidos com
os usurios? Logo no incio do projeto? Mais tarde? O que deveria ser negociado? (Voc
pode consultar o captu lo 21, se o desejar).
16. Voc acha que no verdadeiro que os usurios operativos te nham apenas uma viso
local do sistema do qual participam? Voc acha que seguro para o analista de sistemas
considerar is so como correto? Voc acha que essa uma boa situao? Deve o analista
de sistemas tentar dar uma viso global aos usurios operativos?
17. D um exemplo de uma viso fsica, ou orientada para a imple mentao, de um
sistema, que um usurio operativo pode ter. Voc
v algum problema nisso?
18. O que deve fazer o analista de sistemas se o usurio supervisor no deixar que ele se
dirija diretamente aos usurios operativos? Como
o analista de sistemas deve enfrentar tal situao?
19. Que responsabilidade moral ou tica tem o analista de sistemas com o usurio
supervisor se os usurios operativos demonstrarem preocupao com possveis demisses
causadas pelo novo siste ma? (Veja tambm a pergunta 13).
20. D um exemplo de um sistema onde o usurio supervisor pode no estar
familiarizado com os detalhes polticos da empresa que
so presentemente executados pelos usurios operativos.
75
21. Por que os usurios de nvel executivo normalmente no se inte ressam ou se
preocupam com a possvel economia a ser obtida com a reduo do pessoal (por
dispensas ou demisses a pedido) tornada possvel com o novo sistema?
22. Qual o grau de envolvimento que os usurios de nvel execu tivo devem ter no
desenvolvimento de um novo sistema de
informaes?
23. Que opes tem o analista de sistemas se o usurio no entende modelos abstratos em
papel?
24. Como o analista de sistemas deve lidar com os novatos descritos neste captulo? E se
o usurio insistir em uma determinada opo
de hardware ou software para o novo sistema?
25. Que responsabilidade tem o analista de sistemas em conseguir o consenso entre os
usurios? E se ele falhar nesse aspecto?
26. Quais os riscos enfrentados pelo analista de sistemas em relao direo, como
vimos na seo 3.2? O que pode ser feito para
diminuir esses riscos?
27. O que deve fazer o analista de sistemas se as metas e prioridades da direo forem
conflitantes com as do usurio?
28. Quando, na sua opinio, o pessoal de operaes deve se envolver no projeto?
29. A anlise e o projeto de sistemas (e tambm a programao) devem ser
desempenhadas pela mesma pessoa (ou por um grupo coeso
de pessoas)? Quais so as vantagens e desvantagens?
NOTAS
1 Uma situao desse tipo ocorre comumente com o agente contra tante de uma empresa
governamental. Na maioria dos casos, essa pessoa no o usurio e pode no saber muito
a respeito das reais necessidades dele, mas ele ou ela a pessoa designada para man ter
toda a comunicao oficial com o desenvolvedor ou com a empresa desenvolvedora do
sistema.
2 Existem variaes desta terminologia; (Teague e Pidgeon, 19851, por exemplo,
referem-se tambm ao usurio beneficiado, que o que recebe os beneficios do novo
sistema. Essa pessoa pode no ter qualquer contato direto com o sistema, mas se
beneficiar de algum modo com. a melhora do servio ou com a funcionalidade do novo
sistema.
3 Existem problemas relacionados que enfauzam o fato de qu o novo sistema seja parte
de um sistema maior, O usurio pergunta r: ser que ficarei cansado ou vou adquirir
tendinite por ficar sentado frente a um terminal o dia inteiro?; devo me preocupar
76
com a emanao de radiao da tela do monitor?; e se eu no souber digitar?; e, ainda
mais importante, e se esse novo sistema executar o meu servio e me fizer perder o
emprego?
4 No caso extremo, isso tambm significa que so os usurios opera tivos que podem
iniciar ou parar um novo sistema. Eles podem parecer passivos e talvez no disponham
de poder ou autoridade para aprovar o projeto de desenvolvimento de um sistema, mas se
eles o sabotarem ou simplesmente no o utilizarem, o novo sistema ter fracassado.
5 Observe que essa uma caracterstica dos sistemas operativos (como o termo foi
definido no captulo 2), mas geralmente no uma caracterstica dos sistemas de apoio
deciso. Observe ainda que a alta direo est habitualmente mais interessada nos
sistemas que proporcionaro vantagem competitiva do que com os que reduzem a equipe
operativa a uma ou duas pessoas.
6 Mesmo que todos os usurios que voc encontrar no conheam ou no se interessem
pela tecnologia do processamento de dados, voc deve evitar o erro comum de trat-los
como uma forma sub- humana de vida. Os jovens analistas de sistemas e programadores,
principalmente os novatos que comearam a brincar com computa dores quando estavam
no primrio, presumem que todos devem ser fascinados e hbeis com computadores, e
que os que no so assim devem ser ou deficientes mentais ou pertencentes a uma
gerao antiga e portanto no merecedora de qualquer respeito e considerao. No
entanto o mundo est cheio de usurios que no gostam de computadores por vrios e
legtimos motivos e h usu rios que esto ocupados demais como perUos em suas
prprias profisses ou negcios para se preocuparem em se tornarem peritos em
computadores. Eles tm sobre programadores e analistas de sistemas a mesma opinio
que tm de eletricistas, carpinteiros, encanadores e mecnicos de automveis: um
saudvel respeito pela percia e habilidade profissional exigida pelo servio, mas uma
total falta de interesse pelos detalhes. A compreenso deste aspecto ir, em muitos casos,
determinar se voc ter sucesso ou fracassar em seus principais projetos como analista
de sistemas.
7 Uma analogia: se voc quisesse mandar construir uma casa, voc comearia por
conversar com um arquiteto sobre as desejadas ca ractersticas da casa. Depois de muita
discusso, o arquiteto iria para seu escritrio e depois eventualmente lhe apresentaria
alguns desenhos e/ou modelos em escala da casa. Se voc se recusasse a examinar os
desenhos ou objetasse serem eles muito matemti cos, as possibilidades de sucesso do
arquiteto seriam bem reduzi das. O que voc poderia fazer era conduzir o arquiteto a uma
casa J existente e dizer: faa-me uma casa como esta!. Infelizmente,
77
dificilmente podemos fazer isso na rea do processamento de da
dos e, por causa disso, a protot por vezes um modo vivel
de se obter a mesma coisa.
8 tambm encorajador ver-se que mais e mais desses peritos es
to se transferindo para posies de alta direo de empresas co
merciais e de liderana em outros setores da sociedade. O Citybank
e a American Airlines, para no mencionar vrias empresas de
processamento e outras de alta-tecnologia, so dirigidas por pes
soas que galgaram essa posio vindo dos quadros do processa
mento de dados e, em meados da dcada de 80, havia cerca de
meia-dzia de membros do Congresso que tinham sido original-
mente programadores e analistas de sistemas.
9 Entretanto, s vezes o analista de sistemas est muito envolvido na
gerncia do projeto. Discutiremos esse aspecto com mais detalhes
no captulo 16 e no apndice B.
10 Estudaremos mais detalhadamente o backlog de aplicaes no
captulo 6.
11 Entretanto, pelo menos em alguns casos, isso est se modificando.
Por exemplo, muitas das 8 grandes firmas de contabilidade nos
Estados Unidos esto agora inteiramente familiarizadas com as fer
ramentas de documentao de anlise estruturada descritas neste
captulo; assim, elas no devem ter problemas em participar de
um dos seus projetos como auditor.
12 Na realidade, por causa dessa necessidade de conhecimento em
muitas reas que a maioria dos cientistas do processamento de da
dos considera que a inteligncia artifical e os sistemas especialistas
no podero ser aplicados anlise de sistemas por mais alguns
anos ainda. Este assunto tambm abordado no captulo 25.
13 Discutiremos algumas alternativas a essa abordagem seqencial,
principalmente as conhecidas como desenvolvimento evolutivo, ou
fast tracking, no captulo 5. Na realidade, em alguns projetos a
anlise de sistemas continua em andamento juntamente com a
programao.
14 Na realidade, o contato direto entre o programador e o usurio
mais comum do que voc pode imaginar. Em muitos casos, o ana
lista de sistemas no se esfora em escrever os detalhes do nvel
inferior do sistema, e os usurios de alto nvel com quem o analista
de sistemas se comunica podem desconhecer ou estar desinteressa
dos nesses detalhes. Assim, muitas vezes acontece de o programa
dor precisar falar diretamente ao usurio de baixo nvel para des
cobrir eratamente o que o sistema deve fazer. Isso importante,
porque muitas empresas deploram o fato de que 50% de seus pro
jetos de desenvolvimento de sistemas so despendidos em testes;
na verdade, pode ser que o trabalho que esteja em andamento sob
78
o ttulo oficial de testes sejam, de fato, tarefas de anlise de siste mas que poderiam (e
provavelmente deveriam) ter sido executadas mais cedo.
79
4
FERRAMENTAS
DA ANHSE
E STRUTURADA
A Natureza tem algum tipo de sistema coordenado aritmtico- geomtrico, porque ela
tem todas as espcies de modelos, O que conhe cemos da natureza est em modelos, e
todos os modelos da natureza so muito belos, O que me surpreende que o sistema da
natureza seja de uma beleza fracionria, porque em qumica consideramos que as asso
ciaes so sempre em belos nmeros inteiros - no e.x fraes.
R. Buckminster Fuiler, em In the Outlaw Area: profile by Calvin Tompkins,
The New Yorker, 8 de janeiro de 1966
O homem um animal utilizador de ferramentas ... Sem ferramentas ele no nada, com
ferramentas ele tudo.
Thomas Carlyle,
Sartor Resartus, Livro 1, Captulo 4
Neste captulo, aprenderemos:
1. Para que um analista de sistemas usa ferramentas de modelagem.
2. A natureza e os componentes de um diagrama de banco de dados.
3. Os componentes de um dicionrio de dados.
4. Os componentes de uma especificao de processos.
5. Como modelar dados armazenados e relacionamen tos de dados.
6. Como modelar o compori.amcnto tempo-dependente de um sistema.
7. Como modelar a estrutura de um programa.
81
A maior parte do trabalho que voc ir fazer como analista de sistemas envolve a
modelagem do sistema que o usurio deseja. Como veremos neste captulo, e em maiores
detalhes na parte II, existem mui tos diferentes tipos de modelos que podemos
desenvolver - assim como existem muitos modelos diferentes que um arquiteto poder
usar na construo de uma nova casa. Os modelos de anlise de sistemas discutidos neste
livro so, na maior parte, modelos de papel de sistemas- em-ser, isto , representaes
abstratas daquilo que, eventualmente, se tornar uma combinao de hardware e software
de computadores.
O termo modelo pode soar um tanto formal e amedrontador, po rm, representa um
conceito que voc tem usado por quase toda a sua
vida. Considere os seguintes tipos de modelos:
Mapas: modelos bidimensionais do mundo em que vivemos.
Globos: modelos tridimensionais do mundo em que vivemos.
Fluxog ramas: Represcntacs esquemticas dc decises e se qncia de atividades para
execuo dc algum procedimento.
Desenhos arquitetnicos: Representaes esquemticas de um edifcio ou de uma ponte.
Pautas musicais: Representaes grficas/textuais das notas mu sicais e tempo de uma
pea musical.
Embora voc no saiba como interpretar o modelo arquitetnico mostrado na figura 4.1,
o conceito de tal modelo no dever assust-lo. No muito difcil imaginar que se pode
aprender a ler e a compreender tal modelo, mesmo que voc no pretenda criar algum.
Similarmente, voc provavelmente ainda no sabe como interpretar muitos dos mode los
usados pelos analistas de sistemas, mas saber como l-los e cri-los no final deste livro.
Os usurios com quem voc trabalha certamente estaro aptos a interpretar os modelos
(com uma pequena assistncia inicial) e devero, tambm, ser capazes de cri-los.
Por que devemos construir modelos? Por que no basta apenas construir o sistema? A
resposta que podemos construir modelos de maneira a realar ou enfatizar, certos
recursos decisivos de um sistema, enquanto, simultaneamente, relegamos outros aspectos
do sistema. Isto permite que nos comuniquemos com o usurio de uma maneira clara,
sem nos distrairmos pelos aspectos e caractersticas do sistema que consideramos
irrelevantes. E, se aprendermos que o nosso conheci mento sobre os requisitos do usurio
estava incorreto (ou que o usu rio mudou de opinio sobre eles), podemos modificar o
modelo ou
82
abandon-lo e construir um novo, se necessrio. A alternativa enta bular algumas
discusses iniciais com o usurio e, em seguida, construir o sistema inteiro; o risco,
certamente, que o produto final pode ser ina ceitvel e pode ser extraordinariamente
caro modific-lo nessa altura.
Ento, o analista de sistemas usa ferramentas de modelagem para:
Focalizar a ateno nas caractersticas importantes do sistema, dando menos ateno s
menos importantes.
Discutir modificaes e correes nos requisitos do usurio com baixo custo e mnimo
risco.
Verificar se o analista de sistemas conhece, corretamente, o ambiente do usurio e o
documentou de uma tal maneira que os
projetistas e programadores possam construir o sistema.
Nem todas as ferramentas de modelagem cumprem essas finali dades: por exemplo, uma
descrio narrativa de 500 pginas dos requisi tos do usurio (que , na realidade, um
modelo) poder (1) tornar com pletamente obscuras todas as caractersticas do sistema,
(2) tornar a construo do sistema mais cara do que o prprio sistema, (3) falhar na
verificao do entendimento do analista de sistemas sobre as reais neces sidades do
usurio. No captulo 8, exploraremos detalhadamente que caractersticas uma ferramenta
de modelagem deve ter para que seja til ao analista de sistemas.
-
:
ri
1
Figura 4.1: Um modelo arquitetnico tpico
83
Agora, vamos apresentar e discutir resumidamente trs important ferramentas de
modelagem de sistemas: o diagrama de fluxo de dados, diagrama de entidades-
relacionamentos e o diagrama de transies estado. O diagrama de fluxo de dados ilustra
as jisnes que o sisten deve executar; os diagramas de entidades-relacionamentos do
nfa aos relacionamentos de dados, e o diagrama de transies de esta focaliza o
comportamento tempo-dependente do sistema. Os captulos e 16 exploram essas e outras
ferramentas de modelagem com mai res detalhes. Como veremos, as trs principais
ferramentas de m delagem consistem em grficos (figuras) e ferramentas de modelage
textual de suporte. Os grficos fornecem uma maneira vivida e de f leitura para o
analista de sistemas mostrar aos usurios os princip componentes do modelo, bem como
as conexes (ou interfaces) entre componentes. As ferramentas de modelagem textual de
suporte forn cem definies precisas ou exatas do s1Rn dos componentes das conexes.
4.1 A MODELAGEM DAS FUNES DO SISTEMA:
O DIAGRAMA DE FLUXO DE DADOS
Um antigo ditado da atividade de desenvolvimento de sistem enfatiza que um sistema de
processamento de dados envolve dados processamento, e que no se pode construir um
sistema com xito sem participao de ambos os componentes. O processamento de um
sist ma , certamente, um aspecto importante para ser modelado e exarr nado com o
usurio. A modelagem de que estamos tratando pode & descrita de vrias maneiras:
Que funes deve o sistema executar? Quais so as intera entre as funes?
Que transformaes deve executar o sistema? Que entradas si transformadas em que
sadas?
Que espcie de trabalho faz o sistema? Onde ele obtm a info mao para faz-lo? Para
onde ele remete os resultados do tr:
balho?
A ferramenta de modelagem que usamos para descrever a transfo
mao de entradas em sadas o diagrama de fluxo de dados. Ui
diagrama de fluxo de dados tpico mostrado na figura 4.2.
Os diagramas de fluxo de dados consistem em processos, d
psitos de dados, fluxos e terminais:
84
Figura 4.2: Um diagrama defluxo de dados tpico
Processos so mostrados como crculos ou bolhas no diagrama. Eles representam as
diversas funes individuais que o sistema
executa. Funes transformam entradas em sadas.
Flu.xos so representados por setas direcionadas curvas. Elas so as conexes entre os
processos (funes do sistema), e repre sentam a informao que os processos exigem
como entrada e/ou as informaes que eles geram como sada.
Depsitos de dados so mostrados por duas linhas paralelas ou por uma elipse. Eles
mostram colees (agregados) de dados que o sistema deve manter na memria por um
perodo (tempo). Quando os projetistas de sistemas e programadores terminam a
construo do sistema, os depsitos existiro, tipi camente, como arquivos ou bancos de
dados.
Terminadores mostram as entidades externas com as quais o sistema se comunica. Os
terminadores so, tipicamente,
indivduos, grupos de pessoas (p.ex., um outro departamento
85
ou diviso da orgamzao), sistemas externos de computador e organizaes externas.
O diagrama de fluxo de dados discutido em maiores detalhes no captulo 9 (alm de
processos, fluxos e depsitos, o diagrama de fluxo de dados pode tambm ter fluxos de
controle, processos de controle e depsitos de controle. Eles so teis para a modelagem
de sistemas de tempo-real e so discutidos em mais detalhes no capitulo 9).
Embora o diagrama de fluxo de dados oferea uma prtica viso geral dos principais
componentes funcionais do sistema, no fornece qualquer detalhe sobre esses
componentes. Para mostrar os detalhes de qual informao transformada e como
transformada, precisamos de duas ferramentas de suporte textual de modelagem: o
dicionrio de dados e a espec de processos. A figura 4.3 mostra um tpico dicionrio de
dados para o diagrama de fluxo de dados que vimos na figura 4.2. De modo anlogo, a
figura 4.4 mostra uma tpica especifica o de processos para um processo do diagrama
de fluxo de dados que vimos na figura 4.2.
nome = nome-de-cortesia + primeiro-nome +
(nome-intermedirio) + ltimo-nome
ttulo-de-cortesia = [
primeiro-nome = Icaracter-vlidol
ltimo-nome = lcaracter-vlido}
caracter-vlido = (A-Zla-zII-l I
Figura 4.3: Um dicionno de dados t4
1. lF a quantia em dlares das faturas vezes o nmero de semanas devidas for maior do
que $10.000 THEN:
a. D uma fotocpia da fatura para o vendedor apropriado que ir chamar o cliente.
b. Anote no verso da fitura que uma cpia foi dada ao vendedor, com a data m que isso
foi feito.
c. Recoloque a fatura no arquivo para exame em duas semanas a partir desta data.
86
2. OTHERWISE IF mais do que quatro faturas atrasadas forem enviadas THEN:
a. D uma fotocpia da fatura ao vendedor adequado para que o cliente seja chamado.
b. Registre no verso da fatura que a cpia foi dada ao vendedor, com a data em que isso
foi feito.
c. Recoloque a fatura no arquivo para ser examinada uma semana aps essa data.
3. OTHERWISE (a situao ainda no atingiu srias propores):
a. Acrescente 1 contagem da observao de atraso no verso da fatura (se a conta no foi
registrada, escreva contagem
de fatura atrasada = 1).
b. IF a fatura no arquivo est ilegvel THEN digite uma outra.
c. Envie ao cliente uma fotocpia da fatura, com o carimbo Ensima nota : atraso de
fatura. Por favor, remeta imedia tamente, onde N o valor da contagem da nota de
atraso.
d. Registre no verso da fatura a data em que a ensima obser vao de atraso foi enviada.
e. Recoloque a fatura no arquivo por duas semanas a partir dessa data.
Figura 4.4: Uma rpica espec de processos
Ainda existe muito mais a ser dito sobre diagramas de fluxo de dados, dicionrios de
dados e especificaes de processos; os detalhes constam nos captulos 9 a 11. Veremos,
por exemplo, que a maioria dos sistemas complexos modelada com mais de um
diagrama de fluxo de dados. T fato podem existir dezenas ou mesmo centenas de
diagramas organizados em nveis hierrquicos. Veremos, tambm, que existem
convenes para a rotulao e numerao de itens do diagrama, bem como algumas
diretrizes e regras que ajudam a distinguir entre os bons e os maus diagramas.
87
4.2 A MODELAGEM DE DADOS ARMAZENADOS: O
DIAGRAMA DE ENTIDADES - RELACIONAMENTOS
Embora o diagrama de fluxo de dados seja, de fato, uma ferramen ta til para a
modelagem de sistemas, ele somente enfatiza um aspecto principal de um sistema: suas
funes. A notao de depsito de dados no DFD nos apresenta a existncia de um ou
mais grupos de depsitos de dados, mas, deliberadamente, diz muito pouco acerca de
detalhes de dados.
Todos os sistemas armazenam e usam informaes sobre o am biente com o qual
interagem; algumas vezes as informaes so mni mas, porm na maioria dos sistemas,
atualmente, so bastante comple xas. No somente queremos saber, em detalhes, que
informao est contida em cada depsito de dados, mas tambm que relacionamentos
existem entre os depsitos de dados. Esse aspecto do sistema no est realado pelo
diagrama de fluxo de dados, mas est ativamente retratado por uma outra ferramenta de
modelagem: o diagrama de entidades-rela cionamentos. Um diagrama entidades-
relacionamentos tpico mostrado na figura 4.5.
O diagrama entidades-relacionamentos possui dois importantes componentes:
1. T de objetos so apresentados por um quadro retangular no diagrama de entidades-
relacionamentos. Um tipo de objeto representa uma coleo, ou conjunto, ou objetos
(coisas) do mundo real cujos membros desempenham um papel no sistema que est sendo
desenvolvido. Eles podem ser identificados de forma nica, podendo serem descritos por
um ou mais fatos (atributos).
2. Relacionamentos so representados por losangos no diagrama. Um relacionamento
representa um conjunto de conexes ou as sociaes, entre os tipos de objetos
interligados por setas ao relacionamento.
Assim como no caso do diagrama de fluxo de dados, existe muito mais para ser dito
sobre o diagrama de entidades-relacionamentos; ns o discutiremos mais detalhadamente
no captulo 12. Veremos que existem certos tipos de objetos especializados, bem como
algumas diretrizes para assegurar que o diagrama de entidades-relacionamentos est
completo e consistente.
Assim como no caso do diagrama de fluxo de dados, ele ser ne cessrio para aumentar o
diagrama de entidades-relacionamentos com
88
Figura 4.5: Um diagrama de entidades-relaciona nwnjos
detalhadas informaes textuais, O dicionrio de dados, que vimos pri meiro na figura
4.3, tambm pode ser usado para manter informaes apropriadas sobre objetos e
relacionamentos. Isto ser explorado, mais adiante, nos captulos 10 e 12.
4.3 A MODELAGEM DO COMPORTAMENTO TEMPO-
DEPENDENTE: O DIAGRAMA DE TRANSIES DE ESTADO
Um terceiro aspecto de muitos sistemas complexos o compor tamento tempo-
dependente, a seqncia na qual se tem acesso aos dados e em que as funes sero
executadas. Para alguns sistemas co merciais de processamento, isso no um aspecto
importante para ser destacado, uma vez que a sequncia trivial em princpio. Desse
modo,
89
em muitos sistemas de processamento batch (aqueles que no s on une e nem de tempo-
real), a funo N no pode executar sua tarefa at que receba as entradas necessrias; e
sua entrada produzida como sada da funo N-1; etc.
Entretanto, muitos sistemas on-line e de tempo-real, ambos na rea de negcios e na rea
cientfica e de engenharia, tm complexos relacio namentos de tempo que devem ser
modelados to cuidadosamente quanto as funes e relacionamentos de dados. Muitos
sistemas de tem po-real, por exemplo, devem responder dentro de um intervalo de tempo
muito curto, talvez em poucos segundos, a determinadas entradas que chegam do
ambiente externo. E precisam estar preparados para diversas combinaes e seqncias
de entradas para as quais respostas apropriadas devem ser elaboradas.
A ferramenta de modelagem que usamos para descrever esse as pecto do comportamento
de um sistema o diagrama de transies de estado, algumas vezes abreviado como DTE.
Um diagrama tpico mostrado na figura 4.6; ele modela o comportamento de uma
mquina de lavar controlada por computador. Nesse diagrama, os retngulos re presentam
os estados em que o sistema pode estar (isto , cenrios ou situaes reconhecveis).
Cada estado, portanto, representa um pero do de tempo durante o qual o sistema exibe
algum comportamento ob servvel; as setas que interligam os retngulos mostram a
mudana de estado ou transies de um esrado para outro. Associada a cada mudan a de
estado h uma ou mais condies (os eventos ou circunstncias que causaram a mudana
de estado) e zero ou mais aes (a resposta, sada ou atividade que ocorrem como parte
da mudana de estado). Examinaremos o diagrama de transies de estado em mais
detalhes no captulo 13.
4.4 A MODELAGEM DA ESTRUTURA DO PROGRAMA:
O DIAGRAMA ESTRUTURAL
Apesar de no o usar muito como analista de sistemas, voc deve conscientizar-se de que
muitas ferramentas adicionais dc modelagem so usadas durante o desenvolvimento de
um sistema complexo. Por exem plO, OS projetistas de sistemas costumam usar o
diagrama de fluxo de dados, o dicionrio de dados, as especificaes de processos, os
diagra mas de entidades-relacionamentos e os diagramas de transies de esta do criados
pelo analista de Sistemas para criar uma arquitetura em software, isto , uma hierarquia
de mdulos (algumas vezes citados como sub-rotinas ou procedimentos) para
implementar os requisitos do sistema. Uma ferramenta de modelagem grfica comum
usada para representar essa hierarquia de software um diagrama estrutural; um
90
INICIAR
ATIVAR ENCHENE
LAVADORA CHEIA
ATIVAR LAVANDO
LAVANDO
) DE LAVAGEM TERMINADO ATIVAR SECAGEM
j SECANDO
L
CICLO DE SECAGEM
TERMINADO
DESATIVAR SECAGEM
Figura 4.6: Diagrama de Itransies de estado
diagrama estrutural tpico mostrado na figura 4.7. Nesse diagrama, cada retngulo
representa um mdulo (p.ex., uma sub-rotina FORTRAN, um procedimento PASCAL,
um pargrafo ou subprograma COBOL). As setas que interligam os quadros representam
chamadas de mdulos (p.ex., chamadas de sub-rotina ou de procedimentos). O diagrama
tam bm apresenta os parmetros de entrada passados para cada mdulo chamado, e os
parmetros de sada retornados pelo mdulo quando ele termina a sua tarefa e restitui o
controle a quem o chamou.
Embora o diagrama estrutural seja uma excelente ferramenta pa ra os projetistas de
sistemas, no o tipo de modelo que, normalmente, deve ser mostrado ao usurio, porque
ele modela um aspecto da imple mentao do sistema, em vez dos requisitos subjacentes .
Discutiremos os diagramas estruturais novamente no captulo 22.
L
PARADA
J
PARAR
DESATIVAR
ENCHENDO
ENCHENDO
PARAR
DESATIVAR LAVANDO
91
Figura 4.7: Um diagrama estrutural
4.5 RELACIONAMENTOS ENTRE OS MODELOS
Como se pode ver, cada modelo grfico descrito neste captulo focaliza um aspecto
diferente de um sistema: o DFD mostra as funes,
o DER reala os relacionamentos de dados e o DTE enfatiza o comportamento tempo-
dependente do sistema. til estudar cada um desses aspectos isoladamente, pois existe
muita complexidade em um sistema tpico; por outro lado, essas trs vises do sistema
devem ser consistentes e compatveis entre si.
No captulo 14, examinaremos algumas regras de consistncia que asseguram que os trs
principais modelos de sistema, combinados com detalhados modelos textuais so, de fato,
consistentes. Por exemplo, veremos que cada depsito no DFD deve corresponder a um
objeto ou a um relacionamento do DER.
4.6 RESUMO
Os modelos apresentados neste captulo so, relativamente, sim ples e fceis de ler. Muito
cuidado foi tomado para faz-los dessa maneira, pois eles foram concebidos para serem
lidos e entendidos por usurios sem muito treinamento ou preparao. Entretanto, como
92
veremos nos captulos 9 a 16, necessrio um grande volume de cuida doso trabalho para
criar os diagramas e assegurar que eles sejam repre sentaes completas, consistentes e
corretas dos requisitos do usurio.
PERGUNTAS E EXERCCIOS
1. A introduo ao captulo 4 lista mapas, globos, fluxogramas, dese nhos arquitetnicos e
pautas musicais como exemplos de modelos.
Enumere mais trs exemplos de modelos de uso comum.
2. Qual , no dicionrio, a definio de modelo? Essa definio aplica- se aos sistemas de
informaes?
3. Por que os modelos so usados no desenvolvimento de sistemas de informaes?
Apresente trs motivos.
4. Como responder se o usurio lhe dissesse que os modelos so uma perda de tempo e
que voc deveria iniciar a codificao?
5. Voc acha que uma descrio verbal do usurio sobre os requi sitos do sistema seriam
considerados um modelo? Por que?
6. Por que seria til ter mais de um modelo para um sistema?
7. Todos os modelos discutidos no captulo 4 so modelos em papel. Pode voc imaginar
quaisquer outras formas de modelos?
8. Os modelos discutidos no captulo 4 so, em sua maioria, ferra mentas grficas (isto ,
figuras). Quais so as vantagens do uso de
figuras como ferramentas de modelagem?
9. Voc acredita que as ferramentas grficas de modelagem so sufi cientes para
representar os requisitos de um sistema de informa es? Por qu?
10. Quem o responsvel pela criao dos modelos necessrios descrio dos requisitos
de um sistema de informaes?
11. Os usurios devem criar seus prprios modelos? Se assim for, sob quais
circunstncias?
12. Quais so os trs principais objetivos de um diagrama de fluxo de dados?
13. Quais so os quatro principais componentes de um diagrama de fluxo de dados?
14. Observe que os processos de um DFD so representados por cr culos e os
terminadores por retngulos. Voc acha que isso seja significativo? E se os processos
fossem representados por re tngulos e os terminadores por crculos?
15. Observe que a figura 4.2 mostra trs diferentes processos mas no indica como
muitos computadores participaro do sistema. Isso importante? Que mudanas seriam
necessrias se a equipe de pro jeto decidisse implementar o sistema com um computador?
E com trs computadores?
93
-JIIJ
Observe que a figura 4.2 mostra diversos fluxos de dados entre os processos, mas no
indica o meio fsico que ser utilizado para transportar os dados. Isso importante? E se
os imple mentadores do sistema decidissem transmitir os dados entre os processos
utilizando linhas de telecomunicaes? E se resolvessem transportar os dados de um
processo para outro por meio de fitas magnticas?
Para que serve o dicionrio de dados?
Quem o responsvel pela criao do dicionrio de dados? E por sua atualizao?
A figura 4.3 mostra a definio de dicionrio de dados para um nome. Qual o
significado dos parnteses, ( ), naquela definio? Para que serve a especificao de
processos?
Quantas especificaes de processos devem constar de uma com pleta especificao dos
requisitos do usurio?
Quem o responsvel pela criao da especificao de processos? E por sua atualizao?
Observe que a especificao de processos mostrada no exemplo do captulo um tanto
parecida com um programa. O que voc acha da idia de se utilizar pseudocdigo para se
escrever especi ficaes de processos? O que voc pensa da idia de se usar uma
linguagem de programao real como Ada, como muitos j sugeriram - para a
especificao de programas? Por que uma lin guagem de programao seria boa ou m?
Para que serve o diagrama de entidades-relacionamentos? Quais so os trs principais
componentes de um DER?
Quantos tipos de objetos so mostrados na figura 4.5? Quantos relacionamentos so
mostrados na figura 4.5?
O DER mostra ao leitor alguma informao relativa s funes executadas pelo sistema?
O DFD mostra ao leitor alguma informao relativa aos tipos de objetos ou aos
relacionamentos entre os tipos de objetos de um sistema?
Onde devemos descrever os detalhes dos tipos de objetos e dos relacionamentos
mostrados em um DER?
Para que serve o diagrama de transies de estado? Quais so os componentes de um
DTE?
Os DTE so teis para a modelagem de sistemas de processamen to batch? Por qu?
Para que serve um diagrama estrutural?
Quais so os componentes grficos de um diagrama estrutural?
O usurio deve ser capaz de ler e entender um diagrama estrutural? Deve-se esperar que o
usurio seja capaz de criar um?
Descreva o relacionamento existente entre um DER e um DFD.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
94
38. Existe algum relacionamento entre um DFD e um diagrama estrutu ral? Se assim for,
qual ?
NOTA
Como dissemos no captulo 3, alguns usurios so mais conhece dores de computadores
do que outros, e alguns usurios tm parti cipao mais ativa no projeto de
desenvolvimento de sistemas do que outros. Se voc estiver trabalhando com um usurio
que um membro de tempo integral da equipe do projeto, ou talvez mesmo o lder do
projeto e se o usurio tem algum conhecimento sobre projeto de sistemas, no existe
razo para que no lhe seja apre sentado um diagrama estrutural. Entretanto, se o usurio
estiver interessado apenas em descrever o que o sistema tem de fazer, provavelmente no
estar interessado em examinar um diagrama descrevendo a organizao de sub-rotinas
FORTRAN que imple mentaro aqueles requisitos.
95
5
CICLO DE VIDA
DO PROJETO
Todo o erro humano a impacincia, uma renncia prematura ao
mtodo, uma ilusria fixao a uma iluso.
Franz Kafka, Cartas
Neste captulo, aprenderemos:
1. O conceito de ciclo de vida de um projeto.
2. As caractersticas do ciclo dc vida do projeto clssico.
3. As diferenas entre projetos clssicos e semi-estrutu rados.
4. Os componentes do ciclo de vida estruturado.
5. As diferenas entre ciclos de vida radicais e conserva dores.
Para sermos analistas de sistemas eficientes, precisamos de algo alm de ferramentas de
modelagem; precisamos de mtodos. Na ativida de de desenvolvimento de sistemas, os
termos mtodo, metodologia, ciclo de vida do projeto e ciclo de vida do desenvolvimento
de sistemas so usados alternativamente. Na parte III examinaremos detalhadamente os
mtodos de anlise de sistemas, no contexto mais amplo de mtodo
- conhecido como ciclo de vida estruturado de projeto - para a execu o de todo o
desenvolvimento de um novo sistema.
Antes da introduo do ciclo de vida estruturado de projeto, importante examinar o
ciclo de vida do projeto clssico discutido em muitos livros e usados atualmente em
muitas organizaes de desenvol vimento de sistemas, principalmente para identificar
suas limitaes e fraquezas. Esse exame ser seguido por uma breve discusso sobre o
97
cido de vida de um projeto semi-estruturado: um ciclo de vida de pro jeto que inclui
alguns, mas no todos os elementos do moderno de senvolvimento de sistemas. Em
seguida, apresentaremos o ciclo de vida de projeto estruturado, atravs de uma viso
geral mostrando as principais atividades e como elas se ajustam. Para finalizar, examinare
mos, resumidamente, o ciclo de vida de protoupao popularizado por Bernard Boar,
James Martin e diversos fornecedores de linguagens de programao de quarta gerao.
Exploraremos, tambm, o conceito de desenvolvimento iterativo ou top-down. De modo
especial, apresentaremos a noo de desenvol vimento top-down radical e
desenvolvimento top-down conse7vador.
Dependendo da natureza do projeto de desenvolvimento de sistemas poder haver razes
vlidas para a adoo de uma abordagem em detrimento da outra; na realidade, alguns
projetos sugerem uma combi nao das duas.
5.1 O CONCEITO DE CICLO DE VIDA DE UM PROJETO
Como se poderia esperar, as pequenas organizaes de PED ten dem a ser relativamente
informais. Os projetos de desenvolvimento de sistemas so iniciados como resultado de
um entendimento verbal entre o usurio e o gerente do projeto (que pode ser, tambm, o
analista de sistemas, o programador, o operador de computador e o zelador), e o trabalho
se estende desde a anlise de sistemas at o projeto e imple mentao sem muito
estardalhao.
Nas grandes organizaes, entretanto, tudo feito de maneira muito mais formal. As
comunicaes entre os usurios, a gerncia e a equipe do projeto tendem a ser
documentadas por escrito e todos enten dem que o projeto correr atravs de diversas
fases at sua prontificao. Mesmo assim surpreendente ver as grandes diferenas com
que dois gerentes de projetos na mesma organizao conduzem seus respectivos projetos.
Na realidade, muitas vezes deixado a critrio do gerente do projeto a determinao de
quais fases e atividades seu projeto ser cons titudo e como essas fases sero
conduzidas.
Recentemente, entretanto, a abordagem utilizada no desenvolvi mento de sistemas
comeou a se modificar. Cada vez mais, grandes e pequenas organizaes esto adotando
um nico ciclo de vida de proje to uniforme - tambm conhecido como plano de projeto
ou metodolo gia de desenvolvimento de sistemas ou, simplesmente, o modo como
fazemos as coisas por aqui. Habitualmente contido em um livro de apontamentos to
volumoso como os manuais comuns que costumam estar (no lidos) em qualquer mesa de
analista ou de programador, o
98
ciclo de vida do projeto documentado oferece um modo simples para qualquer pessoa da
organizao de desenvolvimento de sistemas entrosar-se com a atividade de
desenvolvimento de um sistema de processamento.
A abordagem pode ser do tipo feita em casa ou como alternativa, a organizao de
desenvolvimento de sistemas pode preferir comprar um pacote de gerenciamento de
sistemas e, em seguida, adapt-lo s necessidades da empresa Parece ser evidente que
alm de empregos para as pessoas que criam manuais de ciclo de vida de projetos (e para
os que escrevem livros sobre eles), a metodologia de projeto desejvel. Qual , ento, o
propsito de ter-se um ciclo de vida de projeto? Existem trs objetivos principais:
1. Para definir as atividades a serem executadas em um projeto de desenvolvimento de
sistemas.
2. Para introduzir consistncia entre muitos projetos de desenvol vimento de sistemas da
mesma organizao.
3. Para introduzir pontos de verificao para o controle gerencial de decises.
O primeiro objetivo parucularmente importante em uma grande organizao na qual
novas pessoas constantemente alcanam os cargos de gerenciamento de projetos. O
inexperiente gerente de projeto pode no perceber ou subestimar a signiflcncia das fases
importantes do projeto se apenas seguir a intuio. De fato, pode acontecer de os
programadores jnior e os analistas de sistemas no entenderem onde e como seus
esforos se ajustam no projeto a menos que recebam uma descrio correta de todas as
fases dele.
O segundo objetivo tambm importante em uma. grande empre sa. Nos nveis mais
altos de gerenciamento, pode ser extremamente desconcertante supervisionar uma
centena de projetos diversos, cada qual sendo executado de um modo diverso. Por
exemplo, se o projeto A define a atividade da anlise de sistemas de forma diferente do
projeto B e o projeto B no prev uma fase de projeto de sistemas, como o gerente de
segundo ou de terceiro nvel poder saber qual projeto est com problemas e qual
continua dentro dos prazos previstos ?
O terceiro objetivo do ciclo de vida de um projeto comum relacio na-se com a
necessidade da gerncia de controlar um projeto. Em pro jetos triviais o nico ponto de
verificao , provavelmente, o fim do projeto. Ele terminou a tempo e dentro do
oramento especificado? Ou mais simplesmente, ele est todo terminado? Observou os
requisitos do usurio? Mas, em projetos maiores, a gerncia deve ter vrios pontos de
99
verificao intermedirios durante o projeto,os quais oferecem as opor tunidades de
determinar se o projeto est fora das previses e se ser preciso obter recursos adicionais.
Alm disso, um usurio inteligente tambm exigir pontos de verificao em vrios
estgios do projeto a fim de poder determinar se deve continuar investindo nele .
Em vista disso, permita-me enfatizar que o ciclo de vida de projeto de modb algum
responsvel pelo projeto. Ele no libera o gerente da dificil responsabilidade de tomar
decises, avaliar alternativas, travar batalhas polticas, negociar com usurios
recalcitrantes, levantar o moral de programadores desanimados ou qualquer das
provaes e tribulaes relacionadas ao projeto. O gerente do projeto ainda tem que
gerenciar, em todos os sentidos da palavra. A nica ajuda que o ciclo de vida do projeto
pode dar o?ganizar as atividades do gerente, tornando mais provvel que os problemas
sejam atacados no momento apropriado.
5.2 O CICLO DE VIDA DO PROJETO CLSSICO
O tipo de ciclo de vida do projeto usado em muitas organizaes hoje difere daquele ao
qual iremos dar maior ateno na parte III. O ciclo de vida do projeto clssico ou
convencional mostrado na figura
5.1. Todo projeto executado mediante algum tipo de anlise de siste mas, projeto e
implementao, mesmo que isso no seja feito exatamen te da maneira mostrada no
diagrama. O ciclo de vida de projeto usado na sua organizao, por exemplo, pode
divergir do mostrado na figura 5.1 em um ou em todos os seguintes pontos:
A fase de levantamento e a fase de anlise podem ser reunidas em uma s fase (isso
especialmente comum em organizaes
em que qualquer coisa que o usurio queira considerado vivel em princpio).
Pode no haver uma fase chamada estudo do hardware se for garantido que qualquer
novo sistema pode ser implementado
em um computador existente sem causar srios impactos opera cionais.
As fases preliminares de projeto e de projeto detalhado podem ser reunidas em uma
nica fase chamada projeto.
Algumas das fases de teste podem ser agrupadas numa s fase. Na realidade elas
podem, at, ser reunidas codificao.
Assim, o ciclo de vida de projeto de uma organizao individual
100
pode ter cinco, sete ou doze fases, porm, ainda c9ntinuar sendo da variedade clssica.
O que que de fato caracteriza o ciclo de vida de um projeto como clssico? Duas
caractersticas existem: uma forte tendncia implemen tao bottom-up do sistema e a
insistncia na progresso linear e se qencia! entre uma fase e a seguinte.
5.2.1 A Implementao Bottom-Up
O uso da implementao bottom-up uma das maiores fraque zas do ciclo de vida do
projeto clssico. Como voc pode ver na figura 5.1(a), espera-se que os programadores
executem todos os testes de seus mdulos primeiro, em seguida o teste de subsistemas e,
por fim, o teste do sistema. Essa abordagem , tambm, conhecida na rea computacio
na! como ciclo de vida em cascata, com base em um diagrama apresen tado em
[ 19701, e depois popularizado por Barry Boehm em EBoehm, 1981]. Esse diagrama
mostrado na figura 5.1 (b).
No se conhece a origem dessa abordagem, porm pode ter sido emprestada de indstrias
de fabricao em linha de montagem. A abor dagem de implementao bottom-up boa
para montar automveis em uma linha de montagem, mas somente depois que o prottipo
tiver sido completamente corrl,ido ! Infelizmente, muitas organizaes de desen
volvimento de sistemas esto ainda produzindo sistemas um-de-cada-ti po, para os quais
a abordagem bottom-up tem vrias dificuldades srias:
Nada est terminado at que esteja totalmente pronto. Assim, se o projeto estiver
atrasado e o prazo fina! coincidir com o meio do teste de sistema, no haver nada para
mostrar ao usurio exceto uma enorme pilha de listagens de programas - que nada
significam para ele!
Os erros mais triviais so encontrados no incio do perodo de teste e os erros mais
srios so encontrados no fina!. Isso quase uma tautologia. Testes de mdulos cobrem
os erros relati vamente simples de lgica dentro dos mdulos individuais; os testes de
sistema, por outro lado, cobrem os erros principais de interface entre os subsistemas. O
ponto que os mais importan tes erros de interface no so os que o programador deseja
encontrar no final de um projeto em desenvolvimento. Tais er ros podem levar
modificao de muitos mdulos, e podem ter um devastador impacto no programa na
hora em que todos se sentem cansados e irritados de ter trabalhado de maneira exaus tiva
por tantos meses.
101

requisitos do
oramento, cronograma
especificao funcional
de
programas
sistema testado
Figura 5.1(a): O cirlo de vida do projeto clssico
102
A depurao de erros tende a ser extremamente dificil durante os estgios finais dos
testes do sistema. Observe que distingui mos aqui entre teste e depura o. A depurao
a arte de des cobrir onde est o erro (e a determinao subseqente de como corrigi-lo)
depois do processo de teste ter determinado que existe um erro. Quando um erro
descoberto durante a fase de teste de sistema de um projeto bottom-up muitas vezes
extremamente difcil dizer qual o mdulo que contm o erro; ele
1
Figura 5.1(b): O modelo em cascata de desenvolvimento de sistemas
103
pode estar em qualquer uma das centenas (ou milhares) de mdulos que tenham sido
combinados pela primeira vez. Locali zar o erro , freqentemente, o mesmo que
procurar uma agulha em um palheiro.
As necessidades de tempo de computador para testes aumentam exponencialmente
durante os estgios finais dos testes. Mais es pecificamente, o gerente do projeto muitas
vezes considera que necessita de perodos contguos maiores de tempo do computa dor
para testes do sistema, talvez 12 horas ininterruptas por dia. Como todo esse tempo de um
computador , muitas vezes, difcil de se conseguir 6, o projeto poder sofrer um atraso.
5.2.2 Progresso Seqencial
A segunda principal fraqueza do ciclo de vida do projeto ciassico e sua insistncia em que
as fases se organizem seqencialmente uma em seguida outra. Existe uma tendncia
natural e humana para que seja assim. Desejamos ser capazes de dizer que terminamos a
fase de anlise de sistemas e que nunca mais teremos que nos preocupar com ela
novamente. Na realidade, muitas organizaes formalizam essa noo com um ritual
conhecido como congelamento das especificaes ou congelamento dos documentos do
projeto.
O nico problema com esse desejo de progresso metdica que ela completamente
irreal! Em particular, a abordagem seqencial no permite que os fenmenos do mundo
real ocorram com o pessoal, com a orientao ou com a economia da empresa. Por
exemplo, a pessoa que est fazendo o trabalho, tal como o analista de sistemas ou o
projetista, pode ter cometido um erro e ter produzido algo defeituoso. Na realida de,
como seres humanos, raramente realizamos corretamente um traba lho complexo na
primeira vez, mas somos muito bons no aperfeioa mento repetido de um trabalho
imperfeito. Ou a pessoa que revisa o trabalho, em particular, o usurio que reexamina o
servio do analista de sistemas, pode ter cometido um erro. Ou talvez a pessoa que
executa o trabalho associado a cada fase pode no ter tempo suficiente para terminar, mas
pode no querer admitir esse fato. Esse um modo polido para se dizer que, nos projetos
mais complexos, a anlise e o projeto de sistemas (e os testes de sistema, tambm)
terminam quando algum de ade que seu tempo acabou, e no quando voc pretende
finalizar aquelas atividades!
Outros problemas esto normalmente associados ao ciclo de vida
do projeto clssico seqencial. Durante muitos meses (ou anos) que se
leva para desenvolver o sistema, o usurio pode mudar de idia sobre o
104
que o sistema deve fazer. Durante o perodo que se leva para desenvol ver o sistema,
certos aspectos do ambiente do usurio podem se alterar (p.ex., a economia, a competio
ou os regulamentos do governo que afetam as atividades do usurio).
Uma caracterstica adicional do ciclo de vida do projeto clssico que ele se baseia em
tcnicas ultrapassadas. Isto , ele no faz uso de projeto estruturado, programao
estruturada, caminhamentos ou qual quer uma das outras tcnicas modernas de
desenvolvimento Mas, como a vida do projeto clssico ignora a existncia dessas
tcnicas, no h nada que impea o gerente do projeto de us-las. Infelizmente, muitos
programadores, analistas de sistemas e lderes de projeto de primeiro nvel acham que o
ciclo de vida do projeto uma diretriz da orientao da alta direo e se a direo nada
disser sobre o uso de programao estruturada, eles, como meros membros de projeto e
lderes, no sero obrigados a usar abordagens no clssicas.
5.3 O CICLO DE VIDA SEMI-ESTRUTURADO
Os comentrios na seo anterior fazem com que a maioria das organizaes de PED
paream ainda estar vivendo na era do obscurantis mo. Na realidade, tal caracterizao
injusta: nem todas as organizaes usam a vida do projeto clssico. Comeando no final
da dcada de 70 e no incio da dcada de 80 houve um crescente reconhecimento de que
as tcnicas como projeto estruturado, programao estruturada e imple mentao top-
down deveriam ser oficialmente reconhecidas no ciclo de vida de projetos. Esse
reconhecimento conduziu ao ciclo de vida de projeto semi-estruturado mostrado na figura
5.2; ali aparecem duas evi dentes caractersticas ausentes na abordagem clssica:
1. A seqncia bottom-up de codificao, testes de mdulos e testes de sistema
substituda pela implementao top-down, uma abordagem onde os mdulos de alto nvel
so codificados e testados em primeiro lugar, seguidos pelos mdulos deta lhados de
baixo nvel. H, tambm, uma forte indicao de que programao estruturada ser usada
como mtodo real de codificao.
2. O projeto clssico substitudo pelo projeto estruturado, uma abordagem formal de
projeto de sistemas discutida em livros
como lYourdon e Constantine, 19891 e IPage-Jones, 19881.
Paralalemante a essas diferenas bvias, existem alguns pontos
sutis acerca desse ciclo de vida modificado. Considere, por exemplo, que
a implementao top-down significa que alguma codificao e alguns
105
testes ocorram paralelamente. Isso certamente representa um importante afastamento das
fases seqenciais que vimos no ciclo de vida clssica! Em particular, pode significar uma
realmentao entre a atividade de codificao e de teste e a de depurao de erros.
Quando o programador testa a verso reduzida de alto nvel do sistema, ele pode ser visto
resmungando, Ora, eu no sabia que essa instruo FRAMMIS de dupla preciso
funcionava assim! Naturalmente, voc pode ter certeza de que o subseqente emprego da
instruo FRAMMIS de dupla preciso ser completamente diferente.
Talvez mais importante, o uso da implementao top-down leva os implementadores (e os
analistas de sistemas, se eles no abandonaram o projeto nessa altura) a consultar os
usurios aps as especificaes terem sido cerimoniosamente congeladas. Desse modo,
possvel que o usu rio aponte erros e equvocos na especificao; o usurio pode at ex
pressar o desejo de alterar a especificao, e se a entrevista acontecer diretamente entre o
usurio e o implementador, uma alterao pode realmente ser efetuada antes que o
gerente do projeto saiba o que est acontecendo. Resumindo, a implementao top-down
muitas vezes cau sa a realimentao entre o processo de implementao e o processo de
anlise - embora essa realimentao no seja especificamente mostrada na figura 5.2 e o
usurio e o gerente do projeto de PED possam per feitamente negar que isso ocorra!
Existe um detalhe final sobre o ciclo de vida semi-estruturado: uma parte significativa do
trabalho que ocorre sob o ttulo de projeto estruturado realmente um esforo manual
para corrigir especificaes narrativas mal feitas. Pode-se notar isso na figura 5.3, que
descreve os detalhes do projeto estruturado (Observe que essa figura consiste em detalhes
do processo 3 da figura 5.2).
Na figura 5.3, a atividade 3.1 (rotulada CODIFICAT ESPECIFI CAO FUNCIONAL)
representa uma tarefa que os projetistas tinham de fazer tempos atrs: transformar um
documento narrativo, monolti co, ambguo e redundante em um modelo til, no
procedural, para servir como base na derivao da hierarquia dos mdulos que im
plementaro os requisitos dos usurios. Em outras palavras, as pessoas que utilizam
projeto estruturado tm presumido, tradicionalmente, que receberiam uma especificao
clssica. Em conseqncia, a primeira tarefa, do ponto de vista delas, transformar essas
especificaes em um pacote de diagramas de fluxo de dados, dicionrios de dados,
diagramas de entidades-relacionamentos e especificaes de processo.
Este um trabalho mais dificil do que voc possa imaginar; histo ricamente, tem sido
uma tarefa executada no vcuo. Os projetistas, geralmente, tinham pouco contato com o
analista de sistemas que escrevia a longa especificao narrativa e eles, certamente, no
tinham contato com o usurio!
106
de testes
projeto
empacota
sistema
Figura 5.2: O ciclo de vida do projeto semi-estruturado
Obviamente, tal situao est pronta para ser alterada. A introdu o da anlise
estruturada do tipo moderno de abordagem de anlise de sistemas apresentado neste livro
- no contexto, e a expanso da idia de realimentao entre uma parte do projeto e um
outro, cria um tipo inteiramente diferente do ciclo de vida do projeto. o ciclo de vida de
projeto estruturado, que discutiremos a seguir.
107
exigncias de
oramento, cronograma
dados de configurao de hardware
especificao funcional
diagramas de fluxo de dados
DE RI VAF DIAGRAR
diagrama estrutural
diagramas de fluxo de dados, especificaes de processos, dicionrio de dados_-
3.3
PROJETAR MDULO
diagr estrul
dados de configurao
Figura 5.3: Detalhes da atividade de projeto
108
5.4 O CICLO DE VIDA DE PROJETO ESTRUTURAI)()
Agora que j vimos o ciclo de vida do projeto clssico e o ciclo de
vida de projeto semi-estruturado, estamos prontos para examinar o ciclo
de vida estruturado, que mostrado na figura 5.4.
Examinaremos sucintamente as nove atividades e os trs terminais do ciclo de vida do
projeto, como mostrado na figura 5.4. Os terminais consistem em usurios, gerentes e
pessoal da operao (como voc de ve estar lembrado, discutimos essas funes no
captulo 3). Eles so indivduos ou grupos de individuos que fornecem entradas equipe
do projeto e que so os ltimos receptores do sistema. Eles interagem com as nove
atividades que mostramos na figura 5.4. Cada uma das atividades resumida nas sees
seguintes:
5.4.1 Atividade 1: O Levantamento
Essa atividade tambm conhecida como estudo de viabilidade ou estudo inicial das
atividades. Tipicamente, comea quando um usurio solicita que uma ou mais partes de
sua atividade sejam automatizadas. Os principais objetivos da atividade de levantamento
so os seguintes:
Ident os usurios responsveis e desenvolver um escopo inicial do sistema. Isso pode
envolver a realizao de uma srie de entrevistas para ver quais usurio(s) esto
envolvidos no (ou afetados pelo) projeto proposto e quais no esto Pode en volver,
tambm, o desenvolvimento de um diagrama de con texto inicial - um simples diagrama
de fluxo de dados do tipo mostrado na figura 4.2, no qual o sistema inteiro est represen
tado por um nico processo .
Ident as atuais deficincias no ambiente do usurio. Con sistir, habitualmente, em uma
lista narrativa simples das fun es que estejam faltando ou que estejam atuando de modo
in satisfatrio no sistema atual. Por exemplo, ela poderia incluir de claraes como as que
se seguem:
O hardware do sistema atual no confivel, e o fornecedor acaba de entrar em
falncia.
No possvel efetuar a manuteno do software do sistema atual e no poderemos
mais contratar programadores de ma nuteno que concordem em manter software na
linguagem de programao usada para desenvolver o sistema atual.
109
110
Figura 5.4: O ciclo de vida de projeto estruturado
O tempo de resposta para o sistema atual on-line de entrada de pedidos to ruim que
muitos clientes desistem, frustra dos, antes de apresentarem seus pedidos.
O sistema atual incapaz de produzir relatrios do governo requisitados pelo Tax
Reform Act do ano passado.
O sistema atual incapaz de receber relatrios de limite de crdito do departamento de
contabilidade e no pode produzir os relatrios de tamanho mdio de pedidos para o
departamento de comercializao.
Estabelecer metas e objetivos para um novo sistema. Isto pode ser tambm uma lista
narrativa simples constituda pelas funes
existentes que necessitem ser reimplementadas, novas funes
que necessitem ser acrescentadas, e critrios de desempenho
para o novo sistema.
Determinar se possvel automatizar o sistema e, se assim for, sugerir alguns esquemas
aceitveis. Isto envolver algumas esti mativas grosseiras e aproximadas do cronograma e
do custo de construo de um novo sistema e dos benefcios a serem obti dos; ele
tambm envolver dois ou mais esquemas (p.ex., o esquema do mainframe, o esquema de
processamento dis tribudo etc.). Apesar da gerncia e dos usurios, muitas vezes,
desejarem uma estimativa detalhada, precisa neste ponto, o analista de sistemas ter sorte
se puder estimar o tempo, os recursos e os custos dentro dos limites de 50% neste
estgio primitivo do projeto.
Preparar uma previso do projeto que ser usada para con duzir o restante do projeto. A
previso do projeto incluir toda a
informao listada acima, bem como identificar o gerente res ponsvel do projeto. Pode
descrever, tambm, os detalhes do
ciclo de vida que o resto do projeto seguir.
O levantamento ocupa, tipicamente, somente 5% a 10% do tempo e dos recursos de todo
o projeto, e para os pequenos e simples pode no ser tambm uma atividade formal.
Entretanto, mesmo que no venha a consumir muito do tempo ou dos recursos o
levantamento uma ativida de crtica: ao fim, a gerncia pode decidir cancelar o projeto
se ele no parecer atrativo do ponto de vista custo/benefcio.
Como analista de sistemas, voc pode ou no estar envolvido no levantamento. O
usurio, juntamente com os elementos dos nveis apro priados de gerncia, pode t-lo
feito antes mesmo de voc ter ouvido falar sobre o projeto. No entanto, para projetos
grandes e complexos, o levantamento envolve tanto trabalho detalhado que o usurio
muitas vezes solicitar ao analista de sistemas que se envolva to logo seja possvel.
Ns no discutiremos o levantamento em mais detalhes neste livro. Se voc se envolver
nessa atividade, pode achar teis os apndices E e C. Para detalhes adicionais, consulte
lDickinson, 19811, Core e Stubbe, 19831 e LYourdon, 19881.
111
5.4.2 Atividade 2: Anlise de Sistemas
O principal propsito da atividade de anlise transformar as suas duas principais
entradas, critrio do usurio e previso do projeto, em uma especificao estruturada. Isso
envolve a modelagem do ambiente do usurio com diagramas de fluxo de dados,
diagramas de entidades- relacionamentos, diagramas dc transies dc estado e as outras
ferra mentas apresentadas no caplulo 4; essas ferramentas so cobertas em detalhes na
parte II.
O processo passo a passo da anlise de sistemas (p.ex., as subati vidades da atividade de
anlise na figura 5.4) discutido na parte III. Como veremos, ele envolve o
desenvolvimento de um modelo ambiental (discutido no captulo 18) e o
desenvolvimento de um modelo comportamental (discutido nos captulos 19 e 20). Esses
dois modelos se combinam para formar o modelo essencial (discutido no captulo 17) que
representa uma descrio formal do que o novo sistema deve fazer, in dependente da
natureza da tecnologia que ser usada para implementar aqueles requisitos.
Em acrscimo ao modelo do sistema descrevendo os requisitos do usurio, um mais
cuidadoso e detalhado conjunto de oramentos e cl culos de custo-benefcio preparado,
geralmente, ao final da atividade de anlise. Isso estudado em mais detalhes no
apndice C.
Obviamente, como analista de sistemas, isto onde voc poder gastar a maior parte do
seu tempo. No h mais nada a dizer sobre a atividade de anlise neste ponto, uma vez
que ele o assunto do restan te deste livro.
5.4.3 Atividade 3: Projeto
A atividade de projeto ocupa-se da alocao de partes da especifi cao (tambm
conhecida como o modelo essencial) aos processadores apropriados (UCP e/ou pessoas) e
para tarefas apropriadas (ou jobs, ou parties etc) no interior de cada processador. No
interior de cada tare fa, a atividade de projeto ocupa-se com o desenvolvimento de uma
hierarquia apropriada de mdulos de programa e interfaces entre esses mdulos para
implementar a especificao criada na atividade 2. Alm disso, a atividade de projeto
ocupa-se com a transformao de modelos de dados de entidades-relacionamentos cm um
projeto de banco de dados. Ver llnmon, 19881 para maiores detalhes.
Parte dessa atividade ser do seu interesse como analista de siste mas: o desenvolvimento
de alguma coisa chamada de modelo de imple mentao do u.surto. Esse modelo
descreve os problemas de imple mentao que o usurio se sente firme o suficiente para
no deix-los a
112
critrio dos projetistas e programadores dos sistemas. Os principais problemas pelos
quais o usurio normalmente est interessado so a es pecificao da fronteira homem-
mquina e a especificao da interface homem-mquina. A fronteira homem-mquina
separa as partes do modelo essencial que devem ser executadas por uma pessoa (como
uma atividade manual) das partes que devem ser implementadas em um ou mais
computadores. Similarmcnte, a interface homem-mquina uma descrio do formato e
da seqncia de entradas fornecidas pelos usu rios humanos ao computador (p.ex.,
projetos de tela e dilogo on-line entre o usurio e o computador), bem como o formato
e sequncia das sadas fornecidas pelo computador ao usurio. O modelo de implemen
tao do usurio descrito no captulo 21.
Uma introduo ao processo de projeto de sistemas pode ser en contrada no captulo 22.
Material adicional pode ser encontrado em lYourdon e Constantine, 19891, IPage-Jones,
19881, Uackson, 19751 e outros.
5.4.4 Atividade 4. Implementao
Essa atividade inclui a codificao e a integrao de mdulos em um resumo
progressivamente mais completo do sistema final. Desse modo, a atividade 4 inclui a
programao estruturada e a implementao top-down.
Como voc pode imaginar, essa , tipicarnente, uma atividade em que o analista de
sistemas no est envolvido, embora existam alguns projetos (e algumas organizaes)
onde a anlise de sistemas, o projeto e a implementao so feitos pela mesma pessoa.
Esse tpico discutido em mais detalhes no captulo 23.
5.4.5 Atividade 5: A Gerao do Teste de Aceitao
A especificao estruturada deve conter todas as informaes ne cess para definir um
sistema aceitvel do ponto de vista do usurio. No entanto, uma vez que a especificao
tenha sido gerada, o trabalho pode comear na atividade de gerar um grupo de casos de
testes de aceitao a partir da especificao estruturada.
Como o desenvolvimento dc testes de aceitao pode ocorrer em paralelo com as
atividades de projeto e implementao, possvel que voc possa ser designado para essa
tarefa depois dc terminar o desenvol vimento do modelo essencial na atividade 2. Os
testes so discutidos em maiores detalhes no captulo 23.
113

5.4.6 Controle de Qualidade


Controle de qualidade conhecido tambm como teste final ou teste de aceitao. Esta
atividade exige como entrada os dados do teste de aceitao gerados na atividade 5 e um
sistema integrado produzido pela atividade 4.
O analista de sistemas pode estar envolvido na atividade de con trole de qualidade, mas
isso normalmente no acontece. Um ou mais membros da organizao usuria pode
assumir a responsabilidade, ou ela pode ser executada por um grupo independente de
testes ou pe lo Departamento de Controle de Qualidade. Conseqentemente, no
discutiremos a funo de controle de qualidade em qualquer outro detalhe.
Observe, a propsito, que algumas pessoas se referem a esta ativi dade como controle de
qualidade em vez de garantia de qualidade. In dependentemente da terminologia,
precisamos de uma atividade para garantir que o sistema apresentar o nvel apropriado
de qualidade; isto o que chamamos neste livro de controle de qualidade. Observe, tam
bm, que importante executar atividades de controle de qualidade, atravs de todas as
atividades iniciais para assegurar que elas esto sen do realizadas em um nvel apropriado
de qualidade. Desse modo, a atividade CQ deve ser realizada atravs das atividades de
anlise, projeto e programao para assegurar que o analista est desenvolvendo especi
ficaes de alta qualidade, o projetista est desenvolvendo um projeto de alta qualidade e
o programador est escrevendo cdigo de alta qua de. A atividade de controle identificada
aqui meramente o teste final da qualidade do sistema.
5.4.7 Atividade 7 Descrio dos Procedimentos
Por todo este livro ns nos preocupamos com o desenvolvimento de um sistema inteiro -
no somente a parte automatizada, mas tam bm a parte a ser executada por pessoas.
Desse modo, uma das ativi dades importantes a serem realizadas a gerao de uma
descrio for mal das partes do novo sistema que sero manuais, e de uma descrio de
como os usurios realmente vo interagir com a parte automatizada do novo sistema. A
sada da atividade o manual do usurio.
Como se pode imaginar, isso tambm uma atividade na qual voc poder se envolver
como analista de sistemas. Embora no a discutamos mais detalhadamente neste livro,
voc pode consultar livros tcnicos para obter informaes adicionais sobre como
escrever os manuais do usurio.
114
5.4.8 Atividade 8: Converso de Bancos de Dados
Em alguns projetos, a converso de bancos de dados envolvia mais trabalho (e mais
planejamento estratgico) do que o desenvolvimento de programas para o novo sistema;
em outros casos, poderia no haver qualquer banco de dados a ser convertido. No caso
mais geral, essa atividade exige, como entrada, o banco de dados atual do usurio, bem
como a especificao do projeto produzida pela atividade 3.
Dependendo da natureza do projeto, voc poder ou no se envol ver na atividade de
converso de banco de dados como analista de sistemas. Entretanto, no discutiremos
essa atividade em maiores deta lhes neste livro.
5.4.9 Atividade 9: Instalao
A atividade final, obviamente, a instalao. Suas entradas so o manual do usurio
produzido pela atividade 7, o banco de dados con vertido produzido pela atividade 8, e o
sistema aprovado produzido pela atividade 6. Em alguns casos, entretanto, a instalao
pode significar, simplesmente, uma passagem noturna para o novo sistema, sem ne
nhuma comemora ou fanfarra, em outros casos, a instalao poder ser um processo
gradual, com um grupo de usurios aps o outro rece bendo os manuais do usurio, o
hardware e sendo treinado no uso do novo sistema e realmente comeando a us-lo.
5.4.10 Resumo do Ciclo de Vida do Projeto Estruturado
importante que voc veja a figura 5.4 pelo que ela : um diagra ma de fluxo de dados.
Ela no um fluxograma; no existe implicao que toda a atividade N deva terminar
antes do incio da atividade N+1. Ao contrrio, a rede de fluxos de dados interligando
atividades implica em que algumas atividades podem ser executadas em paralelo. por
esse aspecto no seqencial que usamos a palavra atividade no ciclo de vida do projeto
estruturado, em lugar da palavra mais convencional fase. O termo fase referia-se,
tradicionalmente, a um perodo d tempo de um projeto em que uma e somenteuma
atividade era executada.
Existe mais alguma coisa que deve ser enfatizada sobre o uso de um diagrama de fluxo de
dados para descrever o ciclo de vida do pro jeto. Um diagrama de fluxo de dados
clssico, tal como o da figura 5.4, no mostra explicitamente realimentao nem
control&. Virtualmente cada uma das atividades na figura 5.4 pode produzir e
habitualmente produz informaes que podem causar modificaes apropriadas a uma
115
ou mais das atividades precedentes. Desse modo, a atividade de projeto pode produzir
informaes que tm a possibilidade de causar a reviso de algumas das decises de
custo/beneficio que acontecem na atividade de anlise. Na realidade, o conhecimento
obtido na atividade de projeto pode at exigir a reviso das primeiras decises sobre a
viabilidade bsi ca do projeto.
Na realidade, nos casos extremos, certos eventos que acontecem em qualquer atividade
podem causar o trmino repentino de todo o projeto. A entrada da gerncia mostrada
somente para a atividade de anlise por ser a nica atividade que necessita de dados da
gerncia; presume-se, entretanto, que a gerncia exera controle sobre todas as
atividades.
Resumindo, ento, a figura 5.4 somente nos informa a(s) entrada(s) necessria(s) a cada
atividade e a(s) sada(s) produzidas. A seqncia de atividades pode estar envolvida
apenas na extenso em que a presena ou ausncia de dados torna possvel o incio de
uma atividade.
5.5 IMPLEMENTAO RADICAL VERSUS TOP-DOWN CONSERVADORA
Na seo anterior, mostrei que o iclo de vida do projeto estrutura do permite que mais de
uma atividade ocorra de cada vez. Deixe-me dizer isso de uma outra maneira: na situao
mais extrema, todas as atividades do ciclo de vida do projeto estruturado podem
acontecer simultaneamente. No outro extremo, o gerente do projeto pode decidir a adoo
da abordagem seqencial, com o trmino de toda uma atividade antes do incio de uma
outra.
prtico ter-se uma terminologia para ajudar na discusso sobre esses extremos, bem
como sobre compromissos entre os dois extremos. Uma abordagem radical do ciclo de
vida do projeto estruturado uma em que as atividades de 1 a 9 tm lugar em paralelo
desde o incio do projeto, isto , a codificao comea no primeiro dia do projeto e o
levantamento e a anlise continuam at o ltimo dia do projeto. Em contraste, numa
abordagem con.servadora de ciclo de vida do projeto estruturado, toda a atividade N
completada antes do incio da atividade
N+1.
Obviamente, nenhum gerente de projeto em seu juzo perfeito ado taria qualquer desses
dois extremos. O que preciso entender que os extremos radical e conservador
definidos acima so as duas pontas de um leque de escolhas - isso est ilustrado na figura
5.5. Existe um nmero infinito de escolhas entre os extremos radical e conservador. Um
gerente de projeto poderia decidir finalizar 75% da atividade de levanta mento, seguidos
pela complementao de 75% de anlise de sistemas, e,
116
em seguida, 75% do projeto, a fim de produzir uma razovel verso reduzida de um
sistema cujos detalhes poderiam ser aperfeioados, em seguida, por um segundo passo
atravs do ciclo de vida do projeto. Ou, o gerente poderia decidir terminar todo o
levantamento e a anlise, seguida pela complementao de 50% do projeto e 50% da
implemen tao. As possibilidades so verdadeiramente interminveis!
ULTRA MODERADAMENTE MODERADAMENTE ULTRA
RADICAL RADICAL CONSERVADORA CONSERVADORA
Figura 5.5: Opes de implementao radical e conseivadora
Como um gerente de projeto decide se adota uma abordagem radi cal ou uma abordagem
conservadora? Basicamente, no h uma resposta
exata. A deciso habitualmente baseada nos seguintes fatores:
Quo inconstante o usurio?
Qual a presso sobre a equipe do projeto para produzir resul tados imediatos e
tangveis?
Qual a presso sobre o gerente do projeto para produzir um cronograma, um
oramento e avaliao de pessoas e outros
recursos?
Quais so os perigos de ser cometido um grande erro tcnico?
Como voc pode perceber, nenhuma dessas perguntas tem uma resposta simples e direta.
Por exemplo, no se pode perguntar ao usu rio do sistema, em uma conversa casual: A
propsito, quo inconstante voc est hoje? Por outro lado, o gerente do projeto deve
estar apto a avaliar a situao, com base na observao, especialmente se ele for um
veterano que negociou com muitos usurios e com muitos gerentes de nvel superior
antes.
Se o gerente do projeto conclui que est tratando com um usurio inconstante - um cuja
personalidade do tipo que adia as decises finais at que ele veja como o sistema vai
funcionar - ele provavelmen te optaria por uma abordagem mais radical. O mesmo vale
se o gerente estiver lidando com um usurio inexperiente, que tenha tido muito pou cos
sistemas construdos para ele. Por que levar anos desenvolvendo um conjunto
absolutamente perfeito de especificaes somente para des cobrir que o usurio no
entendeu o significado das especificaes?
117

Se, entretanto, o gerente estiver tratando com um usurio veterano que est
absolutamente seguro do que quer, e se o usurio trabalha em uma rea de negcios
estvel e que dificilmente se modificar radical- mente em perodos mensais, ento o
projeto pode receber uma aborda gem mais conservadora. Certamente existem muitas
situaes interme dirias: o usurio pode ter certeza de algumas funes comerciais a se
rem realizadas, mas pode se sentir um pouco inseguro a respeito dos tipos de relatrios e
informaes gerenciais que gostaria que o sistema fornecesse. Ou, se o usurio estiver
familiarizado com os sistemas de processamento batch, ele poderia se sentir inseguro do
impacto que um sistema on-line teria na empresa.
Alm da inconstncia existe um segundo fator a ser considerado: a presso para produzir
resultados imediatos e palpveis. Se, devido a presses polticas ou outras presses
externas, a equipe de projeto preci sar simplesmente acelerar um projeto e execut-lo em
uma data especfi ca, ento recomendvel uma abordagem um tanto radical. O gerente
do projeto ainda corre o risco de ter somente 90% do sistema completo quando chegar a
data fatal, mas, ele pelo menos ter um sistema funcio nando em 90%, o que poder ser
demonstrado e talvez at posto em produo. Isto normalmente melhor do que ter
terminado toda a an lise de sistemas, todo o projeto e todo o cdigo, porm nada de
testes.
Naturalmente, todos os projetos esto sob alguma presso por re sultados tangveis;
simplesmente uma questo de grau, e um aspecto que pode ser bastante dinmico. Um
projeto se que inicia com baixa intensidade, com um cronograma confortvel, pode de
repente tornar-se de alta prioridade e ter a data limite adiantada em seis meses ou em um
ano. Uma das vantagens de fazer a anlise de sistemas, o projeto, a codi ficao e a
implementao top-down que se pode parar uma atividade em qualquer ponto e deixar
os detalhes restantes para consideraes subseqentes; enquanto isso, a anlise de
sistemas de alto nvel que te nha sido completada pode ser usada para comear o projeto
de alto nvel, e assim por diante.
Outro fator em gerenciamento de projeto o requisito sempre presente, em organizaes
maiores, para produzir cronogramas, avalia es, oramentos e coisas semelhantes. Em
algumas organizaes, isso tende a ser feito de uma forma consideravelmente informal,
tipicamente porque os projetos so relativamente pequenos e porque a direo sente que
qualquer erro de avaliao te um impacto insignificante em toda a organizao. Nesses
casos, po e-se adotar uma abordagem radical, mesmo que as estimativas sejan apenas
adivinhaes. Em contraste, projetos maiores necessitam de estimativas relativamente
detalhadas de requisitos de pessoal, recursos de computador e assim por diante; e isso s
pode ser feito depois que tiverem sido feitos o levantamento, a anlise e o projeto
detalhados. Em outras palavras, quanto mais detalhadas e
118
exatas tiverem ue ser as estimauvas, mais provavei sera que o projeio siga uma
abordagem conservadora.
Finalmente, o gerente de projeto deve considerar o perigo de cometer um erro tcnico
maior. Por exemplo, suponha que toda a sua experincia anterior como gerente de projeto
tenha sido com um peque no sistema de processamento batch em um IBM System/36. E
agora, subitamente, se encontre com a incumbncia de desenvolver um sistema de
informaes gerenciais de banco de dados distribudo de multipro cessamento de tempo-
real on-line que processar 2 milhes de transa es por dia, a partir de 5.000 terminais
espalhados pelo mundo. Em tais situaes, um dos perigos da abordagem radical
descobrir uma grande falha de projeto depois que uma grande parte do sistema inicial de
alto nvel ter sido implementado.
Ele pode descobrir, por exemplo, que para o seu maravilhoso siste ma funcionar, um
mdulo de baixo nvel tem de executar sua tarefa em 19 microssegundos - porm seus
programadores, de repente, avisam que no existem meios de codificar um mdulo to
eficiente - no em COBOL, nem em C, e nem mesmo em (ugh!) linguagem assembly. En
to, ele deve estar atento ao fato de que a adoo da abordagem radical exige que seus
analistas de sistemas e projetistas escolham um top para o seu sistema relativamente
cedo rio jogo, e existe sempre o perigo de descobrir, na descida at a base, que eles
escolheram o top errado!
No entanto, considere um outro cenrio: o gerente de projeto deci diu construir um
sistema de PED com um novo hardware, um novo sistema operacional, um sistema de
gerenciamento de banco de dados (produzido por algum que no o fornecedor do
hardware) e um novo pacote de telecomunicaes (produzido por um outro fornecedor).
Todos os fornecedores tm manuais atraentes e lustrosos descrevendo seus produtos, mas
eles nunca interfacearam seus respectivos produtos de hardware e software. Quem sabe
se eles trabalharo juntos? Quem sabe se a taxa de desempenho apregoada por um
fornecedor ser des truda pelos recursos de sistema usados por um dos demais fornecedo
res? Certamente, em um caso como esse, o gerente de projeto poderia escolher uma
abordagem radical, de modo que a verso inicial do siste ma pudesse ser usada para
explorar possveis problemas de interface e de interao entre os componentes dos
fornecedores.
Se o gerente do projeto estiver na direo de um tipo familiar de sistema, algo assim
como o seu sistema de pagamento, ento, provavel mente, ter uma boa idia sobre quo
realistas so suas metas. possvel que se lembre de seu ltimo projeto, que espcies de
mdulos ir preci sar no nvel detalhado, e lembrar-se- com muita clareza de como se
parecia a estrutura de sistema de alto nvel. Nesse caso, ele pode estar pretendendo aceitar
os riscos de cometer um engano por causa dos outros benefcios que a abordagem radical
vai lhe oferecer.
119
Resumindo, a abordagem radical mais apropriada para pesquisas e esforos de
desenvolvimento de pouca monta, em que ningum esteja completamente seguro do que
o sistema final dever fazer. Tambm indicada para ambientes em que alguma coisa
deve estar funcionando em uma certa data e em situaes onde a percepo do usurio
sobre o que ele deseja que o sistema faa est sujeito a alteraes. A abordagem
conservadora, por outro lado, tende a ser usada em grandes projetos, nos quais quantias
macias de dinheiro podem ser gastas e para os quais sejam necessrios anlise e projeto
cuidadosos para prevenir desastres subseqentes. No entanto, cada projeto diferente e
exige sua prpria mistura individual de implementao top-down radical e conservadora.
Para lidar com a natureza individual de qualquer projeto, o gerente do projeto deve estar
preparado para modificar sua abordagem, a meio do caminho, se necessrio for.
5.6 O CICLO DE VIDA DA PROTOTIPAO
Uma variao da abordagem top-down discutida acima tornou-se conhecida h poucos
anos atrs. geralmente conhecida como aborda gem de pmtot e foi popularizada por
Bernard Boar, James Martin e outros. Como a descreve Boar em [ 1984]:
Uma abordagem alternativa para a definio de requisitos obter um conjunto inicial de
necessidades e implement-las rapida mente com a inteno declarada de expandi-las e
refin-las iterativa mente proporo do aumento do conhecimento mtuo do sistema por
parte do usurio e do desenvolvedor. A definio do sistema ocorre atravs da descoberta
gradual e evolutiva em oposio previso onisciente... Esse tipo de abordagem
chamada de protoci pao. Ela tambm conhecida como modelagem de sistemas ou
desenvolvimento heurstico. Ela oferece uma alternativa atraente e funcional para
mtodos de pr-especificao para que se possa lidar melhor com a incerteza, a
ambigidade e a inconstncia dos pro jetos do mundo real.
Sob vrios aspectos, isso se assemelha exatamente abordagem radical top-down
discutida na seo acima. A principal diferena que a abordagem estruturada discutida
neste livro presume que, mais cedo ou mais tarde, ser construdo um completo modelo
de papel do sistema (isto , um completo conjunto de diagramas de fluxo de dados, diagra
mas de entidades-relacionamentos, diagramas de transies de estado, especificaes de
processos etc). O modelo ficar completo mais cedo com a abordagem conservadora e
mais tarde com a abordagem radical mas no final do projeto existir um conjunto formal
de documentos que
120
subsistir para sempre com o sistema enquanto ele suportar manuteno e reviso.
A abordagem de prototipao, por outro lado, quase sempre pres supe que o modelo ser
um modelo que funcione, isto , uma coleo de programas de processamento que
simularo alguma ou todas as fun es que o usurio deseje. Mas, como aqueles
programas de processa mento so pretensamente apenas um modelo, h tambm a
suposio de que, quando a modelagem estiver terminada, os programas sero
desprezados e substtudos por programas REAIS. Os prototipadores normalmente se
utilizam dos seguintes tipos de ferramentas de software:
Um dicionrio de dados integrado
Um gerador de tela
Um gerador de relatrios no-procedural
Uma linguagem de programao de quarta gerao
Uma linguagem de consultas no-procedural
Recursos poderosos de gerenciamento de banco de dados
O ciclo de vida da prototipao proposto por Boar mostrado na figura 5.6. Ele comea
com uma atividade de levantamento, semelhante que foi proposta neste livro; segue-se
imediatamente uma determinao se o projeto um bom candidato para a abordagem de
prototipao. Os bons candidatos para a abordagem de protoupao so projetos que tm
as seguintes caractersticas:
O usurio no capaz ou no deseja examinar modelos abstra tos de papel como
diagramas de fluxo de dados.
O usurio no capaz ou no deseja articular (ou pr-especifi car) seus requisitos de
qualquer forma e s pode determin-los atravs de um processo de tentativa e erro. Ou,
como meu cole ga Bob Spurgeon costuma dizer, essa a situao onde o usu rio diz,Eu
no sei o que quero, mas eu saberei, se o vir!.
O sistema est previsto para ser on-line com atividades de termi nal em tela cheia, em
oposio a sistemas batch de edio, atu alizao e emisso de relatrios. (Quase todas as
ferramentas de software da prototipao so orientadas para a abordagem on une dirigida
por banco de dados e orientada para terminais;
121
P1
PRI
NO
NO
SIM
Figura 5.6; O ciclo de vida da prot
SIM
122
existem poucas ferramentas de software oferecidas pelos forne cedores para ajudar a
construir prottipos de sistemas batch).
O sistema no exige a especificao de grandes quantidades de detalhamento
algoritmico, isto , a escrita de inmeras especifi caes de processos para descrever os
algoritmos pelos quais sero criados os resultados de sada. Desse modo, o apoio de
ciso, a recuperao ad boc e os sistemas de gerenciamento de registros so bons
candidatos prototipao. Os bons candida tos tendem a ser os sistemas nos quais o
usurio est mais inte ressado no formato e na diagramao da entrada de dados por
terminal de vdeo e nas telas de sada e mensagens de erro do que na computao bsica
realizada pelo sistema.
importante observar que o ciclo de vida da prototipao mostra do na figura 5.6 conclui
pela entrada na fase de projeto de um ciclo de vida estruturado tradicional do tipo
descrito neste livro. Isso, especifi camente, significa que o prottipo no feito para um
sistema operati vo, ele feito unicamente como um meio de modelar os requisitos do
usurio.
A abordagem de prototipao certamente tem valor em vrias si tuaes. Em alguns
casos, o gerente do projeto pode querer usar a abor dagem de prototipao como uma
alternativa abordagem de anlise estruturada descrita neste livro; em outros casos pode
querer us-lo em combinao com o desenvolvimento de modelos em papel como os
diagramas de fluxo de dados. Tenha em mente os seguintes pontos:
A abordagem top-down descrita na seo anterior uma outra forma de prototipao, mas
ao invs de usar ferramentas ofere cidas por um fornecedor, tais como geradores de telas
e lin guagens de quarta gerao, a equipe de projeto usa o prprio sistema como seu
prprio prottipo. Isto , as diversas verses de um sistema inicial fornecem um modelo
que funciona,com o qual o usurio pode interagir para obter uma idia mais rea lista das
funes do sistema do que poderia ter com um modelo de papel.
O ciclo de vida da prototipao, como descrito acima, envolve o desenvolvimento de
um modelo de trabalho que , depois, descartado e substitudo por um sistema de
produo. Existe o significativo perigo de o usurio ou a equipe de desenvolvimen to
tentarem transformar o prprio prottipo em sistema em pro duo. Isto normalmente se
converte em um desastre porque o prottipo no pode manipular eficientemente grandes
volumes
123
de transaes, e porque ele carece de detalhes operativos corno recuperao de erros,
auditorias, facilidades de backup/restart, documentao do usurio e procedimentos de
converso.
Se o prottipo for de fato descartado e substituido pelo sistema de produo, existe um
real perigo de que o projeto possa ter minar sem ter um registro permanente dos
requisitos do usurio. Isso provavelmente tornar a manuteno cada vez mais difcil com
o passar do tempo (p.ex., dez anos aps o sistema ter sido construdo, ser difcil para os
programadores de manuteno incorporarem uma alterao, porque ningum, incluindo
os usurios da segunda gerao que esto agora trabalhando com o sistema, podero
lembrar-se do que o sistema se propunha a fazer em sua origem). O ciclo de vida
apresentado neste livro baseado na idia de que os modelos em papel desenvolvidos na
atividade de anlise sero no apenas entradas para a ativida de de projeto, mas sero
tambm conservados (e modificados, quando necessrio) durante a manuteno contnua.
De fato, os modelos podem sobreviver ao sistema que os implementa e podem servir
como especificao para o sistema substituto.
5.7 RESUMO
O principal propsito deste captulo foi proporcionar uma viso geral dos ciclos de vida
de projeto em geral. Se voc examinar o ciclo de vida de projeto formal em qualquer
empresa de desenvolvimento de sistemas, voc poder afirmar se ele pertence ao tipo
clssico, semi-es truturado, estruturado ou de prototipao.
Se seus projetos s permitem uma atividade de cada vez, a discus so sobre
implementao top-down radical e implementao top-down conservadora na seo 5.6
pode t-lo confundido. Esse foi o meu inten to, porque o principal objetivo daquela seo
foi fazer voc pensar sobre a possibilidade de sobrepor algumas das principais atividades
de um projeto de desenvolvimento de sistemas. Evidentemente, mais difcil gerenciar
qualquer projeto que tenha diversas atividades acontecendo em paralelo - mas, at certo
ponto, isso sempre acontece em todo projeto. Ainda que o gerente de projeto decida que
seu pessoal concen trar todos os esforos em uma atividade importante de cada vez,
haver sempre algumas subatividades acontecendo em paralelo. Mltiplos ana listas de
sistemas estaro entrevistando mltiplos usurios simultanea mente; vrias partes do
produto final da anlise de sistemas estaro em diversos estgios de progresso por toda a
fase de anlise. Uma das tarefas do gerente de projeto exercer suficiente controle sobre
essas
124
subatividades para assegurar que elas se ajustem perfeio. E virtualmente em todo
projeto de PED, essa mesma espcie de atividade paralela funciona em nvel mais
elevado tambm; isto , a despeito do que o ciclo de vida de projeto formal da
organizao possa ter reco mendado, a realidade que muitas das principais atividades do
projeto se superpem em certo grau. No obstante, se o gerente de projeto resolver
insistir em uma progresso estritamente seqencial das ati vidades de projeto, o ciclo de
vida do projeto apresentado neste livro continuar vlido.
Para maiores detalhes sobre ciclos de vida de projetos, consul te [ 1981] e EYourdon,
19881. O conceito tambm coberto em diversos livros sobre engenharia de software e
gerenciamento de projeto.
REFERNCIAS
1. Edward Yourdon e Larry L. Constantine, Structurecl Design: Funda mentais and
Applications in Software Engineering, 2 ed. Engle wood Cliffs, N.J.: YOURDON Press,
1989.
2. Meilir Page-Jones, The Practical Guide lo Struclured Systems De sign, 21 ed.,
Englewood Cliffs, N.J.: YOURDON Press, 1988.
3. Bernard Boar, Application Pmtot Reading, Mass.: Addison- Wesley, 1984.
4. James Grier MilIer, J.ivin Systems. Nova lorque: McGraw-Hill,
1978.
5. Brian Dickinson, Developing Struclureci Systems. Nova lorque:
YOURDON Press, 1981.
6. Edward Yourdon, Managing the Systems L Cycle, 2 ed. En glewood Cliffs, N.J.:
Prentice-Hall, 1988.
7. James Grier Miller, Living Systems. Nova lorque: McGraw-Hill,
1978.
8. Michael Jackson, Princ ofPmgram Design. Nova lorque: Aca demic Press, 1975.
9. Winston W. Royce, Managing the Development of Large Software Systems,
Proceedings, IEEE Wescon, agosto de 1970, pgs. 1-9.
10. Barry Boehm, Software Engineerng Economics. Englewood Cliffs, N.J.: Prentice-
Hall, 1981.
11. Bili Inmon, Information Engineerin,g for the Practitioner Putlzng Tbeoty Into
Practice. Englewood Cliffs, N.J.: Prentice-Hall, 1988.
12. Marvin Gore e John Stubbe, Elements of Systems Analysis, 3 ed. Dubuque, Iowa:
William Brown, 1983.
125
PERGUNTAS E EXERCCIOS
1. Apresente dois sinnimos para metodologia.
2. Qual a diferena entre uma ferramenta, como usada no conte
deste livro, e uma metodologia?
3. Quais so os trs principais objetivos do ciclo de vida de u
projeto?
4. Projeto de pesquisa: encontre o preo de trs produtos comercia
de metodologia oferecidos por fornecedores de software ou p
firmas de consultoria.
5. Por que as menores organizaes de processamento de dados,
picamente, no usam metodologias formais?
6. Por que uma metodologia til para novos gerentes?
7. Por que importante ter uma metodologia em uma organiza
com muitos projetos diferentes em andamento?
8. Por que til ter-se uma metodologia para controlar projetos?
9. Quais so as maiores caractersticas que distinguem o ciclo de vi
clssico?
10. O que significa implementao bottom-up?
11. Quais so as quatro maiores dificuldades com a estratgia de ir
plementao bottom-up?
12. Que espcie de ambiente apropriado para a abordagem de ir
plementao bottom-up?
13. Qual a importncia de nada est pronto at que esteja compl
to, que caracteriza a abordagem bottom-up?
14. Por que os erros triviais devem ser encontrados primeiro na fase
testes de um projeto?
15. Qual a diferena entre testes e depurao de erros?
16. Por que a depurao de erros difcil na implementai
bottom-up?
17. O que significa a expresso progresso seqencial ao se descr
ver o ciclo de vida de um projeto?
18. Quais so os dois principais problemas da progresso seqencia
19. Quais so as principais diferenas entre o ciclo de vida clssico e
semi-estruturado?
20. Quais so as duas principais conseqncias da abordagem de ir
plementao top-down?
21. Por que a atividade de projeto no ciclo de vida semi-estruturac
muitas vezes envolve trabalho redundante?
22. Quais so as principais diferenas entre o ciclo de vida semi-estr
turado e o estruturado?
23. Apresente as nove atividades do ciclo de vida de proje
estruturado.
126
24. Quais so os trs tipos de pessoas que fornecem as entradas princi pais do ciclo de
vida de um projeto?
25. Quais so os cinco principais objetivos da atividade de levan tamento?
26. O que um diagrama de contexto?
27. Qual o principal propsito da atividade de anlise?
28. Quais so os tipos de modelos produzidos pela atividade de anlise?
29. Qual o propsito da atividade de projeto?
30. Quais so os dois principais problemas nos quais o usurio est ti picamente
interessado na atividade de projeto?
31. Quando pode se iniciar a gerao dos testes de aceitao (atividade 5)?
32. Qual o propsito da atividade de descrio de procedimentos?
33. Por que foi usado um DFD na figura 5.4 para mostrar o ciclo de vida de projeto
estruturado?
34. D um sinnimo vlido para atividade.
35. Por que importante a realimentao no ciclo de vida de projeto estruturado?
36. Qual a diferena entre a abordagem conservadora e radical do ciclo de vida de
projeto estruturado?
37. Quais so os quatro principais critrios para escolha da abordagem radical versu.s a
abordagem conservadora
38. Voc pode imaginar quaisquer critrios adicionais que poderiam ser usados para
escolha de uma abordagem radical versus uma
abordagem conservadora?
39. Que espcie de abordagem (radical versus conservadora) deveria um gerente de
projeto escolher se houvesse a possibilidade de o
usurio alterar sua opinio sobre os requisitos do sistema?
40. Que espcie de abordagem (radical versus conservadora) deveria um gerente de
projeto escolher se o projeto estivesse sob fortes
presses de tempo?
41. Que espcie de abordagem (radical versu.s conservadora) deveria um gerente de
projeto escolher se o projeto se defrontasse com
grandes riscos tcnicos?
42. Qual a diferena entre ciclo de vida de prototipao e ciclo de vida radical?
43. Quais as caractersticas que tem o projeto de prototipao ideal?
44. Que espcie de ferramentas so tipicamente necessrias usadas em um projeto de
prototipao?
45. Por que no so os sistemas batch bons candidatos para projetos de prototipao?
46. Quais so os perigos da abordagem de prototipao?
127
47. Como podem ser usados juntos em um projeto a abordagem de protoupao e o ciclo
de vida de projeto estruturado
NOTAS
Isso faz parecer que a anarquia prevalece na maioria das empresas de PED. Entretanto,
existem duas situaes comuns que conduzem a essa abordagem individualista mesmo
nas empresas mais exemplares: (1) a organizao altamente descentralizada, onde to do
departamento tem seu prprio grupo de PED com seus prprios padres locais e (2) o
perodo dc vrios anos imediatamente aps o ltimo ciclo de vida de projeto oficial ter
sido considerado como um fracasso e, portanto, dispensado.
2 Existem diversos pacotes desse tipo no mercado, custando de
$10.000 a $100.000 ou mais. Alguns dos mais conhecidos exemplos so o Spectrum (da
Spectrum International Corp), SOM-70 (da AGS Software), e Method/1 (da Arthur
Andersen). No farei comentrios sobre qualquer pacote especifico de gerenciamento de
projeto; Apenas sugiro que voc guarde os conceitos apresentados nes te livro se a sua
organizao usa um pacote adquirido de um fornecedor.
3 Miller indica em [ 19781 que isso um fenmeno comumen te observado; de fato, ele o
apresenta como uma hiptese geral
aplicvel a todos os sistemas vivos:
HIPTESE 2-1: Componentes de sistemas incapazes de se associa rem, ou carentes da
experincia que formou tais associaes, devem funcionar sob rgida programao ou
regras operacionais fortemente padronizadas. Segue-se que quando a modificao de
componentes se coloca acima da taxa na qual esses componentes podem desen volver as
associaes necessrias para a operao, a rigidez da pro gramao aumenta.
4 De fato, a orientao da maioria dos projetos de PED de que haja apenas um ponto de
verificao em que o usurio tem um caminho bvio e claro de recuo: ao fim da fase de
levantamento ou de estu do de viabilidade. Teoricamente, contudo, o usurio deve ter a
oportunidade de cancelar um projeto de PED ao fim de qualquer fase, se ele considerar
que est perdendo dinheiro.
5 Muitos consideram que a metodologia bottom-up tambm pode ser originria da
indstria de hardware de computadores, porque muitos dos primeiros programadores de
computador e gerentes de programao nos anos 50 e 60 eram engenheiros eltricos que
se haviam anteriormente envolvido no desenvolvimento de hardware.
128
6 Estou convencido que ainda h uma outra lei do tipo Murphy que
se aplica nesse aspecto: quanto maior e mais crtico for o projeto
mais provavelmente sua data limite coincidir com o processamen
to de fim de ano e outras crises organizacionais que consumiro
todo o tempo do computador.
7 Essas tcnicas modernas de desenvolvimento sero vistas em forma
resumida no captulo 7.
8 As tcnicas de entrevistas so discutidas no apndice E.
9 O diagrama de contexto faz parte do modelo ambiental que es
tudaremos em detalhes no captulo 18. Seu principal propsito,
como indicado aqui, definir o campo de aplicao do sistema
(o que est no sistema e o que est fora do sistema), bem como os
diversos terminadores (pessoas, unidades organizacionais, outros
sistemas de processamento etc.) com os quais o sistema dever
interagir.
10 Os clculos de custo-beneficio so discutidos no apndice C.
11 Existem, na realidade, maneiras de exibir rcalimentao e controle
em diagramas de fluxo de dados, como veremos no captulo 9. As
notaes complementares (de processos de controle e de fluxos de
controle) so normalmente utilizadas para modelar sistemas de
tempo-real e temos evitado seu uso neste modelo do sistema para
construir sistemas.
129
PRINCIPAIS
PROBLEMAS DO
DESENVOLVIMENTO
DE SISTEMAS
Os dogmas do passado silencioso so inadequados para o tempestuoso presente. O
momento atual esL repleto de d e precisamos acordar para esse momento. Assim como
nosso caso notn, devemos pensar e agir de uma maneira nova. Precisamos nos libertar
e, assim, salvaremos nosso pas.
Abraham Lincoin
Segunda Mensagem Anual ao Congresso
Neste captulo, aprenderemos:
1. Porque a produtividade um problema importante.
2. As solues comuns do problema da produtividade.
3. O nmero dc erros cm um sistema tpico.
4. A relao entre a idade de um sistema e o nmero de erros encontrados.
Como analista de sistemas, voc far parte de uma equipe cujo propsito desenvolver
um sistema de informaes til e de alta quali dade, que satisfaa as exigncias do
usurio final. Ao executar essa tare fa, voc e seus companheiros da equipe de projeto
sero, sem dvida, influenciados pelos seguintes aspectos relevantes:
Produtividade
Confiabilidade
Manutenibilidade 7
131
Naturalmente, todos so a favor da produtividade; este termo utilizado da mesma forma
que maternidade e lealdade em relao a nosso pas. Porm, h uma gerao, quando a
maioria dos sistemas ope racionais atuais estavam sendo construdos, produtividade no
era algo a que se prestasse muita ateno. Os analistas de sistemas e programa dores, nos
anos 60, trabalhavam longas horas (embora nem sempre em horas previstas), mas
nenhum deles tinha certeza do volume de trabalho que produziriam em uma semana, ou
de quanto tempo levariam na ela borao de um sistema completo. A sensao geral era
de que a equipe de desenvolvimento de sistemas trabalharia duramente todos os dias, at
que - voil4! Incrvel! - o sistema estaria pronto.
Nos dias atuais, a produtividade algo bem mais srio. O mesmo acontece com a
confiabilidade: uma falha de um sistema grande e com plexo pode ter conseqncias
devastadoras. A manutenibilidade tornou- se um problema importante: hoje evidente
que muitos dos sistemas recm-construdos levaro 20 anos ou mais at que possam ser
refeitos, e precisaro de constantes revises e modificaes durante seu tempo de vida.
Cada um desses aspectos analisado mais detalhadamente neste captulo. Alguns deles,
como a manutenibilidade, podem aparentar ter pouco ou nada a ver com a anlise de
sistemas, mas, como veremos, a anlise de sistemas tem um papel fundamental na
obteno do aumento da produtividade e da confiabilidade e de uma melhor
manutenibilidade.
6.1 PRODUTIVIDADE: A DEMANDA REPRIMIDA POR
APLICAES
O problema mais evidente que os profissionais de desenvolvi mento de sistemas
enfrentam hoje talvez seja o da produtividade. Os negcios e a sociedade moderna
parecem estar exigindo cada vez mais sistemas, mais sofisticao, e tudo com maior
rapidez. Como analista de sistemas, voc deve perceber os dois aspectos mais
importantes desse problema: um a demanda reprimida (backlog) por novos sistemas que
precisam ser desenvolvidos, e o outro o tempo necessrio para a cons truo de cada um
deles.
Em quase todas as organizaes americanas onde existe um grupo central responsvel
pelo desenvolvimento de novos sistemas, existem servios aguardando h vrios anos
para serem executados. Em realida de, muitas organizaes tm um backlog de quatro a
sete ou mais anos. O backlog se constitui de trs diferentes tipos de sistemas:
Backlog visvel: so os novos sistemas solicitados oficialmente pelos usurios e que
foram aceitos e tiveram suas verbas
132
aprovadas pelas comisses apropriadas dc gerncia. Entretanto, os projetos no foram
iniciados por falta dos recursos neces srios (tais como analistas de sistemas,
programadores etc.).
Backlog invisvel: so os novos sistemas que os usurios sabem que precisam, mas que
no se do ao trabalho de solicitar pelas vias oficiais porque ainda esto aguardando a
prontificao de projetos do backlog visvel.
Backlog desconhecido: so os novos sistemas que os usurios ainda no sabem que
precisam, mas que emergiro logo que sejam terminados alguns dos sistemas dos
backlogs visvel e
invisvel.
Em um clssico estudo sobre a demanda reprimida por sistemas de informaes (Alioway
e Quillard, 1982), os pesquisadores Robert Alloway e Judith Quillard, da MIT Sloan
School, descobriram que o back log invisvel de novos sistemas era upicamente 5,35
vezes maior que o visvel. Isso indica que o problema da demanda reprimida muito pare
cido com o proverbial iceberg: apenas uma pequena parte se mantm visvel, com um
enorme volume oculto sob a gua. Isso, naturalmente, representa um problema
importante para a empresa que prepara seu oramento e seu planejamento com base
apenas na demanda conhecida e visvel por seus servios.
Um segundo aspecto do problema da produtividade o tempo necessrio para
desenvolver um determinado sistema 2 bvio que se o projeto mdio de
desenvolvimento de sistemas puder ser diminudo de trs para um ano, o problema da
demanda reprimida desaparecer rapi damente. A questo que os usurios esto
geralmente preocupados no apenas com o problema global do backlog, mas tambm
com o pro blema local da produtividade em relao a um determinado projeto. Eles
receiam que, quando o novo sistema ficar pronto, as condies se tero modificado to
drasticamente que os requisitos originais tero perdido a importncia.
Explicando em outras palavras, um sistema novo muitas vezes est associado a uma
oportunidade comercial percebida pelo usurio, e essa oportunidade freqentemente tem
uma janela, um perodo de tempo aps o qual a oportunidade comercial ter
desaparecido e no mais haver necessidade do novo sistema.
Existe um terceiro motivo para a preocupao com a produtivida de em algumas
organizaes: alguns projetos falham melancolicamen te e so cancelados pela gerncia
antes mesmo de estarem prontos. Na realidade, vrias pesquisas descobriram que cerca de
25% de todos os projetos em grandes organizaes de SIG (Sistemas de Informaes
133
Gerenciais) nunca so terminados. Existem, naturalmente, muitas razes para o fracasso
de um projeto: problemas tcnicos, problemas geren ciais, inexperincia da equipe, falta
de tempo para ser feita uma ade quada tarefa de anlise e projeto dc sistemas (que
normalmente um problema da chefia), escasso envolvimento por parte da gerncia ou
dos usurios. No excelente trabalho de Robcrt Block, The Politcs ofProjects [ 19801, h
um timo estudo sobre as razes dos fracassos de projetos.
O problema da produtividade existe na profisso de desenvolvi mento de sistemas h
muito tempo e muitas empresas esto vigorosa mente buscando meios de reduzir
radicalmente o backlog de aplicaes e de diminuir o tempo necessrio ao
desenvolvimento de um novo siste ma. Entre as tcnicas mais utilizadas esto:
A contratao de mais programadores e analistas de sistemas. Isso particularmente
comum cm empresas novas e em expan so (p.ex., organizaes resultantes dc fuses, ou
novas organi zaes formadas para a explorao dc novos mercados e novos negcios) .
Essa abordagem, entretanto, tem sido evitada nas empresas antigas; na realidade, muitas
organizaes consideram que j tm programadores e analistas demais e que a atitude
apropriada torn-los mais produtivos .
A contratao de programadores e analistas de sistemas mais talentosos, oferecendo-se-
lhes melhores condies de trabalho. Em vez de utilizar um exrcito de dcscnvolvedores
medocres de sistemas, algumas empresas preferem contar com um pequeno grupo dc
profissionais altamente talentosos, treinados e bem amparados (e prcsumivelmcntc bem
pagos!). Essa abor dagem se baseia na bem conhecida disparidade de desempenho entre
programadores experientes. Um estudo clssico, levado a efeito em 1968 (tSackman,
Erickson e Grant, 19681), documen tou, pela primeira vez, o fato de que alguns
programadores so 25% mais produtivos que outros. Uma forma extrema dessa idia o
superprogramador ou programador-chefe de equipe, conceito popularizado pela IBM
nos anos 70 (veja [ 19761, [ 19721 e [ e Baker, 1973D,uma equipe de projeto formada
por especialistas (bibliotecrios, ferramentistas, dou tores em linguagem etc.) prestando
apoio a um extraordinaria mente talentoso profissional que se encarrega tanto da anlise
de sistemas como Io projeto e da programao do sistema. A maioria das empresas,
naturalmente, no pode construir toda uma organizao de des de sistemas em torno de
uma pessoa dez vezes melhoi do que a mdia . Entretanto, algo
134
existe a ser dito sobre a preparao de uma organizao com pessoas duas vezes mais
produtivas do que o analista/programa dor mdio, ainda que essas pessoas devam ser
pagas em dobro. Tambm existe algo a ser dito a respeito de tornar a equipe existente to
produtiva quanto possvel, proporcionando-lhe treinamento atualizado, modernas
ferramentas de desenvolvi mento de software (discutidas detalhadamente mais adiante) e
adequadas condies de trabalho 6
Deixar que os usu rios desenvolvam seus prprios sistemas. interessante observar que
muitos outros avanos tecnolgicos interpem algum entre o usurio e o dispositivo
tecnolgico; dois exemplos evidentes desse fato so o motorista e a telefo nista. claro
que a maioria entre ns no tem motorista nem precisa da telefonista para fazer nossas
ligaes; o automvel e o telefone so sufkientemente amistosos ao usurio para que os
possamos operar por ns mesmos. De modo semelhante, a combinao de computadores
pessoais, centros de informao e linguagens de quarta gerao, introduzidos cm muitas
organi zaes americanas em meados da dcada de 80, tornou possvel para muitos
usurios (inclusive, como vimos no captulo 2, uma gerao de usurios que aprendeu os
fundamentos da compu tao no segundo grau ou na faculdade) o desenvolvimento de
suas prprias aplicaes mais simples. Relatrio Ad Hoc, consul tas a bancos de dados,
aplicaes de planilhas eletrnicas e determinadas modificaes de manuteno de
programas exis tentes esto entre os projetos que um motivado usurio, en tendido em
computao, pode certamente fazer por si mesmo.
Melhores linguagens de programao. As linguagens de progra mao sofreram enormes
modificaes desde os anos 50, quando os programadores criavam os programas de
computa dor codificando laboriosamente os Os e Is que o hardware exe cuta. A primeira
gerao de linguagens de mquina deu lugar segunda gerao das linguagens de
montagem nos anos 60, e interessante notar que a linguagem de montagem ainda utili
zada em alguns projetos hoje em dia. Entretanto, as linguagens procedurais de terceira
gerao comearam a prevalecer nos anos 70 e permanecem como o mais comum tipo de
linguagem atualmente. Os exemplos sO: COBOL, FORTRAN, BASIC, Pas cal, C,
MODULA-2 e Ada. Enquanto a indstria de software con tinua a melhorar essas
linguagens (a verso do FORTRAN hoje disponvel imensamente melhor que a verso
utilizada pelos programadores no incio dos anos 70), boa parte do enfoque
135
transferiu-se para as novas linguagens de prograrilao de quarta gerao que eliminam a
necessidade de o programador se preocupar com os confusos detalhes, consumidores de
tem po, de edio e validao das entradas, formatao de relatrios e manipulao de
arquivos; exemplos dessas linguagens so FOCUS, RAMIS, MAPPER E MARK V (e
tambm linguagens como PC-FOCUS, dBASE III E Rbase-5000 para computadores
pessoais). Muitos argumentam que essas novas linguagens po dem aumentar a
produtividade da programao por um fator igual a dez. Entretanto, como a programao
normalmente representa apenas 10 a 15% do projeto geral de desenvolvi mento de um
sistema, o ganho total cm produtividade muitas vezes bem menos substancial.
O ataque ao problema cia manuteno. A manuteno um grande problema na rea do
desenvolvimento de sistemas, como veremos na seo 6.4. Contudo, a ateno maior est
sempre focalizada (como era de se esperar) na manutenil,ilidade dos novos sistemas;
enquanto isso, como j foi mencionado, muitas empresas esto destinando 50 a 75% de
seus recursos para a manuteno dos sistemas anti,os. Portanto, a questo :
o que pode ser feito para tornar mais fcil a manutenao dos sis temas antigos, alm da
idia bvia de jog-los fora e substitui-los por outros? Uma abordagem cuja popularidade
vem aumen tando a da restruturao - a converso mecnica dos pro gramas antigos
(cuja lgica j foi to remendada e modificada que muitas vezes est totalmente
ininteligvel) em programas novos, bem organizados e estruturados Uma idia
relacionada com isso o emprego de pacotes automatizados de documen tao que
podem produzir listagens de referncias cruzadas, dicionrios de dados, fluxogramas
dctalhados,diagramas estrutu rais ou fluxogramas de sistemas diretamente a partir do pro
grama (isso citado por alguns componentes da manuteno como engenharia invertida).
Outra abordagem, j mencionada, encorajar os usurios a fazerem suas prprias
modificaes de manuteno 8 e uma outra documentar cuidadosamente a natureza
especifica da tarefa de manuteno; isso muitas ve zes demonstra que apenas 5% do
cdigo de um sistema ope racional so responsveis por 50% ou mais do trabalho de
manuteno.
controles de engenhana de Software. Outra maneira de melho rar a produtividade
realizada atravs de uma coleo de fer ramentas, tcnicas e controles geralmente
conhecida como
136
engenharia de software ou tcnicas estruturadas. Incluem-se a a programao
estruturada, o projeto estruturado e a anlise estruturada bem como os controles
relacionados, como as mtricas de software, as provas de correo de programas e o
controle de qualidade de software. Em geral, as tcnicas estruturadas tm tido um
modesto impacto, uma melhoria de tipicamente 10 a 20%, sobre a produtividade dos
profissionais de desenvolvi mento de sistemas durante a fase de desenvolvimento do pro
jeto. Entretanto, os sistemas desenvolvidos com utilizao das tcnicas estruturadas tm
geralmente custo de manuteno subs tancialmente inferior e confiabilidade maior,
muitas vezes por um fator igual ou maior que 10. Isso leva liberao de recursos que, de
outra forma, seriam utilizados em manuteno ou elimi nao de erros, melhorando,
assim, a produtividade geral da organizao.
Ferramentas automatizadas para desenvolvimento de sistemas. Finalizando, observamos
que um motivo do problema da produ tividade que boa parte do trabalho de
desenvolvimento de um sistema automatizado de informaes , ironicamente, exe
cutado de forma manual. Assim como os filhos do sapateiro so os ltimos a ganharem
sapatos, os programadores e analistas de sistemas tm tradicionalmente sido os ltimos a
se beneficiarem da automatizao de suas tarefas. evidente que algum pode lembrar
que um compilador uma ferramenta automatizada para a programao, assim como os
pacotes de testes e os auxlios eliminao de erros oferecem alguma automatizao.
Mas, at recentemente, pouca ajuda automatizada existia para o projetista de sistemas e
quase nada havia para o analista. Agora existem terminais grficos que podem
automatizar o cansativo trabalho de desenvolver e manter diagramas de fluxo de dados,
diagramas de entidades-relacionamentos e outros modelos gr ficos vistos no captulo 4.
Essas ferramentas automatizadas tam bem desempenham vrias atividades de verificao
de erros, assegurando, desse modo, que a especificao produzida pelo analista de
sistemas fique completa, sem ambigidades e inter namente consistente. Alm disso, em
alguns casos, as ferramen tas automatizadas podem at gerar cdigo diretamente da
especificao, eliminando, dessa forma, a atividade manual da programao. Os detalhes
dessas ferramentas automatizadas para anlise de sistemas so examinados no apndice
A.
Muitas dessas abordagens sobre produtividade podem ser usa das em conjunto porque
envolvem conceitos e tcnicas que se
137
complementam. Individualmente, cada abordagem discutida acima pode conduzir a uma
melhoria de 10 a 15%; combinadas, podem facilmente dobrar a produtividade da
organizao e, em casos especiais, talvez pos sam melhorar a produtividade por um fator
igual a dez. Um excelente es tudo do impacto quantitativo dessas abordagens e de um
grande nme ro de fatores de produtividade podem ser encontrados em [ 1986].
Como analista de sistemas, sua reao a tudo isso poderia ser: E da? Qual a importncia
disso?. Na verdade, parece que muitos dos problemas de produtividade esto na rea da
programao, dos testes e da manuteno e nenhum deles na rea da anlise de sistemas.
No obstante, existem trs motivos para que voc se sensibilize efetivamente pelo
problema da produtividade como analista de sistemas:
1. A qualidade do trabalho executado pelo analista de sistemas pode ter grande impacto
na produtividade do projetista de sistemas e do programador; pode, tambm, ter forte
efeito no volume de tempo gasto em testes, uma vez que 50% dos erros (e 75% do custo
da eliminao de erros) de um sistema esto, habitualmente, associados a erros do
analista de sistemas. Os programadores podem ser acusados pela baixa produtividade por
causa do tempo que eles gastam em testes, porm isso muitas vezes um indcio da baixa
qualidade do servio feito pelo analista de sistemas.
2. Algumas das tcnicas de produtividade - maior nmero de pes soas, melhores
profissionais, melhores condies de trabalho e, principalmente, ferramentas
automatizadas - tm direta importncia para o analista de sistemas. Vale a pena pensar no
que pode ser feito para tornar voc e seu trabalho mais produtivos.
3. A produtividade da anlise dc sistemas um problema politica mente sensvel, porque
muitas vezes parece ao usurio (e, por vezes, aos gerentes pertencentes equipe de
desenvolvimento de sistemas ou a outras partes da empresa) que pouco est sendo feito
durante a fase de anlise do sistema; freqentemente ouve-se o comentrio: Quando
vocs comearo a escrever os programas? No podemos ficar sentados para sempre
falando sobre o sistema, precisamos que ele seja implementado!, e ao produto da anlise
do sistema, a especificao funcional, dado muito pouco valor. A reao s
especificaes algumas vezes ser: Para que servem todas essas figuras e palavras? Ns
j ex plicamos o que queremos que o sistema faa, para que escre veram tudo isso?.
138
O fato que no se pode construir com sucesso um sistema manu tenvel e de alta
qualidade se no se souber precisamente com o neces srio detalhamento o que deve ser
feito. Assim, embora alguns usurios e gerentes possam reclamar que a anlise de
sistemas meramente um perodo de repouso at ser iniciado o verdadeiro trabalho do
projeto (a programao), o certo que isso deve ser feito com cuidado e rigor, mas
tambm deve ser realizado com tanta eficincia e produtividade quanto possvel; dessa
maneira, o analista de sistemas no deve considerar que a produtividade seja apenas um
problema de programao!
6.2 CONFIABIUDADE
Um segundo problema importante a ser enfrentado pelos desen volvedores de sistemas
o da confiabilidade. O enorme tempo despen dido em testes e depurao dc erros,
tipicamente 50% do projeto de desenvolvimento de um sistema, e a extremamente baixa
produtivida de (que muitos pensam estar relacionada com o tempo gasto nos tes tes)
podem ser aceitveis se os resultados forem sistemas altamente confiveis e de fcil
manuteno. A evidncia dos ltimos trinta anos justamente o oposto: os sistemas
produzidos pelas empresas em to do o mundo esto cheios de erros e so quase
impossveis de serem modificados.
Cheio de erros tem significados diferentes para pessoas diferen tes. O software
desenvolvido nas empresas americanas tem, em mdia, de trs a cinco erros em cada cem
comandos depois do software ter sido testado e entregue ao cliente; veja Uoncs, 19861.
Apenas alguns poucos projetos exemplares de desenvolvimento de software apresenta
ram somente trs a cinco erros em cada 10.000 sentenas de programa, da poca do
projeto do superprogramador da IBM ( 1972]). Hou ve, ainda, algumas informaes
pessimistas, como em [ 19851, relatando que o software americano pode ter de trs a
cinco erros para cada dez sentenas!
Os erros de software vo do sublime ao ridculo. Um erro trivial pode consistir de uma
sada (resultado) correta, mas no impressa ou formatada to correta ou arrumadamente
como queria o usurio. Um erro de software moderadamente srio pode se constituir dc
um caso em que o sistema se recusa a aceitar certos tipos dc entradas, mas que o usurio
final consegue um meio de contornar o problema. Os erros srios so os que fazem o
programa parar de ser processado, com perda considervel de dinheiro ou de vidas
humanas. Entre os exemplos de erros srios relativos a software que foram documentados
atravs dos anos incluem-se os seguintes:
139
Em 1979, o sjstema SAC/NORAD (Strategic Air Command/ North American Air
Defense - Comando Areo Estratgico/ Defesa Area Norte-Americana) registrou
cinqenta alertas fal sos, inclusive um ataque simulado cujas sadas provocaram aci
dentalmente a decolagem de interceptadores.
Um erro no programa de simulao de vo do F16 fazia com que o avio virasse de
cabea para baixo sempre que cruzava a
linha do equador.
O mssil de um F18 disparou quando ainda estava preso ao avio, fazendo-o perder
cerca dc 6.500m de altitude.
As portas do trem do sistema So Francisco BART, controlado por computador, s vezes
se abrem durante longas travessias
entre estaes.
Um alerta NORAD do Ballistic Missile Early Warning System (BMEWS) detectou a
Lua como um mssil que se aproximava.
O Stock Index de Vancouver perdeu 574 pontos em um perodo de 22 meses por causa
de erros dc arredondamento (p.ex., o ar redondamento de 3,14159 para 3,1416).
Em 28 de novembro de 1979 um vo da Air New Zealand es patifou-se contra uma
montanha; investigaes posteriores de monstraram que um erro nos dados de rumo do
computador tinha sido detectado e corrigido, mas isso no tinha sido infor mado ao
piloto.
Infelizmente, a lista vai muito alm; veja exemplos em [ 19851. Muitos outros erros de
software nunca foram divulgados porque a pessoa ou empresa culpada prefere no
admitir publicamente o fato. Quando este livro estava sendo escrito, havia uma idia
generali zada de que erros desse tipo poderiam conduzir a conseqncias desagradveis
para o programa Star Wars do Departamento de Defesa dos EUA, ou para alguns dos
principais sistemas complexos de defe sa area controlados por software; veja anlises
sobre isso em Uacky, 19851 e em (Adams e Fischetti, 19851. Na verdade, ainda que a
confiabilidade do programa Star Wars seja 100 vezes maior do que a mdia dos sistemas
desenvolvidos nos Estados Unidos, ele ainda poderia conter 10.000 erros - uma
perspectiva nada tranqilizado ra quando um desses erros pode causar a eliminao da
vida neste planeta!
140
Em muitos casos, ningum est totalmente seguro de quantos erros em um sistema
porque (1) alguns erros nunca chegam a ser descobertos u que o sistema morra de
velhice e (2) o processo de documentao e egistro de erros to relaxado que a metade
dos erros encontrados no divulgada nem mesmo dentro da organizao de
desenvolvimento de ;istemas. Em todos os casos, a atividade tpica de descoberta de
erros, m um perodo de vrios anos de vida til de um sistema de software :oma,
habitualmente, a forma mostrada na figura 6.1.
A forma daquela curva influenciada por diversos fatores. Por xemp1o, quando o sistema
liberado para os usurios finais pela pri rneira vez, eles muitas vezes no esto
capacitados a coloc-lo em total produo, levaro algum tempo para converterem o
sistema antigo (que talvez fosse um sistema manual) e para treinarem a equipe operativa.
Alm disso, ainda estaro um tanto receosos do computador, e no vo querer exigir
muito da mquina, de modo que poucos erros sero desco bertos. Quando converterem o
modo antigo de operar para o novo siste ma, quando a equipe operauva estiver mais bem
treinada e tiverem perdido o medo da mquina, comearo a exigir mais do software, e
mais erros sero encontrados . Naturalmente, se isso prosseguisse inde finidamente -
mais e mais erros descobertos a cada dia - os usurios provavelmente deixariam de usar o
software e o jogariam fora. Na maioria dos casos, os programadores vo freneticamente
corrigindo os novos erros proporo em que so descobertos pelos usurios.
Normalmente, chega um dia em que o sistema comea a se estabilizar e os usurios
encontram cada vez menos erros.
H trs aspectos negativos na figura 6.1. Em primeiro lugar, a curva
nunca atinge o zero, isto , quase nunca encontramos uma situao em
que o tempo passe sem que novos erros sejam encontrados. Segundo, a
(a
o
D
co
o
()
c
a)
(o
o
O)
a)
0
o
O)
E
z
Figura 6.1: En descobertos em funo do tempo
Tempo decorrido
141
rea sob a curva, que representa o nmero total de erros enconhtauos em relao ao
tempo, demasiadamente grande - a mdia de trs a ci co erros para cada 100 sentenas
de programa. E, em terceiro lugar, a curva por vezes sobe de novo - de modo geral aps
alguns anos, mas, s vezes, depois de apenas alguns meses. Ocasionalmente, todos os
sistemas de software atingem a situao de uma colcha de retalhos, quando qualquer
esforo para corrigir um erro introduz dois novos erros, e as modificaes necessrias
para corrigir esses novos erros provocam quatro outros erros, e assim por diante.
Existe um ltimo problema acerca de erros de software: eles no so fceis de serem
corrigidos. Quando algum, o programador, o usu rio final ou algum outro
intermedirio, percebe que o software no est funcionando corretamente, duas coisas
devem ocorrer: (1) o programa dor deve identificar a fonte e a natureza do erro e (2) deve
encontrar um modo de corrigir o erro (modificando alguns comandos, eliminando outros
comandos ou acrescentando novos comandos) sem afetar ne nhum outro aspecto da
operao do sistema. Isso no uma tarefa simples. Na realidade, o programador tem
menos de 50% de probabilida de de sucesso na primeira tentativa, e as estimativas caem
rapidamente se o programador tiver de modificar mais de 10 ou 20 sentenas do
programa (veja EYourdon, 19861).
6.3 MANUTENIBILIDADE
A correo de erros um dos aspectos da manuteno. Lientz e Swanson ( e Swanson,
1980]) descobriram que os erros respon diam por aproximadamente 21% do esforo geral
de manuteno nas empresas americanas de processamento de dados A manuteno est
tambm vinculada modificao deum sistema em conseqncia de alteraes no
hardware, s modificaes para acelerar certos aspectos operacionais do sistema e s
modificaes face a alteraes dos requisi tos do sistema introduzidas pelo usurio.
A manuteno de softwre um importante problema para a maioria das empresas; de 50 a
80% do trabalho realizado na maior parte das organizaes de desenvolvimento de
sistemas esto associados reviso, modificao, converso, ao aperfeioamento ou
depurao de um programa que algum escreveu tempos atrs. E esse um trabalho caro.
No princpio dos anos 70, o Departamento de Defesa dos EUA relatou que o custo de
desenvolvimento de programas de processamento de um projeto atingia em mdia $75
por instruo e o custo da manuteno do sistema atingia $4000 por instruo.
Em termos mais expressivos, considere os seguintes exemplos
oriundos da U.S. Social Security Administration:
142
O clculo do aumento do Custo de vida para 50 milhes de Cida dos que recebem
beneficios da Social Security toma 20 mil horas de processamento em sistemas mais
antigos do Social Se curity System (veja FRochester e Gantz, 19831).
Quando, em 1981, o Social Security System converteu seus siste mas de processamento
de cinco dgitos de verificao para seis, foram necessrios 20 mil homens-hora de
trabalho e 2.500 horas de tempo de processamento para modificar 600 programas se
parados de processamento.
O moral no departamento dc manuteno da Social Security es tava to baixo em
determinada ocasio que um dos programa dores foi pilhado quando urinava em uma
unidade de disco na sala do computador. Embora isso seja uma nova maneira de
desafogar a frustrao, no muito aconselhvel para a unidade de disco.
O resultado de tudo isso, em um nmero sempre crescente de organizaes de
processamento de dados, que os sistemas desenvolvi dos h 10 ou 20 anos
simplesmente no podem ser modificados para satisfazer as novas exigncias do governo,
da economia, das condies climticas ou da inconstncia do usurio. proporo em
que as empre sas e a sociedade tornam-se mais e mais dependentes dos computadores,
pode-se observar um interessante paralelo: quando ocorre a estagnao do software, a
empresa ou sociedade atendida por esse software tambm fica estagnada.
O problema ainda pior do que isso. Se fosse apenas o caso de o software no ser bom,
poder-se-ia dispens-lo e substitui-lo. Porm muitas empresas nunca capitalizaram o
software (os custos so gastos a cada ano), e a poltica de contabilizao e de comrcio
torna proibitiva- mente cara a substituio dos sistemas antigos. Existe outro problema
ainda mais fundamental: na maioria das organizaes no h uma descri o coerente do
que os sistemas devem fazer. A documentao por ventura existente quase sempre
obsoleta e confusa, oferecendo, quando muito, algumas idias de como o software
funciona, mas no de qual seja seu propsito ou de qual doutrina comercial ele se prope
a implementar.
Assim, mesmo que algum possa argumentar que a manutenibili dade seja funo da
implementao (isto , algo da competncia do programador), impossvel mantoc um
sistema se no existir um modelo acurado e atualizado dos requisitos do sistema. Isso,
afinal de contas, da responsabilidade do analista de sistemas; como veremos no captulo
143
8, as especificaes funcionais desenvolvidas pelos analistas de sistemas progrediram
gradualmente de novelas vitorianas (milhares de pginas de texto) de manuteno
absolutamente impossvel para modelos grficos, do sistema, desenhados mo e para
modelos gerados e mantidos pelo computador. No captulo 24 tambm ser discutido o
problema da ma nuteno contnua das especificaes do sistema.
6.4 OUTROS PROBLEMAS
Com que tem o analista de sistemas de se preocupar, alm da produtividade, da
confiabilidade e da manutenibilidade? Bem, a lista va ria de empresa para empresa e de
projeto para projeto, mas normal mente se compe do seguinte:
Eficincta. Um sistema deve funcionar com uma adequada taxa de desempenho
(habitualmente medida em transaes por segundo) e com um tempo de resposta
aceitvel para os termi nais on-line. Isso normalmente no um problema com que o
analista de sistemas deva se preocupar, uma vez que os projetis tas e os programadores
tero a maior parte da influncia na eficincia geral do sistema implementado. Esse
aspecto, na reali dade, est se tornando um problema cada vez menor nos sis temas
modernos, j que os custos do hardware continuam a cair a cada ano, enquanto a
capacidadc e a rapidez do hardware continuam a crescer
Portabilidade. A maioria dos novos sistemas implementada em uma marca de
computador, mas pode haver necessidade de desenvolver o sistema de modo a que possa
ser transferido com facilidade para outros computadores. Isso tambm no costuma ser
um problema da alada do analista de sistemas, embora ela ou ele possam precisar
especificar a necessidade da portabili dade no modelo de implementao.
Segurana. Como os modernos sistemas de processamento tm acesso cada vez mais
fcil (cm face da tendncia dc serem on une), e como so responsveis pelo crescente
gerenciamento dos ativos mais importantes das empresas, a segurana vem tor nando-se
uma importante preocupao em muitos projetos de desenvolvimento de sistemas: o novo
sistema deve impedir acessos no-autorizados assim como a atualizao e o apaga mento
no-autorizados de dados importantes.
144
6.5 RESUMO
Vrios especialistas predizem que a proporo preo/desempenho do hardware dos
computadores ser melhorada por um fator igual a 1000 e talvez por 1 milho, dentro dos
prximos 10 a 15 anos. Infeliz mente, a histria do desenvolvimento de software nas
ltimas trs dca das leva o observador comum a concluir que a tecnologia do software
melhorar muito pouco. Como o softwre tornou-se atualmente a maior despesa e o
caminho critico da maioria dos sistemas, essa pequena melhora no pode ser
considerada aceitvel. Em toda a indstria do processamento, existe um esforo macio e
organizado para a obteno de melhoras relevantes no processo de desenvolvimento de
software.
As tcnicas de anlise de sistemas apresentadas neste livro fazem parte desse esforo.
Como vimos, parte do esforo problema da pro gramao e do projeto do sistema,
porm a boa especificao a base, a pedra fundamental, sobre a qual se apiam o
projeto e a programao.
REFERNCIAS
1. Robert Alloway e Judith Quillard, User Management Systems Needs, CISR Working
Paper 86. Cambridge, Mass.: MIT Sloan
School for Information Systems Research, abril 1982.
2. Harold Sackman, W.J. Erickson e E.E. Grant, Exploratory Experi mental Studies
Comparing Online and Offiine Programming Perfor mance, Communicatons of ihe
ACM, janeiro 1968,pgs.3-11.
3. J. Aron, The Super-Programmer Project, Software Engineering ConcepLs and
Technlques. Eds. J.M. Buxton, P. Naur e B. Randell.
Nova lorque: Petroceili/Charter, 1976, pginas 188-190.
4. F.T. Baker, Chief Programmer Team Management of Production Programming, IBM
Systems Journal, Volume 11, Nmero 1 (janei ro de 1972), pgs. 56-73.
5. H.D. Mills e F.T. Baker, Chief Programmer Teams, Datamation, Volume 19, Nmero
12 (dezembro de 1973), pgs. 58-61.
6. Edward Yourdon, Managing the Structured Techniques: Strategies for Software
Development in lhe 1990s, 3 cd. Nova lorque:
YOURDON Press, 1986.
7. Bennett P. Lientz e E. Burton Swanson, Software Maintenance Management. Reading,
Mass: Addison-Wesley, 1980.
8. T. Capers Jones, Programming Produclivity. Nova lorque:
McGraw-Hill, 1986.
9. T. Capers Jones, A Software Productivity Survey, palestra proferi da na First
National Conference on Software Quality and Producti vity, Williamsburgh, Virginia,
maro de 1985.
145
10. Edward Yourdon, op cit.
11. F.T. Baker, op cit.
12. David Sanger, Software Fears on Star Wars, New York Times, 4 de julho de 1985.
13. Peter G. Neumanri, Some Computer-Related Disasters and Other Egregious
Horrors, ACM SIGSOFT Software Engineern,g Notes,
janeiro de 1985.
14. Jonathan Jacky, The Star Wars Defense Wont Compute, Atlantic Monthly, junho de
1985.
15. John A. Adams e Mark A. Fischetti, Star Wars-SDI: The Grand Experiment, IEEE
Spectruni, setembro de 1985, pgs. 34-64.
16. Artigo do New York Times de cerca de 16 de setembro de 1986, comentando o
nmero de erros do sistema Star Wars.
17. Dines Hansen, up and Running. Nova lorque: YOURDON Press,
1984.
18. Edward Yourdon, op cit.
19. Bennett P. Lientz e E. Burton Swanson, op cit.
20. Jack Rochester e John Gantz, The Naked Computer. Nova lorque:
William Morrow, 1983.
21. Edward Yourdon, Nations at Risk. Nova lorque: YOURDON Press,
1986.
22. Robert Block, The Polilics of Projecis. Nova lorquc: YOURDON Press, 1981.
PERGUNTAS E EXERCCIOS
1. Examine o relatrio financeiro de uma grande empresa pblica e veja se voc pode
determinar o quanto despendido em desenvol vimento de sistemas. Quanto poderia ser
economizado se a produ tividade das empresas de desenvolvimento de sistemas pudesse
ser duplicada?
2. Escolha uma grande empresa pblica que dependa nilidamente dos computadores para
seu funcionamento normal. Estime durante quantos dias, semanas ou meses a empresa
poderia continuar fun cionando se seu sistema de processamento parasse.
3. Quais so os trs principais problemas do desenvolvimento de sis temas nos dias de
hoje?
4. Por que a produtividade parece ser hoje o problema mais evidente?
5. Quais so os trs tipos de backlog que podem ser encontrados em uma empresa tpica?
6. Projeto de Pesquisa: efetue um levantamento em sua empresa para determinar a
extenso do backlog de desenvolvimento de sistemas.
Esse conceito bem conhecido entre os usurios de sua empresa?
146
7. Qual a diferena entre o backlog visvel e o invisvel?
8. Por que existe o backlog desconhecido?
9. Por que o backlog invisvel parece ser muito maior do que o visvel?
10. Quais so as sete solues comuns que as empresas utilizam pa ra resolver seus
problemas de produtividade? Voc pode sugerir
outras?
11. Como voc acha que uma empresa deve medir a produtividade do setor de
desenvolvimento de sistemas?
12. Contratar mais programadores ou analistas de sistemas uma solu o prtica para o
problema da produtividade? Quais so as vanta gens e desvantagens?
13. Voc considera prtico resolver o problema da produtividade pela contratao de
programadores ou analistas de sistemas mais talen tosos? Por qu?
14. Imagine que existisse um programador dez vezes mais produtivo que um
programador mdio que ganha $25.000 por ano. Voc acha que os diretores de uma
empresa tpica estariam dispostos a despender $250.000 por ano com aquele programador
talentoso? Voc acha que eles deveriam estar dispostos? Por qu?
15. Voc considera prtico resolver o problema da produtividade per mitindo que os
usurios desenvolvam seus prprios sistemas?
Quais so as vantagens e as desvantagens?
16. Que tipos de projetos de desenvolvimento de sistemas so mais adequados para serem
desenvolvidos pelos prprios usurios? Qual a percentagem de projetos que podem ser
includos nessa categoria em uma empresa tpica?
17. Voc considera prtico utilizar novas linguagens de programao, de terceira gerao,
como Ada, ou de quarta, como Focus, RAMIS e NOMAD, para resolver o prblema da
produtividade? Quais so as vantagens e desvantagens dessa abrdagem?
18. Projeto de Pesquisa: qual seria a melhora da produtividade em sua empresa nos
prximos cinco anos se fosse iniciada a utilizao de
uma nova linguagem de programao?
19. Por que as linguagens de quarta gerao permitem uma melhora da produtividade
maior do que as linguagens convencionais de tercei ra gerao?
20. Qual seria a melhora da produtividade em uma empresa tpica se a manuteno
pudesse ser reduzida por um fator de dez?
21. Projeto de Pesquisa: use um produto comercial tipo structuring engine (dispositivo
de estruturao) para reestruturar um progra ma existente em sua empresa e mea a
reduo dos custos de manuteno. O que isso representa em relao aos potenciais
benefcios de um dispositivo de estruturao?
147
22. Voc acha que a reestruturao pode transformar programas ruins
em bons? Por qu? Se voc respondeu no, explique qual o pro
psito da reestruturao de programas.
23. Podem os usurios executar a manuteno de seus prprios pro
gramas? O que necessrio para que isso possa ser feito? Qual a
percentagem do servio de manuteno de software que voc, de
forma realista, considera que os usurios possam fazer de fato?
24. Por que a engenharia de software pode melhorar a produtividade?
25. Por que as ferramentas automatizadas de desenvolvimento de soft
ware podem aumentar a produtividade?
26. Como o trabalho do analista de sistemas pode afetar a produti
vidade de um projeto de desenvolvimento de sistemas?
27. Qual o tempo de um projeto tpico gasto em testes e depurao
de erros?
28. Projeto de Pesquisa: qual o nmero mdio de erros nos sistemas
desenvolvidos em sua empresa? Qual a varlncia - a diferena
entre a pior observao e a melhor?
29. Projeto de Pesquisa: encontre pelo menos dois exemplos docu
mentados de falhas de sistemas, no ano passado, que tenham cau
sado uma perda de vida ou tenha resultado em um custo de mais
de $1 milho. Como essas falhas poderiam ter sido evitadas?
30. Por que o nmero de erros de um sistema tende a aumentar de
pois que o sistema posto em operao pela primeira vez?
31. Por que o nmero de erros de um sistema tende a aumentar gra
dualmente depois que o sistema est em funcionamento a alguns
anos?
32. Projeto de Pesquisa: qual o perceritual dos recursos de sua orga
nizao de desenvolvimento de sistemas que gasto com a manu
teno? A alta direo de sua empresa est ciente desses nmeros?
33. Que fatores, alm da produtividade, qualidade e confiabilidade so
importantes nas organizaes tpicas de desenvolvimento de soft
ware hoje?
34. Qual o papel desempenhado hoje pelo analista de sistemas na
determinao da eficincia de um sistema de informao?
35. Qual o papel desempenhado hoje pelo analista de sistemas na
determinao da portabilidade de um sistema de informao?
36. Qual o papel desempenhado hoje pelo analista de sistemas na
determinao da segurana de um sistema de informao?
NOTAS
1 As conversas informais que tive com gerentes de PED no Canad,
na Europa, na Austrlia, na Amrica do Sul e em vrias outras
148
partes do mundo me fazem acreditar que esse problema no , de forma alguma, restrito
aos Estados Unidos.
Para dar uma idia do alcance desse problema, Capers Jones con cluiu, em uma pesquisa
em aproximadamente 200 grandes empre sas americanas, que o projeto tpico estava um
ano atrasado e 100%
acima do oramento. Veja Ijones, 1986].
3 Um bom exemplo disso ocorreu em meados da dcada de 80
quando alguns pases liberaram os bancos e a atividade de compra e venda de estoques.
Austrlia, Japo e Inglaterra esto entre os pases que subitamente se viram com dzias
de novos bancos e empresas comerciais estrangeiras abrindo as portas para o comr cio.
Londres foi talvez o caso mais evidente, com a liberao (Big Bang) de 27 de outubro de
1986. Essas atividades exigiram o de senvolvimento de grandes sistemas novos de
informao, o que ge ralmente era conseguido pela contratao de tantos programadores
e analistas quantos fossem possveis, no menor tempo que se
pudesse.
4 Isso contraria a sombria previso da reduo do nmero de progra madores a nvel
nacional emitida pela U.S. Comrnerce Department
and the National Science Foundation. Para maiores detalhes veja o
captulo 28 de [ 1986].
5 Para uma anlise detalhada sobre a razo de o conceito de super-
programador no ser prtico para a maioria das empresas, veja
Managing the Structured Technlques jYourdon, 1988D.
6 Uma interpretao bvia de condies adequadas de trabalho dar
a cada membro de um projeto de desenvolvimento de sistemas um escritrio privativo, ou
um escritrio para cada duas pessoas ou um compartimento prova de som, que oferea
privacidade e concen trao - isso tende a melhorar a produtividade do analista/progra
mador em 10% ou mais, em comparao com o que trabalha em uma ampla sala aberta,
com som vindo do teto. Outra interpretao deix-los trabalhar em casa. Para mais
detalhes sobre esse concei to, a casa eletrnica, veja o captulo 3 de [ 1986].
7 Existem diversos produtos comerciais nessa rea. Entre os mais co nhecidos esto
Superstructure da Group Operations, Inc.; Struc tured Retrofit, comercializado por Peat,
Marwick; e Recorder, da
Language Technology, Inc.
8 Isso tem uma importncia especial, porque, de acordo com um es tudo em [ e Swanson,
1980], aproximadamente 42% da ativi dade de manuteno em uma empresa tpica
consiste em aperfei oamentos do usurio, em contraste com 12% de reparos emer
genciais de programas, 9% de depuraes rotineiras, 6% de acomodaes s
alteraes de hardware etc. Da parte despendi da em aperfeioamentos do usurio, 40%
referem-se incluso de
149
novos relatrios, 27% so gastos com o acrscimo de dados a
relatrios j existentes, 10% so gastos com a reformatao de rela
trios sem alteraes de contedo e 6% com a consolidao dos
dados de relatrios existentes e linguagem de programao de
quarta gerao, muito provvel que muitas (seno todas!) dessas
modificaes relativas a dados possam ser feitas diretamente pelo
usurio.
9 A abordagem de anlise de sistemas discutida neste livro represen
ta a forma atual da anlise estruturada. Como veremos no captulo
7, algumas modificaes ocorreram desde que a anlise estruturada
foi apresentada pela primeira vez em livros no final dos anos 70.
10 Isso se baseia na pesquisa levada a efeito por Lientz e Swanson
( e Swanson, 19801).
11 Existem, naturalmente, excees a esse faseamento gradual, mor
mente quando o novo sistema tem de receber todo o volume de
servio (transaes) do sistema antigo de uma s vez. Veja em
[ 19841 um interessante exemplo de um projeto desse gne
ro, no qual um sistema dinamarqus de comrcio em mbito nacio
nal foi convertido para um novo sistema.
12 Como a indstria da computao representa aproximadamente 8 a
10% do GNP americano, isso significa que eles esto gastando cer
ca de $75 per capita por ano em manuteno de software.
13 Existem algumas excees a essa otimista afirmativa. No caso de
certas aplicaes crticas (previso do tempo, pesquisa nuclear,
modelagem das propriedades aerodinmicas de avies e autom
veis etc.), a tecnologia atual de processamento ainda no ade
quada (para uma anlise mais detalhada sobre isso veja FYourdon,
1986D. Embora para muitos sistemas de tempo-real e embutidos a
tecnologia atual de processamento seja adequada, os projetistas de
sistemas e os programadores precisam desenvolver grande esforo
para alcanarem um aceitvel nvel de eficincia. Alm disso, em
alguns casos a tecnologia do hardware parece adequada, mas o
novo software (ex.: as novas linguagens de quarta gerao) revela-
se to ineficiente que o sistema como um todo no tem um nvel
de eficincia aceitvel.
150
7
MODIFICAES
NA ANALISE
DE SISTEMAS
Novas e4)rasses como tenso tcnica e choque tcnico foram criadas para definir as man
psicolgicas de um pblico subjugado por coisas desde fornos de microondas a jogos
domsticos t Pac-Man. Infelizmente, essas c no descrevem de modo correto o
progresso no campo do processamento de dados pertencente ao desenvolvimento de
software. Para muitos profissionais do processamento de dados, a tenso tcnica pode ser
definida de modo melhor como a frustrao com o ritmo lento das mod nos mtodos de
desenvolvimento de software, em face da crescente demanda por servios de pd.
Embora no haja dvidas de que algum progresso foi feito nos lti mos 30 anos rumo a
melhores mtodos de desenvolvimento de sistemas, tambm no se discute que acima de
tudo, todo processo de mod o lento e descontnuo. Observando-se a partir de uma
perspectiva histrica, parece que, para que seja obtido algum progresso, necessrio
reconsiderar peridica e coletivamente as idias bsicas, Os perodos entre os grandes
avanos podem ser de dezenas ou de centenas de anos.
Fj. Grant, Twenty Century Software
Datamalion, 1 de abril de 1985
Neste captulo, aprenderemos:
1. Os problemas da anlise de sistemas clssica.
2. As modificaes ocorridas na anlise estruturada clssica.
3. Porque as ferramentas automatizadas so importan tes para o futuro da anlise dc
sistemas.
4. Porque os problemas da anlise estruturada clssica conduziram protoupao.
151
Os mtodos e ferramentas apresentados neste livro representam a abordagem que ser
utilizada na maioria das organizaes de desenvol vimento de sistemas no final dos anos
80 e incio dos 90. Nos meados da dcada de 90 provvel que a anlise de sistemas
tenha evoludo subs tancialmente; o captulo 25 discute a provvel natureza dessa
evoluo.
Porm, no basta estar ciente das tcnicas atuais da anlise de sistemas. necessrio
conhecer tambm as modificaes introduzidas nos ltimos cinco ou dez anos,
modificaes essas que conduziram s fcj e tcnicas que exploraremos em profundidade
nas partes II e III. Existem trs motivos para que voc esteja familiarizado com a
evoluo da anlise de sistemas.
Primeiro, voc talvez venha a perceber que a empresa de desen volvimento de sistemas
para a qual voc trabalha no evoluiu e que nin gum tem qualquer inteno de fazer
alteraes. Embora as modifica es discutidas neste captulo tenham ocorrido em cerca
de 80% das organizaes de processamento de dados da Amrica do Norte, da Euro pa e
de outras partes do mundo, ainda existem aqueles basues da mediocridade que no vem
razes para modificar o modo como vm fazendo as coisas h 20 anos. No caso de voc
se encontrar nessa situa o, a coisa mais lgica a fazer mudar de emprego; ou, se voc
estiver aborrecido, procure oci uma posio de liderana e ajude sua em presa a ingressar
no mundo moderno da anlise de sistemas .
Segundo (e mais freqente), voc pode observar que sua empresa j comeou a
implementar algumas das modificaes vistas neste captu lo, mas que o processo de
mudana ainda continuar por alguns anos. Um bom exemplo disso o desenvolvimento
dc ferramentas automatiza das de anlise de sistemas. Quase todos os analistas de
sistemas lhe afirmaro que as ferramentas baseadas em PC so uma excelente idia e
alguns gerentes de PED esto comeando a apoiar esse conceito. Mas as ferramentas so
relativamente novas, praticamente nenhuma delas exis tia antes de 1984. E as
organizaes modificam-se com lentido; no final de 1987, estimava-se que menos de 2%
dos analistas de sistemas nos Estados Unidos tinham acesso s ferramentas discutidas
neste livro. Esti ma-se que, por volta de 1990, aproximadamente 10% dos analistas de
sistemas estaro utilizando essas ferramentas e que uma verdadeira satu rao do
mercado de trabalho provavelmente no ocorrer antes dos meados da dcada de 90.
Desse modo, mesmo que voc e outros mem
bros de sua empresa saibam o tipo de ferramentas e de tcnicas que sero instaladas
daqui a trs anos, a abordagem atual da anlise de sistemas pode ser algo diferente.
importante conhecer a abordagem que a organizao utilizava anteriormente e qual o tipo
de transio est em andamento.
Terceiro, a noo de transio importante mesmo que voc tra balhe em uma das
empresas de ponta, que tenha j implementado a
152
abordagem de anlise de sistemas tratada neste livro. O campo da anli se de sistemas,
como todos os outros aspectos da rea do processamen to, dinmico; a maneira como
faremos anlise de sistemas em 1995 ser indubitavelmente da maneira como a
realizamos agora, mas para saber quais sero as mudanas que ocorrero no meio e no
final da dcada de 90, torna-se necessria a apreciao de provenincia desse campo e
para onde ele se dirige.
7.1 A PASSAGEM PARA A ANUSE ESTRUTURADA
At o final dos anos 70, a imensa maioria dos projetos de desenvol vimento de sistemas
comeava pela criao de uma novela vitoriana sobre os requisitos do usurio. Isto , o
analista de sistemas documenta va o que ele ou ela conhecia daqueles requisitos em um
macio doai mento constitudo principalmente de uma narrativa no idioma adequado. Os
autores dos primeiros livros sobre anlise estruturada, especialmen te [ 1978], [ e
Sarson, 19771 e lWeinberg,19781 mostraram que aqueles tornos ponderveis (muitas
vezes chamados de especifica o funcional) padeciam tipicamente de alguns grandes
problemas:
Eles eram monolticos: era necessrio ler toda a especificao funcional, do princpio ao
fim, para poder compreend-la. As sim como uma novela vitoriana, se no lssemos a
ltima p gina, no saberamos como a histria terminava 2 Isso era uma deficincia
importante, porque existem muitas situaes em que o analista de sistemas, ou o usurio,
queria ler e compreender urna parte da especificao sem necessariamente ter de ler
qualquer outra parte.
Eles eram redundantes: a mesma informao era muitas vezes repetida em diversas partes
diferentes do documento .O problema disso era que se qualquer aspecto dos requisitos do
usurio fosse alterado durante a fase da anlise de sistemas (ou, pior ainda, depois da fase
de anlise ter sido considerada como concluda), a alterao teria de se refletir em
diversas partes do documento. Isso hoje em dia seria um problema menor, uma vez que
mesmo as mais primitivas organizaes tm amplo aces so s facilidades do
processamento de palavras; porm, nas dcadas de 60 e 70, a maioria das empresas criava
suas especifi caes funcionais sem nada mais sofisticado do que uma mquina de
escrever eltrica . Corno era muito dificil atualizar e revisar o documento, a redundncia
inerente conduzia a um grave problema: inconsistncia. Assim como uma pessoa com
153
muitos relgios dificilmente saber que horas realmente s uma especificao funcional
com a mesma informao repeti trs ou quatro vezes possivelmente conter erros nessa
inforrr o em algumas oportunidades.
Eles eram ambguos: o detalhamento dos requisitos do usui podia ser (e geralmente era)
interpretado de modo difereii pelo usurio, pelo analista de sistemas, pelo projetista e pe
programador. Estudos feitos no final dos anos 70 concluira que 50% dos erros
eventualmente encontrados em um sisten operativo e 75% do custo da eliminao de
erros podiam s imputados a falhas de interpretao ou a erros da espccifica funcional.
A manuteno deles era impossvel: por Lodos os motivos aciff descritos, a especificao
funcional quase sempre estava ol soleta no final do processo de desenvolvimento do
sistema (ist , quando o sistema entrava em operao), o que muitas vez ocorria no final
da fase de anlise. Isso significa que a maior dos sistemas desenvolvidos durante os anos
60 e 70 - sistem que tm agora 20 anos ou mais - no tm o registro atualizad da diretiva
que eles supostamente conservavam. Como os an:
listas de sistemas e os usurios originais h muito tempo j n esto mais presentes, a triste
realidade que ningum sabe que a maior parte dos principais sistemas de processamen
faz hoje.
Enquanto todos esses problemas estavam sendo debaudos, u conjunto complementar de
idias j estava sendo adotado na rea c programao e projeto. Essas idias, geralmente
mencionadas coit programao estruturada e projeto estruturado, prometiam grandes mi
1horas na organizao, codificao, testes e manuteno de programas tinham, na
verdade, se mostrado de geral sucesso; porm mais e ma empresas de PED comearam
gradualmente a perceber que no hav como se escrever brilhantes programas e como
projetar sistemas alt mente modulares se soubesse realmente o que os sistemas deveria
fazer. Na realidade, algum poderia argumentar que a programa estruturada e o projeto
estruturado possibilitavam que algumas equip de projeto chegassem a um desastre com
mais rapidez que nunca - construindo uma brilhante soluo para o problema errado!
Como resultado tem havido um movimento gradual - gradu no sentido de que a atividade
de desenvolvimento de sistemas levc cerca de dez anos para aceitar - rumo a
especificaes funcionais q sejam:
154
Grficas - compostas por vrios diagramas, apoiados por material textual detalhado que,
em muitos casos, serve melhor como material de referncia cio que o corpo principal da
especificao.
Particionadas - de modo a que partes individuais da especifi cao possam ser lidas
independentemente de outras.
De redundncia mnima - para que as alteraes dos requisi tos do usurio possam ser
incorporadas em apenas uma parte da
especificao.
Essa abordagem, conhecida por todos como anlise estruturada, agora utilizada na
maioria das empresas comerciais de desenvolvimento de sistemas e em grande nmero
das empresas de engenharia. Ainda existem algumas empresas preparando especificaes
do tipo novela vitoriana, mas elas j esto em minoria e, como os dinossauros, se exti
guiro em algum momento.
7.2 MODIFICAES DA ANUSE ESTRUTURAL CLSSICA
Como j dissemos, a anlise tradicional de sistemas (caracterizada pelas especificaes
vitorianas) comeou a se modificar no final dos anos 70. A maioria das empresas que
agora usa anlise estruturada ba seia sua abordagem nos primeiros livros dc DeMarco,
Gane e Sarson, Weinberg e outros, bem como nos seminrios, videoteipes e outros re
cursos de treinamento fundamentados nesses livros.
Entretanto, alguns anos de experincia prtica com a anlise estruturada clssica
indicaram diversas reas em que precisam ser feitas algu mas alteraes ou extenses. As
principais alteraes 5
A nfase na construo de modelos fisicos e lgicos atuais do sistema do usurio
mostrou-se politicamente perigosa. A equipe de projeto muitas vezes gastou tanto tempo
(por vezes seis meses, um ano ou mais) estudando o antigo sistema do usurio, um
sistema que todos sabiam que seria dispensado e substituido por um novo, que o projeto
acabou cancelado por um usurio impaciente anLes que a equipe de projeto pudesse
iniciar a tarefa de estudar o novo sistema proposto. Isso no quer dizer que tenhamos
decidido evitar a modelagem do sis tema atual do usurio em todos os casos, mas apenas
que reco nhecemos ser essa uma atividade politicamente perigosa, e que
155
provavelmente dever ser minimizada, se no totalmente elimi nada. Esse ponto voltar a
ser discutido no captulo 17.
A anlise estruturada clssica fazia uma distino vaga e pobre mente definida entre
modelos fisicos (que fazem conjecturas sobre, ou so influenciados pela tecnologia da
implementao) e modelos lgicos (que so independentes da tecnologia da
implementao); na verdade, at os termos lgico e fisico so confusos para muitos.
Idias importantes nessa rea foram intro duzidas por [ e Palmer, 1984] e mesmo partes
da terminologia foram modificadas: agora nos referimos a modelos essenciais (modelos
da essncia de um sistema) em lugar de modelos lgicos, e a modelos de
implementao em lugar de
modelos fisicos.
Mais e mais empresas esto utilizando tcnicas de anlise estruturada para construir
sistemas de tempo-real Entretanto, a an lise estruturada clssica no tem como modelar
o compor tamento tempo-dependente de um sistema; falta-lhe a notao para apresentar
interrupes e sinais, e para mostrar a sincroni zao e a coordenao de diferentes
tarefas de processamento. Para resolver esse problema, foi-lhe acrescentada uma notao
adicional e toda uma nova ferramenta de modelagem - fluxos de controle, processos de
controle e diagramas de transies de
estado. Mais detalhes sobre isso nos captulos 9 e 13.
A anlise estruturada clssica concentrava-se quase inteiramente na modelagem das
funes a serem executadas pelo sistema; a
modelagem dos dados era feita de uma forma primitiva e mui tas vezes sem receber
muita nfase e at ignorada. Enquanto isso, um nmero crescente de empresas percebeu
que seus sis temas envolviam funes, relacionamentos de dados e carac tersticas de
tempo-real complexas. Como vimos, os diagramas de transies de estado foram
acrescentados anlise estrutu rada para possibilitar a modelagem de sistemas de tempo-
real; para possibilitar a modelagem de sistemas com complexos rela cionamentos de
dados, foram acrescentados os diagramas de entidades-relacionamentos. Mais importante
que o simples acrscimo de uma ou duas ferramentas de modelagem o fato de que trs
das principais ferramentas de modelagem possam ser integradas, isto , utilizadas em
conjunto de maneira que cada uma preste apoio outra. Os diagramas de entidades-rela
cionamentos so estudados no captulo 12 e o conceito de modelos integrados visto no
captulo 14.
156
O processo da anlise estruturada modificou-se substancialmen te. A anlise estruturada
clssica presumia que o analista de sis temas comearia desenhando um diagrama de
contexto, um diagrama de fluxo de dados com uma nica bolha represen tando todo o
sistema, e depois subdividiria o sistema em diver sas funes e vrios depsitos de dados
em uma forma estri tamente top-down. Infelizmente, isso no funcionava bem, pelas
razes apresentadas no captulo 20, e em conseqncia, foi acrescentada uma nova
abordagem denominada subdiv de eventos. A terminologia e os conceitos bsicos da
subdiviso de eventos foram apresentados por [ e Palmer, 1984] e estendidos por [ e
Mellor, 1985].
7.3 O SURGIMENTO DAS FERRAMENTAS AUTOMATIZADAS DE ANUSE
Quando as tcnicas de modelagem grfica da anlise estruturada comearam a se
disseminar pelas empresas de desenvolvimento de siste mas no final dos anos 70 e incio
dos 80, os analistas de sistemas come aram a perceber que existia um problema
importante: o trabalho arts tico necessrio para criar diagramas de fluxo de dados,
diagramas de entidades-relacionamentos, diagramas estruturais, diagramas de transi es
de estado e outros modelos grficos era muitas vezes excessivo, O problema, na maior
parte dos casos, no era a criao inicial dos diagra mas, mas a reviso e a manuteno. A
criao do diagrama inicial consome tempo mas, pelo menos d a satisfao de ser uma
atividade desafIadora, criativa e intelectual. Em um projeto tpico, o analista de sistemas
sabe que ter de redescnhar os modelos grficos vrias vezes at que ele e o usurio
cheguem a um acordo sobre os requisitos do sistema
Em um grande sistema, pode haver 50 a 100 ou mais diagramas de fluxo de dados, alguns
diagramas de entidades-relacionamentos e possi velmente vrios diagramas de transies
de estado; desse modo, o volu me de trabalho artstico envolvido pode ser realmente
assustador. A con seqncia prtica disso, em muitas empresas, que a anlise
estruturada clssica no foi to bem-sucedida quanto deveria. Ocorreram os seguin tes
problemas:
Aps a segunda ou terceira reviso do diagrama, o analista de sistemas tornava-se
progressivamente hostil e relutante em fazer novas modificaes. Assim, era possvel
encontrar diagramas congelados que no refletiam verdadeiramente os requisitos do
sistema do usurio.
157
Em face do volume de servio envolvido, o analista de sistemas por vezes no mais
subdividia o modelo do sistema em modelos de nvel mais baixo - isto , em vez de
desenvolver um modelo constitudo de cinco nveis de diagramas de fluxo de dados, ele
parava no quarto nvel. O modelo resultante continha funes primitivas (isto , as
bolhas do quarto nvel) que de fato no o eram; isso se tornava t complexo que o
programador preci sava executar algumas tarefas de anlise de sistemas para poder
escrever os programas .
As alteraes dos requisitos do usurio aps a fase de anlise do projeto muitas vezes
no eram incorporadas ao modelo do sis tema. Muitas dessas alteraes ocorriam durante
as fases de projeto, programao e de testes do sistema, enquanto outras ocorriam depois
de o sistema ter sido implementado. O resul tado era uma especificao obsoleta.
Alm do trabalho necessrio para criar e manter os diagramas, a anlise estruturada
clssica exige um grande volume de trabalho para verificar os diagramas para garantir
que estejam completos e consis tentes; essas normas so discutidas no captulo 14 lO Nos
anos 70 e na maior parte dos 80, os analistas de sistemas dependiam de tcnicas manuais
de verificao (inspees visuais dos diagramas para localizar erros). Como esse trabalho
uma atividade intensa e aborrecida, tende a ser sujeita a erros. Em conseqncia, muitos
erros de especificao dei xaram de ser encontrados.
Muitos desses problemas podem ser resolvidos com um adequado apoio automatizado;
isso era bem conhecido mesmo quando a anlise estruturada clssica foi apresentada pela
primeira vez, mas o custo da automatizao era muito mais elevado do que o que as
empresas po diam suportar. Entretanto, o desenvolvimento de poderosos terminais
grficos em meados da dcada dc 80 conduziu a uma atividade total mente nova
conhecida por CASE (computer-Aided , Engine ering); algumas dzias de fornecedores
oferecem produtos (geralmente para PC) que desenham diagramas de fluxos de dados e
coisas seme lhantes, bem como executam diversas tarefas dc verificao de erros. As
caractersticas e exemplos dessas ferramentas so discutidas no apndice A.
Como j foi mencionado, apenas 2% dos analistas de sistemas nos Estados Unidos
dispunham dessas ferramentas em 1987, e estima-se que apenas 10% as tero em 1990.
Todavia, isso obviamente o caminho do futuro e podemos esperar que todos os analistas
profissionais insistiro nelas proporo que o tempo passar. Isso levar, em princpio, a
um melhor nvel de qualidade dos modelos dc sistemas produzidos; em
158
segundo lugar, levar a modelos grficos de sistema visualmente mais atraentes.
proporo que os conceitos de verificao de erros discuti dos no capituio 14 forem
automatizados, isso pode eliminar a necessida de de os analistas de sistemas conhecerem
o material do captulo 14! E proporo em que as ferramentas CASE comecem
eventualmente a gerar programas (em COBOL, Pascal ou talvez em uma linguagem de
quarta gerao) diretamente a partir das especificaes, haver uma reduo na
necessidade de programadores!
7.4 O USO DA PROTOTIPAO
Como mostramos no capitulo 3, alguns usurios tm dificuldade em lidar com os
modelos grficos da anlise estruturada, preferindo al gum Outro modo de modelar os
requisitos e o comportamento do siste ma. As ferramentas de prototipao, que
comearam a se tornar ampla mente disponveis em meados da dcada de 80, tm sido
vistas por alguns como uma alternativa anlise estruturada para tais usurios.
Existe um outro motivo para a popularidade da prototipao: a anlise estruturada
clssica vista em algumas empresas como consumi dora exagerada de tempo; no
momento em que a fase de anlise termi na, o usurio j esqueceu o que ele queria
inicialmente do sistema. Isso, de hbito, resulta dos seguintes problemas:
A equipe de projeto gastou tempo demais desenvolvendo modelos do sistema atual do
usurio e depois teve de despen der ainda mais tempo modelando o novo sistema. Como
j foi mencionado, a modelagem do sistema atual agora vista como uma atividade
politicamente perigosa.
A empresa investiu anteriormente pouco ou nenhum tempo em fazer qualquer anlise do
sistema, preferindo comear a codifi cao logo que possvel. Em um ambiente assim, o
prolongado trabalho da anlise de sistemas, que aparenta no produzir sadas exceto
figuras com crculos e quadros, pode parecer improdutiva.
Os primeiros projetos utilizando a anlise estruturada podem consmir mais tempo do
que o normal, porque os analistas de sistemas esto aprendendo novas tcnicas e
consultando um ao outro qual a melhor maneira de aplic-las.
As ferramentas de prototipao (ferramentas de software que per mitem ao analista de
sistemas construir uma imitao do sistema) esto
159
sendo consideradas corno uma efetiva soluo para esses problemas Observe tambm que
a prototipao tende a se concentrar no aspecto da interface humana de um projeto de
desenvolvimento de sistema.
Infelizmente, as ferramentas de prototipao s vezes so utilizadas
para evitar os detalhes combinados da anlise e do projeto de sistemas;
o uso adequado da prototipao foi mostrado na seo 5.6.
7.5 O CASAMENTO DA ANLISE E DO PROJETO DE SISTEMAS
Como j foi anteriormente mencionado neste captulo, os aperfei oamentos na rea da
engenharia de software se iniciaram com a progra mao estruturada e com o projeto
estruturado. Na realidade, esses dois tpicos foram tema de considervel debate em
empresas de desenvolvi mento de sistemas durante a primeira metade da dcada de 70.
Foi tambm nessa poca que comearam a surgir os primeiros livros sobre projeto
estruturado (veja lMyers, 1975] e [ e Constantine, 1975]). Esses primeiros livros no
faziam referncia anlise estruturada (uma vez que os conceitos ainda no tinham sido
desenvolvidos), enquanto os livros posteriores, como [ 1980], incluam uma breve vista
geral do assunto. O trabalho sobre anlise estruturada comeou em meados dos anos 70, e
os primeiros livros comearam a aparecer no final daquela dcada; mas havia pouca ou
nenhuma conexo entre a discus so da anlise estruturada e a sobre projeto estnsturado.
O problema principal estava em que a anlise estruturada lidava com a especificao de
sistemas grandes e complexos, enquanto o projeto estruturado pare cia mais apropriado
para o projeto de programas individuais a serem processados em um s computador.
Faltava a ponte entre a anlise de sistemas e o projeto de programas, isto , o projeto de
sistemas.
Esse problema foi tratado por diversos consultores, autores e em presas de
desenvolvimento de sistemas nos anos 80. Livros recentes de [ e Melior, 19851, bem
como novas edies de livros por [ Jones, 1988] e [ e Constantine, 19891, agora tratam
dos proble mas do projeto de sistemas e do projeto de programas.
7.6 RESUMO
Como qualquer campo da cincia da engenharia, a anlise de siste mas passou por uma
srie de modificaes evolutivas durante os ltimos 20 anos. Como indicado no incio
deste captulo, importante saber quais foram essas modificaes, porque a atividade de
desenvolvimen to de software to grande e variada que ningum utiliza as mesmas
160
tcnicas que outros. Sua empresa pode estar no bordo de ataque da tecnologia ou no
bordo de fuga.
Podemos esperar que a rea da anlise de sistemas continue pro gredindo e que as
tcnicas apresentadas neste livro tero evoludo ainda mais nos prximos cinco a dez
anos, O captulo 25 examina a provvel natureza das futuras modificaes evolutivas.
REFERNCIAS
1. Tom DeMarco, StructuredAnalysts and System Spec Nova lorque: YOURDON Press,
1978.
2. Chris Gane e Trish Sarson, Structured Systems Analysis and Design. Nova lorque:
Improved Systems Technologies, Inc., 1977.
3. Victor Weinberg, Structured Analysis. Nova Iorque:YOURDON Press, 1978.
4. Paul Ward e Steve Mellor, Structured Development for Real-Time Systems. Volumes
1-3. Nova Torque: YOURDON Press,1985.
5. Steve McMenamin e John Palmer, Essential Systems Analysis. Nova lorque:
YOURDON Press, 1984.
6. Glen Myers, Reliable Systems through Composite Design. Nova lor que:
Petroceili/Charter, 1975.
7. Edward Yourdon e Larry Constantine, Stnsctured Desgn, 1 cd. Nova lorque:
YOURDON Press, 1975.
8. Meilir Page-Jones, The Practical Guide to Structured Systems De sign, 1 ed. Nova
lorque: YOURDON Press, 1980.
9. Meilir Page-Jones, The Practical Guide to Structured Systems De sign, 2 ed.
Englewood Cliffs, N.J.: Prentice-Hall, 1988.
10. Edward Yourdon e Larry Constantine, Siructured Design, 2 cd. Englewood Cliffs,
N.J.: Prentice-hall, 1989.
PERGUNTAS E EXERCCIOS
1. Quais so os trs principais motivos para que voc conhea a evoluo da anlise de
sistemas?
2. O que voc deveria fazer se a organizao em que voc trabalha no tiver feito as
modificaes discutidas neste captulo?
3. Apresente quatro principais problemas de uma especificao narra tiva clssica.
4. Por que a redundncia indesejvel na especificao de um siste ma? possvel
remover toda a redundncia de uma especificao?
5. Voc pode imaginar algum motivo pelo qual a redundncia pode ria ser til na
especificao de um sistema?
161
6. Quais so as trs razes comuns pelas quais a redundncia intro duzida em uma
especificao clssica?
7. Que percentagem de erros em um sistema operativo pode ser atri buIda aos erros
ocorridos durante a fase de anlise de sistemas do
projeto?
8. Projeto de Pesquisa: qual a percentagem de erros em sua organi zao que pode ser
atribuida a erros ocorridos durante a fase de
anlise de sistemas do projeto?
9. Quais so as conseqncias de uma especificao impossvel de ser mantida?
10. Faa uma breve descrio de programao estruturada.
11. Faa uma breve descrio de projeto estruturado.
12. Por que algumas organizaes descobriram que no so bem sucedidas quando
utilizam a programao estruturada e o projeto
estruturado?
13. Quais so as trs principais caractersticas da especificao estruturada?
14. Quais so as cinco principais modificaes que ocorreram na an use estruturada
clssica?
15. Qual o problema que a anlise estruturada clssica apresenta ao lidar com sistemas de
tempo-real?
16. Quais so os riscos associados modelagem do sistema atual de informaes do
usurio? Quanto tempo se deve despender com
essa modelagem?
17. Quais so os trs principais problemas que o analista de sistemas talvez encontre se
no dispu ser de apoio automatizado em seu
trabalho?
18. importante dispor de apoio automatizado nos projetos de desen volvimento de
pequenos sistemas de informaes? Por qu?
19. Que problemas podem ser encontrados se o analista de siste mas tiver de executar
manualmente as atividades de verificao
de erros?
20. Por que, em sua opinio, apenas 2% dos analistas de sistemas nos Estados Unidos
dispunham de estaes de trabalho para anlise
automatizada de sistemas em 1987?
21. Que benefkios adicionais podem ser obtidos da introduo de uma rede de
ferramentas automatizadas de anlise de sistemas?
(Obs.: um desses benefcios a mala eletrnica).
22. Quais so os trs problemas comuns que as organizaes encon traram na
implementao da anlise estruturada clssica?
23. Que problemas de interfacc existiam entre a anlise estruturada e o projeto
estruturado na dcada de 70 e no incio da de 80?
162
NOTAS
Isso no uma sugesto frvola. Se essas organizaes no se
modificarem, estaro fora do mercado em um determinado mo mento da dcada de 90.
2 Ou, em outras palavras, no havia sexo at a ltima pgina.
3 Existem vrias teorias para explicar porque a redundncia era uma caracterstica to
comum. Pela minha prpria experincia a especi ficao funcional servia a trs diferentes
objetivos na empresa (e por isso a mesma informao era apresentada em trs modos
diferentes): primeiro: ela era a declarao oficial dos requisitos do usurio; segundo: ela
era um manual de treinamento no-ofi cial, destinado a explicar como os estpidos
usurios deveriam operar o sistema, e terceiro: ela era uma ferramenta de vendas po
liticamente orientada, destinada a fazer crer direo que o sistema iria ser to bom que
valeria o preo de sua elaborao.
4 Um dos melhores exemplos desse problema talvez seja o que ocor reu em uma
importante organizao de PED de um banco nova iorquino em meados da dcada de 70.
Reunidos em uma tpica horda monglica de projeto de desenvolvimento de sistemas, o
grupo de analistas de sistemas entrevistou dzias de usurios por todo o banco e
desenvolveu gradualmente a especificao vitoria- na de tamanho entorpecedor. A
datilografia do documento ocupou o pool de datilgrafos por duas semanas e todas as
copiadoras Xerox foram requisitadas por diversos dias para que fossem feitas cpias
suficientes para distribuio aos usurios. Foi dada uma se mana para que a comunidade
usuria lesse toda a especificao funcional e apontasse quaisquer modificaes ou
correes; para grande surpresa (e imenso alvio) os analistas no receberam ne nhum
comentrio por parte dos usurios na data limite. Assim, a especificao funcional foi
declarada como congelada e deu-se a partida nos trabalhos de projeto e programao.
Trs semanas mais tarde, seis membros da comunidade usuria anunciaram que ti nham
finalmente terminado de ler toda a especificao e, sim, eles tinham algumas pequenas
alteraes. Seguiu-se um pequeno pni co: o que seria feito com a especificao? Aps
duas furiosas reu nies nas quais os usurios e os analistas de sistemas insultavam os
ancestrais e a inteligncia uns dos outros em termos que no po dem ser repetidos em um
livro como este, chegaram a uma de ciso: as modificaes no seriam incluidas na
especificao datilo grafada (porque isso seria muito dificil), mas seriam incorporadas ao
sistema. Ou, em outras palavras: a equipe de projeto achou que seria mais fcil alterar o
COBOL do que o ingls.
163
5 Veja James Martin, An Information Systems Man (Englewood Cliffs, N.J.: Prentice-
Hall, 1984).
6 Reveja a definio e os exemplos de sistemas de tempo-real no capitulo 2.
7 Isso talvez seja um tanto injusto, porque IDeMarco, 19781 e IGane e Sarson, 19771
dedicam um ou mais captulos s estruturas de dados.
Mas a notao utilizada (diagramas de estruturas de dados) atualmente considerada
obsoleta; alm disso, boa parte da nfase dos primeiros livros estava na converso de um
conjunto arbitrrio de estruturas de dados para a terceira forma normal, que (1) to
simpies que o processo foi mecanizado e (2) mais um problema
de implementao, ou de projeto, que de anlise de sistemas.
8 Isso talvez no seja evidente para voc por enquanto, porque vi mos apenas alguns
diagramas de anlise estruturada no captulo 4.
Contudo, no final da parte II, ficar bastante evidente; caso contr rio, aguarde at o final
de seu primeiro projeto real de anlise
estruturada!
9 Como veremos no captulo 11, deve haver uma especificao de processo
(habitualmente escrita como uma tabela de deciso, um
fluxograma ou em formato de portugus estruturado) para cada bolha primitiva de ltimo
nvel no diagrama de fluxo de dados. Se
o sistema tiver sido adequadamente subdividido, a maioria das especificaes de
processos deve ter menos de uma pgina.
10 Exemplos de normas de verificao: todos os fluxos de dados de um DFD devem ter
nome, e esses nomes devem estar definidos no
dicionrio de dados. Todas as entradas do dicionrio de dados devem corresponder a
fluxos de dados ou depsitos no DFD. Cada bolha no DFD deve ter pelo menos um fluxo
de dados que chega
e pelo menos um fluxo de dados que sai. E assim por diante.
164

CARACTERSTICAS DAS FERRAMENTAS


DE MODELAGEM
Qualquer coisa fcil, se voc puder inclu-la em sua coleo de
modelos.
Seymour Papert, Mindstorins
Neste captulo, aprenderemos:
1. Porque as ferramentas de modelagem de sistemas so habitualmente grficas.
2. Porque as ferramentas de modelagem de sistemas so subdivisveis na modalidade top-
down.
3. Porque as ferramentas de modelagem de sistemas tm redundncia mnima.
4. Porque as ferramentas de modelagem de sistemas auxiliam a modelagem do
comportamento de sis temas.
Os prximos captulos deste livro descrevem as diversas ferramen tas de modelagem que
voc usar como analista de sistemas. Antes de mergulharmos nos detalhes dos diagramas
de fluxo de dados, dos dia gramas entidade-relacionamentos etc., existem alguns aspectos
introdu trios que precisamos rever.
Voc se recordar do captulo 4 que um modelo um fac-simile
barato de um sistema complexo que desejamos estudar. Os modelos de
sistemas so construdos por trs motivos:
1. Para focalizar caractersticas importantes de sistemas deixando de lado as menos
importantes.
167
2. Para discutir alteraes e correes nos requisitos do usurio a baixo custo e com
mnimo risco.
3. Para confirmar que entendemos o ambiente do usurio e o do cumentamos de uma tal
maneira que os projetistas de sistemas e
programadores podem construir o sistema.
Mas existem muitas espcies diferentes de modelos que podemos construir para o
usurio: modelos narrativos, modelos de prottipos, v rios modelos grficos e assim por
diante. Na realidade, o sistema final que construmos para o usurio pode revelar ser um
modelo - no sentido de que ele pode representar, pela primeira vez, um meio de o usurio
visualizar o que ele deseja.
Neste livro, focalizaremos nossa ateno nos modelos em papel (ou modelos em papel
produzidos por sistemas automatizados CASE). Existe, porm, uma grande variedade
deles: como veremos em maiores detalhes nos prximos captulos, existem fluxogramas,
diagramas HIPO, tabelas de deciso, diagramas de fluxo de dados, fluxogramas de
sistemas, dia gramas de transies de estado, rvores de deciso, diagramas de entida de-
relacionamentos, diagramas de Ferstl, diagramas de Hamilton-Zeldin, diagramas DAP e
um conjunto interminvel de diagramas, tabelas e gr ficos que podemos apresentar ao
usurio. Qual deles deveremos utilizar?
A premissa bsica deste livro que voc deve utilizar qualquer modelo que seja til para
voc e para a situao em que voc se encon trar. Diferentes usurios podem precisar de
diferentes ferramentas de modelagem pela experincia anterior ou porque eles
consideram que certas espcies de diagramas os confundem e intimidam. Diferentes
projetos podem exigir diferentes ferramentas de modelagem face aos padres de
documentao impostos por organizaes externas. E dife rentes tipos de sistemas podem
exigir modelos diferentes para realar adequadamente as caractersticas importantes.
Levando essa questo mais adiante, muitos sistemas exigem mode los mlt cada modelo
focaliza um nmero limitado de aspectos do sistema, deixando de lado (ou ignorando)
outros aspectos do sistema. Isso vale especialmente para muitos sistemas construdos
hoje, uma vez que eles tm complexas caractersticas funcionais, complexas estruturas de
dados e complexas consideraes temporais.
Qualquer ferramenta que voc utilize deve ter as seguintes
caractersticas:
Ela deve ser grfica, com adequado detalhamento textual de apoio.
168
Ela deve permitir que o sistema possa ser visualizado de forma subdividida, na
modalidade top-down.
Ela deve ter mnima redundncia.
Ela deve ajudar o leitor a prognosticar o comportamento do sistema.
Ela deve ser transparente para o leitor.
Exploraremos cada um desses pontos a seguir.
8.1 MODELOS GRFICOS
A maioria dos modelos de sistemas mais conhecidos, e todos aque les usados neste livro,
apia-se firmemente em grficos. O uso de grfi cos no obrigatrio em um modelo de
sistema, porm o velho adgio de que numa figura vale por mil palavras uma boa
justificativa para a nossa preferncia por grficos em lugar de textos narrativos. Uma
figura bem escolhida pode englobar uma imensa quantidade de informaes de forma
concisa e compacta.
Isso no significa que uma figura possa descrever, necessariamen te, tudo sobre um
sistema; para isso poderia criar algo to confuso que ningum se interessaria em
examinar. Geralmente usamos grficos para identificar os componente.s de um sistema e
as lnte7face-s entre eles; todos os outros detalhes (isto , as respostas para perguntas
como Quantos? e Em que seqncia? etc.) so apresentadas em documentos textuais
de apoio. Os documentos textuais de apoio descritos neste livro so a especificao do
pmcesso e o dicionrio de dados.
Isso no significa que todos os analistas de sistemas devam usar o conjunto de
ferramentas de modelagem orientadas para grficos e textos apresentado neste livro. O
Grande Analista de Sistemas celestial no o fulminar com seus raios pela no utilizao
de diagramas de fluxo de dados. No entanto, voc provavelmente ser atingido por raios
se escolher um ou outro dos extremos de tudo em grficos (sem texto de apoio) ou tudo
em texto (sem grficos). E voc ser queimado com pelo menos um pequenino raio se
fizer do texto a parte dominante do modelo, com grficos desempenhando um papel
menor e subordinado. Um ou mais grficos devem ser o principal documento a que o
usurio poder recorrer para compreender o sistema; os documentos textuais devem
servir como material de referncia a ser consultado quando necessrio.
169
8.2 MODELOS SUBDWLSVEIS NA MODALIDADE TOP-DOWN
Um segundo aspecto importante de uma boa ferramenta de mode lagem a sua aptido
para retratar um sistema de forma subdividida top down. Isso no importante para
pequenos sistemas, porque podemos dizer tudo que precisa ser dito em uma ou duas
pginas, e qualquer um que necessite conhecer qualquer aspecto do sistema poder
aprender tudo do sistema.
Entretanto, os projetos reais do mundo real no so geralmente pequenos Na realidade, a
maioria dos projetos em que voc provavel mente se envolver variar de mdios a
gigantescos. Em conseqncia, ser impossvel para qualquer um, sejam eles usurios,
analistas de sistemas ou programadores, focalizar todo o sistema de uma s vez. Nem
seria possvel apresentar um modelo grfico de um grande e complexo sistema em uma
simples folha de papel - a menos que se queira consi derar o extremo burlesco de uma
folha de microficha de 8 por 10 ps! Dessa maneira, nossas ferramentas de modelagem
devem nos permitir retratar partes individuais do sistema de uma forma isolado, juntamen
te com um modo dreto de passar de uma pan do modelo do sistema para outro.
Entretanto, necessitamos bem mais do que isso: no seria apropria do, por exemplo, criar
um enorme modelo grfico de 30 X 30m e, em seguida, dividi-lo em 9 mil pedaos
separados de 0,1 X O,lm, com milha res de conectores de pginas. Isso equivaleria,
aproximadamente, ao desenho de um mapa das ruas de todo os Estados Unidos em uma
nica (embora grande) folha de papel e, em seguida, subdividi-la em milha res de
pedaos do tamanho de pginas.
Na realidade, nossa experincia com mapas e atlas demonstra como precisamos organizar
um modelo de sistema complexo. Um atlas dos Estados Unidos, por exemplo,
normalmente comea com um dia grama de uma nica pgina de todo o pas, como
mostrado na figura 8.1. Essa pgina mostra os estados, e pode mostrar tambm as
principais interfaces entre os estados (rios, rodovias interestaduais, ferrovias, rotas areas
etc.). As pginas subseqentes so habitualmente dedicadas a cada estado, de forma
individual, com cada pgina apresentando as ci dades e municpios de um estado, bem
como as rodovias estaduais lo cais que no foram mostradas no mapa a nvel de pais.
Pode-se imaginar mapas de nvel inferior, que mostram detalhes sobre cada municpio,
cada cidade dentro de um municpio e cada bairro dentro de uma cidade.
Um bom modelo de um complexo sistema de informaes deve
proceder da mesma forma top-down. Uma viso geral de alto nvel de
uma parte do modelo deve dar ao leitor uma boa idia dos principais
170
componentes de alto nvel e das interfaces do sistema. As partes subse qentes do modelo
forneceriam informaes sobre componentes deta lhados de baixo nvel do sistema. E,
assim como um atlas fornece um mecanismo prtico para percorrermos todo o conjunto
de mapas indivi duais (isto , partindo do mapa de nvel de pas para o mapa em nvel de
municpio sem grandes dificuldades), um bom modelo de um sistema de informaes
fornece um modo prtico para passar suavemente de alto para baixo nvel.
8.3 MODELOS DE MNIMA REDUNDNCIA
Os modelos so representaes de algum sistema do mundo real, e o prprio sistema
pode ser esttico (inaltervel) ou dinmico. O mapa dos Estados Unidos, por exemplo,
uma representao grfica do pas onde moramos. E, embora muitos aspectos do nosso
pas sejam cla ramente muito dinmicos, pode-se objetar que os aspectos modelados por
um mapa so relativamente estticos: estados individuais no apa recem ou desaparecem
com freqncia, e as fronteiras entre os estados tm estado relativamente constantes por
um longo perodo (em con traste, no podemos dizer o mesmo em relao a um mapa do
mundo inteiro!).
Em que isso interessa a uma pessoa ao construir um modelo?
Simplesmente porque desejvel manter o modelo em uma forma
correta e atual. Se o sistema se alterar, o modelo deve ser modificado se
Figura 8.1: Mapa dos Estados Unidos
171
quisermos mant-lo atualizado. Evidentemente, se somente um aspecto local do sistema
for modificado, preferiramos modificar apenas um correspondente aspecto local do
modelo, sem sermos forados a alterar qualquer outro aspecto dele. Na realidade, se
forem necessrias ml tiplas mudanas, existe uma boa possibilidade de que elas no
sejam feitas, ou que elas sejam feitas de qualquer maneira. E isso significa que o modelo
se tornar gradualmente menos correto.
Para ilustrar isso considere uma vez mais nosso exemplo do atlas dos Estados Unidos.
Poderamos imaginar, no caso mais simples, uma pgina apresentando o pas inteiro, e 50
pginas subseqentes mostran do os detalhes de cada estado. Agora imagine o que
aconteceria se o es tado de Nova Jersey desaparecesse : o mapa do pas precisaria ser re
desenhado para mostrar o novo pas de 49 estados, e o mapa original do estado de Nova
Jersey seria descartado.
Porm, seria um pouco mais difcil com atlas reais porque, como tpico com muitos
modelos de Sistemas, existe alguma redundncia em butida. Cada mapa de estado mostra
no somente o estado que est sendo descrito, mas partes dos estados vizinhos -
informaes que so adequadamente fornecidas no mapa do pas, mas que convm t-las
em nvel de estado, tambm. Isso quer dizer, portanto, que se Nova Jersey desaparecesse,
teramos, provavelmente, que redesenhar os ma pas de Nova lorque e da Pensilvnia, e
talvez Maryland e Delaware. Que aborrecimento!
Cartgrafos profissionais poderiam desaprovar isso e argumentar que uma certa
redundncia necessria para tornar o atlas mais fcil de ser lido. Entretanto, evidente
que quanto maior for a redundncia que o modelo contiver, maior ser a dificuldade para
mant-lo. Imagine, por exemplo, que nosso atlas mtico mostre as rodovias interestaduzis
no mapa a nvel de pas e todos os mapas a nvel de estado. Imagine, tam bm, que um
fabricante de mapas tenha decidido mostrar toda a ex tenso de cada rodovia
interestadual em cada mapa de estado atravs do qual passa a estrada. Assim, a
Interestadual 95, que corre do Maine Flrida, apareceria nos mapas de cerca de uma
dzia de estados, cada um dos quais estaria afetado pelo (redundante) fato de que toda a
estra da tem aproximadamente 1.700 milhas de extenso, O que aconteceria se fosse
descoberto que essa figura estava errada ou que parte da estrada tenha sido prolongada ou
redesenhada? Obviamente, uma dzia de diferentes mapas estaduais teriam de ser
alterados.
8.4 MODELOS TRANSPARENTES
Para finalizar, um bom modelo deve ser to fcil de ler que o
leitor no precise parar para pensar que ele ou ela est olhando para a
172
representc.o de um sistema, em vez do prprio sistema. Isso no sempre fcil de ser
conseguido, e muitas vezes requer alguma educao e prtica de parte do leitor. Pense em
um mapa, por exemplo: quantas vezes voc pensou estar olhando para uma representao
abstrata do estado de Nova Jersey em lugar do prprio estado? Por outro lado, observe
uma pequena criana examinando um mapa enquanto seus pais ou seu professor tentam
explicar que Nova Jersey se limita com Nova lorque e que Newark est a dez milhas de
distncia de Nova Jorque. No, no , a criana dir, Newark fiGa somente a meia
polegada de distncia da cidade de Nova lorque.
proporo que ficamos mais velhos, no entanto, tornamo-nos gradualmente mais
familiarizados com o conceito de representaes abstratas desde que elas se acomodem
confortavelmente em nossas ca beas. Cientistas estudaram o comportamento e
organizao do crebro humano e descobriram que o lado esquerdo do crebro lida com
pro cessamento seqencial, uma coisa de cada vez; , tambm, o lado es querdo do
crebro que lida com texto, por exemplo, as palavras que voc est lendo, uma de cada
vez, nesta pgina de papel. O lado direito do crebro lida com figuras e com
processamento assncrono, mui tas coisas ao mesmo tempo. Isso nos mostra que se
experimentarmos modelar alguma coisa que seja intrinsecamente linear e seqencial, tal
como o fluxo de controle em um programa de processamento, devemos utilizar uma
ferramenta de modelagem textual que se acomode confortavelmente no lado esquerdo do
crebro, que mais apto para lidar com ela. E se estivermos tentando modelar alguma
coisa que seja intrinsecamente multidimensional, com muitas atividades sendo
executadas ao mesmo tempo, devemos utilizar uma ferramenta de modelagem grfica.
8.5 RESUMO
No tenho dvidas de que voc estar to ocupado aprendendo as ferramentas de
modelagem apresentadas neste livro que no pensar na pssibilidade da existncia de
outras ferramentas de modelagem. Entre tanto, elas existem, e logo examinaremos
diversas ferramentas alternati vas no capitulo 15.
Voc ser exposto a uma variedade de ferramentas de modelagem em projetos do mundo
real. Embora os detalhes (e formas e formatos) dessas ferramentas de modelagem possam
variar enormemente, voc deve verificar cuidadosamente se elas seguem os princpios
bsicos e diretrizes apresentados neste captulo.
173
PERGUNTAS E EXERCCIOS
1. Quais so as trs principais razes para se construir modelos de sistemas?
2. Descreva trs diferentes tipos de modelos de sistemas.
3. Quais so as principais caractersticas que uma ferramenta de modelagem de sistemas
deve ter?
4. Por que as ferramentas de modelagem grfica so geralmente pre feridas em relao s
ferramentas de modelagem textual?
5. necessrio utilizar ferramentas de modelagem grfica para desen volver um sistema
de informaes? Voc pode imaginar alguma si tuao em que no desejaria utilizar tais
ferramentas?
6. Que coisas os modelos grficos normalmente no mostram sobre um sistema?
7. Por que importante que uma ferramenta de modelagem retrate um sistema de forma
top-down? Existe alguma situao em que
isso no importante?
8. A descrio top-down de um sistema exige que esse sistema seja projetado na
modalidade top-down?
9. Descreva uma situao onde seria aceitvel incluir redundncia no modelo de um
sistema.
NOTAS
1 Um corolrio disso que as boas ferramentas de modelagem nor malmente envolvem
notaes muito simples, com muito poucas re gras, simbolos e novas palavras para o
usurio aprender. Um puris ta poderia mesmo argumentar que uma boa ferramenta de
modela gem no requer explanaes e nem treinamento; em qualquer caso, no deve ser
necessrio ler as 700 pginas de um livro como este para aprender como ler e
compreender um modelo desenvol vido pelo analista de sistemas.
2 Em outras palavras, mais e mais desses pequenos projetos esto sendo desenvolvidos
pelos usurios sem . assistncia de analistas de sistemas e programadores. Com a
crescente disponibilidade de computadores pessoais, pacotes de planilhas eletrnicas e
lingua gens de quarta gerao, muitas tarefas que exigiriam alguns dias (ou mesmo
semanas) de trabalho de um profissional em processa mento podem agora ser feitas em
questo de minutos ou de horas pelo usurio. Entretanto, continuam a existir muitos
sistemas de
174
informaes, hoje, que necessitam de mais de 10 milhes de instru es de programa para
executar seu objetivo.
3 Se voc vive em Nova Jersey ou tem alguma outra patolgica cone xo com esse
estado, esteja vontade para utilizar um outro estado
para esse exemplo. Minhas desculpas a Bruce Springsteen.
175
9
DIAGRAMA DE
FLUXO DE DADOS
A forma sempre se segue a funo.
Louis Henry Suilivan
The Tal! Office Building Artistically Considered,
Lippincott s Magazine, maro de 1986
Neste captulo aprenderemos:
1. Os componentes de um diagrama de fluxo de dados.
2. Como desenhar um diagrama de fluxo de dados simples.
3. Diretrizes para desenhar diagramas de fluxo de da dos com sucesso.
4. Como desenhar diagramas de fluxo de dados nivelados.
Neste captulo vamos explorar uma das trs principais ferramentas de modelagem grfica
da anlise estruturada: o diagrama de fluxo de dados. Esse diagrama uma ferramenta de
modelagem que nos permite imaginar um sistema como uma rede de processos
funcionais, interliga dos por dutos e tanques de armazenamento de dados. Na
literatura do processamento de dados e em suas conversas com outros analistas de
sistemas e usurios, voc pode usar qualquer um dos termos abaixo como sinnimo de
diagrama de fluxo de dados:
Diagrama de bolhas
DFD (abreviatura que utilizaremos em todo este livro)
177
Modelo de processo
Diagrama de fluxo de trabalho
Modelo funcional
uma representao do que est acontecendo por aqui
O diagrama de fluxo de dados uma das mais utilizadas ferramen tas de modelagem de
sistemas, principalmente para sistemas operativo nos quais as fi4nes do sistema sejam
de fundamental importncia mais complexas do que os dados manipulados pelo sistema.
Os DPII foram utilizados pela primeira vez na rea da engenharia de softwar como uma
representao para o estudo dos problemas do projeto d sistemas (p,ex,: nos primeiros
livros e artigos sobre projeto estruturado como [ Myers e Constantine, 19741, lYourdon e
Constantine 19751, [ 19751 et alii). A representao, por sua vez, foi trazid de antigos
trabalhos sobre a teoria dos grafos e continua a ser usada como uma forma cmoda de
notao por engenheiros de softwar interessados na implementao direta de modelos dos
requisitos dc usurio.
Isso um retrospecto interessante, mas provavelmente rrelevant para os usurios a quem
so mostrados os modelos do sistema em DFD Em realidade, provvel que a pior coisa
que se pode fazer dizer: Sr Usurio, gostaria de lhe apresentar um modelo iop-down,
particionado fundamentado na teoria dos grafos, dc seu sistema. Muitos usurio esto
familiarizados com o conceito subjacente dos DFD, porque mesmo tipo de representao
tem sido utilizado por cientistas pesquisa dores de operaes durante cerca de 70 anos
para elaborar os modelo do fluxo de tarefas das organizaes. importante lembrar isto:
os DFL podem ser usados no s para modelar sistemas de processamento d informaes,
mas tambm como um meio de se modelar organizae inteiras, isto , como uma
ferramenta para o planejamento comercial estratgico.
Iniciaremos nosso estudo de diagramas de fluxo de dados pek exame dos componentes de
um DFD tpico: o processo, o fluxo, o dep sito e o terminador. Empregaremos uma
notao amplamente padroniza da para DFD, seguindo a notao de livros clssicos
como [ 19781, [ e Sarson, 19771 e outros. Coniudo, tambm incluiremos representao
de DFD para a modelagem de sistemas de tempo-rea (fluxos de controle e processos de
controle). Essa representao suple mentar geralmente no necessria para sistemas
orientados para comrcio, mas torna-se essencial para a modelagem de vrios sistema:
de engenharia e cientficos.
178
A seguir, vamos rever algumas diretrizes para a construo de dia gramas de fluxo de
dados para que possamos minimizar a possibilidade de construirmos um DFD confuso,
incorreto ou inconsistente. Para termi nar, discutiremos o conceito dc DFDs nivelados
como um mtodo de modelar sistemas complexos.
Lembre-se que o DFD apenas uma das ferramentas de modela gem disponveis para o
analista de sistemas e que ele oferece apenas uma viso do sistema - a viso orientada
para funes. Se estivermos desenvolvendo um sistema no qual os relacionamentos entre
os dados sejam mais importantes que as funes, podemos dar menor importncia aos
DFD (e at no desenvolvermos nenhum) e nos dedicarmos ao de senvolvimento de um
conjunto de diagramas de entidades-relaciona mentos como podemos ver no captulo 12.
Como alternativa, se o com portamento tempo-dependente do sistema sobrepujar todos os
outros aspectos, podemos nos dedicar aos diagramas dc transies de estado discutidos
no captulo 13.
9.1 OS COMPONENTES DE UM DFD
A figura 9.1 mostra um DFD tpico de um pequeno sistema. Antes
de analisarmos seus componentes em detalhe, observe que:
Ele no precisa de explicaes; basta olharmos para ele para compreend-lo. A
representao simples e sem intruses e, de uma certa forma, bastante intuitivo. Isso
especialmente impor tante quando lembramos quem supostamcnte examinar a fi gura -
no o analista dc sistemas, mas o usurio! Se precisar de uma enciclopdia para ler e
entender o modelo do sistema, provavelmente no se interessar por nada daquilo.
O diagrama acomoda-se facilmente em uma pgina. Isso tem dois significados: (1) uma
pessoa pode examinar o diagrama sem se confundir e (2) o sistema que est sendo
modelado no muito complexo. Que fazer se o sistema for intrinsecamente to
complexo que haver literalmente centenas de crculos e linhas no diagrama Dicutiremos
isso na seo 9.4.
O diagrama foi desenhado por um computador. Nada existe de errado com diagramas
desenhados mo, mas a figura 9.1 e muitos dos DFD mostrados neste livro foram
desenhados com auxlio do programa MacDraw da Macintosh. Isso quer dizer que o
diagrama desenhado com mais exatido e de um modo mais padronizado do que seria
possvel se tivesse sido desenhado
179
nome do cliente,
detalhes de faturas
Figura 9.1: Um DFD tpico
mo e que as alteraes podem ser feitas e novas verses pc
dem ser produzidas em questo de minutos
9.1.1 O Processo
O primeiro componente dc um DFD conhecido como pmcess Os sinnimos mais
conhecidos so bolha, funo e transformao. ( processo mostra uma parte do sistema, a
que transforma entradas em sa:
das - isto , mostra como uma ou mais entradas so convertidas er sadas. O processo
representado graficamente por um crculo, como s v na figura 9.2(a). Alguns analistas de
sistemas preferem usar um ov ou um retngulo de vrtices curvos, como mostrado na
figura 9.2(b outros preferem ainda um retngulo, corno na figura 9.2(c). As dif renas
entre esses trs formatos so puramente cosmticas, embora sej obviamente importante
utilizar o mesmo formato de maneira consistent para representar todas as funes do
sistema. Neste livro usaremos serr pre o crculo ou bolha 2
180
CALCU LAR
IMPOSTO
SOBRE
VENDAS
Figura 9.2 (a): Um exemplo de processo
( CALCULM
1 IMPOSTO
SOBRE
EN DAS
Figura 9.2(b): Representao alternativa de um processo
CALCULAR
IMPOSTO
SOBRE VENDAS
Figura 9.2 (c): Outra representao de um processo
Observe que o processo denominado ou descrito com uma nica palavra ou sentena
simples. Na maioria dos modelos de DFD que vere mos neste livro, o nome do processo
descrever o que o processo faz. Na seo 9.2, falaremos mais sobre a adequada
atribuio de nomes s bolhas de processos; por enquanto, suficiente dizer que um bom
no me geralmente composto por uma frase constituda de um um verbo e de um objeto,
como VALIDAR ENTRADA ou CALCULAR VALOR DO IMPOSTO.
Em alguns casos, o processo conter o nome de uma pessoa ou de um grupo de pessoas
(um departamento ou diviso de um empresa, p.ex.), ou de um computador ou de um
dispositivo mecnico. Isto , o processo s vezes descreve quem ou o que executa o
processo, em lugar de descrever o que o processo . Discutiremos isso com mais detalhes
no captulo 17, quando estudarmos o conceito de modelo essencial, e na parte IV, quando
examinarmos os modelos de implementao.
9.1.2 OFluxo
Um fluxo graficamente representado por uma seta que entra ou
sai de um processo; a figura 9.3 apresenta um exemplo de fluxo. O fluxo
181
utilizado para mostrar o movimento de fragmentos ou de pacotes informaes de um
ponto a outro do sistema. Desse modo, o flu representa dados em movimento, enquanto
os depsitos (descritos m adiante na seo 9.L3) representam dados cm repouso.
Na maioria dos sistemas que voc modela como analista de sst mas, os fluxos, na
realidade, representam dados, isto , bits, caractere mensagens, nmeros de ponto
flutuante e os diversos outros tipos de i formaes com que o computador lida. Mas os
DFD tambm podem s usados para modelar outros sistemas alm dos automatizados o
computadorizados; podemos, por exemplo, usar um DFI) para model uma linha de
montagem onde no haja componentes computadorizado Em um caso assim, os pacotes
ou fragmentos transportados pelos fluxc podero ser materiais fsicos (pode-se ver um
exemplo na figura 9.4 Em muitos sistemas complexos do mundo real o DFD mostra o
fluxo d materiais e de dados.
Observe que os fluxos das figuras 9.3 e 9.4 tm nomes. O noni representa o significado
do pacote que se move pelo fluxo. Um corolri disso que o fluxo transporta apenas um
tipo de pacote, o que indic do pelo nome do fluxo. Os analistas de sistemas no devem
atribuir um fluxo de dados um nome como MAS E LARANJAS E VRIA OUTRAS
COISAS. Entretanto, como veremos na parte 111, existem exa es a essa conveno: s
vezes til reunir diversos fluxos de dadc elementares em um fluxo consolidado. Desse
modo, poderamos ter ui nico fluxo de dados denominado VEGETAIS em lugar de
vrios fluxc diferentes rotulados como BATATAS, CEBOlAS e ERVILHAS. Como v
remos, isso exige algumas explicaes no dicionrio de dados, que e tudaremos no
captulo 10.
Embora isso possa parecer um tanto bvio, lembre-se que um me mo contedo pode ter
significados diferentes em pontos diferentes d sistema. Considere, por exemplo, o
fragmento de sistema da figura 9.5
CONSULTA DE CLIENTE
Figura 9.3: Um exemplo defluxo
182
O fragmento de dados (p. ex.: 212-410-9955) tem significado dife rente quando passa
pelo fluxo rotulado NMERO-DE-TELEFONE e quando passa pelo fluxo denominado
NMERO-DE-TELEFONE- VLIDO. No primeiro caso ele indica um nmero de
telefone que pode ser vlido ou no, enquanto que no segundo ele indica um nmero de
telefone que, no contexto do sistema, sabido ser vlido.
MISTURA PARA BOLOS
BOLO
Figura 9.4: Um DFD com fluxos mdteriais
FONE AR NMERO NMERO-DE-TELEFONE-VLIDO
Figura 9.5: Um DFD tpico
Outro modo de se interpretar isso ver o fluxo denominado nmero de telefone como
um duto, capaz de permitir a passagem in discriminada de nmeros de telefone vlidos e
invlidos atravs dele; o fluxo NMERO-DE-TELEFONE-VLIDO mais estreito, ou
mais discri minativo, permitindo que passe por ele apenas um conjunto estreita- mente
definido de dados.
Observe tambm que o fluxo mostra dtvo: uma seta em uma das extremidades do
fluxo (ou em ambas) indica se os dados (ou o material) entram ou saem do processo (ou
as duas coisas). O fluxo visto na figura 9.6(a), por exemplo, mostra claramente que um
nmero de telefone est sendo enviado para o processo rotulado VALIDAR NMERO
DE
183
TELEFONE. E o fluxo rotulado ESCAIA-DE-ENTREGM)ORES na figura 9.6(b)
claramente um fluxo de sada gerado pelo processo GERAR- ESCALA-DE-
ENTREGADORES; os dados que se movimentam por aquele fluxo ou iro transitar para
outro processo (como entrada) ou para um depsito (como discutido na seo 9.1.3) ou
para um terminador (como discutido na seo 9.1.4). O fluxo com duas setas mostrado na
figura 9.6(c) um diIo uma prtica juno de dois pacotes de dados (consulta e
informao ou pergunta e resposta) no mesmo fluxo. No caso de um dilogo, os pacotes
em cada extremidade da seta devem ser rotulados, como se v na figura 9.6(c)
Os fluxos de dados podem divergir e convergir em um DFD; con ceitualmente, mais ou
menos como um rio de grande volume subdivi dindo-se em rios menores, ou tributrios
reunindo-se em um maior. Isso, entretanto, tem especial significado em um DFD tpico
no qual pacotes de dados transitam pelo sistema: no caso de um fluxo divergente, isso
quer dizer que cpias de um pacote de dados so enviadas para diferen NMERO
Figura 9.6 (a): Um fluxo de entrada
Figura 9.6 (b): Um fluxo de sada
CONSULTA-SOBRE-SITUAO-DE-PEDI DO
Figura 9.6 (e): Umflu.xo de diloRo
18 /
tes partes do sistema, ou que um pacote complexo de dados est sendo dividido em vrios
pacotes de dados mais simples, cada um dos quais encaminhado para pontos diferentes
do sistema ou que o duto de dados transporta itens com valores diferentes (ex.: vegetais
cujos valores sejam batata, cebola ou ervilha) que estejam sendo separados. In
versamente, no caso de um fluxo convergente, isso quer dizer que vrios pacotes
elementares de dados esto sendo reunidos para formar pacotes de dados complexos e
agregados. Por exemplo, a figura 9.7(a) mostra um DFD onde o fluxo DETALHES-DE-
PEDIDOS diverge e transporta cpias dos mesmos pacotes para os processos GERAR
DOCUMENTOS DE EMBARQUE, ATUALIZAR INVENTRIO e GERAR FATURA.
A figura 9.7(b) apresenta o fluxo rotulado como ENDEREO-DE-CLIENTE subdividido
em pacotes mais simples rotulados como NMERO-DE- TELEFONE, CDIGO-
POSTAL e ENDEREO, que so remetidos para trs processos diferentes de validao
EDIDOS INVLIDOS
Figura 9.7 (a): Um fluxo diz
185
PEDIDO
DETALHES DE
1
Figura 9.7 (b): Outro exemplo defluxo divergente
Observe que o fluxo no responde a muitas perguntas procedura que voc poderia fazer
ao examinar o DFD. Ele nada informa sobi prompts para entradas, por exemplo, e nem
responde perguntas sobi fluxos de sada. Por exemplo, a figura 9.8(a) mostra o caso
simples d um fluxo de entrada chegando ao processo PROCESSAR PEDIDO. M como
isso acontece? PROCESSAR PEDIDO solicita explicitamente entrada? Por exemplo, ele
apresenta um prompt ao usurio de ui sistema on-line, indicando que deseja uma entrada?
Ou ser que
pacotes de dados transitam pelo fluxo por suas prprias vontades, sei serem chamados?
De modo semelhante, a figura 9.8(b) mostra um flux simples de sada emanando de
GERAR RELATRIO DE FATURA; Sei que as FATURAS transitam por aquele fluxo
quando GERA RELATRIO DE FATURA as quer remeter, ou quando outro setor d
sistema reclama o pacote? Para finalizar, considere a situao, ma comum, apresentada na
figura 9.8(c), na qual existem mltiplos fluxc de entrada e de sada; em que seqncia
chegam os fluxos de dados ei que seqncia so gerados os fluxos de saida? Existe uma
propor um-para-um entre os pacotes de entrada e os de sada? Isto , o process
186
E N DEREO-DE-CLIENTE
CDIGO-POSTAL
Q exige exatamente um pacote dos fluxos de entrada A, B e C para pro duzir exatamente
um pacote de sada para os fluxos X, Y e Z? Ou so dois A para cada trs B?
A resposta a todas essas perguntas muito simples: no sabemos. Todas essas perguntas
envolvem detalhes procedurais, o tipo de per guntas que normalmente seriam modeladas
cm um fluxograma ou em alguma outra ferramenta de modelagem procedural. O DFD
simples men te no trata desses aspectos. Se essas perguntas tiverem importncia
Figura 9.8 (a): Um fluxo de entrada
AT
Figura 9.8 (b): Um fluxo de sada
A
B
Figura 9.8 (c): Combinao defluxos de entrada e de sada
187
para voc, ento ser necessrio modelar o procedimento interno de di versos processos;
as ferramentas para isso so estudadas no captulo 11.
9.1.3 O Depsito
O depsito utilizado para se modelar uma coleo de pacotes de dados em repouso. A
representao para um depsito so duas linhas paralelas, como na figura 9.9(a); uma
notao alternativa mostrada na figura 9.9(b) outra representao, usada no estudo dc
caso do apndi ce F, apresentada na figura 9.9(c). Normalmente o nome escolhido para
identificar o depsito o pluraldo nome dos pacotes transportados pelos fluxos para
dentro e para fora do depsito.
PEDIDOS
Figura 9.9 (a): Representao grfica de um depsito
D J PEDIDOS
Figura 9.9 (b): Urna representao aliernativa para um depsito
( PEDIDOS
Figura 9.9 (c): A representao utilizada no Apndice F
Para o analista de sistemas com retrospecto de processamento de dados, tentador
referir-se aos depsitos como arquivos ou bancos de dados (ex.: um arquivo em fita
magntica ou um arquivo em disco orga nizado com o IMS, DB2, ADABAS, IDMS ou
com algum Outro conhecido sistema de gerenciamento de banco de dados). Na realidade,
isso como os depsitos so muitas vezes implementados em sistemas compu
tadorizados; mas um depsito tambm pode conter dados armazenados em cartes
perfurados, microfilmes, microfichas, discos ticos e vrias outras modalidades
eletrnicas. Um depsito tambm pode ser compos to por cartes de 3 por 5 indexados
em uma caixa, ou nomes e endere os em um livro de endereos, ou por algumas pastas
de arquivos em um armrio ou por diversas outras formas no computadorizadas. A fi
gura 9.9(d) mostra um exemplo tpico de um depsito de um sistema manual.
precisamente por causa da variedade de implementaes
188
1
Figura 9.9 (d): Outra forma de depsito
possveis de um depsito que dcliberadamente escolhemos uma repre sentao grfica
simples e abstrata e o termo depsito em lugar de, por exemplo, banco de dados 6
Alm da aparncia fisica que o depsito assume, existe ainda a questo de seu propsito:
o depsito existe por causa de um requisito bsico do usurio ou por um aspecto prtico
da implementao do sis tema? No primeiro caso o depsito existe como uma necessria
rea de armazenamento de espera entre dois processos que ocorrem em mo mentos
diferentes. Como exemplo, a figura 9.10 mostra um fragmento de um sistema em que,
como uma questo de mtina do usurio (indepen dentemente da tecnologia que ser usada
para implementar o sistema), o processo de entrada de pedidos pode funcionar em
momentos diferentes (e possivelmente at no mesmo momento) do processo de consulta a
pedidos. O depsito PEDIDOS tem que existir dc alguma forma, em disco, fita, cartes
ou em tabuinhas de argila.
A figura 9.11(a) mostra um tipo diferente de depsito: o depsito de implementao.
Podemos imaginar o projetista de sistemas interpon do o depsito PEDIDOS entre
INTRODUZIR PEDIDO e PROCESSAR PEDIDO porque:
Ambos os processos devem ser executados no mesmo computa dor, mas no h
memria sufkiente (ou algum outro recurso de hardware) para acomodar ambos os
processos simultaneamente. Assim, o depsito PEDIDOS foi criado como arquivo
interme dirio, tendo em vista que a tecnologia de implementao dis ponvel forou que
os processos sejam executados em momen tos diferentes.
Um ou ambos os processos devem ser executados em uma configurao de hardware
no totalmente confivel. Por causa disso, o depsito PEDIDOS foi criado como um
mecanismo de backup para a eventualidade de um dos processos ser mal sucedido.
189
CONFIRMAO
Figura 9.10: Um depsito necessrio
Os dois processos devem ser implementados por diferentes programadores (ou, no caso
mais extremo, por diferentes grupos de programadores trabalhando em locais
geograficamente dife rentes). O depsito PEDIDOS foi, assim, criado para servir co mo
facilidade para testes e depu rao de modo a que se o sis tema inteiro no funcionar,
ambos os grupos possam examinar o contedo do depsito para descobrir o problema.
O analista e o projetista de sistemas imaginaram que o usurio poderia eventualmente
querer ter acesso ao depsito PEDIDOS para alguma finalidade, mesmo que no tivesse
indicado tal interesse. Nesse caso, o depsito foi criado em antecipao a fu turas
necessidades do usurio (e como vai custar alguma coisa a implementao do sistema
com esse recurso, o usurio vai pagar por um recurso do sistema que no foi solicitado).
Se exclussemos os problemas e modelssemos somente os requisi tos essenciais do
sistema, no haveria necessidade do depsito PEDI DOS; teramos, assim, um DFD
como o da figura 9.11(b).
Como pudemos ver pelos exemplos apresentados at agora, os depsitos so interligados
aos processos por fluxos. Dessa maneira, o contexto em que um depsito se apresenta em
um DFD um (ou am bos) dos seguintes:
190
DETALHES DE PEDIDOS PEDIDO
PEDIDOS
PEDIDO
DETALHES DE PEDIDOS
Um fluxo de um depsito
Um fluxo para um depsito
Na maioria dos casos os fluxos so rotulados como vimos na seo
9.1.3. Entretanto, muitos analistas dc sistemas no se preocupam em rotular o fluxo se
todo um grupo de um pacote entra ou sai do depsito Para exemplificar, a figura 9.12
mostra um fragmento de DFD.
Um fluxo que parte de um depsito normalmente interpretado
como uma leitura ou um acesso feito s informaes desse depsito.
Especificamente, pode significar que:
Um pacote isolado de dados foi recuperado do depsito: este , de fato, o exemplo mais
comum de um fluxo que sai de um de psito. Imagine, por exemplo, um depsito
chamado CLIEN TES, onde cada pacote Contm informaes de nome, endereo e
telefone de clientes. Um fluxo tpico que sasse desse depsito
HES DE PEDIDOS
PEDIDO
PEDIDOS
EDIDO /uDO
RESPOSTA
Figura 9.11 (a): Um depsito de implementao
PEDIDOS
(
EDIDO JLIDO
RESPOSTA
Figura 9.11 (b): O depsito de implementao removido
191
Figura 9.12: Depsitos com JZu no-rotulados
envolveria a recuperao de um pacote completo de infor
maes sobre um cliente.
Mais de um pacote foi recuperado do depsito. Por exemplo o fluxo poderia recuperar
pacotes de informaes sobre todo os clientes da cidade de Nova lorque a partir do
depsit
CLIENTES.
Apenas uma parte do pacote foi recuperada do depsito Em alguns casos, por exemplo,
apenas a parte do nmero d telefone de um cliente poderia ser recuperada do depsit
CLIENTES.
Partes de mais de um pacote foram recuperadas do depsito Por exemplo, um fluxo
pode recuperar do depsito CIJENTE
o cdigo postal de todos os clientes do estado de Nova lorque
Como observamos ao examinarmos fluxos que entram e saem d um processo, teremos
muitas perguntas. procedurais quando exami namos fluxos que entram e saem de um
depsito: o fluxo represent um nico pacote, mltiplos pacotes, partes de pacote ou partes
de v rios pacotes? Em alguns casos, essas dvidas podem ser respondida pelo simples
exame do rtulo do fluxo; se o fluxo no possuir um rtulo isso quer dizer que um pacote
inteiro de informaes est send recuperado (como indicado acima, isso apenas uma
conven
192
PEQUENOS OBJETOS VERMELHOS INGREDIE
MAS
NO-MAS
prtica); se o rtulo do fluxo for o mesmo que o do depsito, ento um pacote inteiro (ou
mltiplas instncias de um pacote inteiro) est sendo recuperado; e se o rtulo do fluxo
for algo diferente do nome do de psito, ento um ou mais componentes de um ou mais
pacotes esto sendo recuperados 8
Embora algumas das perguntas procedurais possam ser respondi das pelo exame
cuidadoso dos rtulos dos fluxos, nem todos os detalhes so evidentes. Na verdade, para
sabermos tudo o que queremos sobre um fluxo que parte de um depsito, temos que
examinar os detalhes - a espec de processos- do processo ao qual o fluxo est interliga do;
as especificaes de processos sero discutidas no captulo 11.
H um detalhe procedural do qual podemos estar certos: o depsi to passivo e os dados
no transitam a partir dele pelos fluxos a menos que um processo os solicite
explicitamente. Existe outro detalhe proce dural que pressuposto, por conveno, para
os sistemas de processa mento de informaes: Um depsito no se altera quando um
pacote de informaes se movimenta a partir dele por um fluxo. Os programa dores
referem-se a isso como leitura no-destrutiva; em outras palavras, uma cpia do pacote
recuperada do depsito, que permanece em suas condies originais .
Um fluxo para um depsito muitas vezes descrito como uma
escrita, uma atualizao ou possivelmente uma eliminao. Em termos
especficos, ele pode ter um dos seguintes significados:
Um ou mais novos pacotes esto sendo introduzidos no depsito. Dependendo da
natureza do sistema, os novos paco tes podem ser acrescentados (appended) (isto ,
colocados de tal forma que fiquem depois dos pacotes j existentes); ou po dem ser
colocados em algum lugar entre os pacotes j existen tes. Isso muitas vezes um
problema de implementao (con trolado pelo especfico sistema de gcrcnciamento de
banco de dados), caso em que o analista dc sistemas no deve se preocu par com isso.
Entretanto, pode ser uma questo de orientao do usurio.
Um ou mais pacotes esto sendo eliminados ou removidos do depsito.
Um ou mais pacotes esto sendo modificados ou alterados. Isso pode envolver a
alterao de todo um pacote, ou (mais habitual) apenas parte dc um pacote ou parte de
mltiplos pacotes. Para exemplificar, suponha que uma delegacia mantenha um depsito
de possveis criminosos e que cada pacote contenha o nome e endereo de um suspeito; a
delegacia poderia oferecer
193
uma nova identidade para um suspeito que colaborasse, caso em que todas as
informaes relativas quele suspeito seriam alteradas. Como alternativa, considere o
depsito CLIENTES que contm informaes sobre os clientes residentes em Man
hattan; se os Correios decidissem alterar o cdigo postal de uma rea de Manhattan
(como ocorreu em 1983, quando a rea de Manhattan onde eu morava teve o cdigo
postal alterado de 10028 para 10128), seria necessria a alterao de uma parte de vrios
pacotes.
Em todos esses casos evidente que o depsito se altera em resul tado da entrada do
fluxo. O responsvel pela alterao do depsito o
processo (Ou processos) interligado outra extremidade do fluxo.
Um aspecto que deve ter ficado evidente de todos os exemplos mostrados at aqui: os
fluxos interligados a um depsito s podem trans portar pacotes de informaes que o
depsito pode aceitar. Desse modo, um fluxo interligado ao depsito CLIENTES s pode
transportar infor maes relativas aos clientes que o depsito contenha, no podendo
transportar pacotes de inventrio ou de fabricao nem dados astronmicos.
9.1.4 O Ter
O componente seguinte do DFD e o tenntnador ele grafi camente representado por um
retngulo, como mostrado na figura 9.13. Os terminadores representam entidades
externas com as quais o sistema se comunica. Tipicamente, o terminador uma pessoa ou
um grupo de pessoas, por exemplo, uma organizao externa ou uma empresa do governo
ou um grupo ou setor que esteja dentro da mesma companhia ou organizao, mas fora
do controle do sistema que est sendo mode lado. Em alguns casos, o terminador pode ser
outro sistema, por exemplo, algum outro sistema de processamento com o qual nosso
sistema se comunicar.
DEPARTAMENTO
DE
CONTABILIDADE
Figura 9.13: Representao grfica de um terininador
194
Costuma ser muito fcil identificar os terminadores do sistema em modelagem. s vezes o
terminador o usurio; isto , em nossas discus ses com o usurio, ele dir: Pretendo
fornecer os itens de dados X, Y e Z para o sistema e espero receber dele os itens de dados
A, B e C. Em outros casos, o usurio considera-se parte do sistema e o ajudar a iden
tificar os terminadores importantes; por exemplo, ele poder dizer-lhe:
Precisamos estar prontos para recebermos formulrios tipo 321 do Departamento de
Contabilidade e temos de remeter semanalmente Rela trios Oramentais para a
Comisso de Finanas. Nesse ltimo caso, claro que o Departamento de Contabilidade
e a Comisso de Finanas so terminadores separados com os quais o sistema se
comunica.
Existem trs importantes aspectos a serem lembrados sobre termi nadores:
1. Eles so externos ao sistema que estamos modelando; os fluxos que interligam os
terminadores aos diversos processos (ou de- psitos) de nosso sistema representam a
interface entre o sis tema e o mundo externo.
2. Como conseqncia, evidente que nem o analista nem o pro jetista de sistemas esto
em posio de modificar o contedo de um terminador ou o modo como o terminador
funciona. Na linguagem de vrios livros clssicos sobre anlise de sistemas, o terminador
est fora do domnio das modificaes. O que isso quer dizer que o analista de sistemas
est modelando um sistema com a inteno de proporcionar ao projetista um considervel
grau de flexibilidade e liberdade de escolher a melhor (ou mais eficiente ou mais
confivel etc.) implementa o possvel. O projetista de sistemas pode implementar o sis
tema em um modo consideravelmente diferente da forma como ele est no momento
implementado; o analista de sistemas po de preferir modelar os requisitos do sistema de
um modo que parea consideravelmente diferente da forma com que o usu rio imagina o
sistema agora (mais sobre isso na seo 9.4 e na parte III). Mas o analista de ststemas no
pode mod o con tedo, ou a organizao ou os procedimentos relativos aos terminadores.
3. Qualquer relacionamento existente entre terminadores no ser mostrado no DFD.
Alguns relacionamentos desse tipo podem existir de fato, mas, por definio, eles no
fazem par te do sistema que estamos estudando. Inversamente, se exis tirem
relacionamentos entre terminadores e for essencial que o analista de sistemas os modele
para documentar de forma
195
Lurreta os requisitos do sistema, ento, por definio, os tem nadores so realmente parte
do sistema e devem ser modelad como processos. Nos modelos simples examinados at
agot vimos apenas um ou dois terminadores. Em um sistema tpi do mundo real, pode
haver literalmente dzias de terminador diferentes interagindo com o sistema. A
identificao d terminadores e a interao deles com o sistema parte d processo de
construo do modelo amhicntal, que ser visto n captulo 17.
9.2 DIRETRIZES PARA A ELABORAO DE DFD
Na seo precedente vimos que os diagramas de fluxo de dado so compostos por quatro
componentes simples: processos (bolhas; fluxos, depsitos e terminadores. Munido
dessas ferramentas, voc agor:
pode comear a entrevistar usurios e a construir DFD de sistemas.
Entretanto, existem algumas diretrizes adicionais necessrias par:
utilizar DFD com sucesso. Algumas dessas diretrizes o auxiliaro a n construir DFD
incorretos (isto , incompletos ou logicamente inconsis tentes) e algumas outras
destinam-se a ajud lo a desenhar DFD agrad veis vista e portanto com mais
possibilidades de serem examinado com ateno pelo usurio.
As diretrizes so as seguintes:
1. Escolher nomes significativos para os processos,fluxos, depsi tos e terminadores.
2. Numerar os processos.
3. Refazer os DFD tantas vezes quantas forem necessrias at obte uma boa esttica.
4. Evitar DFD complexos demais.
5. Certificar-se de que o DFD seja internamente consistente aln de manter a consistncia
com os outros DFD.
9.2.1 Escolher Nomes Sign para os Processos, Fluxos, Depsitos e Terminadores
Como j vimos, um processo cm um DFD pode representar um:
fi no que esteja sendo executada ou pode indicar como a funo est
196
sendo executada, pela identificao da pessoa, grupo ou mecanismo envolvido. No ltimo
caso, torna-se evidente a importncia dc rotular acuradamente o processo para que as
pessoas que examinem o proces so, principalmente os usurios, sejam capazes de
confirmar de que aque le seja um modelo correto. Entretanto, se o processo for executado
por uma s pessoa, recomendvel identificar o papel que essa pessoa de sempenha, em
vez do nome ou da identidade da pessoa. Assim, em vez de desenhar um processo como o
da figura 9.14(a), com o nome Fred imortalizado, sugerimos que o processo seja
representado como na Fi gura 9.14(b). A razo para isso tripla:
1. Fred pode ser substitudo na prxima semana por Maria ou por Joo. Para que
introduzir obsolescncia no modelo?
2. Fred pode desempenhar diversas tarefas no sistema. Em lugar de desenhar trs bolhas,
todas com o rtulo Fred mas re presentando atividades diferentes, prefervel indicar a
verdadeira tarefa que ali executada - ou pelo menos o papel que Fred desempenha no
momento (como modelado em cada uma das bolhas).
3. A identificao de Fred provavelmente atrair ateno para o modo como ele executa
seu trabalho. Como veremos na parte III, devemos geralmente nos concentrar na
onentao comercial subjacente que deve ser seguida, sem referncias aos proce dimentos
(que podem ser baseados em costumes e antecedentes no mais relevantes) empregados
no cumprimento daquela orientao.
Se pudermos evitar o uso de nomes de pessoas (ou de grupos) e
de funes polticas, podemos rotular os processos de modo a identificar
pedidos
vlidos
pedidos
Figura 9.14 (a): Um nome de processo inadequado
197
as fi que o sistema executa. Um bom mtodo para nomes de pro cessos utilizar um
verbo e um objeto. Isto , empregar um verbo que represente ao (um verbo transitivo,
que exige um objeto) e um objeto adequado formando uma sentena descritiva do
processo. Eis alguns exemplos de nomes de processos:
CALCULAR TRAJETRIA 1)0 MSSIL
PRODUZIR RELATRIO DE INVENTRIO
VAliDAR NMERO DE TELEFONE
DESIGNAR ALUNOS PARA SALAS
Voc ver, ao seguir esta diretriz, que consderavelmente mais fcil empregar verbos e
objetos espccfficos se o prprio processo for simples e bem definido. Mesmo nos casos
simples, todavia, existe a tentao de usar nomes vagos como FAZER, MANIPULAR e
PROCESSAR. Quando so utilizados verbos desse tipo elstico (verbos cujo sentido
pode ser estendido para significar quase tudo), muitas vezes significa que o analista de
sistemas no est bem certo de qual funo est sendo executada ou que vrias funes
foram reunidas mas que no o deve riam ser. Eis alguns exemplos de maus nomes de
processos:
198
FAZER SERVIO
FUNES DIVF
MANIPULAR ENT1(AI)i
pedidos
pedidos
pedidos invlidos
Figura 9.14 (b): Um nome de processo mais adequado
1
CUIDAR DOS CLIENTES
PROCESSAR DADOS
EDIO GERAL
Os nomes escolhidos para os processos (e tambm para os fluxos e os terminadores)
devem provir de um vocabulrio conhecido pelo usu rio. Isso acontecer naturalmente
se o DFD for desenhado como resulta do de uma srie de entrevistas com o usurio e se o
analista de sistemas tiver um mnimo conhecimento do objeto subjacente da aplicao.
Porm duas precaues devem ser tomadas:
1. Existe a natural tendncia por parte dos usurio sem utiliza rem as abreviaes e
acrnimos que lhes sejam familiares; isso ocorre tanto para os processos quanto para os
fluxos que eles descrevem. Isso infelizmente resulta em um DFD fortemente orientado
para o modo como as coisas so feitas agora. Assim, o usurio poderia dizer: Bem, ns
pegamos uma cpia do formulrio 107 - o cor-de-rosa, voc sabe - e o enviamos para o
Jos para ser riscado. Uma boa maneira de evitar termos ex cessivamente
idiossincrsicos escolher verbos (como riscar) e objetos (como formulrio 107) que
sero compreensveis para algum da mesma indstria ou aplicao, mas trabalhando em
outra empresa ou organizao. Se voc estiver elaborando um sistema bancrio, os nomes
dos processos e dos fluxos de vem, idealmente, ser compreensveis para os que trabalham
em outros bancos.
2. Se o DFD estiver sendo desenhado por algum com retrospecto em programao,
haver tendncia de serem utilizados termos provenientes daquela atividade como
ROTINA, SUBSISTEMA e FUNO, embora tais termos possam no ter
significado no mundo do usurio. A menos que voc oua os usurios uti lizarem essas
palavras em conversas entre eles mesmos, evite-as nos DFD.
9.2.2 Numerar os Processos
Como um mtodo prtico de referenciar os processos de um DFD, a maioria dos analistas
de sistemas costuma numerar cada bolha. No importa a maneira de fazer isso - da
esquerda para a direita, de baixo para cima, ou de outra maneira qualquer - desde que
voc seja consis tente no modo como atribui os nmeros.
199
A nica coisa que voc dcve ter cm mente que o esquema numerao implicar, para os
eventuais leitores do seu DFD, uma det miixada sequncia de execuo. Isto , ao
apresentar o DFD a um us rio, ele poder indagar: Oh, quer dizer que a bolha 1
executa primeiro, depois a bolha 2 e depois a bolha 3?. Na verdade voc po obter a
mesma pergunta de outros analistas de sistemas e programac res; qualquer um que
conhea fluxogramas cometer o engano dc pres mir que os nmeros das bolhas
implicam uma sequncia.
Mas no assim, O DFD uma rede de processos assncronos qi
se intercomunicam, e , de fato, uma exata representao do modo c
mo realmente funciona a maioria dos sistemas. Uma certa seqncia p
de ser deduzida pela presena ou ausncia de dados (ex.: pode ser
svel que a bolha 2 no possa executar sua funo antes de receber d
dos da bolha 1), mas o esquema de numerao nada tem a ver com iss Sendo assim, ento
para que numerar as bolhas? Em parte, com
explicado acima, como um meio prtico de identificar os processos; muito mais fcil em
uma discusso sobre um DFD dizer-se bolha 1 ei vez de EDITAR ERROS DE
TRANSAES E DE RELATRIOS. Aind mais importante, os nmeros so a base
para o esquema de numer o hierrquica quando apresentarmos diagramas de fluxo de
dadc nivelados na seo 9.3.
9.2.3 Evitar DFD Complexos Demais
O propsito de um DFD modelar corretamente as funes qu um sistema deve executar
e as interaes entre elas. Porm um ouu objetivo do DFD ser lido e compreendido, no
somente pelo analisi de sistemas que elaborou o modelo, mas tambm pelos usurios que
s os conhecedores do assunto correlacionado. Isso significa que o DF deve ser
prontamente compreendido, facilmente absorvido e agradvi aos olhos.
Na prxima subseo discutiremos algumas diretrizes esttica mas h uma diretriz
principal que deve ser sempre lembrada: no cr um DFD com demasiados pmcessos,
fluxos, depsitos e terminaderes. maioria dos casos isso quer dizer que no se deve
incluir mais dc me dzia de processos e depsitos, fluxos e terminadores a eles relacion
dos em um nico diagrama Outra maneira de se dizer isso que DFD deve se acomodar
confortavelmente cm um folha padronizada c papel de 8,5 por 11 polegadas.
Existe uma importante exceo, como veremos no captulo 18; DFD especial, conhecido
como diagrama de contexto, que represeni todo o sistema como um nico processo e que
ressalta as intcrfaccs cmi o sistema e os terminadores externos. A figura 9.15 mostra um
diagra
200
de contexto tpico, e voc pode notar que ele capaz de assustar muitos analistas de
sistemas, quanto mais um usurio despreparado! Normal mente os diagramas de contexto
como o da figura 9.15 no podem ser simplificados, por representarem, mesmo no nvel
mais elevado de deta lhamento, uma realidade que intrinsecamente complexa.
Figura 9.15: Um diagrama de contexto tpico
9.2.4 Refazer o DFD Tantas Vezes Quantas Forem Necessrias
Em um projeto de anlise de sistemas do mundo real, o DFD que discutimos neste
captulo ter de ser feito, refeito e novamente refeito, por dez ou mais vezes, at que
esteja (1) tecnicamente correto, (2) acei tvel pelo usurio e (3) to bem desenhado que
voc no fique constran gido em mostr-lo junta de diretores de sua empresa. Isso pode
parecer muito trabalho, mas vale o esforo de desenvolver um modelo correto,
consistente e agradvel dos requisitos do sistema. Isso tambm vlido em qualquer
Outra atividade de engenharia: voc gostaria de viajar em um avio projetado por
engenheiros que ficassem entediados com seus desenhos aps a segunda iterao 12?
O que torna um diagrama de fluxo de dados esteticamente agrad vel? Isso logicamente
uma questp de gosto pessoal e de opinio, e pode ser determinado por padres
estabelecidos por sua empresa ou pelas caractersticas idiossincrsicas de algum pacote
automatizado de
201
diagramao em terminais de vdeo que voc esteja utilizando. Alm disso, a opinio do
usurio pode ser um tanto diferente da sua; dentro dos limites do que seja razovel, o que
quer que o usurio considere como esteticamente agradvel deve nortear a maneira como
voc deve desenhar os diagramas. Alguns dos problemas que costumeiramente surgem
para discusso nessa rea SO:
Tamanho e forma das bolhas. Algumas organizaes desenham diagramas de fluxo de
dados com retngulos ou ovais em vez de crculos; isso naturalmente uma questo de
esttica. Alm dis so, alguns usurios preocupam-se quando as bolhas do DFD no so
todas do mesmo tamanho - consideram que quando uma bolha maior que outra,
significa que aquela parte do sistema mais importante ou diferente de algum modo
(isso de fato acontece apenas porque o nome da bolha era to grande que o analista de
sistemas precisou desenhar um bolha maior para acomodar esse nome!).
Fluxos de dados curvos ve fluxos de dados retos. Para ilus trarmos esse aspecto,
considere os DFD das figuras 9.16(a) e (b).
Figura 9.16 (a): Uma verso de um DFD
202
Figura 9.16 (b): Uma verso dzferente do mesmo DFD
Qual deles mais agradvel esteticamente? Muitos observado res encolheriam os
ombros, dizendo, Eles na realidade so iguais. Mas, Outros - e essa a questo -
escolhero um e rejeitaro vivamente o outro. , evidentemente, uma boa idia, saber de
antemo qual a opo que ser aceita e qual ser rejei tada. O problema das setas que se
cruzam mais ou menos da mesma categoria: so ou no permitidas?
Diagramas desenhados mo ve diagramas gerados por mquina. Dentro de poucos anos,
virtualmente todos os dia gramas de fluxo de dados e os modelos de sistemas sero dese
nhados por sistemas de processamento grfico; hoje em dia, contudo, muitos desses
diagramas ainda so desenhados mo porque os analistas de sistemas no tm acesso a
essas ferra mentas. O problema, entretanto, a reao do usurio a esses diagramas:
alguns demonstram forte preferncia pelos diagra mas gerados em mquina por serem
mais limpos, enquanto Outros preferem as figuras desenhadas mo porque lhes do a
sensao de que os diagramas ainda no foram terminados ou congelados e ainda
podem sofrer modificaes.
203
9.2.5 Cerqflcar-se de que o DFD Seja Logicamente Consistente
Como veremos no captulo 14, existem algumas normas e diretrizes que auxiliam a
garantir que o diagrama de fluxo de dados seja consisten te com os outros modelos do
sistema - o diagrama de entidades-relacio namentos, o diagrama de transies de estado,
o dicionrio de dados e a especificao de processos. Entretanto, existem algumas
diretrizes que so utilizadas para fazer com que o prprio DFD seja consistente. As
principais diretrizes para a consistncia so estas:
Evite os poos sem fundo, bolhas que tm entradas mas no tm sadas. Tambm
conhecidas pelos analistas de sistemas como buracos negros, em analogia a estrelas
cujo campo gra vitacional to forte que nem mesmo a luz pode lhes escapar. Um
exemplo de poo sem fundo mostrado na figura 9.17.
Evite bolhas com gerao espontnea; bolhas que tm sadas mas no entradas so
suspeitas e geralmente incorretas. Um exemplo plausvel de bolha de sada-apenas um
gerador de nmeros aleatrios, mas difcil imaginar outro exemplo ra zovel. Uma
bolha tpica de sada-apenas mostrada na figura 9.18.
Cuidado com os fluxos e processos sem rtulo. Isso geralmente sinal dc desateno,
mas pode revelar erros mais Srios: s vezes o analista de sistemas omite o rtulo de um
fluxo ou de um processo porque simplesmente no conseguiu encontrar um nome
satisfatrio. No caso de um fluxo sem rtulo, isso pode significar que vrios itens
elementares de dados no relaciona dos foram arbitrariamente reunidos; no caso de um
processo no rotulado, isso pode indicar que o analista de sistemas estava to confuso que
desenhou um fluxograma disfarado em lugar de um diagrama de fluxo dc dados O
Cuidado com deps ilos de leitura -apenas ou escrita-apenas. Esta diretriz anloga
diretriz sobre processos de entrada- apenas ou de sada-apenas; um depsito tpico deve
ter entra das e sadas A nica exceo a esta diretriz o depsito exter no que serve como
interface entre o sistema e um terminador externo. A figura 9.19 mostra um exemplo de
um sistema de mercado de aes com um legtimo depsito de escrita-apenas
204
9.3 DFD COM NVEIS
At o presente momento, neste captulo, os nicos diagramas de fluxo de dados
completos que vimos so o sistema simples de trs bo lhas da figura 9.1 e o de uma s
bolha da figura 9.19. Mas os DFD que veremos em projetos reais so consideravclmcnte
maiores e mais com plexos. Considere, por exemplo, o DFD mostrado na figura 9.20. J
ima ginou mostr-lo a um usurio tpico?
Na seo 9.2.3 j foi sugerido que devemos evitar diagramas como o da figura 9.20. Mas
como? Se o sistema for intrinsecamente complexo e tem dzias ou mesmo centenas de
funes a serem modeladas, como podemos evitar o tipo dc DFI) da figura 9.20?
A resposta est em modelar o DFI) geral em uma srie de nveis de modo a que cada
nvel oferea succssivamcntc mais detalhes sobre uma parte do nvel que lhe seja
superior. Isso anlogo organizao dos mapas em um atlas, como discutido no
captulo 8: podemos examinar um mapa de viso geral de todo um pas, ou mesmo dc
todo o mundo;
a
x
Figura 9.17: Um exemplo de poo sem fundo
a
x
Figura 9.18: Um exemplo de bolha de sada-apenas
205
Dados do
relatrios anuais DADOS DO MERCADO
Figura 9.19: Um caso legtimo de depsito de escrita-apenas
Figura 9.20: Um DPI) complexo
206
os mapas subseqentes nos mostraro os detalhes de pases de modo individual, de
estados dentro de pases e assim por diante. No caso dos DFD, a organizao dos nveis
mostrada conceitualmente na figura
9.21.
O DFD dc nvel mais alto consiste de uma nica bolha, represen tando o sistema inteiro;
os fluxos de dados mostram as interfaces entre o
sistema e os terminadores externos (juntamente com quaisquer depsi tos externos que
possam estar presentes, como ilustrado pela figura
9.19). Esse DFD especial conhecido como dia,grama de contexto e
discutido no captulo 18.
O DFD imediatamente abaixo do diagrama de contexto conheci do como figura O. Ele
representa a viso de mais alto nvel das principais funes do sistema bem como as
principais interfaces entre essas fun es. Como vimos na seo 9.2.2, cada uma dessas
bolhas deve ser numerada para mais fcil identificao.
Os nmeros tambm servem como um meio prtico de se relacio nar uma bolha com o
DFD de nvel imediatamente inferior que descreve
essa bolha de modo mais completo. Por exemplo:
A bolha 2 da figura O est associada ao DFD de nvel inferior conhecido como figura 2.
As bolhas da figura 2 so numeradas
como 2.1, 2.2, 2.3 etc.
A bolha 3 da figura O est associada ao DFD de nvel inferior conhecido como figura 3.
As bolhas da figura 3 so numeradas
como 3.1, 3.2, 3.3 etc.
A bolha 2.2 da figura 2 est associada ao DFD de nvel inferior conhecido como figura
2.2. As bolhas da figura 2.2 so numera das como 2.2., 2.2.2, 2.2.3 etc.
Se uma bolha possuir um nome (e de fato deve possui-lo!), ento esse nome
transportado para a figura de nvel imedia tamente abaixo. Assim, se a bolha 2.2 tem o
nome de CALCU LAR TAXA DE VENDAS, ento a figura 2.2, que subdivide a bolha
2.2 mais detalhadamente, deve ser rotulada como figura
2.2: CALCULAR TAXA DE VENDAS.
Como se pode ver, esse um modo bastante direto de se organizar um potencialmente
enorme diagrama de fluxo de dados em um grupo de partes manipulveis. Mas existem
algumas coisas que devem ser acrescentadas a essa descrio da subdiviso em nveis:
207
DIAGRAMA DE CONTEXTO
FIGURA O
FIGURA 3
Figura 9.21: Diagramas defluxo de dados em nveis
208
1. Como saber quantos nveis deve ter um DFD? A resposta a esta pergunta foi sugerida
na seo 9.2.3: cada figura de DFD deve ter no mais de meia dzia de bolhas e de
depsitos a elas relacionados. Assim, se voc tiver subdividido um sistema grande em
trs nveis, mas os DFD de nvel mais baixo ainda contm 50 bolhas cada um, voc deve
estabelecer pelo menos mais um nvel abaixo desse. Um ponto de verificao alternativo
oferecido no captulo 11, onde discutimos as especificaes de processos para as bolhas
dos DFD do nvel mais baixo: se no pudermos escrever uma razovel especificao de
processo para uma bolha em uma s pgina, ento ela provavelmente est demasiado
complexa, e deve ser subdividida em um DFD de nvel mais baixo antes de tentarmos
escrever a especificao do processo.
2. Existem diretrizes sobre o nmero de nveis que devem ser es perados em um sistema
tpico? Em um sistema simples, encon tram-se provavelmente dois ou trs nveis; um
sistema de mdio porte apresenta costumeiramente de trs a seis nveis; e um sis tema
grande ter de cinco a oito nveis. Deve-se ter cautela com pessoas que afirmam que
qualquer sistema pode ser modelado em exatamente trs nveis - algum assim tambm
vai tentar vender-lhe a ponte Rio-Niteri. Por outro lado, lembre-se de que o nmero total
de bolhas cresce exponencialmente quando se passa de um nvel para o imediatamente
inferior. Se, por exemplo, cada figura tiver sete bolhas, ento haver 343 bolhas no
terceiro nvel, 16.807 bolhas no quinto nvel e 40.353.607 de bolhas no nono nvel.
3. Todas as partes do sistema devem ser subdivididas at o mesmo nvel de
detalhamento? Por exemplo, se a bolha 2 da figura O exigir mais trs nveis de
detalhamento, necessrio subdividir tambm a bolha 3 em mais trs nveis? Isto , uma
figura 3; um conjunto de figuras rotuladas figura 3.1, figura 3.2, ...; e um conjunto de
figuras rotuladas 3.1.1, 3.1.2, ..., 3.2.1, 3.2.2, e assim por diante? A resposta No.
Algumas partes de um sistema podem ser mais complexas que outras e podem exigir a
sub- diviso em mais um ou dois nveis. Por outro lado, se a bolha 2 da figura O do nvel
mais elevado for primitiva, enquanto a bolha 3 requer subdiviso cm sete nveis, ento o
modelo geral do sistema est assimtrico e foi provavelmente mal organizado. Nesse
caso, algumas partes da bolha 3 deveriam ser transferi das para uma bolha separada ou
talvez redesignadas para a bolha 2.
209
4 Como se mostram esses nveis para o usu Muitos usurios s desejaro ver um
diagrama. Um usurio executivo de alto nvel pode querer ver apenas o diagrama de
contexto ou talvez a figura O; um usurio de nvel operativo pode querer ver apenas a
figura que descreve a rea do sistema em que ele esteja interessado. Mas se algum quiser
ver uma grande parte do sistema ou talvez o sistema intciro, ento faz sentido apresentar-
lhe os diagramas na metodologia top-down: comeando pelo diagrama de contexto e
descendo aos nveis inferiores de maior detalhamento. Muitas vezes prtico ter-se dois
diagramas lado a lado na mesa (Ou exibidos por um projetor) para mostr-los: o diagrama
em que voc esteja parucularmente interessado em examinar e o diagrama de nvel
superior que oferece um contexto de alto nvel.
5. Como garantir que os nveis dos DFD sejam consistentes entre si? O aspecto da
consistncia reveste-se de tanta importncia porque os diversos nveis dos I)FD so
normalmente desenvolvidos por d pessoas nos projetos do mundo real. Um analista de
sistemas senhor pode se dedicar ao diagrama de contexto e figura O, enquanto alguns
analistas de sistemas juniors se encarregam das figuras 1, 2 etc. Para garantir que cada
figura seja consistente com sua figura de nvel supe rior, seguimos uma regra simples: os
fluxos de dados que en tram e saem de uma bolha em um nvel devem corresponder aos
fluxos que entram e saem de uma figura inteira do nvel Imediatamente inferior que
descreve aquela bolha. A figura 9.22(a) mostra um exemplo de um diagrama de fluxo de
dados equilibrado; a figura 9.22(b) mostra dois nveis de um DFD no- equilibrado.
6. Como mostrar depsitos nos dive nveis? Esta uma rea em que a redundncia
deliberadamente introduzida no modelo. A diretriz a seguinte: mostre um depsito no
nvel mais alto onde ele setve primeiramente como interface entre duas ou mais bolhas;
em seguida, mostre-o novamente em CADA diagrama de nvel inferior que descreva (ou
subdivida) as bolhas interfa ceadas. A figura 9.23 mostra um depsito compartilhado por
dois processos de alto nvel, A e B; o depsito seria novamente mostrado nas figuras de
nvel mais baixo, que ampliam a descrio de A e B. O corolrho disso que os depsitos
locais, utilizados apenas pelas bolhas de uma figura de nvel inferior, no sero mostrados
nos nveis superiores, porque estaro includos em um processo do nvel imediatamente
superior.
210
DIAGRAMA DE CONTEXTO
o
FIGURA 3
Figura 9.22 (a): Um fragmento de DFD equilibrado
211
DIAGRAMA DE CONTEXTO
o
FIGURA 3
Figura 9.22 (b): Um fragmento de DFD desequilibrado
212
7. Como realmente se faz a subdivso dos DFD em nveis? A dis cusso at agora
orientou mal de um modo um tanto sutil:
embora seja verdadeiro que os DFD devam ser apresentados aos usurios na modalidade
top-down, no necessariamente verdadeiro que o analista de sistemas deva desenvolver
os DFD segundo essa modalidade. A abordagem top-down intuitiva- mente muito
atraente. Pode-se imaginar comear pelo diagrama de contexto e depois desenvolver a
figura O e, em seguida, des cer metodicamente aos nveis inferiores de detalhamento.
Entretanto, veremos no captulo 17 que existem problemas nes sa abordagem; uma
abordagem mais bem-sucedida identificar primeiramente os eventos externos aos quais
o sistema deve reagir e usar esses eventos para criar um esboo de DFD. No captulo 20,
veremos que essa primeira verso do DFD pode ter de ser subdividida para cima (pra
criar DFD de nveis mais
Figura 9.23: A exibio de depsitos nos nveis inferiores
213
elevados) e para baixo (para criar DFD de nveis mais baixos). Por enquanto, suficiente
que voc compreenda apenas que a organizao e a apresentao de um conjunto de DFD
em vrios nveis no corresponde necessariamente estratgia de se desenvolver esses
nveis em primeiro lugar.
9.4 EXTENSES AO DFD PARA SISTEMAS DE TEMPO-REAL
Os fluxos discutidos neste captulo so [ de dados; eles atuam como dutos pelos quais
transitam pacotes de dados entre processos e depsitos. De forma semelhante, as bolhas
dos DFD vistos at o presente momento podem ser consideradas como processadores de
dados. Para uma grande classe de sistemas, particularmente os sistemas comerciais, esse
o nico tipo de fluxo necessrio para a modelagem de sistemas. Mas para outro tipo de
sistemas, os de tempo-real, precisamos de um meio de modelar fluxos de controle (ex.:
sinais ou interrupes) e de um modo de mostrar processos de controle - (bolhas cuja
nica tarefa coordenar e sincronizar as atividades de outras bolhas do DFD) Essas
bolhas se apresentam em linhas tracejadas no DFD, como se pode ver na figura 9.24.
Um fluxo de controle pode ser imaginado como um duto que pode transportar um sinal
binrio (isto , pode estar ligado ou desligado). Contrariamente aos outros [ discutidos
neste captulo, o [ de controle no transporta dados com valores. O fluxo de controle
envia do de um processo para outro (ou de algum terminador externo para um processo)
como uma forma de dizer: Acorde! Est na hora de traba lhar!. A implicao,
naturalmente, que o processo estava adormecido, ou inativo antes da chegada do fluxo
de controle.
Um processo de controle pode ser imaginado como uma bolha supervisora ou executiva
cuja tarefa coordenar as atividades das outras bolhas do diagrama; suas entradas e
sadas consistem apenas em fluxos de controle. Os fluxos de controle que partem do
processo de controle so utilizados para despertar outras bolhas; os que chegam
geralmente indicam que uma das bolhas terminou a execuo de alguma tarefa, ou que
alguma situao extraordinrir surgiu e sobre a qual a bolha de controle deve ser
informada. Norrialmente existe apenas um processo de controle em um DFD.
Como indicado acima, um fuxo de controle utilizado para des pertar um processo
normal; aps desperto, o processo normal executa sua tarefa, descrita por uma
especificao de processo (veja o captulo 11). O comportamento interno de um processo
de controle , portanto, diferente: onde o comportamento tempo-dependente do sistema

214
4
do satlite
PROCESSA
sinal do satlite DADOS DO
SATLITE
- _- ativar
processamento
CONTROLAR do satlite
DADOS DE VIGILNCIA
ativar
processamento
do radar
dados do radar
Figura 9.24: Um DFD com fluxos de controle e processos de controle
modelado em detalhe. O interior de um processo de controle modela do por um
diagrama de transies de estado, que mostra os vrios esta dos em que todo o sistema
pode estar e as circunstncias que conduzem a uma mudana de estado. Os diagramas de
transies de estado so discutidos no captulo 13.
9.5 RESUMO
Como vimos neste captulo, o diagrama de fluxo de dados uma ferramenta simples mas
poderosa para a modelagem das funes de um sistema. O material das sees 9.1, 9.2 e
9.3 deve ser suficiente pa ra modelar a maioria dos sistemas comerciais clssicos de
informaes. Se voc estiver trabalhando em um sistema de tempo-real (p.ex., con trole
de processos, orientao de msseis ou comutao telefnica), as extenses para tempo-
real discutidas na seo 9.4 sero importantes; para mais detalhes sobre problemas de
tempo-real, consulte [ e Melior, 19851.
Infelizmente, muitos analistas de sistemas pensam que os diagra mas de fluxo de dados
so tudo de que precisam saber sobre anlise de sistemas. Se voc perguntar a um de seus
colegas se ele est familiari zado com a anlise estruturada, ele provavelmente
responder: Oh, sim,
215
aprendi tudo sobre bolhas e o resto. Por Outro lado, isso um tributo ao poder dos
diagramas de fluxo de dados - ele muitas vezes a ni ca coisa de que um analista de
sistemas se recorda depois de ler um li vro ou fazer um curso sobre anlise estruturada!
No entanto, isso uma situao perigosa: sem as ferramentas de modelagem adicionais
apresentadas nos prximos captulos, os diagramas de fluxo de dados no tm valor.
Mesmo que os relacionamentos de dados e o compor tamento tempo-dependente do
sistema sejam triviais (o que pouco provvel), ainda necessrio combinar os DFD
com o dicionrio de dados (discutido no captulo 10) e a especificao de processos (dis
cutida no captulo 11).
Portanto, no guarde o livro ainda! Ainda h mais a aprender!
REFERNCIAS
1. Wayne Stevens, Glen Myers e Larry Constantine, Structured Design, IBM Systems
Journal, maio de 1974.
2. Ed Yourdon e Larry Constantine, Structured Deslgn. Nova lorque:
YOURDON Press, 1975.
3. Glen Myers, Reliable Software through Composite Design. Nova lorque:
Petroceili/Charter, 1975.
4. Tom DeMarco, Structured Analysis and Systems Spec Englewood Cliffs, N.J.:
Prentice-Hall, 1979.
5. Chris Gane e Trish Sarson, Struclured Systems Analys&s: Tools and Technques,
Englewood Cliffs, N.J.: Prentice-Hall, 1978.
6. Doug Ross e Ken Schoman, Jr., Structured analysis for Require ments Definition,
IEEE Transactions on Software Englneering, janeiro de 1977, pgs. 41-48. Reimpresso em
Ed Yourdon, Clas.scs in Software Engneering. Nova lorque: YOURDON Press, 1979.
7. Paul Ward e Steve Mellor, Structured Development of Real-Time Systems, Volumes 1-
3. Nova Jorque: YOURDON Press, 1986.
8. Edsger W. Dijkstra, Cooperating Sequential Processes. Program ming Languages, F.
Genuys (editor). Nova lorque: Academic Press,
1968.
9. Paul Ward, The Transformation Schema: An Extension of the Data flow Diagram to
Represent Control and Timing, IEEE Transactions
on Software Engineering fevereiro dc 1986, pgs. 198-210.
10. Derek Hatley, The Use ofStructured Methods in the Development of Large
Software-Based Avionics Systems, AIAA/IEEE 6th Digital
Avionics Conference, Baltimore, 1984.
11. M. Webb e Paul Ward, Executable Dataflow Diagrams: An Experi mental
Implementation, Structured Development Fonim, Seattle,
agosto de 1986.
216
12. E. Reilly e J. Brackett, An Experimental System for Executing Real Time Structured
Analysis Modeis, Pmceedings of lhe 121h Structu red Melhods Conference, Chicago,
agosto de 1987.
PERGUNTAS E EXERCCIOS
1. D uma breve descrio de um diagrama de fluxo de dados. Qual a diferena entre
um DFD e um fluxograma?
2. Apresente seis sinnimos para diagrama de fluxo de dados.
3. Em que os DFD podem ser usados alm da modelagem de siste mas de informaes?
4. Quais so os quatro principais componentes de um DFD?
5. Quais so os trs sinnimos comuns para processo em um DFD?
6. Existe alguma importncia na escolha de um crculo paia um pro cesso? Seria melhor
usar um tringulo ou um hexgono? Por qu?
7. O que est errado no processo abaixo?
8. O que est errado com o processo abaixo
IFX>3
GOTO
O UARK7
9. O que est errado com o processo abaixo?
217
10. O que est errado com o processo abaixo?
REGISTRO
DE CLIENTE
11. O que est errado com o processo abaixo?
12. Por que um analista de sistemas desenharia um DFD com un
processo composto do nome de uma pessoa ou de um grupo d
organizao?
13. Os fluxos de um DFD restringem-se a mostrar apenas o moviment
de informaes? Podem mostrar o movimento de outras coisas?
14. O que est errado neste DFD?
15. O que est errado neste DFD?
16. Como pode o mesmo conjunto de dados ter diferentes significado em um DFD?
Desenhe um exemplo de tal situao.
218
17. Qual o significado do DFD abaixo?
xi x
\S
18. Existe algum limite para o nmero dc entradas e sadas que um processo pode ter em
um DFD? Qual seria sua reao ao ver um
processo com 100 entradas e 100 sadas?
19. O que est errado no DFD abaixo?
20. O que est errado no DFD abaixo?
1
21. O que est errado nos DFD abaixo?
b
219
22. O que est errado no DFD abaixo?
a
c
b
23. O que est errado no DFD abaixo?
c
b
24. Descreva um fluxo de dilogo.
25. O DFD abaixo vlido? Existe alguma outra maneira c
desenh-lo?
Y
x
220
26. O DFD abaixo vlido? Existe alguma outra maneira de desenh-lo?
27. Sob que circunstncias voc poderia ver cpias duplicadas de um fluxo de sada de
um processo?
28. Por que os DFD evitam mostrar detalhes procedurais?
29. No diagrama abaixo, quantos elementos x e quantos elementos y so necessrios para
produzir uma sada z?
x
z
30. O que um depsito mostra em um DFD?
31. Qual a conveno para a atribuio dc nomes de depsitos em um DFD?
32. Quais so os nomes alternativos para um depsito? aceitvel o emprego do termo
arquivo? Por qu?
33. Que nomes so costumeiramente utilizados para descrever pacotes de informaes em
um depsito?
34. Quais so os trs motivos habituais para se mostrar depsitos de implementao em
um DFD?
35. Voc concorda com a exibio de depsitos de implementao em um DFD? Por qu?
36. Qual o significado de um fluxo sem rtulo entrando ou saindo de um depsito?
37. Existe algum limite para o nmem dc fluxos que chegam ou saem de um depsito? Se
assim for, determine esse limite.
221
38. O que est errado nos DFD abaixo?
(a)
b/
(c)
(d)
o
(e)
222
39. Quais so as quatro possveis interpretaes de um fluxo de dados que parte de um
depsito para um processo?
40. O DFD abaixo faz sentido? Por qu?
CLIENTES
registro de cliente
41. D um exemplo de uma situao onde um processo pode extrair partes de mais de um
registro de um depsito em um nico acesso
lgico.
42. D um exemplo de uma situao onde um processo pode extrair mais de um pacote
de informaes de um depsito em um nico
acesso lgico.
43. Examinando os diagramas a seguir voc pode dizer se os DFD esto corretos?
(a) _______________________
CLI ENTES
nmero-de-telefone
223
(b)
Cc)
CLIENTES
44. O que ocorre com um depsito depois que dados saem dele por um fluxo, para um
processo? Isso verdadeiro para todos os tipos
de sistemas ou apenas para sistemas de informaes?
45. Quais so as trs possveis interpretaes da chegada de um fluxo a um depsito?
46. Como podemos mostrar pacotes de dados sendo eliminados Cdeletados) de um
depsito?
47. O que est errado no DFD abaixo?
CLIENTES
dados-de-inventrio
trajetria-do-mssil
224
48. Qual o propsito de se mostrar um terminador em um DFD?
49. Como faz o analista de sistemas para identificar os terminadores?
50. Que representam os fluxos entre termiriadores e processos?
51. O que est errado nos DFD abaixo?
(a)
(b) ________
CLIENTE 1
SISTEMA
DE PEDIDOS
(c)
impostos
(d)
225
52. O analista de sistemas pode alterar o contedo ou a organizao de um terminador
como parte de seu projeto? E se ele achar que deve
ser modificado
53. Por que um processo no deve ter o nome da pessoa que pre sentemente desempenha
aquela funo?
54. Qual uma boa diretriz para atribuir nomes a processos em um
DFD?
55. D cinco exemplos de nomes de processos que voc no gostaria de ver em um DFD.
56. Como voc pode afirmar se o nome escolhido para um processo significativo?
57. Qual o erro de interpretao que o usurio pode cometer em relao aos nmeros
das bolhas de um DFD?
58. Como se pode saber se um DFD ser muito complexo para ser entendido pelo
usurio?
59. Quo rigidamente deve ser obedecida a diretriz da complexidade? Deve ser permitida
alguma exceo? Por qu?
60. Por que freqentemente necessrio redesenhar um DFD muitas vezes?
61. Quais so os principais aspectos que determinam se um DFD esteticamente
agradvel? Voc acha que esses aspectos podem ser
expressos como padres?
62. Seus colegas preferem representar os processos com bolhas ou com ovais? E voc,
como prefere?
63. Voc acha que os fluxos de dados entre processos devem ser de senhados como linhas
curvas ou como linhas retas? Quais so as
vantagens e desvantagens de cada tipo? Esse aspecto importante?
64. O que um poo sem fundo? Por que a presena dele deve ser considerada um erro
em um DFD tpico?
65. Que so bolhas de gerao espontnea em um DFD? Por que devem ser evitadas em
um DFD?
66. Por que os fluxos e processos sem rtulo so perigosos?
67. Por que os depsitos de leitura-apenas e de escrita-apenas con figuram-se
habitualmente como um erro em um DFD?
68. Por que os DFD em nveis so importantes no modelo de um sistema?
69. Quantos nveis de DFD um analista de sistemas deve esperar encontrar em um tpico
sistema de grande porte? Voc pode sugerir
um limite superior para o nmero de nveis em um DFD?
70. Em um DFD em nveis:
(a) O que podemos chamar de bolhas filhas abaixo da bolha 2.3?
(b) Qual seria o nome de figura da figura na qual aparece a bolha 2.3?
226
(c) Quantas figuras de nvel superior existem acima da figura na qual aparece a bolha
2.3? Como so chamadas?
71. necessrio que todas as partes de um sistema sejam subdivididas nos mesmos nveis
de detalhamento? Por qu?
72. Suponha que algum lhe mostre um DFD no qual a bolha 1 esteja subdividida em
dois nveis inferiores e a bolha 2 esteja subdividi da em 17 nveis inferiores. Qual seria
sua reao? Que reco mendaes, se houver alguma, voc faria?
73. Que significa equilbrio, no contexto deste captulo? Como se pode dizer se um DFD
est equilibrado?
74. Por que a figura 9.22(b) deste captulo est desbalanceada?
75. Qual a diretriz para a exibio de depsitos em diferentes nveis de um DFD?
76. O que um depsito local? Quais so as diretrizes para a exibio de um depsito
local em um DFD em nveis?
77. Projeto de Pesquisa: qual a relao entre a diretriz para a exibio de depsitos
locais e o conceito de projeto orientado para o objeto?
Para isto detalhes sobre isso, leia os captulos 19 e 20.
78. Que problemas podem estar associados ao desenvolvimento de um conjunto de DFD
em nveis na metodologia top-down (em comparao com a leitura de um conjunto j
desenvolvido de DFD pela metodologia top-down)?
79. O que um fluxo de controle? Por que diferente de um fluxo de dados?
80. O que um processo de controle? Por que diferente de um processo normal de um
DFD?
81. O que um depsito de controle? Por que diferente de um depsito normal de um
DFD?
82. Desenhe um diagrama de fluxo de dados para modelar a seguinte receita de Fruits de
Mer au Riz (Mexilhes com Arroz), tirada do Tbe New York Times 60-Minute Gourmet,
por Pierre Franey (Nova lorque: TIMES Books, 1979).
1. Para comear, prepare e mea todos os ingredientes para o arroz. Para
ganhar tempo, pique uma xcara extra de cebola e 2 dentes extras de
alho para a mistura. Deixe de lado.
2. Aquea 2 colheres de sopa de leo para o arroz em uma panela e acrescente 1/4 de
xcara de cebola, pimento e alho e aquea at ficar
cozido. Acrescente o aafro e cozinhe por mais 2 minutos.
3. Acrescente arroz, gua, sal e pimento e tampe. Aquea por cerca de 17 minutos ou at
que o arroz esteja cozido. Enquanto o arroz cozinha
prepare os frutos do mar. Lembre-se de que quando o arroz estiver
227
cozido, deve ser retirado do fogo. Ele pode ficar tampado por alguns minutos sem
problemas.
4. Aquea, em uma caarola, 1/4 de xcara de leo e acrescente uma xcara de cebolas e 2
dentes de alho. Mexa e aquea at ficar cozido. Acrescente pimento vermelho, tomates,
vinho e organo. Acrescente sal e pimenta. Tampe e cozinhe por 10 minutos.
5. Coloque os mariscos e mexilhes na panela e tampe de novo. Aquea por 3 minutos e
acrescente os camares, escalopes, sal e pimenta a seu
gosto. Tampe e aquea por 5 minutos.
83. Desenhe um diagrama de fluxo de dados para a seguinte receita de Coqulile St.
Jacques Meunlere (Escalopes Fritos na Manteiga), tirada do 7be New York Times 60-
Minute Gourinet, por Pierre Franey (Nova lorque: TIMES Books, 1979):
Um ponto a ser lembrado cem vezes a organizao. Antes de cozinhar, pique o que for
preciso picar e mea o que tiver de ser medido. Providencie as panelas e caarolas que
forem necessrias para o servio - neste caso, duas frigideiras (uma para os escalopes e
outra para os tomates) e uma caarola (para as batatas).
1. Coloque os escalopes em uma tigela e acrescente leite, mexendo at ficarem cobertos.
Deixe descansar por alguns instantes.
2. Ponha a farinha de trigo em um prato e acrescente sal e pimenta a seu gosto. Misture
bastante. Escorra os escalopes. Polvilhe-os com a farinha e coloque-os em uma peneira.
Agite para retirar o excesso de farinha. Espalhe-os em uma folha de papel laminado ou
encerado de modo a que no se toquem para que no grudem.
3. Os escalopes devem ser cozidos em fogo alto em pequenas quantidades. Aquea 3
colheres de sopa de leo e 1 de manteiga em uma frigideira grande. Quando a mistura
estiver bem quente, mas no fumegando, acrescente metade dos escalopes, mexendo-os e
agitando- os na frigideira de modo a que cozinhem rpida e uniformemente at
adquirirem um marrom dourado.
4. Use uma colher fendida para transferir os escalopes para uma travessa quente.
Acrescente as 2 colheres de sopa restantes de leo frigideira e quando estiver bastante
quente, coloque os escalopes restantes, mexendo-os e agitando-os na frigideira como
antes. Quando estiverem marrons, passe-os para a travessa com os outros escalopes.
Limpe a frigideira, acrescente a manteiga restante e aquea at ficar marrom claro ou
acastanhado. Salpique os escalopes com suco de limo e salsa picada.
228
84. Desenhe um diagrama de fluxo de dados para a seguinte receita de Omelefle Pavilion
(Omelete com frango, tomates e queijo), tirada do Tbe New York Times 60-Minute
Gourmet, por Pierre Franey (Nova Jorque: TIMES Books,1979):
Antes de comear a preparar os omeletes, quebre trs ovos para cada omelete em tantas
tigelas quantas forem necessrias para a quantidade de omeletes a serem preparados (uma
para cada um). Acrescente sal e pimenta a gosto e duas colheres de sopa de creme grosso.
Os ovos tambm podem ser batidos para acelerar o preparo dos omeletes.
1. Aquea 2 colheres de sopa de manteiga em uma caarola e junte farinha de trigo. Bata
com um batedor de ovos at que fique bem mis turado. Junte o caldo de frango e aquea,
batendo vigorosamente com o batedor. Coloque o creme e deixe ferver. Ferva por cerca
de 10 minutos.
2. Enquanto isso, aquea outra colher de sopa de manteiga em uma caarola e acrescente
cebola. Aquea, mexendo, at que esteja cozido, e junte tomates, tomilho, folhas de louro,
sal e pimenta. Ferva, mexendo vez por outra, por uns 10 minutos.
3. Aquea outra colher de manteiga e junte o frango. Deixe cozinhar, mexendo, por cerca
de 30 segundos. Junte 3 colheres de sopa de
molho cremoso. Deixe ferver e retire do fogo. Ponha de lado.
4. Junte as gemas dos ovos ao molho restante e mexa para misturar. Acrescente sal e
pimenta a gosto e queijo suo ralado. Aquea e mexa
at que o queijo derreta. Ponha de lado.
5. Bata os ovos com sal e pimenta. Junte 6 colheres de sopa de molho de tomate. Aquea
as 3 colheres restantes de manteiga em uma omeleteira ou em uma frigideira de Telon e
quando estiver bem quente, acrescente os ovos. Cozinhe, mexendo, at que o omelete
esteja consis tente em baixo mas mido e pastoso no meio. Ponha uma colher de frango
com creme no centro do omelete e um pouco do molho de tomate que sobrou. Passe o
omelete rapidamente para uma travessa.
6. Passe molho de tomate por sobre o omelete e salpique-o com queijo parmeso ralado.
Ponha para assar na grelha at ficar marrom-dourado.
NOTAS
Entretanto, a desvantagem do MacDraw (e de outros programas do
gnero) que ele nada sabe a respeito da especial natureza dos
diagramas de fluxo de dados ou dos outros modelos de sistemas
229
apresentados neste livro. Ele s conhece formas primitivas como
retngulos, crculos e linhas. Os produtos do estojo de ferramentas
do analista de sistemas, discutidos no apndice A,so muito mais
poderosos, porque sabem muito mais sobre o tema dos diagramas
de fluxo de dados.
2 O formato utilizado pelo analista de sistemas para os processos
muitas vezes associado a um determinado campo da anlise
estruturada. O crculo associado ao campo Yourdon/DeMarco,
por ser utilizado em vrios livros publicados pela YOURDON Press
e nas atividades de treinamento e consultoria da YOURDON Inc.
De maneira semelhante, o formato oval muitas vezes associado
ao campo Gane/Sarson, por ter sido apresentado por Chris Gane
e Trish Sarson em seu livro [ e Sarson, 1977], e foi usado pela
McDonnell Douglas Automation Company (McAuto) e vrias outras
empresas. O retngulo comumente associado ao campo SADT,
por ter sido popularizado em vrios artigos sobre a Softech
Structured Analysis Design Technique (SADT); veja, por exemplo,
[ e Schoman, 1977],
3 Uma alternativa aceitvel para o dilogo a utilizao de vrios
fluxos, um mostrando a entrada (consulta) para o processo e o ou
tro exibindo a sada (resposta). Essa , de fato, a melhor maneira
de manipular casos em que uma entrada pode levar a vrias aes
(e respostas) completamente diferentes por parte do processo. No
caso de uma situao simples de consulta-resposta, o uso de um
fluxo de dilogo ou de fluxos separados de entrada e sada uma
questo de escolha. A maioria dos analistas de sistemas prefere a
representao de dilogo porque (1) ela atrai a ateno para o fato
de que a entrada e a sada so relacionadas entre si e (2) ela reduz
o congestionamento do DFD com muitos fluxos e processos e pro
porciona ao leitor um diagrama mais limpo e mais simples.
4 O modo exato como essa multiplicao e/ou decomposio de
pacotes de dados ocorre considerado um problema de
implementao, isto , algo com que o projetista de sistemas ter
de se preocupar, mas no algo que o analista de sistemas precise
mostrar no modelo do sistema. Ele pode eventualmente ser
executado por hardware ou por software, ou manualmente, ou por
magia negra. Se o analista de sistemas estiver modelando um
sistema j existente, ele pode ser tentado a mostrar o mecanismo (o
processo) que se incumbe da multiplicao/de composio dos
dados. Discutiremos isso mais detalhadamente na parte III.
5 A notao Dl na figur 99(b) apenas um esquema de numerao
para que se possa distingir aquele depsito dos demais depsitos
do diagrama. A conveno seguida neste livro no envolve a ro
tulao e a numerao dos depusitos (por parecer desnecess rio e
230
intil), mas (como veremos na seo 9.2) envolve a numerao das bolhas.
6 Tambm comum algum se referir a um pacote de informaes do depsito como um
registro e aos componentes de cada pacote como campos. Nada h de errado com essa
terminologia, mas ela usada com tanta freqncia no contexto de banco de dados de
computadores que possivelmente criaria o mesmo tipo de pro blemas acima discutidos.
Doravante usaremos o termo pacote para descrever uma nica ocorrncia de uma coleo
de objetos relacionados no depsito.
7 Neste captulo mencionaremos vrias convenes como essa, bem como convenes
semelhantes relativas a outras ferramentas de modelagem. Seu gerente de projeto, o
manual de padres de sua empresa ou a ferramenta CASE que voc usa em seu projeto
(veja o apndice A) podem obrig-lo a utilizar uma determinada conveno; mas voc
pode perceber que existe uma certa flexibilidade quanto s ferramentas de modelagem e
notao de modelagem aqui apresentadas. O importante a consistncia:
todos os fluxos com pacotes entram ou saem dos depsitos quer estejam consistentemente
rotulados quer estejam consistentemente no-rotulados.
8 Como sabemos que os rtulos do fluxo tm algo a ver com os componentes de um
pacote de informaes do depsito? Como sa bemos, por exemplo, que um fluxo rotulado
NMERO-DE- TELEFONE tem algo a ver com os pacotes de informaes do depsito
CLIENTES? Existe a tentao, principalmente em projetos do mundo real onde todos
conhecem relativamente o assunto central, de dizer: Ora, isso intuitivamente bvio!
evidente que o telefone faz parte do pacote de cliente. Mas, para ter certeza, precisamos
ver uma rigorosa definio da composio de um pacote de CLIENTES, que encontrada
no dicionrio de dados, que discutiremos no captulo 10.
9 Se voc estiver utilizando um DFD para modelar algo alm de um sistema de puro
processamento de informaes, isso pode no ser verdadeiro. Por exemplo, o depsito
pode conter itens fsicos e o fluxo pode ser um mecanismo para transportar material de
depsito para o processo. Neste caso, um pacote seria removido fisicamente do depsito,
e o depsito sofreria uma reduo em seus itens como resultado. Em um modelo de
sistema contendo depsitos de informaes e depsitos fsicos, importante acrescentar
notas ao DFD (ou colocar uma explicao no dicionrio de dados) para que o leitor no
se confunda.
10 Essa diretriz provm de The Magical Number Seven, Plus or Minus
Two, de George MilIer, Psychology Review, 1956.
231
11 Na verdade, existem algumas coisas que podemos fazer: se houver
vrios fluxos de dados entre um terminador e a bolha nica do
sistema, podemos consolid-las em um nico fluxo de dados, O di
cionrio de dados, discutido no captulo 10, ser usado para
explicar a composio e o significado do fluxo agregado de dados.
Se o diagrama de contexto dever ser mostrado a diversos grupos
diferentes (p.ex., diferentes grupos de usurios com diferentes
interesses), podem ser desenhados diferentes diagramas de con
texto para realar apenas os terminadores e fluxos em que cada
grupo de usurios estiver interessado. Porm, na maioria dos casos,
no h como escapar disso: se o sistema como um todo for in
trinsecamente complexo, o diagrama de contexto tambm o ser.
O captulo 18 apresenta mais detalhes sobre esse aspecto.
12 A no ser que voc considere que os avies sejam diferentes dos
sistemas automatizados de informaces ou que eles sejam mais
crticos, lembre-se que os sistemas de processamento hoje con
trolam a maioria dos avies em que voc viaja; um grande avio
de passageiros de tipo comum pode ter uma dzia ou mais de
complexos sistemas de processamento, que, por sua vez, tm
interface com complexos sistemas de tempo-real como o que
utilizado pela Federal Aviation Administration para monitorar o
espao areo em torno dos aeroportos.
13 Existe uma conveno idiomtica que viola essa diretriz, que
discutida na seo 9.13: um fluxo sem rtulo entrando ou saindo
de um depsito , por conveno, uma indicao de que toda uma
instncia (ou um registro) est sendo introduzido ou retirado desse
depsito.
14 Por vezes pode no ser evidente de imediato se o depsito tem
tanto entradas como sadas. Como veremos na prxima seo, os
DFD so muitas vezes subdivididos em partes; desse modo,
emos nos deparar com uma parte do sistema que aparenta ter
depsitos de leitura-apenas (ou escrita apenas). Algum outro
trecho do sistema, documentado em um DFD separado, pode ter a
atividade de escrita-apenas (ou leitura-apenas) que falta. So
necessrias muitas tediosas verificaes de consistncia para
assegurar que uma parte do sistema l o arquivo e que alguma
outra escreva nele; este um aspecto em que os pacotes automati
zados de anlise de sistemas discutidos no apndice A so extre
mamente valiosos.
15 Tambm muito atraente para os gerentes de projetos. O geren
te de um grande projeto disse sua equipe: 1 want aH of you
to bubble on down to the next levei of detail by the end of this
week!
232
16 Em alguns casos, pode mesmo ser apropriada a incluso de depsitos de controle ou
depsitos de eventos, que so anlogos ao conceito de semforos, apresentados
primeiramente por Dijkstra em [ 1968]. Para detalhes complementares, veja [ e Melior,
19851.
233
lo
O DICIONRIO DE DADOS
Os dicionrios so como relgios; o pior melhor do que nenhum, e no
se pode esperar que o melhor seja totalmente fieL
Mrs. Priozzi, Anecdotes ofSamuelJohnson, 1786
Neste captulo, aprenderemos:
1. Porque precisamos de um dicionrio de dados em um projeto de desenvolvimento de
sistemas.
2. A notao para definies de dicionrios de dados.
3. Como um dicionrio de dados deve ser apresentado ao usurio.
4. Como implementar um dicionrio de dados.
A segunda ferramenta importante de modelagem que estudaremos o dicionrio de
dados. Embora ele no tenha o fascnio e o encanto grfico dos diagramas de fluxo de
dados, dos diagramas de entidade reladonamentos e dos diagramas de transies de
estado, o dicionrio de dados fundamental. Sem ele, seu modelo de requisitos do
usurio no pode ser considerado completo; ser apenas um esboo grosseiro, uma
representao artstica do sistema.
A importncia do dicionrio de dados muitas vezes desprezada por muitos adultos, que
ficam sem us-lo de 10 a 20 anos. Experimente recordar os dias da escola elementar,
quando voc era constantemente assediado por novas palavras em seu trabalho escolar.
Recorde, tambm, os cursos de lnguas estrangeiras, especialmente aquelas que exigiam
235
que voc lesse livros e revistas. Sem um dicionrio, voc estaria perdido. O mesmo pode
ser dito em relao ao dicionrio de dados em anlise de sistemas: sem ele, voc estar
perdido, e o usurio no ter certeza de voc haver entendido os detalhes da aplicao.
A expresso dicionrio de dados quase auto-explicativa. O di cionrio de dados uma
listagem organizada de todos os elementos de dados pertinentes ao sistema, com
definies precisas e rigorosas para que o usurio e o analista de sistemas possam
conhecer todas as entra das, sadas, componentes de depsitos e clculos intermedirios,
O di cionrio de dados define os elementos de dados da seguinte maneira:
Descrevendo o significado dos fluxos e depsitos mostrados nos diagramas de fluxo de
dados.
Descrevendo a composio de pacotes agregados de dados que se movimentam pelos
fluxos, isto , pacotes complexos (como o endereo de um cliente) que podem ser
divididos em itens mais elementares (como cidade, estado e cdigo postal).
Descrevendo a composio dos pacotes de dados nos depsitos.
Especificando os relevantes valores e unidades de partes ele mentares de informaes
dos fluxos de dados e depsito de
dados.
Descrevendo os detalhes dos relacionamentos entre os depsi tos realados em um
diagrama entidades-relacionamentos. Esse aspecto do dicionrio de dados ser estudado
em mais detalhes no captulo 12 aps termos apresentado a notao de entidades-
relacionamentos.
10.1 A NECESSIDADE DA NOTAO DE DICIONRIO DE DADOS
Na maioria dos sistemas do mundo real em que vamos trabalhar os pacotes ou elementos
de dados sero suficientemente complexos para que voc precise descrev-los em termos
de outras coisas. Os elementos de dados complexos so definidos em termos de
elementos de dados mais simples, e elementos de dados simples so definidos em termos
das unidades vlidas e dos valores que eles podem assumir.
Pense, por exemplo, na maneira como voc responderia seguinte
pergunta de um marciano (que como muitos usurios vem os ana listas de sistemas!)
sobre o significado do nome de uma pessoa:
236
Marciano: Ento, o que um nome?
Voc (demonstrando impacincia): Bem, voc sabe, somente
um nome. Quero dizer, como, bem, como ns chamamos um ao
outro.
Marciano (perplexo): Quer dizer que voc os chama de maneira
diferente quando est zangado e quando est feliz?
Voc (levemente espantado com a ignorncia desse estranho):
No, certamente que no. Um nome sempre o mesmo. O nome de
uma pessoa o que ns usamos para distingui-la de outras pessoas.
Marciano (entendendo subitamente): Ahh, agora eu entendi.
Ns fazemos a mesma coisa no meu planeta. Meu nome
3.141592653589793238462643.
Voc (incrdulo): Mas isso um nmero e no um nome.
Marciano: E um nome muito bom, tambm. Eu Sinto orgulho dele. Ningum possui
um nome assim.
Voc: Mas e o seu primeiro nome? Ou o seu primeiro nome 3, e o ltimo nome
1415926535?
Marciano: O que quer dizer com primeiro e ltimo nome? No entendi. Eu tenho
somente um nome, e sempre o mesmo.
Voc: Bem, no assim que fazemos aqui. Ns temos um primei ro nome, e um ltimo
nome, e s vezes temos um nome intermedirio
tambm.
Marciano: Isso quer dizer que voc pode ser chamado de 23
45 99?
Voc: No, ns no permitimos nmeros em nossos nomes. S utilizamos os caracteres
alfabticos de A a Z.
Como se pode imaginar, a conversa poderia continuar por um longo tempo. Voc poderia
pensar que o exemplo foi inventado, porque raramente encontramos marcianos que no
tm noo do significado de um nome. Mas isso no est muito distante das discusses
que ocorrem (ou deveriam ocorrer) entre um analista de sistemas e um usurio, nas quais
as seguintes perguntas poderiam ser feitas:
237
Todos devem ter um primeiro nome? E o personagem Mr. T conhecida srie de TV,
The A Team?
E os caracteres de pontuao no ltimo nome de urna pes como, por exemplo,
DArcy?
Os nomes centrais podem ser abreviados, como, por exemj John X James?
Existe a exigncia de um comprimento mnimo para o nome uma pessoa? Por exemplo,
o nome X Y vlido? (Podc imaginar que isto poderia causar grandes problemas nos
temas de processamento atravs do pas, mas, existe algu razo legal/comercial para que
uma pessoa no possa ter o meiro nome X e o ltimo nome Y?).
Como devemos lidar com os sufixos que, algumas vezes, acc panhani o ltimo nome?
Por exemplo, o nome John Jones, , presumivelmente, legtimo, mas o Jr. deve ser
considen parte do ltimo nome ou uma nova categoria especial? E se uma nova categoria,
devemos permitir tambm dgitos num cos como Sam Smith 3rd?
Observe, a propsito, que nenhuma dessas perguntas tem alg ver com a maneira como
eventualmente armazenamos as informai no computador; estamos tentando apenas
determinar, como um assu de interesse da orientao comercial, o que constitui um nome
vlidi
Como se pode imaginar, um tanto tedioso descrever a comj sio de elementos de dados
em forma de narrativa. Precisamos de u notao concisa e compacta, como um dicionrio
padronizado Webst que tem uma notao compacta e concisa para definir o significado
palavras comuns.
10.2 NOTAO DE DICIONRIO DE DADOS
Existem muitos esquemas de notao comuns usadas pelos a
listas de sistemas. O que est mostrado a seguir est entre os mais
muns, e usa alguns simbolos simples:
= composto de
+e
() opcional (pode estar presente ou ausente)
{} iterao
238
E1 escolha uma das opes alternativas
comentrio
@ identificador (campo chave) de um depsito
1 separa opes alternativas na construo E]
Para exemplificar, podemos definir nome para nosso amigo mar- ciano da seguinte
maneira:
nome - ttulo-cortesia + primeiro-nome + (nome
Intermedirio) + ltimo-nome
ttulo-cortesia - [ 1 Srta. 1 Sra. Sras. 1 Dr. 1 Professor]
primeiro-nome - (caracter-vlido)
nome-intermedirio - (caracter-vlido)
ltimo-nome - (caracter-vlido)
caracter-vlido - [ II
Como se pode ver, os sImbolos parecem bastante matemticos; voc talvez receie que
isso seja demasiadamente complicado para se compreender. Como logo veremos, a
notao muito fcil de ler. A experincia de alguns milhares de projetos de PD e
algumas dezenas de milhares de usurios nos mostraram que a notao tambm
compreen svel para quase todos os usurios se apresentada apropriadamente,
estudaremos isso na seo 10.3.
10.2.1 Definies
Uma definio de elemento de dados apresentada com o smbolo
; neste contexto, o = lido como definido como, ou compos to de, ou
simplesmente significa. Ento, a notao
A-B+C
poderia ser lida de qualquer das maneiras seguintes:
Sempre que dissermos A, queremos dizer B e C
A compe-se de E e C
A definido como B e C
239
Para definir completamente um elemento de dados, nossa defini o incluir o seguinte:
O significado do elemento de dados no contexto desta aplica o do usurio. Isso
normalmente apresentado como um co mentrio, usando-se a notao
A composio do elemento de dados, se ele for composto por componentes elementares
significativos.
Os valores que o elemento de dados poder assumir, se ele for um elemento de dados
elementar que no possa ser decom posto.
Deste modo, se estivssemos construindo um sistema mdico que
controlasse pacientes poderamos definir os termos peso e altura da
seguinte maneira:
peso = peso do paciente ao chegar ao hospital *
* unidades: quilogramas; intervalo: 1-200
altura = altura do paciente ao chegar ao hospital
unidades: centmetros; intervalo: 20-200 *
Observe que descrevemos as unidades e os Inteivalos relevantes com caracteres cor
Novamente, essa uma conveno de notao considerada prtica por muitas
organizaes, mas que pode r ser alterada se necessrio.
Alm das unidades e do intervalo, voc tambm pode precisar es pecificar a exatido ou a
preciso com que o elemento de dados me dido. Para um elemento de dados como
preo, por exemplo, impor tante indicar se os valores sero expressos na forma inteira,
at o ltimo centavo etc. E, em muitas aplicaes de engenharia e cientficas,
importante indicar o nmero de dgitos significativos no valor dos ele mentos de dados.
10.2.2 Elementos de dados elementares
Elementos de dados elementares so aqueles para os quais no existe decomposio
significativa no contexto no ambiente do usurio. Isto , muitas vezes, uma questo de
interpretao e que deve ser explo rada cuidadosamente com o usurio. Por exemplo,
vimos na discusso acima que o termo nome poderia ser decomposto em ltimo-nome,
240
primeiro-nome, nome-Intermedirio e ttulo-cortesia Mas, talvez, em alguns ambientes
nenhuma dessas decomposies seja necessria, relevante ou mesmo significativa (isto ,
onde os termos ltimo-nome etc, no tm significado para o usurio).
Quando os itens de dados elementares tiverem sido identificados, devem ser introduzidos
no dicionrio de dados. Como indicado acima, o dicionrio de dados deve apresentar um
ligeiro comentrio narrativo, entre os caracteres , descrevendo o significado do termo
no contexto do usurio. Certamente, podero existir alguns termos que sejam auto-
explicativos, isto , termos cujos significados so universalmente os mesmos em todos os
sistemas de informaes, ou que o analista de sistemas pode concluir que no
necessria nenhuma outra elaborao. Por exemplo, os seguintes termos podem ser
considerados como auto- explicativos em um sistema que mantenha informaes sobre
pessoas:
altura-atual
peso-atual
data-de-nascimento
sexo
telefone-residencial
Nesses casos, nenhum comentrio narrativo necessrio; muitos analistas de sistemas
utilizam a notao para indicar um coment rio nulo quando o elemento de dados
auto-explicativo. Entretanto, importante especificar os valores e unidades de medida
que o item de dados elementares pode receber. Por exemplo:
altura-atual -
0
unidades: libras; intervalo: 1-400 *
peso-atual -
unidades: polegadas; intervalo: 1-96
data-de-nascimento -
unidades: dias desde 1, jan, 1900;
intervalo: 0-36500
sexo - valores: lM FI
241
10.2.3 Elementos de dados opcionais
Um elemento de dados opcional, como o nome diz, o que pode estar ou no presente
como um componente dc um elemento de dados composto. Existem muitos exemplos de
elementos de dados opcionais em sistemas de informaes:
Um nome de cliente poder ou no incluir um nome interme dirio.
Um endereo de cliente poder ou no incluir alguma infor mao secundria como o
nmero do apartamento.
Um pedido de um cliente poder conler um endereo de co brana, um endereo para
remessas ou possivelmente ambos.
Situaes como esta ltima devem ser cuidadosamente conferidas
com o usurio e devem ser cuidadosamente documentadas no dicionrio
de dados. Por exemplo, a notao
endereo-cliente = (endereo-de-remessa) + (endereo-de cobrana)
significa, literalmente, que o endereo do cliente poderia constituir-
se de:
apenas do endereo de remessas
ou
apenas do endereo de cobrana
ou
o endereo de remessas e o endereo de cobrana
ou
nem do endereo de remessa nem do endereo de cobrana
A ltima possibilidade um tanto duvidosa. bem mais provvel que o usurio
realmente pretenda que o endereo de cliente deva con sistir em um endereo de remessas
ou em um endereo de cobrana ou em ambos. Isto poderia ser expresso da seguinte
maneira:
242
endereo-de-cliente - [ 1 endereo-de cobrana 1 endereo-de-embarque+
endereo-de-cobrana]
Algum tambm poderia objetar que em uma atividade de pedidos pelo correio, sempre
necessrio o endereo de remessa para onde deve ser enviado o pedido do cliente; um
endereo de cobrana separado (p.ex., departamento de contabilidade do cliente)
opcional. Assim sendo, possvel que a poltica verdadeira da empresa do usurio ficaria
mais bem expressa por:
endereo-do-diente - endereo-de-remessa + (endereo-de cobrana)
Porm, certamente, o nico meio de ter certeza disso chamar o
usurio e explicar-lhe, cuidadosamente, as implicaes das diferentes
notaes mostradas acima 2
10.2.4 Iterao
A notao de iterao usada para indicar a ocorrncia repetida de
um componente de um elemento de dados. Ela lida como zero ou
mais ocorrncias de. Deste modo, a notao
pedido - nome-do-cliente + endereo-de-remessa + fitem)
significa que um pedido deve conter sempre o nome do cliente e o en dereo de
embarque, e conter, tambm, zero ou mais ocorrncias de um item. Dessa maneira,
poderemos lidar com um cliente que apresente um pedido envolvendo apenas um item ou
dois itens, ou algum em fria compradora que decide pedir 397 itens diferentes .
Em muitas situaes do mundo real, o usurio desejar especificar os limites superior e
inferior da iterao. No exemplo acima, o usurio provavelmente afirmar que no faz
sentido que um cliente apresente um pedido com zero itens; deve haver pelo menos um
item no pedido. E o usurio pode desejar especificar um limite superior; talvez 10 itens
seja o mximo que ser permitido. Podemos indicar limites superiores e inferiores da
seguinte maneira:
pedido - nome-de-cliente + endereo-de-remessa + 1{ltem} 10
Pode-se especificar apenas um limite inferior, ou apenas um limite
superior, ou ambos ou nenhum. Deste modo, todas as especificaes a
seguir so vlidas:
243
a 1{b}
a - (b}1O
a = 1(b}1O
a = {b}
10.2.5 Seleo
A notao de seleo indica que o elemento de dados consiste er exatamente uma escolha
de um conjunto de opes alternativas. A opes so delimitadas por colchetes E e 1
e separadas pelo caracter de barra vertical 1. Exemplos tpicos S
sexo [ 1 Feminino]
tipo de cliente = [ 1 Indstria 1 Universidade 1 Outro]
importante rever as opes de seleo com o usurio para garan tir que todas as
possibilidades foram identificadas. No ltimo exemplo, usurio podia tender a concentrar
sua ateno nos clientes do governo da indstria e de universidades e podiam
precisar ser lembrados d que alguns clientes se enquadram na categoria de nenhuma das
categc rias acima.
10.2.6 Sinnimus
Um sinnimo (um alias), como o termo indica, um nome altei nativo para um
elemento de dados. uma ocorrncia comum quando s lida com grupo diversificado de
usurios, muitas vezes em departamer tos diferentes ou localizaes geograficamente
diferentes (e algumas ve zes com diferentes nacionalidades e lnguas), que insistem em
utiliza nomes diferentes para indicar a mesma coisa. O sinnimo includo n dicionrio
de dados por uma questo de completude, e deve ter uma rc ferncia cruzada com o nome
principal ou oficial do dado. Por exemplc
cliente = sinnimo de cliente
Observe que a definio de cliente no mostra a composio (i5
to , no mostra que um cliente consiste em nome, endereo, telefon
244
1
etc.). Tcdos esses detalhes devem ser fornecidos somente no nome principal para
diminuir a redundancia no modelo .
Mesmo que o dicionrio de dados relacione corretamente os sin nimos aos nomes de
dados, deve-se evitar o uso de sinnimos sempre que possvel. Isso porque os nomes de
dados so comumente vistos primeiro, e so mais visveis por todos os usurios, nos
diagramas de fluxo de dados, onde possa no ser evidente que fregus e cliente sejam
sinnimos. muito melhor, se for possvel, conseguir que os usurios concordem com
um nome comum
10.3 APRESENTAO DO DICIONRIO DE DADOS AO USURIO
O dicionrio de dados criado pelo analista de sistemas durante o desenvolvimento do
modelo do sistema, mas o usurio deve ser capaz de ler e compreender o dicionrio de
dados para conferir o modelo. Isso d origem a algumas perguntas bvias:
Os usurios so capazes de compreender a notao do di cionrio de dados?
Como os usurios verificam se o dicionrio est completo e correto?
Como criado o dicionrio?
A questo da aceitao pelo usurio da notao do dicionrio uma tentativa para se
desviar do assunto em muitos casos. Sim, a nota o do dicionrio parece um tanto
matemtica; mas, como j vimos, o nmero de simbolos que o usurio tem que aprender
pequeno. Os usurios esto habituados a diversas notaes formais no trabalho e na
vida pessoal; considere, por exemplo, a notao de pauta musical, que muito mais
complexa.
:
Piar 1 ao!!
Ji
H
-
HHHL
,
Figura 10.1: A notao da pauta musical
245
--
1
4

1
.:..
I
1
k
::::
.:.. .
:...:
A
A
A
1
A
A
a

.n
-
The PIQyer
00:00.47
4. b 1-e3
5.-
The Chessmas ter 00:00: 13
4. 8-b4
Figura 10.2: Notao de xadrez
Similarmente, a notao para bridge, xadrez e para diversas outras
atividades , pelo menos, to complexa quanto a notao de dicionrio
de dados mostrada neste captulo.
A questo da verificao do dicionrio de dados pelo usurio cos tumeiramente leva
pergunta: os usurios devem ler o dicionrio intei ro, item por item, para se certificarem
de que esteja correto? difcil imaginar que algum usurio queira fazer isso! mais
provvel que o usurio verifique a exatido do dicionrio de dados em combinao com o
diagrama defluxo de dados, com o diagrama de entidades-relaciona mentos, com o
diagrama de transies de estado ou com as espec es de processos que esteja lendo.
Existem alguns problemas de correo que o analista de sistemas pode executar
pessoalmente, serr a assistncia do usurio: ele pode assegurar que o dicionrio esteja
:ompleto, consistente e sem contradi es. Desse modo, ele pode exan mar o dicionrio e
formular as seguin tes perguntas:
Todos os fluxos no diagrama de fluxo de dados foram definidos no dicionrio de dados?
246
Todos os componentes dos elementos de dados compostos foram definidos?
Algum elemento de dados foi definido mais de uma vez?
A notao correta foi utilizada em todas as definies do di cionrio de dados?
Existe algum elemento de dados no dicionrio de dados que no esteja referenciado nos
diagramas de fluxo de dados, nos diagramas de entidades-relacionamentos ou nos
diagramas de transies de estado?
10.4 A IMPLEMENTAO DO DICIONRIO DE DADOS
Em um sistema de mdio ou grande porte, o dicionrio de dados pode representar um
volume muito grande de trabalho. No incomum vermos um dicionrio de dados com
milhares de entradas, e mesmo um sistema relativamente simples poder ter vrias
centenas de entradas. Deste modo, alguma ateno deve ser dada maneira com que o
dicio nrio estar sendo desenvolvido, ou a tarefa provavelmente sobrecarre gar o
analista de sistemas.
A abordagem mais fcil fazer uso de um recurso automatizado (computadorizado) para
introduzir as definies do dicionrio, verific las relativamente complementao e
consistncia, e produzir informa es adequadas. Se a sua organizao estiver usando
algum qualquer sistema moderno de gerenciamento de banco de dados (p.ex., IMS,
ADABAS, TOTAL, IDMS), um recurso de dicionrio j est disponvel. Nesse caso,
voc pode tirar proveito dessa vantagem e utiliz-la para construir o seu dicionrio de
dados. Entretanto, cuidado com as seguin tes possveis limitaes:
Voc poder ser forado a limitar os nomes em um certo com primento (p.ex., 15 ou 32
caracteres). Isso, provavelmente, no ser um grande problema, mas pode acontecer de o
seu usurio in com um nome como destino-da-remessa-do-cliente e que o seu pacote de
dicionrio de dados o obrigue a abreviar o nome para dest-rem-dli.
Outras limitaes artificiais podem ser colocadas no nome. Por exemplo, o caractere
hfen - pode no ser permitido, e voc
talvez seja forado a utilizar no lugar dele o sublinhado _. Ou
247
voc pode ser forado a prefixar (ou sufixar) todos os nomes com um cdigo do projeto
indicando o nome do projeto de desenvolvimento dos sistemas, con duzindo a nomes
como
acct.pay.GHZ.345P14.fornecedor_telefone_nmero.
Voc pode ser forado a designar atributos fiscos (p.ex., o n mero de bytes ou blocos
de memria em disco, ou certas repre sentaes de dados como decimais compactados)
para um item de dados, mesmo que no seja uma exigncia do usurio, O dicionrio de
dados estudado neste captulo deve ser um di cionrio de anltses e no deve cxig
decises desnecessrias ou irrelevantes de implementao.
Alguns analistas de sistemas tambm esto comeando a usar pa cotes automatizados de
ferramentas que incluem recursos grficos para diagramas de fluxo de dados, e
congneres, bem corno aptides de di cionrio de dados. Novamente, se tal recurso
existir, voc deve us-lo. As ferramentas automatizadas sero discutidas em maiores
detalhes no apndice A.
Se voc no dispuser de nenhum recurso automatizado para construir o dicionrio de
dados, voc deve pelo menos ser capaz de utilizar um sistema convencional de
processamento de palavras para construir um arquivo de texto com as definies do
dicionrio de dados. Ou, se voc tiver acesso a um computador pessoal, poder usar qual
quer programa de gerenciamento de arquivos e de gerenciamento de banco de dados
(p.ex., dBASE-!!!, Rbase-5000, PFS-File, Microsoft File no Apple Macintosh) para
construir e gerenciar o seu dicionrio de dados.
Somente nos casos mais extremos voc deve recorrer a dicionrios de dados manuais, isto
, 3 a 5 cartes indexados para cada entrada do dicionrio. Esse recurso foi muitas vezes
necessrio nos anos 70 e mes mo nos 80. A despeito da popularidade dos computadores
pessoais e dos recursos de processamento de palavras, desanimador ver que muitas
organizaes mantiveram seus programadores e analistas de siste mas na Idade Mdia. Os
filhos do sapateiro, como se diz, so habitual mente os ltimos a ganharem sapatos. Mas
isso hoje imperdovel; se voc estiver trabalhando em um projeto onde no tenha
acesso a um pacote de dicionrio de dados ou a uma ferramenta automatizada de anlise
ou a um computador pessoal ou a um sistema de proces samento de palavras, ento, voc
deve (1) desistir e encontrar um tra balho melhor, ou (2) obter seu prprio computador, ou
(3) as duas coisas simultaneamente.
248
10.5 RESUMO
A construo de um dicionrio de dados um dos aspectos mais tediosos e consumidores
de tempo da anlise de sistemas. Mas tambm um dos aspectos mais importantes: sem
um dicionrio formal que defina o significado de todos os termos, no haver esperanas
de preciso.
No prximo captulo veremos como usar o dicionrio de dados e o
diagrama de fluxo de dados para construir especificaes de processos
para cada um dos processos de baixo nvel.
REFERENCIAS
1. J.D. Lomax, Data Dictiona?y Systems. Rocheile Park, N.J.: NCC Publications, 1977.
2. Tom DeMarco, Structured Analysis and Systems Speclflcatlon. Nova lorque:
YOURDON Press, 1979.
3. D. Kroenke, Database Processing. Chicago: Science Research Asso ciates, 1977.
4. Shaku Atre, Data Base: Structured Technlques for Deslgn, Perfor mance, and
Management. Nova lorque: Wiley, 1980.
PERGUNTAS E EXERCCIOS
1. Defina dicionrio de dados.
2. Por que importante um dicionrio de dados em anlise de sistemas?
3. Quais as informaes que um dicionrio de dados fornece sobre um elemento de
dados?
4. Qual o significado da notao = em um dicionrio de dados?
5. Qual o significado da notao + em um dicionrio de dados?
6. Qual o significado da notao O em um dicionrio de dados?
7. Qual o significado da notao { } em um dicionrio de dados?
8. Qual o significado da notao liii em um dicionrio de dados?
9. Voc acha que os usurios com os quais trabalha podem enten der a notao padro de
dicionrio de dados apresentada neste ca ptulo? Em caso negativo, pode sugerir uma
alternativa?
10. D um exemplo de um item de dados elementar.
11. D trs exemplos de elementos de dados opcionais.
12. Quais so os possveis significados das expresses abaixo?
(a) endereo = (cidade) + (estado)
(b) endereo end-rua + cidade + (estado) + (cdigo postal)
249
13. D um exemplo do uso da notao { 1 de iterao.
14. Qual o significado de cada uma das notaes abaixo?
(a) a = 1{b}
(b) a = {b}1O
(c) a 1{b}10
(d) a = 10{b}10
15. Faz sentido ter um pedido definido desta forma?
pedido = nome-do-cliente + endereo-de-remessas + 6{Item}
Por qu?
16. D um exemplo da construo ( de seleo.
17. Qual o significado de um sinnimo (alias) em um dicionrio de dados?
18. Por que a utilizao de sinnimos deve ser minimizada sempre que for possvel?
19. Que espcie de anotao pode ser usada em um DFD para indicar que o elemento de
dados um sinnimo?
20. Quais os trs principais problemas que o usurio encontra ao exa minar um dicionrio
de dados?
21. Na sua opinio os usurios na sua organizao sero capazes de compreender a
notao de dicionrio de dados?
22. Na sua opinio a notao de dicionrio de dados mostrada neste captulo mais
complexa ou menos complexa do que a notao
musical?
23. Quais so as trs atividades de verificao de erros que o ana lista de sistemas pode
executar no dicionrio de dados sem o
usurio?
24. Quais so as possveis limitaes de um pacote de dicionrio de dados automatizado?
25. D uma definio de dicionrio de dados para nome-de-cliente baseada na seguinte
especificao verbal de um usurio: Quando nos lembramos do nome de um cliente,
temos o cuidado de incluir um ttulo de cortesia que pode ser Sr., Srta., Sra., Srs.,
ou Dr. (Existem muitos outros ttulos como Professor, Sir etc., porm no nos
ocuparemos deles). Cada um dos nossos clientes tem um primeiro nome, mas ns
permitimos uma nica inicial se eles preferirem. Nomes intermedirios so opcionais. E,
natu ralmente, o ltimo nome obrigatrio; permitimos muitos tipos de ltimos nomes,
incluindo nomes com hifens (Smith-Frisby, por exemplo) e apstrofos (DArcy) e
assim por diante. Permitimos
250
ainda um sufixo opcional para nomes como Tom Smith, Jr. ou Harvey Shmrdlu 3rd.
26. O que est errado nas definies de dicionrio de dados abaixo?
(a) a b c d
(b) a = b + + c
(c) a=lb
(d) a = 4{b}3
(e) a = {x)
(E) x = ((y))
(g) a = 4{
27. No exemplo de hospital da seo 9.2, quais so as implicaes da definio de altura
e peso? Comentrio: ela indicaria que somente medimos em unidades integrais e no
controlamos os centmetros, e assim por diante.
28. Escreva uma definio de dicionrio de dados das informaes contidas na sua
carteira de motorista. Se voc no a possuir, en contre um amigo que possua uma.
29. Escreva uma definio de dicionrio de dados das informaes contidas no carto de
crdito de um banco adequado (p.ex.,
Mastercard ou Visa).
30. Escreva uma definio de dicionrio de dados das informaes contidas em um
passaporte.
31. Escreva uma definio de dicionrio de dados das informaes contidas em um carto
de loteria.
NOTAS
Por outro lado, provvel que a poltica de negcios atualmente em vigor seja fortemente
influenciada pelos sistemas de processa mento que a organizao vem utilizando nos
ltimos 30 anos. H cinqenta anos, uma pessoa poderia ser considerada excntrica se
decidisse se chamar Fre5d Smi7th mas isso provavelmente seria aceito por muitas
organizaes, porque os nomes eram transcritos para pedaos de papel por mos
humanas. Os primeiros sistemas de processamento (e a maioria deles, atualmente) tm
um pouco mais de dificuldades com nomes fora do comum.
2 Existe uma possibilidade que poderia explicar a ausncia do en dereo de remessas e do
endereo de cobrana em um pedido do cliente: o cliente eventual que deseja comprar um
item e lev-lo consigo. provvel que quisssemos identificar explicitamente esse cliente
(definindo um novo elemento de dados denominado
251
eventual que pode ter valor verdadeiro ou falso) porque (1) clien tes eventuais podem
precisar ser tratados de modo diferente (por exemplo, seus pedidos no tero quaisquer
cobranas de embar que), e (2) um bom meio de efetuar a dupla verificao e garan tir
que a falta do endereo-de-embarque ou do endereo-de- cobrana constitui um erro.
3 Lembre-se uma vez mais que estamos definindo o significado tcnico intrnseco de um
elemento de dados, sem considerar a tecnologia que ser usada para implement-lo.
provvel, por exemplo, que nossos projetistas de sistemas venham solicitar um limite
superior razovel para o nmero de itens que podem estar contidos em um pedido. Para
fazer com que as coisas funcionem eficientemente com nosso sistema de gerenciamento
de banco de dados SUPERWHIZ, teremos que restringir o nmero de itens em 64.
improvvel que qualquer pessoa deseje pedir mais do que 64 itens diferentes, e se isso
acontecer, basta apresentar mais de um pedido. E o usurio pode ter suas prprias
limitaes, funda mentadas nos formulrios em papel ou nos relatrios impressos com
que ele lida; isso faz parte do modelo de implementao do usu rio, que discutiremos no
captulo 21.
4 Voc pode ignorar esta advertncia se estiver usando um pacote automatizado de
dicionrio de dados que possa gerenciar e con trolar a redundncia, embora isso seja
bastante incomum, O ponto principal a ser lembrado que se modificarmos a definio
de um elemento primrio de dados (p. ex., se decidirmos que a definio de um cliente
no mais deve incluir o nmero do telefone) a modificao tambm deve aplicar-se a
todos os sinnimos.
5 Uma alternativa anotar o fluxo no da de fluxo de dados para indicar que ele um
sinnimo de alguma coisa; um asterisco, por exemplo, pode ser acrescentado no final dos
nomes sinni mos. Por exemplo, a notao fregus poderia ser utilizada para indicar que
fregus um sinnimo de algum outro nome. Mas isto tambm no muito prtico.
252
11
ESPECIFICAES
DE PROCESSOS
Nossos pequenos sistemas tm seu dia.
Alfred, Lord Tennyson
In Memoriam, 1850
Neste captulo, aprenderemos:
1. Como escrever especificaes de processos em lin guagem estruturada.
2. Como escrever especificaes de processos com condies pr/ps
3. Como utilizar tabelas de deciso para escrever espe cificaes de processos.
4. Quando utilizar ferramentas alternativas de especifi cao.
Neste capitulo vamos explorar a espec de processos, a descrio do que ocorre dentro de
cada bolha primitiva, do nvel mais baixo, em um diagrama de fluxo de dados. Vrios
livros, inclusive [ 1978], [ e Sarson, 19771 e [ 1978] tambm usam o termo minispec
(abreviao de miniature specification) como alterna tiva para especificao de
processos. Qualquer que seja seu nome, ,o propsito de uma especificao de processos
totalmente direto: ela define o que deve ser feito para transformar entradas em sadas. Ela
uma detalhada descrio da orientao empresarial do usurio execu tada pelas bolhas.
Como veremos neste captulo, existem diversas ferramentas que
podemos utilizar para produzir uma especificao de processos: tabelas
2
de deciso, linguagem estruturada, condies pr/ps, fluxogramas, diagramas de Nassi-
Shneiderman, e outras. Embora a maioria dos ana listas de sistemas prefiram a linguagem
estruturada, no devemos esquecer que podemos usar qualquer mtodo, desde que ele
satisfaa dois essenciais requisitos:
A espec de processos deve ser expressa de uma forma que possa ser verificada pelo
usurio epelo analista de sistemas. precisamente por essa razo que evitamos a
linguagem comum como ferramenta de especificao: ela notoriamente ambgua,
principalmente para descrever aes (decises) alter nativas e repetitivas (laos). Por sua
natureza, ela tambm tende a causar grande confuso ao expressar condies booleanas
compostas (isto , combinaes dos operadores booleanos
AND, OR e NOT).
A especificao de processos deve ser expressa de uma forma que possa ser
efetivamente comunicada s diversas audincias
envolvidas. Embora costumeiramente seja o analista de sistemas quem redige a
especificao de processos, normalmente h uma diversificada audincia de usurios,
gerentes, auditores, contro ladores de qualidade e outros, que iro ler a especificao. A
especificao de processos talvez possa ser expressa em clculo de predicados, ou em
Pascal ou em uma abordagem de dia gramao formal como o USE-IT da Higher Order
Software, porm se a comunidade usuria recusar-se a ler tais especifi caes, elas sero
inteis, O mesmo pode ser dito a respeito de tabelas de deciso, linguagem estruturada ou
sobre outras fer ramentas de especificao; trata-se mais de uma funo da per
sonalidade, retrospecto e da atitude dos usurios com os quais
lidamos.
Como j dissemos, a maioria dos analistas de sistemas usa a lingua gem estruturada como
mtodo preferido para redigir especificaes de processos. Talvez seja mais importante
dizer que a maioria dos analistas de sistemas e das empresas usa uma ferramenta para
elaborar todas as especificaes Isso, na minha opinio, um grande erro: deve-se ter a
liberdade de se empregar uma combinao de ferramentas de especifi cao, dependendo
de (a) a preferncia do usurio, (b) suas prprias preferncias e (c) a natureza dos
diversos projetos.
A boa ferramenta de especificao de processos deve possuir uma terceira caracterstica
tambm: no deve impor (ou implicar) deci ses arbitrrias de projeto e de
implementao. Isso muitas vezes dif cil, porque o usurio, de quem dependemos para
estabelecer a poltica
254
LI
seguida em cada bolha no DFD, est disposto a descrever a orientao em termos de
como ela executada hoje. tarefa sua, como analista de sistemas, destilar dessa
apresentao a essncia do que seja a orientao e no como ela executada atualmente.
Considere o seguinte exemplo: o analista de sistemas est discutin do um pequeno
fragmento de um sistema, mostrado na figura 11.1. Ele quer desenvolver uma
especificao para a bolha rotulada como CAL CUlAR FATOR IIIP0T11C0. Como o
analista de sistemas no est fa miliarizado com a aplicao, ele entrevistou o usurio e
aprendeu que a doutrina para calcular fatores hipotticos para qualquer valor do elemen
to de dados de entrada, x, a seguinte:
1. O fator hipottico no produzido como resultado de um clcu lo simples. Na
realidade, temos de comear por uma suposio. O usurio nos disse que gosta muito do
14 como suposio inicial.
2. Em seguida, fazemos outra suposio. Dividimos o nmero x, com que comeamos,
pela suposio corrente.
3. Tomamos o resultado desse clculo e o subtraimos da suposio corrente.
4. Tomamos o resultado do item 3 e o dividimos por dois. Essa a nossa nova suposio.
5. Se a nova suposio e a suposio corrente esto muito prxi mas uma da outra,
digamos, dentro dc 0,0001, podemos parar; a
x
FATOR HIPO(X)
Figura 11.1: Clculo do fator hipottico
255
nova suposio o fator hipottico. Caso contrrio, voltamos ao item 2 e fazemos tudo
novamente.
Voc poderia argumentar que essa especificao de processo dificil de ser lida e
compreendida porque est escrita em linguagem nar rativa. De fato, a descrio a seguir
muito mais compacta (observe que as barras verticais 1 na clusula UNTIL significam
valor absoluto da expresso entre elas):
fator-hipo = 14
REPITA para N = O em saltos de 1
fator = (fator - (X/fator-hipoN))/
AT 1 fator - fator-hipoN 1 <0.0001
Entretanto, isso tambm tem um defeito: descreve a norma da empresa em termos de uma
determinada implementao procedural. A norma, como pode ter ficado evidente (mas
que tambm pode no ter ficado evidente), o algoritmo de Newton-Raphson de
aproximao da raiz quadrada . A especificao de processo abaixo descreve a mesma
norma, porm d ao projetista/programador completa liberdade na esco lha de seu prprio
algoritmo:
PR-CONDIO
Existe um nmero X, no negativo.
PS-CONDIO
Um fator-hipo produzido de modo que
X = fator-hlpo * fator-hipo
O programador pode at escolher o algoritmo do usurio para calcular a raiz quadrada,
mas ele no ficar restrito a utiliz-lo pelo analista de sistemas. Na verdade, a
extraordinria ateno dada ao algo- ritmo procedural, principalmente na primeira verso
da especificao acima, no permitiu que se percebesse de que processo se tratava!
Antes de explorarmos as diversas ferramentas de especificao de processos, devemos
enfatizar um ponto: as especificaes de processos s so desenvolvidas para os
processos do nvel mais baixo dos diagra mas de fluxo de dados em nveis. Como
podemos ver na figura 11.2, todos os processos de um determinado nvel so definidos
pela rede de processos do nvel inferior seguinte. Em outras palavras, a espe cificao de
processos para uma bolha de um nvel o DFD do nvel
256
No h especificaes de
processos para estas bolhas
Estas bolhas tm especificaes de processos, presumindo-se
que sejam bolhas do nvel mais baixo
FIGURA 3
Figura 11.2: Fspec de processos de bolhas do nvel mais baixo
257
imediatamente inferior. Escrever uma especificao adicional de processos em linguagem
estruturada seria no somente suprfluo mas tambm redundante; isto , criaria uma
especificao que seria mais difcil de ser mantida atualizada
Vamos nos concentrar nas trs principais ferramentas de especifica o de processos neste
captulo:
Linguagem estruturada
Condies pr/ps
Tabelas de deciso
Faremos tambm alguns rpidos comentrios sobre outras ferra mentas de especificao
menos utilizadas: linguagem narrativa, fluxogra mas e diagramas de Nassi-Shneiderman.
11.1 LINGUAGEM ESTRUTURADA
Linguagem estruturada, como o nome diz, linguagem com es trutura. Isto , um
subconjunto da linguagem normal com algumas restries quanto ao tipo de sentenas
que podem ser utilizadas e maneira como essas sentenas podem ser reunidas. Ela
tambm co nhecida por outros nomes, como LPP (Linguagem de Projeto de Programas)
e LEP (Linguagem de Especificao de Problema). Seu propsito obter um razovel
equilbrio entre a preciso de uma linguagem de programao formal e a casual
informalidade e legi bilidade da lngua que utilizamos normalmente.
Uma sentena em linguagem estruturada pode consistir em uma
equao algbrica, por exemplo,
X=(YZ)/(Q14)
ou em uma simples sentena imperativa composta por um verbo e um objeto. Observe
que essa sentena no tem o ponto-e-vrgula que ter mina uma sentena de programao
em muitas linguagens de progra mao; ela pode ou no terminar por um ponto (.),
dependendo de sua preferncia quanto a esse tipo de coisa. Observe tambm que sen
tenas que descrevem clculos podem ser prefixadas com os verbos COMPUTE, ADD,
SET, e outros; assim, o exemplo acima poderia ser escrito como
COMPUTE X=(YZ)/(Q+ 14)
258
e tambm podemos escrever clculos em linguagem estruturada como as seguintes:
SET TAXA TO 13
ADD 3 TO X
MULTIPLY PRECO-UNIT BY QUANT
DIVIDE ATIVO-CORRENTE BY PASSIVO-CORRENTE.
Os verbos devem ser escolhidos a partir de um pequeno conjunto
de verbos de ao como:
GET (ou ACCEPT ou READ)
PUT (ou DISPLAY ou WRITE)
FIND (ou SEARCH ou LOCATE)
ADD
SUBTRACT
MULTIPLY
DIVIDE
COMPUTE
DELETE
FIND
VALI DATE
MOVE
REPLACE
SET
SORT
A maioria das organizaes considera que 40 a 50 verbos so sufi cientes para descrever
qualquer poltica em qualquer especificao de
processos.
Os objetos (o tema de sentenas imperativas simples) devem ser compostos apenas por
elementos de dados que tenham sido definidos no dicionrio de dados ou em termos
locais. Termos locais so palavras explicitamente definidas na especificao de um
processo individual. Elas s so conhecidas, relevantes e significativas nessa
especificao de processo. Um exemplo tpico de termo local um clculo intermedirio,
utilizado para produzir a sada final do processo . Por exemplo, a es pecificao de
processo em linguagem estruturada abaixo examina uma srie de registros de pedidos no
depsito PEDIDOS para calcular um total dirio.
total-dirio - O
DO WHILE existirem mais podido. em PEDIDOS como data fatura - data-hoje
READ prximo podido em PEDIDOS como data-fatura =
data-hoje
259
DISPLAY em Contab nun noi total geral
total-dirio - total-dirio + total-geral
ENDDO
DISPLAY em Contab total-dirio
A linguagem estruturada permite ainda a combinao de senten as em algumas formas
limitadas; as que se seguem so baseadas nas co nhecidas construes da programao
estruturada 6
A construo ff-THEN-ELSE utilizada para descrever sen tenas alternativas que
devem ser executadas de acordo com o resultado de uma deciso binria. Essa construo
pode tomar uma das duas seguintes formas:
1W condio-1
senena-1
2IDIF
ou
1W condio-1
sentena-1
sentena-2
E
Desse modo, o analista de sistemas poderia escrever:
1W cliente vive em Nova lorque
add cliente a PPOSPECZOS
2
ou
1W idade-cliente maior que 65
set categ-cobrana em categ-senior
set categ-cobrana em categ-normal
2
A construo CASE utilizada para descrever sentenas alterna tivas a serem
executadas com base no resultado de uma deciso multivalorada (diferente da deciso
binria que ocorre com a construo IF-TIIEN). A construo CASE assume a forma
geral:
DO CriSE
260
CASE varivel - valor-1 sentena-1
CASE varivel - valor-n
seniena-n
OT1
sentena -n+1
SE
Dessa maneira, o analista de sistemas poderia escrever:
DO CASE
CASE idad.-c] < 13
set catQg-cobzana em cat.g-irifant
CASE idada-clionte > 12 e idade-cliente < 20
set categ-cobrana em categ-a
CASE idade-cliente > 19 e idade-cliente < 65
set categ-cobrana em categ-adulto
OTHERWI SE
set categ-cobrana em categ-senior
END CASE
Ou, como outro exemplo, considere o seguinte trecho de uma
especificao de processo em linguagem estruturada:
DO CASE
CASE estado
set taxa-vendas em 0.0825
CASE estado - set taxa-vendas em 0.07
CASE estado CA
set taxa-vendas em 0.05
set taxa-vendas em O
END CASE
Observe que a clusula OTHERWISE muitas vezes utilizada para resolver situaes em
que o usurio esquece de especificar e que o analista de sistemas esquece de perguntar a
respeito; ela vai muitas vezes induzir algumas discusses entre o usurio e o analista de
sistemas que de outro modo no ocorreriam at que o sistema estivesse em operao.
Considere o seguinte exemplo:
261
DO CASE
CASE tipo-pag dinh
set taxa-d.ac em 0.05
CASE tipo-pag = cart-cred
set taxa-dGac em 0.01
O1
set taxa-d em O
2 CASE
O usurio poderia questionar essa especificao de processo e perguntar porque o analista
de sistemas incluiu a clusula OTHERWISE; o analista de sistemas poderia responder per
guntando sobre pagamentos em cheque, em cheque de viagem, em moedas de ouro e por
permuta.
A construo DO-WH1LE usada para descrever uma sentena que deve ser executada
repetidamente at que uma determinada condio booleana seja verdadeira. Sua forma
geral :
DO WHILE condio-1
sentena-1
DO
O teste (condio-1 no exemplo acima) feito antes da execuo da sentena-1; assim
sendo, se a condio no for satisfeita, possvel que sentena-1 seja executada zero
vezes.
Por exemplo, o analista de sistemas poderia escrever:
DO WHILE enquanto houver mais itens no pedido do
cliente
preo = preo_unit*quant_item
DO
Muitas organizaes utilizam uma outra estrutura que executa uma especificada sentena
ao menos uma vez antes de testar se ela deve ser repetida. Essa variao, conhecida
habitualmente como REPEAT-UNTIL, tem a seguinte forma:
sentena-1
UNTIL condio-1
Pode-se construir sentenas compostas a partir de combinaes de sentenas simples L
das estruturas simples acima apre sentadas, de acordo com as s regras:
262
1. Uma seqncia linear de sentenas simples equivalente (estru turalmente) a uma
sentena simples. Portanto, a seqncia
sentena-!
sentena-2
sentena-n
estruturalmente equivalente a uma nica sentena simples e pode ser utilizada onde
quer que seja esperada uma sentena simples. Isso nos permite construir estruturas como
esta:
IF condio-!
sentena-!
sentena-2
sentena-3
sentena-4
sentena-5
2
ou
DO WRILE condio-! sentena-1
sentena-2
sentena-3
wO
2. Uma construo IF-THEN-ELSE simples considerada estrutu ralmente equivalente a
uma nica sentena simples. Isso permite que as estruturas IF-THEN-ELSE sejam
aninhadas dentro de outras estruturas IF-THEN-ELSE, ou dentro de estruturas DO-
WHILE ou dentro de estruturas CASE. Por exemplo,
IF condio-!
sentena-!
IF condio-2
sentena-2
sentena-3
sentena-4
sentena-5
2
263
senrena-6
sentena- 7
IF condio-3
sentena-8
IT
sentena-9
3. Uma estrutura DO-WHILE simples considerada estru turalmente equivalente a uma
nica sentena simples. Isso permite que as estruturas DO-WHILE sejam aninhadas
dentro de outras estruturas DO-WHILE, ou dentro de estruturas if THEN-ELSE ou
dentro de estruturas CASE. Dessa forma, podemos ter a seguinte especificao em
linguagem estruturada:
total-geral O
DO WHILE houver pedidos a serem processados
total-faturas - O
READ prximo pedido em PEDIDOS
DO WIIILE houver itens no pedido
total-faturas - total-faturas +
valor-item
DISPLAY ru total-faturas total-geral - total-geral + total-faturas
ENDDO
DISPLAY total-geral
4. Uma estrutura CASE simples considerada estruturalmente equivalente a uma nica
sentena simples. Isso permite que estruturas CASE sejam aninhadas dentro de outras
estruturas CASE, ou dentro de estruturas IF-THEN-ELSE ou dentro de estruturas DO-
WHLLE.
Como se pode ver, isso nos possibilita construir descries arbitra riamente complexas da
poltica da empresa, mantendo-se estrito controle sobre o vocabulrio, a organizao e a
estrutura da descrio. Entretanto, essa complexidade arbitrria tambm a maior
desvantagem da lingua gem estruturada: se o analista de sistemas compuser uma
especificao de processos que seja demasiadamente complexa para o usurio enten der e
verificar, ele ter fracassado. Isso pode normalmente ser evitado pela adoo das trs
seguintes diretrizes:
264
1. Restrinja a especificao de processos em linguagem estrutura da a uma nica pgina
de texto (ex.: uma folha de 8 X 11, com 66 linhas de texto em um editor de texto). Se a
especificao exigir mais de uma pgina, ento o analista de sistemas (com auxlio do
usurio) deve recorrer a um modo inteiramente diferente de formular a poltica (p.ex.:
utilizar um diferente algoritmo simples). Se isso no puder ser feito, possvel que o
prprio processo (isto , a bolha no DFD) seja complexo demais e deva ser subdividido
em uma rede de processos mais simples, de nvel mais baixo.
2. No use mais de trs nveis dc aninhamento (isto , trs nveis de estruturas !F-THEN-
ELSE aninhadas ou trs nveis de estru turas CASE aninhadas etc.). Principalmente no
caso de es truturas IF-THEN-ELSE, mais do que dois nveis de ani nhamento j
representam um forte indcio de que seria pre fervel a especificao de uma tabela de
decises; isso ser discutido na seo 11.3.
3. Evite confuses sobre nveis de aninhamento utilizando a en dentao, como mostrado
nos exemplos acima. Isso pode ser feito e controlado com muita facilidade se voc
utilizar algum tipo de auxlio automatizado para desenvolver as especificaes de
processos (mesmo algo simples como um sistema comum de processamento de palavras).
Se as especificaes de processos forem digitadas manualmente por um funcionrio no
versado em programao estruturada ou anlise estruturada, ser necessrio explicar-lhe
minuciosamente o tipo de endentao desejado; tambm ser necessrio verificar
cuidadosamente a correo do texto resultante.
Muitos analistas de sistemas perguntam se devem esperar que o usurio leia e
compreenda uma especificao de processos redigida em linguagem estruturada. Minha
experincia tem sido uniformemente posi tiva nesse aspecto: os usurios podem ler a
linguagem estruturada, com as seguintes condies:
1. Examine todo o documento uma ou duas vezes para se asse gurar de que eles entendem
o formato e as diversas constru es. Na primeira leitura, ele pode muito bem parecer um
documento legal, especialmente se voc tiver ressaltado a construo IF-THEN-ELSE e
outras coisas do gnero.
265
2. No se refira especificao de processos como lingua gem estruturada. Se
necessrio, refira-se a ela como uma descrio formal da poltica da empresa para a
execuo dessa atividade.
3. D especial ateno ao formato geral e diagramao (layout) do documento; a
endentao de blocos aninhados par ticularmente importante. Alguns usurios preferem
o tipo numerado de endentao, no qual os nveis recebem nmeros como 1.1, 1.1.1,
1.1.1.1, e assim por diante.
O estudo de caso do apndice F mostra alguns exemplos de espe cificao de processos
em linguagem estruturada.
11.2 CONDIES PR/PS
As condies pr/ps so um modo prtico de descrevermos a funo que deve ser
executada por um processo, sem que seja necess rio nos estendermos muito sobre o
algoritmo ou sobre o procedimento que ser empregado. Essa abordagem
particularmente til quando:
(1) O usurio tende a expressar a poltica executada por uma bolha em termos de um
algoritmo especial e particularizado
que ele ou ela tenham estado utilizando por muito tempo.
(2) O analista de sistemas est razoavelmente seguro de que exis tem muitos algoritmos
que podem ser usados.
(3) O analista de sistemas quer deixar que o programador explo re alguns desses
algoritmos, mas no deseja se envolver pes soalmente nesses detalhes, e princi no quer
se en gajar em discusses com o usurio sobre os mritos relativos desses algoritmos.
Um exemplo de especificao de processo escrita com a condio
pr/ps mostrada na figura 11.3:
ESPECIFICAO DE PROCESSO 3.5: CALCULAR IMPOSTO
SOBRE VENDAS
Pr-condio 1
DADOS-DE-VENDA ocorre com TIPO-DE-ITEM que
266
coincide com CATEGORIA-DE-ITEM em CATEGORIAS- DE-IMPOSTOS
Ps-condio 1
TAXA-VENDAS ajustado em TOTAL-VENDAS *
VALOR-TAXA
Pr-condio 2
DADOS-DE-VENDA ocorre com TIPO-DE-ITEM que no coincide com CATEGORIA-
DE-ITEM em CATEGORIAS- DE-IMPOSTOS
Ps-condio 2
MENSAGEM-ERRO gerada
Figura 11.3: Uma espec de condies pr/ps
Como se pode ver, uma especificao tem duas partes principais:
pr condies e ps condies. Alm disso, essas especificaes podem conter termos
locais, como foi explicado na seo 11.1 (veja tambm a nota 5).
As pr-condies descrevem tudo que deve ser verdadeiro (se houver algo) antes que o
processo inicie seu funcionamento. s vezes prtico imaginar o processo como uma
princesa adormecida e as pr- condies como o beijo mgico que despertar o
processo e o por a trabalhar. Como alternativa, as pr-condies podem ser consideradas
como uma garantia do usurio: Garanto que quando este processo for ativado, as
seguintes coisas sero verdadeiras. Costumeiramente, as pr- condies descrevero o
seguinte:
Que entradas devem estar disponveis. Essas entradas sero re cebidas por meio de um
fluxo interligado ao processo, como mostrado no diagrama de fluxo de dados. Observe
que pode haver casos em que haja vrios fluxos chegando a um processo, porm s um
deles seja uma pr-condio necessria ativao do processo. Por exemplo, se vssemos
uma especificao que comeasse por
Pr-condio
o elemento de dados X ocorre
em combinao com o diagrama de fluxo de dados mostrado na figura 11.4, nossa
interpretao seria a seguinte: a chegada do elemento de dados X o estimulo ativador
que d partida no funcionamento do processo. Como parte de sua tarefa, ele procura
entradas provenientes dos fluxos de dados Y ou Z, ou
267
de ambos, mas Y e Z no so necessrios para que o processo inicie seu funcionamento.
Que relacionamentos devem existir entre as entradas ou no in terior delas. Com muita
freqncia uma pr-condio especifi car que devem chegar duas entradas com campos
correspon dentes (ex.: detalhes de pedidos e detalhes de remessas com o mesmo nmero
de conta). Ou a pr-condio pode especificar que um componente de um elemento de
dado de entrada deve estar dentro de um certo intervalo (p. ex.: ocorre um pedido com
data de entrega superior a 60 dias).
Que relacionamentos devem existir entre entradas e depsitos de dados. Uma pr-
condio pode estipular que exista um regis tro em um depsito que coincida com algum
aspecto de um ele mento de dado de entrada (ex.: a pr-condio poderia dizer:
existe um pedido-de-cliente com um nmero-de-conta-de- cliente que coincide com um
nmero-de-conta-de-cliente no depsito de clientes).
Que relacionamentos devem existir entre diferentes depsitos ou no interior de um
depsito. Desse modo, a pr-condio poderia dizer: existe um pedido no depsito de
pedidos cujo nmero- de-conta-de-cliente coincide com o nmero-de-conta-de-cliente no
depsito de clientes. Ou a pr-condio poderia estabelecer:
existe um pedido no depsito de pedidos com uma data-de- embarque igual data
atual.
As ps-condies descrevem de forma anloga o que deve ser
verdadeiro quando o processo terminar sua tarefa. Tal como antes, is so pode ser
considerado como uma garantia: Garanto que quando o
268
x
Y
Q
Figura 11.4: Um DFD com entradas X, Ye Z
1
processo tiver terminado o que se segue ser verdadeiro. As pos- condies
habitualmente descrevem o seguinte:
As sadas que sero geradas ou produzidas pelo processo. Essa a forma mais comum
de ps-condio (ex.: Ser produzida
uma fatura).
Os relacionamentos que existiro entre os valores de sada e os valores origina is de
entrada. Isso comum nas situaes em que uma sada funo matemtica direta de um
valor de en trada. Assim, uma ps-condio poderia dizer: O total-fatu rado ser
calculado como soma dos preos-unitrios-de-Item mais taxas-de-embarque.
Os relacionamentos que existiro entre os valores de sada e os valores em um ou mais
depsitos. Isso comum quando as in formaes devem ser recuperadas de um depsito e
usadas com parte de uma sada do processo. Por exemplo, a especificao de um processo
poderia ter como ps-condio o seguinte: O balano-pendente no depsito
INVENTRIO ser aumentado pelo valor-recebido e o novo inventrio-pendente ser
pro duzido como sada deste processo.
As alteraes que devero ser feitas nos depsitoS: acrscimo de novos itens,
modifIcao ou eliminao de itens j existentes. Desse modo, poderamos ver
declaraes como: O pedido ser acrescentado ao depsito PEDIDOS ou O registro
cliente ser eliminado do depsito CIJENTES.
Quando for elaborar a especificao de uma condio pr/ps, comece por descrever em
primeiro lugar as situaes de processamento normal. Podem existir diversas situaes
normais diferentes (ex.: combi naes nicas de relacionamentos vlidos
entrada/depsito) cada uma das quais expressa por uma pr-condio distinta e separada.
Para cada uma dessas pr-condies, voc deve descrever a condio da bolha de
processo quando as sadas tiverem sido produzidas e os depsitos te nham sido
modificados. Aps terem sido descritas as situaes normais de processamento, devem
ser includas as pr e ps-condies adequa das para os casos de erros e situaes
anormais. Considere a especifica o de condies pr/ps mostrada na figura 11.5(b)
que seriam desen volvidas para um novo sistema a partir da especificao narrativa da
figura 11.5(a).
269
Se um cliente me diz ter crdito ao vir caixa registrar sua despesa, eu verifico sua conta
em meu arquivo. Se eu a ercontrar e ela no estiver marcada com suspensa ou
cancelada, eu preencho o formulrio do dbito com o nmero da conta e o valor da
venda. Caso contrrio, eu informo ao cliente que ele ter de pagar em di nheiro ou
conversar com o gerente.
Figura 11.5 (a): Um exemplo de especificaes narrativas
Pr-Condio 1
O cliente se apresenta com um nmero-de-conta Coincidente com um nmero de conta
em CONTAS,
cujo cdigo-de est ajustado em vlido.
Ps-condio i
A fatura emitida contendo nmero-de e
valor-da-venda
Pr-Condio 2
A Pr-condio i falha por algum motivo (o
nmero-de no encontrado em CONTAS ou o
cdigo-de. no igual a vlido.
PS-Condio 2
E emitida uma mensagem de erro.
Figura 11.5(b): Um exemplo de condies pr-ps
Embora a abordagem de condies pr/ps seja til e apresente diversas vantagens, h
ocasies em que ela pode no ser adequada. A falta de etapas intermedirias entre as
entradas (pr-condies) e as sadas (ps-condies) deliberada e consciente - mas pode
tornar a especificao dificil de ser entendida se o leitor no puder visualizar algum tipo
de procedimento que conduza das entradas para as sadas. Alm disso, se houver
relacionamentos complexos entre as entradas e as sadas, pode ser mais fcil escrever a
especificao usando a lingua gem estruturada. Um exemplo de uma especificao de
pr-condio/ ps-condio que possivelmente muito complexa pode ser visto na figura
11.6.
270
DETERMINAR EMPRSTIMO COM BASE NOS FATORES DO
CLIENTE
Pr-condio 1
pedido-de-emprstimo ocorre
e tempo-de-servio > 5 ou valor-lquido > valor-do- emprstimo e despesas-mensais <
0.25 * valor-do- emprstimo
ou garantia-colateral > 2 * valor-do-emprstimo e idade> 25 ou garantia-colateral >
valor-do-emprstimo e idade > 30
ou tempo-de-servio > 2 e valor-lquido > 2 * valor-do- emprstimo e idade> 21 e
despesas-mensais < 0.5 * valor- do-emprstimo
Ps-condio 1
valor-aprovado = valor-do-emprstimo
Figura 116: Uma espec de condies pr/ps demasiadamente
complexa
Assim como em todas as formas de especificaes de processos, voc deve deixar que
seu prprio julgamento e reaes do usurio o guiem; se o usurio considerar dificil ler a
especificao de pr-condi es/ps-condies, escolha outro formato. A abordagem de
pr-condi es/ps-condies mostrada no estudo de caso do apndice G; a abordagem
alternativa de linguagem estruturada utilizada no estudo de caso do apndice F.
Examine cuidadosamente esses dois estudos de ca sos para determinar a adequabilidade
dessas duas ferramentas de especi ficao de processos.
11.3 TABELAS DE DECISES
Existem situaes em que nem a linguagem estruturada e nem as condies pr/ps so
adequadas para se elaborar uma especificao de processos. Isso especialmente
verdadeiro quando o processo deve produzir alguma sada ou executar aes com base
em decises comple xas. Se as decises forem baseadas em diversas variveis (p.ex.:
elemen tos de dados de entrada), e se essas variveis puderem assumir muitos valores
diferentes, ento a lgica expressa pela linguagem estruturada ou pelas condies pr/ps
ser provavelmente to complexa que o usurio no a entender. A abordagem mais
recomendvel ser possivelmente a tabela de decises.
271
1234 5678
ldade>21
S
S
S
S
N
N
N
N
Sexo
M
M
F
F
M
M
F
F
Peso>150
S
N
S
N
S
N
S
N
Medicao 1
X
X
X
Medicao 2
X
X
Medicao 3
X
X
X
Nenhuma medicao X X
Figura 11.7: Uma tabela de decises tpica
Como se v na figura 11.7, uma tabela de decises criada relacio nando-se todas as
variveis relevantes (tambm conhecidas como condi es ou entradas) e todas as aes
relevantes no lado esquerdo da ta bela; observe que as variveis e as aes esto
separadas por uma linha horizontal grossa. Neste exemplo, todas as variveis so lgicas,
o que significa que podem assumir valor verdadeiro ou falso.
Em muitas aplicaes, fcil (e prefervel) expressar as vari veis como binrias
(falso/verdadeiro), mas as tabelas de decises tambm podem ser construdas a partir de
variveis que podem assu mir muitos valores diferentes; por exemplo, pode-se construir
uma tabela de decises com uma varivel chamada idade-do-cliente cujos valores
relevantes sejam menor que 10,entre 10 e 30 e maior que 30.
Em seguida, cada combinao possvel de valores das variveis listada em uma coluna
separada; costuma-se chamar cada coluna de norma. Uma norma descreve a ao (ou
aes) que deve ser tomada para uma especfica combinao de valores das variveis.
Pelo menos uma ao deve ser especificada para cada norma (isto , para cada colu na
vertical na tabela de decises), ou o comportamento do sistema para aquela situao no
ser especificado.
Se houver N variveis com valores binrios (falso/verdadeiro), en to haver 2 normas
distintas; assim, se houver trs condies, haver 8 normas, e se houver 7 condies,
haver 128 normas. A enumerao de todas as normas um processo bastante direto:
considerando-se o Sim (ou D como um zero binrio e o No (ou F) como um um (1)
binrio, fcil gerar uma seqncia de 000, 001, 010, 011, 100, 101 e assim por diante,
at que todas as 2N combinaes tenham sido geradas .
Voc deve discutir cada norma com o usurio para garantir que tenha sido identificada a
ao correta, ou aes corretas, para cada combinao de variveis. muito comum,
quando se faz isso, descobrir que o usurio nunca pensou em certas combinaes de
variveis ou que
272
elas nunca ocorreram anteriormente R A vantagem da tabela de decises que voc pode
se concentrar em uma norma de cada vez.
Outra vantagem da utilizao das tabelas de decises que elas no implicam qualquer
forma de implementao em particular. Isto , quando o analista de sistemas entrega a
tabela de decises (juntamente com os DFD e etc.) ao projetista/programador, h uma
imensa liberdade de escolha em termos de estratgia de implementao: a tabela de de
cises pode ser programada com sentenas IF aninhadas, com uma cons truo CASE ou
com uma construo GO TO DEPENDING ON em COBOL; no caso extremo, o gerador
de cdigo de tabela de decises po de gerar cdigo automaticamente a partir da tabela de
decises. Assim, as tabelas de decises so muitas vezes consideradas como uma ferra
menta no-proceclural de modelagem de sistemas, porque no deter minam qualquer
especfico algoritmo procedural para executar as aes necessrias.
Para resumir, devemos seguir as etapas abaixo para a criao de
uma tabela de decises para uma especificao de processos:
1. Identifique todas as condies ou variveis na especificao. Identifique todos os
valores que cada varivel pode assumir.
2. Calcule o nmero de combinaes de condies. Se todas as condies forem binrias,
haver 2 combinaes de N
variveis.
3. Identifique cada ao possvel na especificao.
4. Crie uma tabela de decises vazia, relacionando todas as con dies e aes no lado
esquerdo e numerando as combinaes
de condies no alto da tabela.
5. Relacione todas as combinaes de condies, uma para cada coluna vertical da tabela.
6. Examine cada coluna vertical (norma) e identifique as aes adequadas a serem
empreendidas.
7. Identifique todas as omisses, contradies e ambigidades da especificao (ex.:
normas da tabela de decises para as quais a
especificao no indique que aes devem ser empreendidas).
8. Discuta as omisses, contradies e ambigidades com o usurio.
273

11.4 OUTRAS FERRAMENTAS DE ESPECIFICAO DE PROCESSOS


11.4.1 Grafos e Diagramas
Em alguns casos pode ser apropriado expressar uma especificao de processos por meio
de um grafo ou de um diagrama. Na verdade, o usurio pode j dispor de um grafo ou de
um diagrama que seja presen temente usado para executar aquela parte da aplicao. Se
for assim, use-o! No h necessidade de o analista de sistemas traduzir um grafo para
linguagem estruturada; em vez disso, deixe o programador traduzi- lo diretamente para o
COBOL, FORTRAN, ou para outra linguagem de programao quando for a hora de
implementar o sistema.
Considere, como exemplo, uma especificao de processos que
determina o prmio de seguro de um cliente em funo da idade. O
usurio informou que a orientao atual da empresa estabelecer o
prmio a partir do grafo mostrado na figura 11.8.
Presumindo que a orientao no se altere quando for elaborado um novo sistema e
presumindo que o prmio de seguro seja funo apenas da idade, no h necessidade de o
analista de sistemas executar qualquer trabalho adicional. A figura 11.8 a especificao
de processos.
Prmio 300
Idade
Figura 11.8: Prmio de seguro em funo da idade
11.4.2 Linguagem Narrativa
Como ficou implcito por diversas vezes neste captulo, a lingua gem narrativa no uma
ferramenta recomendvel para se redigir espe cificaes de processos. Isso porque:
274
Um vocabulrio irrestrito (com indiscriminado uso de substan tivos, verbos e adjetivos)
torna provvel que a descrio do pro cesso inclua termos que no estejam no dicionrio
de dados e cujo significado no seja claro.
As aes alternativas (decises) so muitas vezes expressas de uma forma mal feita e
ambgua. Isso torna-se pior se as decises
forem expressas com utilizao do aninhamento.
As aes repetitivas (laos) tambm so expressas de forma de sajeitada e ambgua. Os
laos alinhados so extremamente peri gosos quando expressos em linguagem comum.
O conceito de estruturas de bloco s pode ser expresso com endentao ou com
apresentao em estilo de sumrio; se al gum quisesse ir at esse ponto poderia tambm
utilizar a nota o da linguagem estruturada formal.
Se, por alguma razo, voc for forado a utilizar a linguagem narra tiva, convm pelo
menos conservar algumas das vantagens da anlise estruturada altamente subdividida que
vimos discutindo neste livro. Isto , sob nenhuma circunstncia admita ser obrigado a
escrever uma espe cificao tipo novela vitoriana monoltica de 2 mil pginas. Em ltimo
caso, subdivida a especiflcao em pequenas partes, de forma a que voc possa escrever 2
mil historinhas independentes.
11.4.3 Fluxogramas
Temos evitado a utilizao de fluxogramas at agora em nossa discusso, mas isso um
reflexo do atual desinteresse em fluxogramas e no uma acusao contra eles . Grande
parte das crticas em relao aos fluxogramas deve-se mt utilizao deles nas seguintes
reas:
1. Como ferramenta de modelagem de alto nvel de sistemas, os fluxogramas so muito
prejudicados. Os fluxogramas apre sentam lgica procedural e seqencial. Como vimos
no captulo 9, um diagrama de fluxo de dados uma ferramenta mais adequada para
modelar uma rede de processos comunicantes assincronos.
2. Nada impede que o analista de sistemas crie um fluxograma arbitrariamente complexo
e desestruturado da ordenao (sort)
mostrada na figura 11.9.
275
Entretanto, se o fluxograma for utilizado apenas para descrever l gica detalhada e se o
analista de sistemas se restringir a incluir no fluxograma smbolos equivalentes s
construes da linguagem estrutu rada descritas na seo 11.1, nada haver de errado com
seu emprego. Para criar um fluxograma estruturado, o analista de sistemas deve orga
nizar sua lgica com combinaes aninhadas dos simbolos de fluxogra ma mostrados na
figura 11.10.10
Figura 11.9: UmJluxograma no-estruturado
Figura 11.10: Os smbolos dofluxograma estruturado de Bbm-Jacopini
276
Uma alternativa o emprego dos diagramas de Nassi-Shneiderman, discutidos na seo
114.4. Contudo, deve-se dizer que muito poucos analistas de sistemas usam fluxogramas
para especificar processos (e nem para projetos de programas, tambm). Embora as
ferramentas auto matizadas descritas no apndice A possam ser utilizadas para criar e
manter fluxogramas, a verdade que a linguagem estruturada, as tabelas de decises e as
especificaes de condies pr/ps so mais fceis para criar e manter.
11.4.4 Diagramas de Nassi-Shneiderman
Quando a programao estruturada tornou-se popular em meados dos anos 70, os
diagramas de Nassi-Shneiderman foram apresentados como uma tcnica de
fluxogramao estruturada; veja INassi e Shneider man, 19731 e [ 19741. Um diagrama
de Nassi- Shneiderman tpico toma a forma mostrada na figura 11.11.
Observe que uma sentena imperativa simples representada por
um retngulo, como se pode ver na figura 11.12(a); o retngulo tambm
pode ser usado para representar um bloco de sentenas seqenciais. A
N.
\
Figura 11.11: Um diagrama de Nassi-Shneiderman tpico
Figura 11.12 (a): Representao de uma sentena seqencial
sentena 1 sentena 2
277
construo binria IF-TIIEN-EISE representada pela notao grfica mostrada na figura
11.12(b); e a construo repetitiva DO-WHILE representada pela notao grfica
mostrada na figura 11.12(c).
Os diagramas de Nassi-Shneiderman so geralmente mais organiza dos, mais estruturados
e mais abrangentes que os fluxogramas comuns; por esse motivo, eles so por vezes
preferidos como ferramenta para a criao de especificaes de processos. Entretanto,
eles exigem uma quantidade no trivial de grficos, e no est bem claro se os grficos
proporcionam uma vantagem correspondente. Muitos analistas dc siste mas j foram
vistos comentando depois de gastarem uma hora criando um diagrama de Nassi-
Shneiderman: Isso a mesma coisa que usar linguagem estruturada com alguns quadros
desenhados em volta das sentenas!.
Por outro lado, uma pesquisa recente conduzida por David Scanlan na Universidade do
Estado da Califrnia (IScanlan, 19871) mostrou que 75% a 80% dos estudantes de
cincia do processamento preferem deckli damente os diagramas de Nassi-Shneiderman
em lugar de pseudocdigo no aprendizado de algoritmos complexos. Embora isso esteja
em oposi o tpica reao negativa dos programadores experientes em relao aos
fluxogramas, as concluses de Scanlan so baseadas em cuidadosos estudos analticos
dos fatores de algumas centenas de estudantes. Ainda que os usurios finais no tenham
necessariamente as mesmas prefern cias dos estudantes da cincia do processamento,
existe pelo menos a possibilidade de que eles prefiram a representao grfica da
especifica o de um processo em vez de uma representao narrativa/textual.
condio
T F
sentenal sentena2
Figura 11.12 (b): Representao de uma construo IF-77-IEN-ELSE
11.5 RESUMO
O propsito deste captulo foi mostrar que existem muitas maneiras diferentes de
descrever a orientao detalhada do usurio no interior de cada bolha primitiva de um
diagrama de fluxo de dados. Embora a lin guagem estruturada seja a tcnica mais
comumente utilizada nos dias de hoje, voc deve considerar o uso de tabelas de decises,
fluxogramas, condies pr/ps e outras abordagens que podem ser verificadas e
transmitidas facilmente a seus usurios.
278
Condio DO UNTIL
sentena 1
sentena 2
sentena n
Figura 11.12 (c): Representao de uma construo DO-WHILE
Lembre-se que as especificaes de processos representam o maior volume de trabalho
minucioso na construo do modelo de um sistema; podem existir centenas e at milhares
de especificaes de processos, e cada uma pode ocupar uma pgina. Face ao volume de
esforo envol vido, considere a abordagem da implementao top-down discutida no
captulo 5 - comece a fase de projeto e implementao de seu sistema antes do final das
especificaes de processos. Lembre-se tambm que a atividade de escrever
especificaes de processos serve como um teste de sanidade dos diagramas de fluxo
de dados que j foram desenvolvi dos. Voc pode descobrir que a especificao de
processos necessita de fluxos de dados de entrada adicionais (fluxos que no foram
mostrados no DFD) e, ao escrever a especificao de processos, pode surgir a
necessidade de mais funes; por exemplo, ao escrever a especificao de processo para
uma funo que acrescente um novo registro ao de psito CLIENTES, voc pode
observar que o DFD no tem uma bolha que modifique ou suprima um registro daquele
depsito. Assim, voc deve esperar que sejam necessrias modificaes, revises e
correes no DFD fundamentadas no minucioso trabalho de escrever as especifi caes
de processos.
REFERNCIAS
1. Tom DeMarco, Structured Analysis and Systems Speciflcation. Englewood Cliffs, N.J.:
Prentice-Hall, 1979.
2. Chris Gane e Trish Sarson, Structured Systems Analysis: Tools and Tecbniques.
Englewood Cliffs, Nj.: Prentice-Hall, 1978.
279
3. Edward Yourdon, Technques ofProgram Siructure and Design, 2 ed. Englewood
Cliffs, N.J.: Prentice-Hall, 1988.
4. James Martin e Carma McClure, Diagramming Technique.s for Soft ware Engineerng.
Englewood Cliffs, N.J.: Prentice-Hall, 1985.
5. Victor Weinberg, Slructured Analysis. Englewood Cliffs, N.J.: Pren tice-Hall, 1978.
6. Edward Yourdon, Classics in Software Engineering. Nova lorque:
YOURDON Press, 1979.
7. Corrado Bhm e Giuseppe Jacopini, Flow Diagrams, Turing Ma chines, and
Languages with Only Two Formation Rules, Commu nication.s of lhe ACM, Volume 9,
Nmero 5 (maio de 1966), pgs. 366-371. Reimpresso em Classics in Software Engineei
(op. cit.).
8. 1. Nassie B. Shneiderman, Flowchart Techniques for Structured Programming, ACM
SIGPLAN Notces, Volume 8, Nmero 8
(agosto de 1973), pgs. 12-26.
9. Ned Chapin, New Format for Flowcharts, Software - Pracace and Expertence,
Volume 4, Nmero 4 (outubro-dezembro 1974),
pgs. 341-357. -
10. H. McDaniel, editor, Application of Decision Tables. Princeton, N.J.:, Brandon
Systems Press, 1970.
11. S. Pollac, H. Hicks e W. Harrison, Decision Tables Theoiy and Practice. Nova lorque:
Wiley, 1971.
12. T. R. Gildersleeve, Decislon Tables and Their Practical Applica tions in Data
Processing. Englewood Cliffs, N.J.: Prentice-Hall,
1970.
13. David Scanlan, Cognitive Factors in the Preference for Structured Flowcharts: A
Factor Analytic Study, apresentado na First Annual YOURDON Press Authors
Conference, 5 de dezembro dc 1987.
PERGUNTAS E EXERCCIOS
1. Considere a especificao a seguir, apresentada em forma narra- uva. Qual das
ferramentas de especificao vistas neste captulo
voc acha que seria a mais adequada? Por qu?
Quando recebo um pedido de compra meu trabalho escolher um fornecedor em nosso
arquivo de fornecedores disponveis. Natura! mente, alguns so eliminados de imediato
por causa de seus attos preos, ou porque esto temporariamente na lista negra pela m
qualidade. Mas o verdadeiro trabalho escolher o fornecedor timo entre os melhores,
aquele que entregar nosso pedido no mais curto tempo. Meu chefe tem um sistema para
estimar o tempo de entrega, e ele me ensinou a usar esse sistema, mas neste momento eu
apenas
280
II
examino o endereo do fornecedor, a quantidade de itens do pe dido e a data em que
precisamos da mercadoria, e eu sei qual ser o melhor fornecedor... Eu no sei porque
ainda fao isso
2. O que uma especificao de processos? Quais so seus objetivos?
3. Cite cinco ferramentas comuns para modelar especificaes de processos.
4. Quais so os trs requisitos que uma especificao de processos deve satisfazer?
5. Um projeto de desenvolvimento de sistemas deve usar apenas uma ferramenta para
especificao de processos? Por qu?
6. Projeto de Pesquisa: que ferramentas de especificao so utiliza das em sua empresa?
Existem restries quanto s ferramentas que podem ser usadas? Voc acha que estejam
sendo empregadas as ferramentas adequadas?
7. Que bolhas de um DFD exigem especificaes de processos?
8. Quais so as conseqncias de escrevermos especificaes de pro cessos para bolhas
no-atmicas (no-primitivas)?
9. Como o analista de sistemas deve determinar quais devem ser as especificaes de
processo para uma bolha?
10. Como as especificaes de processos por vezes impem decises arbitrrias de
projeto e de implementao? Quais so as conse qncias disso?
11. Projeto de Pesquisa: encontre um exemplo de especificao de processos em sua
empresa que apresente decises arbitrrias de projeto ou de implementao. Como voc a
reescreveria para evitar esse problema?
12. D uma definio para a expresso linguagem estruturada. Apre sente alguns
sinnimos dessa expresso.
13. Quantos verbos so necessrios para formar sentenas em lingua gem estruturada?
Sugira uma lista de 20 verbos.
14. Por que as equaes algbricas costumam ser necessrias em uma especificao de
processos em linguagem estruturada?
15. Que caractersticas devem ter os objetos em uma especificao de processos em
linguagem estruturada?
16. Que so termos locais?
17. Devem os termos locais ser includos em um dicionrio de dados? Por qu?
18. Os termos locais aparecem como fluxs nos DFD?
19. Apresente um exemplo especfico de um termo local.
20. Quais construes da programao estruturada so utilizadas em linguagem
estruturada?
21. Qual o propsito da clusula OTHERWISE na linguagem estruturada?
281
22. Qual a diferena entre a construo DO-WIIILE e a construo REPEAT-UNTIL
em linguagem estruturada?
23. O que uma sentena composta?
24. A construo CASE necessria linguagem estruturada? Quais so as vantagens e
desvantagens da construo CASE?
25. Quais so os quatro componentes de uma sentena composta?
26. Qual a diferena entre (a) e (b)?
(a) 11 A fliEN
IF B T1
senrena-1
sentena-2
sentena-2.
(b) IF A AND B T1 sentena-!
i
sentena-2.
Quais desses dois exemplos voc considera mais fcil de compre ender? Por qu?
27. Projeto de Pesquisa: construa alguns exemplos semelhantes ao da pergunta 26 e faa
um levantamento entre os usurios para verifi car qual verso eles preferem.
28. Quais so as trs diretrizes que devem ser seguidas para garantir que uma
espeificao em linguagem estruturada ser legvel?
29. Voc concorda em que trs nveis de IF aninhados em uma especi ficao em
linguagem estruturada so aceitveis? Por qu
30. Projeto de Pesquisa: prepare alguns exemplos de especificaes de processos em
linguagem estruturada envolvendo dois, trs e quatro nveis de IF aninhados. Faa um
levantamento para determinar, em mdia, quantos nveis os usurios em sua empresa
esto dispostos a aceitar.
31. Qual o propsito da endentao em uma especificao de pro cessos em linguagem
estruturada?
32. Por que importante conduzir caminhamentos (walkthroughs) em uma especificao
de processos em linguagem estruturada com o
usurio apropriado?
33. Qual o propsito de se utilizar numerao em estilo de sumrio em uma
especificao em linguagem estruturada?
34. D uma definio da tcnica de especificao pr-condio/ps condio.
282
35. Qual a diferena entre a tcnica de especificao em linguagem estruturada e a
tcnica de pr-condio/ps-condio?
36. Sob quais circunstncias a tcnica de especificao pr-condio/ ps-condio
recomendvel para ser utilizada pelo analista de
sistemas?
37. D uma definio de pr-condio.
38. Quais so as trs coisas que uma pr-condio habitualmente descreve?
39. Qual o relacionamento entre pr-condies em uma especifi cao de processos e
fluxos de entrada em um DFD?
40. Que acontece se as pr-condies de uma especificao de proces sos no forem
satisfeitas?
41. D uma definio de ps-condio.
42. Quais so as quatro coisas que uma ps-condio habitualmente descreve?
43. Qual o relacionamento entre ps-condies e fluxos de sada em um DFD?
44. Se uma especificao de processos tiver quatro conjuntos de pr- condies, quantos
conjuntos de ps-condies dever possuir?
45. Qual o nmero mnimo de pr-condies que uma especificao de processos pode
ter?
46. Quais so as potenciais desvantagens da abordagem pr-condio/ ps-condio?
47. Projeto de Pesquisa: encontre um exemplo de uma especificao de processos do
mundo real que no se adequaria bem aborda gem de especificao de pr-
condio/ps-condio. Por que ela no se adequaria bem?
48. Examine a figura 11.6. Qual seria a melhor ferramenta de mo delagem para criar uma
especificao de processos para aquela
situao?
49. Projeto de Pesquisa: encontre um exemplo de uma especificao de processos do
mundo real que se adequaria bem abordagem
de pr-condio/ps-condio. Por que ela se adequaria?
50. O que uma tabela de decises? Quais so os componentes de uma tabela de
decises?
51. Sob que condies uma tabela de decises uma boa ferramenta para especificaes
de processos?
283
A
52. O que est errado na tabela de decises abaixo?
Idadesuperiora2
T
E
F
Sexo masculino
T
T
F
Medicao 1
Medicao 2
X
53. O que est errado na tabela de decises abaixo?
Altura superior a 1,80m
T
T
E
F
Pesosuperiora9
T
F
T
E
Prmiodeseguro=$100
>
X
Prmio de seguro = $200
X
X
Prmio de seguro = $300
54. O que est errado na tabela de decises abaixo?
Altura superior a 1,80m
T
T
E
F
Pesosuperiora9okg
T
E
T
F
Prmiodeseguro=$100
x
>
x
Prmio de seguro = $200
X
Prmio de seguro = $300
x
284
55. Qual a diferena entre uma tabela de decises com variveis binrias e uma tabela
com variveis que podem assumir mltiplos
valores?
56. Se uma tabela de decises tiver N variveis binrias, quantas nor mas ela dever ter?
57. Sob que circunstncias o analista de sistemas deve usar um grafo para elaborar a
especificao de processos?
58. Quais so as vantagens de um grafo sobre a linguagem estruturada como ferramenta
de modelagem para especificaes de
processos?
59. Quais so as quatro maiores desvantagens da linguagem narrativa como ferramenta
de modelagem para especificaes de processos?
60. Que diretrizes devem ser seguidas se a linguagem narrativa tiver de ser utilizada
como ferramenta de modelagem para especificaes
de processos?
61. Quais so as duas maiores crticas aos fluxogramas como ferramen tas de
modelagem?
62. Quais so os trs componentes de um fluxograma estruturado?
63. Apresente a um usurio a mesma especificao em linguagem es truturada e em
forma de fluxograma. Qual abordagem ele prefere?
Para maiores informaes sobre isso veja EScanlan, 19871.
64. O que um diagrama de Nassi-Shneiderman? Qual a diferena entre um
fluxograma e um diagrama de Nassi-Shneiderman?
65. De Structured Analysis de Victor Weinberg (Nova lorque:
YOURDON Press, 1978): Prepare uma tabela de decises para a seguinte especificao
narrativa e indique quaisquer omisses, ambigidades e contradies que voc encontrar:
A firma Swell Store emprega alguns vendedores para vender diver sos itens. A maioria
desses vendedores recebe seus ganhos a partir de uma comisso paga sobre os itens que
eles venderem, mas alguns so empregados que recebem salrio + comisses; isto ,
recebem um salrio fixo, no importando a quantidade ou o tipo de itens que vendam,
mais uma comisso sobre certos itens. A Swell Store comercia com vrias diferentes
linhas de mercadorias, algumas das quais so conhecidas como itens comuns (uma lata de
sopa de tomates, por exemplo) porque so amplamente aceitas e no exi gem tcnicas
criativas de venda; alm disso, existem itens privilegia dos que so altamente lucrativos
mas diriceis de vender (um cadillac dourado e cravejado de diamantes, talvez). Os ilens
comuns e os privilegiados representam de modo geral as extremidades inferior e superior
do espectro de preos, ensanduichando um grande nmero de itens no meio do espectro.
Os clientes tambm so divididos em categorias. Alguns so conhe cidos como regulares,
porque fazem compras com tanta freqncia
285
que no h necessidade de vendas criativas. A maioria dos fregueses, contudo, faz um
pequeno volume de compras na Swell Store; vm da rua, entram na loja, compram
alguma coisa e desa parecem para sempre.
O critrio de comisses da direo o seguinte: se um empregado no-assalariado vender
um item que no seja comum nem privile giado para algum que no seja um fregus
regular, recebe uma co misso de 10 por cento, a menos que o item custe mais de
$10.000, em cujo caso a comisso de 5 por cento. Para todos os vendedores, se um item
comum for vendido ou se qualquer item for vendido a um fregus regular, no paga
qualquer comisso. Se um vendedor assalariado vender um item privilegiado, receber
uma co misso de 5 por cento, a menos que o item custe mais de $1.000, caso em que ele
recebe uma comisso simples de $25. Se um vende dor no-assalariado vender um item
privilegiado a algum que no seja um fregus regular, recebe comisso de 10 por cento,
a menos que o item custe mais de $1.000, caso em que receber uma comis so simples
de $75.
NOTAS
1 Para maiores informaes sobre o USE-if, veja Structured iecb fiques for Computing,
de James Martin e Carma McClure. (Engle wood Cliffs, N.J.: Prentice-Hall, 1986).
2 Isso muitas vezes causado pela introduo de todo um conjunto de padres de anlise
estruturada na organizao. Embora os pa dres sejam um admirvel esforo no combate
indolncia, igno rncia e anarquia total, eles s vezes vo longe demais e impem
uma rgida e uniformizadora soluo para todos os problemas. Como diz um ditado
popular: Se voc s tem um martelo, o mundo todo parece um prego.
3 Experimente usar o algoritmo em diversos casos. Voc ver que ele
converge bastante rapidamente.
4 A despeito desse aviso, devemos ressaltar que voc precisar, s vezes, como analista
de sistemas, elaborar uma especificao es crita para processos de nvel elevado. Isso
ocorrer se o usurio de cidir que quer mostrar a especificao a seu chefe e estiver preo
cupado em que ele no aceite a idia de DFD em nveis. Desse mo do, o usurio lhe dir:
Bem, eu sei que voc no precisa de uma especificao de processos para as bolhas de
nvel superior, mas eu gostaria que voc a fizesse para que o chefe possa entender co mo
o sistema. Voc ter de se haver com problemas assim com a mesma habilidade
diplomtica usada para solucionar todos os outros problemas polticos em seu projeto.
286
5 Termos locais so definidos dentro da especificao do processo
onde eles ocorrem e no so definidos no dicionrio de dados. Eles
so muitas vezes derivados (calculados diretamente) de termos que
j constam no dicionrio, assim, seria redundante incluir os termos
locais. Alm disso, por definio, os termos locais s so conheci
dos em um contexto local (isto , no interior de uma bolha de um
diagrama de fluxo de dados). Eles no devem aparecer como um
fluxo no DFD e habitualmente no fazem parte do vocabulrio
normal orientado-para-a-aplicao utilizado pelo usurio.
6 Se voc no estiver familiarizado com a programao estruturada,
consulte um dos textos padres sobre o assunto, ou veja alguns
dos primeiros artigos sobre esse tema coligidos em EYourdon,
1979].
7 Naturalmente, haver situaes em que as condies da tabela de
decises no sero binrias por natureza, mas so capazes de assu
mir diversos valores (p.ex.: uma aplicao de seguros poderia
envolver idade-do-cliente e usar os valores abaixo de 18 anos,
18 a 64 e 65 ou mais). Para determinar o nmero total de nor
mas em uma tabela de decises desse tipo, preciso multiplicar o
nmero de valores que a varivel 1 pode assumir pelo nmero de
valores que a varivel 2 pode assumir pelo ... nmero de valores
que a varivel N pode assumir. Portanto, se tivermos uma aplicao
onde a varivel 1 pode assumir 3 valores, a varivel 2 pode assumir
5 valores e a varivel 3 pode assumir 4 valores, sero necessrias
3 X 5 X 4 = 60 normas distintas.
8 Existem diretrizes para simplificar tabelas de decises e para com
binar diversas normas em normas compostas, mas no trataremos
delas neste livro. Veja LYourdon, 19761, onde se encontram detalhes
sobre isso.
9 Entretanto, interessante observar que os fluxogramas podem es
tar renascendo. Um recente trabalho de David Scanlan da Universi
dade do Estado da Califrnia em Sacramento mostrou que os estu
dantes de programao preferem os fluxogramas aos mtodos mais
apreciados para o aprendizado de algoritmos. Se isso verdadeiro
para estudantes de programao, talvez tambm o seja para os
usurios. Para mais detalhes, veja o artigo de Scanlan entitulado A
Niche for Strutured Flowcharts, Proceedings of the 1987 ACM
Computer Science Conference.
10 Para mais informaes sobre fluxogramas estruturados, veja o cls
sico artigo [ e Jacopini, 1966].
287
12
DIAGRAMAS DE
ENTIDADES-
RELACIONAMENTOS
Obviamente, a capacidade de julgamento de um homem no pode ser melhor do que as
informaes em que ele est fundamentado. Dem-lhe a verdade e ele pode continuar
errado quando tiver a oportunidade de estar certo, mas pnvem-no de notcias ou
apresentem-lhe somente dados dstorcidos ou incompletos, com relatrios ignorantes, mal
feitos ou tendenciosos, com propaganda e falsidades deliberadas, e destruiro seus proc
de raciocnio e o transformaro em algo inferior a um homem.
Arthur Hays Sulzberger
Address, New York State Publisbers Association, 1948
Neste captulo, aprenderemos:
1. Porque os modelos de dados so teis em anlise de sistemas.
2. Os componentes de um diagrama de entidades- relacionamentos.
3. Como desenhar um diagrama de entidades-relaciona mentos.
4. Como refinar um diagrama inicial de entidades- relacionamentos.
Neste captulo vamos explorar uma notao grfica para modela gem de dados. O
diagrama de entidades-relacionamentos (tambm
conhecido como diagrama DER ou E-R) um modelo em rede que
289
descreve a diagramao dos dados armazenados de um sistema em alto nvel de
abstrao. Ele inteiramente diferente de um diagrama de fluxo de dados que modela as
funes executadas por um sistema e diferente do diagrama de transies de estado, que
modela o compor tamento tempo-dependente de um sistema.
Por que estaramos interessados no modelo de dados de um siste ma Primeiro porque as
estruturas de dados e os relacionamentos podem ser to complexos que desejamos
evidenci-los e examin-los indepen dentemente do processamento que ocorrer. Isso, na
realidade, espe cialmente verdadeiro quando mostramos nosso modelo do sistema aos
usurios executivos de alto nvel na organizao (vice-presidentes ou chefes de
departamentos que podem no estar interessados nos detalhes operacionais do dia-a-dia
do sistema). Esses usurios esto muitas vezes mais interessados em: de que dados
precisamos para nossos negcios? Como esses dados se relacionam com outros dados? A
quem pertencem os dados? Quem est autorizado a ter acesso a esses dados?
Algumas dessas perguntas, acesso a dados e propriedade de dados, por exemplo, podem
ser da responsabilidade de um dedicado grupo dentro da organizao. O grupo de
administrao de dados (ou grupo de AD) muitas vezes responsvel pelo gerenciamento
e controle das informaes essenciais da empresa; sempre que for iniciar a construo de
um novo sistema de informaes voc precisar conversar com essas pessoas para poder
coordenar as informaes de seu sistema com o modelo global de informaes de nvel
empresarial de responsabilidade delas. O diagrama de entidades-relacionamentos uma
ferramenta de modelagem til para esses contatos.
Muitas vezes existe um outro grupo com o mesmo nome dentro da organizao: o grupo
de administrao do banco de dados (s vezes conhecido pelo nome de grupo de ABD ou
DBA). Esse grupo habitual mente est localizado dentro do departamento de PD (embora
o grupo de administrao de dados no esteja necessariamente localizado da mesma
maneira), e sua tarefa assegurar que os bancos de dados com putadorizados sejam
organizados, gerenciados e controlados de modo eficiente. Dessa forma, eles muitas
vezes formam a equipe de implemen tao responsvel por tomar um modelo essencial
(independente de uma tecnologia especfica) e traduzi-lo para um projeto de banco de
dados fisico eeaz e eficiente para o IMS, ADABAS, IDMS, TOTAL ou algum outro
sistema de gerenciamento de banco de dados, O diagrama de entidades-relacionamentos
uma eficaz ferramenta de modelagem para comunicao com o grupo de ABD. Com base
nas informaes apresentadas pelo DER, o grupo de administrao de bancos de dados
pode iniciar a verificao de que tipo de chaves, ndices ou ponteiros sero necessrios
para obter acesso eficiente aos registros dos bancos de dados.
290
Para o analista de sistemas o DER tambm um importante bene ficio: ele reala os
relacionamentos entre os depsitos de dados de um DFD que de outro modo s seriam
percebidos nas especificaes de processos. Por exemplo, um DER tpico mostrado na
figura 12.1. Cada um dos retngulos corresponde a um depsito de dados de um DFD
(essa correspondncia ser examinada mais adiante, no captulo 14) e pode-se ver que
existem relacionamentos (conexes) que normalmente no seriam vistos em um DFD.
Isso se deve ao fato de que o DFD focaliza a ateno do leitor para as funes que o
sistema executa e no para os dados de que ele necessita.
Consideremos um caso extremo: e se no houvesse funes a executar? E se o propsito
do sistema em construo no fosse fazer alguma coisa, mas apenas ser o repositrio de
um grande volume de informaes de interesse? Um sistema assim poderia ser chamado
de sistema de consultas ad hc ou sistema de apoio a decises. Em tal sis tema, podemos
nos concentrar inteiramente no modelo de dados sem nem mesmo nos preocuparmos na
elaborao do modelo de DFD orien tado para as funes. Essa situao , de fato, muito
rara: a maioria dos sistemas tem funes a serem executadas; com freqncia
descobrimos que construir o modelo de dados em primeiro lugar facilita descobrir quais
so as funes necessrias.
Naturalmente que a notao do DER da figura 12.1 inteiramente misteriosa por
enquanto. Nas prximas sees examinaremos a estrutura e os componentes de um DER;
depois discutiremos diretrizes para dese nharmos um DER bem estruturado. A notao
apresentada neste captulo
REP. DE VENDAS
Figura 12.1: Um diagrama de entidades-relacionamentos tpico
291
deriva de LFlavin, 19811 e semelhante notao desenvolvida por [ 19761, [ 19821,
[ 19861 e outros.
12.1 OS COMPONENTES DE UM DER
Os quatro principais componentes de um diagrama de entidades-
relacionamentos 5
1. Tipos de objetos
2. Relacionamentos
3. Indicadores associativos de tipos de objetos
4. Indicadores de supertipos/subtipos
12.1.1 Tipos de Objetos
Um tipo de objeto representado por um retngulo em um diagra ma de entidades-
relacionamentos; a figura 12.2 mostra um exemplo. Ele representa uma coleo ou um
conjunto de objetos (coisas) do mundo real cujos membros individuais (exemplares ou
instncias) tm as seguintes caractersticas:
Cada um deles s pode ser identificado de uma nica forma. Existe algum modo de
diferenar as instncias individuais do tipo de objeto. Por exemplo, se tivermos um tipo
de objeto cha mado de CLIENTE, precisamos ser capazes de distinguirmos um cliente de
outro (talvez por um nmero de conta, pelo ltimo sobrenome ou pela inscrio no
INPS). Se todos os clientes fo rem iguais (no caso de uma empresa cujos clientes sejam
pes soas desconhecidas que entram e fazem compras), CLIENTES ser um tipo de objeto
sem significado.
CLIENTE
Figura 12.2: Um tipo de objeto
292
Cada um exerce um papel no sistema em construo. Isto , para que o tipo de objeto
seja legtimo necessrio que o sis tema no possa funcionar sem acesso aos membros
desse tipo de objeto. Se estivermos desenvolvendo um sistema de entrada de pedidos para
nossa loja, por exemplo, pode ocorrer-nos que, alm dos clientes, a loja tem um grupo de
serventes, cada um dos quais identificado individualmente pelo nome. Embora os
serventes, presumivelmente, exeram um papel til na loja, o sistema de entrada de
pedidos pode funcionar perfeitamente sem eles, portanto, eles no merecem ter um papel
de tipo de objeto no modelo de nosso sistema. Obviamente, isso algo que deve ser
confirmado com os usurios quando voc estiver construindo o modelo.
Cada um pode ser descrito por um ou mais elementos de dados.
Desse modo, um CLIENTE pode ser descrito por esses elemen tos de dados pelo nome,
endereo, limite de crdito e nmero do telefone. Muitos livros sobre bancos de dados
descrevem isso como sendo atribuio de elementos de dados a um tipo de objeto.
Observe que os atributos devem se aplicar a cada ins tancia do tipo de objeto; por
exemplo, cada cliente deve ter um nome, endereo, limite de crdito, nmero dc telefone,
e assim por diante.
Em muitos dos sistemas que desenvolvemos, os tipos de objetos sero a representao de
uma coisa material do mundo real. Desse modo, objetos tpicos so clientes, itens de
inventrio, empregados, peas fabricadas e coisas semelhantes. O objeto a coisa
material do mundo real, e o tipo de objeto a representao no sistema. Entretanto, um
objeto tambm pode ser imaterial: escalas, planos, padres, estrat gias e mapas so
apenas alguns exemplos.
Como pessoas so muitas vezes tipos de objetos em um sistema, lembre-se de uma outra
coisa: uma pessoa (ou, para este assunto, qual quer outra coisa material) pode representar
vrios tipos diferentes de objetos em modelos de dados diferentes ou at no mesmo
modelo de dados. Jos da Silva, por exemplo, pode ser um EMPREGADO em um
modelo de dados e um CLIENTE em um outro modelo; ele poderia ser tambm um
EMPREGADO e um CLIENTE no mesmo modelo de dados.
Observe que em todos os exemplos de objetos, utilizamos a forma singular de um
substantivo (empregado, cliente). Isso no obrigatrio, mas uma conveno til.
Como veremos no captulo 14, existe uma correspondncia entre os objetos do DER e os
depsitos do DFD; assim, se existe um objeto CLIENTE no DER, deve haver um
depsito CLIENTES no DFD.
293
1
12.1.2 Relacionamentos
Os objetos so interligados por relacionamentos. Um relaciona mento representa um
conjunto de conexes entre objetos e representa do por um losango. A figura 12.3
mostra um relacionamento simples que pode existir entre dois ou mais objetos.
Figura 12.3: Um relacionamento
importante reconhecer que o relacionamento representa um conjunto de conexes.
Cada instncia do relacionamento representa uma associao entre zero ou mais
ocorrncias de um objeto e zero ou mais ocorrncias de outro objeto. Dessa forma, na
figura 12.3, o relacio namento rotulado COMPRA pode conter as seguintes instncias
individuais:
instncia 1: cliente 1 compra item 1
instncia 2: cliente 2 compra iteris 2 e 3
instncia 3: cliente 3 compra item 4
instncia 4: cliente 4 compra itens 5, 6 e 7
instncia 5: cliente 5 no compra itens
instncia 6: clientes 6 e 7 compram item 8
instncia 7: clientes 8, 9 e 10 compram itcns 9, 10 e 11
etc.
Assim, como se pode ver, um relacionamento pode interligar duas
ou mais instncias do mesmo objeto.
Observe que o relacionamento representa alguma coisa que deve ser recordada pelo
sistema - alguma coisa que no pode ser calculada ou derivada mecanicamente. A&m
sendo, nosso modelo de dados da figura 12.3 indica que existe alguma importante razo
relativa ao usurio
294
para recordar o fato de que o cliente 1 compra o item 1 etc. O relacio namento tambm
indica que no h nada a priori que nos permitisse determinar que o cliente 1 comprasse o
item 1 e nenhum outro item. O relacionamento representa a memria do sistema (um
objeto tambm representa a memria do sistema, claro).
Observe tambm que pode haver mais de um relacionamento entre dois objetos. A figura
12.4, por exemplo, mostra dois diferentes relacio namentos entre um PACIENTE e um
MDICO. primeira vista, voc poderia pensar que isso insistir no bvio: a cada vez
que o mdico atende o paciente ele cobra alguma coisa desse mesmo paciente. Mas a
figura 12.4 sugere que a situao pode ser diferente; ela pode revelar, por exemplo, que
existem diversas instncias diferentes de um tra tamento entre um mdico e o mesmo
paciente (uma consulta inicial, as consultas subseqentes etc.). A figura 12.4 mostra
tambm que o rela cionamento de cobrana totalmente separado do relacionamento de
consulta: alguns pacientes talvez s sejam cobrados pela primeira con sulta, enquanto
outros o sejam em cada consulta, e outros ainda talvez nunca sejam cobrados.
Uma situao mais corriqueira haver mltiplos relacionamentos
entre mltiplos objetos. A figura 12.5 mostra o relacionamento que
Figura 12.4: Mltiplos relacionamentos entre objetos
295
tipicamente existe entre um comprador, um vendedor, um corretor imveis, o
representante do comprador e o representante do vende para a compra e venda de uma
casa.
Em um diagrama complexo como o da figura 12.5 (que tpico no mais simples, dos
DER que voc provavelmente encontrar em jetos reais), o relacionamento e seus tipos
de objetos interligados de ser udos em conjunto. O relacionamento pode ser descrito do
ponto vista de qualquer dos tipos de objetos participantes, e todos esses por de vista so
vlidos. Na verdade, o conjunto desses pontos de vista descreve de maneira completa o
relacionamento. Por exemplo, na fig 12.5 podemos ler o relacionamento negocia preo
em qualquer das maneiras seguintes:
1. Corretor de imveis negocia preo entre compradoi vendedor.
2. Comprador negocia preo com vendedor por intermdio corretor de imveis.
3. Vendedor negocia preo com comprador por intermdio corretor de imveis.
Figura 12.5: Mltiplos relacionamentos entre mltz objetos
Observe que, em alguns casos, podemos ter relacionamentos cn diferentes instncias do
mesmo tipo de objeto. Imagine, por excmp um sistema em desenvolvimento por uma
universidade, no qual CURS ESTUDANTE E PROFESSOR sejam tipos de objctos. A
maioria d
296
relacionamentos em que vamos nos concentrar est entre instncias de diferentes tipos de
objetos (p.ex. inscreve-se, ensina etc.). Entretanto, podemos precisar modelar o
relacionamento pr-requisito para entre uma instncia e outra de CURSO.
12.1.3 Notao Alternativa para Relacionamentos
Como vimos na seo 12.1.2 os relacionamentos no diagrama E-R so multidlreciona
podem ser udos em qualquer direo. Vimos tam bm que o diagrama E-R no apresenta
cardinalidade, isto , no mostra o nmero de objetos que participam de um
relacionamento. Isso algo consciente e deliberado: prefervel colocar esses detalhes no
dicionrio de dados. Isso ser discutido na seo 12.3.
Uma notao alternativa usada por alguns analistas de sistemas mostra tanto a
cardinalidade como a ordinalidade. Por exemplo, a figura 12.6(a) mostra um
relacionamento entre CLIENTE e ITEM no qual a notao adicional indica que
(1) O CLIENTE o ponto dc fixao, o objeto principal de cujo ponto de vista ser lido o
relacionamento 2
(2) O relacionamento consiste em um cliente interligado a N itens. Isto , um cliente
individual pode comprar O, 1, 2, ... ou N itens. Entretanto, o relacionamento indica que
apenas um cliente pode estar envolvido em cada instncia de um relacionamento. Isso
impediria, por exemplo, o caso em que vrios clientes estejam envolvidos na compra do
mesmo item.
Ii NI
Cliente. Item
Figura 12.6 (a): Notao de ponto defira o para diagramas E-R
Outra notao de uso comum mostrada na figura 12.6(b); a seta de ponta dupla
utilizada para indicar um relacionamento um-para- muitos, enquanto a seta de ponta
singela empregada para indicar rela cionamentos um-para-um entre objetos.
compra
ClienteItem
Figura 12.6 (b): Notao alternativa para relacionamentos um-para-muitos
297
Diagramas E-R assim so discutidos detalhadamente em [ 1976], [ 1982] e lDate, 19861.
Entretanto, eu prefiro no incluir esses detalhes porque eles podem ser facilmente
includos no dicionrio de dados (como pode ser visto na seo 12.4), e eles favorecem o
desvio da ateno do propsito principal do diagrama E-R, que dar uma viso geral dos
componentes de um sistema e das interfaces entre os elemen tos de dados desse mesmo
sistema. Apesar de no haver nada intrinseca mente errado com anotaes procedurais no
diagrama, minha experin cia ensina que os analistas de sistemas muitas vezes levam
uma boa idia longe demais e sobrecarregam o diagrama com muito mais informaes do
que seria adequado.
12.1.4 Indicadores de Tipos de Objetos Associativos
Uma notao especial em diagramas E-R o indicador de tipos de objeto associativos;
ele representa alguma coisa que funciona tan to como um objeto quanto como um
relacionamento. Outro modo de encarar o tipo de objeto associativo considerar que ele
represen ta um relacionamento sobre o qual queremos manter algumas informaes .
Considere, por exemplo, o caso simples de um cliente que compra um item (ou itens),
representado na figura 12.6. No importando se inclumos a anotao procedural ou no,
o importante que o relacio namento de COMPRA nada mais faz do que associar um
CLIENTE e um ou mais ITEM (NS). Mas, suponha que existam alguns dados que
desejamos lembrar sobre cada instncia de uma compra (ex.: a hora do dia em que ela
ocorreu). Onde poderamos armazenar essa informao? Hora do dia no certamente
um atributo de CLIENTE nem de ITEM. Em vez disso, atribumos hora do dia
prpria compra e a mostramos em um diagrama como o da figura 12.7.
klgura 12.7: Um indicador de tipo de objeto associativo
298
Observe que COMPRA agora escrita dentro de um retngulo e que est ligada por uma
linha direta a um losango sem nome de relacio namento. Isso serve para indicar que
COMPRA funciona como:
Um tipo de objeto, alguma coisa sobre a qual queremos armaze nar informaes. Neste
caso, queremos lembrar a hora em que ocorreu a compra e o desconto oferecido ao
cliente (novamente se presume que tais informaes no podem ser derivadas pelo
sistema depois do fato ocorrido).
Um relacionamento interligando os tipos de objetos CLIENTE e rFEM. O importante
aqui que CLIENTE e ITEM permanecem
como esto. Eles existiriam ocorrendo ou no uma compra .
Por outro lado, uma COMPRA depende obviamente de CIJENTE e
de ITEM para sua prpria existncia. Ela s passa a existir como resulta do de um
relacionamento entre os objetos aos quais ela est interligada.
O relacionamento na figura 12.7 foi deliberadamente deixado sem nome. Isso se deve ao
fato de o indicador do tipo de objeto associativo
(COMPRA) ser tambm o nome do relacionamento.
12.1.5 Indicadores de Subti
Os tipos de objetos subtipo/supertipo consistem em um objeto e uma ou mais
subcategorias, interligados por um relacionamento. A figu ra 12.8 t um subtipo/supertipo
tpico: a categoria geral EM PREGADO e as subcategorias so EMPREGADO
ASSALARIADO e EMPREGADO HORRIO. Observe que os subtipos so interligados
ao supertipo por meio de um relacionamento sem nome; note ainda que o supertipo
interligado ao relacionamento por uma linha cortada por uma pequena barra.
Nessa notao o supertipo descrito por elementos de dados que
se aplicam a todos os subtipos. Por exemplo, na figura 12.8, podemos
imaginar que todos os empregados so descritos por:
Nome
Anos de servio
Endereo
Nome do supervisor
299
Figura 12.8: Um indicador de supertzpo/sub:ipo
Entretanto, cada subtipo descrito por diferentes elementos de dados; caso contrrio,
nada haveria que os pudesse distinguir. Por exem plo, podemos imaginar que um
EMPREGADO ASSALARIADO seja des crito por:
Salrio mensal
Percentagem anual de bnus
Total permitido para o carro da empresa E o EMPREGADO HORRIO fosse descrito
por:
Salrio horrio
Valor da hora extra
Hora de incio
12.2 DIRETRIZES PARA A CONSTRUO DE DIAGRAMAS DE ENTIDADES-
RELACIONAMENTOS
A notao mostrada na se anterior suficiente para cons trujr diagramas de entidades-
relacionamentos arbitrariamente com plexos. Entretanto, voc pode estar se perguntando:
Como saber quais objetos e relacionamentos esto em primeiro lugar?. Seu modelo
inicial
300
de tipos de objetos e relacionamentos derivar habitualmente de (1) seu conhecimento da
aplicao do usurio, (2) entrevistas com o usurio e (3) alguma outra pesquisa e coleta
de dados que voc faa (as tcnicas para entrevistas e coleta de dados so discutidas no
apndice E).
Voc no deve esperar que o primeiro diagrama de E-R que voc desenhar ser uma
verso final que ser revista com a comunidade usuria ou que ser entregue aos
projetistas de sistemas. Assim como os diagramas de fluxos de dados e todas as outras
ferramentas de modela gem de sistemas, os diagramas de E-R devem ser revistos e
aperfeioa dos vrias vezes. A primeira verso ser normalmente nada mais que um
esboo, e as verses subseqentes sero produzidas com a utilizao de uma srie de
diretrizes de refinamento apresentadas nesta seo. Algu mas das diretrizes de
refinamento conduziro criao de tipos de obje tos adicionais, enquanto outras levaro
eliminao de tipos de objetos e/ou de relacionamentos.
12.2.1 A Incluso de T de Objetos Adicionais
Como dito acima, seu DER inicial ser normalmente criado a partir de entrevistas iniciais
com o usurio e de seu conhecimento do ramo da empresa do usurio. Isso, naturalmente,
proporcionar-lhe- uma boa indicao de como identificar os principais objetos e
relacionamentos
Aps o desenvolvimento da verso inicial do DER, a etapa seguinte a ser executada a
de designar os elementos de dados do sistema aos diversos tipos de objetos. Isso
naturalmente presume que voc conhea quais so os elementos de dados! Isso pode
ocorrer em uma de trs maneiras:
1. Se o modelo do processo (DFD) j foi desenvolvido ou estiver sendo desenvolvido em
paralelo com o modelo de dados, ento j existe um dicionrio de dados. Ele pode ainda
no estar completo, mas ser suficiente para se dar incio ao processo de designaes.
2. Se o modelo do processo no foi desenvolvido (ou, no caso extremo, voc no
pretende desenvolver um), ento voc ter de comear a entrevistar todos os usurios
apropriados para elaborar uma lista completa de elementos de dados (e suas definies).
Ao termin-la, voc pode atribuir os elementos de dados para os objetos do diagrama E-R
(entretanto, observe que isso um processo bottom-up que consome muito tempo e que
pode causar atrasos e frustraes).
301
3. Se voc estiver trabalhando com um grupo de administrao de dados ativo, h uma
boa possibilidade de que o dicionrio de dados j exista. Voc poder receb-lo logo nas
etapas iniciais do projeto, a partir de quando voc poder iniciar o processo de
designaes.
O processo de designaes pode apresentar um destes trs motivos para a criao de
novos tipos de objetos:
1. Voc pode descobrir elementos de dados que podem ser desig nados para algumas
instncias de um tipo de objeto, mas n
para outros.
2. Voc pode descobrir alguns elementos de dados que sejam apli cveis a todas as
instncias de dois objetos diferentes.
3. Voc pode descobrir que alguns elementos de dados descrevem relacionamentos entre
outros tipos de objetos.
Se, durante o processo de designao de elementos de dados a tipos de objetos, voc
descobrir que alguns elementos de dados no podem ser aplicados a todas as instncias dc
um tipo de objeto, voc precisar criar um conjunto de subtipos abaixo do tipo de objeto
com que voc est trabalhando e designar aqueles elementos de dados aos subtipos
adequados.
Suponha, por exemplo, que voc esteja desenvolvendo um sis tema de pessoal, e
identificou (com extraordinrio brilho e criatividade!) um tipo de objeto chamado
EMPREGADO. Ao revisar os elementos de dados disponveis, voc descobriu que
muitos deles (Idade, altura, data-de-admisso etc.) so aplicveis a todas as instncias de
um empregado. Entretanto, posteriormente voc descobre um elemento de dado chamado
nmero-de-gravidezes; isso , evidentemente, um ele mento de dado importante para
empregados mulheres mas no para empregados homens. Isso o levaria a criar
EMPREGADO-HOMEM e EMPREGADO-MULHER como subtipos para a categoria
geral de empregado.
Obviamente, no estou sugerindo que todos os sistemas de pes soal devam controlar o
nmero de gravidezes que cada empregado teve; o exemplo foi escolhido apenas porque
do consenso geral que os empregados homens no podem engravidar. Compare isso, no
en tanto, com o elemento de dado nome-do-cnjuge: existem diversas instncias de
EMPREGADO para as quais nome-do-cnjuge talvez no possa (N.T.: no original may
not) se aplicar (porque no esto presentemente casados), mas esta uma situao muito
diferente da de
302
um elemento de dado que no pode (NT.: no original cannot) ser aplicado 6
Na maioria dos casos, o processo de criao dc novos subtipos e de designao de
elementos de dados de forma apropriada muito direto. Entretanto, lembre-se de uma
exceo: pode ocorrer que lodos os elementos de dados relevantes sejam designados para
um dos subtipos e que nenhum desses elementos de dados possa ser designado para o
objeto supertipo; isto , pode ocorrer que os elementos de dados sejam mutuamente
exclusivos, pertencendo a um subtipo ou a outro, mas no a ambos. Suponha que os
nicos elementos de dados que podemos designar para empregados sejam nmero-de-
gravidezes e anos-de-ex perinc lorque. Poderamos decidir com razo (depois de
imaginar que tipo de luntico seria o usurio responsvel por tal sistema!) que o supertipo
geral de EMPREGADO no aplicvel.
A situao oposta tambm pode ocorrer: os elementos dc dados podem descrever
instncias de dois (ou mais) diferentes tipos de objetos do mesmo modo. Se isso ocorrer,
ser preciso criar um novo supertipo e designar os elementos de dados comuns para o
superupo. Por exemplo, podemos ter identificado ClIENTE-DINHEIRO e ClIENTE-
CARTO- DE-CRDITO como dois tipos de objetos distintos ao elaborarmos o pri
meiro DER para um sistema dc entrada dc pedidos (talvez porque o usurio nos tenha
dito que eram duas categorias distintas). Entretanto, pode logo tornar-se evidente que os
elementos de dados nome-do- cliente e endereo-do-cliente descrevem ambos os tipos de
cliente da mesma forma; isso levaria criao dc um supertipo, como mostrado na figura
12.9.
De modo semelhante, se um elemento de dados descrever a
interao de um ou mais tipos de objetos, devemos substituir o
CLIENTE DE CLIENTE A
CARTAO DE DINHEIRO
CRDITO ____________
Figura 12.9: Criao de um novo objeto superlipo/subtipo
303
relacionamento nu entre os dois objetos por um tipo de objete as sociativo. Examine,
por exemplo, o DER de primeira verso mostrado na figura 12.10(a) na qual existe o
relacionamento COMPRA entre CLIENTE e 1TEM. Durante a designao dos elementos
de dados, po demos descobrir que h um elemento dc dado chamado data-da-compra que
(1) parece pertencer ao relacionamento COMPRA e (2) obviamente descreve, ou fornece
dados sobre, a interao de um CLIENTE e um ITEM. Isso sugere que deveramos
substituir o relacionamento COMPRA por um tipo de objeto associativo, como se v na
figura 12.10(b).
CLIENTE ITEM
Figura 12.10 (a): Um diagrama de E-R inicial
Figura 12.10 (b): Substituio dc um relacionamento por um tipo de objeto
associativo
Por vezes o diagrama dc E-R inicial contm um tipo de objeto que em melhor anlise
merece ser um tipo dc objeto associativo. Por exem plo, a figura 12.11(a) mostra um
diagrama de l com trs objetos rela cionados entre Si: CLIENTE, PEDIDO e PRODUTO.
I)urante o processo de designao de elementos dc dados para os diversos objetos,
descobri mos que data-da-entrega deve pertencer ao objeto PEDIDO; afinal, os clientes
no so entregues e os produtos s so entregues como resul tado de um pedido. Na
verdade, o raciocnio sobre isso torna evidente que PEDIDO um relacionamento entre
CLIENTE e PRODUTO, bem como um objeto sobre o qual desejamos memorizar certos
fatos. Isso nos leva figura 12.11(b).
Por fim, temos o caso dos grupos repetitivos. Considere, por exem plo, O tipo de objeto
EMPREGADO, com elementos de dados bvios como nome e endereo. Agora suponha
que encontramos os elementos de dados adicionais nome-do-filho, idade-do-filho e sexo-
do-filho. Pode-se argumentar que nome-do-filho, idade-do-filho e sexo-do- filho sejam
maneiras de se descrever um novo tipo de objeto chamado
304
FILHO, que inadvertidamente foi embutido anteriormente em EMPREGADO. Tambm
se poderia argumentar que existem (po tencialmente) mltiplas instncias de informaes
relativas a filhos asso ciadas a cada instncia de um empregado e que cada instncia de in
formaes relativas a filhos identificada de forma exclusiva por nome- do-filho. Nesse
caso, o tipo de objeto que idealizamos inicialmente sob a forma mostrada na figura
12.12(a) deve ser transformado em dois tipos de objetos, interligados por um novo
relacionamento, como se pode ver na figura 12.12(b).
Figura 12.12 (a): Viso inicial de um objeto
Figura 12.11 (a): Um diagrama de E-R inicial
Figura 12.11 (b): Um objeto transformado em objeto associativo
EMPREGADO FILHO
305
Figura 12.12(b): Diagrama de E-R revisto
Esse processo de remoo de objetos embutidos parte de uma atividade de refinamento
mais abrangente conhecida como normaliza o, O objetivo da normalizao produzir
tipos de objetos em que cada instncia (ou membro) consiste em um valor de chave
primria que identifica alguma entidade, juntamente com um conjunto de valores de
atributos mutuamente independentes que descrevem aquela entidade de algum modo, O
processo dc normalizao descrito cm detalhes no captulo 14 de [ 19861 e no captulo
19 dc IDeMarco, 19781.
12.2.2 A Supresso dc Tipos de Objetos
A seo anterior tratou dc refinamentos cm DER que criam objetos e/ou relacionamentos
adicionais. Entretanto, existem algumas situaes em que o refinamento do DER conduz
supresso de tipos de objetos e relacionamentos redundantes ou errneos. Vamos
examinar quatro si tuaes comuns:
1. Tipos de objetos compostos por apenas um identificador
2. Tipos de objetos para os quais existe apenas uma instncia
306
3. Tipos de objetos associativos alternativos
4. Relacionamentos derivados
Se houver um diagrama dc E-R no qual um dos tipos dc obje tos tem apenas um ident a
ele designado como elemento dc da do, pode haver uma oportunidade dc se eliminar o
tipo de objeto e de signar o identificador como um elemento dc dado cm um tipo dc ob
jeto relacionado. Por exemplo, imaginemos que construmos um dia grama de E-R inicial
como mostrado na figura 12.13(a) para um sistema de pessoal:
EM PREGADO
ado com
CNJUGE
Figura 12.13(a): Um diagrama de E-R inicial
Durante o processo de designao de elementos de dados para os diversos objetos,
entretanto, podemos descobrir que a nica informao que o sistema de pessoal conserva
sobre um cnjuge o nome (isto , o identificador que distingue um cnjuge de todos os
outros cnjuges no sistema). Nesse caso, um refinamento bvio eliminar CNJUGE
como tipo de objeto e incluir nome-do-cnjuge como elemento de dados no objeto
EMPREGADO.
Observe que esse refinamento s faz sentido quando existe uma correspondncia de um-
para-um entre as instncias do objeto a ser elimi nado e as instncias do objeto que lhe
seja relacionado. O exemplo imediatamente acima faz sentido porque a sociedade
moderna presume
307
que uma pessoa dcva ter, no mximo, um cnjuge, o que nos conduz ao diagrama dc E-R
reduzido da figura 12.13
L EMPREGAD
Figura 12.13(b): Um diaRrama de E-R reduzido
Podemos obter uma reduo ainda maior se descobrirmos que nosso diagrama de E-R
inicial contm um objeto para o qual o nico fato o identificador e que um objeto de
uma nica instncia Considere o diagrama de E-R inicial most.rado na figura l
Figura 12.14 (a): Um diagrama de E-R inicial
primeira vista, parece ser um modo razovel de mostrar o relacionamento entre
pacientes e remdios (ou drogas, medicinais, claro!) em um hospital. Mas, suponha que
a nica informao que temos sobre o remdio seja seu nome (identificador); e imagine
que o hospital administra apenas um lipo de droga (ex.: aspirina), Nesse caso, o rem dio
uma constante e nem mesmo precisa aparecer no diagrama (obser ve que isso tambm
significa que nosso sistema no ter um depsito
308
chamado remdios). O diagrama reduzido ficaria como o da figura 12.14(b).
Figura 12.14 (b): Diagrama de E-R reduzido
Tendo cm vista a situao acima, possvel criar um tipo de obje to associativo
alternativo. Considere a seguinte variao do exemplo anterior do hospital, como
mostrado na figura 12.15(a). Se, como acima sugerido, REMDIO for um objeto
somente identificador e dc instncia nica, deve ser eliminado. Isso daria como resultado
o diagrama reduzido mostrado na figura 12.15(1i); observe que TRATAMENTO ain da
um tipo de objeto associativo, apesar de estar interligado a somente um outro tipo de
objeto. Isso conhecido como um tipo de objeto associativo alternativo e inteiramente
vlido (embora um tanto inco mum) em um DER.
Finalizando, os relacionamentos que possam ser derivados, ou cal culados, devem ser
removidos do diagrama de E-R inicial. Como j foi dito neste captulo, o DER deve
mostrar os requisitos dc dados armaze nados. Desse modo, na figura 12.16(a), se o
relacionamento renova en tre MOTORISTA e LICENA puder ser derivado (com base na
data de aniversrio do motorista, ou na primeira letra de seu ltimo nome ou em
PACIENTE
Figura 12.15 (a): Um dw rama de E-R inicial
309
Figura 12.16(b): O DER reduzido
qualquer critrio que seja utilizado pelo DETRAN), deve, ento, ser eliminado. Isso nos
conduz figura 12.16 na qual os tipos de objetos no so interligados. Isso inteiramente
vlido em um DER; no ne cessrio que todos os upos de objetos se interliguem.
12.3 EXTENSES AO DICIONRIO DE DADOS PARA DIAGRAMAS DE E-R
Para finalizar, observamos que o dicionrio de dados discutido no
captulo 10 precisa ser estendido para que seja includa a notao para o
Figura 12.15 (b): O diagrama de E-R reduzido
Figura 12.16 (a): Um ERD inicial
MOTORISTA
LICENA
310
DER discutida neste captulo. Em geral, os objetos do DER correspondem aos depsitos
do DFD; o captulo 14 apresenta mais detalhes sobre este assunto. Isso significa que na
definio de dicionrio de dados abaixo, CLIENTE tanto uma definio do tipo de
objeto como uma instncia do depsito CLIENTES.
CLIENTES - (CLIENTE)
CLIENTE - @NC*4E-DO--CLIENTE + ENDEREO + NM TZr
Observe tambm que a definio de um CLIENTE inclui uma espe cificao do campo
de chave, que o elemento de dado (ou atributo)
que distingue uma instncia de um cliente de outra, O smbolo arroba
(@) utilizado para indicar o(s) campo(s) chave(s) .
Contudo, tambm precisamos incluir no dicionrio de dados uma definio de todos os
relacionamentos mostrados no DER. A definio dos relacionamentos deve incluir a
descrico do significado do relacio namento, dentro do contexto da aplicao; e deve
indicar os objetos que compem a associao. Devem ser especificados adequados
limites superior e inferior para indicar se a associao do tipo um-para-um, um-para-
muitos ou muitos-para-muitos. Por exemplo, o relacionamento compra mostrado na
figura 12.10(a) poderia ser definido no dicionrio de dados da seguinte maneira:
compra - *a associao de um cliente e um ou mais
itens *
@id-cli.c + 1 { @id-item + quantidada-com
prada
12.4 RESUMO
O DER pode ser uma valiosa ferramenta para qualquer sistema com mltiplos depsitos
(objetos) e complexos relacionamentos de dados. Como vimos neste captulo, ele
inteiramente voltado para os re lacionamentos de dados, sem oferecer quaisquer
informaes sobre as flsnes que criam ou utilizam os dados.
Embora tenhamos utilizado o DER neste livro como ferramenta de modelagem grfica
para mostrar os relacionamentos de dados, voc de ve estar cnscio de que vrias outras
ferramentas de modelagem so usadas para o mesmo fim; [ 1982] e [ 1986] mostram
muitos exemplos de ferramentas alternativas de modelagem.
Neste ponto, muitos estudantes perguntam se o DFD deve ser
desenvolvido antes do DER, ou se melhor desenvolver primeiro o DER
311
e depois o DFD. Na realidade, alguns estudantes indagam at se de fato necessrio
desenvolver ambos os modelos, uma vez que tanto o DFD como o DER oferecem tantas
informaes de interesse. A resposta primeira pergunta simples: no importa qual seja
o modelo desenvol vido em primeiro lugar. Dependendo de suas prprias preferncias ou
das preferncias do usurio, ou da natureza do prprio sistema (isto , se ele rico em
funes ou rico em dados), um dos modelos muitas vezes se evidenciar como devendo
ser desenvolvido primeiro. Em outros casos, entretanto, voc perceber que ambos devem
ser desenvolvidos concorrentemente; isso especialmente comum quando a equipe de
projeto contm um grupo distinto de projeto de bancos de dados, ou quando o setor de
PED tem um grupo dc administrao de dados que desenvolve modelos consolidados de
dados.
A segunda pergunta mais importante; realmente importante desenvolver dois
diferentes modelos de um sistema (e, como veremos no captulo 13, um terceiro modelo,
o do comportamento tempo- dependente do sistema)? A resposta que isso depende do
tipo do sistema que se esteja desenvolvendo. Muitos dos clssicos sistemas comerciais de
processamento de dados desenvolvidos nos anos 60 e 70 aparentavam (pelo menos
superficialmente) consistir em muitas fun es complexas, mas com estruturas de dados
relativamente triviais; desde ento foi enfatizado o DFD, enquanto o DER foi muitas
vezes ignorado. De maneira inversa, muitos dos sistemas de apoio deciso e sistemas de
consulta a bancos de dados ad hoc construdos nos anos 80 aparentavam (pelo menos
superficialmente) ser compostos por complexos relacionamentos de dados, mas quase
sem atividades funcionais; a partir da foi enfatizado o l)ER e um tanto relegado o DFD.
As caractersticas temporais dos sistemas de tempo-real constru dos nos anos 60 e 70
pareciam (pelo menos superflcialmcnte) domi nar quaisquer consideraes sobre funes
e relacionamentos de dados. Nesses sistemas o modelo de transies de dados (discutido
no captulo 13) foi muitas vezes enfatizado a ponto de excluir os DFD e I)ER.
Os sistemas do final da dcada de 80 e dos anos 90, entretanto, ten dem a ser muito mais
complexos do que OS sistemas de emprego geral de uma ou duas dcadas passadas; na
verdade, muitos deles so de 100 a 1.000 vezes maiores e mais complexos. Muitos desses
sistemas grandes e complexos tm funes e relacionamentos e comportamento tempo-
dependente incrivelmente complexos; considere, por exemplo, o siste ma Star Wars, que
se estima necessitar de 100 milhes de instrues de processamento e que ter um
comportamento de tempo-real de espanto sa complexidade. Para sistemas assim to
complexos, bvio que todas as trs ferramentas de modelagem discutidas neste livro
sero critica mente importantes. Por outro lado, se voc estiver envolvido em um sim ples
sistema unidimensional, voc talvez decida que pode se concentrar
312
na ferramenta de modelagem que ilumina e reala o aspecto mais importante do sistema.
No captulo 14 veremos como o DER, o DFD, o diagrama de tran sies de estado, a
especificao de processos e o dicionrio de da dos podem ser verificados um em relao
aos outros para que se possa produzir um completo modelo do sistema que seja
internamente consistente.
REFERNCIAS
1. Matt Flavin, Fundamental Concepts ofinformation Modeling Nova lorque:
YOURDON Press, 1981.
2. Peter Chen, The Entity-Relationship Model - Toward a Unified View of Data, ACM
Tran.sactions on Database Systems, Volume 1,
Nmero 1 (maro 1976), pgs. 9-36.
3. Peter Chen, Tbe Entlty-Relatonship Approach to Logical Database Design. Wellesley,
Mass.: Q.E.D. Information Sciences, 1977.
4. DC. Tsichritzis e F.H. Lochovsky, Data Modeis. Englewood Cliffs, N.J.: Prentice-Hall,
1982.
5. James Martin, Computer Database Oi Englewood Cliffs, N.J.: Prentice-Hall, 1982.
6. Proceedings ofthe International Conference on Data Engineering. Washington, D.C.:
IEEE Press, 1984.
7. C.J. Date, An Introduction to Database Systems, 4 ed. Reading, Mass.: Addison-
Wesley, 1986.
8. Sally Shlaer e Stephen Melior, Object-Oriented Systems Analysis:
Modeling the World in Data. Englewood Cliffs, N.J.: YOURDON
Press, 1988.
9. R. Veryard, Pragmatic Data Analysis. Oxford, U.K.: Blackwell Scientific Publications,
1984.
10. Jeffrey Ullman, Principies of Database Systems. Potomac, Md.:
Computer Science Press, 1982.
11. Tom DeMarco, StructuredAnalysis and System Spec Nova Torque: YOURDON
Press, 1978.
PERGUNTAS E EXERCCIOS
1. O que um diagrama de entidades-relacionamentos? Para que serve?
2. Por que um DER diferente de um diagrama de fluxo de dados?
3. Por que as pessoas se interessam por modelos de dados?
313
4. Que grupo alm dos analistas de sistemas pode criar modelos de dados em uma
empresa?
5. Por que o grupo de DBA de uma empresa normalmente interes sado em modelos de
dados?
6. Quais so os quatro principais componentes de um diagrama de entidades-
relacionamentos?
7. Qual a definio de um tipo de objeto?
8. Qual a diferena entre um objeto e um tipo de objeto?
9. Quais so os trs critrios que um tipo de objeto deve satisfazer?
:10 Que itens da lista abaixo podem ser tipos de objetos aceitveis em um sistema
comercial tpico? Para os que voc considerar como
no aceitveis, explique o porqu.
(a) cliente
(b) calcular imposto sobre vendas
(c) altura
(d) produto
(e) tomate
(f) religio
(& temperatura
(h) transao de edio
(i) pea fabricada
(j) mapa
(k) caracter ASCII
11. Qual a definio de relao?
12. Quantos tipos de objetos podem ser interligados por uma relao?
13. Que itens da lista abaixo podem ser considerados como relacio namentos em um DER
e quais no podem? Por qu?
(a) compra (verbo)
(b) cliente
(c) pertence a
(d) peso
(e) produz
(f) clculo do imposto sobre vendas
14. Qual a diferena entre um relacionamento derivado e um recor dado? Qual deles
mostrado em um DER?
15. D dois exemplos de relacionamento derivado entre dois objetos.
16. Quantos relacionamentos podem ex entre dois objetos em um
DER?
314
17. Examine o DER abaixo.
(a) Escreva uma descrio narrativa dos objetos e dos relaciona mentos.
(b) Quantas faturas podem existir entre uma instncia de fabri cante e uma instncia de
cliente?
(c) Quantos produtos um cliente pode comprar em uma instncia do relacionamento
compra?
18. Os DER apresentam cardinalidade?
19. Use a notao da figura 12.6 para mostrar uma verso aceitvel do diagrama da figura
12.5.
20. Que argumentos existem contra se mostrar ordinalidade e cardina lidade em um
DER?
21. Apresente uma notao alternativa para DER que mostre tanto a ordinalidade como a
cardinalidade.
22. Desenhe um DER que represente a seguinte situao para uma empresa de linhas
areas:
A empresa de linhas areas XYZ possui trs importantes recursos:
avies, pilotos e tripulantes. Os pilotos e os tripulantes tm suas res pectivas bases
domsticas, para as quais retornam aps um vo para o qual tenham sido designados. Um
vo deve ter pelo menos um piloto e um ou mais tripulantes escalados para um avio.
Cada avio tem uma base dc manuteno.
23. Desenhe um DER para descrever a seguinte situao de uma editora:
315
A ABC Press trabalha com diversos autores que escrevem os livros que ela publica.
Alguns autores escreveram apenas um livro, en quanto outros j escreveram muitos; alm
disso, alguns livros foram escritos em conjunto por vrios autores. A ABC tambm
trabalha com mltiplas impressoras; cada livro, portanto, impresso por apenas uma
impressora. Um editor da ABC Press trabalha com vrios autores ao mesmo tempo,
editando e produzindo os projetos de livros; tarefa do editor levar a cpia final para a
impressora quando o manuscrito est copieditado e composto.
24. Desenhe um DER para a seguinte situao de uma empresa de consultoria gerencial.
Cada representante de vendas trabalha com diversos clientes e tem acesso a diversos
consultores da empresa. Um contrato de consulto- ria com um cliente pode envolver
vrios consultores diferentes. Durante a vigncia do contrato, o vendedor no envolvido
e os consultores tratam diretamente com o cliente.
25. Desenhe um DER para a seguinte situao:
Um professor pode dar aulas a diversas classes, desde que ele ou ela esteja qualificado
para ensinar a matria. Cada classe deve ter um professor, mas pode ser freqentada por
vrios alunos. No incio de cada semestre as classes so designadas para as salas, uma
para cada classe, que ali comparece regularmente.
26. O que um tipo de objeto associativo?
27. O que um ponto de fixao?
28. D trs exemplos de tipos de objetos associativos.
29. Examine a figura 12.7. Suponha que no existam dados sobre a compra que o sistema
deva memorizar. Em que isso modificaria o
diagrama?
30. O que um subtipo/supertipo em um DER?
31. D trs exemplos de subtipos/supertipos.
32. Por que nos preocuparmos em termos subtipos/supertipos em um DER? No basta
termos os tipos comuns de objetos?
33. Que refinamentos o analista de sistemas deve esperar fazer depois de desenhar a
primeira verso de um DER?
34. Quais so os trs meios que o analista de sistemas possivelmente usar para descobrir
os elementos de dados em um modelo de
dados?
35. O que significa designao no contexto deste captulo?
36. Como o analista de sistemas deve continuar com o DER se o DFD j tiver sido
desenvolvido?
316
37. Quais so os trs motivos para criarmos tipos de objetos adicionais em um DER
depois que a primeira verso est pronta?
38. O que deve fazer o analista de sistemas se descobrir elementos de dados que podem
ser designados para algumas instncias de um
tipo de objeto mas no para outras?
39. O que deve fazer o analista de sistemas se descobrir elementos de dados que sejam
aplicveis a todas as instncias de dois difereni
tipos de objetos?
40. O que deve fazer o analista de sistemas se descobrir elementos de dados que
descrevem relacionamentos entre outros tipos de
objetos?
41. O que deve fazer o analista de sistemas se descobrir conjuntos repetitivos em um tipo
de objeto?
42. Descreva o que significa termos conjuntos repetitivos em um tipo de objeto. D um
exemplo.
43. Quais so os quatro bsicos comuns para se remover um tipo de objeto da primeira
verso de um DER?
44. O que um tipo de objeto associativo alternativo?
45. O que deve fazer o analista de sistemas se descobrir, na primeira verso de um DER,
um tipo de objeto constitudo por apenas um
identificador?
46. O que deve fazer o analista de sistemas se descobrir, na primeira verso de um DER,
um tipo de objeto do qual s h uma instncia?
47. O que deve fazer o analista de sistemas se descobrir, na primeira verso de um DER,
um relacionamento derivado?
48. Que extenses devem ser feitas ao dicionrio de dados para apoiar o DER?
49. O que significa a notao @ em um item do dicionrio de dados?
NOTAS
1 Entre os objetos podem existir outros relacionamentos que no so mostrados no DER.
Como o DER um modelo de dados armaze nados, os relacionamentos que podem ser
calculados ou derivados no aparecem ali. Considere, por exemplo, o objeto
MOTORISTA e o objeto LIcENA. Pode haver o relacionamento de data de re novao
entre os dois, que calculado em funo da data de nas cimento do motorista (o motorista
deve renovar sua licena a cada ano na data de seu aniversrio). Tal relacionamento no
deve ser mostrado no DER, por no ser um relacionamento de dados arma zenados.
Entretanto, se a data de renovao fosse escolhida alca toriamente, ela provavelmente
teria de ser lembrada pelo sistema.
2 A expresso ponto de fixao foi introduzida por IFlavin, 1981].
317
3 Alguns livros sobre bancos de dados referem-se a isso como dados de interseo.
4 Um purista poderia argumentar que isso no verdadeiro a longo prazo. Se no
houvesse ITEM(NS) por diversos dias na prateleira, os CLIENTE(S) desapareceriam de
cena e fariam suas compras em outro lugar. E se no houvesse CLIENTE(S) a loja
eventualmente fecharia e os ITEM(NS) desapareceriam. Mas na estvel situao a curto
prazo, bvio que os clientes e itens podem coexistir tranqilamente sem terem
necessariamente algo a ver uns com os outros.
5 Entretanto, provavelmente no identificar todos os relaciona mentos entre os objetos.
Dado um sistema com N objetos, a quanti dade de relacionamentos possveis
proporcional a N!, que nor malmente um nmero muito grande. Muitos dos
(teoricamente) relacionamentos possveis revelar-se-o como no tendo (1) um
significado legtimo em qualquer lugar do sistema ou (2) relevncia no contexto do
sistema em modelagem. Algum poderia imaginar, por exemplo, um sistema em que o
principal relacionamento entre clientes e o pessoal de vendas seja VENDE. Tambm pode
ocorrer de um cliente e um vendedor serem casados; ou que a vendedora seja filha do
cliente; ou que o cliente e o vendedor sejam colegas de escola. Tudo isso pode ser muito
interessante, mas no ser representado no modelo do sistema a menos que seja relevante.
6 Nesse exemplo obviamente estamos ignorando algumas excees obscuras. Ignoramos,
por exemplo, o caso de urna empregada que depois de trs gravidezes submeteu-se a uma
operao de mudan a de sexo. E, no caso do nome do cnjuge, supusemos que ne nhum
dos empregados sejam crianas menores de idade, para as quais o casamento
presumivelmente uma impossibilidade.
7 Alguns livros usam a conveno de sublinhar o(s) campo(s)
chave(s). Desse modo, poderamos definir cliente como
= nc* + andar + num
318
13
DIAGRAMAS
DE TRANSIES
DE ESTADO
Todos os corpos permanecem em estado de r ou em movimento
un segundo uma linha reta, a menos que sejam obrigados a modificar esse estado por
foras que lhes sejam aplicadas.
Sir Isaac Newton,
Philosopbtae Naturalts Princ Mathematica,
LeL do Movimento, 1, 1687
Neste captulo aprenderemos:
1. A notao para diagramas de transies de estado.
2. Como desenhar diagramas de transies de estado subdivididos.
3. Como elaborar um bom diagrama de transies de estado.
4. O relacionamento entre DTE e outros modelos.
Nos captulos anteriores vimos ferramentas de modelagem que realam as ftines
desempenhadas por um sistema e os dados armaze nados que o sistema deve memorizar.
Agora veremos um terceiro tipo de ferramenta de modelagem, o diagrama de transies
de estado (tam bm conhecido por DTE), que enfatiza o comportamento tempo-
dependente do sistema.
At bem pouco tempo, os modelos do comportamento tempo-
dependente de um sistema de um sistema somente eram importantes
para uma categoria especial de sistemas conhecidos como sistemas de
319
tempo-real. Exemplos desses sistemas (que discutimos superficialmente no captulo 2)
so controle de processos, sistemas de comutao telef nica, sistemas de obteno rpida
de dados e sistemas de comando e controle militares. Alguns desses sistemas so passivos
no sentido de que no procuram controlar o ambiente em que se encontram e, em vez
disso, reagem a ele e obtm dados sobre ele. Muitos Sistemas de obten o rpida de
dados pertencem a essa categoria (ex.: um sistema que obtm, em alta velocidade, dados
cientficos de um satlite). Outros sis temas de tempo-real so mais ativos, no sentido de
que buscam obter controle sobre algum aspecto do ambiente circundante. A essa
categoria pertencem os sistemas de controle de processos e diversos outros sis temas
embutidos.
Como voc pode imaginar, sistemas desse tipo lidam com fontes externas de dados de
alta velocidade e devem produzir respostas e da dos de sada com suficiente rapidez para
interagir com o ambiente exter no. Uma parte importante da especificao desses
sistemas a descrio do que acontece quando.
No caso dos sistemas orientados para o comrcio, esse problema no tem sido to
importante. As entradas podem chegar ao sistema de muitas fontes diferentes e em
velocidades relativamente altas, porm essas entradas podem habitualmente ser
retardadas se o sistema estiver ocupado com alguma outra coisa. Um sistema de
pagamento, por exem plo, no tem de se preocupar com interrupes nem com sinais de
uma unidade externa de radar. Em casos tpicos, os nicos problemas de tempo que
encontramos nesses sistemas so especificaes de tempo de resposta, que includo no
modelo de implementao do usurio, que veremos no captulo 21.
Entretanto, esto comeando a surgir alguns grandes e comple xos sistemas de orientao
comercial que tm aspectos de compor tamento tempo-dependente. Se o sistema lidar
com entradas prove nientes de milhares de terminais e com entradas de alta velocidade de
Outros sistemas ou de dispositivos de comunicao via satlite, ele poder ter o mesmo
tipo de problemas de dependncia do tempo que tem um clssico sistema de tempo-real.
Assim, embora voc no lide com tais problemas em todos os sistemas que construir,
voc deve se familiarizar com as ferramentas de modelagem para o comportamento
tempo-dependente.
13.1 A NOTAO PARA OS DIAGRAMAS DE TRANSIES DE ESTADO
Um diagrama tpico de transies de estado mostrado na figu ra l3.1(a) (embora ele seja
algo mais simples que os diagramas que
320
veremos depois neste captulo). Esse diagrama mostra o comportamento de uma mquina
comum de respostas telefnicas.
Os principais componentes do diagrama so os estados e as setas que representam
alteraes de estado. Existem diversas notaes alterna- Uvas para diagramas de
transies de estado; uma bastante comum mostrada na figura 13.1(b). Embora seja
equivalente em contedo figu ra 13.1(a) ela tem a desvantagcm de ser muito parecida
com um diagra ma de fluxo de dados. Para evitar confuses, usaremos neste livro figura
13.1(a).
13.1.1 Estados do Sistema
Cada quadro retangular representa um estado em que o sistema
pode estar. O Websters New World Dictionary define estado (state) da
seguinte maneira:
Conjunto de circunstncias ou atributos que caracterizam uma pes soa ou objeto em
determinado momento; modo ou forma de ser;
condio.
Dessa maneira, os estados tpicos de um sistema podem ser um dos
seguintes:
Aguardando que o usurio introduza uma senha
Aquecendo uma mistura qumica
Aguardando o prximo comando
Acelerando um motor
Misturando ingredientes
Aguardando dados para instrumentos
Enchendo o tanque
Ocioso
Observe que muitos desses exemplos apresentam o sistema aguardando pela ocorrncia
de alguma coisa e no indicam que o com putador esteja fazendo algo. Isso se deve ao
fato de o diagrama de tran sies de estado ser utilizado para desenvolver um modelo
essencial do sistema um modelo de como o sistema se comportaria se tivssemos
321
Figura 13.1 (a): Um tpico diagrama de transies de estado
tecnologia perfeita. Uma caracterstica da tecnologia perfeita seria o computador
funcionar com rapidez infinita, de modo a que qualquer processamento ou clculo que o
sislema tivesse de executar ou qualquer ao que ele tivesse de empreender fosse feita em
tempo zero. Dessa forma, qualquer estado observvel em que o sistema esteja s pode
corresponder a perodos de tempo em que ele esteja (1) aguardando a ocorrnca de
alguma coisa do ambiente externo ou (2) aguardando que a atual atividade do ambiente
(misturando, lavando, enchendo, aceleran do etc.) se modifique para alguma outra
atividade.
Isso no quer dizer que nossos sistemas sejam incapazes de empre ender uma ao ou que
no pretendamos mostrar essas aes. Significa apenas que essas aes, que ocorrem
instantaneamente em nosso mo delo de tecnologia perfeita, no so iguais a estados, que
representam as condies observveis em que o sistema pode estar. Desse modo, um
estado represnta um comportamento do sistema que observvel e que perdura por um
perodo finito de tempo.
13.1.2 Mudanas de Estado
Um sistema que existisse em apenas um estado no seria muito
interessante de ser estudado: ele seria esttico. Na realidade, os sistemas
322
Figura 13.1 (b): Uma notao alternativa de diagrama de transies de estado
que costumamos modelar podem ter dzias de estados diferentes. Mas como um sistema
passa de um estado a outro? Se o sistema tiver normas regulamentares dirigindo seu
comportamento, ento somente certos ti pos de mudanas de estado sero significativas e
vlidas.
As modificaes vlidas de estado no DTE so mostradas interli gando-se por uma seta
os pares de estados relevantes. Assim, a figura 13.2 mostra que o sistema pode passar do
estado 1 para o estado 2; mos tra tambm que quando o sistema est no estado 2 pode
passar para o estado 3 ou voltar ao estado 1. Entretanto, de acordo com o DTE, o sistema
no pode passar diretamente do estado 1 para o estado 3. Por Outro lado, o diagrama
ainda nos diz que o sistema pode passar direta mente do estado 3 de volta ao estado 1.
Observe que o estado 2 tem dois estados sucessores. Isso comum nos DTE; qualquer
estado pode con duzir a um arbitrrio nmero de estados sucessores.
Embora a figura 13.2 nos d algumas informaes interessantes sobre o comportamento
tempo-dependente de um sistema, ele nada nos diz sobre algo que pode vir a ser muito
importante: quais so os estados inlcialefinaldo sistema. Na realidade, a figura 13.2 um
modelo est tico de um sistema que tem estado ativo desde sempre e que continuar ativo
para sempre. A maioria dos sistemas tem um reconhecvel estado inicial e outro, final;
isso mostrado na figura 13.3.
323
ESTADO 1
ESTADO 2
ESTADO 3
Figura 13.2: Mudanas de estado
O estado inicial normalmente desenhado no alto do diagrama, embora isso no seja
obrigatrio; o que realmente identifica o estado 1 na figura 13.3 como estado inicial a
seta que no est ligada a qualquer outro estado. Analogamente, o estado final muitas
vezes desenhado na base do diagrama, mas isso tambm no mandatrio. O que de
fato identifica o estado 5 como estado final a ausncia de setas que partam dele. Em
outras palavras, ao se chegar ao estado 5 no se vai a qualquer lugar mais!
O senso comum nos diz que um sistema s pode ter um estado inicial; entretanto, ele
pode ter mltiplos estados finais; esses estados finais so mutuamente exclusivos, o que
quer dizer que apenas um deles pode ocorrer durante a execuo do sistema. A figura
13.4 mostra um exemplo no qual os possveis estados finais so estados 4 e 6.
Como estamos utilizando DTE para construir um modelo essencial, vamos tambm
presumir que as mudanas de estado ocorram instanta neamente; isto , o sistema no
precisa de tempo observvel para passar de um estado a outro. Quando os projetistas e
programadores come arem a construir o modelo de implementao isso ser um
problema real: normalmente so necessrios alguns microssegundos para um computador
passar de uma atividade de processamento para outra, e eles devem assegurar que isso
ocorra com suficiente rapidez para que o ambiente no fique fora de controle.
324
Figura 13.3: Estados inicial efinal
Figura 13.4: Mlt estados finais de um sistema
325
13.1.3 Condies e Aes
Para tornar completo nosso diagrama de transies de estado, pre cisamos acrescentar
mais duas coisas: as condies que causam uma mu dana de estado e as aes que o
sistema empreende quando muda de estado. Como mostra a figura 13.5, as condies e
aes so exibidas junto seta que liga os dois estados inter-relacionados.
ESTADO 1
Condio
Ao
ESTADO 2 1
Figura 13.5: Indicao das condies e das aes
Uma condio um evento no ambiente externo que o sistema seja capaz de detectar,
podendo ser um sinal, uma interrupo ou a chegada de um pacote de dados. Isso
normalmente far o sistema passar do es tado de aguardando X para o estado de
aguardando Y ou de executando a atividade X para executando a atividade Y.
Mas, como parte da mudana de estado, o sistema normalmente empreender uma ou
mais aes; produzir uma saida, apresentar uma mensagem no terminal do usurio,
efetuar um clculo etc. Portanto, as aes mostradas no DTE ou so respostas enviadas
ao ambiente externo ou so clculos cujos resultados so memorizados pelo sistema
(geral mente em um depsito de dados constante no diagrama de fluxo de da dos) para
reagir a algum evento futuro 2
13.2 DIAGRAMAS SUBDIVIDIDOS
Em um sistema complexo pode haver dzias de estados distintos:
tentar mostr-los todos no mesmo diagrama seria dificil, seno imposs vel. Assim, da
mesma forma que utilizamos nveis e subdivises nos dia gramas de fluxo de da&s,
podemos subdividir os DTE. A figura 13.6(a) apresenta um exemplo . dois nveis de
diagramas de transies de estado de um sistema complexo
Observe que nesse caso, qu -uer estado individual de um dia grama de nvel mais
elevado pode tornar-se o estado inical de um
326
diagrama de nvel inferior que descreva mais detalhadamente aquele estado de nvel mais
elevado; e o(s) estado(s) final (finais) de um dia grama de nvel mais baixo
corresponde(m) s condies de sada do estado associado de nvel superior. Em outros
casos, o analista de siste mas pode precisar mostrar, explicitamente, como um DTE de
nvel in ferior sai para um ponto adequado do diagrama superior.
Um exemplo da necessidade de um diagrama subdividido de tran sies de estado pode
ser o dos caixas automticos hoje vistos na maioria dos bancos; um DTE para essa
aplicao apresentado na figura 13.6(b).
L_L_ ESTADO3
Figura 13.6 (a): Dois nveis de D7E
327
start press Exibir inserir carto
AGUARDANI
CARTO
Reset
Carto inserido pressionado ou senha errada
Exibir introduza senha Limpar tela
IAGUARDANDO
Exibir quanto deseja?
AGUARDANDO
ENTRADA
Cliente introduz importncia
4 Exibir por favor, aguarde, dinheiro sendo providenciado
ENTREGANDO
DINHEIRO
Dinheiro disponivel
4 por favor, recolha o dinheiro
AGUARDANDO
RECOU-BMENTO Retornar ao estado de AGUARDANDO ESCOLHA
na figura superior
Flgural3.6 (b): Um DTE subdividido para uma mquina de caixa automtico
328
Senha introduzida
Exibir selecione funo
-j
Reset pressionado
4 Limpar tela
IAGUARDANI
ESCOLHA
Recolha o dinheiro
1
13.3 A CONSTRUO DO DIAGRAMA DE TRANSIES DE ESTADO
Agora que j vimos a notao para diagramas de transies de
estado, vamos discutir rapidamente as etapas da construo deles. Pode mos seguir uma
destas duas abordagens:
1. Voc pode comear pela identificao de todos os estados pos sveis do sistema,
representando cada um deles como um re tngulo em uma folha de papel. Em seguida,
voc pode explorar todas as conexes significativas (ex.: mudanas de estado) entre os
retngulos.
2. Como alternativa, voc pode comear pelo estado inicial, conti nuando metodicamente
seu caminho para o(s) estado(s) se guinte(s); e depois, do(s) estado(s) secundrio(s) para
o(s) tercirio(s) e assim por diante.
A abordagem que voc vai adotar ser, em muitos casos, ditada pelo usurio com quem
voc estiver trabalhando, principalmente se ele for o nico familiarizado com o
comportamento tempo-dependente do sistema.
Aps haver terminado de elaborar o DTE preliminar, voc deve
executar as seguintes diretrizes de verificao de consistncia:
Foram definidos todos os estados? Examine detidamente o siste ma para verificar se h
qualquer outro comportamento ob servvel ou qualquer outra condio em que o sistema
possa estar alm daqueles que voc tiver identificado.
Todos os estados podem ser atingidos? Ai gum estado foi definido sem que haja
caminhos que levem a ele?
Todos os estados tm sada? Como j dissemos, o sistema pode ter um ou mais estados
finais com mltiplas entradas; mas todos
os outros estados devem ter um estado sucessor.
Em cada estado, o sistema reage adequadamente a todas as condies possveis? Este
o erro mais comum na elaborao de um diagrama de transies de estado: o analista de
sistemas identifica as mudanas de estado quando ocorrem as condies normais, mas
esquece de especificar o comportamento do sis tema em condies inesperadas. Suponha
que o analista tenha modelado o comportamento de um sistema como mostrado na
329
figura 13.7; ele espera que o usurio pressione uma tecla de funo do terminal para
causar uma transio do estado 1 para o estado 2 e uma outra tecla de funo para passar
do estado 2 para o estado 3. Mas, e se o usurio acionar a mesma tecla duas vezes
seguidas? Ou alguma outra tecla? Se o comportamento do sistema no for especificado,
provavelmente os projetistas e pro gramadores no programaro para essa eventualidade,
e o sis tema apresentar um comportamento imprevisvel sob diversas circunstncias.
13.4 O RELACIONAMENTO COM OS OUTROS COMPONENTES DO MODELO
O diagrama de transies de estado pode ser utilizado isoladamen te como ferramenta de
modelagem. Entretanto, ele pode ser usado em
combinao com as outras ferramentas, o que normalmente acontece.
Na maioria dos casos, o diagrama de transies de estado repre senta a especificao de
processo de uma bolha de controle de um diagrama de fluxo de dados. A figura 13.8
ilustra este fato; observe que as condies do DTE correspondem aos fluxos de controle
que chegam de um DFD, e as aes do DTE correspondem aos fluxos de controle que
saem em um DFD. Como ferramenta de alto nvel, o diagrama de
ESTADO 1
tecla de funo 1
exibir mensagem 1
ESTADO 2
tecla de funo 2
exibir mensagem 2
ESTADO3 1
Figura 13.7: Um DTE incompleto
330
sinal x
sinal y
Figura 13.8: O relacionamento entre o DFD e o DTE
transies de estado pode servir como especificao de processo para todo o sistema.
Dessa forma, se representarmos o si:stema inteiro como um diagrama de fluxo de dados
de uma s bolha poderemos utilizar o diagrama de transies de estado para mostrar a
seqncia das ativi dades dentro do sistema.
13.5 RESUMO
O diagrama de transies de estado uma poderosa ferramenta de modelagem para
descrever o necessrio comportamento de sistemas de tempo-real e a parte de interface
humana de muitos sistemas on-line. Apesar de no ser amplamente conhecido ou
utilizado no desenvolvi mento de sistemas comerciais de informaes, ele uma
ferramenta que voc deve procurar conhecer porque, no futuro, podemos esperar que
mais e mais sistemas de natureza comercial, cientfica ou de engenharia, se aproximaro
dos de tempo-real.
331
REFERNCIAS
1. Websters New World Dicttona Second Coliege Edition. Nova lorque: Simon &
Schuster, 1980.
PERGUNTAS E EXERCCIOS
1. O que um diagrama de transies de estado? Para que serve?
2. Em que tipo de sistema se costuma utilizar o DTE como ferramen ta de modelagem?
3. Os DTE so ferramentas importantes para se descrever os requisi tos de um tpico
sistema de informaes comerciais? Por qu?
4. Os DTE so ferramentas importantes para se descrever o projeto e a implementao de
um tpico sistema de informaes comerciais?
por qu? Caso afirmativo, de que tipo de sistemas comerciais?
5. Quais so os dois principais componentes de um DTE?
6. Apresente uma notao alternativa para um DTE, isto , uma que seja diferente dos
diagramas comuns mostrados neste captulo e
em todo este livro.
7. Qual a definio de estado?
8. D trs exemplos de estado.
9. O que uma mudana de estado? Como se mostra isto em um
DTE?
10. O que um estado sucessor?
11. O que o estado inicial de um sistema? Quantos estados iniciais um sistema pode ter?
12. O que o estado final de um sistema? Quantos estados finais um sistema pode ter?
13. O que so condies em um DTE? Como so mostradas?
14. O que so aes em um DTE? Como so mostradas?
15. Quantas condies pode haver em um diagrama de transies de estado?
16. Quantas aes podem estar associadas a cada condio em um diagrama de transies
de estado?
17. Quais dos estados abaixo so aceitveis? Para os que no o forem explique porqu.
(a) Calcular imposto sobre vendas
(b) Monitorando mistura de reagentes
(c) Endereo-de-cobrana-de-cliente
(d) Arquivo-de-produtos
(e) Ascenso de elevador
(f) Temperatura do reagente fora da medida
332
(g) Atualizar total faturado
(h) Parar elevador
(i) Tecla de interrupo pressionada
Ci) Processando dados
18. O que um diagrama de transies de estado subdividido?
19. Qual o relacionamento entre os estados iniciais e os estados finais de um DTE
subdividido?
20. Quantos nveis podem existir em um DTE subdividido?
21. Quais so as duas abordagens comuns para a elaborao de um
DTE?
22. Quais so as quatro diretrizes para determinar se um DTE est consistente?
23. Qual o relacionamento entre um DTE e um DFD?
24. O que est errado no DTE abaixo?
ESTADO
25. O que est errado com o DTE abaixo?
ESTADO 1
ESTADO 2
26. O que est errado com o DTE abaixo?
333
27. O que est errado com o DTE abaixo?
28. O que est errado com o DTE abaixo?
29. O que est errado com o DTE abaixo?
334
30. O que est errado com o DTE abaixo?
31. O que est errado com o DTE abaixo? Se voc achar que nada est errado com ele,
descreva o que poderia acontecer com o sistema
modelado por este DTE.
condio-1
32. O que est errado com o DTE abaixo?
condio-1
33. Em um sistema complexo, deve o analista de sistemas comear desenhando um
conjunto de DFD para o sistema, ou comear
pelos DER ou pelos DTE?
34. Onde devem ser descritos os detalhes das condies e aes do DTE no modelo de
um sistema?
35. Desenhe um diagrama de transies de estado para um gravador de fila ou para um
toca-fitas.
36. Desenhe um diagrama de transies de estado para o caixa eletrnico de seu banco.
37. Desenhe um diagrama de transies de estado para um relgio digital de pulso (a
maioria dos relgios digitais de hoje tem apa rncia normal bem como um despertador
e um crongrafo).
condio-1 ao-1
condio-1
335
1
38. Desenhe um diagrama de transies de estado para um forno de microondas.
39. Desenhe um diagrama de transies de estado para o menu de interface humana para
o Lotus 1-2-3.
NOTAS
1 Discutiremos com mais detalhes o conceito de modelo essencial no
captulo 17.
2 Observe que para executar uma ao o sistema pode precisar de entradas adicionais do
ambiente externo. Assim, podemos dizer que cada condio corresponde a um evento
externo ao qual o sis tema deve responder e que esses eventos externos sero habi
tualmente reconhecidos pelo sistema pela chegada de um fluxo de dados. Entretanto, no
necessariamente verdadeiro que cada flu xo de dados que chega ao sistema seja um
evento correspondente a uma condio do DTE.
3 Esse diagrama conhecido como diagrama de contexto. O diagra ma de contexto ser
discutido em detalhes no captulo 18.
336
14
O EQUILBRIO DOS MODELOS
Todas as pessoas esto sujeitas a errar, e a maioria delas, sob muitos
aspectos, por paixi ou por interesse, tentada a isso.
John Locke,
F Concernin,g Human Undei 1690
Neste captulo, aprenderemos
1. Como equilibrar um diagrama de fluxo de dados em relao ao dicionrio de dados.
2. Como equilibrar um diagrama de fluxo de dados em relao especificao de
processos.
3. Como equilibrar uma especificao de processos em relao ao dicionrio de dados.
4. Como equilibrar um DER em relao ao DFD e especificao de processos.
5. Como equilibrar um DER em relao ao dicionrio de dados.
6. Como equilibrar um diagrama de fluxo de dados em relao ao diagrama de transies
de estado.
Nos ltimos cinco captulos examinamos diversas ferramentas de
modelagem importantes para a anlise estruturada:
Diagramas de fluxo de dados
Dicionrio de dados
337
1
Especificao de processos
Diagramas de entidades-relacionamentos
Diagramas de transies dc estado
Cada uma dessas ferramentas, como vimos, enfoca um dos aspec tos fundamentais do
sistema que est sendo modelado. importante ter isso em mente, porque significa que a
pessoa que l o modelo tambm est focalizando um dos aspectos fundamentais, isto , o
aspecto para o qual sua ateno est sendo atraida pela prpria ferramenta de modela
gem. Como o sistema subjacente possu muitas diferentes dimenses de complexidade,
queremos que o diagrama de fluxo de dados atraia a ateno do leitor para as frnes do
sistema sem que os relacionamentos entre os dados distraiam sua ateno; e queremos
tambm que o diagra ma de entidades-relacionamentos focalize a ateno sobre os
relaciona mentos entre os dados sem permitir que as caractersticas funcionais distraiam a
ateno do leitor; queremos, ainda, que o diagrama de tran sies de estado focalize a
ateno para as caractersticas do timing do sistema sem distraes com funes ou
dados.
Mas chega o momento de combinar todas as ferramentas de mode lagem, e sobre isso
que falaremos neste captulo. A situao com que o modelador de sistemas se defronta
um tanto anloga antiga fbula dos trs sbios cegos indianos que esbarraram em um
elefante. Como mostra a figura 14.1, eles emitiram trs opinies diferentes concernen tes
realidade com que se deparavam tocando diferentes partes do elefante:
Figura 14.1: Trs cegos examinando um elefante
338
Um dos cegos tocou a ponta afiada de uma das longas presas do elefante. Aha!, disse
ele, temos aqui um touro. Posso perceber
seus chifres!
O segundo tocou o couro hirsuto do elefante. Sem dvida, disse ele, isto um .
..qu? Um porco-espinho? Sim, claro - um
porco-espinho!.
O terceiro cego apalpou uma das grossas pernas do elefante e declarou: Isto deve
tratar-se de uma rvore.
De modo semelhante, quando modelamos trs diferentes aspectos de um sistema
(funes, dados e timing), bem como quando modela mos as caractersticas detalhadas
do sistema em um dicionrio de dados e um conjunto de especificaes de processo,
fcil desenvolver vrias interpretaes inconsistentes diferentes da realidade. Isso
representa um perigo particularmente srio em grandes projetos, onde vrias pessoas e
vrios grupos de interesses especiais provavelmente estaro envolvidos. Tambm
arriscado quando uma equipe de projeto (e/ou a comunidade usuria) envolve pessoas
com formaes muito diferentes.
Existe um outro motivo para se focalizar a consistncia do modelo:
quaisquer que sejam os erros eles sero encontrados em algum momen to, mas isso se
torna cada vez mais difcil e caro nas fases finais do projeto. Na realidade, os erros que
forem introduzidos no modelo de requisitos durante a fase de anlise provavelmente se
propagaro e se ampliaro nas fases de projeto e de implementao do projeto. Isso
representa um risco especialmente srio em grandes projetos em que a anlise de sistemas
muitas vezes feita por diferentes pessoas (ou mes mo por diferentes empresas!) e no as
de projeto e implementao. Assim, Martin aponta que 50% dos erros detectados em um
sistema e 75% do custo da remoo de erros relacionam-se aos erros cometidos na fase
de anlise do sistema e os estudos em lBoehm, 19811 mostraram que o custo de correo
de um erro cresce exponencialmente nos estgios derradeiros de um projeto; dez vezes
mais barato corrigir um erro de anlise durante a fase de anlise do que corrigi-lo na fase
de projeto.
Alguns desses erros so, naturalmente, erros simples em cada modelo (ex.: um diagrama
de fluxo de dados com um poo sem fundo). Alguns desses erros podem ser
caracterizados como interpretaes err neas do que o usurio realmente desejava.
Porm, muitos desses erros mais difceis e insidiosos so inter-modelos, isto ,
inconsistncias entre um modelo e outro. Uma especificao estruturada na qual todas as
ferramentas de modelagem so verificadas mediante referncias cruza das em relao a
cada uma das outras em busca de consistncia dita ser equilibrada.
339
O erro de equilbrio mais comum envolve afaltade uma definio:
alguma coisa definida (Ou descrita) em um modelo no est adequada mente definida em
outro. Veremos alguns exemplos disso nas prximas sees (ex.: um depsito mostrado
no DFD mas no definido no dicio nrio de dados, ou um objeto no DER no mostrado
como um corres pondente depsito de dados no DFD). O segundo tipo comum de erro a
inconsistncia: a mesma realidade descrita de modos diferentes e contraditrios em
dois diferentes modelos.
Vamos examinar alguns dos principais aspectos do equilbrio:
Equilibrar o diagrama de fluxo de dados em relao ao dicionrio de dados.
Equilbrio do diagrama de fluxo de dados em relao s especi ficaes de processos.
Equilbrio das especificaes de processos em relao ao dicio nrio de dados.
Equilbrio do DER em relao ao DFD e s especificaes de processos.
Equilbrio do DER em relao ao dicionrio de dados.
Equilbrio do DFD em relao ao diagrama de transies de estado.
Como veremos, as regras do equilbrio so todas muito diretas; elas
exigem muito pouco raciocnio ou criatividade para serem executadas.
Mas elas devem ser executadas e de maneira diligente.
14.1 O EQUILBRIO DO DFD EM RELAO AO DD
As normas para equilibrar o diagrama de fluxo de dados em rela o ao dicionrio de
dados so as seguintes:
Cada fluxo de dados (uma flexa no DFD) e cada depsito de dados deve ser definido no
dicionrio de dados. Se no constar no dicionrio de dados, o fluxo de dados ou o
depsito con siderado como indefinido.
Inversamente, cada elemento de dados e cada depsito de da dos definido no dicionrio
de dados deve aparecer em algum
340
lugar de um DFD. Caso negativo, o elemento ou depsito de dados em questo um
fantasma - algo definido mas no utilizado no sistema. Isso pode acontecer se os
elementos de dados forem definidos para corresponderem a uma verso anterior do DFD;
o perigo est em que o DFD pode ser alterado (isto , um fluxo ou um depsito de dados
pode ter sido supri mido) sem uma correspondente alterao no dicionrio de dados.
Isso, naturalmente, significa que o analista de sistemas deve rever meticulosamente os
DFD e o dicionrio de dados para se certificar que estejam equilibrados. No importa que
modelo seja examinado em pri meiro lugar, embora a maioria dos analistas comece pelo
DFD para garantir que todos os elementos estejam definidos no dicionrio de da dos.
Como todas as outras atividades de equilbrio (balanceamento) neste captulo, esse um
servio entediante e que se presta muito bem aos produtos automatizados.
14.2 O EQUILBRIO DO DFD EM RELAO ESPECIFICAO DE PROCESSOS
Eis as normas para o equilbrio do DFI) em relao s especifica es de processos:
Cada bolha no DFD deve estar associada a um DFD do nvel imediatamente inferior ou a
uma especificao de processos, mas no a ambos. Dessa forma, se o DFD mostrar uma
bolha identificada como 1.4.2, ento deve existir ou uma figura correspondente,
identificada como figura 1.4.2, cujas bolhas so identificadas como 1.4.2.1, 1.4.2.2 etc.,
ou a especificao es truturada deve conter uma especificao dc processo para a bolha
1.4.2. Se ambas existirem, o modelo dcsnecessariamente (e perigosamente) redundante.
Cada especificao de processo deve estar associada a uma bolha do nvel bsico de um
I)FI). Como a especificao de processos no exige grande volume de isabalho, poder-se-
ia pensar ser altamente improvvel que possa haver especificaes de processos
errantes flutuando no sistema. Mas isso pode acontecer: a especificao de processos
pode ter sido escrita para uma verso preliminar do DFD, aps o que algumas das bolhas
do DFD poderiam ter sido eliminadas em algum pro cesso de reviso.
341
Entradas e sadas devem corresponder. O DFD deve apresentar fluxos que chegam e que
saem de cada bolha, bem como co nexes com os depsitos. Tudo isso tambm deve estar
evidente na especificao de processos: assim sendo, devemos esperar ver um comando
READ (ou GET, ou INPUT, ou ACCEPT, ou algum outro verbo semelhante)
correspondente a cada fluxo de dados que chega a um WRITE (ou PUT, ou DISPLAY
etc.) para cada fluxo que sai.
Observe que esses comentrios aplicam-se especificamente a bo lhas de pmcessaniento.
Para as bolhas de conirole de um DFD existem correspondncias entre essas bolhas e os
diagramas associados de transi es de estado, como discutimos na seo 14.6.
14.3 O EQUILBRIO DAS ESPECIFICAES DE
PROCESSOS EM RELAO AO DFD E AO DD
As normas para equilibrar as especificaes de processos em rela o ao diagrama de
fluxo de dados e ao dicionrio de dados podem ser descritas da forma que se segue: cada
referncia a dados na especifica o de processos (habitualmente um substantivo) deve
satisfazer uma das seguintes normas:
ela coincide com o nome dc um fluxo de dados ou de um de psito de dados interligado
bolha descrita pela especificao
de processos, ou
ela um termo local, explicitamente definido na especificao de processos, ou
ela aparece como um componenlecm um item do dicionrio de dados para um fluxo ou
depsito de dados interligado bolha. Desse modo, os elementos de dados X e Y
aparecem na espe cificao de processo da figura 14.2, mas no como um fluxo de dados
interligado no DFD mostrado na figura 14.3. Entretanto, o dicionrio de dados, do qual
um fragmento mostrado na figura 14.4, indica que X e Y s componentes de Z e na
figura 14.3 vemos que Z , na verdade, um fluxo de dados interligado bolha, assim,
conclumos que o modelo equilibrado 1
342
ESPECIFICAO DE PROCESSO 3.5: CALCULAR FATOR HIPOTTICO
* P E O SO TERMOS LOCAIS UTILIZADOS EM RESULTADOS
INTERMEDIRIOS
P = 3.14156 *
O = 2.78128 * Y - 13
FATOR-HIPOTTICO = P * Q + 2
Figura 14.2: Um componente de uma espec de processo de um modelo
de sistema
Z fator-hipottico
Figura 14.3: Um componente de DFD de um modelo de sistema
X = * componente horizontal do fator frammis *
* unidade: centmetros; intervalo: O - 100 *
= * componente vertical do fator frammis *
* unidade: centmetros; intervalo: 0- 10 *
Z = * fator frammis, como definido pelo Dr. Frammis *
x+Y
Figura 14.4: Um componente do dicionrio de dados de um modelo de sistemas
343
14.4 O EQUILBRIO DO DICIONRIO DE DADOS EM RELAO AO DFD E S
ESPECIFICAES
DE PROCESSOS
Da discusso acima, pode-se ver que o dicionrio de dados est
consistente com o restante do modelo se obedecer seguinte regra:
Cada item do dicionrio deve ser referenciado por uma especi ficao de processo, ou
por um DFD, ou por outro item do di cionrio de dados.
Isso naturalmente pressupe que estamos modelando o compor tamento essencial de um
sistema. Um dicionrio de dados complexo e completo de uma implementao existente
dc um sistema pode conter alguns elementos de dados que j no so mais usados.
Algum poderia tambm argumentar que o dicionrio de dados poderia ser planejado de
tal forma que permitisse sua futura expanso; isto , ele contm elementos que no so
necessrios hoje, mas podem vir a ser teis no futuro. Um bom exemplo disso um
dicionrio de dados que contm elementos que possam ser teis para pesquisas id boc . A
equipe de projeto, talvez em combinao com o usurio, pode determinar se esse tipo de
modelo desequilibrado realmente algo adequado a ser feito. Entretanto, importante ao
menos ter cautela com essas decises deliberadas.
14.5 O EQUILBRIO DO DER EM RELAO AO DFD E s ESPECIFICAES DE
PROCESSOS
O diagrama de entidades-relacionamentos, como vimos no captulo 12, apresenta uma
viso de um sistema bastante diferente daquela que proporcionada pelo diagrama de
fluxo de dados. Entretanto, existem alguns relacionamentos que devem ser conservados
para que o modelo do sistema como um todo seja completo, correto e consistente:
Cada depsito do DFD deve corresponder a um tipo de objeto ou a um relacionamento
ou combinao de um tipo de objeto e de um relacionamento (isto , um tipo
associativo de objeto) do DER. Se houver um depsito no DFD que no aparea no DER,
algo est errado; e se houver um objeto ou um relacio namento no DER que no aparea
no DFD, tambm h algum erro.
344
Os nomes de objetos no DER e os de depsitos de dados no DFD devem coincidir.
Como vimos nos captulos 9 e 12, a con veno neste livro usar a forma plural (ex.:
CLIENTES) no DFD e a forma singular no DER.
Os itens do dicionrio de dados devem aplicar-se tanto ao mo delo de DFD como ao de
DER. Dessa forma, o item do di cionrio de dados para o exemplo acima deve incluir
definies para o objeto no DER e para o depsito no DER. Isso implica uma definio
no dicionrio de dados como a que se segue:
CLIENTES = ICLIENTE}
CLIENTE = nome + endereo + nmero-de-telefone +...
Os itens do dicionrio de dados para a forma singular (ex.:
CLIENTE) devem informar o significado e a composio de uma nica instncia do
conjunto de objetos mencionados (no singular) no DER e (no plural) no depsito de
dados de um DFD. Os itens do dicionrio de dados para a forma plural (ex.: CLIENTES)
do o significado e a com posio do conjunto de instncias.
De modo semelhante, existem normas para assegurar que o DER esteja consistente com a
parte da especificao de processos relativa ao modelo orientado para funes (lembre-se
que as especificaes de processos so os componentes detalhados do modelo cuja
encarnao grfica o DFD). As normas estabelecem que o conjunto combinado de
todas as especificaes de processos deve, em sua inteireza:
Criar e suprimir instncias de cada tipo de objeto e de cada re lacionamento mostrado
no DER. Isso pode ser entendido me lhor examinando-se o DFD da figura 14.5: como
sabemos, o depsito CLIENTES corresponde ao objeto CLIENTE. Alguma coisa deve
ser capaz de criar e suprimir instncias de um cliente, o que significa que alguma bolha
do DFD deve ter um fluxo de dados interligado ao depsito CLIENTES. Mas a tarefa real
de escrever no depsito (isto , de criar ou suprimir uma instncia do objeto CLIENTE
correspondente no DRD) deve ocorrer den tm dessa bolha, o que quer dizer que deve ser
documentado pela especificao de processo associada quela bolha 2
Alguma bolha do DFD estabelece valores para cada elemento de dado atribudo a cada
instncia de cada tipo de objeto, e algum processo do DFD usa (ou l) valores de cada
elemento de dado.
14.6 O EQUILBRIO DO DFI) EM RELAO AO
DIAGRAMA DE TRANSIES DE ESTADO
A condio de estado pode ser considerada equilibrada em relao
ao diagrama de flaxo de dados se forem observadas as seguintes normas:
Cada bolha de controle no DFD tem associado a si um diagrama de transies de estado
como sua especificao de processo. De modo semelhante, cada diagrama de transies
de estado no modelo geral do sistema deve estar associado a um processo de controle
(bolha) no DFD.
Cada condio no diagrama de transies de estado deve cor responder a um fluxo de
controle que chega ao processo de controle associado ao diagrama de transies de
estado. De modo semelhante, cada fluxo de controle que chega bolha de controle deve
estar associado a uma condio apropriada no correspondente diagrama de transies de
estado.
Figura 14.5: Criao e eliminao de instncias do DER
CLIENTES
detalhes-de-cliente
ITENS
346
Cada ao no diagrama de transies de estado deve correspon der a um fluxo de
controle que sai no processo de controle associado ao diagrama de transies de estado.
Do mesmo modo, cada fluxo de controle que sai na bolha de controle deve estar
associado a uma ao apropriada no correspondente dia grama de transies de estado.
Essas correspondncias so mostradas na figura 14.6.
Figura 14.6: Correspondncias entre o DFD e o DTE
14.7 RESUMO
Observe que todas as normas de equilbrio neste captulo foram apresentadas como se
voc fosse examinar pessoalmente todos os com ponentes de um modelo de sistema para
descobrir possveis erros ou inconsistncias. Isso poderia exigir que voc desenhasse, no
cho ou em um quadro de avisos de grandes dimenses, todos os DFD, especifica es de
processos, DER, DTE e dicionrio de dados, e em seguida ca minhasse de um ao outro,
verificando cuidadosamente se tudo est em seu lugar.
sinal x
sinal y
347
Enquanto este livro est sendo preparado, em 1987, isso precLga mente o que voc teria
de fazer em 98% das organizaes de desenvol vimento de sistemas no mundo. Se voc
tiver a sorte de o estar lendo por volta de 1990, a estimativa pode ter cado para 90%. E
se voc ainda estiver lendo este livro em 1995 (quando meu editor j deve ter-me
obrigado a produzir uma nova edio na qual toda esta seo ter sido eliminada), a
perspectiva dever ser de 50%. O importante que as normas de equilbrio que
apresentamos neste captulo podem ser auto matizadas, e j existem diversas ferramentas
para estaes de trabalho, baseadas em PC, que executaro mecanicamente algumas ou
todas as verificaes de erros.
Vimos, porm, exatamente o mesmo fenmeno em vrias outras reas. Algum poderia
objetar que a proliferao dos baratos sistemas de processamento de palavras eliminou a
necessidade de se aprender a escrever mo; na verdade, tambm se poderia argumentar
que a dispo nibilidade de verificadores da correo da escrita eliminou at mesmo a
necessidade de se saber escrever corretamente. E a universal disponibi lidade de
calculadoras de bolso dispensou a necessidade dc sabermos fazer longas divises. Do
mesmo modo a ubqua presena dos carros de mudana automtica de marcha eliminou a
necessidade dc se aprender a dirigir automveis com alavanca de mudana.
Eu, na verdade, no consigo imaginar qualquer razo para se en sinar uma pessoa na
Amrica do Norte a dirigir um carro com alavanca de mudana quando j nos
aproximamos do final do sculo XX. Nem posso imaginar qualquer motivo para se
enfatizar a arte da caligrafia e da escrita mo (exceto, naturalmente, como uma forma
de arte) em uma poca em que os sistemas de processamento de palavras esto prestes a
serem substitudos pelos sistemas de reconhecimento de voz. Mas posso entender a
necessidade de se aprender os princpios bsicos de uma longa diviso, mesmo que
tenhamos absoluta certeza de que nunca es taremos sem uma calculadora de bolso; como
Joshua Schwartz, da Uni versidade de Harvard lembra, isso, no mnimo, nos ajudar a
sabermos se a resposta produzida com a calculadora tem o ponto decimal no lugar
correto.
Algum pode defender os mritos de se aprender a escrever ma nualmente em 1987,
quando (1) menos da metade das crianas privile giadas nos Estados Unidos tem um
computador pessoal em casa; (2) apenas cerca de 3% da populao americana em geral
tem um computa dor pessoal em casa; (3) cerca de somente 10% dos professores america
nos tem seu prprio PC e (4) apenas uma pequenina percentagem das escolas nos EUA
est preparada para ensinar as habilidades mecnicas da digitao. A escrita manual
tecnologcamenje obsoleta, e doloroso para os pais versados em computao (para no
mencionar os filhos versados em computao!) serem forados a ensinar essa antiga e
348
primitiva tcnica de comunicao; mas ela provavelmente ainda uma habilidade
necessria na sociedade de hoje. Afinal de contas, foi apenas h uns poucos anos atrs
que a maioria dos pais parou de ensinar aos filhos como substituir as velas, trocar o leo e
consertar um pneu baixo do automvel.
Estou igualmente convencido de que o analista de sistemas profis sional precisa conhecer
os princpios dc equilbrio apresentados neste captulo. Como analista de sistemas
provvel que voc no tenha outra alternativa seno executar essas normas de verificao
de erros mecanicamente pelos prximos anos at que as ferramentas adequadas de
engenharia de software estejam amplamente disseminadas. O processo manual de
verificao de erros ser normalmente validado em ambiente de caminhamentos
(walkthrough); essa tcnica discutida no apndice D.
REFERNCIAS
1. James Martin, An Information Systems Manifesto. Englewood Cliffs,
N.J.: Prentice-Hall, 1984.
2. Barry Boehm, Software Engineering Economics. Englewood Cliffs, N.J.: Prentice-
Hall, 1981.
PERGUNTAS E EXERCCIOS
1. Por que importante equilibrar os modelos da especificao de um sistema? Quais so
os riscos de uma especificao desequilibrada?
2. Por que importante descobrir os erros do modelo de um sistema o mais cedo
possvel?
3. Que percentagem do custo da eliminao de erros est associada fase de anlise de
sistemas de um projeto?
4. Quais so as duas formas mais comuns de erros de equilbrio?
5. O DFD deve ser equilibrado em relao a quais partes do modelo do sistema?
6. O DER deve ser equilibrado em relao a quais partes do modelo do sistema?
7. O DTE deve ser equilibrado em relao a quais partes do modelo do sistema?
8. O dicionrio de dados deve ser equilibrado em relao a quais partes do modelo do
sistema?
9. A especificao de processos deve ser equilibrada em relao a quais partes do modelo
do sistema?
349
10. Existem outros componentes do modelo do sistema que devam scr equilibrados?
11. Quais so as normas para equilibrar o DFD em relao ao dicio nrio de dados?
12. Sob que condies pode um item ser definido no dicionrio de dados sem aparecer
em algum lugar de um DFD?
13. Quais so as normas para equilibrar o DFD em relao s especifi caes de
processos?
O que aconteceria se uma especificao de processo fosse escrita para uma bolha no-
primitiva (ou no-atmica) do DFD?
Deve existir uma especificao de processo para processos de controle do DFD? Se assim
for, ela deve ter a mesma forma que a especificao de um processo normal?
Quais so as normas para equilibrar a especificao de processos em relao ao DFD e ao
dicionrio de dados?
O que so dados errantes?
Sob que condies aceitvel haver um termo (Ou referncia de dado) na especificao
de processos para no ser definido no di cionrio de dados?
Quais so as normas para equilibrar o dicionrio de dados em relao ao DFD e
especificao de processos?
Sob que condies possvel que a equipe de projeto coloque deliberaaamenje itens no
dicionrio de dados que no constem no
DFD?
Quais so as normas para equilibrar o DER em relao ao DFD? Qual a conveno para
nomes no DER coincidentes com depsi tos no DFD?
Quais so as normas para equilibrar o DER em relao especifi cao de processos?
Quais so as normas para equilibrar o DTE em relao ao DFD? Sob que circunstncias
vlido no haver um DTE no modelo de um sistema?
Como as normas de equilbrio apresentadas neste captulo devem ser observadas em um
tpico projeto de desenvolvimento de siste mas? Quem deveria ser o responsvel cm
verificar se isso foi feito? Se voc dispuser de uma estao automatizada de trabalho para
anlise de sistemas, necessrio conhecer as normas de equilbrio apresentadas neste
captulo? Por qu?
Se os modelos de sistema tiverem sido equilibrados, podemos confiar em que estejam
corretos? Por qu?
29. Mostre trs erros de equilbrio no modelo de sistema abaixo
NOTAS
Contudo, pode valer a pena fazer mais algumas verificaes nesse ponto: se X for o nico
componente de Z utilizado na espe cificao do processo, podemos seriamente questionar
por que Z foi mostrado primeiramente como entrada. Isto , os demais componentes de Z
podem ser dados errantes que flutuam pela bolha sem serem utilizados. Isso muitas
vezes reflete um modelo de uma Implementao arbitrria de um sistema, em vez de um
modelo do comportamento essencial do sistema.
2 A situao pode ser um pouco mais complicada: a bolha mostrada no DFD pode no ser
uma bolha do nvel mais baixo. Desse modo, possvel que a bolha rotulada
INTRODUZA-NOVO-CLIENTE na figura 14.5 possa ser descrita por um diagrama
defluxo de dados de nvel inferior, no por uma especificao de processo. Se for esse o
caso, ento uma das bolhas de nvel inferior (talvez no um nvel, mas vrios nveis
abaixo) ser primitiva e ter acesso ao depsito diretamente. Lembre-se, do captulo 9,
que pela nossa conveno no DFD o depsito mostrado no mais alto nvel em que ele
uma interface entre duas bolhas e repetido em todos os diagramas de nvel inferior.
z
Y
30. O DTE deve ser equilibrado em relao ao DER? Por qu?
351

15
FERRAMENTAS
ADICIONAIS DE
M ODELAGEM
A necessidade de descobrir a ineficincia o quanto antes torna impor tante que se
externalize (isto , que se torne visvel) cada estgio de um projeto em andamento. As
plantas de engenharia, por exemplo, cum previ esta finalidade e so teis no somente
para um projetista, atrain do sua ateno para pontos duvidosos e potenciais
inconsistncias, mas, tambm, para uma equ ou toda uma organizao que esteja desen
tolvendo um produto. Os planos so os principais meios de comunica o, crtica e
refinamento coletiva. Alm disso, os mtodos de representa o devem ser relativamente
simples e diretos para transpor o espao entre a realidade e o programa; e devem ser
eficientes em todas as mltiplas etapas iterativas.
L.A.Belady, prefcio a Software Design, EPeters, 19811
Neste captulo, aprenderemos:
1. Como identificar diversas variaes dos fluxogramas.
2. Como desenhar diagramas FIIPO e diagramas estruturais.
3. Como identificar diversas variaes dos DFD.
4. Como identificar diversas variaes dos DER.
As ferramentas de modelagem apresentadas nestes ltimos captu los seriam suficientes
para qualquer projeto em que voc estivesse traba lhando. Entretanto, voc deve se
familiarizar com algumas ferramentas adicionais de modelagem; mesmo que no as
utilize, voc pode encon tr-las no seu trabalho, e deve, pelo menos, saber l-las e
interpret-las.
353
As ferramentas adicionais dc modelagem que estudaremos neste captulo incluem:
Fluxogramas e suas variantes.
Fluxogramas de sistemas.
Diagramas HIPO e grficos estruturais.
Variaes nos diagramas de fluxo de dados.
Variaes nos diagramas de entidades-relacionamentos.
O propsito deste captulo no fazer de voc um perito em qual quer dessas ferramentas
de modelagem, mas apenas mostrar-lhe que elas existem como alternativas possveis.
Detalhes suplementares de cada ferramenta de modelagem podem ser encontrados nas
referncias do final do captulo.
15.1 FLUXOGRAMAS E SUAS VARIANTES
15.1.1 O Fluxograma Clssico
Uma das mais antigas e melhores ferramentas de modelagem co nhecidas o fluxograma
clssico; um fluxograma tpico mostrado na
figura 15.1.
Se voc j teve algum contato com computadores, ou programa o, ou processamento de
dados, provvel que tenha tido pelo menos alguma relao informal com os
fluxogramas. No os estudaremos em detalhe neste livro, e somente daremos uma olhada
em um subconjunto da notao de diagramao. Para detalhes sobre notao de fluxogra
mas, recorra a [ 19701.
A notao apresentada na figura 15.1 tem somente trs compo nentes:
O quadro retangular representa uma instruo executvel de computador ou uma
sequncia de inslrues conl
O quadro em forma de losango representa uma deciso; no caso mais simples representa
uma deciso binria.
As setas que interligam os quadros representam o fluxo de con trole. S pode haver uma
seta saindo de um quadro retangular;
354
Figura 15.1: Umfluxo,grama tpico
isto , quando uma instruo termina sua execuo, o fluxo pode prosseguir para alguma
instruo ou deciso nica sub seqente. De modo semelhante, s pode haver duas setas
ori ginando-se de uma deciso.
Como voc pode ver, os fluxogramas nos permitem representar graficamente a lgica
procedural de um programa de computador. nessa rea que os fluxogramas so mais
usados, embora a introduo de linguagens de programao de alto nvel nos anos 60 e 70
tenha elimi nado grande parte da necessidade de fluxogramas detalhados.
Porm, se os fluxogramas so uma das ferramentas de programa o, por quediscuti-los
nesse livro? A resposta j lhe deve ter ocorrido:
alguns analistas de sistemas usam fluxogramas como um meio de docu-, mentar as
especificaes de processos (isto , como uma alternativa linguagem estruturada e s
outras ferramentas apresentadas no capitulo 11). Como se pode recordar do captulo 11,
minha opinio que qual quer tcnica de documentao que descreva corretamente as
exigncias do usurio e que comunique efetivamente essas exigncias, aceitvel. Desse
modo, se o usurio gosta de ler fluxogramas e se estes descrevem
355

com exatido a norma executada dentro de uma bolha em um diagrama de fluxo de


dados, eles podem ser utilizados.
Entretanto, muito poucos analistas dc sistemas fazem uso, realmen te, de fluxogramas
detalhados para especificaes de processos. Existem
diversas razes para iSSO:
A menos que seja tomado um grande cuidado, o fluxograma pode tornar-se
incrivelmente complicado e dificil para ser lido. Um exemplo de um tpico fluxograma
no-estruturado mos trado na figura 15.2.
Embora o suporte automatizado (em estaes de trabalho basea das em PC) esteja agora
disponvel, ele ainda requer um tra balho considervel para se desenvolver os grficos de
um fluxograma. E, se os detalhes da orientao do usurio se modi ficarem, ou se o
analista de sistemas tiver que alter-los muitas vezes at que tenha alguma coisa que o
usurio aceite como correta, ser uma tarefa tediosa e consumidora de tempo rede senhar
o fluxograma a cada vez. Se a especificao de processos estiver representada sob alguma
forma textual que possa ser manipulada com um processador de palavras, as mudanas
costumam ser muito mais fceis.
Os modelos grficos so geralmente mais eficazes como meio de ilustrar uma realidade
mullklimensional. Os diagramas de fluxo de dados, por exemplo, ilustram de forma
vvida o fato de que todas as bolhas do sistema podem estar ativas ao mesmo tempo. Mas
o fluxo de controle cm um programa ou em uma especificao de um processo individual
pode ser descrito sob forma unidimensional; isto , a lgica pode ser organizada de forma
a fluir uniformemente de alto a baixo l:ace a isso os grficos tornam-se desnecessrios.
15.1.2 Variaes dos Fluxogramas
Embora os fluxogramas clssicos sejam os mais utilizados - quan do so utilizados -
existem algumas variaes que voc deve conhecer.
Mencionaremos quatro delas:
1. Diagramas de Nassi-Shneiderman
2. Diagramas de Ferstl
3. Diagramas de Hamilton-Zeldin
4. Diagramas de anlise de problemas
356
Os diagramas de Nassi-Shneiderman (s vezes citados como dia gramas de Chapin)
foram apresentados nos anos 70 (veja [ e Shnei derman, 19731 e EChapin, 19741) como
uma forma de reforar a estrita abordagem da programao estruturada. A figura 15.3
mostra um dia grama de Nassi-Shneidcrman tpico. Como se pode ver, o diagrama fcil
de ser lido. Entretanto, pode-se objetar que os diagramas de Nassi Shneiderman nada
mais so do que declaraes cm linguagem estruturada com quadros ao redor.
Os diagramas de Fersil so uma outra variao do fluxograma cls sico; [ 19781
apresenta uma completa descrio deles. A figura 15.4(a) mostra um diagrama de Fcrstl
tpico. Alm de mostrar a lgica seqencia! normal de programas, o diagrama de Ferstl
tambm pode ser usado para mostrar o processamento em paralelo; a notao Ferstl para
processamento em paralelo mostrada na figura 15.4(b).
Os diagramas de Jamilton-Zeldin foram desenvolvidos como parte das atividades de
desenvolvimento de software para o projeto Space Shuttle (nibus espacial) da NASA;
veja IHamilton e Zeldin, 19721. A figura 15.5 apresenta um tpico diagrama de Hamilton-
Zeldin, tambm conhecido por diagrama estruturado de projeto. Nesses diagramas, os
quadros retangulares tm o mesmo significado que os dos fluxogramas ANSI: um
comando executvel ou um grupo de comandos executveis
Figura 15.2: Umfluxograrna no-estruturado
357
Obter registro mestre
Obter registro de transao
N DO WHILE existirem mais transaes OR existirem mais registros mestres
Imprimir mestre ver - mestre <transao?
Z
atualizar mestre
dadeiro falso
obter novo mestre Imprimir mestrel imprimir erro
obter nova transao
Fechar arquivo mestre
Fechar arquivo de transaes
contnuos.Um pentgono alongado empregado para mostrar coman dos IF e iteraes
DO-WHILE/REPEAT- UNTIL. O controle flui normal mente de cima para baixq no
diagrama, exceto no caso de testes IF e de iteraes (DOs e REPEA que vo da esquerda
para a direita.
Diagramas de anlise c problemas (DAP), deseiwolvido na
Hitachi Corporation (veja IFutam Kawai, Horikoshi e Tsutsumi,
1981]), so uma representao bidimensional, com estrutura em rvore,
Figura 15.3: Um diagrama de Nassi-Shneiderman tpico
Figura 15.4 (a) Um diagrama de Fers:1 tpico
358
da lgica de programas. Os componentes dc um DAP so mostrados na figura 15.6(a).
Assim comt os diagramas de Ilamilton-Zeldin, os DAP so lidos de cima para baixo, com
as estruturas dc IF e as iteraes mos tradas da esquerda para a direita; a figura 15.6(b)
mostra um exemplo.
Como os diagramas de Ferstl, um DAP pode mostrar o processa mento em paralelo; ele
tambm utiliza uma combinao de fluxo se qencial vertical com nveis dc aninhamento
horizontais (cx.: laos dentro de laos dentro de outros laos) semelhante dos diagramas
de Hamilton Zeldin.
15.2 FLUXOGRAMAS DE SISTEMA
As abordagens de fluxogramas vistas nas sees precedentes so teis para mostrar lgica
detalhada, em um programa de computador ou em uma especificao de processo para
uma determinada bolha de um DFD. Contudo, uma viso de alto nvel da organizao de
um sistema pode ser mostrada por outro tipo de fluxograma chamado de j7u.xograma de
sistema. A figura 15.7 mostra um Jluxo8rama de sistema tpico.
.
Isso indica que o processo P composto pelos processos P1 Pn, que podem ser
executados em paralelo
Figura 15.4 (b): Notao de processamcnto cm paralelo em diagramas Fe
359
4
Figura 15.5: Um diagrama de Hamilton-Zeldin tz
ENQUANTO C PROCESSAR P
(verdadeiro)
PROCESSAR P
CONDIO
(falso)
PROCESSAR Q
Figura 15.6 (a): Componentes de um DAP
Observe que os quadros retangulares representam agregados ope racionais de software
(ex.: programas, job steps, execues e outras uni dades de software de processamento).
O fluxograma de sistema tambm mostra diversos tipos de arquivos fisicos (ex.: arquivos
em fita magntica ou em discos), podendo mostrar ainda a presena de terminais on-line
e elos de telecomunicao.
O fluxograma de sistema muitas vezes um diagrama bastante til para os projetistas de
sistemas que tm de desenvolver a arquitetura
360
AT c2 P2
P3
NQUANTOc3P4
Figura 15.6(b): Um DAP tpico
geral de hardware e software de um sistema para implementar os requi sitos do usurio.
Entretanto, minha opinio que esse recurso no uma ferramenta adequada de
modelagem para a anlise de sistemas pela simples razo de que ele enfatiza os detalhes
fisicos da implementao que o usurio e o analista de sistemas no devem discutir. Em
lugar de tecerem consideraes sobre um arquivo em disco, por exemplo, o ana lista de
sistemas e o usurio devem discutir o contedo do arquivo; em vez de falarem sobre
programas individuais eles devem discutir as funes que devem ser executadas.
Existe uma situao em que o fluxograma de sistema pode ter muita utilidade como
ferramenta de modelagem: no final da atividade da anlise do sistema, quando o modelo
de implementao do usurio esti ver sendo elaborado. Naquele ponto, o usurio, o
analista de sistemas e a equipe de implementao (projetistas e programadores) discutem
as restries da implementao que devem ser impostas ao sistema; essas restries
incluem coisas como a determinao da fronteira da automati zao (que partes do
sistema sero automatizadas e que partes sero manuais) e a interface humana (detalhes
da interao entre o sistema e os usurios humanos).
361
Figura. 15.7: Um tpico fluxograma de sistema
15.3 OS DIAGRAMAS HIPO
Os diagramas HIPO foram desenvolvidos pela IBM nos anos 70 (veja [ 1974] e EKatzan,
1976]) e tm sido utilizados por alguns analistas de sistemas para apresentar uma viso de
alto nvel das funes executadas por um sistema, bem como a decomposio de funes
em subfunes etc. A figura 15.8 mostra um diagrama HIPO tpico.
Em alguns ambientes usurios, os diagramas HIPO podem ser fer ramentas teis para
modelagem, porque se parecem com o conhecido diagrama organizacional
(organograma) que descreve a hierarquia de gerentes, subgerentes etc. Entretanto, o
diagrama no mostra os dados utilizados ou produzidos pelo sistema; embora seja
compreensvel que
362
Figura 15.8: Um diagrama HIPO tpico
algum queira deserifatizar os relacionamentos de dados em um modelo,
no creio que isso ajude a eliminar todas as informaes sobre os dados.
Em realidade existe um segundo componente do diagrama HIPO que no mostra os
dados. O diagrama mostrado na figura 15.8 conhe cido como VTOC (visual table of
contents). Cada funo representada por um quadro retangular pode ser descrita com
mais detalhes em um diagrama IPO (input-process-outpuO; a figura 15.9 apresenta um
diagrama IPO tpico.
Embora os detalhes dos dados sejam de fato mostrados nesse nvel, no o so no
diagrama VTOC de alto nvel. Assim, algum que examine uma vista geral do sistema
no ver com facilidade as interfaces entre os diversos componentes do sistema.
15.4 DIAGRAMAS ESTRUTURAIS
Uma variao dos diagramas HIPO que tem ampla utilizao o
diagrama estrutural. A figura 15.10 mostra um diagrama estrutural
363
,eniente de ATUALIZAR-CAMPO-MESTRE
ENTRADA PROCESSO: Obter transao vlida SAD
POINTER = O
CALL INICIALIZATRANS transao
REPEAT UNTIL fim do arquivo OR
fim da transao
primeiro CALL OBTER CAMPO VLIDO primeir3
carto daT IF NOT fim do arquivo or fim carto da
transao da transao transac
ENDIF COLETAR CAMPOS seguinte
ENDREPEAT
do-ar
Para: INICIALIZATRANS
OBTER CAMPOS VLIDOS
COLE1rAR CAMPOS
Figura 15.9: Um diagrama IFV tpico
tpico; observe que alm de mostrar a hierarquia funcional, ele tambm
mostra as interfaces de dados entre os componentes.
De modo diverso de muitos dos diagramas anteriores, o quadro retangular em um
diagrama estrutural no representa uma nica de clarao computacional ou um grupo
contguo de declaraes; em vez disso, ele representa um mdulo (exemplos comuns de
mdulos so sub-rotinas FORTRAN, procedimentos Pascal, subprogramas e sees
COBOL). As setas que interligam os mdulos no representam coman dos GOTO e, sim,
chamadas a sub-rotinas; a notao implica em que a sub-rotina sair ou retornar para o
ponto de onde foi chamada, ao terminar de executar sua funo.
Embora o diagrama estrutural seja mais utilizado que o diagrama HIPO, ele de fato no
tem uso na rea da anlise de sistemas. Por qu? Porque ele utilizado como uma
ferramenta de projeto para modelar a hierarquia sincrontzada de mdulos de um sistema;
sincronizada quer
364
Figura 15.10: Um diagrama estrutural tpico
dizer que apenas um mdulo executado a cada momento, o que uma acurada
representao da maneira como as coisas funcionam na maioria dos processamentos
atuais, O analista dc sistemas, por seu lado, necessita de uma ferramenta de modelagem
que lhe permita mostrar uma hierarquia de redes assncronas dc processos; isso
efetivamente realizado com o conjunto de diagramas dc fluxo de dados em vrios nveis.
O diagrama estrutural extensivamente utilizado em projeto de programas; veremos isso
detalhadamcnte no captulo 22.
15.5 VARIAES DOS DIAGRAMAS DE FLUXO DE DADOS
Como dissemos no captulo 9, existem diversas diferenas cosm ticas entre os
diagramas de fluxo de dados deste livro e os apresentados em outros livros. As principais
diferenas so, geralmente, relativas a detalhes como a utilizao de retngulos ou ovais
em lugar de bolhas para mostrar as funes executadas por um sistema; os diagramas de
fluxo de dados desenhados com ovais costumam ser chamados de dia gramas de Gane-
Sarson.
Entretanto, existe pelo menos uma significativa variao do diagra ma de fluxo de dados
clssico; essa variao conhecida como diagrama
365
SADT, tendo sido desenvolvido pela Sofiech (veja lRoss e Schornan, 19771). A figura
15.11 mostra um diagrama SADT tpico.
Embora semelhante em natureza aos diagramas de fluxo de dados mostrados neste livro,
os diagramas SADT distinguem entre fluxos de dados e fluxos de controle pelo
posicionamento das setas nos quadros retangulares. Embora certamente possa ser feito,
isso introduz algumas restries topolgicas no diagrama, o que muitos analistas de
sistemas consideram complicado.
mecanismo
de suporte
Figura 15.11: Um diagrama SDT tpico
15.6 VARIAES DOS DIAGRAMAS DE ENTIDADES- RELACIONAMENTOS
Os diagramas de entidades-relacionamentos apresentados no cap tulo 12 so
considerados pela maioria dos analistas de sistemas como sendo o recurso mais geral e
abstrato de representar relacionamentos de dados. Contudo, existem pelo menos trs
outras conhecidas notaes de estruturas de dados:
Diagramas de Bachman
Diagramas de estruturas de dados dc DeMarco
Diagramas de estruturas de dados de Jackson
Uma das formas mais conhecidas de modelos de dados o diagra ma de Bachman,
desenvolvido primeiramente por Charles Bachman na
366
dcada de 60. A figura 15.12 mostra um diagrama de Bachman tpico. Observe que ele
semelhante ao diagrama de entidades-relacionamen tos discutido no captulo 12, porm
no mostra explicitamente o relacio namento entre os objetos. Observe tambm a seta de
duas pontas: ela indica um relacionamento de um-para-muitos (ex.: um cliente pode pos
suir mais de uma casa, mas (no modelo) uma casa s pode pertencer a um cliente).
Os diagramas de estruturas de dados de DeMarco obtiveram consi dervel popularidade
nos ltimos dez anos; a figura 15.13 apresenta um diagrama de estrutura de dados tpico.
Observe que alm de mostrar cada objeto do modelo de dados, o diagrama mostra o
campo chave; como voc deve recordar, a conveno usada neste livro mostrar o campo
chave no dicionrio de dados.
Embora os diagramas de estrutura de dados de Jackson no sejam largamente utilizados
nos Estados Unidos atualmente, eles so muito populares na Inglaterra, Europa e em
outras partes do mundo; Jean Dominique Warnier, [ 19761 e Ken Orr lOrr, 19771,
desenvolve ram modelos de dados semelhantes, e que so um tanto mais populares nos
Estados Unidos. Em vez de focalizarem os relacionamentos entre os
Figura 15.12: Um diagrama de Bach man tpico
367
Figura 15.13: Um diagrama de estrutura de dados de DeMarco tipko
diferentes objetos de um sistema, os diagramas de Jackson oferecem um recurso grfico
para mostrar a estrutura hierrquica de um nico objeto. Os componentes de um diagrama
de Jackson so mostrads na figu ra 15.14(a); observe que essa mesma estrutura
hierrquica tambm pode ser documentada diretamente no dicionrio de dados
utilizando- se a notao apresentada no captulo 11, como se mostra na figura 15.14(b).
15.7 RESUMO
A lista de ferramentas de modelagem apresentada neste captulo no completa e
nenhuma das ferramentas alternativas de modelagem foi discutida detalhadamente; para
obter mais detalhes voc ter de consultar as referncias no final do captulo. Entretanto,
lembre-se que voc pode jamais ver qualquer desses diagramas em um projeto real (com
a provvel exceo do ubquo fluxograma); desse modo, no recomendo que voc
conhea profundamente os diagramas de Hamil ton-Zeldin, DAP, Fersti e outros, a menos
que voc esteja trabalhando em um projeto em que eles sejam exigidos.
Lembre-se, ainda, de que voc pode ser submetido a tcnicas de
diagramao totalmente idiossincrsicas que no tenham sido vistas
neste livro (e talvez no discutidas em nenhum livro!). Isso no deve
368
O asterisco usado para indicar iterao, e
o o usado para indicar uma opo (either-or).
Dessa forma, este modelo indica que o elemento de dados (ou objeto) X consiste em zero
ou mais ocorrncias de A, seguidas por um 8, seguido por um E. O elemento de
dados 8 consiste em um C ou um O.
Figura 15.14 (a): Um tpico diagrama de estrutura de dados deJackson
X = {A} + B + E
B = IC 1 D
Figura 15.14 (b): Notao de dicionrio de dados correspondente estrutura de
dados Jack dafigura 15.14(a)
369
deix-lo preocupado: nada existe de especialmente sagrado a respeito d ferramentas de
modelagem utilizadas neste livro. Contudo, existe uma diferena entre boas e m4s
ferramentas de modelagem; se voc se deparar com novas tcnicas de diagramao, releia
o captulo 8 para identificar os critrios para boas ferramentas de modelagem.
REFERNCIAS
1. Ned Chapin, Flowcharting with the ANSI Standard: A Tutorial, ACM Computng
Su?veys, Volume 2, Nmero 2 (junho de 1970),
pgs. 119-146.
2. Corrado B e Giuseppe Jacopini, Flow Diagrams, Turing Ma chines and Languages
with Only Two Formation Rules, Communi cation.s of lhe ACM, Volume 9, Nmero 5
(maio de 1966), pgs. 366- 371. Tambm publicado em Clas.sics in Software Engineering,
E. Yourdon (editor). Nova lorque: YOURDON Press, 1979.
3. 1. Nassi e B. Shneiderman, Flowchart Tcchniques for Structured Programming,
ACM SJGPLAN Nolice.s, Volume 8, Nmero 8 (agos to de 1973), pgs. 12-26.
4. Ned Chapin, New Format for FlowcharLs, Software - Pract and Experience, Volume
4, Nmero 4 (outubro-dezembro de
1974), pgs. 341-357.
5. O. Ferstl, Flowcharting by Stepwise Refinement, ACM SIGPL4N Notices, Volume
13, Nmero 1 (janeiro de 1978), pgs. 34-42.
6. M. Hamilton e S. Zeldin, Top-Down, Bottom-Up, Structured Pn gramming and
Program Strucluring, Charles Stark Draper Labo ratory, Document E-2728. Cambridge,
Mass.: Massachusetts Insti tute of Technology, dezembro de 1972.
7. Y. Futamura e outros, Development of Computer Programs by PAD (Problem
Analysis Diagram), Proceedin,gs of lhe F Inter national Software Engineering
Conference. Nova lorque: IEEE Computer Society, 1981, pgs. 325-332.
8. HIPO - A Design Aid and Documentation Technique, IBM Corp., Manual nr. GC2O-
1851-0. White Plains, N.Y.: IBM Data Processing
Div., outubro de 1974.
9. Harry Katzan, Jr., Systems Desi,gn and Documentalion: An Intro duction lo lhe HIPO
Melhod. Nova lorque: Van Nostrand Reinhold,
1976.
10. Doug Ross e Ken Schoman, Structurcd Analysis for RequiremenLs
Definition, IEEE Transaclion.s on Software Engineering Volume
SE-3, Nmero 1, janeiro dc 1977, pgs. 6-15. Rcimpresso em Classics
in Software Engineerng, E. Yourdori (editor). Nova lorque:
YOURDON Press, 1979.
370
11. C.W. Bachman, Data Structure Diagrams, Data Base, The Quar terly Newsletler of
lhe Special lnlerest Group on Business Data Pro cessn,g ofthe ACM, Volume 1, Nmero
2 (Vero de 1969), pgs. 4-10.
12. Tom DeMarco, Structured Analysis and Systems Speczfication. Nova lorque:
YOURDON Press, 1978.
13. Michael Jackson, Principies of Program Desgn. Londres: Academic Press, 1975.
14. Larry Peters, Software Design: Methods and Techniques. Nova lor que: YOURDON
Press, 1981.
15. Ken Orr, Structured Systems Deveiopment. Nova Jorque:
YOURDON Press, 1977.
16. Jean-Dominique Warnier, Logcal Construction of Programas, 3 ed., traduzida por B.
Flanagan, Nova Jorque: Van Nostrand
Reinhold, 1976.
PERGUNTAS E EXERCCIOS
1. Por que importante conhecer outras ferramentas de modelagem alm de DFD, DER e
DTE?
2. Quais so os trs principais componentes de um- fluxograma?
3. Projeto de Pesquisa: Que cones adicionais so s vezes utilizados em fluxogramas?
(Consulte Chapin IChapin, 1970] para maiores
informaes).
4. Quantas setas podem emanar de um quadro de processo em um fluxograma?
5. Qual a diferena entre um fluxograma e um diagrama de fluxo de dados?
6. Desenhe um fluxograma para um algoritmo de pesquisa binria.
7. Desenhe um fluxograma para um algoritmo de ordenao (sort) de simples troca.
8. Desenhe um fluxograma para uma aproximao de Newton-Ra phson para o clculo da
raiz quadrada.
9. Quais so os trs principais motivos para no se usar os fluxo- gramas?
10. Quais so as quatro principais variaes dos fluxogramas?
11. O que um diagrama de Nassi-Shneiderman? Apresente um sinni mo conhecido
para esse diagrama.
12. Desenhe um diagrama de Nassi-Shneiderman para um algoritmo de pesquisa binria.
13. Desenhe um diagrama de Nassi-Shneidcrman para uma ordenao (sorO de simples
troca.
14. Desenhe um diagrama de Nassi-Shneiderman para aproximao da funo raiz
quadrada pelo mtodo de Newton-Raphson.
371
15. O que o diagrama de Ferstl
16. Desenhe um diagrama de Ferstl para um algoritmo de pesquisa binria.
17. Desenhe um diagrama de Ferstl para uma ordenao (sort) de simples troca.
18. Desenhe um diagrama de Ferstl para o mtodo de Newton Raphson para a raiz
quadrada aproximada.
19. Por que o diagrama de Ferstl diferente de um fluxograma? O que ele pode mostrar
que o fluxograma no pode?
20. O que um diagrama de Hamilton-Zeldin? Apresente um sinnimo para esse
diagrama.Onde ele foi desenvolvido?
21. Desenhe um diagrama de Hamilton-Zeldin para um algoritmo de pesquisa binria.
22. Desenhe um diagrama de Hamilton-Zcldin para uma ordenao (sort) de simples
troca.
23. Desenhe um diagrama de 1-lamilton-Zeldin para a aproximao da raiz quadrada pelo
mtodo dc Ncwton-Raphson.
24. O que um DAP? Onde ele foi desenvolvido?
25. Desenhe um DAP para um algoritmo de pesquisa binria.
26. Desenhe um DAP para uma ordenao (sort) de intercmbio simples.
27. Desenhe um DAP para a aproximao da raiz quadrada pelo mto do de Newton-
Raphson.
28. Quais as caractersticas que os diagramas de Ferstl e os DAP tm em comum?
29. O que um fluxograma de sistema? Para que serve?
30. Em que estgio do desenvolvimento de um sistema de informaes provvel que
seja utilizado o fluxograma de sistema?
31. O que um diagrama HIPO?
32. Desenhe um diagrama HIPO mostrando o projeto de um programa para o jogo da
velha.
33. O que um diagrama de entrada-processamento-sada (input process-output - IPO)?
Qual o relacionamento entre um diagra ma IPO e o conceito HIPO?
34. Desenhe um diagrama IPO para um algoritmo de pesquisa binria.
35. Desenhe um diagrama IPO para uma ordenao (sorO de simples troca.
36. Desenhe um diagrama IPO para a aproximao da raiz quadrada pelo mtodo de
Newton-Raphson.
37. O que um diagrama estrutural?
38. Qual a diferena entre um diagrama estrutural e um diagrama
HIPO?
39. Desenhe um diagrama estrutural para um programa simples do jogo da velha.
372
40. Por que o diagrama estrutural costuma ser insuficiente como ferra menta de
modelagem da anlise de sistemas?
41. O que um diagrama SADT Qual a diferena entre um diagrama SADT e um
diagrama de fluxo de dados?
42. O que um diagrama de Bachman? Qual a diferena entre um diagrama de
Bachman e um diagrama de entidades-relacio namentos?
43. O que um diagrama de estrutura de dados de DeMarco? Qual a diferena entre um
diagrama de estrutura de dados d DeMarco e
um diagrama de entidades-relacionamentos?
44. O que um diagrama de estrutura de dados de Jackson? Qual a diferena entre um
diagrama de estrutura de dados de Jackson e
um diagrama de entidades-relacionamentos?
NOTAS
1 Como conseqncia disso, uma espeqflcao desenvolvida com fluxogramas seria
enormemente maior do que uma especificao desenvolvida com as outras ferramentas
de modelagem estudadas neste livro.
2 O fato de que qualquer lgica arbitrria de fluxograma possa ser reorganizada em seu
equivalente fluxo de alto a baixo o funda mento da programao estnsturada. Bhm e
Jacopinil2l foram os primeiros a provar que isso podia ser feito em termos de fluxogra
mas; em termos de programao, isso significa que qualquer pro grima pode ser escrito
em linguagens tipo Pascal sem comandos
GOTO.
373
1L
16
FERRAMENTAS DE
MODELAGEM PARA
GERENCIAMENTO
DE PROJETOS
Para o bem das pessoas de diferentes ti a verdade cientffica deve ser apresentada sob
diferentes aspectos, e deve ser vista como igualmente cient quer se mostre com a forma
robusta e o vivo colorido de uma ilustrao r quer com a fragilidade e palidez de uma
e4resso simblica.
James Clerk Maxwell
Address lo lhe Malhematics and Physics Section
Brit Associalion for lhe Advancement ofScience 1870
Neste captulo, aprenderemos:
1. Porque a gerncia necessita de suas prprias ferra mentas de modelagem.
2. Como desenhar diagramas PERI.
3. Como desenhar diagramas de Ganti.
4. Os relacionamentos entre as ferramentas de geren ciamento e outras ferramentas de
modelagem.
16.1 INTRODUO
Embora este no seja um livro sobre gerenciamento de projetos, devemos fazer uma
pequena pausa aqui, neste ltimo captulo sobre ferramentas de modelagem, para
apresentar algumas ferramentas de modelagem teis para se gerenciar o projeto de
desenvolvimento de um sistema; focalizaremos nossa ateno principalmente nas
ferramentas de modelagem conhecidas como diagramas PERT e diagramas de Gantt.
375
Por que voc deveria se interessar por ferramentas gerenciais de modelagem? Existem
diversos possveis motivos:
Alm de seu papel como analista dc sistemas, voc pode ser o gerente do projeto; os
analistas de sistemas juniores e os pro gramadores podem tratar diretamente com voc
durante o pro jeto. Desse modo, voc mesmo pode desenvolver seus modelos gerenciais
para apresent-los aos nveis mais elevados da di reo ou pode solicitar a um dos seus
subordinados que os desenvolva para voc.
Como o mais graduado tcnico da equipe, o gerente do projeto pode solicitar-lhe que
desenvolva modelos gerenciais para ele ou ela. Nesse cenrio, voc pode ser o aprendiz
de gerente de projeto, a quem ele d assistncia e orientao em diversos pro blemas de
natureza gerencial e tcnica.
Mesmo que voc no seja responsvel pelo desenvolvimento dos modelos, importante
conhec-los, porque eles refletem a percepo da gerncia sobre como est o andamento
dos trabalhos do projeto. Voc pode tirar suas prprias concluses sobre o provvel
sucesso ou possvel fracasso do projeto pela comparao dos modelos com a sua prpria
percepo da realidade.
A organizao do trabalho e a distribuio de pessoas para as diversas atividades, muitas
vezes conhecidas como a subdiviso das tarefas do projeto, ser habitualmente feita em
paralelo com a subdiviso tcnica do projeto. Como voc estar estreitamente envolvido
com a decomposio do sistema em suas funes e objetos de dados, voc poder ter
alguma influncia no modo como o projeto ser organizado 1
No restante deste captulo examinaremos as ferramentas de mode lagem gerencial mais
utilizadas e vamos ver como elas tratam os princi pais problemas enfrentados pelos
gerentes dc projetos. Veremos tam bm como as ferramentas de gerenciamento de
projetos relacionam-se com as demais ferramentas de modelagem de sistemas discutidas
nos ltimos captulos.
16.2 POR QUE A GERNCIA PRECISA DE MODELOS?
Existem trs principais razes para que a gerncia de projetos
precise de modelos relativos a projetos de desenvolvimento de sistemas:
376
1 IL
1. Para estimar o dinheiro, tempo e pessoal necessrios ao desen volvimento do projeto.
2. Para atualizar e rever essas estimativas durante o andamento do projeto.
3. Para gerenciar as tarefas e atividades das pessoas envolvidas no projeto.
Oramentos e estimativas so, naturalmente, uma importante ativi dade dos gerentes em
qualquer projeto; elas se constituem nas at.ivida des mais difceis em muitos projetos de
desenvolvimento porque cada projeto (ou pelo menos parece ser) indito, O apndice B
discute algumas das frmulas e alguns dos mtodos para se estimar o volume de trabalho
a ser executado em um projeto e a quantidade dc pessoas que ser necessria. Entretanto,
a gerncia necessita de modelos - e os modelos grficos so desejveis, pelos mesmos
motivos que esses modelos so teis em outros aspectos da anlise dc sistemas - para
saber quando as pessoas esto disponveis para desempenhar tarefas no projeto, o que
acontecer se essas pessoas no estiverem disponveis, e assim por diante. Esses aspectos
sero examinados detalhadamente na seo 16.5.
Mesmo o melhor dos planos, entretanto, pode fracassar se for implementado s cegas. As
circunstncias mudam continuamente duran te o projeto: os recursos fundamentais podem
no estar disponveis no exato momento em que se fazem necessrios; importantes
membros da equipe podem adoecer ou deixar o projeto; a estimativa original do volume
de trabalho a ser feito pode revelar-se inexata; o usurio pode subitamente anunciar que o
sistema precisa estar operacional um ms antes da data prevista; o gerente pode descobrir
que o trabalho est sendo feito com mais lentido que o esperado. Desse modo,
importan te para o gerente de projeto dispor dc modelos que lhe possibilitem resolver as
conseqncias das alteraes do plano.
E, por fim, o gerente de projeto deve no s chefiar tarefas, mas tambm deve chefiar
pessoas. O gerente deve assegurar que todos os analistas de sistemas, os programadores,
os projetistas de sistemas e todos os demais faam o que devem fazer no momento certo.
Assim, o gerente precisa dc ferramentas de modelagem que se focalizem nas pessoas,
alm das-que se focalizam nas tarefas.
377
16.3 OS DIAGRAMAS PERT
PERT um acrnimo para Program Evaluation Revlew Technlque. Essa tcnica foi
originalmente desenvolvida nos anos 60 como uma ferramenta de gerenciamento para o
plojeto do submarino Polaris da Marinha dos EUA; Booz Alien (a firma consultora), a
Lockhead Aircraft e a Marinha dos EUA so geralmente creditadas pelo desenvolvimento
do conceito. Os diagramas PERT tm sido amplamente usados em projetos industriais e
governamentais desde ento; muitos os denominam atual mente de diagramas de
atividades.
A figura 16.1 mostra um tpico diagrama PERT para um projeto hipottico. Cada
retngulo representa uma tarefa ou atividade (isto , uma parte reconhecvel de um
servio que precisa ser feito). Os quadros com cantos arredondados so conhecidos como
marcos, e tm um signi ficado bvio no contexto de um projeto. As linhas que interligam
os quadros mostram dependncias; isto , mostram que atividades devem ser terminadas
antes do incio de alguma outra atividade. As linhas mais grossas e escuras, que formam
um caminho contnuo do incio ao fim do projeto representam o caminho crtico, as
atividades cujo atraso causar o atraso de todo o projeto (as atividades fora do caminho
crtico tm uma folga; elas podem ser iniciadas em data mais tardia que a prevista at o
total das folgas disponveis, se assim for desejado, sem que isso afete o projeto inteiro).
4/1 Plano do projeto XYZ Ltda
Figura 16.1: Um diagrama PERT
378
Atente para o fato de que o gerente do projeto (ou um subor dinado) quem determina as
tarefas que sero dependentes de outras tarefas. Em muitos casos, a dependncia
relacionada aos dados: a ati vidade N + 1 exige, como entrada, algo que seja produzido
como sada pela atividade N. Em outros casos, a dependncia representa um ponto de
verificao do projeto (ex.: o marco N pode ser uma reunio de reviso da gerncia que
deve aprovar o trabalho feito at aquele ponto, antes que a atividade N + 1 possa ser
iniciada).
Observe que o exemplo da figura 16.1 bastante trivial: ele contm apenas dez atividades
e termina quando a atividade de anlise de siste mas comea. Um projeto tpico,
naturalmente, prossegue aps a conclu so da atividade de anlise dc sistemas e dcspcndc
um considervel volume de tempo na rea de projeto, codificao, testes etc. Na realida
de um projeto tpico ter provavelmente algumas centenas de atividades que sero
mostradas em um diagrama PFRT. Esse diagrama pode ser colocado na parede do
escritrio do gerenle do projeto, mas certamente no caberia nas pginas deste livro.
Um aspecto da maior importncia que a maioria dos projetos identifica as principais
atividades que so depois subdivididas em outras menores. Por exemplo, a figura 16.1
mostra uma atividade rotulada Conduzir atividades de anlise de sistemas. Como temos
visto neste livro, existem muitas e muitas coisas que se enquadram sob o ttulo de
conduzir anlise de sistemas: na verdade, poderamos ter um grande diagrama PERT
dedicado a essas subatividades. Assim, do mesmo modo como vimos o conceito de
diagramas de fluxo de dados em nveis no captulo 9, podemos imaginar o conceito de
diagramas PERT em nveis para auxiliar a organizar a complexidade de muitas centenas,
ou talvez de milhares, de atividades de um grande projeto.
A propsito, observe que o diagrama PERF focaliza as atividades e interdependncias
entre as atividades, mas informa pouco ou nada sobre muitos outros aspectos de um
projeto que so do interesse de um ge rente. Ele no indica, por exemplo, que pessoa ou
grupo de pessoas deve executar as diversas atividades e nada nos diz explicitamente
sobre o tempo (ou nmero de homens-dias) que cada atividade exige. Ele tambm no
mostra que produtos ou sadas so fornecidos em cada atividade. Algumas dessas
informaes so ressaltadas nos outros modelos gerenciais discutidos a seguir.
Por fim, observe que o diagrama PERT parece presumir que tudo se movimenta para a
frente, como indica a seqncia esquerda-para-a direita das atividades. Na realidade,
muitas vezes necessrio voltar e refazer algumas das atividades anteriores no caso de
serem encontrados problemas em algum estgio posterior. Esse tipo de atividade iterativa
no bem mostrada em um diagrama PERT tpico.
379
Por outro lado, o diagrama PERT mostra, com clareza, o fato de que muitas atividades
podem ocorrer em paralelo em um projeto do mundo real. Isso importante, porque
muitos dos outros modelos do projeto do a entender que as atividades devem ocorrer de
modo se qencial (veja, por exemplo, a figura 5.1). Os gerentes de projeto geral mente
querem tirar o mximo proveito possvel do paralelismo, uma vez que ele pode
abreviar o tempo necessrio para o projeto.
16.4 DIAGRAMAS DE GANTF
Um segundo tipo de modelo de gerenciamento de projetos o diagrama de Ganit, s
vezes chamado de linha cronolgica dc tarefas. A figura 16.2 mostra um diagrama de
Gantt para o mesmo projeto hipot tico utilizado na figura 16.1. Perceba que cada
atividade mostrada com a indicao de quando se inicia e de quando termina; a rea
sombreada indica o tempo de folga, enquanto as atividades em retngulos brancos so as
que pertencem ao caminho crtico.
Como se pode ver, o diagrama de Gantt apresenta quase que o mesmo tipo de
informaes que o diagrama PERT; a principal diferena que ele mostra a durao de
cada atividade 2, o que o diagrama PERT no faz. Como ele algo mais do que uma
representao tabular do
4/1 1/2 29/2 28/3 25/4
Incio
F4ar com re do usurio
Desnvolver aspectos iniciais do projeto [ instalaes do usurio
Apresentar estudo de viabilidade
Rever 9 reguladores
lnvestig alternativas financeiras
Conduzir atividades de anlise de sistemas
Apresentar resultados da anlise de siste
Figura 16.2: Um dia,grama de Gana
380
projeto, pode muitas vezes ser empregado para apresentar grandes volu mes de
informaes de forma relauvamente compacta.
16.5 FERRAMENTAS ADICIONAIS DE MODELAGEM GERENCIAL
Alm das duas principais ferramentas de modelagem acima discuti das, os gerentes do
projeto muitas vezes procuram utilizar outros diagra mas e tabelas para auxili-los a
controlar seu trabalho. Por exemplo, em vez de mostrar as tarefas como fizemos na figura
16.2, poderamos facil mente elaborar um diagrama mostrando a atividade de cada
recurso do projeto 3. A figura 16.3 mostra uma lista de recursos para o mesmo pro jeto
hipottico; ela, obviamente, seria til para se manter controle sobre as diversas atividades
sobre as quais cada membro do projeto res ponsvel. De forma semelhante, podemos
decidir que seria prtico termos uma lista das diversas atividades do projeto,
possivelmente com a indicao da data mais prxima cm que cada atividade pode ser
iniciada e a data mais tardia para seu incio sem prejudicar outras tarefas nem atrasar o
trmino do projeto.
evidente que as informaes da 16.4 so uma outra viso dos aspectos gerenciais do
projeto; ela deve ser compatvel com as ou tras vises, do mesmo modo como os modelos
DFD, DER e DTE de um sistema de informaes so compatveis entre si. Tendo criado
qualquer um dos modelos de gerenciamento do projeto, devemos poder derivar os outros
mecanicamente; voltaremos a este assunto na seo 16.7.
16.6 O RELACIONAMENTO ENTRE AS FERRAMENTAS
DE GERENCIAMENTO DE PROJETOS E AS
OUTRAS FERRAMENTAS
Qual ser o relacionamento existente entre os diagramas PERT, diagramas de Gantt e os
diversos modelos de sistemas (DFD, DER, DTE etc.) que estivemos discutindo neste
livro? O mais forte parece ser o relacionamento entre o diagrama PERT e o diagrama de
fluxo de dados:
ambos mostram as atividades (ou funes) que so executadas, e ambos tambm mostram
algumas coisas relativas interao entre essas fun es. Entretanto, o DFD no mostra
absolutamente nada a respeito da seqncia em que as funes so executadas, enquanto
o diagrama PERT indica as atividades que funcionam dc maneira concorrente e as que
so executadas de modo seqencial. Alm disso, vimos que o dia grama PERT no
mostra a sada produzida cm cada atividade, nem indica as entradas que cada atividade
exige.
381
4/1 1/2 29/2 28/3 26/4
Beth
Desenvolver aspe tos iniciais do roie
Apresentar estud de viabilidade
Rever procedime reguladores
lnvestig alterna vas financeiras
David
instal es do usurio
Apresentar estudo de viabilidade
Conduzir ativida4s de anlise de sist mas
Vary
Inicio
I insta aes do usurio
Conduzir ativida( es de anlise de sistemas
Caro 1
-i
Falar com representantes do usuano
Jos
Figura 16.3: Uma lista de recursos
Como vimos no captulo 5, os DFD podem ser utilizados para mostrar as atividades de
um projeto, e tambm as entradas e sadas; assim sendo, podem ser usados como
ferramentas de modelagem em lugar do diagrama PERT. Contudo, a maioria dos gerentes
de projeto poderiam utilizar o diagrama para que fosse mostrado o caminho crtico;
precisariam ainda de informaes adicionais, como a durao de cada atividade e o
pessoal envolvido em cada atividade. Assim, comum ver se o diagrama PERT clssico
usado em combinao com o diagrama de Gantt e com a linha cronolgica de recursos
que discutimos antes.
Mais significativo o fato de que as atividades que aparecem em
um diagrama PERT so as atividades de desenhar DFD, DER etc. Portan to, embora a
figura 16.1 mostrasse a atividade de alto nvel conduzir
382
anlise de sistemas, um diagrama PERT mais realista provavelmente mostraria uma lista
de atividades como esta:
Desenhar os diagramas de dados do novo sistema
Desenhar os diagramas de entidades-relacionamentos do novo sistema
Desenhar os diagramas de transies de estado do novo sistema
Elaborar o dicionrio de dados do novo sistema
Redigir as especificaes dc processos para as bolhas do nvel mais baixo
Equilibrar os modelos
Executar os clculos de custo/benefcio
Etc.
Como veremos na parte IV, os diagramas de fluxo de dados e outras ferramentas de
modelagem semelhantes so utilizadas para ela borar uma srie de modelos do novo
sistema. Assim, provvel que encontremos as seguintes atividades dc alto nvel:
Desenvolver o modelo amhicntal
Desenvolver a primeira verso do modelo comportamental
Refinar o modelo comportamcntal
Desenvolver o modelo de implementao do usurio
No presente momenio, nenhum desses itens deve fazer muito sen tido para voc;
discutiremos o modelo ambiental no captulo 18, o
modelo comportamental nos captulos 19 e 20, e o modelo de imple mentao do usurio
no captulo 21.
O principal aspecto a ser lembrado que as atividades que mostra mos no diagrama
PERT e nos diagramas de Gantt correspondem s ativi dades de elaborao de modelos
que vimos discutindo neste livro. claro que um diagrama PERT real para um projeto,
abrangendo todo o ciclo de vida, tambm deve mostrar as atividades de desenho
(projeto), programao, testes, converso de bancos de dados e instalao.
383
Incio Trmino Incio Trmino
Tarefa Dias mais mais mais mais
cedo cedo tardio tardio
1 Incio O 1/4/88 1/4/88 1/4/88 1/4/88
2 Falar com represen- 5 1/4/88 1/11/88 1/19/88 1/26/88
tante do usurio
3 Desenvolver aspectos 20 1/4/88 2/1/88 1/4/88 2/1/88
iniciais
4 Visitar instalaes do 4 1/11/88 1/15/88 1/26/88 2/1/88
usurio
5 Apresentar estudo de O 2/1/88 2/1/88 2/1/88 2/1/88
viabilidade
6 Rever procedimentos 10 2/1/88 2/15/88 2/15/88 2/29/88
reguladores
7 Investigar alternativas 10 2/1/88 2/15/88 2/15/88 2/29/88
financeiras
8 Conduzir atividades de 20 2/1/88 2/29/88 2/1/88 2/29/88
anlise de sistemas
9 Apresentar resultados O 2/29/88 2/29/88 2/29/88 2/29/88
Figura 16.4: Uma lista de tarefas
16.7 O PROBLEMA DA AUTOMATIZAO
Trs coisas devem ter ficado evidentes aps a discusso sobre fer ramentas de
gerenciamento de projetos deste captulo:
1. Algumas das ferramentas de modelagem envolvem grficos; portanto, para faz-las
funcionar, algum ou alguma coisa tem
que desenhar figuras.
2. Para um grande projeto do mundo real, os modelos tornam-se imensos. E, como as
coisas se modificam (como inevita velmente ocorre durante um projeto), os modelos tm
que ser refeitos. Isso acarreta um enorme volume de trabalho.
3. Todos os modelos relacionam-se uns com os outros; portanto, dispondo de suficientes
informaes sobre o projeto, algum deve ser capaz de criar um diagrama PERT, ou um
diagrama de Gantt, ou uma linha cronolgica dc recursos e tambm o adequado suporte
narrativo.
384
L
Isso leva a uma concluso bvia: seria extremanente til se as ferramentas gerenciais de
modelagem pudessem ser computadorizadas. E de fato tm sido; existem atualmente
diversos pacotes de gerenciamen to de projetos disponveis em computadores pessoais,
bem como em minicomputadores e em computadores dc grande porte . Na realidade, um
gerente de projeto do final dos anos 80 seria ingnuo em gerenciar algo alm de um
projeto trivial sem essas ferramentas automatizadas. Alm das atividades de modelagem
simples discutidas neste captulo, as ferramentas computadorizadas normalmente
possuem as seguintes caractersticas:
Capacidade de especificar o cu.slo de cada recurso do projeto. Isso de enorme auxlio
em atividades oramentrias.
Capacidade de estabelecer o calendrio dentro do qual o projeto deve correr (ex.:
feriados, horas normais de trabalho etc.). Al guns programas permitem at que cada
recurso tenha seu prprio calendrio, considerando, desta maneira, o fato de que
diferentes pessoas tm diferentes escalas de frias, e coisas desse tipo.
Capacidade de escalonar para diante ou para trs. Em um pro jeto normal, a data inicial
conhecida e o objetivo estimar quando o projeto estar pronto. Mas, em outros casos,
a data de trmino conhecida (porque um limite foi externamente im posto ao projeto), e
o objetivo determinar a data mais tardia de incio para cada uma das atividades .
Capacidade de diversos relatrios em vrios formatos.
Capacidade de interface com vrios outros programas (ex.:
planilhas eletrnicas e programas grficos).
Capacidade de mostrar a comparao entre o desempenho real e o estimado de modo a
que o gerente possa verificar o grau de exatido de sua estimativa e possivelmente us-la
como meio de reviso de estimativas futuras.
Para projetos de pequeno ou mdio porte, um pacote de geren ciamento de projetos que
funcione em um PC normalmente adequado; entre os pacotes de gerenciamento de
projetos mais conhecidos para PC esto o Microsoft Project, o Timeline e o Harvard
Project Manager. Para grandes projetos com milhares de tarefas e centenas de recursos
para gerenciar, pode ser necessrio um computador de grande porte. Alm
385
disso, muitas grandes empresas re nem os planos de projetos individuais em modelos e
oramentos agregados; desse modo, importante que cada um utilize um sistema de
modelagem compatvel com o PC ou que compartilhem um sistema maior baseado em
um computador de grande porte.
16.8 RESUMO
O gerenciamento de projetos, naturalmente, no se resume a dese nhar diagramas PERT.
O gerente de projeto tpico contrata, despede, negocia, motiva, comunica-se e persuade
programadores, analistas de sistemas, usurios e membros dos nveis mais elevados da
direo. Mas, sem as ferramentas de modelagem dos tipos descritos neste captulo,
quase impossvel para o gerente de projeto controlar as atividades, os custos e os recursos
envolvidos.
REFERNCIAS
1. Philip Metzger, Mana a Irogramming Jroject, 2* cd. Engle wood Cliffs, N.J.:
Prenticc-llall, 1983.
2. Tom Gildersleeve, Sucessful Data Imcessin,g Systems Analysis, 2* ed. Englewood
Cliffs, N.J.: Prentice-Hall, 1985.
3. Marvin Gore e John Stubbe, Elemenis of Systems Analysis, 3* cd. Dubuque, Iowa:
William C. Brown, 1983.
PERGUNTAS E EXERCCIOS
1. Apresente trs motivos pelos quais os gerentes de projeto neces sitam de modelos
relativos a projetos de desenvolvimento de
sistemas.
2. O que significa o acrnimo PERT?
3. D uma definio sucinta do diagrama PERT.
4. O que o caminho crtico em um diagrama PERT? Qual a sua importncia?
5. Que informaes relativas a um projeto o diagrama PERT no apresenta?
6. D uma definio sucinta dc um diagrama dc Gantt. Apresente um sinnimo para esse
diagrama.
7. Que informaes o diagrama dc Gantt apresenta que o diagrama PERT no mostra?
8. D uma definio sucinta de uma lista dc recursos.
386
9. Qual o relacionamento existente entre os diagramas PERT, os
diagramas de Gantt e os modelos de DFD de um sistema?
10. Qual a vantagem de termos ferramentas automatizadas para a
elaborao de diagramas PERT de Gantt?
NOTAS
1 s vezes ocorre exatamente o inverso. Como disse o consultor da
IBM George Mealy a respeito dc alguns projetos, A estrutura do
sistema isomorfa em relao estrutura da organizao que o
constri.
2 No indicamos exatamente como o gerente de projeto determina
a durao de cada tarefa. Nos casos mais simples, ele pode fazer
por si mesmo a estimativa, ou pode solicitar s pessoas incumbi
das daquela tarefa que faam essa avaliao. Se a tarefa for gran
de ou complexa, ela geralmente subdividida em atividades
menores (subatividades). As frmulas para se estimar o tempo e os
recursos de programao e coisas semelhantes so apresentadas no
apndice B.
3 Na maioria dos projetos, o recurso que temos maior interesse em
gerenciar o pessoal; mas h outros recursos, como uma mquina,
uma sala de conferncias ou qualquer outra coisa que seja (1)
necessria ao projeto em algum momento e (2) escassa o bastante
para que deva ser gerenciada.
4 Os diagramas mostrados neste capftulo foram criados usando-se o
MacProject em um computador Apple Macintosh. Existe um grupo
um tanto maior de opes de pacotes de gerncia de projetos para
o IBM PC.
5 Tom DeMarco gosta de referir-se a isso como pensamento positivo
s avessas.
387
1h
17
O MODELO ESSENCIAL
Examine a essncia das coi.sas, quer seiam aspectos de doutrina, de
prtica ou de inleipretao.
Marco Aurlio, Meditaes VIII
Neste captulo, aprenderemos:
1. Os quatro principais modelos do ciclo de vida.
2. Porque arriscado modelar o sistema atual do usurio.
3. A distino entre o modclo essencial e o modelo de implementao.
4. Como logicalizar um modelo de implementao.
Na seo anterior (captulos 9 ao 16), examinamos algumas ferra mentas dc modelagem
que todos os analistas de sistemas devem ter sua disposio. Entretanto, dc posse dessas
ferramentas, que tipo de modelos devemos elaborar? Um modelo da atual implementao
de um sistema do usurio? Um modelo da nova implementao proposta? Ou um que seja
independente da tecnologia de implementao? Ou todos esses trs? Essas perguntas
sero tratadas nos prximos captulos.
Comearemos por examinar a clssica abordagem de anlise de sistemas para
desenvolver modelos dc sistemas; como veremos, existem srios problemas com essa
abordagem. Discutiremos, em seguida, o modelo essencial, que o principal modelo da
anlise de sistemas que recomendamos construir. Por fim, discutiremos algumas
diretrizes para a
391
construo de um modelo essencial a partir dc um modelo de implemen tao existente.
17.1 A ABORDAGEM CLSSICA DE MODELAGEM E
PORQUE ELA NO FUNCIONAVA
17.1.1 Os Quatro Modelos de Sistemas
Quando a anlise estruturada foi apresentada pela primeira vez, era
comumente dito que o analista de sistemas devia desenvolver quatro
modelos distintos. Eles so mostrados na figura 17.1
O modeloflsico atual um modelo do sistema que o usurio pre sentemente utiliza. Ele
pode ser um sistema manual, um sistema automa tizado ou uma combinao das duas
coisas. Geralmente, os processos (bolhas) do diagrama de fluxo de dados do sistema
fisico atual rccebem os nomes das pessoas, dos setores da emprc.sa ou dos sistemas dc
pro cessamento que executam o trabalho de transformar entradas em sadas. Um exemplo
disso mostrado na figura 17.2. Observe tambm que os fluxos de dados geralmente
mostram formas fsicas de dados sendo transportados de bolha em bolha; alm disso, os
depsitos de dados podem ser representados por pastas de arquivos, arquivos em fitas
magnticas ou alguma outra tecnologia.
O novo modelo lgico um modelo dos requisitos puros ou essen ciais do novo sistema
que o usurio deseja. No caso ideal (do ponto de vista do analista de sistemas), ele igual
ao modelo lgico atual, isto , contm as mesmas funes e os mesmos dados. Essa
situao pode ocorrer se o usurio estiver plenamente satisfeito com a funcionalidade do
sistema atual, mas no com a implementao Na maioria dos casos, entretanto, o usurio
solicita novas funes: Aproveite, e inclua uma nova transao para cuidar da seguinte
situao.... Ou o usurio pode solicitar que o sistema controle uma nova forma de dados.
Desse modo, embora 80 a 90% dos novos modelos lgicos possam ser idnticos ao
modelo lgico atual, provvel que haja pelo menos algumas pequenas modificaes e
acrscimos.
O modelo lgico atual um modelo dos requisitos puros ou essen ciais executados pelo
sistema atual do usurio. Assim, so suprimidos os detalhes arbitrrios d implementao
e o modelo resultante mostra o que o sistema faria se uma perfeita tecnologia estivesse
disponvel 2 A figura 17.3 mostra um exemplo de um modelo lgico atual.
O novo modelo fisico mostra as restries de implementao im postas pelo usurio.
Uma das restries mais importantes a determina o das fronteiras da automatizao
(isto , a determinao de que funes no novo sistema sero automatizadas e quais sero
executadas
392
modelo lgico atual
novo modelo lgico
novo modelo fsico Figura 17.1: Os quatro modelos de sistema
393
contrato do projeto
atual
pedidos
acarbonodo formulrio 2107
CAIXA DE ENTRADA
formulrio 2107
ARQUIVO DE PEDIDOS
COMPUTADOR DE PROCES SAMENTO
blocos de DE PEDIDOS
tamanho fixo
manifesto de em ba rq u e
FUNCIONRIO
DO
EMBARQUE
lista de emba
pedidos
Figura 17.2: Um modelo fsico atual
pedido invlido
relatrio de pedid
fatura
Figura 17.3: O modelo lgico atual
394
manualmente). O novo modelo fsico corresponde ao que agora deno minamos de modelo
de implementao do usurio, que discutiremos mais detalhadamente no captulo 21.
17.1.2 Porque a Aborda8em Clssica No Funcionava
A abordagem clssica, que acabamos dc descrever, baseava-se em
trs importantes suposies:
1. O analista de sistemas pode no conhecer a aplicao ou o ra mo comercial: ele pode
ser um perito em tecnologia de processamento de dados, mas conhecer apenas
superficial- mente as atividades bancrias, dc seguros, de controle de inventrios de
material ou de qualquer outra rea em que o usurio trabalhe. Por causa disso,
importante que o analista de sistemas comece por um modelo fsico atual como meio de
se auto-instruir. O modelo desenhado ser fcil de verificar, por que conter diversos
marcos fsicos que podem ser observa dos no ambiente fsico atual. Aps ter obtido o
conhecimento necessrio, o analista de sistemas pode prosseguir, transfor mando o
modelo fsico cm modelo lgico.
2. O usurio talvez no queira ou no possa trabalhar com o novo modelo lgico no incio
do projeto. O motivo mais comum para isso a desconfiana na capacidade do analista
de sistemas em desenvolver o modelo lgico do novo sistema. Mesmo que o analista de
sistemas julgue ser perito na rea da empresa do usurio, este pode no concordar. Por
que devo confiar em que voc desenhar um novo sistema para mim, perguntar ele, se
voc nem sequer sabe como funciona minha empresa atualmente? Alm disso, alguns
usurios consideram difcil examinar um modelo abstrato do sistema sem marcos re
conhecveis; eles podem precisar dc um modelo do sistema fsico atual como meio de se
familiarizarem com o processo de anlise estruturada e de se certificarem de que o
analista no deixou de lado alguma coisa (uma alternativa a abordagem de protoupao
discutida no captulo 5).
3. A transformao do modelo lgico atual em um novo modelo lgico no exige muito
trabalho e, cm particular no exige muito desperdfcio de trabalho. Como j dissemos, o
usurio normalmente acrescentar algumas novas funes, ou novos dados, ao sistema
existente, mas a maior parte do sistema lgico existente (ou talvez todo ele) permanecer
intacta.
395
Essas suposies revelaram-se corretas cm muitos projetos. Entre tanto, elas ignoram um
risco muito maior: o processo de desenvolvimen to de um modelo do s alua/pode tomar
tanto tempo e esforo que o usurio poder se tornar fn e impaciente, chegando ao ponto
de cancelar o projeto. Para entender este problema, lembre-se do seguinte:
Alguns usurios (e alguns gerentes e programadores-analistas) vm qualquer forma de
anlise de sistemas como uma perda de tempo - um modo de descansar antes que o
trabalho ver dadeiro (isto , a codificao) se inicie.
Muitos usurios tm compreensveis dvidas sobre os mritos da cuidadosa modelagem
de um sistema que, por definio, ser superado e substitudo como resultado do
desenvolvimento do novo sistema.
O problema ocorre com mais freqncia porque o analista de sistemas se envolve com a
tarefa da modelagem do sistema atual e passa a encar-la como um fim em si mesma.
Assim, em vez de apenas desenhar o(s) diagrama(s) de fluxo de dados e documentar
somente as. principais especificaes de processos, o analista de sistemas muitas vezes
desenha todos os diagramas de fluxos de dados, documenta todas as especificaes de
processos e desenvolve um dicionrio de dados completa
Infelizmente, essa abordagem quase sempre envolve um grande desperdcio de tempo.
Pode-se, de fato, esperar que cerca de 75% do modelo fsico sejam jogados fora na
transio do modelo fsico para o modelo lgico atual; ou, em outras palavras, o modelo
fsico atual tipicamente trs ou quatro vezes maior que o modelo lgico atual. Isso se
deve redundncia (a mesma funo executada cm vrias partes do sistema atual e
diversos elementos dc dados so duplicados ou triplica dos) e verificao, validao e
correo de erros, que so adequadas no sistema fsico atual mas no no sistema lgico
atual .
Isso tudo pode parecer um tanto bvio para o leitor ocasional. Entretanto, projeto aps
projeto, os analistas dc sistemas tm-se visto to envolvidos no processo de modelagem
que esqueceram o objetivo final do usurio: um sistema que funcione. Como disse Steve
McMenamin (co-autor de lMcMenamin e Palmer, 198ll), As bolhas no so
compilveis .
Em conseqncia, este livro recomenda que o analista de sistemas evite, tanto quanto
possvel, modelar o sistema atual do usurio. As ferramentas de modelagem discutidas na
parte II devem ser utilizadas para, assim que for possvel, desenvolver um modelo do
novo sistema
396
desejado pelo usurio. Esse novo sistema, mencionado na literatura sobre a anlise
estruturada clssica como o novo sistema lgico, aqui tratado como o modelo essencial
do sistema.
Ocasionalmente pode haver uma situao em que o analista de sistemas deva construir o
modelo do sistema atual do usurio; isso ocor re, por exemplo, quando o analista de
sistemas precisa modelar o siste ma fsico atual para descobrir quais so, de fato, os
processos essenciais. Esta situao abordada com mais detalhes na seo 17.3.
17.2 O MODELO ESSENCIAL
17.2.1 Oque
O modelo essencial do sistema indica o que o sistema deve fazer para satisfazer os
requisitos do usurio, mencionando o mnimo possvel (de preferncia nada) sobre como
o sistema ser implementado. Como foi dito, isso significa que o nosso modelo de
sistema pressupe que dispomos de perfeita tecnologia e que pode ser obtido a custo
zero.
De uma forma especfica, isso significa que quando o analista de sistemas conversar com
o usurio sobre os requisitos do sistema, deve evitar descrever as implementaes
especficas dos processos (bolhas do diagrama de fluxo de dados) do sistema; isto , ele
ou ela no deve mostrar as funes do sistema executadas por pessoas ou por um siste ma
de processamento j existente. Como as figuras 17.4(a) e (b) demons tram, essas so
opes arbitrrias de como o sistema poderia ser imple mentado; mas uma deciso que
deve ser protelada at que se inicie a atividade de projeto do sistema . A figura 17.4(c)
mostra um modelo essencial mais adequado do que a funo do sistema deve executar
independentemente de sua implementao.
Isso tambm vale para fluxo de dados e depsitos de dados: o modelo essencial deve
descrever o contedo dos fluxos e dos depsitos de dados, sem considerar o meio (isto ,
disco ou fita) ou a organizao fsica dos dados.
17.2.2 Dificuldades na Construo do Modelo Essencial
Apesar de as diretrizes acima poderem parecer simples e bvias, muitas vezes torna-se
bastante difcil eliminar completa mente do mode lo essencial todos os detalhes da
implementao. Os exemplos mais comuns de detalhes de implementao so os
seguintes:
397
Seqncia arbitrria de atividades em um modelo de fluxo de dados. A nica seqncia
no diagrama de fluxo de dados deve ser a que exigida pelos dados (isto , a bolha 2
pode exigir um elemento de dado produzido pela bolha 1 e, por isso, no pode iniciar seu
trabalho at que a bolha 1 tenha terminado o dela) ou pelos eventos externos ao sistema.
Arquivos desnecessrios, depsitos de dados que no seriam necessrios se estivesse
disponvel a tecnologia perfeita. Os ar quivos temporrios (ou intermedirios) fazem-se
necessrios em um modelo de implementao porque os processos so escala dos para
funcionar em momentos diferentes (ex.: um programa em batch executado durante a noite
produz um arquivo utili zado pelo sistema diurno, on-line); eles tambm so intro duzidos
nos modelos de implementao para fins de backup e recuperao, uma vez que a
tecnologia da implementao propensa a erros, assim como as pessoas que operam os
computadores.
Desnecessrias verifica es de erros e validao de erros e processos dentro do
sistema. As atividades de validao so necessrias em um modelo de implementao por
ser necess rio trabalhar com processos tendentes a erros (ex.: algumas funes so
executadas por seres humanos que so notoria mente sujeitos a erros) e por ruidosos
caminhos de dados entre esses processos.
Dados redundantes ou derivados. Por vezes so includos ele- - mentos de dados
redundantes em depsitos de dados em prol da eficincia; embora isso normalmente seja
razovel, deve ser feito durante a fase de projeto e no durante a modelagem das
folhas de tempo
ARQUIVO DE EMPREGADOS
Figura 17.4 (a): Um modelo de como uma funo do sistema executa sua tarefa
398
cartes de tempo
Figura 17.4 (b): Outro modelo de como a/uno ser executada
horas trabalhadas
EMPREGADOS
Figura 17.4 (c): Um modelo do que a/uno
funes e dados essenciais. Alm disso, o analista de sistemas pode inadvertidamente
incluir elementos de dados que podem ser derivados, ou calculados, a partir dc valores de
outros ele mentos de dados.
17.2.3 componentes do Modelo Essencial
O modelo essencial composto por dois principais componentes:
1. O modelo ambiental
2. O modelo comportamental
O modelo ambiental define a fronteira entre o sistema e o resto do mundo (isto , o
ambiente onde reside o sistema). Ele ser discutido com
399
mais detalhes no captulo 19; como veremos, ele compe-se de um dia grama de
contexto, uma lista de evcntos e uma pequena descrio do propsito do sistema.
O modelo comportamcntal descreve o comportamento, do interior do sistema, necessrio
para intcragir com sucesso com o ambiente. Os captulos 20 e 21 descrevem uma
estratgia para se derivar o modelo comportamental; o modelo compe-se dos conhecidos
diagramas de fluxo de dados, diagramas de entidades-relacionamentos, diagramas de
transies de estado, itens do dicionrio de dados e especificaes de processos que j
estudamos anteriormente neste livro.
17.3 O QUE FAZER SE VOC TIVER QUE ELABORAR UM MODELO DE
IMPLEMENTAO
Como j foi dito neste captulo, existem circunstncias em que voc pode achar
necessrio ou desejvel elaborar um modelo de implementa o antes dc construir o
modelo essencial do sistema. Isso geralmente ocorre porque o usurio no est
convencido de que voc conhece o assunto suficientemente bem para modelar um novo
sistema, ou porque voc decidiu que precisa estudar o ambiente atual antes dc propor o
novo sistema.
Se voc decidir continuar nessa modalidade, a primeira coisa a ser lembrada que seu
principal objetivo obter o conhecimento e uma viso geral do sistema existente. No
seu objetivo documentar o siste ma atual em suas mincias. Dessa forma, ser
provavelmente til e ade quado criar um ou mais nveis de diagramas de fluxo dc dados
para o sistema atual; ser tambm provavelmente adequado elaborar um dia grama de
entidades-relacionamentos. Tambm poderia ser til escrever especificaes de processos
para algumas das mais crticas (ou obscuras) funes do sistema; podena ser til reunir
alguns dos documentos fsicos que representariam um dicionrio de dados fsico. Mas
voc no deve tentar escrever especificaes de processos para todas as funes nem
desenvolver um completo dicionrio de dados para o sistema existente.
Quando tiver terminado dc desenvolver o modelo da implemen tao atual, sua prxima
tarefa torn-la lgica (isto , suprimir tantos detalhes orientados para a implementao
quantos forem possveis). Isso normalmente abrange as seguintes etapas:
Procure os fluxos essenciais que tenham sido arbitrariamente reunidos e separe-os. Por
exemplo, voc pode descobrir que no sistema atual diversos elementos de dados so
transmitidos jun tos a partir de um computador para outro atravs de um elo de
telecomunicao comum; ou que alguns elementos de dados
400
no relacionados so copiados em um formulrio de papel a ser transmitido para diversas
funes.
Procure fluxos a,gregados ou empacotados que sejam remetidos para bolhas
(representando pessoas, computadores etc.) que no necessitam de todos os dados desses
fluxos. Assim, a figura 17.5(a) mostra um processo, CAI.CULAR FATOR FRAMMIS,
que exige apenas o elemento de dado X; enquanto isso, outro processo, CALCULAR
FATOR WIDGET, exige somente o ele mento de dado Y. Por convenincia, a
implementao atual empacotou X e Y em um elemento de dado agregado Z; a logi
calizao deste modelo resulta no diagrama de fluxo de dados mostrado na figura
17.5(b).
Faa a distino entre o trabalho essencial feito por um processo e a idenl do processador
mostrado no modelo de implementao. O processador pode ser uma pessoa ou um
computador ou qualquer forma de tecnologia; e um processador individual pode executar
fragmentos de um ou mais processos essenciais ou, em sua inteireza, executar mltiplos
processos
fator
framm is
401
x
fator widget
Figura 17.5 (a): (Jm modelo fi
r
fator widget
essenciais. Como veremos no captulo 20, os processos essen ciais devem ser agrupados
se forem provocados pelo mesmo evenio externo.
Elimine os processos cujo nico propsito seja o de Ira nsporlar dados de um ponto a
outro do sitema. Elimine tambm as bo lhas responsveis pelas entradas e sadas fsicas
entre o sistema e o ambiente externo. O modelo fsico de um sistema pode mostrar, por
exemplo, uma funo dc correio ou de entrega de mensagens; ela deve ser eliminada do
modelo essencial. Mui tos DFD fsicos tm processos com nomes como obter entra da
do usurio ou imprimir relatrio que tambm devem ser eliminados.
Elimine os processos cuja tarefa seja verificar dados que sejam produzidos e utilizados
no interior do sistema. Como estamos pressupondo perfeita tecnologia no modelo
essencial, esses tes tes internos e verificacs cruzadas no so necessrios. , con tudo,
aconselhvel, introduzir veriflcacs dc erros para dados provenientes do ambiente
externo e trazidos para o sistema. Dessa forma, os processos cujos nomes sejam dupla
verifica o ... ou verificar ... ou validar ... ou editar ... devem ser
x
Y
Figura 17.5 (b); A verso com lRica
402
vistos com suspeita, a menos que estejam nas fronteiras do sis tema e lidem com entradas
externas.
Venfique a presena de situaes em que depsitos essenciais tenham sido a no mesmo
depsito de implementao (ex.: arquivos cm disco, arquivos em fita OU cm papel); isso
muito comum cm sistemas de segunda gerao e em sistemas que tenham sido
otimizados durante um perodo dc alguns anos para manipular grandes volumes dc dados
com eficincia. Sepa re o contedo do depsito do meio dc armazenamento.
Remova dos depsitos quaisquer elementos de dados se no forem utilizados por
qualquer processo; alm disso, remova tambm dos depsitos os elementos de dados que
possam ser calculados ou derivados diretamente de outros elementos de dados (observe
que elementos dc dados derivados e cpias redundantes dc elementos dc dados podem ser
reinseridos mais tarde, quando o modelo Je implementao for desenvolvido durante a
fase de projeto de sistemas).
Para finalizar, supnma todos os depsitos de dados que existam entre processos apena.s
como retardos dependentes da imple mentao. Isso inclui arquivos intermedirios,
arquivos dc re latrios, arquivos spool e outros congneres.
17.4 RESUMO
O conceito de modelo essencial aparenta ser algo muito natural, mas ele no to fcil dc
ser pcparado cm projetos do mundo real como se pode pensar. A maioria dos usurios
est to envolvida nos detalhes da implementao dc seu sistema atual que para eles
difcil entender a viso de tecnologia perfeita dc um sistema. E isso tambm difcil
para muitos analistas dc sistemas veteranos, porque passaram tantos anos construindo
sistemas que para eles se torna difcil evitar fazer suposies de implementao ao
descreverem um sistema.
Lembre-se que de suma importncia desenvolver o modelo es sencial de um sistema,
porque (como j foi dito diversas vezes neste livro) a maioria dos grandes sistemas de
informaes tem um ciclo de vida de 10 a 20 anos. Durante esse perodo de tempo
podemos contar com o aperfeioamento da tecnologia de hardware de computadores por
um fator de mil, no mnimo, e provavelmente prximo de um fator de um milho ou
mais. Um computador que seja um milho de vezes mais rpido, menor e mais barato que
um computador atual est, de fato,
i03
prximo da perfeita tecnologia; preciso comearmos hoje a ri nossos sistemas como se
j dispusssemos dessa tecnologia.
REFERNCIAS
1. Tom deMarco, Structured A nalysis and Systems Speqflcatlon. Nova
lorque: YOURDON Press, 1978.
2. Chr Gane e Trish Sarson, Slructured Systems Analyszs: Tools and
Techniques. Englewood Cliffs, N.J.: Prentice-Hall, 1978.
3. Edward Yourdon, Managing lhe Systems L Cycle, Nova lorque:
YOURDON Press, 1982.
4. Victor Weinberg, Stnsctured Analysis, Nova lorque: YOURDON
Press, 1978.
5. Steve McMenamin e John Palmcr, Essential Systems Analysis, Nova
lorque: YOURDON Press, 1984.
PERGUNTAS E EXERCCIOS
1. Quais so os quatro modelos recomendados pelos livros clssicos
sobre anlise de sistemas?
2. O que o modelo fsico atual?
3. D trs exemplos de processos fsicos (Ix)lhas).
4. D trs exemplos de depsitos flsicos.
5. D trs exemplos de fluxos de dados fsicos.
6. O que um o modelo lgico atual?
7. Qual a diferena entre o modelo fsico atual e o modelo lgico
atual?
8. O que tecnologia perfeita no contexto deste captulo?
9. O que o novo modelo lgico?
10. Qual a diferena entre o modelo lgico atual e o novo modelo
lgico?
11. Sob quais circunstncias podem ser iguais o modelo lgico atual e
o novo modelo lgico de um sistema?
12. Que grau de sobreposio deve o analista de sistemas esperar que
ocorra entre o modelo lgico atual e o novo modelo lgico de um
sistema?
13. O que o novo modelo fsico?
14. Apresente um outro nome para o novo modelo fsico.
15. Qual a principal restrio descrita pelo novo modelo fsico?
16. Quais so as trs principais suposies em que se apia a abor
dagem clssica da anlise estruturada?
/404
17. Projeto de Pesquisa: Em sua organizao, qual o percentual de projetos que tm
analistas de sistemas que no esto intimamente familiarizados com o ramo dc negcios
do usurio? Em sua opinio, esse percentual aceilvel? Ele est se modificando?
18. Quais so os dois maiores motivos para que o usurio encontre dificuldades em ler e
compreender um modelo lgico?
19. Qual o principal problema com a abordagem clssica da anlise estruturada?
20. Por que alguns usurios tm dvidas sobre os mritos de se modelar seu sistema
atual?
21. Que frao do modelo fsico atual ser provavelmente desprezada na transio para o
modelo lgico atual?
22. Quais so os motivos para que o modelo f atual seja to maior que o modelo lgico
atual dc um sistema?
23. Apresente um sinnimo para o novo modelo lgico.
24. Que tipo de verificao de erros adequada em um modelo lgico? Que tipo no ?
Por qu?
25. D uma definio do modelo essencial de um sistema.
26. O que significa protelao construtiva no contexto deste livro?
27. Quando, no projeto de desenvolvimento de sistemas, deve-se decidir se a
implementao de uma funo (isto , um processo do
DFD) ser feita com uma pe.ssoa ou com um computador?
28. Quais so os quatro erros ou enganos comuns normalmente cometidos ao tentarem
criar um modelo essencial?
29. Por que os arquivos temporrios no devem aparecer em um modelo essencial?
30. Quando os arquivos temporrios devem ser mostrados em um modelo de sistema? Por
qu?
31. Quando os dados redundantes devem ser mostrados em um modelo de sistema?
32. Quando dados derivados devem ser mostrados em um modelo de sistema?
33. Quais so os dois componentes do modelo essencial de um sistema?
34. Para que serve o modelo ambiental de um sistema?
35. Para que serve o modelo comportamental de um sistema?
36. Se voc tiver que documentar a implementao atual de um sistema, o que voc deve
ter o cuidado de evitar?
37. uma boa medida documentar todos os fluxos de dados da implementao atual de
um sistema? Por qu?
38. uma boa medida documentar todas as especificaes de processos da
implementao atual de um sistema? Por qu?
39. uma boa medida documentar todos os elementos do dicionrio de dados da
implementao atual dc um sistema? Por qu?
405
40. Quando se introduz lgica (logicaliza) o modelo fsico atual, o
que se deve fazer com os fluxos essenciais que tenham sido
empacotados no mesmo meio?
41. Quando se logicaliza o modelo fsico atual, o que se deve fazer
com fluxos empacotados enviados para processos que no necessi
tam de todos os dados?
42. Quando se logicaliza o modelo fsico atual, o que se deve fazer
com os processos cujo nico propsito seja transportar dados de
um lugar para outro?
43. Quando se logicaliza o modelo fsico atual, o que se deve fazer
com as bolhas cujo nico propsito seja o de verificar dados que
so criados dentro do sistema?
44. Quando se logicaliza o modelo fsico atual, o que se deve fazer
com os depsitos essenciais que tenham sido empacotados no
mesmo meio?
45. Quando se logicaliza o modelo fsico atual, o que se deve fazer
com os elementos de dados que existem nos depsitos mas que
no so utilizados em lugar algum do sistema?
46. Quando se logicaliza o modelo fsico atual, o que se deve fazer
com os arquivos temporrios encontrados no sistema fsico atual?
NOTAS
1 Existem muitos possveis motivos para isso, O sistema pode estar
implcmentado em hardware j obsoleto ou cujo fabricante j esteja
fora do mercado. Pode acontecer tambm o sistema ter mau de
sempenho ou tempo de resposta inadequado. O usurio pode
solicitar que alguns dados de manuteno manual (ex.: arquivos
em papel) sejam computadorizados. Ou, o que ocorre cada vez
mais nos dias dc hoje, o software pode estar to mal documentado
que j no pode mais ser mantido ou modificado.
2 Perfeita tecnologia pode ser interpretada como hardware que nada
custa, que no ocupa espao, que no consome energia nem gera
calor, que funciona cm velocidade infinita (isto , que execute
qualquer operao em tempo zero), que armazena um volume
infinito dc dados, que podem ser recuperados individualmente ou
todos de uma vez cm tempo zero e como o computador que
nunca, jamais, quebra nem comete erros.
3 Sem considerarmos se estamos construindo um modelo lgico
(essencial) ou fsico (de implementao), costuma ser apropriado
executar algumas verificaes de erros de dados que entram no
sistema a partir do mundo exterior. Entretanto, como os dados so
transmitidos de ponto para ponto dentro do sistema, o modelo
406
lgico (essencial) no faz verificacs de erros por presumir que o sistema ser
implementado com tecnologia perfeita. No modelo fsico (de implementao),
pnncipalmente em um modelo do sistema fsico atual, a verificao dc erros vital
porque (1) parte do processamento tende a ter erros, mormente quando executada por
pessoas, (2) o transporte dc dados dc um processo para outro pode ser propenso a erros,
dependendo do meio de comunicao empregado e (3) o armazenamento e a recuperao
de dados de depsitos fsicos de dados pode ser uma atividade tambm propensa a erros.
4 Eventualmente as bolhas podem ser compiladas. Isto , a combi nao de diagramas dc
fluxos dc dados, de dicionrios de dados e de rigorosas especificaes dc processos
podem ser a entrada de um gerador de cdigo que produz programas executveis. Entre
tanto, mesmo nesse caso, o esforo para produzir um modelo flsico completo e detalhado
um desperdcio dc tempo. Ningum quer uma rplica computadorizada do sistema
atual.
5 Existe um nome popular para iSSO: protelao construtiva. Meu colega Steve Weiss
prefere protelao de segurana que menos pejorativo, e que , na verdade, o
princpio em que se baseia a abordagem top-down.
407
18
O MODELO AMBIENTAL
A estabilidade do meio inwrno a condio bsica para a liberdade e
independncia de certos Corpos viventes era relao ao ambiente que os
cerca.
Claude Bernard, Leons sur les Phenomnes de la
Vie Communs au.x Animaux ei aux Vegetaux, 1875-1879
Neste captulo, aprenderemos:
1. Porque as fronteiras do sistema so arbitrrias porm fundamentais.
2. Como desenhar um diagrama dc contexto para um sistema.
3. Como produzir urna lista dc evcntos para um sistema.
4. Como usar o diagrama de contexto e a lista de cven tos para construir o modelo
arnl)iental.
Para o analista de sistemas, a tarefa mais difcil na especificao de um sistema , muitas
vezes, a determinao dc) que faz parte dc) sistema e o que no faz. Qualquer sistema que
voc desenvolva, no importando quo ambicioso ou grandioso, far parte de um sistema
ainda maior. Como foi visto no captulo 2, virtualmente todos os sistemas com os quais
temos experincia humana so, meramente, subsistemas dc siste mas ainda maiores:
mesmo se nossa tarefa fosse projetar o mundo, teramos que reconhecer que o mundo
somente uma parte do sistema solar, que parte de uma galxia pequena e obscura, que
(afinal de contas) parte do universc).
409
Desse modo, o primeiro modelo importante que voc deve dcsen volver como analista de
sistemas um que no faa nada mais do qu definir as interfaces entre o sistema e o resto
do universo, isto , o am bente. Por razes bvias, esse modelo conhecido como model
ambiental. Ele modela a parte exterior do sistema; o modelo do interio:
do sistema, conhecido como modelo comporsamenial, ser discutido no captulos 20 e
21.
Alm de determinar o que est dentro do sistema e o que est fora (o que se consegue
pela definio da fronteira entre o sistema e o am biente), tambm fundamentalmente
importante definir as interfac entre o sistema e o ambiente. Precisamos conhecer que
informaes pe netram no sistema provenientes do ambiente externo, e devemos
conhecer que informaes que o sistema produz como sadas para serem transmitidas ao
ambiente externo.
Naturalmente, entradas e saidas no So produzidas ao acaso:
nenhum sistema de informaes engloba todos os dados disponveis do universo, nem
qualquer sistema real emite sadas alcatoriamcnte para consumo do ambiente externo. Os
sistemas que construmos so racionais e objetivos; especificamente, eles produzem
sadas como resposta a um evento, ou a um estmulo, do ambiente. Desse modo, um outro
aspecto bsico do modelo ambiental a identificao dos even tos que ocorrem no
ambiente aos quais o sistema deve rea,gfr Nem todos os eventos, isto , o ambiente cm
sua totalidade, gera um n mero infinito de eventos! Estamos interessados apenas nos
evenLos que (1) ocorrem no ambiente externo, e (2) exigem uma resposta do sistema.
Observe, que a fronteira entre um sistema e seu ambiente, como se pode ver na figura
18.1, arbitrria. Ela pode ser estabelecida por deter minao da direo, ou como
resultado de uma negociao poltica, ou, simplesmente, por acidente. E algo cm que o
analista de sistemas, habitualmente, tem alguma oportunidade de influenciar.
Em geral, o usurio tem uma boa idia dos limites gerais entre o sistema e o ambiente.
Mas, como ilustrado na figura 18.2, existe muitas vezes uma rea cinzenta aberta para
negociaes, uma rea em que o usurio (1) no est muito seguro, (2) ainda no pensou,
(3) tem algu mas idias preconcebidas que precisam ser repensadas, ou (i) tudo isso em
conjunto.
Assim, para exemplificar, o usurio poder solicitar ao analista de sistemas o
desenvolvimento de um sistema de contas a receber. Embora isso possa representar uma
fronteira bem definida e firme entre o sistema (conhecido como o sistema C/R) e o
ambiente, o analista de sistemas deve considerar a rea cinzenta, ilustrada pela figura
18.3, de contas a pagar, controle de inventrio, controle de caixa, faturamcnto, e controle
de pedidos como uma abrangncia um tanto maior.
410
Figura 18.1: A fronteira entre o sistema e o ambiente
Figura 18.2: A rea cinzenta entre o sistema e o ambiente
411
Figura 18.3: A rea cinzenta em torno do sistema de contas a receber
Se o analista de sistemas escolher um escopo demasiado pequenc para um projeto, ele
est predestinado ao fracasso, porque o usurio pode ter sabiamente identificado o
sintoma do problema (p.ex., nossas contas a receber esto fora de controle) em vez da
causa do problema. E, se o analista de sistemas, por excesso de confiana, ingenuidade ou
exuberncia escolher um escopo grande demais para o projeto, ele estar predestinado a
falhar, porque estar lidando com uma situao poltica muito mais complexa, e estar
tentando desenvolver um sistema que ser provavelmente grande demais para ser
desenvolvido sob quaisquer circunstncias. E ele podcr estar lidando com problemas
com que o usurio no se importa ou que no podem ser modificados de forma alguma.
Desse modo, importante gastar o tempo que foi necessrio e obter suficiente
participao do usurio na escolha de uni limite de sistema propriado.
Em um grande sistema, podem ser considerados alguns fatore
quando o escopo do projeto est sendo escolhido. Entre os fatores mai5
importantes esto:
412
\
O desejo do usurio em obter uma certa fatia do mercadT para o produto ou para
aument-la alm do seu nvel atual. Isto poderia ser feito pela oferta dc um novo produto
ou pelo aumento da funcionalidade de um produto existente (p.ex., maior funcionalidade
oferecida pelos sistemas de caixa au tomtico e sistemas bancrios domsticos on-line).
Ou o usurio poderia tentar aumentar a participao no mercado pela oferta de um
servio melhor e mais rpido (p.ex., Todos os nossos pedidos so remetidos em 2i
horas, e temos um sofisticado sis tema que localiza o seu pedido, possibilitando-nos saber
onde ele est a qualquer momento).
A legislao decretada pelo governo municipal, estadual, oufe deral. A maioria desses
sistemas de sistemas de relatrios, por exemplo, sistemas que informam o emprego (ou
desemprego) de trabalhadores com base na idade, sexo, nacionalidade e as sim por diante.
Ou um novo sistema poderia ser construdo para acomodar alteraes nas leis de
impostos.
Um desejo do usurio em minimizar os gastos operacionais de alguma rea da sua
empresa. Isso era especialmente comum em grandes companhias nos anos 60 e
verdadeiro para muitas empresas pequenas que esto instalando hoje seu primeiro
computador. Porm a maioria das organizaes que tm compu tadores instalados h 10
anos ou mais j se beneficiou das evi dentes oportunidades de reduzir o excesso de
funcionrios.
Um desejo do usurio em obter alguma vantagem estratgica para a linha de produtos
ou rea de negcios que ele est ope rando. O usurio poderia tentar fazer isso
organizando e geren ciando informaes sobre o mercado para que ele possa pro duzir
mercadorias dc urna forma mais oportuna e econmica. Um bom exemplo disso so as
linhas areas (bem como muitas outras indstrias que tiveram, recentemente, suas
restries abolidas) onde melhores informaes sobre tendncias de mer cado e
preferncias dos clientes podem conduzir a escalo namentos e preos mais eficientes.
A rea dentro das fronteiras do sistema algumas vezes chamada de domnio da mod
Com isso queremos simplesmente dizer que tudo que estiver no interior das fronteiras do
sistema est sujeito a modificaes (p.ex., reorganizao e/ou automatizao), enquanto
tudo que estiver fora dos limites dever permanecer na sua forma atual, no sendo
examinado pelo analista de sistemas.
413
Para ver dois exemplos dc limites dc sistemas, examine os estudos de casos nos
apndices F e G. No caso do YOURIX)N Press Information System (apndice F), o
limite do sistema um tanto maior do que se poderia esperar: ele inclui o faturamento e a
manipulao de receitas de caixa que fariam parte, caractcristicamcntc, dc) l)epartamcnto
de Conta bilidade (e, portanto, fora dos limites do sistema). Similarmcnte, o con trolador
dos elevadores no apndice G tem uma fronteira um tanto menor do que o desejado: um
sistema bem diferente poderia ter sido desenvolvido se os painis de controle do elevador
tivessem sido consi derados parte do sistema em vez de parte do ambiente. Em ambos os
casos, as escolhas foram arbitrrias.
18.1 FERRAMENTAS UTILIZADAS NA DEFIMO DO AMBIENTE
A modelagem ambiental consiste em trs componentes:
1. Declarao dc objetivos
2. Diagrama de contexto
3. Lista de eventos
Cada um desses componente ser discutido a seguir.
18.1.1 A Declarao de Objetivos
O primeiro componente do modelo ambiental uma declarao textual concisa e breve
dos objclivos dc) sistema. Ela voltada para a direo superior, direo usuria e Outros
que no esto diretamente envolvidos no desenvolvimento do sistema.
Um exemplo de uma declarao tpica de objetivos :
O propsito do Afaz Book Processing Sysiem manipular todos os detalhes dos pedidos
de licros, bem como remessas, faturamento e cobranas a clientes com faturas em atraso.
Informaes sobrepe didos de livros devem estar disponveis para outros sistemas, tal
como rnarketing, vendas e contabilidade.
A declarao de objetivos pode ter comprimento de uma, duas ou diversas sentenas.
Entretanto, poderia ter apenas um nico pargrafo,. pois ela no se destina a dar uma
descrio detalhada e abrangente do sistema. Tal esforo seria intil: tarefa do restante
do modelo ambiental e do modelo comportamcntal preencher Lodos os detalhes.
414
Como resultado, a declarao de objetivos ser deliberadamente vaga em relao a
muitos detalhes. No exemplo da Ajax, poderamos
perguntar:
Exatamente que esp de informao fornecida para a conta bilidade, vendas e
marketing pelo sistema de pedidos de livros?
Como o sistema de pedidos de livros determina se um cliente merecedor de crdito?
Isto determinado pelo prprio sistema ou por intermdio de recomendaes do
departamento de contabilidade?
Como o sistema toma conhecimento que novos livros foram pu blicados e j esto
disponveis para venda?
Essas perguntas detalhadas somente podem ser respondidas com o exa me do modelo
comportamental, que discutiremos nos captulos 19 e 20.
Embora as perguntas detalhadas de comportamento no sejam res pondidas pela
declarao de objetivos, geralmente suficiente respon der a uma srie de perguntas de
alto nvel:
O sistema de pedidos de livros responsvel pelas atividades de folha de pagamento?
No, virtualmente qualquer um que leia o material acima concordaria que a folha de
pagamento est fora do escopo do sistema e est provavelmente includa no sistema de
contabilidade.
O sistema de pedidos de livros responsvel pelo envio de fatu ras aos clientes que
encomendam livros? Sim, a declarao de objetivos diz isso. Pode-se imaginar que isto
seja um assunto de debate entre o departamento de pedidos de livros e o depar tamento de
contabilidade. Assim, apropriado que ele seja mencionado na declarao de objetivos.
O sistema de pedidos de livros responsvel pelo controle de inventrio, isto , pela
determinao de quando se deve enco mendar livros que esto esgotados? No, a
declarao de objeti vos no faz tal declarao. altamente concebvel que o con trole de
inventrio seja um dos muitos outros sistemas (ou de partamentos) que faro uso das
informaes sobre pedidos de livros, produzidas pelo sistema de pedidos de livros.
Muitos analistas de sistemas tambm consideram que a declarao
de objetivos deve relacionar os benefcios tangveis e quantificveis que
415
sero obtidos pelo novo sistema; por exemplo, o propsito do sistema reduzir o tempo
necessrio para processar um pedido de trs para um dia. Embora isto possa ser muito
til em pequenos projetos for temente direcionados, no fcil de ser conseguido em
grandes pro jetos. Em seu lugar, costuma ser exigida uma anlise de custo/beneficio em
separado.
Figura 18.4: Um diaR rama de contexto
18.1.2 O Diagrama de Contexto
A parte seguinte do modelo arnbicntal comea por responder algumas das perguntas
levantadas pela declarao de objetivos. O diagrama de contexto um caso especial do
diagrama dc fluxo de da dos, no qual uma nica bolha representa o sistema inteiro. O
diagrama de contexto para o sistema dc pedido de livros mostrado na figura 18.4.
Exemplos de diagramas dc contexto para dois sistemas reais esto apresentados nos
apndices F e G.
O diagrama de contexto reala diversas caractersticas importantes do sistema:
As pessoas, organizaes ou sistemas com os quais nosso sis tema comunica-se. Esses
elementos so conhecidos como
ter,nnadores.
Os dados que nosso sistema recebe do mundo exterior e que devem ser processados de
alguma maneira.
416
Os dados produzidos pelo nosso sistema e enviados para o mundo exterior.
Os depsitos de dados que so compartilhados por nosso sistema e os terminadores.
Esses depsitos de dados ou so criados na parte externa do sistema e usados por nosso
siste ma ou so criados por nosso sistema e usados externamente ao sistema.
Os limites entre o nosso sistema e o resto do mundo.
As tcnicas para construo do diagrama de contexto so discuti das na seo 18.2.
18.1.3 A Lista de Eventos
A lista de eventos uma lista narrativa dos estmulos que ocorrem no mundo exterior, e
aos quais nosso sistema deve responder:
uma lista de eventos para o sistema de pedidos de livros mostrada na figura 18.5:
1. Cliente entrega pedido. (F)
2. Cliente cancela pedido. (F)
3. Direo solicita relatrio de vendas. (T)
4. Pedido de reimpresso de livro chega ao depsito. (C)
Figura 18.5: Urna hsia de evenlos
Observe que cada evento rotulado com um F, um T ou um C. Isto para mostrar se o
evento orientado por fluxo, um evento temporal ou um evento de controle. Um evento
orientado por fluxo associado a um fluxo de dados; isto , o sistema toma conhecimento
da ocorrncia do evento quando chega um grupo de dados (ou possivelmente diversos
grupos de dados). Como se pode imaginar, isso corresponde a um fluxo de dados no
diagrama de contexto.
Entretanto, nem todos os fluxos de dados no diagrama de contexto
s necessariamente eventos orientados por fluxos. Considere, por
exemplo, o diagrama de contexto parcial mostrado na figura 18.6.
primeira vista, poder-se-ia concluir que os fluxos de dados A, B e C fossem todos
indicadores de eventos separados e discretos. Entretanto, pode ser que apenas o fluxo de
dados A esteja associado a um evento (p.ex., o fluxo de dados iniciado pelo
terminador). Para processar o evento, pode ser que o sistema exija explicita mente outros
terminadores
417
para entradas relativas aos fluxos dc dados 13 e C para produzir alguma resposta do
sistema.
Desse modo, no existe necessariamente uma correspondnca um para um entre os
fluxos de dados do diagrama de contexto e os eventos da lista de eventos. Em geral, cada
fluxo de dados ou um evento (ou, mais precisamente, a indicao que o evento ocor
reu) ou exigido pelo sistema com a finalidade de processar um evento.
Figura 18.6: Um diagrama de contexto parcial
Alm dos eventos fluxo-orientados, um sistema pode ter tambm eventos temporais.
Como o nome diz, eventos tcmporais S disparados em um determinado momento. Desse
modo, exemplos de eventos tem porais podem Ser:
Um relatrio dirio de todos os pedidos de livros solicitado s 9:00 horas.
As faturas devem ser geradas s 15:00 horas.
Os relatrios para a direo devem ser gerados uma vez a cada hora.
Observe que os eventos temporais no so disparados por fluxos de dados de entrada;
pode-se imaginar que o sistema tem um relgio interno com o qual ele pode controlar a
passagem do tempo. Lembre-se, entretanto, que um evento temporal pode exigir que o
sistema solicite entradas de um ou mais terminadores. Assim, um ou mais fluxos de dados
podem estar associados a um evento temporal, embora os fluxos de dados no
representem o prprio evento.
418
Os eventos de controle podem ser considerados casos especiais de wenlos telnporais: um
estmulo externo que ocorra em algum momento mprevisvel. Ao contrrio dc um evento
temporal normal, o evento de :ontrole no se relaciona com a passagem regular do tempo,
assim o ;istema no o pode prever pelo uso do relgio interno. E ao contrrio de im
evento fluxo-orientado normal, o evento dc controle no marca sua resena pela chegada
dc dados. Como apresentado na figura 18.7, um vento de controle est associado a
umfiu.xo de controle no diagrama de :ontexto.
O fluxo de controle pode ser considerado um fluxo dc dados bin jO: ele est ligado ou
desligado, e pode passar dc um estado a outro em
ualquer momento, informando, assim, ao sistema que ele necessita
xecutar alguma ao imediata. Os sistemas de informaes orientados ara empresas no
costu ter fluxos dc controle nos diagramas le contexto; o YOURDON Press Information
System descrito no tpndice F, por exemplo, no os apresenta. Porm, os fluxos de
controle o muito comuns nos sistemas de tempo-real; para um exemplo disso, xamine o
diagrama de contexto do sistema de controle de elevadores io apndice G.
fluxo de
Figura 18.7: Llmflu.xo de conirole associado a um evento de controle
8.1.4 Componenles Adicionais do Modelo Ambiental
Na maioria dos projetos, a lista de cvcntos, o diagrama de contexto a definio de
objetivos so suficientes. Entretanto, dois componentes dicionais podem ser teis,
dependendo da natureza e da complexidade lo sistema:
Dicionrio de dados inicial, definindo fluxos e depsitos externos.
Modelo de entidades-relacionamentos dos depsitos externos.
419
Mesmo um sistema dc mdio porte costuma ter algumas dezena dc fluxos dc dados que
entram e saem; um grande sistema pode ter, lite ralmente, centenas. Embora esses fluxos
dc dados eventualmente sejam definidos em grande detalhe flO modelo comportamental
(discutido no captulo 20), pode ser til iniciar agora a preparao de um dicionrio de
dados. Isso pode ser importante se as interfaces entre o sistema e os diversos
terminadores estiverem sujeitas a mudanas e negociaes; quanto mais cedo comear-se
a definir formalmcnte essas interfaces (de finindo a composio e o significado dos
depsitos), mais cedo elas podero ser finalizadas.
De forma anloga, um diagrama dc entidades-relacionamentos pode ser construdo a
partir dos depsitos externos (se houver algum). Isso pode ajudar a expor os
relacionamentos entre os depsitos que, dc outra maneira, no se tornariam evidentes at
que o modelo comporta- mental estivesse sendo desenvolvido. Pela concentrao nesses
relacio namentos, nesse primeiro estgio, teremos um meio dc duplicar a verifi cao das
interaes entre os terminadorcs (que costuma incluir os usu rios finais do sistema) e o
prprio sistema.
18.2 A CONSTRUO DO MODELO AMBIENTAL
A discusso acima provavelmente faz com que o modelo ambien tal parea ser um tanto
simples e direto: afinal dc contas, existe somente um processo, alguns fluxos de dados e
tcrminadorcs, uma pequena des crio narrativa do objetivo do sistema, e uma lista de
eventos. Embora isso seja verdadeiro, muitas vezes o modelo ambental exige muito
trabalho; alm disso, ele habitualmente desenvolvido com uma srie de refinamentos
iterativos, com detalhes adicionais sendo introduzidos e refinados.
Urna importante razo pela qual tantos refinamentos e revises costumam ser necessrios
que ningum habitualmente entende o escopo completo do sistema como ele
inicialmente definido. Se o pro jeto envolver um novo sistema que substituir um sistema
j existente, ser vivel falar sobre ele com os usurios que esto presentemente
executando as funes do sistema; de um certo modo, eles tm a pers pectiva de pessoas
localizadas no lado interno, olhando para fora, como ilustrado pela figura 18.8.
Entretanto, mesmo nesse caso, os diversos usurios internos normalmente esto
familiarizados com apenas uma parte do sistema, e suas diferentes vises so por vezes
conflitantes. Pior ainda, as suas entrevislas iniciais com a comunidade usuria podem
omitir um ou dois usurios importantes, cujas interaes com os termina- dores externos
ao sistema devem ser modeladas
420
Figura 18.8: A viso que o usuno tem do sistema
importante gastar tempo e energia no modelo ambiental, pois ele muitas vezes o
ponto central de vrias reunies e apresentaes im portantes desde o incio da vida de
um projeto de desenvolvimento de sistemas. Ele, na verdade, muitas vezes a nica parte
de todo o modelo do sistema que muitos usurios de alto nvel e diretores (aqueles que
tm o dinheiro para continuar patrocinando o projeto e o poder de cancel-lo!) chegaro a
ver. Depois de construdo e aprovado, ele pode r ser visto afixado em diversas paredes e
quadros de avisos - e, assim, importante que esteja correto.
18.2.1 A Construo do Diagrama de Contexto
O diagrama de contexto, como j vimos, compe-se de termina- dores, fluxos de dados e
fluxos de controle, depsitos de dados e um nico processo representando todo o sistema.
Estudaremos cada um deles a seguir:
A parte mais fcil do diagrama de contexto o processo; como j
vimos, ele consiste em uma nica bolha, O nome dentro do processo
normalmente o nome do sistema ou um acrnimo convencionado para o
sistema. Alguns exemplos so mostrados na figura 18.9(a) e (b).
Observe que, no caso mais extremo, o novo sistema pode repre sentar toda uma
organizao; nesse caso, o nome do processo seria, nor malmente, o da prpria
organizao, como mostrado na figura 18.9(c)
SISTEMA
DE
CONTABI LIDADE
Figura 18.9 (a): Um nome tipico de processo para um diagrama de conte
421
Os terminadores, como j vimos, so rcprcscntados por um quadro retangular no
diagrama dc contexto. Os tcrminadores comunicam-se diretamente com o sistema atravs
dos fluxos dc dados ou dos fluxos de controle, como mostrado na figura 18.10(a), ou
atravs dc depsitos dc dados externos, como mostrado na figura 18.10W).
Observe que os terminadores no se comunicam diretamente entre Si; desse modo, o
diagrama dc contexto mostrado na figura 18.11 est incorreto. Na realidade, os
terminadores tm comunicaes entre si, mas uma vez que, por definio, os
terminadores so externos ao sistema, a natureza e o contedo das interaes terminador-
para-terminador so irrelevantes para o sistema. Se durante os entendimentos com os
usu rios voc decidir que essencial saber quando, por que ou como um terminador
comunica-se com outro, ento os tcrminadores so parte do sistema e eles devem ser
colocados dentro da bolha do processo do diagrama de contexto.
Figura 18.9(b): Outro nome 1/.ico de processo
Figura 18.9 (c): BNome de processo representando toda uma organizao
Figura 18.10 (a): Comunicao direta terminador-sistema
422
DADOS DE PESQUISA DE MERCADO
FIRMAS DE PESQUISA
Figura 18.10 (b): Comunicao atravs de um um depsito externo
Trs outras observaes devem ser feitas sobre os terminadores:
1. Alguns terminadores podem ter um grande nmero de entradas e sadas. Para evitar um
diagrama desnecessariamente conges tionado, pode ser conveniente desenhar o
terminador mais de uma vez, como mostrado na figura 18.12(a). Observe que os
terminadores duplicados so marcados com um asterisco; uma conveno alternativa
representar os tcrminadores duplicados com uma linha diagonal, como mostrado na
figura 18.12(b).
anncio
pedidos
Pedidos de
reco m p1 eta me nto
Figura 18.11: Um diagrama de contexto incorreto
423
Figura 18.12 (b): Um modo alternativo de mostrar terminadores duplicados
424
Figura 18.12 (a): Terminadores duplicados no diaR rama de contexto
2. Quando o terminador urna s pessoa, geralmente prefervel indicar o papel que a
pessoa desempenha, em vez de indicar a identidade dessa pessoa; desse modo, a figura
18.13(a) melhor que a figura 18.13(b). Existem dois motivos para isSo: primeiro, a
pessoa que executa o papel pode ser substituida em um de terminado momento, e
desejvel que o diagrama de contexto permanea estvel e correto, mesmo que ocorram
mudanas no pessoal. E, segundo, uma s pessoa pode desenpenhar diver sos diferentes
papis no sistema; ao invs de mostrar um ter- minador rotulado John Smith com
diversos fluxos no inter- relacionados de entrada e dc sada, mais significativo apre
sentar os vrios papis que John Smith desempenha, cada um como um tcrminador
separado.
3. Como estamos interessados principalmente no desenvolvimento de um modelo
essencial do sistema, importalite distinguirmos entre fontes e manipuladores quando
desenharmos os ter- minadores no diagrama dc contexto. Um manipulador um me
canismo, dispositivo, ou meio fisico usado para transportar dados para dentro ou para
fora do sistema. Como esses mani puladores so, muitas vezes, conhecidos e visveis aos
usurios da implementao atual do sistema, existe, iuitas vezes, uma tendncia para
mostrar o manipulador, em lugar da verdadeira fonte dos dados. Entretanto, como o novo
sistema normalmente ter a opo de modificar a tecnologia pela qual os dados so
trazidos para dentro e enviados para fora do sistema, o mani pulador no deve ser
mostrado. Desse modo, o diagrama de contexto mostrado na gura 18.l(a) prefervel ao
mostrado na figura 18.14(b).
ENCARREGADO
DE REMESSAS
Figura 18.13 (a): Um modo melhor d mosirar um terminador
FRED QUIMBY
Figura 18.13 (b): Um modo menos usado de mostrar um terminador
425
Como um compromisso, principalmente se o usurio insistir, pode- se rotular um
terminador para mostrar a vcrdadcira origem e o manipu lador que conduz os dados para
dentro ou para fora do sistema: isso est ilustrado na figura 18.14(c).
Os fluxos mostrados no diagrama dc contexto modelam os dados que chegam ao sistema
e os que so transportados para fora dele bem como os sinais de controle recebidos pelo
sistema ou gerados por ele. Os fluxos de dados sero includos no diagrama dc contexto
se forem necessrios para detectar um evento no ambiente ao qual o sistema deva
responder, ou se forem necessrios (como dados) para que seja produ zida uma resposta.
Os fluxos de dados tambm podem aparecer no diagrama de contexto para mostrar dados
que sejam transportados entre terminadores para o sistema. Finalizando, os fluxos de
dados so mostra dos no diagrama de contexto quando os dados so produzidos pelo
sistema para responder a um evento.
Como j afirmamos, o diagrama de contexto de um modelo essen cial evita (sempre que
possvel) mostrar os manipuladores orientados
pedido
Figura 18.14 (a): Um terminador mostrando a verdadeira fonte de dados
pedido
Figura 18.14 (b): Um lerininador que alua como um manipulador
426
para a implementao que transportam dados para dentro e para fora do sistema. Alm
disso, desejamos evitar a apresentao das mensagens e handshakings orientados para a
implementao pelos quais o sistema e os terminadores informam-se que esto prontos
para entradas e sadas. Desse modo, queremos evitar o desenho dc diagramas de contexto
como o mostrado na figura 18.15(a), porque ele incorpora pressuposi es de
implementao que podem ser drasticamente alteradas quando o novo sistema for
implementado.
Em vez disso, devemos desenhar o diagrama de contexto na hip tese de que as entradas
so causadas e iniciadas pelos terminadores, e de que as sadas so causadas e iniciadas
pelo sistema. Evitando-se as mensagens indesejveis e as entradas e sadas orientadas
para a imple mentao, modelaremos somente um fluxo de dados limpo.
pedido
Figura 18.14 (c): Um terniinador que combina fonte e manipulador
pronto para
Figura 18.15 (a): Um diagrama de contexto com mensagens desnecessrias
427
Ent.retanto, haver ocasies cm que um terminador no iniciar entradas, porque, mesmo
face tecnologia perfeita, o terminador no sabe que o sistema necessita da sua entrada.
Similarmente, h ocasies em que o sistema no inicia a gerao de sadas, pois ele no
sabe que o terminador a necessita ou a deseja. Em ambos os casos, uma mensagem do
sistema (um prompt) uma parte essencial do sistema, e deve ser mostrada no diagrama
dc contex to; um exemplo est mostrado na figura 18.15(b). Algumas vezes conveniente
mostrar o prompi e o correspon dente fluxo de entrada ou sada com um fluxo de dilogo
(uma seta de duas pontas), como mostrado ria Figura 18.15(c)
18.2.2 A Construo da Lista dc Evc
A lista de eventos, como j vimos, uma simples listagem textual dos eventos do
ambiente aos quais o sistema deve responder. Quando construir a lista de eventos,
assegure-se de distinguir entre um evento e um fluxo relacionado a um evento. O
exemplo abaixo provavelmente no um evento:
O pedido do cliente recebido pelo sistema
Em vez disso, ele provavelmente o fluxo dc dados de chegada pelo qual o sistema toma
conhecimento da ocorrncia do evento. Um nome mais apropriado para o evento poderia
ser
Cliente entrega pedido
Isso pode parecer um exerccio semntico, mas no . Se descre vermos o evento do
ponto de vista do sistema (isto , visto de dentro), poderemos identificar erroneamente os
fluxos de chegada que no so eventos por eles mesmos, mas que so necessrios para
processar algum outro evento. Desse modo, sempre desejamos descrever os eventos do
ponto dc vista do ambiente (isto , de fora do sistema).
Na maioria dos casos, o meio mais fcil para identificar os eventos relevantes para um
sistema visualizar o sistema em ao: examinamos cada terminador e nos perguntamos
qual o efeito que as aes do termi nador podem ter no sistema. Isso habitualmente feito
em combinao com os usurios do sistema, que podem desempenhar o papel dos ter-
minadores. No entanto, devemos ter cuidado em distinguir entre os eventos discretos que
tenham sido acidentalmente empacotados juntos como se fossem um nico evento; isso
acontece quase sempre com os eventos orientados por fluxo. Devemos examinar o evento
candidato e nos perguntarmos se todas as instncias do evento envolvem os mesmos
dados; se os dados estiverem presentes em algumas instncias e ausentes em outras,
podemos ter de fato dois eventos distintos. Por exemplo, se
428
consulta sobre
resposta sobre situa
SISTEMA DE
solicitao de CONTROLE
verificao de crdito DE PEDIDOS
resposta
verificao de crdito
PARTAM ENTO
DE
INTABILIDADE
CLIENTE
consulta sobre situao de pedido
Figura 18.15 (c):, Um meio alternativo de mostrar fluxos de dilogo
itao de ficao de cr
situao de pedido
resposta verificao de crdito
Figura 18.15 (b): Fluxos de dilogo para mostrar mensagens essenciais
429
examinarmos cuidadosamente o evento cliente entrega pedido, vere mos que algumas
instncias do evento incluem o elemento de dads vendedor-ID e outros nO; e veremos
que a resposta do sistema ser diferente quando um vendedor estiver envolvido do que
quando no houver vendedor. Desse modo, seria mais apropriado termos dois even tos
separados: cliente entrega pedido, e vendedor entrega pedido de cliente.
Alm disso, lembre-se que a lista dc eventos deve incluir no somente as interaes
normais entre o sistema e seus terminadores, mas, tambm, situaes de falhas. Como
estamos criando um modelo essen cial, no temos de nos preocupar com falhas do
sistema; mas temos de levar em considerao as possveis falhas ou erros causados pelos
termi nadores. Como assinalam Paul Ward e Stephen Meilor em Structured Development
for Real-Time Systems (Nova lorque: YOURDON Press, 1985).
Como os terminadores esto, por definio, fora dos limites do esforo da construo do
sistema representados pelo modelo, os im plementadores no podem modificar a
tecnologia do terminador sua vontade para melhorar a confiabilidade. Ao invs disso,
eles devem construir respostas aos problemas do terminador no modelo essencial do
sistema. Uma til abordagem para modelar respostas aos problemas do terminador
construir uma lista de eventos nor mais e, em seguida, perguntar a cada evento, O
sistema necessita responder, se o evento no ocorrer da maneira esperada?.
Por exemplo, nossa lista de cventos para o Ajax Book Order Sys tem (figura 18.5) incluiu
o evento Pedido de reimprimir livro chega ao depsito. Porm e se o pedido no chegar
dc forma oportuna (p.ex., dentro de uma semana da data prometida pela grfica)? O que
far o sistema ? Provavelmente, precisaremos dc um evento iniciado pelo siste ma para
fazer com que o sistema efetue um contato com a grfica e verifique o motivo da demora.
18.2.3 O Que Vem Primeiro, o Dia de Contexto ou a Lista de Eventos?
Pode-se iniciar com a lista de cventos ou com o diagrama de con texto. Realmente, isso
no importa, medida que voc eventualmente produz componentes do modelo
ambienial e confirma que eles estejam consistentes entre si
Voc tambm pode encontrar-se falando com pessoas que esto
cientes de tudo o que entra e sai do sistema; alguns usurios podem ser
capazes de fornecer-lhe essa informao, ou os programadores de
430
manuteno responsveis pela manuteno dc uma verso atual do siste ma poderiam ter
conhecimento nessa rca. Isso lhe fornecer partes do diagrama de contexto como ponto
dc partida. Depois, voc pode discutir as transaes que os usurios enviam para o
sistema e as respostas que eles esperam do sistema. Isso permite criar a lista de eventos
do diagra ma de contexto.
Entretanto, voc pode encontrar-se cm uma situao onde o dia grama de contexto no
esteja disponvel. Isso particularmente comum no incio de alguns projetos de
desenvolvimento de sistemas: pode no ser fcil identificar imediatamente os
terminadores e os vrios fluxos que entram e saem do sistema. Nesse caso, muitas vezes
mais prtico comear com um diagrama DER que mostra os objetos e os relaciona
mentos. Os eventos candidatos podem, depois, ser encontrados pela procura de atividades
ou operaes que fazem com que sejam criadas ou eliminadas instncias de um
relacionamento. A criao da lista de even tos pode conduzir, portanto, ao
desenvolvimento do diagrama de con texto; isso est ilustrado na figura 18.16.
Suponha, por exemplo, que identificamos os objetos CLIENTE e LIVRO em um sistema
dc uma editora; nosso usurio tambm poderia dizer-nos que existe um relacionamento
pedidos entre CLIENTE e LIVRO. Um evento provvel, ento, seria uma ao que
criasse uma ins tncia do relacionamento de pedidos: um outro evento seria uma ao que
anulasse uma instncia do relacionamento. Isso nos conduziria a identificar Cliente pede
livro e Cliente cancela pedido de livro como eventos da lista de eventos. No preciso
muita investigao para perceber que cliente um terminador para o sistema (enquanto
livro no ); em seguida poderemos comear a desenhar o diagrama de contexto.
Quando ambos os componentes do modelo ambiental estiverem
terminados, estaremos aptos a confirmar o seguinte:
Cada fluxo de entrada no diagrama de contexto seria necess rio ao sistema para
reconhecer que um evento ocorreu, ou seria necessrio ao sistema para a produo de
uma resposta a um evento, ou ambos.
Cada fluxo de sada deve ser uma resposta a um evento.
Cada evento no temporal da lista de eventos deve ter entradas a partir das quais o
sistema pode detectar que o evento ocorreu.
Cada evento deve ou produzir urna sada imediata como res posta, ou armazenar dados
para serem emitidos como sada
posteriormente (como resposta ou parte de uma resposta para
i31
DE EVENTOS
Figura 18.16: Criao do dia de contexto a partir de um DER
algum outro evento), ou ele deve fazer com que o sistema a mude de estado (como
indicado no diagrama de transaes de estado).
18.3 RESUMO
A construo do modelo ambicntal a prime!ra e mais importante parte da construo de
um modelo completo dos requisitos do usurio para um novo sistema. A essa altura, isso
poderia parecer uma tarefa fcil; afinal de contas, o diagrama de contexto consiste em
uma nica bolha, e a lista de eventos se parece com uma simples lista de transa es.
Mas, em um grande projeto, pode estar envolvido um grande vo lume de trabalho: a nica
bolha no diagrama de contexto pode intera gir com dezenas de terminadores externos e
podem ter mais de uma
432
pedidos,
1. Evento 1...
2. Evento 2...
3. Evento 3...
4.
5.
fatura,
fatur
CONTABILI - DADE
liiL
centena de fluxos de dados chegando e partindo. E a lista de eventos tambm um
importante esforo em grandes sistemas; pode existir facil mente mais de uma centena de
eventos com que o sistema ter de lidar, e todos devero ser identificados. Alm disso,
pode ser difcil conseguir uma declarao simples consensual do motivo da existncia do
sistema.
Uma vez construdo o modelo ambicntal, ele deve ser minucio samente revisto por todos
os representantes dos usurios principais, bem como pela equipe do projeto. Depois
disso, voc estar pronto para iniciar a construo do modelo comportamental, o modelo
do interior do sistema. Isso ser discutido nos captulos 19 e 20.
PERGUNTAS E EXERCCIOS
1. Quais so as trs coisas definidas pelo modelo essencial?
2. Que espcie dc eventos devem ser modelados em um modelo essencial?
3. Como a fronteira entre o sistema e o ambiente determinada pelo analista de sistemas?
1. Qual a provvel conseqncia de o analista de sistemas escolher
um escopo demasiado pequeno para o projeto?
. Qual a provvel conseqncia de o analista de sistemas escolher um escopo
demasiadamente grande para o projeto?
6. Que fatores devem ser levados em conta na definio dc um escopo para o projeto?
7. Como o desejo do usurio de conseguir uma certa participao no mercado afeta o
mbito de um sistema?
8. Como a legislao decretada pelos diversos nveis governamentais afeta o escopo de
um sistema?
9. Como o desejo do usurio para minimizar (Ou reduzir) despesas operacionais afeta o
mbito dc um sistema?
10. Como o desejo do usurio em obter alguma vantagem estratgica contra os
competidores afeta o escopo dc um projeto?
11. Projeto de Pesquisa: examine um projeto da sua prpria organi zao. Que fatores
voc considera que mais influram na escolha do escopo do sistema? Voc acha que o
usurio, o analista de sistemas e a equipe do projeto estavam cientes dele e estavam de
acordo?
12. Na sua opinio, de um modo geral, quais sero os principais fatores dos sistemas
desenvolvidos nos anos 90? Por exemplo, a reduo das despesas operacionais ser mais
importante do que as mudanas causadas pela legislao governamental?
13. Quais so os trs principais componentes do modelo ambiental?
433
14. Qual deve ser aproximadamente a extenso da declarao de
objetivos?
15. Quais so as cinco caractersticas dc um sistema mostradas pelo
diagrama de contexto?
16. Quais so os componentes dc um diagrama dc contexto?
17. O que uma lista de eventos?
18. Quais so os trs tipos dc eventos que devem ser modelados em
um diagrama de contexto?
19. Qual o relacionamento entre fluxos e eventos no diagrama de
contexto?
20. O que um evento temporal?
21. Que componentes adicionais podem ser encontrados em um
modelo ambiental alm do diagrama de contexto, a lista de eventos
e a declarao de objetivos?
22. Por que costuma ser necessrio fazer muitas revises e refina
mentos do modelo ambicntal?
23. Por que importante garantir que o modelo ambiental esteja
correto?
24. Que tipo de nome deve ser colocado na bolha de um diagrama de
contexto?
25. O que um modelo de empresa?
26. Como os terminadores comunicam-se com o sistema
27. Os terminadores comunicam-se entre si cm um modelo de sistema?
Por qu?
28. Sob que condies seria um terminador desenhado mais do que
uma vez em um diagrama de contexto? Como seria mostrado?
29. Se um terminador for uma pessoa, como deve ele ou ela ser mos
trado no diagrama de contexto?
30. Como pode o analista de sistemas ter certeza de que ele ou ela
identificou todos os terminadores no diagrama dc contexto?
31. O que um manipulador? Qual a diferena entre urna fonte e um
manipulador?
32. Por que devem ser mostradas fontes e no manipuladores em um
diagrama de contexto?
33. O que deve fazer o analista de sistemas se o usurio insistir em
mostrar os manipuladores no diagrama de contexto?
34. Sob que condies os fluxos so mostrados em um DFD?
35. Por que as mensagens (prompts) e handshakings em geral no so
mostrados em um diagrama de contexto?
36. O que significa a expresso fluxo limpo de dados?
37. Sob que condies um terminador no inicia a entrada em um.
sistema?
38. Sob que condies o sistema no inicia a sada para um
terminador?
434
39. O que deve ser desenvolvido primciro, o diagrama de contexto ou a lista de eventos?
Por qu?
40. Quais so as quatro coisas que devem ser verificadas para garantir que o modelo
ambiental esteja correto?
41. O que est errado no diagrama dc contexto abaixo?
42. O que est errado no diagrama de contexto abaixo?
43. O que est errado no diagrama de contexto abaixo? p
/
44. O que est errado no diagrama de contexto abaixo?
a
LISTA DE EVENTOS
1. Cliente precisa de um a
2. Fornecedor precisa de fatura.
3. Fornecedor faz uma remessa.
4. Cliente entrega pedido.
NOTAS
Alguns usurios podem no ser importantes em termos de hierar quia organizacional; eles
podem ser considerados como funcion rios subalternos, secretrios ou administradores.
Contudo, as funes que eles desempenham podem ser vitais, e pode ser fun damental
modelar exatamente as entradas que eles recebem do mundo exterior e as sadas que eles
enviam ao mundo exterior, O motivo pelo qual o analista de sistemas muitas vezes
esquece de falar para essas pessoas muito simples: um usurio de nvel mais elevado
(isto , o chefe) informar ao analista de sistemas com quem deve falar. No aborrea
nenhum dos meus funcionrios, dir o chefe ao analista, eles esto muito ocupados e
por isso que precisamos de um novo sistema. Eu direi tudo que voc necessita saber sobre
o sistema. Como j estudamos no captulo 3, pode no haver um meio diplomtico para
evitar isso; mas essencial verificar cuidadosamente o modelo ambiental para ga rantir
que nada esteja faltando.
2 Esse um improvvel cenrio para o projeto de desenvolvimento de um sistema, mas
est comeando a ocorrer gradualmente mais, proporo que as pessoas esto utilizando
diagramas de fluxo de dados e outras ferramentas de modelagem descritas neste livro
para a construo de modelos de empresas. Isso pode ser feito sem qualquer inteno de
se computadorizar toda a empresa, mas sim plesmente para abranger o que j existe -
principalmente para. abranger os dados de que a organizao necessita para executar seu
objetivo, O tema dc modelos dc empresas discutido em Information Engineering for lhe
Practilioner, de William Inmon
436
b
(Engle wood Cliffs, N.J.: Prentice-hall, 1987) e Slrategic Data Base Modeling, de James
Martin (Englcwood Cliffs, N.J.: Prentice-Hall, 1985).
3 No obrigatrio o uso dc um fluxo dc dilogo, mas ele faz com que o diagrama de
contexto fique mais legvel pela agregao das entradas e sadas associadas de forma a
que fiquem imediatamente visveis ao leitor. Alm disso, a utilizao de uma seta para
mostrar que o dilogo, em oposio a duas setas separadas, cria um de diagrama de
contexto menos congestionado. Isso importante em grandes sistemas, onde pode existir
uma centena ou mais de diferentes interaes com terminadores externos.
437
IL
19
A CONSTRUO
DO MODELO
COMPORTAMENTAL
PRELIMINAR
As coisas so sempre melhores no incio.
Blaise Pascal, Leilres Provinciales, 1656-165Z nr. 4
Neste captulo, aprenderemos:
1. Porque a abordagem top-down difcil para o mo delo comportamental.
2. Como desenvolver um modelo comportamental pre liminar usando a subdiviso de
cvcntos.
3. Como desenvolver o modelo dc dados DER inicial.
No captulo anterior vimos como desenvolver o modelo ambiental para um sistema. Se,
neste momento, voc estivesse trabalhando em um projeto real, voc teria prontificado o
diagrama de contexto, a lista de eventos e uma declarao de objetivos. Alm disso, voc
teria iniciado a preparao do dicionrio de dados, com pelo menos a definio dos
elementos de dados que representam as intcrfaces entre os terminadores externos e o
sistema. Nossa tarefa agora comear a construir o modelo comportamental, isto , o
modelo do que deva ser o comportamento interno do sistema para que possa interagir
corretamente com o ambien te. Isso envolve o desenvolvimento de um diagrama de fluxo
de dados preliminar e um diagrama de entidades-relacionamentos, bem como a
elaborao dos itens iniciais dc) dicionrio de dados.
Essa abordagem envolve fundamentalmente o desenho da primei ra verso de um
diagrama de fluxo dc dados, com um processo (bolha)
439
para a resposta do sistema a cada evento q tcnha sido identificado na lista de eventos. Em
seguida, desenhamos depsitos cm nossa primeira verso de DFD para modelar s dados
que devem ser memorizados entre eventos assncronos. Finalizando, interligamos os
fluxos adequa dos de entrada e de sada s bolhas e verificamos nosso conjunto de DFD
em relao ao diagrama dc contexto para manter a consistncia.
Feito isso, damos partida cm um processo de limpeza, descrito no captulo 20, para
produzirmos um modelo bem organizado de processos e de dados para apresentao ao
usurio final. A esta abordagm foi dado o nome de subdiviso dc evcntos cm
lMcMenamin e Palmer, 198/d.
Comearemos comparando esta abordagem com a clssica aborda gem top-down.
19.1 A ABORDAGEM CLSSICA
A abordagem sugerida neste captulo substancialmente diferente da abordagem top-
down descrita em livros clssicos como DeMarco [ 19791, Gane [ e Sarson, 19791 e
outros. A abordagem clssica presume que voc j desenhou o diagrama de contexto; mas
tambm presume que voc prosseguir direlarncnie da bolha nica do diagrama de
contexto para um 1)11) de alto nvel (conhecido como figura 0), em que cada uma das
bolhas representa um importante sub sistema. Cada bolha da figura O , depois, dividida
em figuras de nvel mais baixo, e cada bolha dessas figuras dc nvel mais baixo so tam
bm divididas, e assim por diante, at que se alcance o nvel de bolhas atmicas, que j
no exigem mais decomposies. Isso ilustrado na figura 19.1.
Embora essa abordagem top-down seja diferente da que apresen tada neste livro, eu
nada tenho contra ela, ... clesc1e que funcione. Entre tanto, lembre-se de que muitos
analistas de sistemas encontram os se guintes problemas quando utilizam a abordagem
top-down:
Paralisia da anlise. Em muitos sistemas grandes e complexos, simplesmente no existe
algo que possa orientar o analista de sistemas no desenho da figura O adequada a partir
do diagrama de contexto. Dessa forma, o analista senta-se sua mesa, con templando o
diagrama dc contexto, esperando pela inspirao divina, ou por algum que lhe diga que
o projeto ultrapassou o tempo para anlise e que j hora de se iniciar a codificao.
O fenmeno dos seis anolislas. Em um sistema grande e com plexo muitas vezes h
mais dc um analista de sistemas contem plando o diagrama de contexto. Para dividir o
trabalho sem que
440
Figura O
rigura 19.1: li aesenvoivzmenro rop-down do modelo comportamental
um interfira no servio dos outros, eles criam arbitrariamente uma figura O com uma
bolha para cada analista de sistemas. Desse modo, se houver seis deles, a figura O se
constituir de seis bolhas. Desnecessrio dizer que isso pode no ser a melhor subdiviso
do sistema, O que acontecer, por exemplo, se o mesmo sistema for especificado por trs
analistas de sistemas? E por nove? E por um s?
A subdiviso fl arbitrria. Em muitos casos o novo sistema fundamenta-se em outro
sistema j existente ou a computa dorizao de uma organizao. A subdiviso em alto
nvel do sistema atual (ex.: as unidades atuais da organizao ou os sis temas de
processamento existentes) muitas vezes utilizada como base lgica para se subdividir o
novo sistema. Portanto, se o sistema atual representado pelo Departamento de Compras
e pelo Departamento de Controle de Qualidade, o novo sistema freqentemente tem um
Subsistema de Compras e um Subsis tema de Controle de Qualidade mesmo que essa no
seja (e muitas vezes no ) a melhor forma de subdividir (do ponto de vista funcional) o
sistema.
441
A abordagem descrita neste captulo no puramente top-down e tambm no
puramente bottom-up. Ela , dc certa forma, uma aborda gem do meio; depois que o
DFI) inicial est pronto, pode ser preciso criar alguns nveis para cima e alguns outros
nveis para baixo.
19.2 A IDENTIFICO DE RESPOSTAS A EVENTOS
A abordagem dc subdiviso dc evcntos envolve as quatro etapas
abaixo:
1. Desenha-se uma bolha, ou processo, para cada evento da lista de eventos.
2. A bolha recebe um nome de acordo com a resposta que o siste ma deve dar ao evento
associado.
3. Desenham-se entradas e sadas apropriadas de modo a que a bolha seja capaz de emitir
a resposta necessria e desenham-se depsitos, como for mais adequado, para
comunicao entre as bolhas.
4. O resultante DFD inicial verificado em relao ao diagrama de contexto e lista de
eventos para que se confirme se est
completo e consistente.
A primeira etapa direta, quase mecnica por natureza. Se houver 25 eventos na lista,
voc ter de desenhar 25 bolhas. Para facilitar consul tas, numere cada bolha de modo a
coincidir com o evento a ela associa do. Assim, o evento 13 corresponder bolha 13
(posteriormente, como veremos no captulo 20, rcnumerarcmos as bolhas
adequadamente).
A segunda etapa tambm direta e mecnica: cada bolha recebe um nome apropriado, de
acordo com sua necessria resposta. Isso igni fica que voc deve examinar o evento e
perguntar a voc mesmo Que resposta o sistema deve dar a este evento?. Lembre-se,
contudo, que voc deve escolher nomes to especficos quanto possvel. Assim, se um
evento for CLIENTE EFETUA PAGAMEN1O, um nome adequado para uma bolha seria
ATUALIZAR CONTAS A RECEBER (se for esta a nica resposta exigida do sistema),
em vez dc PROCESSAR PAGAMENTO DE CLIENTE (que nada nos informa sobre a
natureza da resposta).
A terceira etapa definitivamente no mecnica, mas normal mente bastante direta.
Para cada bolha desenhada, preciso identificar as entradas que a bolha necessita para
executar sua tarefa; preciso identificar as sadas (se houver alguma) que a bolha produz,
sendo ainda
442
necessrio identificar os depsitos a que a bolha deve ter acesso. Isso normalmente feito
mediante entrevistas com os usurios apropriados e focalizando cada evento e sua bolha
associada. De que necessita esta bolha para fazer seu servio? - voc perguntar ao
usurio - e Que sadas ela gera?
Em muitos casos, o evento dirigido pelos fluxos; isso quer dizer que o sistema se torna
interessado na ocorrncia do evento por causa da chegada de alguns dados de um
tcrminador externo. Isso obviamente significa que o fluxo de dados apropriado deve ser
associado ao proces so necessrio para responder quele evento. Porm, como mostram
as figuras 19.2(a) e (b), podem ser necessrias entradas adicionais (de ou tros
terminadores e possivelmente de depsitos de dados) para que o processo possa produzir
a necessria sada.
Do mesmo modo, preciso desenhar as sadas apropriadas produ zidas pelo processo
como parte da resposta. Em muitos casos, isso en volver sadas que so encaminhadas
de volta aos terminadores fora do sistema; entretanto, isso pode envolver sadas enviadas
aos depsitos, para serem utilizadas como entradas por outros processos. Isso est ilus
trado nas figuras 19.3(a) e (b).
Por fim, a quarta etapa uma atividade de verificao de consistn cia semelhante s
etapas de equilbrio descritas no captulo 14. Voc deve se certificar de que cada entrada
no diagrama de contexto esteja associada a uma entrada em um dos processos do DFD
preliminar e de que cada sada produzida por um processo no DFD preliminar seja
1 ___
Figura 19.2 (a): Fluxo de dados sinalizando a ocorrncia de um evento
443
Figura 19.3 (a): Uma sada enviada de um processo para um terminador
enviada para um depsito ou seja uma sada externa mostrada no diagra ma de contexto.
Existem dois casos especiais: (1) eventos unitrios que provocam mltiplas sadas e (2)
eventos mltiplos que causam a mesma resposta. No primeiro caso, um evento unitrio
pode provocar mltiplas respostas, sendo cada uma delas modelada com sua prpria
bolha no DFD preliminar. Isso ilustrado na figura 19.4. Isso s adequado se todas as
444
Y
Figura 19.2 (b): Entradas adkionajs necessrias para a produo da resposta
Figura 19.3(b): Uma sada sendo enviada de um processo para um depsito
edido de cliente
Figura 19.4: Mltiplas respostas proven ientes do mesmo evento
respostas usarem o mesmo fluxo de dados que chega, e somente se todas elas forem
independentes entre si. Nenhuma sada de uma parte da resposta geral deve ser necessria
como entrada para outra parte da resposta geral
De forma inversa, haver ocasionais situaes em que um pro cesso esteja associado a
mais de um evento; isso mostrado na figura
19.5. Isso s vlido e adequado se a resposta emitida pela bolha for
445
pedido/
dinheiro
idntica para os diversos evcntos e somente se os dados de entrada e os
de sada forem idnticos para as diversas resposlas aos eventos.
19.3 A INTERLIGAO DAS RESPOSTAS AOS E VENTOS
Observe que, nos exemplos anteriores, nenhum dos processos do diagrama de fluxo de
dados preliminar era interligado a outro: bolbas no falam diretamente com outras bolhas.
Ao invs disso, as bolhas se intercomunicam atravs dos depsitos de dados.
Por que assim? Simplesmente porque as bolhas do DFD preli minar representam
respostas a um evento, e os eventos que ocorrem no ambiente externo so, no caso geral,
assmncronos. Isto , no temos meios de garantir que dois eventos ocorrero no mesmo
instante, ou defasados um do outro por dois segundos, ou por qualquer intervalo de
tempo. Os eventos acontecem no ambiente externo quando o ambiente decide faz-los
acontecer.
E desde que:
a resposta a um evento possa exigir dados produzidos por al gum outro evento, e
no tenhamos meios dc saber quando os eventos ocorrero, e
tenhamos de presumir, em um modelo essencial, que cada pro cesso executar sua tarefa
de modo infinitamente rpido, e
pedido!
carto de crdito
Figura 19.5: Eventos mltiplos com a mesma resposta
446
da depreende-se que o nico modo dc sincronizarmos mltiplos even tos
interdependentes atravs dc um depsito. Atente para o fato de que esse um depsito
essencial: necessrio, no por causa dos retardos de tempo relacionados tecnologia
impcrfcita, mas devido s considera es temporais do ambiente.
Desse modo, voc no deve ver um diagrama de fluxo de dados preliminar como o
mostrado na figura 19.6(a); como os evcntos associa dos so assncronos, a figura 19.6(a)
s poderia funcionar se um depsi to de dados com retardo estivesse oculto cm um dos
processos ou no prprio fluxo de dados. Assim sendo, a figura 19.6(b) a maneira correta
de mostrar as comunicaes entre processos.
19.4 O DESENVOLVIMENTO DO MODELO DE DADOS INICIAL
Como vimos, o procedimento dc esboar o DFD inicial engloba
o desenho de depsitos de dados entre processos assmncronos. Na maioria dos casos, a
natureza desses depsitos ser bvia e os nomes pode ro ser escolhidos a partir do seu
conhecimento do objetivo do projeto.
Todavia, enquanto isso, voc ou um dc seus colegas deve ter co meado a trabalhar na
verso inicial do diagrama de entidades-re lacionamentos como atividade independente,
em paralelo com o desen volvimento do DFD inicial, o que deve ser feito com o emprego
das tcnicas descritas no captulo 12.
Como o DER e o DFD so desenvolvidos cm paralelo, eles podem ser usados para
verificaes cruzadas entre eles. Dessa forma, os depsitos que tenham sido definidos
cxpcrimcnta!mcntc no DFD preliminar podem ser utilizados para sugerirem objetos no
DER pre liminar e os objetos que tenham sido cxpcrimcntalmcnte identificados no DER
preliminar podem ser usados para auxiliar a escolha dos depsitos adequados no DFD
preliminar. Nenhum dos modelos deve ser considerado como sendo o modelo dominante,
que controla os demais; todos esto no mesmo p dc igualdade e podem dar inestimvel
auxlio ao outro.
Voc tambm descobrir que a lista de eventos to til na elabo rao do DER inicial
como na do DFD inicia!. Os substantivos na lista de eventos muitas vezes se mostraro
como objetos no DER; por exemplo, se um evento for Cliente introduz pedido,
identificamos imediatamen te cliente e pedido como objetos experimentais. Podemos
usar, do mesmo modo, a lista de eventos como meio de verificao cruzada do
cada fluxo de dados atue como um duto que possa transportar elementos de dados em
velocidade infinita,
pedido de cliente
consulta sobre pedido de cliente
de cliente
situao de pedido
Figura 19.6 (a): Modelo incorreto de comunicao com retardo entre processos
pedido de cliente
SSAR
PEDIDO DE
3
PEDIDOS
situao de pedido
Figura 19.6 (b): Modelo correto de comunicao com retardo entre processos
consulta sobre pedido de cliente
448
DER inicial: todos os tipos de objetos do DER devem corresponder a substantivos na lista
de eventos.
19.5 RESUMO
A concluso mais importante deste capitulo e que voc no produ zir um modelo
comportamental que esteja pronto para ser mostrado ao usurio. Ele no est terminado,
no est atraente e no suficientemen te simples ou bem organizado para ser
inteiramente compreendido. Pode-se ver um exemplo disto examinando-se o estudo de
caso do apndice F.
Ento, o que ele ? Qual o momento de executar as etapas descri tas na seo 19.3?
Muito simples, ele um comeo, uma estrutura sobre a qual voc pode assentar o
desenvolvimento da verso final, completa, do modelo essencial.
Neste momento voc no deve estar preocupado com a preparao do modelo
comportamental, ou com sua complexidade ou compreensi bilidade. Voc deve resistir
resolutamente tentao de reorganizar, empacotar, decompor ou recompor qualquer
bolha do DFD prelimi nar. Tudo com que voc deve se preocupar neste momento com a
correo subjacente do modelo: ele tem um processo para cada evento? Eie apresenta as
necessrias entradas e sadas para cada evento? E ele mostra as necessrias conexes
entre os eventos?
Depois de haver estabelecido Ludo isso,voc pode comear a traba lhar na reorganizao
do modelo. Isso ser discutido mais detalhada-
mente no captulo 20.
REFERNCIAS
1. Tom DeMarco, Sl Analysis and Systems Specification. Englewood Cliffs, N.J.:
Prentice-! lalI, 1979.
2. Chris Gane e Trish Sarson, Struclured Systems Analysis: lbols and Tecbniques.
Englewood Cliffs, N.J.: Prentice-! laIl, 1979.
3. Steve McMenamin e John Palmer, Essential Systems AnalysLs. Nova lorque:
YOURDON Press, 1984.
PERGUNTAS E EXERCCIOS
1. O que o modelo comportamental de um sistema? Para que serve?
2. Quais so os trs principais componentes do modelo comporta- mental pre1imina
449
3. Qual a abordagem clssica de construo do modelo comporta-
mental? Por que ela caracterizada como uma abordagem top
down?
4. Quais so os trs principais problemas normalmente encontrados
pelos analistas de sistemas ao tentarem seguir a abordagem top
down clssica para preparar o modelo comportamental de um
sistema de informaes?
5. Por que voc acha que alguns analistas de sistemas so tomados de
paralisia, ou do bloqueio de escritor, ao tentarem desenvolver o
DFD da figura O a partir do diagrama dc contexto?
6. Por que o modelo comportamental de alguns projetos apresenta
uma subdiviso fisica arbitrria?
7. O que significa a expresso subdiviso de eventos?
8. Quais so as quatro etapas da subdiviso dc eventos?
9. Se o analista de sistemas tiver descoberto 13 eventos no modelo
ambiental, quantos processos (bolhas) deve haver na primeira
verso do modelo comportamental?
10. Que tipo de esquema de numerao utilizado para se numerar as
bolhas na primeira verso do DFD do modelo comportamental?
11. Que base lgica utilizada para se dar um nome a cada bolha na
primeira verso do DFD do modelo comportamentaP
12. Como o analista de sistemas deve determinar as entradas, sadas e
depsitos necessrios a cada bolha na primeira verso do DFD?
13. Se um evento for dirigido por fluxos, quantos fluxos de dados de
entrada deve receber a bolha que processa esse evento?
14. Quais so as diretrizes dc verificao dc consistncia que o analista
de sistemas deve seguir ao desenhar a primeira verso do DFD do
modelo comportamental?
15. Como deve ser desenhada a primeira verso do DFD para o caso
de um evento que produz mltiplas respostas?
16. Sob que condies pode urna bolha nica na primeira verso do
DFD estar associada a mais dc um evento?
17. Na primeira verso do DFI), como as bolhas comunicam-se entre
si? Isto , como a sada produzida por uma bolha torna-se a entrada
de outra bolha?
18. Como a primeira verso do l)Fl) mostra a sincronizao de eventos
mltiplos, assmncronos e interdependentes?
19. O que deve ser desenvolvido primeiro: a primeira verso do DFD
ou a primeira verso do modelo de dados (I)ElO? Por que?
20. O que o analista dc sistemas dcvc fazer com a primeira verso do
DFD e do DER depois de hav-las completado?
21. Quando a primeira verso do I)FD est pronta, deve ser revista
com o usurio? Por qu?
450
22. O que est errado na primeira verso dc DFD abaixo?
23. O que est errado na primeira verso de DFD abaixo?
crdito
o)
PROCESSAR
o
TO
o
w
o LISTA DE EVENTOS (do modelo ambiental)
1. Cliente pede item.
2. Cliente devolve um item.
2. Cliente efetua pagamento.
451
20
COMO COMPLETAR
O MODELO
COMPORTAMENTAL
Dem-nos as ferramentas e completaremos nossa tarefa.
Winston Churchill,
transmisso radiofnica, 194
Neste captulo, aprenderemos:
1. Como subdividir um DFD inicial em nveis deforma ascendente.
2. Como ocultar depsitos dc dados locais.
3. Quando e como subdividir dc forma descendente as bolhas de um DFD inicial.
4. Como completar o dicionrio de dados inicial.
5. Como completar as especificaes dc processos.
6. Como completar o modelo de dados.
7. Como completar o diagrama de transies de estado.
No captulo anterior, apresentei um estratgia para desenvolver uma verso inicial do
modelo comportamental. Entretanto, evidente que aquele modelo no pode ser
apresentado ao usurio para verifica o. Por que no? Em primeiro lugar porque ele
complicado demais. Como vimos no captulo 19, o DFD preliminar ter um processo
para ca da evento que identificamos no modelo ambiernal; assim, ele pode ter 40 cu 50
bolhas, e possivelmente mais. Dc maneira semelhante, a verso inicial do DER
provavelmente muito tosca para ser revista com os usu rios; como discutimos no
captulo 12, necessrio algum refinamento para eliminar os objetos desnecessrios e/ou
acrescentar novos objetos.
453
Existe um segundo problema com o modelo: ele composto po muitos grficos, com
pouco ou nenhum suporte textual. Embora o dia grama de fluxo de dados e o de
entidades-relacionamentos sejam exce lentes veculos de apresentao dc uma vista geral
do sistema a usurio eles necessitam do apoio de um dicionrio de dados e de um conjunt
completo de especificaes dc processos.
20.1 COMO COMPLETAR O MODELO DE PROCESSOS
20.1.1 A Subdiviso do DE!) em Nveis
O primeiro passo reorganizar o DFD que desenvolvemos no captulo 19. Como vimos,
ele compe-se de um nico nvel, com dema siadas bolhas. Ento, precisamos subdividir
o I)FD em nveis ascenden tes. Isso quer dizer que desejamos agrupar processos
relacionados em agregados significativos, cada um representando uma bolha de um dia
grama de nvel mais elevado. Isso ilustrado na figura 20.1.
Existem trs diretrizes que voc deve ter em mente ao fazer isso:
1. Cada agrupamento de processos deve envolver respostas estrei tamente relacionadas
(lembre-se que cada bolha no DFD preliminar tem um nome relativo resposta a um
evento da lista de eventos). Isso habitualmente significa que OS processos lidam com
dados estreitamente relacionados.
2. Procure oportunidades para ocultar, ou sepultar, dados arma zenados que apaream
no nvel inferior. Assim, se voc en contrar um grupo de processos no DFD preliminar
relativo ao mesmo depsito, sem que oulros processos no DFD preliminar se refiram a
esse depsilo, ento voc deve criar uma bolha em nvel mais alto que oculte aquele
depsito. Isso ilustrado na figura 20.2.
3. Lembre-se de que a pessoa que examinar seus diagramas de fluxo de dados, seja ela
um usurio ou um analista de sistemas, no quer ver tudo de uma s vez. lm face disso,
voc deve criar agregados ou grupos provenientes do DFD preliminar com postos por
cerca de 7 mais ou menos 2 fragmentos de informa o, onde um prc (e os fluxos que
lhe sejam relacionados) ou um depsito possa ser considerado um fragmento
Isso, naturalmente, significa qu )odemos precisar de algum esfor o de subdiviso em
nveis ascendentes. Por exemplo, se comeamos
454
1 RESULTADO DA SUBDIVISO
EM NVEIS ASCENDENTES
DFD PRELIMINAR
Figura 20.1: Subdiviso de um DFD em nveis ascendentes
com um DFD preliminar que tinha (para fins de argumentao) 98 processos e
organizamos o diagrama em grupos de 7 bolhas (ignorando, para favorecer a
simplicidade, todos os depsitos), poderamos criar um diagrama de nvel mais alto com
14 bolhas, cada uma delas representan do uma abstrao de sete bolhas do n inferior.
Mas 14 bolhas um nmero elevado para se manipular e muito grande para ser mostrado
ao usurio de uma s vez; desse modo, ns possivelmente criaramos um diagrama de
nvel ainda mais elevado, como na figura 20.3, com apenas duas bolhas.
Observe que este exemplo envolve nmeros inteiramente artifi ciais. Voc no deve
orientar sua atividade de subdiviso em nveis de forma a garantir que cada diagrama
tenha exatamente sete bolhas! Na verdade, as duas primeiras diretrizes acima citadas,
agrupar bolhas se gundo os dados comuns e buscar oportunidades de ocultar depsitos
455
RESULTADO DA SUBDIVIS EM NVEIS ASCENDENTES
DFD PRELIMINAR
Figura 20.2: A ocultao de um deposito local no nivel superior
locais, devem ser sua principal base lgica para a subdiviso em nvei
ascendentes, e no uma lei aritmtica.
Observe ainda que voc tambm pode precisar fazer subdivise em nveis descendentes.
Isto , os processos idcntifkados no DFD preli minar podem no ser processos primitivos
e exigirem subdivises par baixo, em DFD de nveis inferiores. Isso significa apenas que
os proces sos iniciais, cada um dos quais responsvel pela produo da respost a um
evento, podem ser demasiadamente complexos para serem descri tos em uma
especificao de processos de uma pgina. Isso muitas ve zes torna-se evidente quando se
examina cuidadosamente o processo ou quando se solicita ao usurio uma explicao do
que a bolha dev fazer. Se o usurio hesitar por um instante, inspirar profundamente
456
Figura 20.3: M1t subdivises ascendentes de um DFD
disser Bem, uma longa histria, mas mais ou menos o seguinte uma boa indicao
de que aquela bolha preliminar ter de ser subdividida!
Em outros casos, a necessidade dc subdividir cm nveis no sentido
descendente pode no se tornar evidente at que voc realmente tente
redigir a espccifkao de processos; se voc notar que j escreveu trs
FIGURA o (duas bolhas>
lesultado da primeira su bdiviso m nveis ascendentes
(14 bolhas)
o
o
o
o
o
DFD preliminar (98 bolhas)
o
o
457
pginas sobre uma bolha preliminar e ainda h mais, muito mais a se escrito, outra
indicao da necessidade da subdiviso.
Eis algumas diretrizes para a subdiviso em nveis descendentes:
Em alguns casos, a abordagem de decomposio funciona pura adequada. Isto , se
voc encontrar uma bolha de proces. so que execute uma funo complexa, tente
identificar sub. funes, cada uma das quais podendo ser uma bolha de nve, mais baixo.
Suponha, por exemplo, que tenhamos um processc chamado Ajustar trajetria do
mssil; ele poderia ser a bolha responsvel pela manuteno dc um evento temporal em
uni sistema de direo dc msseis cm tempo-real. A funo geral de ajustar a trajetria do
mssil poderia ser decomposta em vria5 subfunes:
Calcular a variao da coordenada x.
- Calcular a variao da coordenada y.
- Calcular a variao da coordenada z.
- Calcular o novo fator de arrasto atmosfrico.
- Calcular a nova velocidade do vento.
- Calcular fora de impulso da coordenada x.
- Calcular fora de impulso da coordenada y.
- Etc.
Em outros casos, os fluxos de dados que chegam e que saem da bolha daro a melhor
indicao para a subdiviso em nveis descendentes. Por exemplo, suponha que tenhamos
uma bolha como a da figura 20.4. provvel que um DFD de nvel inferior possa ser
criado com a forma geral mostrada na figura 20.5. Evidentemente, pode ser necessrio
mais de uma bolha para combinar ou agregar os elementos de dados, mas a idia a
mesma: deti os dados seivirein de guias.
Enquanto voc estiver envolvido com a atividade de subdivdir os nveis de maneira
ascendente ou descendente lembre-se da impor tncia do equilbrio. Isto (como vimos
no captulo 14), preciso veri ficar se as entradas e sadas de urna bolha de um
determinado nvel
458
x
p
correspondem s entradas e sadas dc um diagrama do nvel ime diatamente inferior. Para
ver um exemplo da atividade de subdiviso ascendente, leia o estudo de caso do Sistema
dc Informaes da YOURDON Press no apndice F. Naquele caso comeamos com um
DFD preliminar contendo 40 bolhas; tornou-se necessrio um nvel de ;ubdiviso
ascendente, conduzindo-nos a um DFD da figura O com nove olhas.
Figura 20.4: Decomposio de uma bolha complexa em nveis descendentes
entrada intermediria (X)
Figura 20.5: O DFD de nvel inferior
459
20.1.2 Como Completar o Dicionrio de Dados
Quando voc comeou a desenvolver o DFD preliminar no cap tulo 19, deve tambm ter
iniciado o desenvolvimento do dicionrio d dados; na verdade bastante comum
comear-se o dicionrio de dado quando o diagrama de contexto est sendo desenvolvido.
Entretanto, dc ainda est longe de estar completo. Normalmente, ainda ser necessric
fazer a descrio do st dc cada itcm de dado; por uma questc de clareza,podc tambm
ser necessrio dividir os itens de dados comple xos em subitens.
Quando o dicionrio de dados estiver ficando pronto, precisc verificar se ele est
consistente e completo. Inspecione-o para ver se est internamente consistente (cx.: se
uma parte do dicionrio no contra- diz alguma outra parte). Certifique-se tambm que o
dicionrio est equilibrado em relao ao diagrama de fluxo de dados em nveis, ao dia
grama de entidades-relacionamentos e s especificaes de processos.
20.1.3 Como Completar as Espec de Processos
Quando desenvolvemos o diagrama de fluxo de dados preliminar, utilizando a abordagem
da subdiviso dc eventos mostrada no captulo 19, h grandes possibilidades dc que no
tenhamos feito qualquer espe cificao de processo. Poder haver algum caso de uma
determinada especificao ter sido esboada face a um interesse particular de sua parte ou
de parte do usurio, mas sua principal preocupao ser apenas com a preparao do
prprio DEr).
Na verdade, muitas vezes uma m idia gastar tempo com a escrita de especificaes de
processos antes que o DFD esteja pronto, porque o desenvolvimento inicial do I)Fl) est
sujeito a muitas modifica es, correes e revises. As bolhas podem aparecer,
desaparecer, ser movidas e rebatizadas. Quando o DFD preliminar comea a se assentar e
passa pelo teste da subdiviso cm nveis ascendentes (isto , essa ativi dade no descobre
maiores falhas no modelo), voc pode comear a redigir as especificaes de processos.
Esse trabalho muitas vezes prolongado e consumidor de tempo, porque cada bolha do
nvel mais baixo do I)FD exige uma especificao de processo. Desse modo, pode ser
possvel a um grupo de dois ou trs analistas de sistemas desenhar algumas dezenas de
DFD; mas ser neces srio um grupo maior de analistas para completar todas as
especificaes. de processos em tempo satisfatrio.
Quando as especificaes de processos estiverem prontas, devem
ser equilibradas e passar por uma verificao cruzada em relao ao
460
[ de dados e ao DER, observando-se as diretrizes apresentadas Lo captulo 14.
O.2 COMO COMPLETAR O MODELO DE DADOS
Como dissemos no captulo 12, o DER desenvolvido em uma nodalidade um tanto
semelhante que foi apresentada sobre o DFD:
sboamos um DER e depois o refinamos e melhoramos. Grande parte lo melhoramento
feita designando-se ou atribuindo-se elementos de lados aos adequados tipos de objetos;
isso costuma ser uma boa aju la na identificao de novos tipos de objetos ou de tipos de
objetos lesnecessrios.
Lembre-se, contudo, que o DER muitas vezes desenvolvido mais )u menos ao mesmo
tempo que o DFD. muito comum encontrar tlgum (ou um pequeno grupo) da equipe
de projeto trabalhando no )ER, enquanto outra pessoa (ou um outro pequeno grupo) trata
do )FD. Ou ento o DFD pode ser desenvolvido pela equipe de projeto, nquanto o DER
desenvolvido por um grupo de administrao centra izada de dados dentro da organizao
de PED. Em qualquer que seja ) caso, se o DER e o DFD forem desenvolvidos
aproximadamente ao mesmo tempo, o conhecimento adquirido com o DFD (existncia de
Jepsitos, fluxos de dados etc.) pode muitas vezes ser usado para refinar fazer
verificaes cruzadas do DER
O.3 COMO COMPLETAR O DIAGRAMA DE
TRANSIES DE ESTADO
Se o seu sistema possuir caractersticas de tempo-real, voc desen olver um diagrama de
transies de estado em acrscimo ao DFD e ao J.iagrama de entidades-relacionamentos.
O conhecimento detalhado do :omportamento do sistema poder ajud-lo a refinar esse
modelo. Como Jissemos no captulo 13, voc deve examinar o diagrama inicial de tran
ies de estado em busca dos seguintes tipos comuns de erros:
Todos os estados foram definidos?
Todos os estados podem ser atingidos?
Pode-se sair de todos os estados?
O sistema responde adequadamente, em cada estado, a todas as condies possveis?
461
20.4 RESUMO
Atingimos, aqui, o final do modelo essencial. Se voc acompanho todas as etapas dos
captulos 18, 19 e este captulo, deve estar de poss de um modelo completo, detalhado,
formal e rigoroso de tudo o que sistema deve fazer para satisfazer os requisitos do
usurio. Ele contn todos os itens abaixo:
Diagrama de contexto
Lista de eventos
Declarao de objetivos
Um conjunto completo de diagramas de fluxo de dados ezr nveis
Diagrama de entidades-relacionamentos terminado e completo
Um conjunto completo de diagramas de transies de estado
Dicionrio de dados completo (para a fase de anlise dc projeto)
Um completo conjunto de especificaes de processos, con uma especificao para cada
processo do nvel mais baixo.
Presumindo que voc tenha revisado os componentes da especi. ficao para certificar-se
de que esto completos e consistentes e que c usurio revisou e aprovou o documento,
voc terminou. Voc pode passar um belo lao vermelho em volta do pacote e entreg-lo
equipe de projeto/programao cuja tarefa ser construir o sistema. Em seguida, pode
recolher-se ao aconchegante conforto de seu escritrio at que suna o prximo projeto.
Mas, espere! Ainda h uma ltima etapa. Tudo o que desenvol vemos no modelo
essencial pressupunha a existncia de perfeita tecno logia, mas tambm que o usurio no
teria restries de implementac a impor ao sistema. Perfeita tecnologia uma fantasia
de nossa ima ginao, mas podemos deixar que a equipe de implementao decida como
alcanar um compromisso razovel coma tecnologia existente.
A idia de que o usurio vai ignorar todas as restries de imple. mentao tambm
uma fantasia, com a qual teremos de lidar ante5 de passarmos a verso final da
especificao para a equipe de imple mentao. Essa atividade final, que deve ser feita
com a colaborao do
462
usurios, dos analistas e de al,guns membros da equipe de implemen tao, o
desenvolvimento do modelo de implementao do usurio. Esse assunto ser discutido no
prximo captulo.
PERGUNTAS E EXERCCIOS
1. Por que a primeira verso do modelo comportamental no pode ser apresentada ao
usurio?
2. A primeira verso do modelo comportamcntal completa? Se no , que elementos lhe
faltam?
3. O que significa subdiviso em nveis ascendentes no contexto des te captulo?
4. Qual a base lgica que o analista de sistemas deve usar para agrupar bolhas cm um
DFI)?
5. Quais so as trs diretrizes que o analista dc sistemas deve lembrar ao fazer uma
subdiviso em nveis ascendentes?
6. O que significa o conceito de ocultao de dados armazenados no contexto deste
captulo?
7. Quantos nveis de DFD dc nvel mais elevado devem ser criados a partir de um nico
DFD de primeira verso? Existe alguma frmula matemtica que possa ser utilizada para
dar uma aproximao do nmero necessrio de nveis?
8. Sob que condies a subdiviso de um DFD em nveis descenden tes torna-se
necessria?
9. possvel que o analista de sistemas precise executar a subdiviso de um DFD em
nveis ascendentes e descendentes? Por qu?
10. Por que o dicionrio de dados normalmente deve estar pronto du rante o estgio de
desenvolvimento do modelo comportamental?
11. Que tipo de verificao de erros deve ser feita no dicionrio de dados durante esse
perodo do projeto?
12. Por que muitas vezes no uma boa medida que o analista de sistemas despenda
tempo redigindo especificaes de processos antes que o DFD preliminar esteja
completo? Sob que condies faria sentido escrever pelo menos algumas especificaes?
13. Quais so os oito principais componentes do modelo terminado dos requisitos do
usurio?
NOTAS
1 Esse nmero aparentemente arbilrrio (sete mais ou menos dois)
uma diretriz para controlar a complexidade em diversas situaes
de resoluo de problemas. Ela se fundamenta na obra de George
463
Milier, que foi o primeiro a perceber a dificuldade das pessoas err lidar com mltiplos
fragmentos de informao, em um clssico ar tigo intitulado The Magical Number
Seven, Plus or Minus lwo Some Limits on Our Capacity for Processing Information,
publica do em Psycholo Revew, Volume 63 (1956), pgs. 81-97.
2 O ideal que os modelos I)ER e 1)1:1) sejam desenvolvidos pelc mesmo grupo,
trabalhando cm conjunto. Isso evita problemas d comunicao, e tende a garantir que seja
dada a mesma nfase a ambos os modelos. Infelizmente, isso raramente acontece no mun
do real.
464
21
O MODELO DE IMPLEMENTAO
DO USUARIO
Deve ser observada uma simplicidade espartana. Nada poder ser feito apenas porque
contribui para a beleza, convenincia, conforto ou prestgio.
Office of lhe ChiefSi.gnal Offcer, U. S. Ar?ny,
29 de Maio de 1945
Neste captulo, aprenderemos:
1. Como escolher as fronteiras da automatizao para um sistema.
2. Como selecionar os dispositivos de entrada e os dis positivos de sada para o usurio.
3. Como desenvolver os formatos dc entrada e os for matos de sada.
4. Como projetar formulrios para o sistema.
5. Como desenvolver esquemas de codificao para entradas de sistemas.
6. Como identificar atividades manuais de suporte.
7. Como descrever as restries operacionais do sistema.
Ao finalizarmos o ltimo captulo terminamos o desenvolvimento do modelo essencial de
um sistema dc informaes. Esse modelo con tm uma descrio completa do que o
sistema deve fazer para satisfazer o usurio. Especificamente o modelo essencial
descreve:
465
1
A ao essencial ou lgica das funes que devem s executadas.
O contedo essencial dos dados armazenados pelo sistema que se movimentam atravs
dele.
O comportamento essencial tempo-dependente que o sistern deve exibir para lidar com
os sinais e as interrupes do arr
biente externo.
No melhor de todos os mundos (do ponto dc vista do analista d sistemas e da equipe de
implementao), isso representa informac suficientes para os projetistas e
programadores: ns simplesmente lhc daremos o modelo essencial e os deixaremos
escolher o melhor harc ware, o melhor sistema opcracional, o melhor sistema de
gcrcnciament de banco de dados e a melhor linguagem de programao, dentro da
restries gerais de tempo, dinheiro e recursos humanos para o projetc Entretanto, isso
no to simples: em virtualmente todos os projeto de desenvolvimento dc sistemas, o
usurio insistir em que se incluar informaes adicionais.
Essas informaes adicionais envolvem problemas de imp1emei lao - mas problemas
de implementao que sejam suficientementi importantes e que tenham impacto
suficiente na capacidade do usuri em utilizar o sistema para que precisem ser
especificados agora. O pro biema mais evidente de implementao de interesse do
usurio a fron teira da automatizao, isto , que partes do modelo essencial ser
implementadas em computador, e que partes sero executadas manual mente na
organizao do usurio? O analista de sistemas pode ter um opinio sobre isso, e o grupo
projetista/programador pode tambm que rer exprimir sua opinio, mas este,
naturalmente, um problema sobre qual o usurio tem a ltima palavra.
De modo anlogo, ofonnaio das entradas do sistema (tambm co nhecido como interface
humana) de grande interesse para o usurio- muitas vezes, ele parece ser dc interesse
maior do que as funes dc sistema! Desde que os sistemas dc processamento comearam
a gerai relatrios impressos, os usurios tm manifestado fortes opinies sobre
organizao e o layout das informaes do relatrio. Onde devem ficai os nmeros das
pginas? Onde devem ser colocados os ttulos das p ginas? Como deve ser arrumada
cada linha de informao para mxima legibilidade? Deve haver um resumo ou um
subtotal ao final de cada pgina ou somente ao final do relatrio? E assim por diante.
Com o advento dos sistemas on-line nos anos 70, esse problema
expandiu-se incluindo o interesse do usurio na formatao das telas dc
entrada do terminal de vdeo. Onde devem ser apresentadas na tela as
466
mensagens de entrada? Que espcies de mensagens de erros devem ser exibidas? Como o
usurio dever mover-se de uma tela para outra?
Mais recentemente diversas outras opes e possibilidades vieram
aumentar a importncia desses problemas de implementao do usurio:
Os usurios finais muitas vezes tm a oportunidade de usar computadores pessoais (PC)
como parte de uma rede distribu da de computadores (p.ex., so-lhes dados PCs
interligados ao computador de grande porte da organizao). Isso levanta uma srie de
questes: que partes do mode essencial sero desig nadas para o PC (sob controle do
usurio) e quais ao main frame? Que partes dos dados sero designadas para o PC e que
partes ao mainframe? Qual ser o formato da entrada que o usurio fornecer ao PC?
Quais as atividades adicionais de apoio que devem ser oferecidas para assegurar que o
usurio no danifique inadvertidamente os dados do PC ou do mainframe?
Os usurios finais atualmente esto tendo cada vez mais opor tunidades para escrever
seus prprios programas em linguagens de quarta gerao como FOCUS, NOMAD e
IDEAL em computa dores de grande porte, ou dBASE-III e Rbase-5000 nos PCs.
proporo que se envolvem com tais problemas de implemen tao, eles precisam
especificar os formatos das entradas e sadas do sistema. E mais, eles podem querer
decidir que partes do sistema sero implementadas usando linguagens de quarta gerao e
que partes sero implementadas com linguagens con vencionais de terceira gerao
Em muitas situaes hoje em dia, o usurio e o analista de sis temas podem decidir
prototipar partes do sistema, usando ou uma linguagem de quarta gerao de alto nvel ou
um pacote gerador de aplicaes. A prototipao pode ser feita porque o usurio est
inseguro da ao detalhada que eventualmente ter de ser escrita nas especificaes de
processos do modelo essen cial; porm, a atividade de prototipao est, na maioria das
vezes, interessada na explorao e experimentao com forma tos de entrada, dilogos
on-line e formatos de sada para telas e relatrios.
Para muitas aplicaes da empresa, uma opo disponvel ao usurio a escolha e
aquisio de um pacote de software, isto , um produto de software que pode ser utilizado
sob licena ou adquirido de um fornecedor. Nesse caso, os mesmos problemas de
implementao so importantes para o usurio: que partes
467
das funes essenciais sero implementadas pelo pacote adqui rido e que partes tero dc
ser executadas pelo usurio (ou im plementadas pelo setor dc SIG do usurio como um
sistema se parado)? Que partes dos dados essenciais sero mantidos pek pacote e que
partes tero dc ser mantidas pelo usurio? sero a forma e a seqncia das entradas
exigidas pelo sistem adquirido e sero elas aceitveis
E problemas devem ser tratados como parte do modelo de Im plementa do usurio. Eles
podem ser originados pelo aumento, pek incluso de observaes e pela reviso do
modelo essencial, como ve remos nas sees subseqentes deste capftulo. Recomendo,
entretanto que voc mantenha sempre intacta uma cpia do modelo essencial origi na!;
isto permitir que voc experimente modelos alternativos de imple mentao do usurio
no futuro.
Em termos gerais, o modelo dc implementao do usurio abrang
os quatro aspectos seguintes:
. A alocao do modelo essencial a pessoas versus mquinas.
2. Detalhes da interao homem/mquina.
3. Suplementares atividades manuais que podem vir a se necessrias.
4. Restries operacionais que o usurio deseja impor ao sistema.
Todos esses aspectos sero discutidos cm maiores detalhes
seguir.
21.1 A DETERMINAO DOS LIMITES DA AUTOMATIZAO
Lembre-se de que o modelo de sistema em que estamos traba lhando neste momento
identifica todas as atividades (funes) essenciai e todos os dados essenciais. A pergunta
a esta altura : que funes que dados sero manipulados manualmente, e quais sero
automatiza dos? Embora possa ter havido uma experimental escolha preliminai dos
limites da automatizao durante o estudo de viabilidade no de. vemos consider-los
como fixados. Na realidade, o limite da auta matizao quase irrelevante no modelo
essencial, pois embora c usurio obviamente deseje que desenvolvamos um sistema auto
matizado, ele tambm necessita de uma bem elaborada declarao dc
468
requisitos das funes e dos dados que ficaro fora das frontLiras da automatizao.
Existem trs casos extremos que mencionaremos sucintamente:
O usurio pode no se importar com onde esteja a fronteira da automatizao.
improvvel que isso acontea, mas uma possibilidade terica. Na prtica, o usurio
solicita equipe de implementao, Diga-me que partes do sistema devem ser manuais
ou automatizadas. Alm do fato de que o usurio normalmente tem grande sensibilidade
sobre esse problema, es pera-se que o analista de sistemas produza (como produto se
cundrio do seu trabalho) uma anlise revisada de custo/be nefcio de todo o projeto. Isso
costuma exigir pelo menos al guma deciso preliminar de que partes do modelo essencial
sero automatizadas e quais sero manuais.
O usurio pode optar por um sistema inteiramente automati zado. Essa uma situao
muito comum, principalmente se o sistema estiver sendo desenvolvido para substituir um
outro sis tema j existente e suas fronteiras no sero alteradas. Desse modo, as
atividades manuais executadas pelo usurio podem j estar fora dos limites do sistema -
representadas no diagrama de contexto como terminadores com os quais o sistema se
comunica.
O usurio pode optar por um sistema inteiramente manual. F.ssa uma opo bastante
incomum, especialmente nesta era da automatizao, pois o analista dc sistemas
habitualmente tem interesse em computadorizar o quanto for possvel. Entretanto, isso
pode ocorrer em ocasies cm que a inteno expressa do usurio no seja computadorizar
coisa alguma, mas simples mente reorganizar a maneira com as atividades estejam presen
temente sendo executadas em uma organizao.
Normalmente, esses casos extremos no ocorrem; com base nas interaes entre o
usurio, o analista de sistemas e a equipe de imple mentao, algum acordo ser ajustado.
Isto , al,guinas das atividades do modelo essencial sero automatizadas, e outras sero
identificadas como funes manuais; de forma anloga, alguns dos dados essenciais sero
identificados como candidatos certos para computadorizao (sendo, presumivelmente,
colocados sob o controle de uma organizao de SIG) e alguns sero deixados sob o
controle direto do usurio. A menos que o usurio faa uma escolha imediatista e
arbitrria por ordem, ser aconse lhvel que as tr.s partes (o usurio, o analista dc
sistemas e a equipe de
469
implementao) examinem diversas opes. Como as figuras 21.1(a), (b e (c)
demonstram, pode haver diversas alternativas razoveis para detei minar o limite da
automatizao. Cada alternativa ter custos diferente (em cuja estimativa a equipe de
implementao deve auxiliar, uma ve
PARTE
MANUAL
Figura 21.1 (a): Uma opo para afronteira da automatizao
Figura 21.1 (b): Outra opo para os limites da automatizao
470
PARTE
AUTOMATIZADA
Figura 21.1 (c): Uma terceira opo para os limites da automatizao
que eles tm o conhecimento das possibilidades da tecnologia de imple mentao) e
ramificaes organizacionais diferentes na rea do usurio.
A tarefa de determinar os limites da automatizao no da ala da do analista de
sistemas e nem da equipe de implementao; ela , em ltima anlise, da
responsabilidade do usurio, e este livro no apresentar qualquer diretriz para determinar
qual seria a melhor escolha. Mas, observe como o modelo essencial serve como uma til
ferramenta para o usurio e para a equipe de implementao exami narem as diversas
opes. Uma vez que a fronteira da automatizao tenha sido escolhida, o analista de
sistemas pode pensar que ele tem o privilgio de eliminar os processos manuais e dados
manuais (isto , as bolhas e depsitos que no sero automatizados) sem maiores con
sideraes. Porm, geralmente no assim. No caso mais simples, as ati vidades e dados
manuais podem ter de voltar para os terminadores que envolvem o sistema, como
ilustrado nas figuras 21.2(a) e (b).
Mas, em geral, o analista de sistemas deve reconhecer que mesmo as atividades manuais
fazem parte do novo sistema. Portanto, o analista pode ter de escrever procedimen para
que os membros da comunida de usuria saibam como executar as funes requeridas. E
o analista pode ter de fornecer alguma orientao na organizao de depsitos que no
sero automatizados Observe que esse aspecto do modelo de implementao do usurio
precisa apenas que sejam feitas observaes no DFD e no PRD para indicar quais
atividades e dados so manuais e quais so automatizados.
471
PARTE
UTOMATIZADA
Figura 21.2 (a): Um modelo essencial com os limites da automatizao
Figura 21.2(b): As atividades manuais foram colocadas dentro dos terininadores
472
Observe que quando se determinam as fronteiras da automatiza o pode ser importante
considerar alguns problemas ambientais; volu me do som, radiao, iluminao, aspectos
ergonmicos do terminal de vdeo, espao de trabalho e assim por diante. Quase sempre o
novo sistema desorganiza o ambiente normal dc trabalho do usurio (p.ex., ele far com
que um terminal dc vdeo seja colocado na mesa do usu rio, onde nunca tinha existido
um antes) Ou pode introduzir atividades de processamento de informaes em um
ambiente onde nunca tinham sido executadas essas atividades antes (ex., um piso dc
fbrica em um ambiente de manufatura). Assim, importante garantir que esses fatores
humanos tenham sido cuidadosamente estudados antes da determina o final das
fronteiras da automatizao. O usurio muitas vezes tem importantes opinies a expressar
sobre esses aspectos, porm se ele no tiver experincia anterior em sistemas dc
informaes, pode no ser capaz de adiantar quais sero os problemas. Voc pode se
aconselhar com Outros profissionais dc sistemas que desenvolveram e instalaram
sistemas semelhantes em iguais condies ambientais.
Para finalizar, observe que uma vez que tenha sido decidida a fronteira da automatizao,
pode ser necessrio aumentar o modelo es sencial para mostrar como dar partida no
sistema e como termin-lo; o modelo essencial mostra somente o comportamento
steady-state do sistema, e pressupe que o sistema esteve sempre funcionando e assim
continuar para sempre. Desse modo, podemos precisar incluir processos (bolhas no
DFD), fluxos de dados e depsitos adicionais para mostrar as atividades inicializadoras e
tcrminadoras do sistema; isso pode incluir relatrios para a direo (ou para os usurios
ou para o de partamento de operaes) sobre as caractersticas operacionais do sistema.
21.2 A DETERMINAO DA INTERFACE HUMANA
A atividade mais consumidora dc tcmpo e na qual o usurio estar
mais interessado, provavelmente a especificao da interface humana.
Isso envolve quatro problemas relacionados:
1. A escolha de dispositivos dc entrada e sada (p.ex., terminais de vdeo, dispositivos de
kitura tica, cartes perfurados etc. para entrada e relatrios impressos, imagens na tela
do monitor, ou luzes piscantes como sada).
2. O formato de todas as entradas que fluem dos terminadores para o sistema.
473
3. O formato de todas as sadas que fluem de volta do sistema para os terminadores.
4. A seqncia e o timing de entradas e sadas em um sistema on-line.
21.2.1 Dispositivos de Entrada e Sada
A escolha dos dispositivos de entrada e sada pode ser imposta pelos terminadores
externos ao sistema; por exemplo, se o sistema pro duzir relatrios de sada a serem
enviados ao governo, pode no haver outra escolha seno produzir relatrios impressos.
Os dispositivos que costumam ser usados para entrada de dados incluem:
Cartes perfurados. Os cartes perfurados foram a forma mais comum de entrada de
dados, porm so raramente utilizados atualmente, exceto em alguns sistemas batch de
processamento muito grandes. Uma vantagem dos cartes perfurados que eles podem
ser usados como documentos fonte pelo usurio externo (p.ex., considere os cheques
produzidos por alguns sistemas do governo; eles so documentos negociveis, mas
tambm so usados como entrada direta para um sistema de processamento). As maiores
desvantagens dos cartes perfurados so o tamanho volumoso, capacidade limitada de
armazenamento de dados, o fat