Análise Estruturada Moderna

Consultor Editorial
Fernando Barceilos Ximenes

KPMG Consulting
Tradução
Dalton Conde de Alencar
Mestre em Informática
pelo Instituto Militar de Engenharia
yrOkIz
ESSOOAÇÃO D DE O CEPCOCRÁHCOS
ooierrro
EDITORA AFIL lADA
P Preencha a ficha de cadastro no final deste livro
e receba gratuitamente informações
sobre os lançamentos e promoções
da Editora Campus.
Consulte também nosso catálogo
completo e últimos lançamentos em
www.campus.com.br
EDWARD YOURDON
ANÁLISE
ESTRUTURADA
MODERNA
TRADUÇÃO DA TERCEIRA EDIÇÃO AMERICANA
12 Tiragem
mm.
CAMPUS
SERIE YOURDON PRESS
‘6s’’ 1
Do original:
Modem Structured Analysis - 3 rd Ed.
Tradução autorizada do idioma inglês da edição publicada por i- Inc.
Copyright © 1989 by Prentice-Hall, Inc. ci (./ . 2-1
© 1990, Editora Campus Ltda.
CL
http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

Página 1 de 584
Todos os direitos reservados e protegidos pela Lei 5988 de 14/12/73.
Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida
ou transmitida sejam quais forem os meios empregados:
eletrônicos, mecãnicos, fotográficos, gravação ou quaisquer outros.
Todo o esforço foi feito para fornecer a mais completa e adequada informação. ) Contudo a editora
e o(s) autor(es) não assumem responsabilidade
pelos resultados e uso da informação fornecida. Recomendamos aos leitores testar a informação
antes de sua efetiva utilização.
Capa
Otávio Studart
Copidesque --
Maria Cláudia Ajúz Goulart
Editoraçâo Eletrônica UNIVERSt DADE ESTÁCIO DE SÃ
Graphbos J
Revisão Grã ltca _______
N
Projeto Gráfico -
AQuaIidade Informática. 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
(Edição Original: ISBN 0-13-598624-9, Prentice-Hall, Inc., Inc., New Jersey, USA).
Ficha Catalográfica
CIP-Brasil. Catalogação-na-fonte.
Sindicato Nacional dos Editores de Livros, RJ
Yourdon, Edward, 1944-
Y74a Análise estruturada moderna / Eward Vourdon; tradução
Dalton Conde de Alencar. - Rio de Janeiro: Campus, 1990.
Tradução de: Modem structured analysis
Apêndice
Indice
ISBN 85-7001-615-8

Página 2 de 584
1. Análise de sistemas. 2. Processamento de dados - Técnicas estruturadas. 1. Titulo
90.0087 CDD -001 64404
CDU -681.3.02
01020304 1615141312
Todos os esforços foram feitos para assegurar a precisão absoluta das informações apresentada
publicação. A editora responsável pela publicação original, a Editora Campus e o(s) autor(es) det se
isentam de qualquer tipo de garantia (explícita ou não), incluindo, sem limitação, garantias im de
comercialização e de adequação a determinadas finalidades, com relação ao código-fonte elc
técnicas descritos neste livro. A Editora CampuS e o(s) autor(es) não se responsabilizam por prol
relacionados à funcionalidade do código-fonte para datas a partir de 01/01/2000.
PREFÁCIO
O que é valioso não é noto
e o que é nova não é valioso.
Henry Peter, Lord Brougham
Tbe Edinburgh Review, 1802
Permitam-me fazer uma pergunta bastante óbvia: o mundo realmente precisa de outro livro sobre
análise de sistemas? Esta pergunta pode parecer retórica mas houve muitas ocasiões -
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 têm 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, não por mim. No entanto, creio
realmente que existe a necessidade de um livro que atualize parte do material clássico sobre análise
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
Technícs, não haviam linguagens de quarta geração, nem ferramentas de prototipação disponíveis
para os desenvolvedores de sistemas. Os computadores pessoais ainda não tinham sido lançados,
embora já existissem algumas das primitivas máquinas da Apple e da Radio-Shack. Não havia
produtos de software baseados em estações inteligentes que auxiliassem o analista de sistemas na
elaboração dos diagramas de fluxo de dados.
Os progressos nessas áreas tiveram um grande impacto na aceitação geral da análise estruturada:
muitos questionam se a análise estruturada é relevante em ambientes onde os usuários podem criar
suas próprias aplicações em questão de horas ou dias, Só isso já é motivo para um novo livro sobre
o tema da análise de sistemas: a bem mais poderosa tecnologia disponível para os analistas de
sistemas e usuários alterou nosso enfoque e perspectivas.
Além disso, os desenvolvedores de sistemas tiveram de enfrentar problemas de sistemas de bancos
de dados e de tempo real, em acréscimo aos sistemas “orientados por função” originalmente
visados pela análise estruturada no final dos anos 70. Este livro discute os diagramas de entidades e
de transições de estado, os clássicos diagramas de fluxo de dados e mostra como esses três modelos
podem ser integrados; essa integração de modelos se tornará mais e mais importante no decorrer
dos próximos anos. Alguns outros recentes desenvolvimentos na análise estruturada - incluindo o

Página 3 de 584
particionamento
de eventos e a desenfatização da modelagem do sistema físico atual - estão incluídos neste livro.
Existe ainda outra razão para se escrever mais um livro sobre aná lise estruturada: a maioria dos
livros “clássicos” sobre análise estruturada foi escrita para analistas de sistemas veteranos - sem
preocupação com os mais novatos, que ainda estão se iniciando na área. Ademais, a maioria dos
livros didáticos sobre análise de sistemas escritos, durante os últimos dez anos, deu pouca atenção
às novas técnicas de análise estruturada e continuou a dedicar muitas páginas às discussões sobre
cartões perfurados e sobre o código Hollerith; afora o fato de que muitos desses aspectos estejam
obsoletos, o conhecimento superficial do hardware, do software e da programação de
computadores é, geralmente, ministrado por um curso de “Introdução aos Computadores”, que
habitualmente precede o aprofundamento no estudo da análise de sistemas. Este livro tenta obter o
equilíbrio, reconhecendo a necessidade de algum material introdutório para os estudantes que
tiveram um curso inicial sobre computadores mas nunca fizeram análise de sistemas, embora
reconhecendo que os conceitos de análise de sistemas sejam simples o bastante para que possam
ser ensinados detalhadamente nos níveis de segundo grau e universitário. Em face disso, a maior
parte do material introdutório está reunido nos apêndices de modo que possam ser dispensados
pelos que já têm prática do assunto.
Este livro é adequado para cursos universitários de um semestre sobre análise 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 não abrange ambos os tópicos de análise 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 discussão 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 edição, de Meilir Page Jones (YOURDON Press, Englewood Cliffs,
N.J., 1988), ou o livro Struc tured Design, 2 edição, de Ed Yourdon e Larry Constantine
(YOURDON Press, Eng!ewood Cliffs, N.J., 1989).
Os analistas de sistemas veteranos podem ler o primeiro capítulo como orientação, e depois saltar o
restante da parte 1; os primeiros sete capítulos são básicos para os novos estudantes. Os veteranos
considerarão familiar boa parte da discussão sobre diagrama de fluxo de dados, dicionário de dados
e coisas desse tipo; entretanto, o capítulo 9 apresenta extensões de DFD para sistemas de tempo-
real que talvez sejam novos para aqueles que têm trabalhado exclusivamente em sistemas
orientados para o comércio. O estudo sobre diagramas de entidades- relacionamentos pode ser
novo, também, para os mais familiarizados com os “diagramas de estruturas de dados”, e a
discussão sobre os
diagramas de transições de estado no capítulo 13 apresenta uma nova ferramenta importante de
modelagem. É de grande interesse para os veteranos, os capítulos 19 e 20 apresentam uma
abordagem para a elaboração do modelo básico (também conhecido como modelo lógico), que
contrasta totalmente com a rígida 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 capítulo 17 recomenda que seja eliminada a clássica abor dagem de se
modelar o sistema físico atual” do usuário esse aspecto deve ser estudado atentamente pelos
analistas de sistemas cujas técnicas estejam baseadas em livros dos anos 70.

Página 4 de 584
Entre os apêndices há dois estudos de casos que mostram as diversas ferramentas e técnicas
discutidas neste livro. O primeiro estudo de caso é uma típica aplicação “orientada para o
comércio” baseada nas operações editoriais da YOURDON Press; o segundo é um exemplo típico
de «sistema de tempo-real” baseado em um sistema de controle de elevadores. Ambos são
apresentados detalhadamente, embora isso aumente o tamanho do livro: é importante que os
estudantes vejam um exemplo completo de uma especificação. Esses modelos podem ser usados
para discussões e exercícios em salas de aula.
Análise Estruturada Moderna é resultado de muitos anos de experiência com centenas de clientes
de consultoria, milhares de estudantes em seminários e dezenas de colegas na YOURDON Inc. e
outras organizações de consultoria; devo muito a essas pessoas, demasiadamente numerosas para
que eu as possa citar pelos nomes. Contudo, há algumas pessoas que merecem especial atenção,
por terem auxiliado a tornar este livro bem melhor do que poderia ter sido. Não se pode escrever
um livro hoje em dia sobre análise 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 exposição da análise estruturada; de modo semelhante, Paul Ward e Steve Mellor
apresentaram vários conceitos e ferramentas de modelagem importantes para sistemas de tempo-
real no conjunto de três volumes Structured Development for Real-Time Systems. Fui grandemente
beneficiado no ano passado em debates com colegas com os quais ministrei seminários sobre
análise 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 eloqüentes de explicar os conceitos de análise estruturada que eu, certamente,
não 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 análise de sistemas;
Capítulo 11
Especificações de Processos . 253
Capítulo 12
Diagramas de Entidades-Relacionamentos 289
Capítulo 13
Diagramas de Transições de Estado 319
Capítulo 14
O Equilíbrio dos Modelos 337
Capítulo 15
Ferramentas Adicionais de Modelagem 353
Capítulo 16
Ferramentas de Modelagem para Gerenciamento de Projetos 375
PARTE ifi
O PROCESSO DE ANÁLISE

Página 5 de 584
Capítulo 17
O Modelo Básico 391
Capítulo 18
O Modelo Ambiental 409
Capítulo 19
A Construção do Modelo Comportamental Preliminar 439
Capítulo 20
Como Completa: o Modelo Comportamental 453
Capítulo 21
O Modelo de Implementação do Usuário .. 465
PARTE IV
PROBLEMAS DE CONTINUIDADE
Capítulo 22
A Fase de Projeto 507
Capítulo 23
Programação e Testes 527
Capítulo 24
A Manutenção das Especificações 553
Capítulo 25
O Futuro da Análise de Sistemas 563
APÊNDICES
Apêndice A
Ferramentas Automatizadas 579
Apêndice B
Diretrizes da Avaliação 605
Apêndice C
O Cálculo de Custo/Beneficio 623
Apêndice D
Caminhamentos (Walkthroughs) e Inspeções 645
Apêndice E
Técnicas de Entrevistas e de Coleta de Dados 655
Apêndice F
Estudo de Caso: A Yourdon Press .... 671
Apêndice G

Página 6 de 584
Estudo de Caso: O Sistema de Elevadores 787
ÍNDI 821
1
INTRODUÇÃO
Oprincipio e a finalização de todos os empreendimentos humanos são desorganizados, a construção

de uma casa, a escrita de uma novela, a demolição de uma ponte e principalmente, ofim de uma
viagem.
John Galsworthy
Over the River, 1933
Neste capítulo, aprenderemos:
1. Porque a análise de sistemas é interessante.
2. Porque a análise de sistemas é mais difícil do que a programação.
3. Porque é importante estar familiarizado com a análise de sistemas.
Muito bem, aqui estamos no início de um longo livro. A perspectiva de ler um livro técnico assim
tão extenso provavelmente o assusta, mas pode servir de consolo o fato de ser ainda mais
aterrorizante quando se começa 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 são
feitos um capítulo de cada vez, e, em última análise, uma sentença de cada vez.
1.1 POR QUE A ANÁLISE DE SISTEMAS É INTERESSANTE?
Os livros longos geralmente são enfadonhos, este não o será. Ator tunadamente, o assunto deste
livro - análise de sistemas - é
interessante. Na realidade, a análise de sistemas é mais interessante que tudo que conheço,
excetuando, talvez, sexo e certos tipos de vinhos da Austrália. Ela é, sem dúvida, mais interessante
que a programação de computadores (não que a programação seja enfadonha) por envolver o
estudo das interações entre pessoas, entre gn diferentes de pessoas e entre computadores e
organizações.
Como disse Tom DeMarco em seu último livro, StructuredAnal
and Systems Speqflcation [ 1978],
a análise [ sistemas] é frustrante, repleta de relacionamentos entre pessoas, indefinida e difícil.
Resumindo, é fascinante. Depois que você é fisgado, os velhos e fáceis prazeres da construção de
sistemas nunca mais serão suficientes para satisfazê-lo.
Isto pode surpreendê-lo, no caso de você ter alguma experiência em escrever programas de

Página 7 de 584
computadores Programar é divertido, sendo ainda um desafio intelectual; é difícil imaginar algo
mais recompensador e agradável do que ver um programa ser processado com sucesso, prin
cipalmente depois de despender várias horas (ou dias!) expurgando-lhe os erros. É difícil imaginar
que pode ser ainda mais recompensador e excitante quando nos afastamos do computador e da
programação para estudarmos o sistema completo, do qual os programas participam. Po rém, 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 análise de sistemas.
Não importa a profissão que você decida seguir, será sempre im portante que você compreenda o
que é a análise de sistemas. Se você trabalha na indústria de computadores em algo diferente da
engenharia elétrica 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 nível de gerência
1.2 A QUEM ESTE LWRO É DIRIGIDO
Este livro está sendo escrito para dois tipos de pessoas: uma é a novata na área da análise de
sistemas, e a outra é o analista de sistemas experiente que precisa conhecer as ferramentas e
técnicas de modela gem de sistemas que evoluiram nos últimos cinco a dez anos. Muitos leitores
serão estudantes universitários da ciência dos computadores que completaram os cursos iniciais de
programação 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 universitário como pelas que já estejam
2
trabalhando na indústria. Muitas pessoas na indústria computacional passam seus primeiros anos
trabalhando como programadores e, depois, são subitamente promovidas (ou redesignadas) à
posição de analistas de sistemas, sem serem instruídas sobre o que seja a análise de sistemas ou
sobre o que faz um analista de sistemas. Se você estiver numa situação dessas, este livro é para
você. Ele também ser-lhe-á útil no caso de você ter começado a trabalhar como analista de sistemas
nos anos 60 ou 70 e nunca teve a oportunidade de aprender a respeito das técnicas da análise
estruturada, como diagramas de fluxo de dados, diagramas de entidades- relacionamentos e
dicionários de dados.
Com mais e mais freqüência hoje em dia, as pessoas estranhas ao computador estão descobrindo
ser necessário se familiarizar com a área de análise de sistemas. Se você é um homem de negócios
ou um gerente (ou é um dos profissionais descritos pelo pessoal da computação como usuários),
existe uma boa possibilidade de que você se envolva em alguma atividade de análise 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, funcionário, cientista, político ou um contador - ou exerce virtualmente qualquer
outra profis são 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 projetarão e
especificarão 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ê não pretenda trabalhar com um colarinho branco

Página 8 de 584
- isto é, mesmo que você aspire ser um artista, um escritor, um músico ou um atleta - você deve
saber o que significa a análise de sistemas. As pessoas em todos os setores da vida são afetadas
pelos sistemas de informações de todos os tipos. Ainda que você não pretenda construir um sistema
nem mandar construir um, é inevitável que você os utilize em suas contas bancárias, na sua
educação, em suas relações com a Pre vidência Social e em praticamente todos os aspectos de suas
relações com a sociedade moderna. Como John Gall diz em Systemant [ 1977],
Ninguém, atualmente, pode evitar o contato com os sistemas. Os sistemas estão em toda parte:
sistemas grandes, sistemas pequenos, sistemas mecânicos e eletrônicos, e os sistemas especiais
compostos por associações organizadas de pessoas. Como auto-defesa, pre cisamos aprender a
conviver com os sistemas, a controlá-los para que não nos controlem. Como disse Humpty Dumpty
a Alice (em bora em outro contexto): “A questão é: quem dominará - isso é tudo”.
3
Para enfatizar ainda mais este ponto, lembre-se de que a indústria da computação 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 têm um ou mais
computadores envolvidos em sua produção, e quase todos os serviços oferecidos pelo mercado de
negócios americano estão baseados ou controlados por um sistema de computação.
1.3 OQUE ESTE LWRO FARÁ POR vocÊ
Como você já deve ter percebido, um dos maiores objetivos deste livro é ensinar-lhe análise de
sistemas: o que ela é e como se lida com ela. Mas não é só isso, O meu verdadeiro propósito é
entusiasmá-lo, torná-lo tão interessado em começar a praticar análise de sistemas que você vai
querer disparar pelas últimas páginas do livro e começar a trabalhar em seu primeiro projeto.
Seymour Papert comenta em Mmd storms [ 1980],
Agradam-me especialmente sistemas, como um mecanismo diferen cial, que não obedecem a uma
seqüência linear de causalidades, uma vez que o movimento do eixo de transmissão pode ser dis
tribuído de várias maneiras diferentes para as duas rodas, depen dendo da resistência encontrada.
Lembro, de forma vivida, minha excitação em descobrir que um sistema pode estar sujeito a leis e
ser inteiramente compreensível sem ser rigidamente determinístico.
E como Sir Arthur Stanley Eddington disse em [ 1987],
Descobrimos que onde a ciência 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 após a outra, para explicar sua origem. Por fim, obtivemos sucesso na reconstrução da criatura
autora da pegada. E, surpresa! Ela era nossa.
Outro propósito deste livro é fazê-lo compreender e considerar que vivemos em um mundo de
sistemas - e de sistemas dentro de outros sistemas, que são 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” não é vital apenas para analistas profissionais de sistemas, mas para todos os
membros da sociedade moderna.

Página 9 de 584
4
Infelizmente, este livro não pode transformá-lo em um experiente analista de sistemas, do mesmo
modo que um livro sobre teoria musical não pode torná-lo um pianista experiente. No final do
livro, você disporá de bons conhecimentos técnicos que o auxiliarão a desenvolver modelos
corretos de sistemas complexos, e você se tornará conhecedor das técni cas passo a passo para
executar o esforço da análise de sistemas. Mas ainda será necessário um grande volume de trabalho
no mundo real para conhecer as aptidões das pessoas: como entrevistar usuários de diversos tipos
para compreender a verdadeira essência de um sistema; como apresentar os resultados do seu
trabalho de análise 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 clássica obra, Software Engineering Econo mics [ 1981]:
Cada um de nós, como engenheiros individuais de software, tem uma oportunidade de fazer um
significante impacto positivo na so ciedade, simplesmente por nos tornarmos mais sensíveis às
impli cações das relações humanas de longo alcance de nosso trabalho, e por incorporarmos essa
sensibilidade em nossos projetos e produtos de software.
É necessária uma certa prática para fazer bem isso, e para aprender
a equilibrar os aspectos das relações humanas com os da pro gramação e com os aspectos
econômicos. O ponto principal a ser
lembrado é conservar nossas prioridades firmes entre as conside rações da programação,
orçamentárias e humanas.
1.4 A ORGANIZAÇÃO DESTE LIVRO
Este livro está organizado em quatro partes principais, seguidas por uma série de apêndices. A
parte 1 serve como apresentação para todo o livro; ela começa, no capítulo 2, com uma introdução
sobre o conceito de sistemas e sobre a natureza da análise de sistemas; nesse capítulo, veremos que
os sistemas de informação são normalmente compostos por pessoas, hardware, software
(programas de computador), procedimen tos, dados e informações. O capítulo 3 descreve as
pessoas que costu mam estar envolvidas no desenvolvimento de um moderno sistema de
informações - usuários, gerentes, pessoal das operações, membros do grupo de controle da
qualidade, entre Outros - bem como o papel es pecial e as responsabilidades do analista de
sistemas. O capítulo 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 transições de estado.
O capítulo 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 capítulos da parte 1 devem
ser udos, porque dão o tom para o restante do livro. O capítulo 2, por exemplo, apresenta e analisa
os axio mas e princípios básicos que podemos encontrar em todo o trabalho da análise de sistemas:
o desenvolvimento de modelos de sistemas, a noção de iteração, e a noção da subdivisão top-down.
O capítulo 6 delineia os principais problemas que se apresentam aos analistas de sistemas
atualmente: produtividade, qualidade dos sistemas, manutenibilidade e o uso estratégico das
informações. Por fim, o capítulo 7 resume as prin cipais modificações ocorridas na área da análise

Página 10 de 584
dc sistemas nos últimos dez anos.
A parte II discute detalhadamente as ferramentas de modelagem de sistemas. Há capítulos sobre
diagramas de fluxo de dados (capítulo 9), dicionários de dados (capítulo 10), especificações de
processos (capítulo 11), diagramas de entidades-relacionamentos (capítulo 12) e diagramas de
transições de estado (capítulo 13). Os capítulos 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 focalização scletiva em aspec tos isolados de um sistema cujas características sejam
importantes. para serem compreendidas: as funções 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ê faça. Você descobrirá que essas ferramentas
podem ser úteis para modelar (ou descrever) virtualmente qualquer tipo de sistema:
sistemas biológicos comerciais, ecossistemas, industriais, políticos, de fluxo de materiais etc.
Vivemos em um mundo de sistemas, e boa parte de nossa vida é passada tentando entender e lidar
com os inúmeros sistemas diferentes; as ferramentas de modelagem são extremamente úteis nesse
aspecto.
A parte III refere-se ao processo da análise de sistemas - isto é, as etapas seguidas pelo analista de
sistemas na construção de um modelo de sistema. Ali, também, as informações que você receber
serão úteis, independentemente da sua profissão; mas o conteúdo é definitivamente dirigido para a
constmç de sistemas automatizados de informações. Veremos que o processo ou metodologia da
construção de um sistema envolve o desenvolvimento de vários tipos diferentes de modelos, dos
quais o último é o produto ou a saíc da análise de sistemas. Em muitas organizações comerciais,
esse produto é conhecido por nomes como
6
“especificação funcional”, ou “definição de requisitos do sistema” ou “projeto do sistema”.
Qualquer que seja o nome adotado, ele se torna a entrada para o responsável pela construção real
do sistema - isto é, pelo projeto da arquitetura geral do hardware e software e, em última análise,
pela escrita e pelos testes dos programas do sistema.
Isso conduz à parte IV: o que ocorre depois da análise de sistemas. Examinaremos a transição da
análise de sistemas para o projeto de siste mas e discutiremos resumidamente os detalhes finais da
programação e dos testes. Como a maioria dos sistemas automatizados de informações tem um
tempo de vida de alguns anos (e muitas vezes de algumas décadas), estudaremos também a
manutenção no capítulo 24; porém nosso interesse não será a programação de manutenção, e, sim,
a manu tenção do produto da análise de sistemas. O capítulo final trata do futu ro: as alterações
evolutivas na área da análise de sistemas que esperamos presenciar nos anos 90 e no próximo
século.
Os apêndices no final do livro abordam problemas que podem ou não afetar seu trabalho como
analista de sistemas. O apêndice A, por exemplo, trata do problema de estações automatizadas de
trabalho baseadas em PC para a análise de sistemas - ao qual poucos analistas de sistemas têm
acesso no final dos anos 80, mas que se tornará progres sivamente comum nos anos 90. O apêndice

Página 11 de 584
B discute fórmulas de avalia ção e métricas utilizadas para calcular o tamanho, a duração e o custo
de um projeto. O apêndice C mostra os aspectos econômicos dos cálculos de custo-beneficio. O
apêndice D abrange o assunto dos caminhamentos (walkthroughs) e inspeções, que são utilizadas
freqüentemente na revi são dos produtos técnicos da análise de sistemas. O apêndice E discute as
técnicas de entrevistas e de coleta de dados, principalmente as entre vistas do usuário com o
analista de sistemas. Todos esses assuntos foram organizados em apêndices de modo a que os
analistas experientes pos sam saltá-los com facilidade e os principiantes possam recorrer a eles
sempre que for necessário consultar tópicos que, com certeza, emergirão durante os projetos do
mundo real.
Os apêndices 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 recém-apren didos princípios
podem ser aplicados a situações do mundo real. Na realidade, você deve ler a introdução e o
histórico de cada estudo de caso para se familiarizar com a natureza de cada aplicação. Cada
capítulo tem algumas perguntas e exercícios para ajudá-lo a rever o que foi estu dado. Alguns
exercícios são rotulados como “Projeto de Pesquisa”, o que significa que apresentam problemas
não mencionados diretamente no capítulo mas que são relevantes no mundo real da análise de
sistemas. Certas perguntas são dirigidas para discussão em sala de aula; não há
7
respostas certas ou erradas, embora haja respostas mais defensáveis que outras!
Chega de introduções. Vamos dar a partida! Começaremos falando
a respeito da natureza dos sistemas.
REFERÊNCIAS
1. Tom DeMarco, Structured Analysis and Systems Speqfzcation. Englewood Cliffs, N.J.: Prentice-
Hall, 1979, página 6.
2. John Gal!, Systemantícs. Nova lorque: Quadrangle/The New York Times Book Company, 1977,
página 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 EXERCÍCIOS
1. Explique como a análise de sistemas pode ser útil em seu trabalho ou profissão mesmo que você
não pretenda se tornar um pro gramador ou analista de sistemas.
2. Projeto de Pesquisa: quantas pessoas, atualmente, estão emprega das como analistas de sistemas
no Brasil? Qual é .0 salário médio

Página 12 de 584
dessas pessoas? Qual é o nível médio de educação delas?
3. Projeto de Pesquisa: existe uma carência de programadores e analistas de sistemas no Brasil?
Tente encontrar pesquisas que indiquem as necessidades desses profissionais para o país para os
próximos dez anos.
4. Dê dez exemplos de sistemas com que você lida ou interage em seu dia a dia.
5. Você estudaria análise de sistemas no caso de ainda não o ter feito? Se a sua resposta for “não”,
explique porque o assunto não será útil ou relevante. Encontre alguém que esteja estudando esse
mesmo assunto e inicie um debate construtivo a respeito da utilidade geral da análise de sistemas.
6. Você considera ser importante para as pessoas fora da área da computação (pessoas que não
trabalham na área da computa ção como profissão) estudarem análise de sistemas? Quão
8
respostas certas ou erradas, embora haja respostas mais defensáveis que outras!
Chega de introduções. Vamos dar a partida! Começaremos falando
a respeito da natureza dos sistemas.
REFERÊNCIAS
1. Tom DeMarco, Structured Analysis and Systems Spe Englewood Cliffs, N.J.: Prentice-Hall,
1979, página 6.
2. John GalI, Systemantics. Nova lorque: Quadrangle/The New York Times Book Company, 1977,
página xiii.
3. Barry Boehm, Software Engineeríng 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.
1. Explique como a análise de sistemas pode ser útil em seu trabalho ou profissão mesmo que você
não pretenda se tornar um pro gramador ou analista de sistemas.
2. Projeto de Pesquisa: quantas pessoas, atualmente, estão emprega das como analistas de sistemas
no Brasil? Qual é ,o salário médio
dessas pessoas? Qual é o nível médio de educação delas?
3. Projeto de Pesquisa: existe uma carência de programadores e analistas de sistemas no Brasil?
Tente encontrar pesquisas que indiquem as necessidades desses profissionais para o país para os
próximos dez anos.
4. Dê dez exemplos de sistemas com que você lida ou interage em seu dia a dia.
5. Você estudaria análise de sistemas no caso de ainda não o ter feito? Se a sua resposta for «não”,

Página 13 de 584
explique porque o assunto não será útil ou relevante. Encontre alguém que esteja estudando esse
mesmo assunto e inicie um debate construtivo a respeito da utilidade geral da análise de sistemas.
6. Você considera ser importante para as pessoas fora da área da computação (pessoas que não
trabalham na área da computa ção como profissão) estudarem análise de sistemas? Quão
8
1
conhecedoras do assunto você acha que elas seriam?
7. Por que a análise de sistemas parece ser mais interessante que a
programação? Você concorda com este ponto de vista?
8. O que um analista de sistemas deve aprender além do conheci
mento técnico de construir modelos de sistemas?
9. Por que as ferramentas de modelagem do tipo apresentado neste
livro podem ser úteis no estudo de sistemas não-computacionais?
NOTAS
Se você tem menos de 30 anos de iiade, e difícil imaginar que nunca escreveu um programa de
computador, pois quase todas as escolas e colégios agora ensinam alguma coisa a respeito de
programação de computadores. Porém, é possível que você não tenha escrito um programa
realmente complicado. Se você não levou pelo menos um mês trabalhando no mesmo programa -
16 horas por dia, sonhando com ele nas 8 horas restantes de sono intranqüilo, passando várias
noites em claro, tentando eliminar aquele ‘último erro” do programa - então você ainda não
escreveu realmente um programa complicado. E pode não ter a sensação de que existe algo
divertido em programar (a propósito, todos na indústria lhe dirão que não se deve construir
programas grandes e complexos - e que o objetivo do jogo é construir
programas simples e compreensíveis. Isto é verdade: mas imagine
a energia mental e as noites insones gastas na criação e no desen
volvimento de algo como o programa MacPaint da Macintosh, ou a
primeira versão do Lotus 1-2-3).
2 Existem diversas outras carreiras que podem ser seguidas. Você
pode se especializar na área de telecomunicações e projeto de
redes; ou pode concentrar-se no projeto de bancos de dados ou
“administração de dados”. Embora a maior parte deste livro
presuma que você se ocupe com sistemas aplicativos (folhas de
pagamento, inventários, contabilidade ou aplicações de tempo-
real, como orientação de mísseis, comutação telefônica e controle
de processos), você pode ocupar-se também, com projetos de
programação de sistemas - compiladores ou sistemas opera

Página 14 de 584
cionais, por exemplo. Tudo isso possivelmente representa seu
segundo ou terceiro emprego na indústria da computação: você
deve, provavelmente, começar como programador júnior (quando
se espera que você saiba escrever programas relativamente
simples, ou fazer modifIcações em programas já existentes), depois
passar a programador sênior, antes dc, finalmente, ascender à
posição de analista de sistemas. Nessa posição, você deverá ter
9
maiores habilitações que um programador: além do conhecimcni
do hardware e do software do computador, você deve ser capaz de
se comunicar com pessoas leigas em computação e estar familia
rizado com as aplicações comerciais dessas pessoas.
3 Para maiores detalhes sobre esse assunto e para mais explicações
sobre o impacto dos computadores na sociedade, veja Nations at
Risk EYourdon, 19861.
10
2
A NATUREZA
DOS SISTEMAS
Finalmente colocaremos o próprio Sol no centro do Universo. Tudo isso é sugerido pela sequáncia
sistemática de eventos e pela harmonia de todo o Universo, se encararmos os fatos, como se
costuma dizer, ‘com os olhos abertos
Nicolau Copérnico
De Revolutionibus Orbium Coelestium, 1543
1. O que é definição de um sistema.
2. A diferença entre sistemas naturais e sistemas feitos pelo homem.
3. Os 19 principais subsistemas encontrados em todos os sistemas vivos.
4. As cinco principais razões por que alguns sistemas não devem ser automatizados.
5. Os cinco principais componentes de um sistema au tomatizado de informações típico.
6. A definição e as características de diversos tipos es pecíficos de sistemas.
7. A definição e três exemplos de princípios gerais de sistemas.
Não podemos falar muito sobre análise de sistemas enquanto não
tivermos uma clara idéia do que seja um sistema; este é o propósito des te capítulo. Como veremos,
existe uma definição “oficial” do termo no

Página 15 de 584
11
dicionário, que parecerá bastante abstrata. Existem, porém, muitos usos comuns do termo que lhe
parecerão 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
espécies 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 organização comercial geral (que constitui um sistema), que
é, por sua vez, componente de um sistema econômico geral, e assim por diante. Ou você pode estar
trabalhando cm um siste ma de controle de processos que é parte de uma refinaria química, ou em
um sistema operacional que seja parte de um “pacote” de software de sistemas distribuído 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 são substi tuições ou novas implementaçôes
de sistemas não-computadorizados que já existem; além disso, a maioria dos sistemas
computadorizados interage ou tem uma interface com vários sistemas existentes (alguns podem ser
computadorizados e outros não). Para que nosso sistema computadorizado seja bem-sucedido,
precisamos conhecer, detalhadamente, como o sistema atual se comporta.
Em segundo lugar, embora muitos tipos de sistemas pareçam ser totalmente diferentes, eles têm
muitas semelhanças; existem princípios 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 experiên cia diária, bem como na
experiência de cientistas e engenheiros em diversas áreas - aos sistemas que elaboramos na área da
computação. Por exemplo, um dos importantes princípios de sistemas que primeiro foi obser vado
no campo da biologia é conhecido como a lei da especia lização; quanto mais adaptado for um
organismo a um determinado ambiente, mais dificil será para esse organismo a adaptação a outro.
Isso ajuda a explicar o desaparecimento dos dinossauros quando o clima da Terra modificou-se
radicalmente ajuda, também, aos analistas de siste mas a compreenderem que se otimizarem um
sistema computadori zado de forma a tirar a máxima vantagem dc uma determinada UCP, de uma
linguagem de programação e de um sistema de gerenciamento de banco de dados, poderão vir a ter
sérios 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 informações. Isso é cada
dia mais impor tante, pois queremos construir sistemas estáveis e confiáveis, que funcionarão bem
em nossa complexa sociedade - e há, naturalmente, muitos sistemas não-computadorizados que
vêm sobrevivendo por mi lhões de anos: a humilde barata provavelmente sobreviverá a iodos os
sistemas computadorizados já construídos ou a construir, e a toda a humanidade, também.

Página 16 de 584
Assim, vamos começar com uma definição do termo básico siste ma. Todos os livros sobre algum
aspecto de sistemas contêm essa defi nição; eu escolhi o Webster’s New Coilegiate Dictionary . Ele
a várias definições:
1. um grupo de itens que interagem entre si ou que sejam inter dependentes, formando um todo
unificado < - numérico>
como
a. (1) um grupo de corpos que interagem entre si sob a in fluência de forças relacionadas < -
gravitacional >
(2) uma mistura de substâncias em equilíbrio ou que tende para o equilíbrio < - termodinâmico >
b. (1) um grupo de órgãos do corpo que desempenham, em conjunto, uma ou mais funções vitais <
o - digestivo>
(2) o corpo, considerado como uma unidade funcional.
c. um grupo de objetos ou forças naturais relacionados entre si <um - fluvial>
d. um grupo de dispositivos ou uma organização em rede, principalmente para a distribuição de
algum produto ou servindo a um propósito comum <um - telefônico > <um
- de aquecimento > < um - rodoviário > < um - de processamento de dados>
2. um conjunto organizado dc doutrinas, idéias ou princípios, habitualmente previsto para explicar
a organização ou o fun cionamento de um conjunto sistemático < o - da mecânica newtoniana >
3. a. um procedimento organizado ou estabelecido < o - de toques da digitação>
13
b. uma maneira de classificar, simbolizar ou esquematizar < um - taxonômico > < o - decimal>
4. organização harmoniosa ou modelo: ORDEM
5. sociedade organizada ou situação social vista como inde sejável: “ESTABLISHMENT”
2.1 TIPOS COMUNS DE SISTEMAS
Como se pode depreender da definição acima, existem muitos tipos 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 biológicos e sistemas de computação? Claro que não! Entretanto, é
conveniente organizar os diferentes tipos de sistemas cm categorias. Muitos agru pamentos
diferentes são possíveis; na realidade, a definição do dicio nário no início deste capítulo apresenta
uma classificação em categorias. Como nosso interesse principal são os sistemas de
processamento, vamos começar por dividir todos os sistemas em duas categorias: siste mas naturais
e sistemas feitos pelo homen
2.2 SISTEMAS NATURAIS
A maioria dos sistemas não é feita por pessoas. Eles são encontra dos na natureza e, de modo geral,
servem a seus próprios propósitos. É conveniente dividir esses sistemas em duas suhcatcgorias
básicas: siste mas fisicos e sistemas vivos. Os sistemas físicos incluem exemplos tão diferentes

Página 17 de 584
como:
• Sistemas estelares: galáxias, sistemas solares etc.
• Sistemas geológicos: rios, cadeias de montanhas etc.
• Sistemas moleculares: organizações complexas de átomos.
Os sistemas físicos são interessantes de serem estudados porque, como humanos intrometidos que
somos, por vezes tentamos modificá los. Desenvolvemos, também, diversos sistemas, incluindo-se
aí os siste mas em computadores, que devem interagir harmoniosamente com os
14
sistemas físicos; dessa forma é importante estarmos capacitados a mode lar esses sistemas para nos
assegurarmos que os entendemos tão bem quanto possível.
Os sistemas vivos, naturalmente, abrangem as miríades de animais e plantas em volta de nós e
também a espécie humana. E, como afirma James Miller em sua monumental obra, Living Systems
[ 1978], essa categoria também inclui hierarquias de organismos vivos individuais, como ervas,
rebanhos, tribos, grupos sociais, empresas e nações.
O estudo dos sistemas vivos já é uma carreira por si próprio; uma rápida leitura da obra de Miller
permite que se perceba a extensão desse tema. O propósito deste livro não é o estudo dos sistemas
vivos per se; não obstante, algumas das propriedades e características 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 eloqüentes exemplos de sistemas vivos empregados como analogias para sistemas
comerciais e organizacionais estão 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 nível de célula, de
órgão, de organismo, de grupo, de organização, de sociedade ou de sistemas inter nacionais,
contêm, todos, os seguintes subsistemas:
• O reprodutor, que é capaz de dar origem a outros sistemas se melhantes ao que ele pertence. Em
uma organização comercial, pode ser a divisão de planejamento, que faz novas plantas e constrói
novos escritórios regionais.
• O delímitador que mantém coesos os componentes do sistema, que os protege dos problemas
ambientais e que impede ou permite a entrada de vários tipos de matéria-energia e infor mações.
Em uma organização comercial, poderia consistir nas instalações físicas (prédio do escritório,
fábrica etc.) e dos guar das e outros elementos da segurança que impedem intrusões não desejadas.
• O ingestor, que introduz matéria-energia através dos limites do sistema a partir do seu ambiente.
Em uma organização comer cial, pode ser representado pelo departamento de recebimentos ou de
compras, que traz produtos in natura, material de escritório e coisas afins. Pode ser constituído
também pelo de partamento de entrada de pedidos, que recebe pedidos verbais e escritos para os
produtos e serviços da empresa.
15
• O distribuidor, que transporta entradas de fora do sistema ou saídas dos subsistemas em torno do

Página 18 de 584
sistema para cada compo nente. Em uma organização comercial, podem ser as linhas telefônicas, o
correio eletrônico, os mensageiros, correias transportadoras e vários 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
organi7ação comercial típica.
• O produtor, que forma associações estáveis que garantem, du rante significativos períodos entre
entradas de matéria-energia no sistema ou entre as saídas do conversor, o material sinteti zado para
crescimento, reparo dos danos ou substituição dos componentes do sistema, ou destinado ao
fornecimento de energia para movimentar ou compor as saídas de produtos ou informações de
mercado para seu sistema de nível superior.
• O subsistema de ar de matéria-enei que con serva no sistema, por diferentes períodos de tempo,
depósitos
de vários tipos de matéria-energia.
• O extravasor, que envia matéria-energia para fora do sistema sob a forma de produtos ou
resíduos.
• O moaor, que move o sistema ou setores dele em relação a uma parte do ambiente ou todo ele ou
move componentes relativa mente um ao outro.
• O suportador, que mantém 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 ferências físicas.
• O tran.sdutor de entrada, que traz marcadores com informações para o sistema, modificando-os
para outras formas de matéria-
energia adequadas para transmissão em seu interior.
• O transdutor Interno, que recebe, de outros subsistemas ou componentes do sistema, marcadores
com informações sobre al terações importantes nesses subsistemas ou componentes, modificando-
os para outras formas de matéria-energia que pos sam ser transmitidas em seu interior.
16
• O canal e a rede, que se compõem de uma única via no espaço físico, ou de múltiplas vias
interligadas, pelas quais os marca dores com informações são transmitidos para todas as partes do
sistema.
• O decod que modifica o código da entrada de informa ções para ele, por intermédio do transdutor
de entrada ou do transdutor interno, em um código privativo que pode ser utili zado internamente
pelo sistema.
• O associador, que executa o primeiro estágio do processo de aprendizado, formando associações
duráveis entre os itens de
informação do sistema.
• A memória, que executa o segundo estágio do processo de aprendizado, armazenando diversos
tipos de informações no
sistema por diferentes períodos de tempo.

Página 19 de 584
• O decididor, que recebe entradas de informações de todos os outros subsistemas e lhes transmite
saídas de informações que
controlam todo o sistema.
• O cod que modifica o código das entradas de informa ções para ele a partir de outros subsistemas
de processamento de informações, de um código privativo de utilização interna do sistema para um
código que possa ser interpretado por outros sistemas do ambiente.
• O transdutor de saída, que extrai do sistema marcadores com informações, modificando esses
marcadores dentro do sistema em outras formas de matéria-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
comunicações de um moderno vapor; as figu ras 2.2 (a) e 2.2 (b) apresentam os principais
subsistemas do próprio navio e as figuras 2.3 (a) e 2.3 (b) mostram os principais subsistemas de
toda a Holanda. Esses modelos são válidos 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 coração
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 orgânicos) 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 são, 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 definição no início deste capítulo, alguns siste mas são construídos, organizados
e mantidos por seres humanos. Entre
eles podemos considerar:
• Sistemas sociais: organizações de leis, doutrinas, costumes etc.
• Uma coleção organizada e disciplinada de idéias: o sistema deci mal Dewey para a organização
de livros em bibliotecas, o sis tema Weight-Watcher para perda dc peso etc.
• Os sistemas de transporte: redes rodoviárias, canais, linhas aéreas, petroleiros, e semelhantes.
• Sistemas de comunicações: telefone, telex, sinais de fumaça, si nais manuais utilizados pelos
comerciantes atacadistas etc.
• Sistemas de manufatura: fábricas, linhas de montagem etc.
• Sistemas financeiros: contabilidade, inventários, livros-razão, controle de estoques, entre outros.
Hoje, a maioria desses sistemas usa computadores; na verdade, muitos deles não poderiam
sobreviver sem os computadores. Contudo, também é importante ressaltar que esses sistemas já
existiam antes que surgissem os computadores; alguns deles, na realidade, não estão ainda
totalmente computadorizados e podem permanecer assim por muitas décadas mais. Outros contêm

Página 20 de 584
um computador como componente, mas contêm também um ou mais componentes não-
computadorizados (ou manuais).
Considere, por exemplo, a frase “João possui um sistema que faz esse serviço” ou “Maria
certamente tem um modo sistemático de fa zer seu trabalho”. Tais frases não implicam
necessariamente em que Maria tenha computadorizado seu trabalho ou que João tenha utilizado
18
algumas das ferramentas formais de modelagem discutidas nos capítulos 9 e 10 para documentar
(ou modelar) a maneira como ele pretende executar sua tarefa. Essas frases, no entanto, certamente
implicam em que João e Maria dividiram o serviço em uma série de etapas separadas, cuja
combinação cumpre algum propósito geral.
A questão de se um sistema feito pelo homem deve ou não ser computadorizado será discutida
através de todo este livro; l não é algo que deva ser tomado por certo. Como analista de sistemas,
você naturalmente pressupõe que todo sistema com que você tiver contato deverá ser
computadorizado; e o cliente ou usuário (o dono do sistema em questão) com quem você interagir
imaginará geralmente que você tenha tal intenção. Como veremos nos próximos capítulos, sua
principal tarefa como analista de sistemas será analisar ou estudar o sistema para determinar-lhe a
essência: seu comportamento exigido independente mente da tecnologia utilizada em sua
implementação ‘. Na maioria dos casos, só estaremos em situação de decidir se faz sentido usar um
com putador para executar as funções do sistema depois de modelarmos seu comportamento
básico.
Por que alguns sistemas de informação não devem ser automati zados? Pode haver muitas razões,
mas aqui estão algumas das mais
comuns:
• Custo pode ser mais barato continuar executando as funções do sistema e armazenando as
informações manualmente. Nem sempre é verdade que os computadores sejam mais rápidos e mais
baratos do que o modo “antigo”.
• Conforto - um sistema automatizado pode ocupar espaço em demasia, fazer excessivo ruído,
gerar muito calor ou consumir eletricidade demais ou, em termos gerais, a presença de um deles
pode ser uma dor de cabeça. Isso está se tornando menos verdadeiro com a penetrante influência
dos microprocessadores mas ainda é um fator a considerar.
• Segurança - se o sistema de informações mantém dados im portantes e confidenciais, o usuário
pode achar que um sistema automatizado não seja suficientemente seguro, podendo preferir manter
a capacidade de conservar as informações fisicamente protegidas debaixo de chave.
• Manutenibilidade - o usuário pode argumentar que um sis tema computadorizado de informações
poderia ser econômi co, só que não há ninguém na organização que possa manter o hardware e/ou
o software do computador, de forma que
19
ninguém estaria capacitado a reparar o sistema no caso de um defeito e não haveria quem pudesse
efetuar modificações e melhoramentos.
• PolUica - a comunidade de usuários pode achar que os com putadores são uma ameaça a seus

Página 21 de 584
empregos ou que tornam seu trabalho tedioso e «mecânico”, ou podem ter uma dúzia de outras
razões que o analista de sistemas pode considerar como irracionais. Mas como o sistema pertence
aos usuários, a opinião deles está acima de tudo. Se eles não desejarem um sistema automatizado,
farão o que for possível 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 são 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 estão computadorizados.
Como resultado, podemos distinguir muitos tipos diferentes de sistemas automatizados.
Embora haja muitos tipos diferentes de sistemas automatizados,
todos têm componentes comuns:
• Hardware de computadores - UCP, terminais, impressoras, uni dades de fitas magnéticas etc.
• Software de computadores - programas de sistemas, como sis temas operacionais, sistemas de
bancos de dados e programas de controle de telecomunicacões, além dos programas aplicati vos
que executam as funções desejadas pelo usuário.
• Pessoas - aquelas que operam o sistema, que fornecem as en tradas e utilizam as saídas, e as que
desempenham atividades de
processamento manual em um sistema.
• Dados - as informações que o sistema conserva por um período de tempo.
• Procedimentos - determinações e instruções formais para a operação do sistema.
20
Subsistemas que processam matéria-energia e informações: Delimitador (Dl), parede da estação-
rádio (objeto).
Subsistemas que processam matéria-energia: Ingestor (IN), garçonete que leva alimentos da
cozinha para a estação-rádio; Distribuidor (DI), garçom que entrega alimentos aos membros da
equipe de comunicações; Conversor (CO), garçom que corta pão, carne e queijo para sanduíches;
Produtor (PIO, garçom que prepara sanduíches e café; Armazenamento de Matéria-Energia (AM),
garçom que armazena diversos tipos de material, inclusive comida no refrigerador, casacos e
chapéus dos membros da equipe no armário, cobertores e travesseiros também no armário e
ferramentas e equipamentos na cômoda; Extravasor (EX), garçom que retira pratos sujos, papéis
usados e outros materiais inúteis da estação-rádio; Suportador (SU), chão, paredes, teto e mobília
da estação-rádio (objetos).
Subsistemas que processam informações: Transdutor de Entrada (te), rádio- operador que recebe
mensagens pelo rádio; Transdutor Interno (ti), tripulante de serviço no dia, que apresenta relatórios
ao encarregado das comunicações a respeito da eficiência e do moral dos membros da equipe
durante seu serviço; Canal e Rede (cr), todos os membros do grupo que se intercomunicam ver
balmente através do ar da estação-rádio; Decodificador (dc), rádio-operador que transcreve em
linguagem legível as mensagens recebidas em código morse; Memória (me), secretário que

Página 22 de 584
conserva o registro de todas as mensagens re cebidas e transmitidas; Decididor (de), oficial
encarregado das comunicações, que chefia a equipe de comunicações; Codificador (cO, rádio-
operador que codifica mensagens claras em código morse; Transdutor Externo (tx), rádio- operador
que transmite mensagens pelo rádio.
Figura 2.1(a): Subsistemas da equipe de comunicações de um namo.
Uma maneira de classificar os sistemas automatizados é feita pela aplicação: sistemas industriais,
sistemas de contabilidade, sistemas de defesa militar etc. Entretanto, isso não será muito útil já que
as técnicas que discutiremos neste livro para analisar, modelar, projetar e implemen tar sistemas
automatizados são geralmente as mesmas, qualquer que seja a aplicação .
21
7
i
F1gu 2.1 (b): Subsig de
uma equijie de comunicaçj de um natio
4
00
f
0
to
1
0
22
Subsistemas que processam matéria-energia e informações: Reprodutor (Re), que representa a
organização proprietária; Delimitador (Di), o casco do navio e o pessoal que o guarda e trata de sua
manutenção.
Subsistemas que processam matéria-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, garçons e carrega dores que por eles transportam alimentos, bebidas,
bagagens e vários outros tipos de matéria-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 refeições e padeiros que fazem pão na
cozinha do navio; Armazenamento de Matéria- Energia (AM), porões e tanques de combustível do
navio e o pessoal responsável por eles; Extravasor (EX), chaminé para eliminação de resíduos
gasosos, disposi tivos de descarga de lixo e esgoto para resíduos líquidos e sólidos e o pessoal en
carregado de verificar se esses resíduos estão sendo adequadamente eliminados; Motor (MO),
máquinas, eixo propulsor, hélices e todo o casco do navio, que transportam passageiros, tripulação
e carga pelo mar, bem como os maquinistas responsáveis pela movimentação do navio; Suportador
(SU), casco, bordos, anteparas (paredes) e conveses do navio e o pessoal encarregado da
manutenção desses elementos.

Página 23 de 584
Subsistemas que processam informações: Transdutor de Entrada (te), rádio- operador e outros
membros da equipe de comunicações que recebem men sagens para o navio; Transdutor Interno
(ti), oficial que informa ao oficial mais graduado do serviço sobre o estado de diversos
componentes do navio; Canal e Rede (cr), o ar entre os oficiais de serviço no passadiço do navio,
pelo qual eles transmitem e recebem mensagens; Decodificador (dc), rádio-operador, da equipe de
comunicações, que decodifica mensagens em código Morse para linguagem clara, depois de serem
recebidas; Memória (me), livros de registro de viagens anteriores, cartas náuticas e o pessoal que as
consulta no compartimento de cartas; Decididor (de), o Comandante e outros oficiais do navio;
Codificador (cO, rádio-operador, da equipe de comunicações, que codifica mensagens em lin
guagem clara para o código morse para poder transmiti-las; Transdutor de Saída (is), rádio-
operador e outros membros da equipe de comunicações 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 matéria-energia como informações: Delimita dor , organizações
de defesa, guarda ou policiamento das fronteizas nacionais. Subsistemas que processam matéria-
energia: Ingestor organizações, como empresas de transportes aéreos, ferroviários ou rodoviários
ou empresas de transpor tes marítimos, que importam diversas formas de matéria-energia para o
pais; Distribuidor
organizações nacionais que transportam formas diversas de matéria-energia por água, estradas,
ferrovias ou pelo ar; Conversor r ii organizações que con vertem formas brutas de matéria-energia
em outras formas utiizáveis pela sociedade;
Produtor , organizações industriais que fabricam produtos para a sociedade
ou para exportação; Armazenamento de Matéria-Energia organizações como depósitos,
reservatórios e instalações de energia elétrica que armazenam diferentes formas
de matéria-energia; Extravasor organizações que exportam produtos da Ho
landa para outros países, ou despejam resíduos no mar, e setores que deportam pessoas in
desejáveis; Motor , unidades do ramo de transportes ou construções, forças armadas ou agências
espaciais; Suportador , edifícios públicos e a terra.
Subsistemas que processam informações: Transdutor de Entrada ( organiza ções que recebem
sinais telegráficos, por cabos, telefônicos ou de radar, ou notícias pro venientes do exterior da
Holanda; Transdutor Interno (4) , legislatura representa tiva, membros de partidos ou organizações

Página 24 de 584
de consulta da opinião pública que recebem comunicaçôes e relatórios de todos os pontos da
Holanda; Canal e rede recur sos nacionais de comunicações; Decodificador , setor de assuntos
estrangei ros que decodifica mensagens secretas recebidas das embaixadas da Holanda em todo o
(Continua)
26
mundo; Associador instituições de ensino da língua holandesa; Me
mória ( , biblioteca; Decididor , Rainha e o governo em Haia;
Codificador , secretário 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 divisão mais prática dos sistemas automati zados:
• Sistemas on-line
• Sistemas de tempo-real
• Sistemas de apoio à decisão
• 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 são os que recebem entradas diretamente do local onde ele foi criado. São também
os sistemas em que as saídas, ou os resultados do processamento, são dirigidas diretamente para
onde sejam necessárias.
Isso habitualmente signifIca que a arquitetura de hardware de um
sistema de processamento é semelhante à da figura 2.4.
Uma característica típica de um sistema on-line é o fato de que os dados são introduzidos no
sistema de processamento e dele recebi dos remotamente. Isto é, os usuários do sistema de
processamento inte
-ragem com o computador através de terminais 6 que podem estar
27
localizados a centenas de milhas de distância de outros terminais e do próprio computador.
Outra característica de um sistema on-line é que os dados armaze nados, isto é, os arquivos ou
bancos de dados, são habitualmente organi zados de forma tal que os dados individuais (como um
registro de reser va de passagem aérea 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 décadas de 60 e 70. Nos sistemas de processamento em lotes, as
informações são normalmente recuperadas na modalidade se qüencial, o que significa que o

Página 25 de 584
sistema de processamento lê todos os registros do banco de dados, processando e atualizando os
registros para os quais haja alguma atividade. A diferença entre um Sistema on-line e um sistema
batch é análoga à diferença entre a procura de uma música em um gravador de fita e em um toca-
disco; o primeiro envolve o acesso seqüencial por todas as trilhas, enquanto o outro permite o
acesso “alea tório” a qualquer das trilhas sem que seja necessário ouvir as demais.
Como um sistema on-line interage diretamente com pessoas (isto é, usuários humanos em
terminais), é importante que o analista de sistemas planeje cuidadosamente a interface homem-
máquina . Isso quer dizer que o analista deve ter um meio de modelar todas as mensagens possí
veis que o usuário poderá digitar no terminal e todas as respostas que o sistema pode dar - e todas
as respostas que o usuário pode dar às consultas do computador, e assim por diante. Isso
geralmente é feito mediante a identificação de todos os estados em que o computador e o usuário
podem se encontrar e pela identificação de todas as modifica ções de estado. Um exemplo de um
estado em que poderia se encontrar o computador de um sistema de caixa automático de um b
poderia ser: «O usuário introduziu o cartão de crédito e se identificou, mas ainda não 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 mudança de
estado poderia ser: «Ele tentou introduzir a senha três vezes sem sucesso e agora vou soar o
alarme». Esses estados e modificações de estado são normalmente modelados nos diagramas de
transições de estado, que discutiremos detalhadamente no capítulo 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 tão eficientes quanto possível. Na realidade, é muitas vezes verdade
que os cálculos executados por um sistema on-line sejam relativamente triviais, enquanto que os
dados (principalmente a estrutura e a organização dos dados manudos pelo sistema on-line) são
bastante
28
As informações são 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 capítulo 12 são
de grande importância para o analista e para o projetista de sistemas.
A decisão de se construir um sistema on-line ou não é, no contexto deste livro, uma decisão de
implementação e não algo que deva ser de terminado pelo analista de sistemas mas sim pelos
implementadores do sistema. Contudo, como essa decisão tem evidente impacto sobre o usuário (a
presença ou ausência de terminais de vídeo etc.), trata-se de uma decisão de implementação da qual
os usuários geralmente querem participar. Na verdade ela faz parte do modelo de implementação
do usuário, que veremos no capítulo 21.
2.4.2 Sistemas de Tempo-Real
Os sistemas de tempo-real são por muitos considerados como va riações dos sistemas on-line; na
realidade, muitas pessoas usam esses termos indiferentemente. Entretanto, é importante fazer
distinção entre eles. Usaremos a definição encontrada em IMartin, 19671:
Os dados são organizados de modo a que possam ser recuperados rapidamente

Página 26 de 584
A saída é transmitida para onde for necessário
29
Um sistema de processamento em tempo-real pode ser definido como aquele que controla um
ambiente pelo recebimento de dados, seu processamento e apresentação dos resultados com rapidez
sufi ciente para afetar o ambiente naquele momento.
A expressão, “rapidez suficiente” está, naturalmente, sujeita a muitas interpretações.
Evidentemente existem muitos sistemas on-line:
sistemas bancários, sistemas de reserva de passagens aéreas, 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 é característico dos seguintes tipos de sistemas:
• Sistemas de controle de processos - sistemas de processamento usados para monitorar e controlar
refinarias de pciróleo, proces sos da indústria química, operações de moagem e operações
mecânicas servem como exemplos.
• Sistemas de caixa automático - os “caixas eletrônicos” que muitos de nós usamos para pequenos
depósitos e retiradas em
um banco são exemplos.
• Sistemas de obtenção de dados de alia velocidade - são exem plos os sistemas de processamento
que recebem dados de te lemetria de alta velocidade de satélites em órbita, ou computa dores que
recebem maciças quantidades de dados de ex periências laboratoriais.
• Sistemas de orientação de mísseis - sistemas de processamento que acompanham a trajetória de
um míssil e fazem contínuos
ajustamentos na orientação e ativação dos propulsores do míssil.
• Sistemas de comutação telefônica - sistemas de processamento que monitoram voz e transmissão
de dados entre milhares de chamadas telefônicas, detectando os números discados, con dições de
no-gancho e fora-do-gancho e todas as outras inúmeras condições de uma rede telefônica típica.
• Sistemas de monitora ção de pacientes - sistemas de processa mento que monitoram diversos
«sinais vitais” de pacientes (ex., temperatura e pulso) e administram a medicação ou soam o alarme
se esses sinais vitais se alteram além de certas condições predeterminadas.
30
Além da velocidade existe uma outra característica 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 autôno mo e muitas
vezes hostil. Na verdade, a preocupação principal do analis ta de sistemas de tempo-real é que, se o
computador não responder com suficiente rapidez, o ambiente ficará fora de controle - os dados
que chegarem poderão se perder irremediavelmente, ou um míssil poderá se desviar tanto de sua
trajetória que não se conseguirá recuperá-lo, ou um processo industrial poderá ir pelos ares Em
contraste com isso, um sistema on-line que não reaja com suficiente rapidez nada mais fará do que
tornar seus usuários impacientes e irritados. As pessoas podem ‘explodir” ou “ir pelos ares” em
sentido figurado se tiverem que esperar mais de três segundos por uma resposta de um sistema on-

Página 27 de 584
line, mas não em sentido literal. Isso é mostrado na figura 2.5.
Em virtude de sua preocupação com resposta instantânea à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 serão
examinadas no capítulo 13.
Do ponto de vista da implementação, 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 períodos
razoáveis de tempo.
• Interrupção de uma tarefa de processamento antes de haver ter minado de modo a que outra, de
alta prioridade, possa ser aten dida.
• Comunicações extensivas entre tarefas, principalmente quando muitas das tarefas funcionam em
diferentes aspectos de um
processo geral como um processo de controle industrial.
• Acesso simultâneo a dados de uso comum, tanto na memória principal como na secundária,
exigindo portanto elaborados procedimentos de “hand-shaking” e ‘sinais de trânsito» para as
segurar que esses dados comuns não se corrompam.
• Uso dinâmico e alocação da memória RAM no sistema de pro cessamento, visto não ser
econômico (mesmo nos dias atuais de memórias de baixo preço) ocupar muita memória fixa para
manipular situações de pico de quantidade de dados.
2.4.3 Sistemas de Apoio à Decisão e Sistemas de Planejamento Estratégico
A maioria dos sistemas automatizados de informações construídos nos Estados Unidos nos últimos
30 anos era de sistemas operativos que auxiliam na execução do trabalho diário de uma empresa.
Esses siste mas, também conhecidos como de pmcessamento de ações, 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á estão à beira do desmoronamento.
Em face disso, novos sistemas operativos são conti nuamente construídos nas maiores empresas
por todo o mundo.
Na medida em que os sistemas operativos atuais prosseguem em seu rumo cambaleante, muitas
empresas estão concentrando a atuação em um novo tipo de sistema: o de apoio à decisão.Como o
termo sugere, esses sistemas de processamento não tomam decisões por eles mesmos, mas
auxiliam gerentes e outros profissionais “funcionários do conheci mento” de uma organização a

Página 28 de 584
tomarem decisões inteligentes e bem in formadas sobre vários aspectos da operação. Os sistemas
de apoio à
32
decisão são tipicamente passivos no sentido de que não funcionam de uma forma regular: em vez
disso, são utilizados de forma ad hoc quando isso se faz necessário.
Existem vários exemplos simples de sistemas de apoio à decisão:
programas de planilhas eletrônicas (p.ex., o Lotus 1,2,3, o Multiplan da Microsoft e o Framework
da Ashton-Tate), sistemas de análise estatística, programas de previsões mercadológicas e outros.
Em realidade, uma característica comum dos sistemas de apoio à decisão é a de que eles não só
recuperam e apresentam dados, mas também executam diversas análises matemáticas e estatísticas
sobre os dados; têm também a apti dão, na maioria dos casos, de apresentar as informações sob
várias for mas gráficas (tabelas, diagramas etc.) bem como relatórios convencio nais. A figura 2.6
mostra uma típica planilha financeira que poderia ser utilizada por um gerente para avaliar a
rentabilidade de uma divisão da empresa; a figura 2.7 mostra um gráfico típico, que apresenta as
receitas da divisão comparadas à média da indústria. Observe que, em ambos os casos, a saída
produzida pelo sistema não toma a decisão e, sim, fornece informações relevantes em formato
adequado para que o gerente possa tomar a decisão.
Alguns sistemas de apoio à decisão são úteis para organizar e
mecanizar as normas utilizadas para se chegar a uma decisão comercial.
Projeções de Lucros/Perdas
10
TRIM.
TRIM.
30
TRIM.
TRIM.
TOTAL
Vendas domésticas
Vendas internacionais
Taxa de licença
Receitas diversas
RECEITA TOTAL
400
100
25
10
535

Página 29 de 584
425
150
60
10
645
250
200
50
15
515
375
125
25
10
535
1450
575
160
45
2230
Custodasvendas
Salários
Outros custos
Aluguéis
Telefone
Despesas postais
Viagens
Despesas legais
Depreciaçôes
Despesas diversas
DESPESA TOTAL
123
100
15

Página 30 de 584
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

Página 31 de 584
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 típica
33
Receitas da Widget
12
10
8
Receita em 6 • Receitas da Widget
milhões Média da indústria
81 82 84 85
Ano

Página 32 de 584
Figura 2.7: Um típico gráfico prod uzido por um sistema de apoio à decisão
Um sistema desse tipo é o programa chamado Lightyear (da Lightyear, Inc.), que funciona nos
computadores pessoais compatíveis com o IBM. Ele permite que o usuário (ou múltiplos usuários)
descreva os detalhes de um problema orientado para decisão; um exemplo poderia ser o problema
de decidir onde instalar um novo escritório. Em primeiro lugar, o usuário identifica os critérios que
serão utilizados na tomada de deci são. Para o problema da instalação do escritório, isso poderia
incluir critérios como: «deve ser acessível por transporte público» e “não deve ser instalado em
locais sujeitos a terremotos”. Alguns dos critérios são binários no sentido de que uma falha em
satisfazê-los elimina um candi dato ou causa a automática seleção 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 numéricos dependendo da cidade e do estado
onde se localiza o novo escritório. Os próprios critérios podem ser escalonados relativamente uns
aos outros: um imposto talvez tenha um valor igual a 5 em uma escala de 10 pontos, enquanto as
instalações comerciais convenientes próximas têm um valor de 3. Tendo sido definidos os critérios
para a tomada de decisão, vários 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 mágico nisso. O programa está simplesmente apli cando, de forma mecânica, as
normas de avaliação introduzidas pelo
usuário. Entretanto, a capacidade do sistema é mais do que apenas o
34
Identificar opções alternativas
‘Ir
Estabelecer critérios de avaliação
Escalonar as opções alternativas
conforme critérios
‘4
Selecionar melhor opção
Figura 2.8: O sistema Lightyear de apoio à decisão
cálculo mecânico: ele obriga a usuário a emitir seu critério, o que muitas vezes não é feito. Ele
também oferece um recurso neutro para reunir as opiniões de muitos usuários em situações onde é
importante a obtenção de um consenso. Em um problema emocionalmente sensível como o da
escolha da localização do novo escritório (p.ex.: a instalação das famílias dos que tomarão a
decisão), pode ser muito benéfico não apenas deter minar os critérios de decisão mas também
determinar o escalonamento dos critérios de cada tomador de decisões. Se dois membros da
comissão de instalação do escritório divergirem, deve ficar claro para eles qual é a base da
divergência.
Os sistemas de planejamento estratégico são usados pelos diretores para avaliar e analisar a missão
da empresa. Em vez de oferecer conse lhos sobre uma decisão comercial isolada, esses sistemas
fornecem infor mações mais amplas e mais gerais sobre a situação do mercado, as pre ferências dos
clientes, o comportamento dos competidores etc. Isso habitualmente pertence à área do

Página 33 de 584
Departamento de Planejamento Estra tégico ou do Departamento de Planejamento a Longo Prazo,
embora essa possa ser uma atividade informal desempenhada por um ou dois diretores de alto
nível.
Planejamento estratégico é 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
estratégico não são intrinsecamente programas de com putador, mas uma complexa combinação de
atividades e procedimentos, muitos deles executados por pessoas utilizando informações
‘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 à decisão. Steiner afirma que podem existir muitos tipos de
sistemas de planejamento estratégico, dependendo do tamanho e da natureza da organização.
Dois modelos típicos são retratados nas figuras 2.9 e 2.10. O siste ma de planejamento estratégico
fundamentado na análise de intervalos tenta identificar a discrepância entre a posição atual da
empresa (em termos de receita, lucros etc.) e a posição desejada pela direção, acionis tas e outros.
Os sistemas de planejamento estratégico constituem outro tema e
não trataremos deles detalhadamente neste livro. Nossa ênfase será prin cipalmente sobre os
sistemas operativos e de apoio à decisão.
Observe o relacionamento entre os três diferentes tipos de sistemas examinados nesta seção. Como
mostra a figura 2.11, os sistemas operau vos representam a base sobre a qual se fundamentam os
sistemas de apoio à decisão e os de planejamento estratégico. Os sistemas operativos criam os
dados exigidos pelos sistemas de nível mais elevado, e atua lizam continuamente esses dados.
A forma piramidal da figura 2.11 representa outra característica dos
sistemas de informações encontrados na maioria das organizações atuais:
o tamanho dos sistemas operativos (medido em pessoas-ano, ou milhões
Figura 2.9: Um modelo de planeja rnento esiral4gico centralizado na análise de intervalos
36
Figura 2.10: Um modelo de planejamento estratégico baseado na força do mercado.
de comandos COBOL etc.) excede ao dos sistemas de apoio à decisão e ao dos sistemas de
planejamento estratégico. Mas podemos esperar uma mudança nesse aspecto na próxima década.
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 à decisão e de planejamento estratégico.
37
Figura 2.11: A hierarquia dos sistemas de processa mento de informação

Página 34 de 584
2.4.4 Sistemas Baseados no Conhecimento
Uma expressão relativamente nova na indústria do processamento é “sistemas especialistas” ou
“sistemas baseados no conhecimento”. Es ses sistemas estão associadQs ao campo da inteligência
artificial, assim definida por Elaine Rich [ 19841:
A meta dos cientistas da computação que trabalham no campo da inteligência artificial é a
produção 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á próxima de ser atingida.
Nos demais casos, apesar de ainda não sabermos como construir programas que funcionem bem
por eles mesmos, emos começar a elaborar programas que auxiliem as pessoas de forma
significativa, na execução de suas tarefas.
Os sistemas baseados no conhecimento e os sistemas especialistas foram descritos por dois
eminentes escritores do campo da inteligência artificial, Feigenbaum e McCorduck em [ e
McCorduck, 19831 da seguinte maneira:
Os sistemas baseados no conhecimento, como é óbvio, contêm grande quantidade de
conhecimentos variados que eles trazem para utilização em determinada tarefa. Os sistemas
especialistas são uma espécie 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 permitirão fun cionar como especialista. Desempenho especialista significa, por
exemplo, o nível de desempenho de um médico em diagnose e terapêutica, ou de doutores ou
pessoas de grande experiência em exercer tarefas de engenharia, científicas ou administrativas. O
sis tema especialista é um auxilio intelectual de alto nível para o espe cialista humano, o que
explica seu outro nome, o de assistente inteligente.
Os sistemas especialistas são construídos habitualmente para terem a capacidade de explicar as
linhas de raciocínio que conduzem a suas decisôes. Alguns podem até mesmo explicar porque
rejeitaram cer tas linhas de raciocínio e escolheram outras. Essa transparência é uma das principais
características dos sistemas especialistas. Os pro jetistas fazem todo o esforço para conseguir isso
porque sabem que a utilização de um sistema especialista depende de sua credibilidade junto aos
usuários, e a credibilidade surge pelo fato de seu compor tamento ser transparente, explicativo.
Os sistemas especialistas ainda são imaginados como sistemas es pecializados, usando hardware
especial .e linguagens de programação também especiais, como LISP e PROLOG. Entretanto,
alguns sistemas especialistas simples começam a surgir em computadores pessoais de porte padrão,
e as cápsulas (‘shelis”) de sistemas especialistas - estrutu ras de software para o desenvolvimento
de aplicações específicas 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 “típico” em que você trabalha
como analista de sistemas. Desde o final dos anos 80 os pesquisadores vêm estudando o
relacionamento entre as técnicas clássicas de desenvolvimento de soft ware e a inteligência

Página 35 de 584
artificial; um estudo típico desses é Uacob e Fros cher, 1986]. KelIer (IKeller, 1987]) prevê um
tempo no futuro próximo em que os sistemas de IA e especialistas farão parte da atividade
“normal” de análise de sistemas; outros, como lBarstow, 1987] e (Lubars e Harandi, 19871
presumem que a inteligência artificial será útil no auxílio aos ana listas de sistemas na
documentação dos requisiI do usuário em meados dos anos 90. Mais adiante, voltaremos a este
assunto.
39
1
1
2.5 PRINCÍPIOS GERAIS DE SISTEMAS
Todos os exemplos vistos acima têm uma coisa em comum: todos eles são sistemas. Embora
possam ser diferentes de várias maneiras eles compartilham muitas características comuns. O
estudo dessas “caracterís 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 visão mais humorística da freqüentemente
perversa natureza dos siste mas pode ser encontrada no delicioso Systemantics [ 19771.
Apesar do assunto da teoria geral dos sistemas estar além do pro pósito deste livro, existem alguns
princípios “gerais” de particular inte resse para os que constróem sistemas automatizados de
informações. São os seguintes:
1. Quanto mais especializado é um sistema, menos capaz ele é de se adaptar a circunstâncias
diferentes. Isso é muitas vezes usa do para descrever sistemas biológicos (p.ex., animais que têm
dificuldade de se adaptar a novos ambientes), mas também se aplica a sistemas de computador.
Quanto mais um sistema for de «emprego geral”, menos “otimizado” ele será para uma situação
específica; porém, quanto mais um sistema for otimi zado para uma situação específica, menos
adaptável ele será a novas circunstâncias. Isso é um problema verdadeiro para muitos sistemas de
tempo-real que precisam ser otimizados para proporcionarem respostas suíicientemente rápidas aos
estímu los externos. Mas o processo de otimização 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 princípio também é
importante para muitos sistemas comerciais que «refletem” a política do usuário, que também pode
ser extremamente especializada. Quanto mais espe cializados forem os requisitos do usuário para
um sistema de pagamento de pessoal, por exemplo, menos provável será que possa ser utilizado um
pacote comercial disponível.
2. Quanto maior for um sistema, maior o número de seus recursos que serão destinados à
manutenção diária. Novamente a Biologia é o exemplo mais conhecido deste princípio: os dinos
sauros gastavam a maior parte de suas vidas diurnas enchendo se de comida para manter suas
imensas carcaças. Isso também se aplica a exércitos, 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,

Página 36 de 584
exigirá habitualmente muito pouca “burocracia”, enquanto um sistema grande exigirá enormes
esforços nas “improdutivas” áreas da verificação de erros, edição, cópias, manutenção, segurança e
documentação’°.
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 divisão em sistemas menores (veremos
mais detalhes sobre isso nos últimos capítulos do livro). Mais importante, en tretanto, é que ele
sugere que a definição do sistema que queremos desenvolver é arbitrária - poderíamos ter escolhido
um sistema ligeiramente menor ou ligeiramente maior. A escolha do escopo de um sistema e a sua
cuidadosa definição 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 capítulo 18. Isto é
mais difícil do que pode parecer: tanto os usuários como os analistas pensam muitas vezes que os
limites de um sistema são fixos e imutáveis e que tudo que estiver fora desses limites não merece
ser estudado. Estou em dívida côm Lavctte Teague e Christopher Pidgeon ( e Pidgeon, 19851) pela
localização do seguinte exemplo de sistemas dentro dc sistemas, tirado de EEberhard, 1970]:
Uma preocupação inerente aos métodos de projeto é a natureza hierárquica da complexidade. Essa
preocupação movimenta-se em duas direções, escalada e regressão infinita. Usarei uma
história, “O Aviso da Maçaneta”, para ilustrar o princípio da es calada.
Tive esta experiência em Washington, quando eu tinha dinheiro para gastar. Se eu celebrasse um
contrato com um projetista e dissesse: “A maçaneta da porta do meu escritório foi feita com pouca
imaginação e com desenho muito pobre. Você me projetaria outra maçaneta?” Ele responde “sim”,
e após estabelecermos um preço, ele vai embora. Uma semana mais tarde ele volta e diz: “Sr.
Eberhard, estive pensando sobre a maçaneta. Em primeiro lugar, precisamos decidir se uma
maçaneta é a melhor opção para abrir e fechar uma porta”. Eu digo, ‘Ótimo, eu gosto de
imaginação, prossiga”. Ele volta outra vez e diz, “Sabe, estive pensando sobre seu problema e a
única razão para o senhor querer uma maçaneta é que o senhor
41
presume que deseje uma porta para o seu escritório. O Sr. tem certeza de que uma porta é a melhor
maneira para controlar a sakla e a privacidade - “Não! não 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 insistência em ter quatro paredes em volta de
seu escritório. Tem certeza de ser essa a melhor maneira de organizar o espaço para o tipo de
serviço que o Sr. faz como burocrata?”. Eu digo: “Não! não tenho certeza”. Bom, a escalada
prossegue até (e isso aconteceu literalmente com dois contratos, embora não exatamente conforme
este processo) que nosso projetista físico regresse com a fisionomia muito séria. “Sr. Eberhard,
precisamos decidir se a democracia capitalista é a melhor maneira de organizar nosso país antes
que eu possa atacar o seu problema”.
No outro extremo está o problema da regressão infinita. Se aquele homem se deparasse com o
projeto da maçaneta diria:
“Espere. Antes de me preocupar com a maçaneta, quero estudar o formato da mão humana e o que
o homem é capaz de fazer com ela”. Eu diria: “Muito bem”. Ele retornaria e diria: “Quanto mais eu

Página 37 de 584
penso sobre isso, surge um problema de adaptação. O que quero estudar em primeiro lugar é como
o metal é formado, quais são as tecnologias para fabíicar coisas metálicas de modo que eu possa
conhecer os verdadeiros parâmetros para o ajuste à mão”. “Ótimo”. Mas aí ele diz: “Estive
estudando a constituição do metal e tudo depende das propriedades metalúrgicas. Preciso estudar
metalurgia por três ou quatro meses para compreender melhor o problema”. - “Ótimo!”. Após três
meses, ele volta e diz: “Sr. Eberhard, quanto mais estudo metalurgia mais percebo que é a estrutura
atômica que está de fato no centro do problema”. E, assim, nosso projetista físico está estudando
física atômica a partir da maçaneta. Esta é uma das quatro preocupações - a natureza da
complexidade.
4. Os sistemas crescem. Naturalmente, isso não pode ser verda deiro para todos os sistemas ou isso
violaria um princípio geral de sistemas muito conhecido: a lei da conservação 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 típico sistema de
informações, por exemplo, cresce para incluir mais software do que estava previsto originalmente,
mais dados, mais funções e mais usuários. Por exemplo, Lientz e Swanson encontraram em uma
clássica avaliação de aproximadamente 500 empresas de
42
processamento de dados em todo o país (lLientz e Swanson, 19801), que o volume de código 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
construído vá permanecer estático; o custo da expansão pelo tempo deve ser incluído nos cálculos
do “custo-beneficio”, que discutiremos no capítulo 5 e no a C.
2.6 RESUMO
Os analistas de sistemas na atividade de processamento de dados são vítimas freqüentes da lei da
especialização acima examinada. Eles se tornam especialistas em seu próprio campo, sem
perceberem que exis tem outros tipos de ‘construtores de sistemas” e que podem ser aplica dos
alguns princípios gerais. O principal propósito deste capítulo foi ampliar seus horizontes e dar-lhe
maiores perspectivas antes de mergu lharmos mais profundamente no estudo dos sistemas
automatizados de informações.
É claro que não se pode ser especialista em sistemas vivos, físicos e em todas as formas de
sistemas feitos pelo homem em acréscimo aos sistemas automatizados de infor Porém, como os
sistemas que você vier a construir quase sempre irão interagir com esses outros tipos de sistemas, é
importante não os ignorar. Compreendendo que outros sistemas obedecem a muitos dos mesmos
princípios 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.
REFERÊNCIAS
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.

Página 38 de 584
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.

Página 39 de 584
22. M.D. Lubars e M.T. Harandi, “Knowledge-Based Software Design Using Design Schemas”,
Proceedíngs 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”, Engíne ering Methods in Environ
mental Desi,gn and Pia nning, Gary T.
Moore, ed. Cambridge, Mass.: MIT Prcss, 1970, pgs. 364-365.
44
1. Dê dois exemplos de cada uma das definições do que seja um sistema apresentadas pelo
dicionário Webster’s no início do
capitulo 2.
2. Dê cinco exemplos de sistemas que duraram por pelo menos 1 milhão 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 explicação de porque duraram tanto tempo e se podemos esperar que
sobrevivam outros mil anos.
4. Dê cinco exemplos de sistemas não 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 Braín of the Firm de Beer e faça um resumo para seus colegas.
8. Projeto de Pesquisa: leia Tbe Heart ofEnteiprise de Beer e faça um resumo para seus colegas.
9. Com referência à seção 2.3, dê um exemplo de um sistema feito pelo homem, que, em sua
opinião, não deve ser automatizado. Por que você acha que ele não deve ser automatizado? O que
sairia errado?
10. Dê um exemplo de um sistema não-automatizado que, em sua opinião, deveria sê-lo. Por que
você acha isso? Quais seriam os benefícios? E quais seriam os custos? Qual a confiança que você
tem nos benefícios 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 inventário, (c) o sistema telefônico.
12. Escolha uma pequena empresa que você conheça bem, ou um departamento ou divisão de uma
grande empresa. Prepare um inventário dos sistemas utilizados pela empresa que você escolheu.

Página 40 de 584
Quantos deles são sistemas operativos? Quantos são sistemas de apoio à decisão? Quantos são
sistemas de planejamento estratégi co? Existem outras espécies úteis de sistemas? Para ajudá-lo a
enfo car essa área, consulte [ e Quillard, 19821.
13. Dê cinco exemplos de seu próprio conhecimento de (a) sistemas de tempo-real, (b) sistemas on-
line, (c) sistemas de apoio à deci são, (d) sistemas de planejamento estratégico e (e) sistemas espe
cialistas.
45
14. A figura 2.4 mostra uma configuração típica de hardware para um sistema on-line. Desenhe um
diagrama de uma configuração 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 usuário?
15. Dê um exemplo de um sistema comercial que seja descrito como um sistema “de inteligência
artificial» ou “baseado no conhecimen to” que, em sua opinião, não seja honesta ou corretamente
des crito. Por que você acha que a descrição está incorreta?
16. Pode o modelo de resposta a estímulo mostrado na figura 2.5 ser aplicado a sistemas que não
sejam de tempo-real? Não é verdade que todos os sistemas respondem a estímulos? O que há de
especial com os sistemas de tempo-real?
17. Um sistema de apoio à decisão pode realmente tomar decisões? Caso negativo, por quê? O que
poderia ser feito para modificar o sistema típico de apoio à decisão de modo a que ele pudesse
tomar decisões? Seria isso desejável? O que seria relegado em troca dos benefícios?
NOTAS
Os paleontologistas ainda discutem sobre esse problema: alguns acham que os dinossauros se
extingüiram em um relativamente curto período de tempo, depois do choque de um grande meteoro
com a Terra, causando a formação de uma nuvem de poeira tão densa que a maior parte da vida
vegetal teria morrido. Outros consideram que a modificação foi mais gradual, processando-se
durante um período de aproximadamente um milhão 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 também pode auxiliar os analistas de sistemas a com preenderem o fenômeno das práticas de
um usuário serem tão especializadas que não 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 aplicação atual do usuário, pode ser difícil
adap tá-lo quando os requisitos do usuário (e o ambiente externo em que esse usuário opera) se
modificarem ou evolufrem.
3 Webster’s New Coliegiate Dictionaiy, Springfield, Mass.: G.& C.
Merriam Company, 1977.
46
4 A essência de um sistema e modelos básicos (Ou essenciais) serão discutidos no Capítulo 17.
5 Não obstante, cada aplicacão tem seu próprio vocabulário, sua cultura e seu conjunto de
procedimentos. O usuário normalmente espera que o analista de sistemas saiba alguma coisa sobre

Página 41 de 584
os deta lhes, política comercial e procedimentos de sua aplicação, de modo que nem tudo precise
ser explicado do princípio. Assim, se você pretende ser um analista de sistemas de um banco, será
pro vavelmente útil aprender tudo o que for possível sobre as ativida des bancárias. Esta não é uma
via de mão-única: os banqueiros estão aprendendo mais e mais a respeito da tecnologia de sistemas
de informação a cada dia.
6 A palavra terminal está sendo tão usada hoje que não tenho certeza de que precise ser definida.
Entretanto, lembre-se de que há muitos sinônimos: “vídeo”(screen), “estação de trabalho”
(workstation), “teclado” (keyboard) e “unidade de vídeo” (display unit) estão entre os mais
comuns. Existem, também, abreviaturas conhecidas usadas para descrever o dispositivo de
entrada/saída com que nos comunicamos com o computador: “CRT” (“cathode ray tube”), “VDU”
(“visual display unit”) etc. Esses termos serão utilizados indistintamente neste livro.
7 Isso às vezes é mencionado como “diálogo homem-máquina”, ou como “interface homem-
máquina”. Muitas organizações de de senvolvimento de sistemas estão adotando as expressões
“interface homem-computador” ou apenas “interface humana” para evitar enganos desnecessários.
8 Um dos mais interessantes exemplos de uma situação 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 subterrâneos), 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 explosão. Isso é um requisito de processamento em tempo-real.
9 Existem algumas exceções: as organizações menores que ainda não computadorizaram a maior
parte das suas atividades; os antigos sistemas operativos desenvolvidos por 500 empresas nos anos
60 que estão à beira da ruína e os novos sistemas operativos exigidos por füsões, compras ou
entradas em novos mercados e produtos; e a comunidade da defesa tem uma lista aparentemente
interminável de novos sistemas operativos a serem construídos. A tendência geral, entretanto, é de
um vagaroso deslocamento a partir dos siste mas operativos para os de apoio à decisão.
10 Os usuários muitas vezes não apreciam esse fenômeno, e i pode ser um dos motivos para o
presente fascínio das lingi
gens de quarta geração e ferramentas de prototipação. Pode construir rapidamente um sistema com
uma linguagem de qu geração que se incumba das principais partes do processamei
(proporcionando, assim, imediata satisfação ao usuário), ma preciso muito trabalho para introduzir
inteligência artificial i operações de verificação de erros, cópias, manutenção, seguran melhora de
desempenho, documentação etc. É preciso ter e aspecto em mente para evitar ser forçado pelo
usuário a consti um sistema “rápido e sujo” destinado ao fracasso. Para dar u idéia da extensão de
algo tão mundano como a documentaç considere a estatística apresentada por Capers Jones em P
gramming Productivity (Nova lorque: McGraw-Hill, 1986): 1 grande sistema de telecomunicações
tinha 120 palavras em in para cada linha de código-fonte, totalizando 30 milhões de pala e 60.000
páginas e um grande sistema de governo tinha 200 lavras em inglês por linha de código-fonte,
totalizando 125 milh de palavras e 250.000 páginas de documentação.
48
3

Página 42 de 584
PARTICIPANTES
DO JOGO
DOS SISTEMAS
O mundo inteiro é um pako,
Onde todos os homens e todas as mulheres são meros partic!pan:es.
Eles tém suas saídas e suas entradas;
E cada um, por sua vez, desempenha muitos papéis,
Shakespeare
As You Like Ii, II, vii
1. Os tipos de pessoas com quem interagimos em um projeto.
2. Os três principais tipos de usuários, por tipo de tra balho.
3. As reações do usuário durante o projeto dc desenvol vimento de sistemas.
4. A diferença entre os usuários novatos e experientes.
5. O papel da gerência em um projeto de desenvol vimento de sistemas.
6. O papel do analista de sistemas em um projeto de desenvolvimento de sistemas.
7. Outros papéis 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 serão extremamente diferentes umas das outras; e o número de pessoas com
49
quem você vai interagir variará de apenas uma a diversas dúzias. Entre tanto, os personagens são
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 aptidões 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 considerarão sua linguagem da tecnolo gia do computador alienígena e
amedrontadora. Dessa forma, é impor tante saber o que essas pessoas esperam de você e o que
você pode esperar delas.
Este capítulo dedica-se às características dos principais tipos de
“participantes” que você provavelmente encontrará em um típico projeto
de desenvolvimento de sistemas, e que 5
• Usuários
• Gerentes
• Auditores, pessoal do controle dc qualidade e “mantenedores dos padrões”
• Analistas de sistemas

Página 43 de 584
• Projetistas de sistemas
• Programadores
• Pessoal operativo
Cada um desses tipos é descrito a seguir.
3.1 USUÁRIOS
O primeiro, e de longe o mais importante, participante do jogo de sistemas é alguém conhecido
pelos analistas de sistemas como um u.suá rio. Usuário é a pessoa (ou grupo de pessoas) para quem
o sistema é construído. Ele ou ela é a pessoa a quem você entrevistará, muitas vezes
detalhadamente, para saber que características o novo sistema deverá ter para ser bem-sucedido.
Deve-se ressaltar que a maioria dos usuários não se refere a eles
mesmos como “usuários”; afinal, a palavra é freqüentemente 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 utilização dos
termos cliente ou proprietário para identificar o usuário, O usuário é o “proprietário” 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 razão”, não importando quão exigente, desagradável ou ilógico 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 não ficar satisfeito com o produto recebido.
Na maioria dos casos é muito fácil identificar o usuário (ou usuá rios): ele é, normalmente, a
pessoa que emite uma solicitação 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: “João, preciso de um novo sistema para controlar
nossa campanha de comercialização Widget!”. Em uma grande empresa o início do projeto de
desen volvimento de um sistema é muito mais formal. A “solicitação de levantamento e estudo de
um sistema”, como às vezes é chamada, transita normalmente por diversos níveis de aprovação
antes que o analista de sistemas inicie seu envolvimento, O capítulo 5 se estenderá mais sobre esse
assunto.
Entretanto, existem algumas situações em que a identidade do ver dadeiro usuário é 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 interação entre a empresa cliente e a de consultoria
pode se processar entre agentes con tratantes ou outros setores administrativos, às vezes com
cláusulas explí citas de que o analista de sistemas não pode se entender diretamente com o usuário.
Mesmo que o sistema esteja sendo desenvolvido inteira mente dentro de uma única organização, o
“verdadeiro” usuário 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 situações assim existe uma forte possibilidade de mal-entendidos: o que quer
que o verdadeiro usuário queira que o sistema faça pode ser mal transmitido para o analista de

Página 44 de 584
sistemas, e o que quer que o analista de sistemas imagine que está criando para o usuário também
pode ser mal comunicado - até que todo o sistema esteja pronto, quando já será tarde demais!
Podemos tirar daí duas conclusões:
• Sempre que possível, o analista de sistemas deve tentar estabele cer contato direto com o usuário.
Mesmo que outras pessoas
51
estejam envolvidas como intermediárias (p.ex.: para lidar com problemas contratuais ou detalhes
administrativos), é importante que haja reuniões regulares, frente a frente com a pessoa que irá
afinal receber o sistema. Na verdade, é até melhor se o usuário for um membro de tempo integral
da equipe de projeto. Em muitas organizações, o usuário é o gerente do projeto, alguns chegam a
defender a idéia de que o usuário deveria fazer o projeto.
• Se não for possível a comunicação direta com o usuário, então a documentação produzida pelo
analista de sistemas torna-se ainda mais crítica. 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 gênero para evitar mal-entendi dos caros.
3.1.1 A Heterogeneidade dos Usu4rios
Um dos equívocos freqüentemente cometidos por pessoas da área do processamento -
principalmente pelos programadores, e às vezes por analistas de sistemas também, é presumir que
todos os usuários são iguais. “Usuário”, como substantivo singular, implica que o analista irá
interagir com apenas uma pessoa; mesmo quando é óbvio que mais de um usuário está envolvido,
existe a tendência de imaginá-los como um grupo humano indistinto e sem forma.
Dizer-se que um usuário é diferente do outro é, naturalmente, uma declaração trivial. Sim, todos
eles têm diferentes personalidades, diferen tes experiências, interesses, e assim por diante. Mas
existem algumas importantes diferenças que você deve ter em mente em seu trabalho como analista
de sistemas. Aqui estão dois modos de classificar os usuários:
• por tipo de função, ou por nível de supervisão;
• por nível de experiência com processamento de dados.
3.1.2 A Class dos Usuários por Tipo de Função
Em um projeto típico de análise de sistemas, gasta-se um consi derável tempo entrevistando
usuários para estabelecer os requisitos do
sistema. Mas, que usuários? De que nível? Isso, naturalmente, depende
52
do projeto e da doutrina da empresa, mas você, certamente, vai interagir
com três tipos principais de funções: usuários operativos, superiores e
executivos 2
Usuários operalivos são os funcionários burocratas, operativos e administrativos que com mais
probabilidade terão contato diário com o novo sistema (a menos que esteja sendo construído um
sistema de apoio à decisão, caso em que você pode ter pouco ou nenhum contato com esse grupo).
Assim, em uma grande organização, você pode acabar en trevistando secretárias, agentes de

Página 45 de 584
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 usuários
operativos cujos títulos serão engenheiros, físicos, operários de fábricas, pilotos, telefonistas etc.
Há três coisas que você deve ter em mente quando trabalhar com usuários de nível operativo:
1. Os usuários operativos são muito interessados em relação às funções que o sistema executará -
mas eles estão prova velmente mais interessados nos aspectos da interface humana. Os exemplos
sáO: Que tipo de teclado terei de usar para me comunicar com o sistema? Ele se parece com o da
máquina de escrever que venho utilizando há anos? Que tipo de terminal on line terá o sistema?
Será ofuscante? E os caracteres, serão fáceis 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 relatório para mim, onde ficará a in formação
na página? Poderei ter a data e a hora impressas no alto de cada página? E assim por diante. Esses
são problemas em relação aos quais o supervisor do usuário de nível operativo pode estar ou não
ciente ou interessado, mas, como se pode imaginar, eles são 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 usuário operativo, ou (bem menos preferível) deve ter muita certeza
de que a pessoa que fala pelo usuário operativo conhece esses problemas, que são discutidos
detalhadamente como parte do modelo de implementação para o usuário no capítulo 21.
2. Os usuários operativos tendem a ter uma visão “local” do siste ma; tendem ainda a conhecer
apenas a específica tarefa que executam e as pessoas com quem têm contato direto (clientes,
supervisores, colegas etc). Porém eles muitas vezes não conhe cem bem toda a estrutura, isto é, eles
podem ter dificuldade em descrever como suas atividades se encaixam na organização
53
como um todo ou qual seja a verdadeira finalidade d organização. Isso raramente se deve à
estupidez e geralment reflete uma certa falta de interesse por parte deles. Pode tambér ser reflexo
do fato de o usuário supervisor. nada lhes ter falad sobre a estrutura geral e preferir que eles nada
saibam sobre el Uma conseqüência dessa situação é que o analista de sistema deve ser capaz de
desenvolver modelos do sistema qu possibilitem tanto as visões locais (descrição de uma pequena
detalhada parte do sistema, independentemente das outra partes) como as visões globais (visões
gerais de alto nível di todo o sistema, evitando os detalhes).
3. Os usuários operativos tendem a imaginar os sistemas em ter mos físicos, 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 discussões abstratas sobre “funções” e
“elementos de dados podem ser difíceis. Diante disso, o analista de sistemas pod achar necessário
conversar com o usuário exclusivamente c termos que lhe sejam familiares. Em seguida, como
ativida& separada, o analista pode traduzir essa descrição física para un “modelo essencial” - um
modelo do que o sistema deve fazer não importando a tecnologia empregada para implementá-lo
Isso será examinado mais adiante, no capítulo 17.
Os usuários supeivisores são, como o termo indica, empregado em atividades de supervisão. Eles
geralmente cheflam um grupo d usuários operativos e são responsáveis por seus desempenhos
(obvia mente, pode-se imaginar mais de um nível de usuários supervisore em uma grande
organização). Eles podem ter o título de supervisore mas também podem ter os de gerente, chefe de

Página 46 de 584
grupo, chefe de seção encarregado de setor, maquinista-chefe e muitos outros títulos. O aspectos
importantes a serem lembrados a respeito de usuário supervisores Sao:
• Muitos deles foram originalmente usuários operativos que foran promovidos à atual posição
Assim, eles geralmente conhecem c serviço feito por seus subo dinados operativos, e pode-se
imagi. nar que habitualmente sin pauzem com suas necessidades, pre ocupações 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 atrás.
54
• Uma razão pela qual o usuário supervisor pode ser visto como não tendo contato com o usuário
operativo é que ele ou ela é muitas vezes avaliado e motivado pelo desempenho em relação a um
orçamento. Em face disso, o usuário supervisor está freqüentemente mais interessado em um novo
sistema de infor mações pela possibilidade de aumentar o volume de trabalho realizado, reduzindo
o custo de processamento das transações e diminuindo os erros no serviço. Também 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 usuário operativo. Dependendo de como isso for
imple mentado, os usuários operativos podem ter ou não a mesma perspectiva do usuário
supervisor.
• Em virtude da ênfase na eficiência operativa é comum o usuário supervisor ver o novo sistema
como um meio de reduzir o nú mero de usuários operativos (por dispensas ou a pedido) ou de
evitar novos aumentos desse número quando o volume de ser viço crescer. Isso não é bom nem
mau, porém é muitas vezes o ponto focal de disputas políticas acaloradas, em que o analista de
sistemas freqüentemente se vê envolvido
• Por esses mesmos motivos, o usuário supervisor age muitas vezes como intermediário entre o
analista de sistemas e o usuá rio operativo, argumentando que os usuários operativos são muito
ocupados para desperdiçar o tempo conversando com o analista. “Afinal de contas”, dirá o usuário
supervisor, “é exa tamente por estarmos tão atarefados que precisamos de um novo sistema de
processamento!” Como é fácil imaginar, essa é uma posição muito perigosa, afinal, é o usuário
operativo quem está mais interessado com a iruerface humana do sistema, e é improvável que o
usuário supervisor seja capaz de compreender essa necessidade.
• O usuário supervisor muitas vezes pensa nos mesmos termos físicos que o usuário operativo e
essa perspectiva é muitas vezes tão local quanto a desse último. Seria de se esperar, natu ralmente,
que alguém em nível de chefia possuísse uma visão mais global; como corolário é possível que o
usuário supervisor já não se recorde de alguns detalhes da orientação comercial executada pelos
usuários operativos.
• Por fim, é com o usuário supervisor que você terá seu princi pal contato diário. Ele ou ela é quem
normalmente define os
55
requisitos e a detalhada orientação 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 usuários de nível executivo normalmente não estão diretamente envolvidos nos projetos de

Página 47 de 584
desenvolvimento de sistemas, a menos que o projeto seja tão grande e tão importante que venha a
ter grande impacto na organização. No caso de um projeto normal, entretanto, o usuário executivo
está habitualmente dois ou três níveis acima das atividades associadas ao projeto. À proporção que
tiver contato com eles você provavelmente descobrirá o seguinte a respeito deles:
• Eles podem ter a iniciativa do projeto, mas provavelmente servi rão como a autoridade financeira
para as solicitações de projetos
que se originem nos níveis inferiores da organização.
• Eles normalmente não foram usuários operativos ou, se o ti verem sido, foi a tanto tempo que
qualquer experiência que pudessem ter já está obsoleta. Dessa forma, eles não es tão em posição de
ajudar a definir os requisitos do sistema pa ra os que realmente o utilizarão diariamente. A exceção
é o sis tema de apoio à decisão discutido no capítulo 2; tal sistema se ria normalmente mais
utilizado pelos usuários executivos e supervisores.
• Os usuários executivos são upicamente mais interessados nos aspectos estratégicos de lucros e
perdas a longo prazo. Dessa forma, eles normalmente estão menos preocupados com os problemas
operativos como custos reduzidos de transações ou a conservação de três funcionários burocratas
do que com o que Paul Strassman chama de ‘pagamento da informação” em lStrassman, 19851 -
isto é, novos mercados, novos produtos ou novas vantagens competitivas que obterão do novo
sistema.
• Os usuários do nível executivo geralmente estão mais interes sados na visão global do sistema e,
como resultado, não se in teressam pelos detalhes. Como já dissemos, isso significa que devemos
usar ferramentas de modelagem de sistemas que per mitam oferecer uma visão geral do sistema
para os usuários executivos (e para qualquer um que dela precise) e partes deta lhadas do sistema
para os usuários operativos que sejam os “peritos locais”.
56
• De modo semelhante, os usuários do nível executivo são nor malmente capazes de lidar com
modelos abstratos de um sis tema; na verdade, já estão habituados a lidar com estes modelos como
os modelos financeims, mercadológicos, organizaciona1 e de engenharia (de novos produtos,
fábricas, escritórios etc.). Não estarão, na realidade, de forma alguma interessados nos modelos
“fisicos do sistema” e ficarão imaginando porque você os estará aborrecendo mostrando-lhes todas
essas coisas.
Resumindo, você pode esperar interagir com três diferentes tipos ou níveis de usuários, como
mostrado na figura 3.1. Lembre-se que eles têm diferentes perspectivas, diferentes interesses e
prioridades e muitas vezes diferentes retrospectos. Esses três tipos de usuários podem ser
caracterizados como mostrado na tabela 3.1.
Na discussão anterior sugeri que o usuário nem sempre está satis feito com a perspectiva de um
novo sistema. Na realidade, às vezes, ele se opõe ativamente à idéia. Esse muitas vczes é o caso
dos usuários operativos (já que são os que terão dc usá-lo), mas a resistência também pode provir
do usuário supervisor (uma vez que ele ou ela pode consi derar que o sistema terá impacto negativo
na eficiência ou na lucrativida de do setor do qual ele ou ela é responsável) ou até do usuário
executi vo. Como Marjorie Leeson diz em ILeeson, 1981],
O analista que conhece a motivação básica, porque as pessoas resis tem às modificações e como

Página 48 de 584
elas resistem às modificações, pode ser capaz de superar algumas resistências. A maioria dos livros
sobre ge rência faz referência à hierarquia das necessidades do psicólogo AH. Maslow. As cinco
categorias, da prioridade mais baixa à mais elevada, São:
Necessidade Exemplos
1. Fisiológica Alimentação, vestuário
e abrigo
2. Segurança Proteção contra perigos e
perda do emprego
3. Social Identificação com
pessoas e grupos
4. Egotista Reconhecimento, status
e importância
5. Realização Realização de todo o
pessoal potencial em criatividade
e desevolvimento pessoal
Desse modo, se você encontrar alguns usuários apresentando resis tência à idéia de um novo
sistema, você deve considerar a possibilidade
57
de uma ou mais dessas necessidades não serem satisfeitas. É difícil, natu ralmente, que um usuário
se preocupe com o nível fisiológico de neces sidades mas não é absolutamente surpreendente
descobrir que um usuá rio esteja preocupado com a perda dc seu emprego. E também é comum que
os usuários (principalmente os operativos) se preocupem com que o novo sistema faça com que
eles não se identifiquem com seus respec tivos grupos sociais. Eles receiam que ficarão presos a
um terminal de vídeo o dia inteiro e que passarão todo o tempo interagindo com um computador e
não com outros seres humanos, O usuário operativo que se tornou perito na execução de uma
atividade de processamento de informações de forma manual pode achar que um novo sistema
deixará
Tabela 3.1 Características dos usuá rios
Usuário Operativo
Usuário Supcrvi.sor
Usuário Executivo
Normalmente tem visão local
Pode ou não ter visão local
Tem visão global
Executa a função do sistema
Normalmente conhece a operação

Página 49 de 584
Tem iniciativa sobre o projeto
Tem visão física do sis tema
Orientado por consi derações orçamentárias
Não tem experiência operativa
Muitas vezes age como intermediário entre os usuários e os níveis mais elevados da direção
Tem preocupações estra tégicas
Usuário executivo
Usuário operativo
Figura 3.1: Os três tipos de usuá ri os
58
suas necessidades ‘egotistas” insatisfeitas; e o usuário que imaginar que o sistema poderá eliminar
os aspectos de sua atividade atual também pode opor-se.
3.1.3 Class dos Usuários por Nível de Experiência
Deveria ser óbvio que usuários diferentes tivessem níveis de expe riência diferentes; infelizmente,
é comum que os analistas de sistemas presumam que lodos os usuários sejam completos ignorantes
em termos de processamento de dados. Isso talvez fosse algo verdadeiro há dez anos atrás, mas é
provável que lhe trouxesse grandes problemas na maioria das organizações modernas pode-se
distinguir amadores, novatos e um pequeno (porém aumentando rapidamente) número de
verdadeiros peritos em processamento.
O usuário amador é o que nunca viu um computador e que excla ma alta e freqüentemente que
“não entende nada de computadores». Esse usuário muitas vezes é um funcionário ou comerciante
de meia- idade que sobreviveu alegremente a 16 anos de educação e a outros 10 ou 20 anos em um
emprego, antes que os computadores fossem introdu zidos. Entretanto, também é comum
encontrarmos usuários 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 “diálogos homem-máquina orientados por menu” e outros
assuntos afins - mas, se o analista de sistemas fizer seu sewlço corretamente, não há motivos para
que o usuá rio deva ser interessado ou entendido em computadores.
Na realidade, o verdadeiro problema com o usuário amador é algo mais sutil. Ele pode sentir
dificuldade em compreender a “linguagem» utilizada pelo analista de sistemas para descrever os
recursos, funções e características do sistema a ser construído, 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 criação de alguns modelos do sistema a ser construído. Esses modelos são
representações formais e rigorosas de um sistema de processamento e ao mesmo tempo são repre
sentações abstratas do sistema. A maioria dos modelos envolve gráficos (figuras) apoiados por
textos detalhados e a representação geral (neces sária para garantir uma descrição formal e
rigorosa) choca os usuários com uma matemática complexa e portanto ilegível. Esses usuários
recor dam a dificuldade em ler a complexa notação gráfica usada na química orgânica ou a notação
igualmente complexa empregada no cálculo dife rencial e na álgebra. Qualquer que seja o motivo,
o resultado é o mesmo:

Página 50 de 584
longe de entender a terminologia do processamento, se o usuário não
59
compreender o modelo do sistema, existe pouca possibilidade de ficar satisfeito com o sistema
quando ele ficar pronto .
Um segundo tipo de usuário é 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 usuário que
tem um computador pessoal e que escreveu um ou dois programas em (ugh!) BASIC. Esse usuário
freqüentemente alardeia que sabe exatamente o que deseja que o sistema faça e está disposto a
apontar todos os erros cometidos pelo analista de sistemas no último projeto. Isso tudo é ótimo,
exceto por um detalhe: o usuário muitas vezes se envolve demais em discussões sobre a específica
tecnologia que será utilizada na Implementação do sistema. Assim, o usuário pode dizer ao analista
de sistemas: “preciso de um novo sistema de processamento de pedidos e gostaria que ele fosse
construído com uma rede local interligando nossos IBM PC e acho que deveríamos utilizar o
dBASE-III ou o PC-FOCUS”. Essas podem eventualmente se revelarem as opções técnicas mais
corretas, mas é prematuro até consi derar o hardware, a linguagem de programação e os pacotes de
bancos de dados antes que os verdadeiros requisitos do sistema tenham sido documentados. Na
realidade, no caso extremo, a “sugestão” do usuário sobre os adequados hardware e software pode
se transformar em uma “solução 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 usuários que realmenie conhecem análise de sistemas, bem como a
subjacente tecnologia dos computadores (e também seu próprio ramo de atividades, naturalmente!).
É um prazer trabalhar com essas pessoas. Na verdade, o único problema pode ser o de que o
usuário e o analista de sistemas sintam tanto prazer em conver sar sobre as ferramentas e as
técnicas da análise de sistemas que esque çam que o objetivo real é a elaboração de um sistema que
funcione 8!
3.2 A GERÊNCIA
Gerência é um termo bastante vago. Na realidade, o analista de
sistemas provavelmente terá contato com vários tipos de gerentes.
Gerentes usuários - são os gerentes encarregados de várias pessoas da área operativa em que o
novo sistema será utilizado. Isso já foi discutido anteriormente. Habitualmente são gerentes de
nível médio que querem sistemas que produzam diversos relatórios internos e análises das
tendências de curto prazo. Os relatórios internos geralmente são relatórios financeiros, operau vos,
de exceções, e assim por diante.
• Gerentes de PED/SIG - as pessoas encarregadas do projeto de desenvolvimento do sistema e os
gerentes de nível superior preocupados com o gerenciamento geral e a alocação de recur sos de
toda a equipe técnica da organização de desenvolvi mento de sistemas.
• Gerenclamento Geral - gerentes do nível mais elevado que não estão diretamente envolvidos em
PED nem na organização usuária. Aí podem ser incluídos o presidente e/ou o gerente- geral da
organização e/ou a direção financeira (o “controiler”, o vice-presidente de finanças etc.). Esses
diretores estão normal mente mais interessados nos sistemas de planejamento estraté gico e de
apoio à decisão, discutidos no capitulo 2. Embora a alta direção necessite dos relatórios financeiros

Página 51 de 584
internos, seus membros normalmente não precisam do nível de detalhamento (principalmente na
área de relatórios de exceções) necessário aos gerentes usuários. Além disso dão mais atenção a
infor mações externas: normas governamentais, relatórios da compe tição em seu mercado,
relatórios sobre novos mercados e pro dutos, e assim por diante.
A principal interação entre o analista de sistemas e todos esses gerentes tem a ver com os recut que
serão destinados ao projeto. É tarefa do analista de sistemas identificar e documentar os requisitos
do usuário e as restrições dentro das quais o sistema deverá ser construído. Essas restrições
consistem normalmente em recursos: pessoal, tempo e dinheiro. Assim, o analista de sistemas
eventualmente produzirá um documento que diga: “o novo sistema dève executar as funções X, Y e
Z e deve ser desenvolvido em seis meses com no máximo três programa dores do departamento de
PED a um custo máximo de $100.000”.
Obviamente a direção 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 orçamento. Porém esses problemas pertencem à gerência do projeto, e não à análise
de sistemas . Os gerentes de diversas áreas funcionais diferentes muitas vezes formam uma
comissão de direção 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 nível do gerente, torna-se menos
provável que conheça ou se interesse pela tecnologia do pro
cessamento de dados. Embora isso seja uma generalização, é
61
habitualmente um pressuposto seguro em relação à atual geração de gerentes de alto nível. Isso não
deve afetá-lo como analista de sistemas (os projetistas de sistemas têm tarefa mais árdua!), mas
você deve lembrar-se de concentrar a discussão nas características essenciais de um sistema ao
conversar com eles.
• As metas e prioridades da direção podem ser conflitantes com as dos usuários, principalmente os
supervisores e operativos. A direção pode até impor um sistema aos usuários e os forçar a utilizá-lo
(p.ex., se a empresa usuária tiver tido prejuízos ou não tiver podido reagir a novas modificações do
mercado).
• Uma variação do tema acima: a direção pode não conceder os recursos, verbas ou tempo que os
usuários consideram ne cessários para a construção de um sistema eficiente. É con veniente para o
analista de sistemas e para o usuário responder a isso afirmando que a direção “não compreende”,
mas isso muitas vezes é uma decisão consciente e calculada. Se desejar maiores detalhes sobre a
política de provisão de recursos e es calonamentos, veja o apêndice B.
• O termo gerência (direção) implica em um grupo homogêneo de pessoas que pensam do mesmo
modo. A verdade, na turalmente, é normalmente muito diferente. Os gerentes têm di ferentes visões
e opiniões, e muitas vezes têm metas e objetivos muito diferentes. Eles discutem entre si e
competem uns contra os outros. Assim, pode acontecer que alguns membros da di reção sejam
favoráveis ao novo sistema enquanto Outros sejam contrários. Pior ainda é a omissão que por vezes
sobrevém em relação a alguns projetos; eles finalmente terminam após anos de lento progresso.

Página 52 de 584
• Também é cômodo presumir que depois que a direção decidiu- se a respeito do projeto de
desenvolvimento de um sistema, que ele seja mantido. Mas nem sempre é assim. Forças externas à
organização podem fazer com que a direção 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 direção e o seu projeto de desenvolvi mento de sistemas pode depender
muito da estrutura geral da direção de sua empresa, principalmente o relacionamento entre as
atividades de desenvolvimento de sistemas e o resto da organização. A estrutura
62
organizacional clássica é mostrada na figura 3.2 (a); observe que o setor de processamento de
dados como um todo se reporta ao setor de fi nanças e contabilidade, O motivo para isso é que a
maioria das grandes empresas introduziram originalmente os computadores para auxiliarem a
automatizar suas atividades contábeis (folha de pagamento, livro-razão e contas a receber).
A partir dos anos 70, algumas empresas começaram a compreender que essa estrutura era um tanto
assimétrica. Ela virtualmente garantia que a função de processamento de dados seria orientada para
aplicações contábeis e haveria pouco interesse ou conhecimento em outros setores da organização.
Quando as informações automatizadas de processamen to começaram a transitar pela empresa (na
fabricação, 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 é tão im portante para a sobrevivência da empresa como a fabricação,
engenha ria, vendas etc.
Entretanto, nos anos 80, algumas empresas começaram a conside rar que o setor de SIG tinha se
transformado em um “império”, com suas próprias prioridades e sua própria política. As
organizações usuárias, 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 rápida proliferação dos baratos e poderosos computadores pessoais; assim, alguns
depar tamentos usuários perceberam que poderiam desenvolver seus próprios sistemas, sem
necessitar de uma função centralizada de SIG. Como resultado, algumas empresas agora têm uma
estrutura como a da figura 3.2 (c). Embora continue existindo um setor central de SIG para
aplicações “clássicas”, como folha de pagamento e livro-razão, boa parte do processamento
departamental é feito por grupos de desenvolvimento de sistemas dentro dos departamentos.
Se você trabalha em uma organização caracterizada pela figura 3.2 (a), você poderá perceber que
os analistas de sistemas e os usuários em vários outros setores não são tão bons quanto deveriam.
Na verdade, é provável que você descubra que muitos dos projetos de desenvolvi mento de
sistemas são do tipo “processamento de transações” que podem ser encontrados em um
departamento de contabilidade. Se sua empresa se parece mais com a apresentada na figura 3.2 (b),
então há uma boa possibilidade de que o grupo de desenvolvimento de sistemas tenha uma
razoável “visibilidade” política na organização. Entretanto, pode-se perceber que existe uma
crescente frustração relativa ao backlog de novos sistemas à espera de serem desenvolvidos. E se
você estiver trabalhando em uma organização do tipo apresentado na figura 3.2 (c), é

Página 53 de 584
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 usuários
provável que você tenha muito mais contato direto com os usuários de seu sistema - na verdade,
você talvez trate diretamente com eles. Tam bém é provável que você venha a trabalhar com
computadores pessoais e outras pequenas redes de sistemas de processamento adquiridos dire
tamente pelo setor usuário.
3.3 AUDITORES, CONTROLE DE QUALIDADE E PADRONIZADORES
Dependendo do tamanho de seu projeto e da natureza da organi zação em que trabalha você pode
ter ou não auditores, pessoal de controle de qualidade e/ou membros do setor de padronização par
ticipando do projeto. Agrupei essas pessoas em uma só categoria porque o objetivo e as
perspectivas delas são em geral semelhantes, se não fo rem iguais.
O objetivo geral dessa heterogênea tripulação é garantir que o seu sistema será desenvolvido de
acordo com vários padrões externos (exter nos a seu projeto): padrões de contabilidade
desenvolvidos pelo setor de contabilidade de sua empresa; padrões desenvolvidos por outros se
tores da organização ou pelo cliente/usuário que receberá seu sistema; e possivelmente padrões
impostos por diversos setores normatizadores governamentais.
Existem três problemas que devem ser tratados antecipadamente
ao se lidar com auditores, controladores de qualidade ou componentes
do setor de padronização:
1. Eles muitas vezes não se envolvem no projeto até que esteja terminado - depois que a análise de
sistemas, o projeto e a programação tenham encerrado suas tarefas e tenha começado a atividade de
testes formais. Nesse ponto, naturalmente, é muito difícil fazer grandes modificações no sistema.
2. Eles muitas vezes estão habituados com uma antiga notação ou formato para a documentação
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 capítulo 4)
sejam compreensíveis “.
3. Infelizmente, os membros desse grupo estão freqüentemente mais interessados na forma do que
na substância: se seus do cumentos não estiverem exatamente corretos, poderão ser rejeitados.
67
3.4 O ANALISTA DE SISTEMAS
É vocéi O analista de sistemas é um membro essencial de qualquer projeto de desenvolvimento de
sistemas, e as seções precedentes deste capítulo já lhe deram diversos exemplos de como o analista

Página 54 de 584
de sistemas interage com outros participantes do projeto.
Em um sentido lato, o analista de sistemas desempenha vários
papéis:
Arqueólogo e escriba. Como analista de sistemas uma de suas principais tarefas é trazer à luz os
detalhes e documentar a orientação comercial que possa existir somente como «folclore tribal”,
passado de geração em geração de usuários.
• Inovador. O analista de sistemas deve separar os sintomas do problema do usuário de suas
verdadeiras causas. Com o seu co nhecimento da tecnologia do processamento, o analista deve
auxiliar o usuário a explorar as novas e úteis aplicações dos computadores - e novas maneiras para
o usuário conduzir seus negócios. Embora muitos dos primeiros sistemas de processa mento apenas
perpetuaram os negócios do usuário em velocidade eletrônica, os analistas de sistemas estão sendo
hoje desafiados a auxiliar o usuário a encontrar produtos e mercados radicalmente novos e
inovantes, tornados possíveis 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 capítulo, é o analista de sistemas que muitas vezes se vê no
meio de usuários, gerentes, programadores, auditores e vários outros participantes - que
freqüentemente se desentendem entre si. Existe a tentação do analista de sistemas tentar impor sua
visão de como o sistema deva parecer ou que funções ele deva conter. Mas a principal atribuição do
analista é obter um consenso, o que requer a deli cada arte da diplomacia e da negociação!
• Líder de projeto. Não é um papel universal, mas ocorre com su ficiente freqüência 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 tendência natural para atribuir ao analista as responsabilidades da gerência 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 técnicos’ Você precisa ter habilidade com as pessoas
para entrevistar usuários, mediar desentendimentos e sobreviver às inevitáveis batalhas políticas
que ocorrem em todos os projetos, mesmo nos mais triviais. Vo cê precisa de conhecimento de
aplicações para compreender e apreciar a empresa do usuário. Você precisa de habilidade em
pmcessamento para compreender os potenciais usos do hardware e do software dos computadores
na empresa do usuário. E (obviamente) você necessita de uma mente lógica e organizada; você
precisa ser capaz de visualizar um sistema de várias perspectivas diferentes, ser capaz de subdividi-
lo em subsistemas de vários níveis e de pensar em um sistema em termos abstratos e fisicos 12
Ninguém disse que era uma tarefa fácil!
3.5 PROJETISTAS DE SISTEMAS
Como ficou implícito em nossas discussões anteriores, o projetista de sistemas é a pessoa (ou
grupo de pessoas) que recebe a saída de seu trabalho de análise de sistemas: a tarefa dele é
transformar uma lista isenta de tecnologia dos requisitos do usuário em um projeto arquitetural de
alto-nível que fornecerá a estrutura com a qual os programadores poderão trabalhar. A natureza
dessa atividade é discutida no capítulo 22.

Página 55 de 584
Em muitos casos, o analista de sistemas e o projetista são 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
realimentação que ocorre entre a análise e o projeto de sistemas: o analista de sistemas deve
fornecer informações suficiente mente detalhadas para que o projetista elabore um projeto
tecnologica mente bom, e o projetista de sistemas deve fornecer informações sufi cientemente
acuradas para que o analista de sistemas possa dizer se os requisitos do usuário que ele ou ela está
documentando são tecnologica mente viáveis. Fundamentando-se nas informações recebidas do
projetis ta de sistemas, o analista pode ter de negociar com o usuário para mo dificar seus
requisitos.
3.6 PROGRAMADORES
Pode-se argumentar que no melhor dos mundos não 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 descrição arquitetural dos
componentes dc hardware e software que serão utilizados para implementar o sistema) aos
programadores.
Existe uma outra razão para que o analista de sistemas e os progra madores tenham pouco ou
nenhum contato entre Si: O serviço é muitas vezes executado de maneira estritamente seqüencial
em muitos projetos de desenvolvimento de sistemas “. Desse modo, a tarefa de análise de sistemas
é iniciada antes e é totalmente executada antes que a tarefa de programação 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 participação no projeto.
Entretanto, é provável que haja algum contato entre os programa dores e os analistas de sistemas
pelas seguintes razões:
• Em pequenos projetos, as tarefas de análise, projeto e programa ção são combinados e, assim,
pode acontecer de uma pessoa fazer o serviço de análise e de projeto de sistemas e continuar
interagindo com o programador. Pode também acontecer de uma pessoa desempenhar funções 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 ambigüi 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 específicos e detalhados. Se estiver faltando alguma coisa,
ou se houver algo errado ou confuso, o programa dor tem duas opções: pedir ao analista de
sistemas melhores esclarecimentos ou perguntas ao usuário .

Página 56 de 584
• Como dissemos n’ capítulo 2, muitas empresas estão come çando a perceber que é necessário
substituir os sistemas opera tivos que foram consti há 20 anos. Na imensa maioria desses projetos
de redesei. olvimento praticamente não há
70
documentação que descreva como o sistema funciona, ou (ainda mais importante!) o que se
imagina que o sistema faça. E como os sistemas já têm 20 anos, já existe toda uma nova geração de
usuários envolvidos; os usuários que estavam mi cialmente envolvidos na especificação dos
requisitos do sistema já se aposentaram ou mudaram de emprego e a nova geração de usuários tem
apenas uma pequena idéia dos detalhados requisi tos normativos embutidos no sistema. Nesse
momento, todas as atenções se voltam para o programador de manutenção, que tem feito o sistema
continuar funcionando nos últimos anos; essa pessoa é também provavelmente um funcionário da
segun da ou terceira geração, não tendo tido qualquer contato com os projetistas e programadores
que construíram originalmente o sistema! Como afirma Nicholas Zvegintzov (autor do artigo Soft
ware Maintenance News):
Até o presente momento, o principal profissional da computação era alguém 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á alguém 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 alguém é o engenheiro às avessas. Os man tenedores de software são os
engenheiros às avessas da sociedade.
• Algumas organizações estão cotneçando a modificar suas equi pes de projeto da estrutura vertical
para uma horizontal. A dis tribuição típica de responsabilidade (que é pressuposta em todo este
livro) atribui todas as tarefas de análise de sistemas a uma pessoa (ou grupo de pessoas); de modo
semelhante, todas as tarefas de projeto são atribuidas ao projetista e todas as ativida des de
programação são entregues ao programador. Quando se adota essa abordagem parece de fato que
os analistas de sis temas e os programadores têm pouco contato entre si. Porém algumas
organizações começam a perceber que existe um con flito inerente a essa abordagem: os analistas
de sistemas são, de hábito, pessoas mais antigas e mais experimentadas dentro da organização e,
mesmo assim, são solicitados a executar não ape nas a lista conceitual de alto nível dos requisitos
do sistema, mas também os detalhes elementares de nível inferior dos requisitos do usuário. Igual
conflito existe entre os programadores que ti picamente são mais jovens e menos expericntes Uma
solução é dar ao pessoal técnico “sênior” (cujo titulo é o de analistas de
71
sistemas) todas as atividades de alto nível: análise de sistemas de alto nível, projetos de alto nível e
a cod dos módulos de nível superior do sistema; de modo análogo, ao pessoal técnico de nível
‘júnior” são dadas atribuições de detalhes de nível infe rior na área da análise e na área de projeto e
na da programação. 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 capítulo 23.

Página 57 de 584
3.7 PESSOAL DE OPERAÇÕES
Assim como alguém poderia argumentar que o analista de sistemas nunca teria contato com o
programador, poder-se-ia afirmar que o ana lista de sistemas não precisa ter qualquer interação com
o pessoal de operações, que é responsável pelo centro de processamento, pela rede de
telecomunicações, pela segurança do hardware e dos dados do com putador, bem como pela
execução dos programas, pela montagem dos diskpacks e pela manipulação da saída das
impressoras. Tudo isso acon tece depois que um novo sistema foi não somente analisado e
projetado, mas também programado e testado.
Entretanto, há mais sobre isso do que se pode ver, O analista de sistemas deve conhecer algumas
das restrições impostas a um novo siste ma pelo pessoal de operações, porque isso deve fazer parte
da especifi cação 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
funções X, Y e Z e, para se adaptar aos requisitos do Departamento de Operações, ele deve ocupar
não mais que 16 megabytes de memória do computador de grande por te. O sistema deve ser
implementado com utilização de terminais IBM 3270 comuns interligados à rede de
telecomunicações XYZ da empresa”.
Em alguns casos, os detalhes operacionais do sistema podem ser uma questão de negociação entre
o usuário e o grupo de operações do computador central. Isso é particularmente comum hoje,
quando os usuários muitas vezes estão em situação 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
organização usuária (portanto não precisando dos talentos especializados do pessoal de operações),
e embora muitos desses computadores possam funcionar no ambiente de um escritório normal (não
precisando da fiação especial e do equipamento de ar condicionado típico dos mainframes), ainda é
72
verdade que essas pequenas máquinas terão 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 através de uma rede
local ou de algum dispositivo de telecomunicações. Tudo isso normalmente envolve interação com
o pessoal de operações; somente um sistema “stand alone” realmente independente pode ser
construído sem a assistência e aprovação daquele pessoal.
Esses problemas operacionais são documentados em uma parte do
esforço de análise de sistemas conhecida como modelo de implemen tação do usu Isso será visto
detalhadamente no capitulo 21.
3.8 RESUMO
Como vimos neste capítulo, 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, porém ainda mais esforço é 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á.

Página 58 de 584
Todos os participantes são pessoas e elas têm diferentes metas, di ferentes prioridades e diferentes
perspectivas. Embora elas possam estar comprometidas com o sucesso do projeto, eles podem ter
preocupações ocultas que se opõem a um ou mais aspectos desse projeto.
As perguntas e exercícios no final deste capítulo destinam-se a fazer você pensar um pouco mais
sobre esses aspectos. Você deve con sultar também o excelente livro de Block sobre a política de
projetos (iBiock, 1982D ou até o clássico livro de Sun Tzu sobre a arte da guerra [ 1983].
REFERÊNCIAS
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.
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 não teve conta to direto com o verdadeiro
usuário. Quais foram as vantagens e desvantagens dessa situação? Que arranjos alternativos foram
feitos?
3. Você pode citar algum outro termo para usuário além de proprie tário ou cliente?
4. Você pode imaginar alguma situação em que o analista de sistemas não devesse falar com o
usuário?
5. Quais são as vantagens e desvantagens de o usuário ser um mem bro em tempo integral da
equipe de projeto de desenvolvimento de um sistema? Você pode imaginar alguns projetos
específicos em que seria particularmente recomendável que o usuário participasse da equipe de
projeto?
6. Quais são as vantagens e desvantagens de o usuário ser o gerente da equipe de projeto de
desenvolvimento de um sistema? Você pode imaginar alguns projetos específicos em que seria
particularmente recomendável que o usuário gerenciasse o projeto?
7. Quais são as vantagens e desvantagens de o próprio usuário desen volver inteiramente um

Página 59 de 584
sistema de informações? Você pode imagi nar alguns projetos em que seria particularmente
recomendável que o usuário fosse o analista, o projetista, o programador e o gerente?
8. Qual o conhecimento que o usuário deve ter sobre computadores e sobre software para poder
participar de uma equipe de projeto durante a fase de análise? Qual o conhecimento que ele deve
ter a respeito das ferramentas e técnicas da análise de sistemas?
gerenciar uma equipe de projeto de desenvolvimento de sistema? Qual o conhecimento que ele
deve ter a respeito da análise de sistemas para poder ser um eficiente gerente?
74
desenvolver por ele mesmo todo o projeto de desenvolvimento de um sistema? Qual o
conhecimento que ele deve ter sobre análise de sistemas?
11. Que precauções especiais você tomaria como analista de siste mas se você não tivesse contato
direto com o usuário? Você acha que as ferramentas de modelagem descritas neste livro seriam
suficientes?
12. A seção 3.1.2 relaciona diversas preocupações que o usuário ope rativo poderia ter com um
novo sistema. Apresente mais três prová veis aspectos com que ele pode se preocupar. Você acha
que essas preocupações são razoáveis, ou elas apenas refletem o típico des conhecimento do
usuário sobre computadores?
13. Que responsabilidade ética ou moral tem o analista de sistemas em relação ao usuário operativo
se ele estiver convencido de que não haverá dispensas de empregados, mas o usuário está
preocupado com que haja? (Veja também a pergunta 19).
14. Descreva as circunstâncias em que os usuários operativos pode riam causar o fracasso de um
novo sistema. Você acha que essas circunstâncias são realistas? O usuário supervisor não poderia
sim plesmente determinar que o sistema fosse utilizado?
15. Quando você acha que os problemas da interface humana devem ser discutidos com os
usuários? Logo no início do projeto? Mais tarde? O que deveria ser negociado? (Você pode
consultar o capítu lo 21, se o desejar).
16. Você acha que não é verdadeiro que os usuários operativos te nham apenas uma visão 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 situação? Deve o analista de sistemas tentar dar uma
visão global aos usuários operativos?
17. Dê um exemplo de uma visão física, ou orientada para a imple mentação, de um sistema, que
um usuário operativo pode ter. Você
vê algum problema nisso?
18. O que deve fazer o analista de sistemas se o usuário supervisor não deixar que ele se dirija
diretamente aos usuários operativos? Como
o analista de sistemas deve enfrentar tal situação?
19. Que responsabilidade moral ou ética tem o analista de sistemas com o usuário supervisor se os

Página 60 de 584
usuários operativos demonstrarem preocupação com possíveis demissões causadas pelo novo siste
ma? (Veja também a pergunta 13).
20. Dê um exemplo de um sistema onde o usuário supervisor pode não estar familiarizado com os
detalhes políticos da empresa que
são presentemente executados pelos usuários operativos.
75
21. Por que os usuários de nível executivo normalmente não se inte ressam ou se preocupam com a
possível economia a ser obtida com a redução do pessoal (por dispensas ou demissões a pedido)
tornada possível com o novo sistema?
22. Qual o grau de envolvimento que os usuários de nível execu tivo devem ter no
desenvolvimento de um novo sistema de
informações?
23. Que opções tem o analista de sistemas se o usuário não entende modelos abstratos em papel?
24. Como o analista de sistemas deve lidar com os novatos descritos neste capítulo? E se o usuário
insistir em uma determinada opção
de hardware ou software para o novo sistema?
25. Que responsabilidade tem o analista de sistemas em conseguir o consenso entre os usuários? E
se ele falhar nesse aspecto?
26. Quais os riscos enfrentados pelo analista de sistemas em relação à direção, como vimos na
seção 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 direção forem conflitantes
com as do usuário?
28. Quando, na sua opinião, o pessoal de operações deve se envolver no projeto?
29. A análise e o projeto de sistemas (e também a programação) devem ser desempenhadas pela
mesma pessoa (ou por um grupo coeso
de pessoas)? Quais são as vantagens e desvantagens?
NOTAS
1 Uma situação desse tipo ocorre comumente com o agente contra tante de uma empresa
governamental. Na maioria dos casos, essa pessoa não é o usuário e pode não saber muito a
respeito das reais necessidades dele, mas ele ou ela é a pessoa designada para man ter toda a
comunicação oficial com o desenvolvedor ou com a empresa desenvolvedora do sistema.
2 Existem variações desta terminologia; (Teague e Pidgeon, 19851, por exemplo, referem-se
também ao ‘usuário beneficiado», que é o que recebe os beneficios do novo sistema. Essa pessoa
pode não ter qualquer contato direto com o sistema, mas se beneficiará de algum modo com. a
melhora do serviço 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 usuário pergunta rá: “será que ficarei cansado ou vou adquirir tendinite por ficar

Página 61 de 584
sentado frente a um terminal o dia inteiro?”; “devo me preocupar
76
com a emanação de radiação da tela do monitor?”; “e se eu não souber digitar?”; e, ainda mais
importante, «e se esse novo sistema executar o meu serviço e me fizer perder o emprego?
4 No caso extremo, isso também significa que são os usuários opera tivos que podem iniciar ou
parar um novo sistema. Eles podem parecer passivos e talvez não disponham de poder ou
autoridade para aprovar o projeto de desenvolvimento de um sistema, mas se eles o sabotarem ou
simplesmente não o utilizarem, o novo sistema terá fracassado.
5 Observe que essa é uma característica dos sistemas operativos (como o termo foi definido no
capítulo 2), mas geralmente não é uma característica dos sistemas de apoio à decisão. Observe
ainda que a alta direção está habitualmente mais interessada nos sistemas que proporcionarão
vantagem competitiva do que com os que reduzem a equipe operativa a uma ou duas pessoas.
6 Mesmo que todos os usuários que você encontrar não conheçam ou não 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 começaram a brincar com computa dores quando estavam no primário, presumem que
todos devem ser fascinados e hábeis com computadores, e que os que não são assim devem ser ou
deficientes mentais ou pertencentes a uma geração antiga e portanto não merecedora de qualquer
respeito e consideração. No entanto o mundo está cheio de usuários que não gostam de
computadores por vários e legítimos motivos e há usuá rios que estão ocupados demais como
perUos em suas próprias profissões ou negócios para se preocuparem em se tornarem peritos em
computadores. Eles têm sobre programadores e analistas de sistemas a mesma opinião que têm de
eletricistas, carpinteiros, encanadores e mecânicos de automóveis: um saudável respeito pela
perícia e habilidade profissional exigida pelo serviço, mas uma total falta de interesse pelos
detalhes. A compreensão 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ê começaria por conversar com
um arquiteto sobre as desejadas ca racterísticas da casa. Depois de muita discussão, o arquiteto iria
para seu escritório 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
matemáti 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: “faça-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 viável
de se obter a mesma coisa.
8 É também encorajador ver-se que mais e mais desses “peritos” es
tão se transferindo para posições de alta direção de empresas co
merciais e de liderança em outros setores da sociedade. O Citybank

Página 62 de 584
e a American Airlines, para não mencionar várias empresas de
processamento e outras de alta-tecnologia, são dirigidas por pes
soas que galgaram essa posição vindo dos quadros do processa
mento de dados e, em meados da década de 80, havia cerca de
meia-dúzia 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
gerência do projeto. Discutiremos esse aspecto com mais detalhes
no capítulo 16 e no apêndice B.
10 Estudaremos mais detalhadamente o backlog de aplicações no
capítulo 6.
11 Entretanto, pelo menos em alguns casos, isso está se modificando.
Por exemplo, muitas das 8 grandes firmas de contabilidade nos
Estados Unidos estão agora inteiramente familiarizadas com as fer
ramentas de documentação de análise estruturada descritas neste
capítulo; assim, elas não 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 inteligência artifical e os sistemas especialistas
não poderão ser aplicados à análise de sistemas por mais alguns
anos ainda. Este assunto também é abordado no capítulo 25.
13 Discutiremos algumas alternativas a essa abordagem seqüencial,
principalmente as conhecidas como desenvolvimento evolutivo, ou
“fast tracking”, no capítulo 5. Na realidade, em alguns projetos a
análise de sistemas continua em andamento juntamente com a
programação.
14 Na realidade, o contato direto entre o programador e o usuário é
mais comum do que você pode imaginar. Em muitos casos, o ana
lista de sistemas não se esforça em escrever os detalhes do nível
inferior do sistema, e os usuários de alto nível 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 usuário de baixo nível para des

Página 63 de 584
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 são despendidos em testes;
na verdade, pode ser que o trabalho que esteja em andamento sob
78
o título oficial de testes sejam, de fato, tarefas de análise de siste mas que poderiam (e
provavelmente deveriam) ter sido executadas mais cedo.
79
4
FERRAMENTAS
DA ANÁHSE
E STRUTURADA
A Natureza tem algum tipo de sistema coordenado aritmético- geométrico, porque ela tem todas as
espécies de modelos, O que conhe cemos da natureza está em modelos, e todos os modelos da
natureza são muito belos, O que me surpreende é que o sistema da natureza seja de uma beleza
fracionária, porque em química consideramos que as asso ciações são sempre em belos números
inteiros - não e.x frações.
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 não é nada, com
ferramentas ele é tudo.
Thomas Carlyle,
Sartor Resartus, Livro 1, Capítulo 4
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 dicionário de dados.
4. Os componentes de uma especificação 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 usuário deseja. Como veremos neste capítulo, 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 construção de uma nova casa. Os

Página 64 de 584
modelos de análise de sistemas discutidos neste livro são, na maior parte, modelos de papel de
sistemas- em-ser, isto é, representações abstratas daquilo que, eventualmente, se tornará uma
combinação de hardware e software de computadores.
O termo modelo pode soar um tanto formal e amedrontador, po rém, 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: Represcntaçõcs esquemáticas dc decisões e se qüência de atividades para execução
dc algum procedimento.
• Desenhos arquitetônicos: Representações esquemáticas de um edifício ou de uma ponte.
• Pautas musicais: Representações gráficas/textuais das notas mu sicais e tempo de uma peça
musical.
Embora você não saiba como interpretar o modelo arquitetônico mostrado na figura 4.1, o conceito
de tal modelo não deverá assustá-lo. Não é muito difícil imaginar que se pode aprender a ler e a
compreender tal modelo, mesmo que você não pretenda criar algum. Similarmente, você
provavelmente ainda não 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 usuários com quem você
trabalha certamente estarão aptos a interpretar os modelos (com uma pequena assistência inicial) e
deverão, também, ser capazes de criá-los.
Por que devemos construir modelos? Por que não basta apenas construir o sistema? A resposta é
que podemos construir modelos de maneira a realçar ou enfatizar, certos recursos decisivos de um
sistema, enquanto, simultaneamente, relegamos outros aspectos do sistema. Isto permite que nos
comuniquemos com o usuário de uma maneira clara, sem nos distrairmos pelos aspectos e
características do sistema que consideramos irrelevantes. E, se aprendermos que o nosso conheci
mento sobre os requisitos do usuário estava incorreto (ou que o usuá rio mudou de opinião sobre
eles), podemos modificar o modelo ou
82
abandoná-lo e construir um novo, se necessário. A alternativa é enta bular algumas discussões
iniciais com o usuário e, em seguida, construir o sistema inteiro; o risco, certamente, é que o
produto final pode ser ina ceitável e pode ser extraordinariamente caro modificá-lo nessa altura.
Então, o analista de sistemas usa ferramentas de modelagem para:
• Focalizar a atenção nas características importantes do sistema, dando menos atenção ás menos
importantes.
• Discutir modificações e correções nos requisitos do usuário com baixo custo e mínimo risco.
• Verificar se o analista de sistemas conhece, corretamente, o ambiente do usuário 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 descrição

Página 65 de 584
narrativa de 500 páginas dos requisi tos do usuário (que é, na realidade, um modelo) poderá (1)
tornar com pletamente obscuras todas as características do sistema, (2) tornar a construção do
sistema mais cara do que o próprio sistema, (3) falhar na verificação do entendimento do analista
de sistemas sobre as reais neces sidades do usuário. No capítulo 8, exploraremos detalhadamente
que características uma ferramenta de modelagem deve ter para que seja útil ao analista de
sistemas.
ÕÕ-
:
ri
1
Figura 4.1: Um modelo arquitetônico típico
83
Agora, vamos apresentar e discutir resumidamente três important ferramentas de modelagem de
sistemas: o diagrama de fluxo de dados, diagrama de entidades-relacionamentos e o diagrama de
transições estado. O diagrama de fluxo de dados ilustra as jisnções que o sisten deve executar; os
diagramas de entidades-relacionamentos dão ênfa aos relacionamentos de dados, e o diagrama de
transições de esta focaliza o comportamento tempo-dependente do sistema. Os capítulos e 16
exploram essas e outras ferramentas de modelagem com mai res detalhes. Como veremos, as três
principais ferramentas de m delagem consistem em gráficos (figuras) e ferramentas de modelage
textual de suporte. Os gráficos fornecem uma maneira vivida e de fá leitura para o analista de
sistemas mostrar aos usuários os princip componentes do modelo, bem como as conexões (ou
interfaces) entre componentes. As ferramentas de modelagem textual de suporte forn cem
definições precisas ou exatas do s1Rn dos componentes das conexões.
4.1 A MODELAGEM DAS FUNÇÕES 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 não se pode construir um sistema
com êxito sem participação de ambos os componentes. O processamento de um sist ma é,
certamente, um aspecto importante para ser modelado e exarr nado com o usuário. A modelagem
de que estamos tratando pode & descrita de várias maneiras:
• Que funções deve o sistema executar? Quais são as interaçõ entre as funções?
• Que transformações deve executar o sistema? Que entradas si transformadas em que saídas?
• Que espécie de trabalho faz o sistema? Onde ele obtém a info mação para fazê-lo? Para onde ele
remete os resultados do tr:
balho?
A ferramenta de modelagem que usamos para descrever a transfo
mação de entradas em saídas é o diagrama de fluxo de dados. Ui
diagrama de fluxo de dados típico é mostrado na figura 4.2.

Página 66 de 584
Os diagramas de fluxo de dados consistem em processos, d
pósitos de dados, fluxos e terminais:
84
Figura 4.2: Um diagrama defluxo de dados típico
• Processos são mostrados como círculos ou “bolhas” no diagrama. Eles representam as diversas
funções individuais que o sistema
executa. Funções transformam entradas em saídas.
• Flu.xos são representados por setas direcionadas curvas. Elas são as conexões entre os processos
(funções do sistema), e repre sentam a informação que os processos exigem como entrada e/ou as
informações que eles geram como saída.
• Depósitos de dados são mostrados por duas linhas paralelas ou por uma elipse. Eles mostram
coleções (agregados) de dados que o sistema deve manter na memória por um período (tempo).
Quando os projetistas de sistemas e programadores terminam a construção do sistema, os depósitos
existirão, tipi camente, como arquivos ou bancos de dados.
• Terminadores mostram as entidades externas com as quais o sistema se comunica. Os
terminadores são, tipicamente,
indivíduos, grupos de pessoas (p.ex., um outro departamento
85
ou divisão da orgamzação), sistemas externos de computador e organizações externas.
O diagrama de fluxo de dados é discutido em maiores detalhes no capítulo 9 (além de processos,
fluxos e depósitos, o diagrama de fluxo de dados pode também ter fluxos de controle, processos de
controle e depósitos de controle. Eles são úteis para a modelagem de sistemas de tempo-real e são
discutidos em mais detalhes no capitulo 9).
Embora o diagrama de fluxo de dados ofereça uma prática visão geral dos principais componentes
funcionais do sistema, não fornece qualquer detalhe sobre esses componentes. Para mostrar os
detalhes de qual informação é transformada e como é transformada, precisamos de duas
ferramentas de suporte textual de modelagem: o dicionário de dados e a espec de processos. A
figura 4.3 mostra um típico dicionário de dados para o diagrama de fluxo de dados que vimos na
figura 4.2. De modo análogo, a figura 4.4 mostra uma típica 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-intermediário) + último-nome
título-de-cortesia = [
primeiro-nome = Icaracter-válidol
último-nome = lcaracter-válido}
caracter-válido = (A-Zla-zI’I-l I
Figura 4.3: Um dicionáno de dados t4
1. lF a quantia em dólares das faturas vezes o número de semanas devidas for maior do que

Página 67 de 584
$10.000 THEN:
a. Dê uma fotocópia da fatura para o vendedor apropriado que irá chamar o cliente.
b. Anote no verso da fitura que uma cópia 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 fotocópia da fatura ao vendedor adequado para que o cliente seja chamado.
b. Registre no verso da fatura que a cópia foi dada ao vendedor, com a data em que isso foi feito.
c. Recoloque a fatura no arquivo para ser examinada uma semana após essa data.
3. OTHERWISE (a situação ainda não atingiu sérias proporções):
a. Acrescente 1 à contagem da observação de atraso no verso da fatura (se a conta não foi
registrada, escreva “contagem
de fatura atrasada = 1”).
b. IF a fatura no arquivo está ilegível THEN digite uma outra.
c. Envie ao cliente uma fotocópia da fatura, com o carimbo Enésima 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 enésima obser vação de atraso foi enviada.
e. Recoloque a fatura no arquivo por duas semanas a partir dessa data.
Figura 4.4: Uma rípica espec de processos
Ainda existe muito mais a ser dito sobre diagramas de fluxo de dados, dicionários de dados e
especificações de processos; os detalhes constam nos capítulos 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 níveis hierárquicos.
Veremos, também, que existem convenções para a rotulação e numeração 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 funções. A notação de
depósito de dados no DFD nos apresenta a existência de um ou mais grupos de depósitos de dados,
mas, deliberadamente, diz muito pouco acerca de detalhes de dados.
Todos os sistemas armazenam e usam informações sobre o am biente com o qual interagem;
algumas vezes as informações são míni mas, porém na maioria dos sistemas, atualmente, são
bastante comple xas. Não somente queremos saber, em detalhes, que informação está contida em
cada depósito de dados, mas também que relacionamentos existem entre os depósitos de dados.
Esse aspecto do sistema não está realçado pelo diagrama de fluxo de dados, mas está ativamente

Página 68 de 584
retratado por uma outra ferramenta de modelagem: o diagrama de entidades-rela cionamentos. Um
diagrama entidades-relacionamentos típico é mostrado na figura 4.5.
O diagrama entidades-relacionamentos possui dois importantes componentes:
1. T de objetos são apresentados por um quadro retangular no diagrama de entidades-
relacionamentos. Um tipo de objeto representa uma coleção, 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 são representados por losangos no diagrama. Um relacionamento representa
um conjunto de conexões ou as sociações, 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; nós o discutiremos mais detalhadamente no capítulo 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 cessário para aumentar o diagrama
de entidades-relacionamentos com
88
Figura 4.5: Um diagrama de entidades-relaciona nwnjos
detalhadas informações textuais, O dicionário de dados, que vimos pri meiro na figura 4.3, também
pode ser usado para manter informações apropriadas sobre objetos e relacionamentos. Isto será
explorado, mais adiante, nos capítulos 10 e 12.
4.3 A MODELAGEM DO COMPORTAMENTO TEMPO-
DEPENDENTE: O DIAGRAMA DE TRANSIÇÕES DE ESTADO
Um terceiro aspecto de muitos sistemas complexos é o compor tamento tempo-dependente, a
seqüência na qual se tem acesso aos dados e em que as funções serão executadas. Para alguns
sistemas co merciais de processamento, isso não é um aspecto importante para ser destacado, uma
vez que a sequência é trivial em princípio. Desse modo,
89
em muitos sistemas de processamento batch (aqueles que não s on une e nem de tempo-real), a
função N não pode executar sua tarefa até que receba as entradas necessárias; e sua entrada é
produzida como saída da função N-1; etc.
Entretanto, muitos sistemas on-line e de tempo-real, ambos na área de negócios e na área científica
e de engenharia, têm complexos relacio namentos de tempo que devem ser modelados tão
cuidadosamente quanto as funções 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 combinações e seqüências 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

Página 69 de 584
sistema é o diagrama de transições de estado, algumas vezes abreviado como DTE. Um diagrama
típico é mostrado na figura 4.6; ele modela o comportamento de uma máquina de lavar controlada
por computador. Nesse diagrama, os retângulos re presentam os estados em que o sistema pode
estar (isto é, “cenários» ou “situações” reconhecíveis). Cada estado, portanto, representa um perío
do de tempo durante o qual o sistema exibe algum comportamento ob servável; as setas que
interligam os retângulos mostram a mudança de estado ou transições de um esrado para outro.
Associada a cada mudan ça de estado há uma ou mais condições (os eventos ou circunstâncias que
causaram a mudança de estado) e zero ou mais ações (a resposta, saída ou atividade que ocorrem
como parte da mudança de estado). Examinaremos o diagrama de transições de estado em mais
detalhes no capítulo 13.
4.4 A MODELAGEM DA ESTRUTURA DO PROGRAMA:
O DIAGRAMA ESTRUTURAL
Apesar de não o usar muito como analista de sistemas, você deve conscientizar-se de que muitas
ferramentas adicionais dc modelagem são usadas durante o desenvolvimento de um sistema
complexo. Por exem plO, OS projetistas de sistemas costumam usar o diagrama de fluxo de dados,
o dicionário de dados, as especificações de processos, os diagra mas de entidades-relacionamentos
e os diagramas de transições de esta do criados pelo analista de Sistemas para criar uma arquitetura
em software, isto é, uma hierarquia de módulos (algumas vezes citados como sub-rotinas ou
procedimentos) para implementar os requisitos do sistema. Uma ferramenta de modelagem gráfica
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 Itransições de estado
diagrama estrutural típico é mostrado na figura 4.7. Nesse diagrama, cada retângulo representa um
módulo (p.ex., uma sub-rotina FORTRAN, um procedimento PASCAL, um parágrafo ou
subprograma COBOL). As setas que interligam os quadros representam chamadas de módulos
(p.ex., chamadas de sub-rotina ou de procedimentos). O diagrama tam bém apresenta os
parâmetros de entrada passados para cada módulo chamado, e os parâmetros de saída retornados
pelo módulo quando ele termina a sua tarefa e restitui o controle a quem o chamou.

Página 70 de 584
Embora o diagrama estrutural seja uma excelente ferramenta pa ra os projetistas de sistemas, não é
o tipo de modelo que, normalmente, deve ser mostrado ao usuário, porque ele modela um aspecto
da imple mentação do sistema, em vez dos requisitos subjacentes . Discutiremos os diagramas
estruturais novamente no capítulo 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 gráfico descrito neste capítulo focaliza um aspecto diferente de um
sistema: o DFD mostra as funções,
o DER realça 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 típico; por outro lado, essas três visões do sistema devem ser consistentes e
compatíveis entre si.
No capítulo 14, examinaremos algumas regras de consistência que asseguram que os três principais
modelos de sistema, combinados com detalhados modelos textuais são, de fato, consistentes. Por
exemplo, veremos que cada depósito no DFD deve corresponder a um objeto ou a um
relacionamento do DER.
4.6 RESUMO
Os modelos apresentados neste capítulo são, relativamente, sim ples e fáceis de ler. Muito cuidado
foi tomado para fazê-los dessa maneira, pois eles foram concebidos para serem lidos e entendidos
por usuários sem muito treinamento ou preparação. Entretanto, como
92
veremos nos capítulos 9 a 16, é necessário um grande volume de cuida doso trabalho para criar os
diagramas e assegurar que eles sejam repre sentações completas, consistentes e corretas dos
requisitos do usuário.
1. A introdução ao capítulo 4 lista mapas, globos, fluxogramas, dese nhos arquitetônicos e pautas
musicais como exemplos de modelos.

Página 71 de 584
Enumere mais três exemplos de modelos de uso comum.
2. Qual é, no dicionário, a definição de modelo? Essa definição aplica- se aos sistemas de
informações?
3. Por que os modelos são usados no desenvolvimento de sistemas de informações? Apresente três
motivos.
4. Como responder se o usuário lhe dissesse que os modelos são uma perda de tempo e que você
deveria iniciar a codificação?
5. Você acha que uma descrição verbal do usuário 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 capítulo 4 são modelos em papel. Pode você imaginar quaisquer
outras formas de modelos?
8. Os modelos discutidos no capítulo 4 são, em sua maioria, ferra mentas gráficas (isto é, figuras).
Quais são as vantagens do uso de
figuras como ferramentas de modelagem?
9. Você acredita que as ferramentas gráficas de modelagem são sufi cientes para representar os
requisitos de um sistema de informa ções? Por quê?
10. Quem é o responsável pela criação dos modelos necessários à descrição dos requisitos de um
sistema de informações?
11. Os usuários devem criar seus próprios modelos? Se assim for, sob quais circunstâncias?
12. Quais são os três principais objetivos de um diagrama de fluxo de dados?
13. Quais são os quatro principais componentes de um diagrama de fluxo de dados?
14. Observe que os processos de um DFD são representados por cír culos e os terminadores por
retângulos. Você acha que isso seja significativo? E se os processos fossem representados por re
tângulos e os terminadores por círculos?
15. Observe que a figura 4.2 mostra três diferentes processos mas não indica como muitos
computadores participarão do sistema. Isso é importante? Que mudanças seriam necessárias se a
equipe de pro jeto decidisse implementar o sistema com um computador? E com três
computadores?
93
-JÍIIJ
Observe que a figura 4.2 mostra diversos fluxos de dados entre os processos, mas não indica o
meio físico 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
telecomunicações? E se resolvessem transportar os dados de um processo para outro por meio de
fitas magnéticas?
Para que serve o dicionário de dados?
Quem é o responsável pela criação do dicionário de dados? E por sua atualização?

Página 72 de 584
A figura 4.3 mostra a definição de dicionário de dados para um nome. Qual é o significado dos
parênteses, ( ), naquela definição? Para que serve a especificação de processos?
Quantas especificações de processos devem constar de uma com pleta especificação dos requisitos
do usuário?
Quem é o responsável pela criação da especificação de processos? E por sua atualização?
Observe que a especificação de processos mostrada no exemplo do capítulo é um tanto parecida
com um programa. O que você acha da idéia de se utilizar pseudocódigo para se escrever especi
ficações de processos? O que você pensa da idéia de se usar uma linguagem de programação real
como Ada, como muitos já sugeriram - para a especificação de programas? Por que uma lin
guagem de programação seria boa ou má?
Para que serve o diagrama de entidades-relacionamentos? Quais são os três principais componentes
de um DER?
Quantos tipos de objetos são mostrados na figura 4.5? Quantos relacionamentos são mostrados na
figura 4.5?
O DER mostra ao leitor alguma informação relativa às funções executadas pelo sistema?
O DFD mostra ao leitor alguma informação 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 transições de estado? Quais são os componentes de um DTE?
Os DTE são úteis para a modelagem de sistemas de processamen to batch? Por quê?
Para que serve um diagrama estrutural?
Quais são os componentes gráficos de um diagrama estrutural?
O usuário deve ser capaz de ler e entender um diagrama estrutural? Deve-se esperar que o usuário
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.

Página 73 de 584
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 capítulo 3, alguns usuários são mais conhece dores de computadores do que
outros, e alguns usuários têm parti cipação mais ativa no projeto de desenvolvimento de sistemas
do que outros. Se você estiver trabalhando com um usuário que é um membro de tempo integral da
equipe do projeto, ou talvez mesmo o líder do projeto e se o usuário tem algum conhecimento
sobre projeto de sistemas, não existe razão para que não lhe seja apre sentado um diagrama
estrutural. Entretanto, se o usuário estiver interessado apenas em descrever o que o sistema tem de
fazer, provavelmente não estará interessado em examinar um diagrama descrevendo a organização
de sub-rotinas FORTRAN que imple mentarão aqueles requisitos.
95
5
CICLO DE VIDA
DO PROJETO
Todo o erro humano é a impaciência, uma renúncia prematura ao
método, uma ilusória fixação a uma ilusão.
Franz Kafka, Cartas
1. O conceito de ciclo de vida de um projeto.
2. As características do ciclo dc vida do projeto clássico.
3. As diferenças entre projetos clássicos e semi-estrutu rados.
4. Os componentes do ciclo de vida estruturado.

Página 74 de 584
5. As diferenças entre ciclos de vida radicais e conserva dores.
Para sermos analistas de sistemas eficientes, precisamos de algo além de ferramentas de
modelagem; precisamos de métodos. Na ativida de de desenvolvimento de sistemas, os termos
método, metodologia, ciclo de vida do projeto e ciclo de vida do desenvolvimento de sistemas são
usados alternativamente. Na parte III examinaremos detalhadamente os métodos de análise de
sistemas, no contexto mais amplo de método
- conhecido como ciclo de vida estruturado de projeto - para a execu ção de todo o
desenvolvimento de um novo sistema.
Antes da introdução do ciclo de vida estruturado de projeto, é importante examinar o ciclo de vida
do projeto clássico discutido em muitos livros e usados atualmente em muitas organizações de
desenvol vimento de sistemas, principalmente para identificar suas limitações e fraquezas. Esse
exame será seguido por uma breve discussão sobre o
97
cido de vida de um projeto semi-estruturado: um ciclo de vida de pro jeto que inclui alguns, mas
não todos os elementos do moderno de senvolvimento de sistemas. Em seguida, apresentaremos o
ciclo de vida de projeto estruturado, através de uma visão geral mostrando as principais atividades
e como elas se ajustam. Para finalizar, examinare mos, resumidamente, o ciclo de vida de
protoupação popularizado por Bernard Boar, James Martin e diversos fornecedores de linguagens
de programação de quarta geração.
Exploraremos, também, o conceito de desenvolvimento iterativo ou top-down. De modo especial,
apresentaremos a noção de desenvol vimento top-down radical e desenvolvimento top-down
conse7vador.
Dependendo da natureza do projeto de desenvolvimento de sistemas poderá haver razões válidas
para a adoção de uma abordagem em detrimento da outra; na realidade, alguns projetos sugerem
uma combi nação das duas.
5.1 O CONCEITO DE CICLO DE VIDA DE UM PROJETO
Como se poderia esperar, as pequenas organizações de PED ten dem a ser relativamente informais.
Os projetos de desenvolvimento de sistemas são iniciados como resultado de um entendimento
verbal entre o usuário e o gerente do projeto (que pode ser, também, o analista de sistemas, o
programador, o operador de computador e o zelador), e o trabalho se estende desde a análise de
sistemas até o projeto e imple mentação sem muito estardalhaço.
Nas grandes organizações, entretanto, tudo é feito de maneira muito mais formal. As comunicações
entre os usuários, a gerência e a equipe do projeto tendem a ser documentadas por escrito e todos
enten dem que o projeto correrá através de diversas fases até sua prontificação. Mesmo assim é
surpreendente ver as grandes diferenças com que dois gerentes de projetos na mesma organização
conduzem seus respectivos projetos. Na realidade, muitas vezes é deixado a critério do gerente do
projeto a determinação de quais fases e atividades seu projeto será cons tituído e como essas fases
serão conduzidas’.
Recentemente, entretanto, a abordagem utilizada no desenvolvi mento de sistemas começou a se
modificar. Cada vez mais, grandes e pequenas organizações estão adotando um único ciclo de vida
de proje to uniforme - também conhecido como plano de projeto ou metodolo gia de

Página 75 de 584
desenvolvimento de sistemas ou, simplesmente, “o modo como fazemos as coisas por aqui”.
Habitualmente contido em um livro de apontamentos tão volumoso como os manuais comuns que
costumam estar (não 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
organização 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 organização 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 além 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 é desejável. Qual é, então, o propósito de ter-se um ciclo de vida de
projeto? Existem três objetivos principais:
1. Para definir as atividades a serem executadas em um projeto de desenvolvimento de sistemas.
2. Para introduzir consistência entre muitos projetos de desenvol vimento de sistemas da mesma
organização.
3. Para introduzir pontos de verificação para o controle gerencial de decisões.
O primeiro objetivo é parucularmente importante em uma grande organização na qual novas
pessoas constantemente alcançam os cargos de gerenciamento de projetos. O inexperiente gerente
de projeto pode não perceber ou subestimar a signiflcância das fases importantes do projeto se
apenas seguir a intuição. De fato, pode acontecer de os programadores júnior e os analistas de
sistemas não entenderem onde e como seus esforços se ajustam no projeto a menos que recebam
uma descrição correta de todas as fases dele.
O segundo objetivo também é importante em uma. grande empre sa. Nos níveis 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 análise de sistemas de forma diferente do projeto B e o projeto B não prevê uma fase
de projeto de sistemas, como o gerente de segundo ou de terceiro nível 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
gerência de controlar um projeto. Em pro jetos triviais o único ponto de verificação é,
provavelmente, o fim do projeto. Ele terminou a tempo e dentro do orçamento especificado? Ou
mais simplesmente, ele está todo terminado? Observou os requisitos do usuário? Mas, em projetos
maiores, a gerência deve ter vários pontos de
99
verificação intermediários durante o projeto,os quais oferecem as opor tunidades de determinar se o
projeto está fora das previsões e se será preciso obter recursos adicionais. Além disso, um usuário
inteligente também exigirá pontos de verificação em vários estágios 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 é responsável

Página 76 de 584
pelo projeto. Ele não libera o gerente da dificil responsabilidade de tomar decisões, avaliar
alternativas, travar batalhas políticas, negociar com usuários recalcitrantes, levantar o moral de
programadores desanimados ou qualquer das provações e tribulações 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 provável que
os problemas sejam atacados no momento apropriado.
5.2 O CICLO DE VIDA DO PROJETO CLÁSSICO
O tipo de ciclo de vida do projeto usado em muitas organizações hoje difere daquele ao qual
iremos dar maior atenção na parte III. O ciclo de vida do projeto clássico ou convencional é
mostrado na figura
5.1. Todo projeto é executado mediante algum tipo de análise de siste mas, projeto e
implementação, mesmo que isso não seja feito exatamen te da maneira mostrada no diagrama. O
ciclo de vida de projeto usado na sua organização, 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 análise podem ser reunidas em uma só fase (isso é
especialmente comum em organizações
em que qualquer coisa que o usuário queira é considerado viável em princípio).
• Pode não haver uma fase chamada estudo do hardware se for garantido que qualquer novo
sistema pode ser implementado
em um computador existente sem causar sérios 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 à codificação.
Assim, o ciclo de vida de projeto de uma organização individual
100
pode ter cinco, sete ou doze fases, porém, ainda c9ntinuará sendo da variedade clássica.
O que é que de fato caracteriza o ciclo de vida de um projeto como clássico? Duas características
existem: uma forte tendência à implemen tação bottom-up do sistema e a insistência na progressão
linear e se qüencia! entre uma fase e a seguinte.
5.2.1 A Implementação Bottom-Up
O uso da implementação bottom-up é uma das maiores fraque zas do ciclo de vida do projeto
clássico. Como você pode ver na figura 5.1(a), espera-se que os programadores executem todos os
testes de seus módulos primeiro, em seguida o teste de subsistemas e, por fim, o teste do sistema.
Essa abordagem é, também, 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).
Não se conhece a origem dessa abordagem, porém pode ter sido emprestada de indústrias de
fabricação em linha de montagem. A abor dagem de implementação bottom-up é boa para montar

Página 77 de 584
automóveis em uma linha de montagem, mas somente depois que o protótipo tiver sido
completamente corrl,çido ! Infelizmente, muitas organizações de desen volvimento de sistemas
estão ainda produzindo sistemas um-de-cada-ti po, para os quais a abordagem bottom-up tem
várias dificuldades sérias:
• 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, não haverá nada para mostrar ao usuário
exceto uma enorme pilha de listagens de programas - que nada significam para ele!
• Os erros mais triviais são encontrados no início do período de teste e os erros mais sérios são
encontrados no fina!. Isso é quase uma tautologia. Testes de módulos cobrem os erros relati
vamente simples de lógica dentro dos módulos 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 não são os que o programador deseja encontrar no final de um projeto em
desenvolvimento. Tais er ros podem levar à modificação de muitos módulos, 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
orçamento, cronograma
especificação funcional
de
programas
sistema testado
Figura 5.1(a): O cirlo de vida do projeto clássico
102
• A depuração de erros tende a ser extremamente dificil durante os estágios finais dos testes do
sistema. Observe que distingui mos aqui entre teste e depura ção. A depuração é a arte de des cobrir
onde está o erro (e a determinação subseqüente 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 difícil dizer qual o módulo que contém 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 módulos que tenham sido combinados
pela primeira vez. Locali zar o erro é, freqüentemente, o mesmo que procurar uma agulha em um
palheiro.
As necessidades de tempo de computador para testes aumentam exponencialmente durante os

Página 78 de 584
estágios finais dos testes. Mais es pecificamente, o gerente do projeto muitas vezes considera que
necessita de períodos contíguos 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, difícil de se
conseguir 6, o projeto poderá sofrer um atraso.
5.2.2 Progressão Seqüencial
A segunda principal fraqueza do ciclo de vida do projeto ciassico e sua insistência em que as fases
se organizem seqüencialmente uma em seguida à outra. Existe uma tendência natural e humana
para que seja assim. Desejamos ser capazes de dizer que terminamos a fase de análise de sistemas e
que nunca mais teremos que nos preocupar com ela novamente. Na realidade, muitas organizações
formalizam essa noção com um ritual conhecido como congelamento das especificações ou
congelamento dos documentos do projeto.
O único problema com esse desejo de progressão metódica é que ela é completamente irreal! Em
particular, a abordagem seqüencial não permite que os fenômenos do mundo real ocorram com o
pessoal, com a orientação 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 aperfeiçoa mento repetido de
um trabalho imperfeito. Ou a pessoa que revisa o trabalho, em particular, o usuário que reexamina
o serviço do analista de sistemas, pode ter cometido um erro. Ou talvez a pessoa que executa o
trabalho associado a cada fase pode não ter tempo suficiente para terminar, mas pode não querer
admitir esse fato. Esse é um modo polido para se dizer que, nos projetos mais complexos, a análise
e o projeto de sistemas (e os testes de sistema, também) terminam quando alguém de ade que seu
tempo acabou, e não quando você pretende finalizar aquelas atividades!
Outros problemas estão normalmente associados ao ciclo de vida
do projeto clássico seqüencial. Durante muitos meses (ou anos) que se
leva para desenvolver o sistema, o usuário pode mudar de idéia sobre o
104
que o sistema deve fazer. Durante o período que se leva para desenvol ver o sistema, certos
aspectos do ambiente do usuário podem se alterar (p.ex., a economia, a competição ou os
regulamentos do governo que afetam as atividades do usuário).
Uma característica adicional do ciclo de vida do projeto clássico é que ele se baseia em técnicas
ultrapassadas. Isto é, ele não faz uso de projeto estruturado, programação estruturada,
caminhamentos ou qual quer uma das outras técnicas modernas de desenvolvimento Mas, como a
vida do projeto clássico ignora a existência dessas técnicas, não há nada que impeça o gerente do
projeto de usá-las. Infelizmente, muitos programadores, analistas de sistemas e líderes de projeto
de primeiro nível acham que o ciclo de vida do projeto é uma diretriz da orientação da alta direção
e se a direção nada disser sobre o uso de programação estruturada, eles, como meros membros de
projeto e líderes, não serão obrigados a usar abordagens não clássicas.
5.3 O CICLO DE VIDA SEMI-ESTRUTURADO
Os comentários na seção anterior fazem com que a maioria das organizações de PED pareçam
ainda estar vivendo na era do obscurantis mo. Na realidade, tal caracterização é injusta: nem todas

Página 79 de 584
as organizações usam a vida do projeto clássico. Começando no final da década de 70 e no início
da década de 80 houve um crescente reconhecimento de que as técnicas como projeto estruturado,
programação estruturada e imple mentação 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 características ausentes na
abordagem clássica:
1. A seqüência bottom-up de codificação, testes de módulos e testes de sistema é substituída pela
implementação top-down, uma abordagem onde os módulos de alto nível são codificados e
testados em primeiro lugar, seguidos pelos módulos deta lhados de baixo nível. Há, também, uma
forte indicação de que programação estruturada será usada como método real de codificação.
2. O projeto clássico é substituído 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 diferenças óbvias, existem alguns pontos
sutis acerca desse ciclo de vida modificado. Considere, por exemplo, que
a implementação top-down significa que alguma codificação e alguns
105
testes ocorram paralelamente. Isso certamente representa um importante afastamento das fases
seqüenciais que vimos no ciclo de vida clássica! Em particular, pode significar uma realímentação
entre a atividade de codificação e de teste e a de depuração de erros. Quando o programador testa a
versão reduzida de alto nível do sistema, ele pode ser visto resmungando, “Ora, eu não sabia que
essa instrução FRAMMIS de dupla precisão funcionava assim!’ Naturalmente, você pode ter
certeza de que o subseqüente emprego da instrução FRAMMIS de dupla precisão será
completamente diferente.
Talvez mais importante, o uso da implementação top-down leva os implementadores (e os analistas
de sistemas, se eles não abandonaram o projeto nessa altura) a consultar os usuários após as
especificações terem sido cerimoniosamente congeladas. Desse modo, é possível que o usuá rio
aponte erros e equívocos na especificação; o usuário pode até ex pressar o desejo de alterar a
especificação, e se a entrevista acontecer diretamente entre o usuário e o implementador, uma
alteração pode realmente ser efetuada antes que o gerente do projeto saiba o que está acontecendo.
Resumindo, a implementação top-down muitas vezes cau sa a realimentação entre o processo de
implementação e o processo de análise - embora essa realimentação não seja especificamente
mostrada na figura 5.2 e o usuário 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 título de “projeto estruturado” é realmente um esforço manual para corrigir
especificações 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 CAÇÃO FUNCIONAL)
representa uma tarefa que os projetistas tinham de fazer tempos atrás: transformar um documento
narrativo, monolíti co, ambíguo e redundante em um modelo útil, não procedural, para servir como

Página 80 de 584
base na derivação da hierarquia dos módulos que im plementarão os requisitos dos usuários. Em
outras palavras, as pessoas que utilizam projeto estruturado têm presumido, tradicionalmente, que
receberiam uma especificação clássica. Em conseqüência, a primeira tarefa, do ponto de vista
delas, é transformar essas especificações em um pacote de diagramas de fluxo de dados,
dicionários de dados, diagramas de entidades-relacionamentos e especificações de processo.
Este é um trabalho mais dificil do que você possa imaginar; histo ricamente, tem sido uma tarefa
executada no vácuo. Os projetistas, geralmente, tinham pouco contato com o analista de sistemas
que escrevia a longa especificação narrativa e eles, certamente, não tinham contato com o usuário!
106
de testes
projeto
empacota
sistema
Figura 5.2: O ciclo de vida do projeto semi-estruturado
Obviamente, tal situação está pronta para ser alterada. A introdu ção da análise estruturada do tipo
moderno de abordagem de análise de sistemas apresentado neste livro - no contexto, e a expansão
da idéia de realimentação 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
exigências de
orçamento, cronograma
dados de configuração de hardware
especificação funcional
diagramas de fluxo de dados
DE RI VAF DIAGRAR
diagrama estrutural
diagramas de fluxo de dados, especificações de processos, dicionário de dados_-
3.3
PROJETAR MÓDULO
diagr estrul
dados de configuração
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 clássico e o ciclo de

Página 81 de 584
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 três terminais do ciclo de vida do projeto,
como mostrado na figura 5.4. Os terminais consistem em usuários, gerentes e pessoal da operação
(como você de ve estar lembrado, discutimos essas funções no capítulo 3). Eles são indivíduos ou
grupos de individuos que fornecem entradas à equipe do projeto e que são os últimos receptores do
sistema. Eles interagem com as nove atividades que mostramos na figura 5.4. Cada uma das
atividades é resumida nas seções seguintes:
5.4.1 Atividade 1: O Levantamento
Essa atividade é também conhecida como estudo de viabilidade ou estudo inicial das atividades.
Tipicamente, começa quando um usuário solicita que uma ou mais partes de sua atividade sejam
automatizadas. Os principais objetivos da atividade de levantamento são os seguintes:
Ident os usuários responsáveis e desenvolver um “escopo” inicial do sistema. Isso pode envolver a
realização de uma série de entrevistas para ver quais usuário(s) estão envolvidos no (ou afetados
pelo) projeto proposto e quais não estão Pode en volver, também, 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 deficiências no ambiente do usuário. Con sistirá, habitualmente, em uma lista
narrativa simples das fun ções que estejam faltando ou que estejam atuando de modo in satisfatório
no sistema atual. Por exemplo, ela poderia incluir de clarações como as que se seguem:
• O hardware do sistema atual não é confiável, e o fornecedor acaba de entrar em falência.
• Não é possível efetuar a manutenção do software do sistema atual e não poderemos mais
contratar programadores de ma nutenção que concordem em manter software na linguagem de
programação 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 é tão ruim que muitos
clientes desistem, frustra dos, antes de apresentarem seus pedidos.
• O sistema atual é incapaz de produzir relatórios do governo requisitados pelo Tax Reform Act do
ano passado.
• O sistema atual é incapaz de receber relatórios de limite de crédito do departamento de
contabilidade e não pode produzir os relatórios de tamanho médio de pedidos para o departamento
de comercialização.
• Estabelecer metas e objetivos para um novo sistema. Isto pode ser também uma lista narrativa
simples constituída pelas funções
existentes que necessitem ser reimplementadas, novas funções
que necessitem ser acrescentadas, e critérios de desempenho

Página 82 de 584
para o novo sistema.
• Determinar se é possível automatizar o sistema e, se assim for, sugerir alguns esquemas
aceitáveis. Isto envolverá algumas esti mativas grosseiras e aproximadas do cronograma e do custo
de construção de um novo sistema e dos benefícios a serem obti dos;’° ele também envolverá dois
ou mais esquemas (p.ex., o esquema do mainframe, o esquema de processamento dis tribuído etc.).
Apesar da gerência e dos usuários, 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 estágio primitivo do projeto.
• Preparar uma previsão do projeto que será usada para con duzir o restante do projeto. A previsão
do projeto incluirá toda a
informação listada acima, bem como identificar o gerente res ponsável do projeto. Pode descrever,
também, 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 não ser também uma atividade formal. Entretanto, mesmo que
não venha a consumir muito do tempo ou dos recursos o levantamento é uma ativida de crítica: ao
fim, a gerência pode decidir cancelar o projeto se ele não parecer atrativo do ponto de vista
custo/benefício.
Como analista de sistemas, você pode ou não estar envolvido no levantamento. O usuário,
juntamente com os elementos dos níveis apro priados de gerência, 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 usuário muitas vezes solicitará ao analista de
sistemas que se envolva tão logo seja possível.
Nós não discutiremos o levantamento em mais detalhes neste livro. Se você se envolver nessa
atividade, pode achar úteis os apêndices E e C. Para detalhes adicionais, consulte lDickinson,
19811, Core e Stubbe, 19831 e LYourdon, 19881.
111
5.4.2 Atividade 2: Análise de Sistemas
O principal propósito da atividade de análise é transformar as suas duas principais entradas, critério
do usuário e previsão do projeto, em uma especificação estruturada. Isso envolve a modelagem do
ambiente do usuário com diagramas de fluxo de dados, diagramas de entidades- relacionamentos,
diagramas dc transições dc estado e as outras ferra mentas apresentadas no capílulo 4; essas
ferramentas são cobertas em detalhes na parte II.
O processo passo a passo da análise de sistemas (p.ex., as subati vidades da atividade de análise na
figura 5.4) é discutido na parte III. Como veremos, ele envolve o desenvolvimento de um modelo
ambiental (discutido no capítulo 18) e o desenvolvimento de um modelo comportamental
(discutido nos capítulos 19 e 20). Esses dois modelos se combinam para formar o modelo essencial
(discutido no capítulo 17) que representa uma descrição formal do que o novo sistema deve fazer,
in dependente da natureza da tecnologia que será usada para implementar aqueles requisitos.
Em acréscimo ao modelo do sistema descrevendo os requisitos do usuário, um mais cuidadoso e

Página 83 de 584
detalhado conjunto de orçamentos e cál culos de custo-benefício é preparado, geralmente, ao final
da atividade de análise. Isso é estudado em mais detalhes no apêndice C.
Obviamente, como analista de sistemas, isto é onde você poderá gastar a maior parte do seu tempo.
Não há mais nada a dizer sobre a atividade de análise 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 alocação de partes da especifi cação (também conhecida como o
modelo essencial) aos processadores apropriados (UCP e/ou pessoas) e para tarefas apropriadas (ou
jobs, ou partições 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 módulos de programa e
interfaces entre esses módulos para implementar a especificação criada na atividade 2. Além disso,
a atividade de projeto ocupa-se com a transformação 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 mentação do u.suárto. Esse modelo descreve os
problemas de imple mentação que o usuário se sente firme o suficiente para não deixá-los a
112
critério dos projetistas e programadores dos sistemas. Os principais problemas pelos quais o
usuário normalmente está interessado são a es pecificação da fronteira homem-máquina e a
especificação da interface homem-máquina. A fronteira homem-máquina 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-máquina é uma descrição do formato e da seqüência de entradas fornecidas pelos usuá rios
humanos ao computador (p.ex., projetos de tela e ó diálogo on-line entre o usuário e o
computador), bem como o formato e sequência das saídas fornecidas pelo computador ao usuário.
O modelo de implemen tação do usuário é descrito no capítulo 21.
Uma introdução ao processo de projeto de sistemas pode ser en contrada no capítulo 22. Material
adicional pode ser encontrado em lYourdon e Constantine, 19891, IPage-Jones, 19881, Uackson,
19751 e outros.
5.4.4 Atividade 4. Implementação
Essa atividade inclui a codificação e a integração de módulos em um resumo progressivamente
mais completo do sistema final. Desse modo, a atividade 4 inclui a programação estruturada e a
implementação top-down.
Como você pode imaginar, essa é, tipicarnente, uma atividade em que o analista de sistemas não
está envolvido, embora existam alguns projetos (e algumas organizações) onde a análise de
sistemas, o projeto e a implementação são feitos pela mesma pessoa. Esse tópico é discutido em
mais detalhes no capítulo 23.
5.4.5 Atividade 5: A Geração do Teste de Aceitação
A especificação estruturada deve conter todas as informações ne cess para definir um sistema
aceitável do ponto de vista do usuário. No entanto, uma vez que a especificação tenha sido gerada,

Página 84 de 584
o trabalho pode começar na atividade de gerar um grupo de casos de testes de aceitação a partir da
especificação estruturada.
‘Como o desenvolvimento dc testes de aceitação pode ocorrer em paralelo com as atividades de
projeto e implementação, é possível que você possa ser designado para essa tarefa depois dc
terminar o desenvol vimento do modelo essencial na atividade 2. Os testes são discutidos em
maiores detalhes no capítulo 23.
113
ÀÂ
5.4.6 Controle de Qualidade
Controle de qualidade é conhecido também como teste final ou teste de aceitação. Esta atividade
exige como entrada os dados do teste de aceitação 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 não acontece. Um ou mais membros da organização usuária pode assumir a
responsabilidade, ou ela pode ser executada por um grupo independente de testes ou pe lo
Departamento de Controle de Qualidade. Conseqüentemente, não discutiremos a função de
controle de qualidade em qualquer outro detalhe.
Observe, a propósito, 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 nível apropriado de qualidade; isto é o que
chamamos neste livro de controle de qualidade. Observe, tam bém, que é importante executar
atividades de controle de qualidade, através de todas as atividades iniciais para assegurar que elas
estão sen do realizadas em um nível apropriado de qualidade. Desse modo, a atividade CQ deve ser
realizada através das atividades de análise, projeto e programação para assegurar que o analista está
desenvolvendo especi ficações de alta qualidade, o projetista está desenvolvendo um projeto de alta
qualidade e o programador está escrevendo código de alta qua de. A atividade de controle
identificada aqui é meramente o teste final da qualidade do sistema.
5.4.7 Atividade 7 Descrição dos Procedimentos
Por todo este livro nós nos preocupamos com o desenvolvimento de um sistema inteiro - não
somente a parte automatizada, mas tam bém a parte a ser executada por pessoas. Desse modo, uma
das ativi dades importantes a serem realizadas é a geração de uma descrição for mal das partes do
novo sistema que serão manuais, e de uma descrição de como os usuários realmente vão interagir
com a parte automatizada do novo sistema. A saída da atividade é o manual do usuário.
Como se pode imaginar, isso é também uma atividade na qual você poderá se envolver como
analista de sistemas. Embora não a discutamos mais detalhadamente neste livro, você pode
consultar livros técnicos para obter informações adicionais sobre como escrever os manuais do
usuário.
114
5.4.8 Atividade 8: Conversão de Bancos de Dados
Em alguns projetos, a conversão de bancos de dados envolvia mais trabalho (e mais planejamento

Página 85 de 584
estratégico) do que o desenvolvimento de programas para o novo sistema; em outros casos, poderia
não haver qualquer banco de dados a ser convertido. No caso mais geral, essa atividade exige,
como entrada, o banco de dados atual do usuário, bem como a especificação do projeto produzida
pela atividade 3.
Dependendo da natureza do projeto, você poderá ou não se envol ver na atividade de conversão de
banco de dados como analista de sistemas. Entretanto, não discutiremos essa atividade em maiores
deta lhes neste livro.
5.4.9 Atividade 9: Instalação
A atividade final, obviamente, é a instalação. Suas entradas são o manual do usuário 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 instalação pode significar,
simplesmente, uma “passagem” noturna para o novo sistema, sem ne nhuma comemoraçãü ou
fanfarra, em outros casos, a instalação poderá ser um processo gradual, com um grupo de usuários
após o outro rece bendo os manuais do usuário, o hardware e sendo treinado no uso do novo
sistema e realmente começando 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 não é
um fluxograma; não existe implicação que toda a atividade N deva terminar antes do início da
atividade N+1. Ao contrário, a rede de fluxos de dados interligando atividades implica em que
algumas atividades podem ser executadas em paralelo. É por esse aspecto não seqüencial 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 período 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 clássico, tal como o da
figura 5.4, não mostra explicitamente realimentação nem control&’. Virtualmente cada uma das
atividades na figura 5.4 pode produzir e habitualmente produz informações que podem causar
modificações apropriadas a uma
115
ou mais das atividades precedentes. Desse modo, a atividade de projeto pode produzir informações
que têm a possibilidade de causar a revisão de algumas das decisões de custo/beneficio que
acontecem na atividade de análise. Na realidade, o conhecimento obtido na atividade de projeto
pode até exigir a revisão das primeiras decisões sobre a viabilidade bási ca do projeto.
Na realidade, nos casos extremos, certos eventos que acontecem em qualquer atividade podem
causar o término repentino de todo o projeto. A entrada da gerência é mostrada somente para a
atividade de análise por ser a única atividade que necessita de dados da gerência; presume-se,
entretanto, que a gerência exerça controle sobre todas as atividades.
Resumindo, então, a figura 5.4 somente nos informa a(s) entrada(s) necessária(s) a cada atividade e
a(s) saída(s) produzidas. A seqüência de atividades pode estar envolvida apenas na extensão em
que a presença ou ausência de dados torna possível o início de uma atividade.
5.5 IMPLEMENTAÇÃO RADICAL VERSUS TOP-DOWN CONSERVADORA

Página 86 de 584
Na seção 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 situação 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 adoção da abordagem seqüencial, com o término
de toda uma atividade antes do início de uma outra.
É prático ter-se uma terminologia para ajudar na discussão 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 têm lugar em paralelo desde o início do projeto,
isto é, a codificação começa no primeiro dia do projeto e o levantamento e a análise 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 início da atividade
N+1.
Obviamente, nenhum gerente de projeto em seu juízo perfeito ado taria qualquer desses dois
extremos. O que é preciso entender é que os extremos radical e conservador definidos acima são as
duas pontas de um leque de escolhas - isso está ilustrado na figura 5.5. Existe um número infinito
de escolhas entre os extremos radical e conservador. Um gerente de projeto poderia decidir
finalizar 75% da atividade de levanta mento, seguidos pela complementação de 75% de análise de
sistemas, e,
116
em seguida, 75% do projeto, a fim de produzir uma razoável versão reduzida de um sistema cujos
detalhes poderiam ser aperfeiçoados, em seguida, por um segundo passo através do ciclo de vida
do projeto. Ou, o gerente poderia decidir terminar todo o levantamento e a análise, seguida pela
complementação de 50% do projeto e 50% da implemen tação. As possibilidades são
verdadeiramente intermináveis!
ULTRA MODERADAMENTE MODERADAMENTE ULTRA
RADICAL RADICAL CONSERVADORA CONSERVADORA
Figura 5.5: Opções de implementação radical e conseivadora
Como um gerente de projeto decide se adota uma abordagem radi cal ou uma abordagem
conservadora? Basicamente, não há uma resposta
exata. A decisão é habitualmente baseada nos seguintes fatores:
• Quão inconstante é o usuário?
• Qual é a pressão sobre a equipe do projeto para produzir resul tados imediatos e tangíveis?
• Qual é a pressão sobre o gerente do projeto para produzir um cronograma, um orçamento e
avaliação de pessoas e outros
recursos?
• Quais são os perigos de ser cometido um grande erro técnico?
Como você pode perceber, nenhuma dessas perguntas tem uma resposta simples e direta. Por
exemplo, não se pode perguntar ao usuá rio do sistema, em uma conversa casual: «A propósito,
quão inconstante você está hoje?” Por outro lado, o gerente do projeto deve estar apto a avaliar a

Página 87 de 584
situação, com base na observação, especialmente se ele for um veterano que negociou com muitos
usuários e com muitos gerentes de nível superior antes.
Se o gerente do projeto conclui que está tratando com um usuário inconstante - um cuja
personalidade é do tipo que adia as decisões 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 usuário inexperiente, que tenha tido muito pou cos sistemas construídos para ele.
Por que levar anos desenvolvendo um conjunto absolutamente perfeito de especificações somente
para des cobrir que o usuário não entendeu o significado das especificações?
117
Se, entretanto, o gerente estiver tratando com um usuário veterano que está absolutamente seguro
do que quer, e se o usuário trabalha em uma área de negócios estável e que dificilmente se
modificará radicalmente em períodos mensais, então o projeto pode receber uma aborda gem
mais conservadora. Certamente existem muitas situações interme diárias: o usuário pode ter certeza
de algumas funções comerciais a se rem realizadas, mas pode se sentir um pouco inseguro a
respeito dos tipos de relatórios e informações gerenciais que gostaria que o sistema fornecesse. Ou,
se o usuário estiver familiarizado com os sistemas de processamento batch, ele poderia se sentir
inseguro do impacto que um sistema on-line teria na empresa.
Além da inconstância existe um segundo fator a ser considerado: a pressão para produzir resultados
imediatos e palpáveis. Se, devido a pressões políticas ou outras pressões externas, a equipe de
projeto preci sar simplesmente acelerar um projeto e executá-lo em uma data específi ca, então é
recomendável 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 produção. Isto é
normalmente melhor do que ter terminado toda a aná lise de sistemas, todo o projeto e todo o
código, porém nada de testes.
Naturalmente, todos os projetos estão sob alguma pressão por re sultados tangíveis; é simplesmente
uma questão de grau, e é um aspecto que pode ser bastante dinâmico. Um projeto se que inicia com
baixa intensidade, com um cronograma confortável, 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 análise de
sistemas, o projeto, a codi ficação e a implementação top-down é que se pode parar uma atividade
em qualquer ponto e deixar os detalhes restantes para considerações subseqüentes; enquanto isso, a
análise de sistemas de alto nível que te nha sido completada pode ser usada para começar o projeto
de alto nível, e assim por diante.
Outro fator em gerenciamento de projeto é o requisito sempre presente, em organizações maiores,
para produzir cronogramas, avalia ções, orçamentos e coisas semelhantes. Em algumas
organizações, isso tende a ser feito de uma forma consideravelmente informal, tipicamente porque
os projetos são relativamente pequenos e porque a direção sente que qualquer erro de avaliação te’
um impacto insignificante em toda a organização. Nesses casos, po e-se adotar uma abordagem
radical, mesmo que as estimativas sejan apenas adivinhações. 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

Página 88 de 584
levantamento, a análise 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 técnico maior. Por
exemplo, suponha que toda a sua experiência 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 incumbência de desenvolver um sistema de informações gerenciais de banco de
dados distribuído de multipro cessamento de tempo-real on-line que processará 2 milhões de transa
ções por dia, a partir de 5.000 terminais espalhados pelo mundo. Em tais situações, um dos perigos
da abordagem radical é descobrir uma grande falha de projeto depois que uma grande parte do
sistema inicial de alto nível ter sido implementado.
Ele pode descobrir, por exemplo, que para o seu maravilhoso siste ma funcionar, um módulo de
baixo nível tem de executar sua tarefa em 19 microssegundos - porém seus programadores, de
repente, avisam que não existem meios de codificar um módulo tão eficiente - não em COBOL,
nem em C, e nem mesmo em (ugh!) linguagem assembly. En tão, ele deve estar atento ao fato de
que a adoção 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 cenário: 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 alguém que não o fornecedor do hardware) e um novo pacote de
telecomunicações (produzido por um outro fornecedor). Todos os fornecedores têm manuais
atraentes e lustrosos descrevendo seus produtos, mas eles nunca interfacearam seus respectivos
produtos de hardware e software. Quem sabe se eles trabalharão juntos? Quem sabe se a taxa de
desempenho apregoada por um fornecedor será des truída 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 versão inicial do siste ma pudesse ser usada para
explorar possíveis problemas de interface e de interação entre os componentes dos fornecedores.
Se o gerente do projeto estiver na direção de um tipo familiar de sistema, algo assim como o seu
sistema de pagamento, então, provavel mente, terá uma boa idéia sobre quão realistas são suas
metas. É possível que se lembre de seu último projeto, que espécies de módulos irá preci sar no
nível detalhado, e lembrar-se-á com muita clareza de como se parecia a estrutura de sistema de alto
nível. Nesse caso, ele pode estar pretendendo aceitar os riscos de cometer um engano por causa dos
outros benefícios que a abordagem radical vai lhe oferecer.
119
Resumindo, a abordagem radical é mais apropriada para pesquisas e esforços de desenvolvimento
de pouca monta, em que ninguém esteja completamente seguro do que o sistema final deverá fazer.
Também é indicada para ambientes em que alguma coisa deve estar funcionando em uma certa data
e em situações onde a percepção do usuário sobre o que ele deseja que o sistema faça está sujeito a
alterações. A abordagem conservadora, por outro lado, tende a ser usada em grandes projetos, nos

Página 89 de 584
quais quantias maciças de dinheiro podem ser gastas e para os quais sejam necessários análise e
projeto cuidadosos para prevenir desastres subseqüentes. No entanto, cada projeto é diferente e
exige sua própria mistura individual de implementação 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 necessário for.
5.6 O CICLO DE VIDA DA PROTOTIPAÇÃO
Uma variação da abordagem top-down discutida acima tornou-se conhecida há poucos anos atrás.
É 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 definição de requisitos é obter um conjunto inicial de
necessidades e implementá-las rapida mente com a intenção declarada de expandi-las e refiná-las
iterativa mente à proporção do aumento do conhecimento mútuo do sistema por parte do usuário e
do desenvolvedor. A definição do sistema ocorre através da descoberta gradual e evolutiva em
oposição à previsão onisciente... Esse tipo de abordagem é chamada de protoci pação. Ela também
é conhecida como modelagem de sistemas ou desenvolvimento heurístico. Ela oferece uma
alternativa atraente e funcional para métodos de pré-especificação para que se possa lidar melhor
com a incerteza, a ambigüidade e a inconstância dos pro jetos do mundo real”.
Sob vários aspectos, isso se assemelha exatamente à abordagem radical top-down discutida na
seção acima. A principal diferença é que a abordagem estruturada discutida neste livro presume
que, mais cedo ou mais tarde, será construído um completo modelo de papel do sistema (isto é, um
completo conjunto de diagramas de fluxo de dados, diagra mas de entidades-relacionamentos,
diagramas de transições de estado, especificações 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 manutenção e revisão.
A abordagem de prototipação, por outro lado, quase sempre pres supõe que o modelo será um
modelo que funcione, isto é, uma coleção de programas de processamento que simularão alguma
ou todas as fun ções que o usuário deseje. Mas, como aqueles programas de processa mento são
pretensamente apenas um modelo, há também a suposição de que, quando a modelagem estiver
terminada, os programas serão desprezados e substítuídos por programas REAIS. Os
prototipadores normalmente se utilizam dos seguintes tipos de ferramentas de software:
• Um dicionário de dados integrado
• Um gerador de tela
• Um gerador de relatórios não-procedural
• Uma linguagem de programação de quarta geração
• Uma linguagem de consultas não-procedural
• Recursos poderosos de gerenciamento de banco de dados
O ciclo de vida da prototipação proposto por Boar é mostrado na figura 5.6. Ele começa com uma
atividade de levantamento, semelhante à que foi proposta neste livro; segue-se imediatamente uma

Página 90 de 584
determinação se o projeto é um bom candidato para a abordagem de prototipação. Os bons
candidatos para a abordagem de protoupação são projetos que têm as seguintes características:
• O usuário não é capaz ou não deseja examinar modelos abstra tos de papel como diagramas de
fluxo de dados.
• O usuário não é capaz ou não deseja articular (ou “pré-especifi car”) seus requisitos de qualquer
forma e só pode determiná-los através de um processo de tentativa e erro. Ou, como meu cole ga
Bob Spurgeon costuma dizer, essa é a situação onde o usuá rio diz,”Eu não 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 oposição a
sistemas batch de edição, atu alização e emissão de relatórios. (Quase todas as ferramentas de
software da prototipação são orientadas para a abordagem on une dirigida por banco de dados e
orientada para terminais;
121
P1
PRI
NÃO
NÃO
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
protótipos de sistemas batch).
• O sistema não exige a especificação de grandes quantidades de detalhamento algoritmico, isto é, a
escrita de inúmeras especifi cações de processos para descrever os algoritmos pelos quais serão
criados os resultados de saída. Desse modo, o apoio à de cisão, a recuperação ad boc e os sistemas
de gerenciamento de registros são bons candidatos à prototipação. Os bons candida tos tendem a
ser os sistemas nos quais o usuário está mais inte ressado no formato e na diagramação da entrada
de dados por terminal de vídeo e nas telas de saída e mensagens de erro do que na computação
básica realizada pelo sistema.
É importante observar que o ciclo de vida da prototipação 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 protótipo não é feito para um sistema operati vo, ele é feito
unicamente como um meio de modelar os requisitos do usuário.
A abordagem de prototipação certamente tem valor em várias si tuações. Em alguns casos, o
gerente do projeto pode querer usar a abor dagem de prototipação como uma alternativa à
abordagem de análise estruturada descrita neste livro; em outros casos pode querer usá-lo em
combinação com o desenvolvimento de modelos em papel como os diagramas de fluxo de dados.
Tenha em mente os seguintes pontos:

Página 91 de 584
A abordagem top-down descrita na seção anterior é uma outra forma de prototipação, mas ao invés
de usar ferramentas ofere cidas por um fornecedor, tais como geradores de telas e lin guagens de
quarta geração, a equipe de projeto usa o próprio sistema como seu próprio protótipo. Isto é, as
diversas versões de um sistema inicial fornecem um modelo que funciona,com o qual o usuário
pode interagir para obter uma idéia mais rea lista das funções do sistema do que poderia ter com
um modelo de papel.
• O ciclo de vida da prototipação, como descrito acima, envolve o desenvolvimento de um modelo
de trabalho que é, depois, descartado e substituído por um sistema de produção. Existe o
significativo perigo de o usuário ou a equipe de desenvolvimen to tentarem transformar o próprio
protótipo em sistema em pro dução. Isto normalmente se converte em um desastre porque o
protótipo não pode manipular eficientemente grandes volumes
123
de transações, e porque ele carece de detalhes operativos corno recuperação de erros, auditorias,
facilidades de backup/restart, documentação do usuário e procedimentos de conversão.
Se o protótipo for de fato descartado e substituido pelo sistema de produção, existe um real perigo
de que o projeto possa ter minar sem ter um registro permanente dos requisitos do usuário. Isso
provavelmente tornará a manutenção cada vez mais difícil com o passar do tempo (p.ex., dez anos
após o sistema ter sido construído, será difícil para os programadores de manutenção incorporarem
uma alteração, porque ninguém, incluindo os usuários da “segunda geração” que estão agora
trabalhando com o sistema, poderão lembrar-se do que o sistema se propunha a fazer em sua
origem). O ciclo de vida apresentado neste livro é baseado na idéia de que os modelos em papel
desenvolvidos na atividade de análise serão não apenas entradas para a ativida de de projeto, mas
serão também conservados (e modificados, quando necessário) durante a manutenção contínua. De
fato, os modelos podem sobreviver ao sistema que os implementa e podem servir como
especificação para o sistema substituto.
5.7 RESUMO
O principal propósito deste capítulo foi proporcionar uma visão 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 clássico, semi-es
truturado, estruturado ou de prototipação.
Se seus projetos só permitem uma atividade de cada vez, a discus são sobre implementação top-
down radical e implementação top-down conservadora na seção 5.6 pode tê-lo confundido. Esse foi
o meu inten to, porque o principal objetivo daquela seção foi fazer você pensar sobre a
possibilidade de sobrepor algumas das principais atividades de um projeto de desenvolvimento de
sistemas. Evidentemente, é mais difícil 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 esforços em uma atividade
importante de cada vez, haverá sempre algumas subatividades acontecendo em paralelo. Múltiplos
ana listas de sistemas estarão entrevistando múltiplos usuários simultanea mente; várias partes do
produto final da análise de sistemas estarão em diversos estágios de progresso por toda a fase de
análise. Uma das tarefas do gerente de projeto é exercer suficiente controle sobre essas

Página 92 de 584
124
subatividades para assegurar que elas se ajustem à perfeição. E virtualmente em todo projeto de
PED, essa mesma espécie de atividade paralela funciona em nível mais elevado também; isto é, a
despeito do que o ciclo de vida de projeto formal da organização possa ter reco mendado, a
realidade é que muitas das principais atividades do projeto se superpõem em certo grau. Não
obstante, se o gerente de projeto resolver insistir em uma progressão estritamente seqüencial das ati
vidades de projeto, o ciclo de vida do projeto apresentado neste livro continuará válido.
Para maiores detalhes sobre ciclos de vida de projetos, consul te [ 1981] e EYourdon, 19881. O
conceito é também coberto em diversos livros sobre engenharia de software e gerenciamento de
projeto.
REFERÊNCIAS
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:
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 Engineeríng 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
1. Apresente dois sinônimos para metodologia.
2. Qual é a diferença entre uma ferramenta, como usada no conte
deste livro, e uma metodologia?

Página 93 de 584
3. Quais são os três principais objetivos do ciclo de vida de u
projeto?
4. Projeto de pesquisa: encontre o preço de três produtos comercia
de metodologia oferecidos por fornecedores de software ou p
firmas de consultoria.
5. Por que as menores organizações de processamento de dados,
picamente, não 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 são as maiores características que distinguem o ciclo de vi
clássico?
10. O que significa implementação bottom-up?
11. Quais são as quatro maiores dificuldades com a estratégia de ir
plementação bottom-up?
12. Que espécie de ambiente é apropriado para a abordagem de ir
plementação bottom-up?
13. Qual é a importância 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 diferença entre testes e depuração de erros?
16. Por que a depuração de erros é difícil na implementaçi
bottom-up?
17. O que significa a expressão “progressão seqüencial” ao se descr
ver o ciclo de vida de um projeto?
18. Quais são os dois principais problemas da progressão seqüencia
19. Quais são as principais diferenças entre o ciclo de vida clássico e
semi-estruturado?
20. Quais são as duas principais conseqüências da abordagem de ir
plementação top-down?
21. Por que a atividade de projeto no ciclo de vida semi-estruturac
muitas vezes envolve trabalho redundante?

Página 94 de 584
22. Quais são as principais diferenças 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 são os três tipos de pessoas que fornecem as entradas princi pais do ciclo de vida de um
projeto?
25. Quais são os cinco principais objetivos da atividade de levan tamento?
26. O que é um diagrama de contexto?
27. Qual é o principal propósito da atividade de análise?
28. Quais são os tipos de modelos produzidos pela atividade de análise?
29. Qual é o propósito da atividade de projeto?
30. Quais são os dois principais problemas nos quais o usuário está ti picamente interessado na
atividade de projeto?
31. Quando pode se iniciar a geração dos testes de aceitação (atividade 5)?
32. Qual é o propósito da atividade de descrição 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 sinônimo válido para atividade.
35. Por que é importante a realimentação no ciclo de vida de projeto estruturado?
36. Qual é a diferença entre a abordagem conservadora e radical do ciclo de vida de projeto
estruturado?
37. Quais são os quatro principais critérios para escolha da abordagem radical versu.s a abordagem
conservadora
38. Você pode imaginar quaisquer critérios adicionais que poderiam ser usados para escolha de
uma abordagem radical versus uma
abordagem conservadora?
39. Que espécie de abordagem (radical versus conservadora) deveria um gerente de projeto
escolher se houvesse a possibilidade de o
usuário alterar sua opinião sobre os requisitos do sistema?
40. Que espécie de abordagem (radical versus conservadora) deveria um gerente de projeto
escolher se o projeto estivesse sob fortes
pressões de tempo?
41. Que espécie de abordagem (radical versu.s conservadora) deveria um gerente de projeto
escolher se o projeto se defrontasse com
grandes riscos técnicos?
42. Qual é a diferença entre ciclo de vida de prototipação e ciclo de vida radical?

Página 95 de 584
43. Quais as características que tem o projeto de prototipação ideal?
44. Que espécie de ferramentas são tipicamente necessárias usadas em um projeto de prototipação?
45. Por que não são os sistemas batch bons candidatos para projetos de prototipação?
46. Quais são os perigos da abordagem de prototipação?
127
47. Como podem ser usados juntos em um projeto a abordagem de protoupação 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 situações comuns que conduzem a essa abordagem individualista mesmo nas empresas mais
exemplares: (1) a organização altamente descentralizada, onde to do departamento tem seu próprio
grupo de PED com seus próprios padrões locais e (2) o período dc vários anos imediatamente após
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 são o Spectrum (da Spectrum
International Corp), SOM-70 (da AGS Software), e Method/1 (da Arthur Andersen). Não farei
comentários sobre qualquer pacote especifico de gerenciamento de projeto; Apenas sugiro que
você guarde os conceitos apresentados nes te livro se a sua organização usa um pacote adquirido de
um fornecedor.
3 Miller indica em [ 19781 que isso é um fenômeno comumen te observado; de fato, ele o
apresenta como uma “hipótese” geral
aplicável a todos os sistemas vivos:
HIPÓTESE 2-1: Componentes de sistemas incapazes de se associa rem, ou carentes da experiência
que formou tais associações, devem funcionar sob rígida programação ou regras operacionais
fortemente padronizadas. Segue-se que quando a modificação de componentes se coloca acima da
taxa na qual esses componentes podem desen volver as associações necessárias para a operação, a
rigidez da pro gramação aumenta.
4 De fato, a orientação da maioria dos projetos de PED é de que haja apenas um ponto de
verificação em que o usuário tem um caminho óbvio e claro de recuo: ao fim da fase de
levantamento ou de estu do de viabilidade. Teoricamente, contudo, o usuário 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 também pode ser originária da indústria de
hardware de computadores, porque muitos dos primeiros programadores de computador e gerentes
de programação nos anos 50 e 60 eram engenheiros elétricos que se haviam anteriormente
envolvido no desenvolvimento de hardware.
128
6 Estou convencido que ainda há uma outra lei do tipo Murphy que

Página 96 de 584
se aplica nesse aspecto: quanto maior e mais crítico for o projeto
mais provavelmente sua data limite coincidirá com o processamen
to de fim de ano e outras crises organizacionais que consumirão
todo o tempo do computador.
7 Essas técnicas modernas de desenvolvimento serão vistas em forma
resumida no capítulo 7.
8 As técnicas de entrevistas são discutidas no apêndice E.
9 O diagrama de contexto faz parte do modelo ambiental que es
tudaremos em detalhes no capítulo 18. Seu principal propósito,
como indicado aqui, é definir o campo de aplicação 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 cálculos de custo-beneficio são discutidos no apêndice C.
11 Existem, na realidade, maneiras de exibir rcalimentação e controle
em diagramas de fluxo de dados, como veremos no capítulo 9. As
notações complementares (de processos de controle e de fluxos de
controle) são 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 são 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
país.
Abraham Lincoin
Segunda Mensagem Anual ao Congresso
1. Porque a produtividade é um problema importante.
2. As soluções comuns do problema da produtividade.

Página 97 de 584
3. O número dc erros cm um sistema típico.
4. A relação entre a idade de um sistema e o número de erros encontrados.
Como analista de sistemas, você fará parte de uma equipe cujo propósito é desenvolver um sistema
de informações útil e de alta quali dade, que satisfaça as exigências do usuário final. Ao executar
essa tare fa, você e seus companheiros da equipe de projeto serão, sem dúvida, influenciados pelos
seguintes aspectos relevantes:
• Produtividade
• Confiabilidade
• Manutenibilidade 7
131
Naturalmente, todos são a favor da produtividade; este termo é utilizado da mesma forma que
maternidade e lealdade em relação a nosso país. Porém, há uma geração, quando a maioria dos
sistemas ope racionais atuais estavam sendo construídos, produtividade não era algo a que se
prestasse muita atenção. 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 boração de um
sistema completo. A sensação geral era de que a equipe de desenvolvimento de sistemas trabalharia
duramente todos os dias, até que - voil4! Incrível! - o sistema estaria pronto.
Nos dias atuais, a produtividade é algo bem mais sério. O mesmo acontece com a confiabilidade:
uma falha de um sistema grande e com plexo pode ter conseqüências devastadoras. A
manutenibilidade tornou- se um problema importante: hoje é evidente que muitos dos sistemas
recém-construídos levarão 20 anos ou mais até que possam ser refeitos, e precisarão de constantes
revisões e modificações durante seu tempo de vida.
Cada um desses aspectos é analisado mais detalhadamente neste capítulo. Alguns deles, como a
manutenibilidade, podem aparentar ter pouco ou nada a ver com a análise de sistemas, mas, como
veremos, a análise de sistemas tem um papel fundamental na obtenção do aumento da
produtividade e da confiabilidade e de uma melhor manutenibilidade.
6.1 PRODUTIVIDADE: A DEMANDA REPRIMIDA POR
APLICAÇÕES
O problema mais evidente que os profissionais de desenvolvi mento de sistemas enfrentam hoje
talvez seja o da produtividade. Os negócios e a sociedade moderna parecem estar exigindo cada
vez mais sistemas, mais sofisticação, 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 necessário para
a cons trução de cada um deles.
Em quase todas as organizações americanas onde existe um grupo central responsável pelo
desenvolvimento de novos sistemas, existem serviços aguardando há vários anos para serem
executados’. Em realida de, muitas organizações têm um backlog de quatro a sete ou mais anos. O
backlog se constitui de três diferentes tipos de sistemas:

Página 98 de 584
• Backlog visível: são os novos sistemas solicitados oficialmente pelos usuários e que foram
aceitos e tiveram suas verbas
132
aprovadas pelas comissões apropriadas dc gerência. Entretanto, os projetos não foram iniciados por
falta dos recursos neces sários (tais como analistas de sistemas, programadores etc.).
Backlog invisível: são os novos sistemas que os usuários sabem que precisam, mas que não se dão
ao trabalho de solicitar pelas vias “oficiais” porque ainda estão aguardando a prontificação de
projetos do backlog visível.
Backlog desconhecido: são os novos sistemas que os usuários ainda não sabem que precisam, mas
que emergirão logo que sejam terminados alguns dos sistemas dos backlogs visível e
invisível.
Em um clássico estudo sobre a demanda reprimida por sistemas de informações (Alioway e
Quillard, 1982), os pesquisadores Robert Alloway e Judith Quillard, da MIT Sloan School,
descobriram que o back log invisível de novos sistemas era upicamente 5,35 vezes maior que o
visível. Isso indica que o problema da demanda reprimida é muito pare cido com o proverbial
iceberg: apenas uma pequena parte se mantém visível, com um enorme volume oculto sob a água.
Isso, naturalmente, representa um problema importante para a empresa que prepara seu orçamento
e seu planejamento com base apenas na demanda conhecida e visível por seus serviços.
Um segundo aspecto do problema da produtividade é o tempo necessário para desenvolver um
determinado sistema 2 É óbvio que se o projeto médio de desenvolvimento de sistemas puder ser
diminuído de três para um ano, o problema da demanda reprimida desaparecerá rapi damente. A
questão é que os usuários estão geralmente preocupados não apenas com o problema global do
backlog, mas também com o pro blema local da produtividade em relação a um determinado
projeto. Eles receiam que, quando o novo sistema ficar pronto, as condições se terão modificado
tão drasticamente que os requisitos originais terão perdido a importância.
Explicando em outras palavras, um sistema novo muitas vezes está associado a uma oportunidade
comercial percebida pelo usuário, e essa oportunidade freqüentemente tem uma “janela”, um
período de tempo após o qual a oportunidade comercial terá desaparecido e não mais haverá
necessidade do novo sistema.
Existe um terceiro motivo para a preocupação com a produtivida de em algumas organizações:
alguns projetos falham melancolicamen te e são cancelados pela gerência antes mesmo de estarem
prontos. Na realidade, várias pesquisas descobriram que cerca de 25% de todos os projetos em
grandes organizações de SIG (Sistemas de Informações
133
Gerenciais) nunca são terminados. Existem, naturalmente, muitas razões para o fracasso de um
projeto: problemas técnicos, problemas geren ciais, inexperiência da equipe, falta de tempo para ser
feita uma ade quada tarefa de análise e projeto dc sistemas (que normalmente é um problema da
chefia), escasso envolvimento por parte da gerência ou dos usuários. No excelente trabalho de
Robcrt Block, The Politícs ofProjects [ 19801, há um ótimo estudo sobre as razões dos fracassos de
projetos.

Página 99 de 584
O problema da produtividade existe na profissão de desenvolvi mento de sistemas há muito tempo
e muitas empresas estão vigorosa mente buscando meios de reduzir radicalmente o backlog de
aplicações e de diminuir o tempo necessário ao desenvolvimento de um novo siste ma. Entre as
técnicas mais utilizadas estão:
• A contratação de mais programadores e analistas de sistemas. Isso é particularmente comum cm
empresas novas e em expan são (p.ex., organizações resultantes dc fusões, ou novas organi zações
formadas para a exploração dc novos mercados e novos negócios) . Essa abordagem, entretanto,
tem sido evitada nas empresas antigas; na realidade, muitas organizações consideram que já têm
programadores e analistas demais e que a atitude apropriada é torná-los mais produtivos .
• A contratação de programadores e analistas de sistemas mais talentosos, oferecendo-se-lhes
melhores condições de trabalho. Em vez de utilizar um exército de dcscnvolvedores medíocres 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
clássico, levado a efeito em 1968 (tSackman, Erickson e Grant, 19681), documen tou, pela
primeira vez, o fato de que alguns programadores são 25% mais produtivos que outros. Uma forma
extrema dessa idéia é 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 (bibliotecários, ferramentistas, dou tores em linguagem etc.)
prestando apoio a um extraordinaria mente talentoso profissional que se encarrega tanto da análise
de sistemas como Io projeto e da programação do sistema. A maioria das empresas, naturalmente,
não pode construir toda uma organização de des de sistemas em torno de uma pessoa dez vezes
melhoi do que a média . Entretanto, algo
134
existe a ser dito sobre a preparação de uma organização com pessoas duas vezes mais produtivas
do que o analista/programa dor médio, ainda que essas pessoas devam ser pagas em dobro.
Também existe algo a ser dito a respeito de tornar a equipe existente tão produtiva quanto possível,
proporcionando-lhe treinamento atualizado, modernas ferramentas de desenvolvi mento de
software (discutidas detalhadamente mais adiante) e adequadas condições de trabalho 6
Deixar que os usuá rios desenvolvam seus próprios sistemas. É interessante observar que muitos
outros avanços tecnológicos interpõem alguém entre o usuário e o dispositivo tecnológico; dois
exemplos evidentes desse fato são o motorista e a telefo nista. É claro que a maioria entre nós não
tem motorista nem precisa da telefonista para fazer nossas ligações; o automóvel e o telefone são
sufkientemente amistosos ao usuário para que os possamos operar por nós mesmos. De modo
semelhante, a combinação de computadores pessoais, centros de informação e linguagens de quarta
geração, introduzidos cm muitas organi zações americanas em meados da década de 80, tornou
possível para muitos usuários (inclusive, como vimos no capítulo 2, uma geração de usuários que
aprendeu os fundamentos da compu tação no segundo grau ou na faculdade) o desenvolvimento de
suas próprias aplicações mais simples. Relatório Ad Hoc, consul tas a bancos de dados, aplicações
de planilhas eletrônicas e determinadas modificações de manutenção de programas exis tentes
estão entre os projetos que um motivado usuário, en tendido em computação, pode certamente
fazer por si mesmo.

Página 100 de 584
Melhores linguagens de programação. As linguagens de progra mação sofreram enormes
modificações 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 geração de linguagens
de máquina deu lugar à segunda geração 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 geração começaram a prevalecer nos anos 70 e permanecem
como o mais comum tipo de linguagem atualmente. Os exemplos sãO: COBOL, FORTRAN,
BASIC, Pas cal, C, MODULA-2 e Ada. Enquanto a indústria de software con tinua a melhorar
essas linguagens (a versão do FORTRAN hoje disponível é imensamente melhor que a versão
utilizada pelos programadores no início dos anos 70), boa parte do enfoque
135
transferiu-se para as novas linguagens de prograrilação de quarta geração que eliminam a
necessidade de o programador se preocupar com os confusos detalhes, consumidores de tem po, de
edição e validação das entradas, formatação de relatórios e manipulação de arquivos; exemplos
dessas linguagens são FOCUS, RAMIS, MAPPER E MARK V (e também linguagens como PC-
FOCUS, dBASE III E Rbase-5000 para computadores pessoais). Muitos argumentam que essas
novas linguagens po dem aumentar a produtividade da programação por um fator igual a dez.
Entretanto, como a programação 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 manutenção. A manutenção é um grande problema na área do
desenvolvimento de sistemas, como veremos na seção 6.4. Contudo, a atenção maior está sempre
focalizada (como era de se esperar) na manutenil,ilidade dos novos sistemas; enquanto isso, como
já foi mencionado, muitas empresas estão destinando 50 a 75% de seus recursos para a manutenção
dos sistemas anti,ços. Portanto, a questão :
o que pode ser feito para tornar mais fácil a manutençao dos sis temas antigos, além da idéia óbvia
de jogá-los fora e substitui-los por outros? Uma abordagem cuja popularidade vem aumen tando é
a da restruturação - a conversão mecãnica dos pro gramas antigos (cuja lógica já foi tão remendada
e modificada que muitas vezes está totalmente ininteligível) em programas novos, bem organizados
e estruturados Uma idéia relacionada com isso é o emprego de pacotes automatizados de documen
tação que podem produzir listagens de referências cruzadas, dicionários de dados, fluxogramas
dctalhados,diagramas estrutu rais ou fluxogramas de sistemas diretamente a partir do pro grama
(isso é citado por alguns componentes da manutenção como engenharia invertida). Outra
abordagem, já mencionada, é encorajar os usuários a fazerem suas próprias modificações de
manutenção 8 e uma outra é documentar cuidadosamente a natureza especifica da tarefa de
manutenção; isso muitas ve zes demonstra que apenas 5% do código de um sistema ope racional
são responsáveis por 50% ou mais do trabalho de manutenção.
• controles de engenhana de Software. Outra maneira de melho rar a produtividade é realizada
através de uma coleção de fer ramentas, técnicas e controles geralmente conhecida como
136
engenharia de software ou técnicas estruturadas. Incluem-se aí a programação estruturada, o
projeto estruturado e a análise estruturada bem como os controles relacionados, como as métricas

Página 101 de 584
de software, as provas de correção de programas e o controle de qualidade de software. Em geral,
as técnicas estruturadas têm 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 utilização das técnicas
estruturadas têm geralmente custo de manutenção subs tancialmente inferior e confiabilidade
maior, muitas vezes por um fator igual ou maior que 10. Isso leva à liberação de recursos que, de
outra forma, seriam utilizados em manutenção ou elimi nação de erros, melhorando, assim, a
produtividade geral da organização.
• 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 informações é, ironicamente, exe cutado de forma manual. Assim como
os filhos do sapateiro são os últimos a ganharem sapatos, os programadores e analistas de sistemas
têm tradicionalmente sido os últimos a se beneficiarem da automatização de suas tarefas. É
evidente que alguém pode lembrar que um compilador é uma ferramenta automatizada para a
programação, assim como os pacotes de testes e os auxílios à eliminação de erros oferecem alguma
automatização. Mas, até recentemente, pouca ajuda automatizada existia para o projetista de
sistemas e quase nada havia para o analista. Agora existem terminais gráficos 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 capítulo 4. Essas ferramentas
automatizadas tam bem desempenham várias atividades de verificação de erros, assegurando, desse
modo, que a especificação produzida pelo analista de sistemas fique completa, sem ambigüidades e
inter namente consistente. Além disso, em alguns casos, as ferramen tas automatizadas podem até
gerar código diretamente da especificação, eliminando, dessa forma, a atividade manual da
programação. Os detalhes dessas ferramentas automatizadas para análise de sistemas são
examinados no apêndice A.
Muitas dessas abordagens sobre produtividade podem ser usa das em conjunto porque envolvem
conceitos e técnicas 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 organização 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 núme ro de fatores de produtividade
podem ser encontrados em [ 1986].
Como analista de sistemas, sua reação a tudo isso poderia ser: “E daí? Qual a importância disso?”.
Na verdade, parece que muitos dos problemas de produtividade estão na área da programação, dos
testes e da manutenção e nenhum deles na área da análise de sistemas. Não obstante, existem três
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, também, ter forte efeito no
volume de tempo gasto em testes, uma vez que 50% dos erros (e 75% do custo da eliminação de
erros) de um sistema estão, habitualmente, associados a erros do analista de sistemas. Os

Página 102 de 584
programadores podem ser acusados pela baixa produtividade por causa do tempo que eles gastam
em testes, porém isso é muitas vezes um indício da baixa qualidade do serviço feito pelo analista
de sistemas.
2. Algumas das técnicas de produtividade - maior número de pes soas, melhores profissionais,
melhores condições de trabalho e, principalmente, ferramentas automatizadas - têm direta
importância 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 análise dc sistemas é um problema politica mente sensível, porque muitas
vezes parece ao usuário (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 análise do
sistema; freqüentemente ouve-se o comentário: “Quando vocês começarão a escrever os
programas? Não podemos ficar sentados para sempre falando sobre o sistema, precisamos que ele
seja implementado!”, e ao produto da análise do sistema, a especificação funcional, é dado muito
pouco valor. A reação às especificações algumas vezes será: “Para que servem todas essas figuras e
palavras? Nós já ex plicamos o que queremos que o sistema faça, para que escre veram tudo isso?”.
138
O fato é que não se pode construir com sucesso um sistema manu tenível e de alta qualidade se não
se souber precisamente com o neces sário detalhamento o que deve ser feito. Assim, embora alguns
usuários e gerentes possam reclamar que a análise de sistemas é meramente um período “de
repouso» até ser iniciado o verdadeiro trabalho do projeto (a programação), o certo é que isso deve
ser feito com cuidado e rigor, mas também deve ser realizado com tanta eficiência e produtividade
quanto possível; dessa maneira, o analista de sistemas não deve considerar que a produtividade seja
apenas um problema de programação!
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 depuração 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 aceitáveis se os resultados
forem sistemas altamente confiáveis e de fácil manutenção. A evidência dos últimos trinta anos é
justamente o oposto: os sistemas produzidos pelas empresas em to do o mundo estão cheios de
erros e são quase impossíveis de serem modificados.
“Cheio de erros” tem significados diferentes para pessoas diferen tes. O software desenvolvido nas
empresas americanas tem, em média, de três 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 três a cinco erros em cada
10.000 sentenças de programa, da época do projeto do superprogramador da IBM ( 1972]). Hou ve,
ainda, algumas informações pessimistas, como em [ 19851, relatando que o software americano
pode ter de três a cinco erros para cada dez sentenças!
Os erros de software vão do sublime ao ridículo. Um erro trivial pode consistir de uma saída
(resultado) correta, mas não impressa ou formatada tão correta ou arrumadamente como queria o
usuário. Um erro de software moderadamente sério pode se constituir dc um caso em que o sistema

Página 103 de 584
se recusa a aceitar certos tipos dc entradas, mas que o usuário final consegue um meio de contornar
o problema. Os erros sérios são os que fazem o programa parar de ser processado, com perda
considerável de dinheiro ou de vidas humanas. Entre os exemplos de erros sérios relativos a
software que foram documentados através dos anos incluem-se os seguintes:
139
• Em 1979, o sjstema SAC/NORAD (Strategic Air Command/ North American Air Defense -
Comando Aéreo Estratégico/ Defesa Aérea Norte-Americana) registrou cinqüenta alertas fal sos,
inclusive um ataque simulado cujas saídas provocaram aci dentalmente a decolagem de
interceptadores.
• Um erro no programa de simulação de vôo do F16 fazia com que o avião virasse de cabeça para
baixo sempre que cruzava a
linha do equador.
• O míssil de um F18 disparou quando ainda estava preso ao avião, fazendo-o perder cerca dc
6.500m de altitude.
• As portas do trem do sistema São Francisco BART, controlado por computador, às vezes se
abrem durante longas travessias
entre estações.
• Um alerta NORAD do Ballistic Missile Early Warning System (BMEWS) detectou a Lua como
um míssil que se aproximava.
• O Stock Index de Vancouver perdeu 574 pontos em um período 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 vôo da Air New Zealand es patifou-se contra uma montanha;
investigações posteriores de monstraram que um erro nos dados de rumo do computador tinha sido
detectado e corrigido, mas isso não tinha sido infor mado ao piloto.
Infelizmente, a lista vai muito além; veja exemplos em [ 19851. Muitos outros erros de software
nunca foram divulgados porque a pessoa ou empresa “culpada” prefere não admitir publicamente o
fato. Quando este livro estava sendo escrito, havia uma idéia generali zada de que erros desse tipo
poderiam conduzir a conseqüências desagradáveis para o programa Star Wars do Departamento de
Defesa dos EUA, ou para alguns dos principais sistemas complexos de defe sa aérea controlados
por software; veja análises 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 média
dos sistemas desenvolvidos nos Estados Unidos, ele ainda poderia conter 10.000 erros - uma
perspectiva nada tranqüilizado ra quando um desses erros pode causar a eliminação da vida neste
planeta!
140
Em muitos casos, ninguém 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
documentação e egistro de erros é tão relaxado que a metade dos erros encontrados não divulgada’
nem mesmo dentro da organização de desenvolvimento de ;istemas. Em todos os casos, a atividade
típica de descoberta de erros, m um período de vários anos de vida útil de um sistema de software

Página 104 de 584
: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 usuários finais pela pri rneira vez, eles muitas vezes não estão capacitados a
colocá-lo em total produção, levarão algum tempo para converterem o sistema antigo (que talvez
fosse um sistema manual) e para treinarem a equipe operativa. Além disso, ainda estarão um tanto
receosos do computador, e não vão querer exigir muito da máquina, de modo que poucos erros
serão 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 máquina, começarão a
exigir mais do software, e mais erros serão encontrados “. Naturalmente, se isso prosseguisse inde
finidamente - mais e mais erros descobertos a cada dia - os usuários provavelmente deixariam de
usar o software e o jogariam fora. Na maioria dos casos, os programadores vão freneticamente
corrigindo os novos erros á proporção em que são descobertos pelos usuários. Normalmente, chega
um dia em que o sistema começa a se estabilizar e os usuários encontram cada vez menos erros.
Há três aspectos negativos na figura 6.1. Em primeiro lugar, a curva
nunca atinge o zero, isto é, quase nunca encontramos uma situação 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 função do tempo
Tempo decorrido
141

Página 105 de 584
área sob a curva, que representa o número total de erros enconhtauos em relação ao tempo, é
demasiadamente grande - a média é de três a ci co erros para cada 100 sentenças de programa. E,
em terceiro lugar, a curva por vezes sobe de novo - de modo geral após alguns anos, mas, às vezes,
depois de apenas alguns meses. Ocasionalmente, todos os sistemas de software atingem a situação
de uma colcha de retalhos, quando qualquer esforço para corrigir um erro introduz dois novos
erros, e as modificações necessárias para corrigir esses novos erros provocam quatro outros erros, e
assim por diante.
Existe um último problema acerca de erros de software: eles não são fáceis de serem corrigidos.
Quando alguém, o programador, o usuá rio final ou algum outro intermediário, percebe que o
software não 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 operação do sistema. Isso não é 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 sentenças
do programa (veja EYourdon, 19861).
6.3 MANUTENIBILIDADE
A correção de erros é um dos aspectos da manutenção. Lientz e Swanson ( e Swanson, 1980])
descobriram que os erros respon diam por aproximadamente 21% do esforço geral de manutenção
nas empresas americanas de processamento de dados A manutenção está também vinculada à
modificação deum sistema em conseqüência de alterações no hardware, às modificações para
acelerar certos aspectos operacionais do sistema e às modificações face a alterações dos requisi tos
do sistema introduzidas pelo usuário.
A manutenção de softwre é um importante problema para a maioria das empresas; de 50 a 80% do
trabalho realizado na maior parte das organizações de desenvolvimento de sistemas estão
associados à revisão, à modificação, à conversão, ao aperfeiçoamento ou à depuração de um
programa que alguém escreveu tempos atrás. E esse é um trabalho caro. No princípio dos anos 70,
o Departamento de Defesa dos EUA relatou que o custo de desenvolvimento de programas de
processamento de um projeto atingia em média $75 por instrução e o custo da manutenção do
sistema atingia $4000 por instrução.
Em termos mais expressivos, considere os seguintes exemplos
oriundos da U.S. Social Security Administration:
142
• O cálculo do aumento do Custo de vida para 50 milhões de Cida dãos 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
dígitos de verificação para seis, foram necessários 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 manutenção da Social Security es tava tão baixo em determinada
ocasião que um dos programa dores foi pilhado quando urinava em uma unidade de disco na sala

Página 106 de 584
do computador. Embora isso seja uma nova maneira de desafogar a frustração, não é muito
aconselhável para a unidade de disco.
O resultado de tudo isso, em um número sempre crescente de organizações de processamento de
dados, é que os sistemas desenvolvi dos há 10 ou 20 anos simplesmente não podem ser
modificados para satisfazer as novas exigências do governo, da economia, das condições climáticas
ou da inconstância do usuário. À proporção 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
estagnação do software, a empresa ou sociedade atendida por esse software também fica estagnada.
O problema é ainda pior do que isso. Se fosse apenas o caso de o software não ser bom, poder-se-ia
dispensá-lo e substitui-lo. Porém muitas empresas nunca capitalizaram o software (os custos são
gastos a cada ano), e a política de contabilização e de comércio torna proibitiva- mente cara a
substituição dos sistemas antigos. Existe outro problema ainda mais fundamental: na maioria das
organizações não há uma descri ção coerente do que os sistemas devem fazer. A documentação por
ventura existente é quase sempre obsoleta e confusa, oferecendo, quando muito, algumas idéias de
como o software funciona, mas não de qual seja seu propósito ou de qual doutrina comercial ele se
propõe a implementar.
Assim, mesmo que alguém possa argumentar que a manutenibili dade seja função da
implementação (isto é, algo da competência do programador), é impossível mantoc um sistema se
não existir um modelo acurado e atualizado dos requisitos do sistema. Isso, afinal de contas, é da
responsabilidade do analista de sistemas; como veremos no capítulo
143
8, as especificações funcionais desenvolvidas pelos analistas de sistemas progrediram
gradualmente de novelas vitorianas (milhares de páginas de texto) de manutenção absolutamente
impossível para modelos gráficos, do sistema, desenhados à mão e para modelos gerados e
mantidos pelo computador. No capítulo 24 também será discutido o problema da ma nutenção
contínua das especificações do sistema.
6.4 OUTROS PROBLEMAS
Com que tem o analista de sistemas de se preocupar, além 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 compõe do seguinte:
• Eficiêncta. Um sistema deve funcionar com uma adequada taxa de desempenho (habitualmente
medida em transações por segundo) e com um tempo de resposta aceitável para os termi nais on-
line. Isso normalmente não é um problema com que o analista de sistemas deva se preocupar, uma
vez que os projetis tas e os programadores terão a maior parte da influência na eficiência 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 também não costuma ser um problema da alçada do
analista de sistemas, embora ela ou ele possam precisar especificar a necessidade da portabili dade

Página 107 de 584
no modelo de implementação.
• Segurança. Como os modernos sistemas de processamento têm acesso cada vez mais fácil (cm
face da tendência dc serem on une), e como são responsáveis pelo crescente gerenciamento dos
ativos mais importantes das empresas, a segurança vem tor nando-se uma importante preocupação
em muitos projetos de desenvolvimento de sistemas: o novo sistema deve impedir acessos não-
autorizados assim como a atualização e o apaga mento não-autorizados de dados importantes.
144
6.5 RESUMO
Vários especialistas predizem que a proporção preço/desempenho do hardware dos computadores
será melhorada por um fator igual a 1000 e talvez por 1 milhão, dentro dos próximos 10 a 15 anos.
Infeliz mente, a história do desenvolvimento de software nas últimas três déca 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 não pode ser considerada aceitável. Em toda a indústria do processamento, existe
um esforço maciço e organizado para a obtenção de melhoras relevantes no processo de
desenvolvimento de software.
As técnicas de análise de sistemas apresentadas neste livro fazem parte desse esforço. Como
vimos, parte do esforço é problema da pro gramação e do projeto do sistema, porém a boa
especificação é a base, a pedra fundamental, sobre a qual se apóiam o projeto e a programação.
REFERÊNCIAS
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”, Communicatíons 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, páginas 188-190.
4. F.T. Baker, “Chief Programmer Team Management of Production Programming”, IBM Systems
Journal, Volume 11, Número 1 (janei ro de 1972), pgs. 56-73.
5. H.D. Mills e F.T. Baker, “Chief Programmer Teams”, Datamation, Volume 19, Número 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:
7. Bennett P. Lientz e E. Burton Swanson, Software Maintenance Management. Reading, Mass:
8. T. Capers Jones, Programming Produclivity. Nova lorque:

Página 108 de 584
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, março 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 Engineerín,g Notes,
janeiro de 1985.
14. Jonathan Jacky, “The Star Wars Defense Won’t 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 número 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.
1. Examine o relatório financeiro de uma grande empresa pública 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 pública 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 são os três 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 são os três tipos de backlog que podem ser encontrados em uma empresa típica?
6. Projeto de Pesquisa: efetue um levantamento em sua empresa para determinar a extensão do
backlog de desenvolvimento de sistemas.

Página 109 de 584
Esse conceito é bem conhecido entre os usuários de sua empresa?
146
7. Qual é a diferença entre o backlog visível e o invisível?
8. Por que existe o backlog desconhecido?
9. Por que o backlog invisível parece ser muito maior do que o visível?
10. Quais são as sete soluções 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 prática para o problema
da produtividade? Quais são as vanta gens e desvantagens?
13. Você considera prático resolver o problema da produtividade pela contratação de
programadores ou analistas de sistemas mais talen tosos? Por quê?
14. Imagine que existisse um programador dez vezes mais produtivo que um programador médio
que ganha $25.000 por ano. Você acha que os diretores de uma empresa típica estariam dispostos a
despender $250.000 por ano com aquele programador talentoso? Você acha que eles deveriam estar
dispostos? Por quê?
15. Você considera prático resolver o problema da produtividade per mitindo que os usuários
desenvolvam seus próprios sistemas?
Quais são as vantagens e as desvantagens?
16. Que tipos de projetos de desenvolvimento de sistemas são mais adequados para serem
desenvolvidos pelos próprios usuários? Qual é a percentagem de projetos que podem ser incluídos
nessa categoria em uma empresa típica?
17. Você considera prático utilizar novas linguagens de programação, de terceira geração, como
Ada, ou de quarta, como Focus, RAMIS e NOMAD, para resolver o prblema da produtividade?
Quais são as vantagens e desvantagens dessa abórdagem?
18. Projeto de Pesquisa: qual seria a melhora da produtividade em sua empresa nos próximos cinco
anos se fosse iniciada a utilização de
uma nova linguagem de programação?
19. Por que as linguagens de quarta geração permitem uma melhora da produtividade maior do que
as linguagens convencionais de tercei ra geração?
20. Qual seria a melhora da produtividade em uma empresa típica se a manutenção pudesse ser
reduzida por um fator de dez?
21. Projeto de Pesquisa: use um produto comercial tipo “structuring engine” (dispositivo de
estruturação) para reestruturar um progra ma existente em sua empresa e meça a redução dos
custos de manutenção. O que isso representa em relação aos potenciais benefícios de um
dispositivo de estruturação?

Página 110 de 584
147
22. Você acha que a reestruturação pode transformar programas ruins
em bons? Por quê? Se você respondeu não, explique qual é o pro
pósito da reestruturação de programas.
23. Podem os usuários executar a manutenção de seus próprios pro
gramas? O que é necessário para que isso possa ser feito? Qual a
percentagem do serviço de manutenção de software que você, de
forma realista, considera que os usuários 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 típico gasto em testes e depuração
de erros?
28. Projeto de Pesquisa: qual é o número médio de erros nos sistemas
desenvolvidos em sua empresa? Qual é a varlância - a diferença
entre a pior observação 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 milhão. Como essas falhas poderiam ter sido evitadas?
30. Por que o número de erros de um sistema tende a aumentar de
pois que o sistema é posto em operação pela primeira vez?
31. Por que o número 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
nização de desenvolvimento de sistemas que é gasto com a manu
tenção? A alta direção de sua empresa está ciente desses números?
33. Que fatores, além da produtividade, qualidade e confiabilidade são
importantes nas organizações típicas de desenvolvimento de soft
ware hoje?
34. Qual é o papel desempenhado hoje pelo analista de sistemas na

Página 111 de 584
determinação da eficiência de um sistema de informação?
determinação da portabilidade de um sistema de informação?
determinação da segurança de um sistema de informação?
NOTAS
1 As conversas informais que tive com gerentes de PED no Canadá,
na Europa, na Austrália, na América do Sul e em várias outras
148
partes do mundo me fazem acreditar que esse problema não é, de forma alguma, restrito aos
Estados Unidos.
Para dar uma idéia do alcance desse problema, Capers Jones con cluiu, em uma pesquisa em
aproximadamente 200 grandes empre sas americanas, que o projeto típico estava um ano atrasado e
100%
acima do orçamento. Veja Ijones, 1986].
3 Um bom exemplo disso ocorreu em meados da década de 80
quando alguns países liberaram os bancos e a atividade de compra e venda de estoques. Austrália,
Japão e Inglaterra estão entre os países que subitamente se viram com dúzias de novos bancos e
empresas comerciais estrangeiras abrindo as portas para o comér cio. Londres foi talvez o caso
mais evidente, com a liberação (Big Bang) de 27 de outubro de 1986. Essas atividades exigiram o
de senvolvimento de grandes sistemas novos de informação, o que ge ralmente era conseguido pela
contratação de tantos programadores e analistas quantos fossem possíveis, no menor tempo que se
pudesse.
4 Isso contraria a sombria previsão da redução do número de progra madores a nível nacional
emitida pela U.S. Comrnerce Department
and the National Science Foundation. Para maiores detalhes veja o
capítulo 28 de [ 1986].
5 Para uma análise detalhada sobre a razão de o conceito de super-
programador não ser prático para a maioria das empresas, veja
Managing the Structured Technlques jYourdon, 1988D.
6 Uma interpretação óbvia de condições adequadas de trabalho é dar
a cada membro de um projeto de desenvolvimento de sistemas um escritório privativo, ou um
escritório para cada duas pessoas ou um compartimento à prova de som, que ofereça privacidade e
concen tração - isso tende a melhorar a produtividade do analista/progra mador em 10% ou mais,
em comparação com o que trabalha em uma ampla sala aberta, com som vindo do teto. Outra
interpretação é deixá-los trabalhar em casa. Para mais detalhes sobre esse concei to, a “casa
eletrônica”, veja o capítulo 3 de [ 1986].

Página 112 de 584
7 Existem diversos produtos comerciais nessa área. Entre os mais co nhecidos estão Superstructure
da Group Operations, Inc.; Struc tured Retrofit, comercializado por Peat, Marwick; e Recorder, da
Language Technology, Inc.
8 Isso tem uma importância especial, porque, de acordo com um es tudo em [ e Swanson, 1980],
aproximadamente 42% da ativi dade de manutenção em uma empresa típica consiste em ‘aperfei
çoamentos do usuário”, em contraste com 12% de ‘reparos emer genciais de programas”, 9% de
‘depurações rotineiras”, 6% de “acomodações às alterações de hardware” etc. Da parte despendi da
em aperfeiçoamentos do usuário, 40% referem-se à inclusão de
149
novos relatórios, 27% são gastos com o acréscimo de dados a
relatórios já existentes, 10% são gastos com a reformatação de rela
tórios sem alterações de conteúdo e 6% com a consolidação dos
dados de relatórios existentes e linguagem de programação de
quarta geração, é muito provável que muitas (senão todas!) dessas
modificações relativas a dados possam ser feitas diretamente pelo
usuário.
9 A abordagem de análise de sistemas discutida neste livro represen
ta a forma atual da análise estruturada. Como veremos no capítulo
7, algumas modificações ocorreram desde que a análise 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, exceções a esse faseamento gradual, mor
mente quando o novo sistema tem de receber todo o volume de
serviço (transações) do sistema antigo de uma só vez. Veja em
[ 19841 um interessante exemplo de um projeto desse gêne
ro, no qual um sistema dinamarquês de comércio em âmbito nacio
nal foi convertido para um novo sistema.
12 Como a indústria da computação representa aproximadamente 8 a
10% do GNP americano, isso significa que eles estão gastando cer
ca de $75 per capita por ano em manutenção de software.
13 Existem algumas exceções a essa otimista afirmativa. No caso de
certas aplicações críticas (previsão do tempo, pesquisa nuclear,
modelagem das propriedades aerodinâmicas de aviões e automó
veis etc.), a tecnologia atual de processamento ainda não é ade

Página 113 de 584
quada (para uma análise 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 esforço
para alcançarem um aceitável nível de eficiência. Além disso, em
alguns casos a tecnologia do hardware parece adequada, mas o
novo software (ex.: as novas linguagens de quarta geração) revela-
se tão ineficiente que o sistema como um todo não tem um nível
de eficiência aceitãvel.
150
7
MODIFICAÇÕES
NA ANALISE
DE SISTEMAS
Novas e4)rassões como tensão técnica e choque técnico foram criadas para definir as man
psicológicas de um público subjugado por coisas desde fornos de microondas a jogos domésticos t
‘Pac-Man”. Infelizmente, essas c não 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 tensão técnica pode ser definida de modo melhor como a frustração com
o ritmo lento das mod nos métodos de desenvolvimento de software, em face da crescente
demanda por serviços de pd.
Embora não haja dúvidas de que algum progresso foi feito nos últi mos 30 anos rumo a melhores
métodos de desenvolvimento de sistemas, também não se discute que acima de tudo, todo processo
de mod ção é lento e descontínuo. Observando-se a partir de uma perspectiva histórica, parece que,
para que seja obtido algum progresso, é necessário reconsiderar periódica e coletivamente as idéias
básicas, Os períodos entre os grandes avanços podem ser de dezenas ou de centenas de anos.
Fj. Grant, “Twenty Century Software”
Datamalion, 1 de abril de 1985
1. Os problemas da análise de sistemas clássica.
2. As modificações ocorridas na análise estruturada clássica.
3. Porque as ferramentas automatizadas são importan tes para o futuro da análise dc sistemas.
4. Porque os problemas da análise estruturada clássica conduziram à protoupação.
151
Os métodos e ferramentas apresentados neste livro representam a abordagem que será utilizada na
maioria das organizações de desenvol vimento de sistemas no final dos anos 80 e início dos 90.
Nos meados da década de 90 é provável que a análise de sistemas tenha evoluído subs

Página 114 de 584
tancialmente; o capítulo 25 discute a provável natureza dessa evolução.
Porém, não basta estar ciente das técnicas atuais da análise de sistemas. É necessário conhecer
também as modificações introduzidas nos últimos cinco ou dez anos, modificações essas que
conduziram às fcj e técnicas que exploraremos em profundidade nas partes II e III. Existem três
motivos para que você esteja familiarizado com a evolução da análise de sistemas.
Primeiro, você talvez venha a perceber que a empresa de desen volvimento de sistemas para a qual
você trabalha não evoluiu e que nin guém tem qualquer intenção de fazer alterações. Embora as
modifica ções discutidas neste capítulo tenham ocorrido em cerca de 80% das organizações de
processamento de dados da América do Norte, da Euro pa e de outras partes do mundo, ainda
existem aqueles basuões da mediocridade que não vêem razões para modificar o modo como vêm
fazendo as coisas há 20 anos. No caso de você se encontrar nessa situa ção, a coisa mais lógica a
fazer é mudar de emprego; ou, se você estiver aborrecido, procure oci uma posição de liderança e
ajude sua em presa a ingressar no mundo moderno da análise de sistemas .
Segundo (e mais freqüente), você pode observar que sua empresa já começou a implementar
algumas das modificações vistas neste capítu lo, mas que o processo de mudança ainda continuará
por alguns anos. Um bom exemplo disso é o desenvolvimento dc ferramentas automatiza das de
análise de sistemas. Quase todos os analistas de sistemas lhe afirmarão que as ferramentas baseadas
em PC são uma excelente idéia e alguns gerentes de PED estão começando a apoiar esse conceito.
Mas as ferramentas são relativamente novas, praticamente nenhuma delas exis tia antes de 1984. E
as organizações modificam-se com lentidão; 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 estarão utilizando
essas ferramentas e que uma verdadeira satu ração do mercado de trabalho provavelmente não
ocorrerá antes dos meados da década de 90. Desse modo, mesmo que você e outros mem
•bros de sua empresa saibam o tipo de ferramentas e de técnicas que serão instaladas daqui a três
anos, a abordagem atual da análise de sistemas pode ser algo diferente. É importante conhecer a
abordagem que a organização utilizava anteriormente e qual o tipo de transição está em andamento.
Terceiro, a noção de transição é importante mesmo que você tra balhe em uma das empresas “de
ponta”, que tenha já implementado a
152
abordagem de análise de sistemas tratada neste livro. O campo da análi se de sistemas, como todos
os outros aspectos da área do processamen to, é dinâmico; a maneira como faremos análise de
sistemas em 1995 será indubitavelmente da maneira como a realizamos agora, mas para saber quais
serão as mudanças que ocorrerão no meio e no final da década de 90, torna-se necessária a
apreciação de proveniência desse campo e para onde ele se dirige.
7.1 A PASSAGEM PARA A ANÁUSE ESTRUTURADA
Até o final dos anos 70, a imensa maioria dos projetos de desenvol vimento de sistemas começava
pela criação de uma “novela vitoriana” sobre os requisitos do usuário. Isto é, o analista de sistemas
documenta va o que ele ou ela conhecia daqueles requisitos em um maciço doai mento constituído
principalmente de uma narrativa no idioma adequado. Os autores dos primeiros livros sobre
“análise estruturada”, especialmen te [ 1978], [ e Sarson, 19771 e lWeinberg,19781 mostraram que

Página 115 de 584
aqueles tornos ponderáveis (muitas vezes chamados de especifica ção funcional) padeciam
tipicamente de alguns grandes problemas:
Eles eram monolíticos: era necessário ler toda a especificação funcional, do princípio ao fim, para
poder compreendê-la. As sim como uma novela vitoriana, se não lêssemos a última pá gina, não
saberíamos como a história terminava 2• Isso era uma deficiência importante, porque existem
muitas situações em que o analista de sistemas, ou o usuário, queria ler e compreender urna parte
da especificação sem necessariamente ter de ler qualquer outra parte.
Eles eram redundantes: a mesma informação era muitas vezes repetida em diversas partes
diferentes do documento .O problema disso era que se qualquer aspecto dos requisitos do usuário
fosse alterado durante a fase da análise de sistemas (ou, pior ainda, depois da fase de análise ter
sido considerada como concluída), a alteração teria de se refletir em diversas partes do documento.
Isso hoje em dia seria um problema menor, uma vez que mesmo as mais primitivas organizações
têm amplo aces so às facilidades do processamento de palavras; porém, nas décadas de 60 e 70, a
maioria das empresas criava suas especifi cações funcionais sem nada mais sofisticado do que uma
máquina de escrever elétrica . Corno era muito dificil atualizar e revisar o documento, a
redundância inerente conduzia a um grave problema: inconsistência. Assim como uma pessoa com
153
muitos relógios dificilmente saberá que horas realmente s uma especificação funcional com a
mesma informação repeti três ou quatro vezes possivelmente conterá erros nessa inforrr çào em
algumas oportunidades.
Eles eram ambíguos: o detalhamento dos requisitos do usuái podia ser (e geralmente era)
interpretado de modo difereii pelo usuário, 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 eliminação de erros podiam s imputados a
falhas de interpretação ou a erros da espccificaç funcional.
A manutenção deles era impossível: por Lodos os motivos aciff descritos, a especificação funcional
quase sempre estava ol soleta no final do processo de desenvolvimento do sistema (ist é, quando o
sistema entrava em operação), o que muitas vez ocorria no final da fase de análise. Isso significa
que a maior dos sistemas desenvolvidos durante os anos 60 e 70 - sistem que têm agora 20 anos ou
mais - não têm o registro atualizad da diretiva que eles supostamente conservavam. Como os an:
listas de sistemas e os usuários originais há muito tempo já n estão mais presentes, a triste realidade
é que ninguém sabe que a maior parte dos principais sistemas de processamen
faz hoje.
Enquanto todos esses problemas estavam sendo debaudos, u conjunto complementar de idéias já
estava sendo adotado na área c programação e projeto. Essas idéias, geralmente mencionadas coit
programação estruturada e projeto estruturado, prometiam grandes mi 1horas na organização,
codificação, testes e manutenção de programas tinham, na verdade, se mostrado de geral sucesso;
porém mais e ma empresas de PED começaram gradualmente a perceber que não hav como se
escrever brilhantes programas e como projetar sistemas alt mente modulares se soubesse realmente
o que os sistemas deveria fazer. Na realidade, alguém poderia argumentar que a programaç
estruturada e o projeto estruturado possibilitavam que algumas equip de projeto chegassem a um

Página 116 de 584
desastre com mais rapidez que nunca - construindo uma brilhante solução 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 especificações funcionais
q sejam:
154
Gráficas - compostas por vários diagramas, apoiados por material textual detalhado que, em muitos
casos, serve melhor como material de referência cio que o corpo principal da especificação.
• Particionadas - de modo a que partes individuais da especifi cação possam ser lidas
independentemente de outras.
• De redundância mínima - para que as alterações dos requisi tos do usuário possam ser
incorporadas em apenas uma parte da
especificação.
Essa abordagem, conhecida por todos como análise estruturada, é agora utilizada na maioria das
empresas comerciais de desenvolvimento de sistemas e em grande número das empresas de
engenharia. Ainda existem algumas empresas preparando especificações do tipo novela vitoriana,
mas elas já estão em minoria e, como os dinossauros, se exti guirão em algum momento.
7.2 MODIFICAÇÕES DA ANÁUSE ESTRUTURAL CLÁSSICA
Como já dissemos, a análise tradicional de sistemas (caracterizada pelas especificações vitorianas)
começou a se modificar no final dos anos 70. A maioria das empresas que agora usa análise
estruturada ba seia sua abordagem nos primeiros livros dc DeMarco, Gane e Sarson, Weinberg e
outros, bem como nos seminários, videoteipes e outros re cursos de treinamento fundamentados
nesses livros.
Entretanto, alguns anos de experiência prática com a análise estruturada clássica indicaram
diversas áreas em que precisam ser feitas algu mas alterações ou extensões. As principais
alterações 5
A ênfase na construção de modelos “fisicos” e “lógicos” atuais do sistema do usuário 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 usuário, um sistema que todos sabiam que seria
dispensado e substituido por um novo, que o projeto acabou cancelado por um usuário impaciente
anLes que a equipe de projeto pudesse iniciar a tarefa de estudar o novo sistema proposto. Isso não
quer dizer que tenhamos decidido evitar a modelagem do sis tema atual do usuário em todos os
casos, mas apenas que reco nhecemos ser essa uma atividade politicamente perigosa, e que
155
provavelmente deverá ser minimizada, se não totalmente elimi nada. Esse ponto voltará a ser
A análise estruturada clássica fazia uma distinção vaga e pobre mente definida entre modelos
fisicos (que fazem conjecturas sobre, ou são influenciados pela tecnologia da implementação) e
modelos lógicos (que são independentes da tecnologia da implementação); na verdade, até os
termos lógico e fisico são confusos para muitos. Idéias importantes nessa área foram intro duzidas
por [ e Palmer, 1984] e mesmo partes da terminologia foram modificadas: agora nos referimos a

Página 117 de 584
modelos essenciais (modelos da “essência” de um sistema) em lugar de modelos lógicos, e a
modelos de implementação em lugar de
modelos fisicos.
• Mais e mais empresas estão utilizando técnicas de análise estruturada para construir sistemas de
tempo-real Entretanto, a aná lise estruturada clássica não tem como modelar o compor tamento
tempo-dependente de um sistema; falta-lhe a notação para apresentar interrupções e sinais, e para
mostrar a sincroni zação e a coordenação de diferentes tarefas de processamento. Para resolver esse
problema, foi-lhe acrescentada uma notação adicional e toda uma nova ferramenta de modelagem -
fluxos de controle, processos de controle e diagramas de transições de
estado. Mais detalhes sobre isso nos capítulos 9 e 13.
• A análise estruturada clássica concentrava-se quase inteiramente na modelagem das funções 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 número crescente de empresas percebeu que seus sis temas
envolviam funções, relacionamentos de dados e carac terísticas de tempo-real complexas. Como
vimos, os diagramas de transições de estado foram acrescentados à análise 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 acréscimo de uma ou duas ferramentas de
modelagem é o fato de que três 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 são estudados no capítulo 12 e o conceito de modelos integrados é
visto no capítulo 14.
156
• O processo da análise estruturada modificou-se substancialmen te. A análise estruturada clássica
presumia que o analista de sis temas começaria 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 funções e vários depósitos de dados em uma forma estri
tamente top-down. Infelizmente, isso não funcionava bem, pelas razões apresentadas no capítulo
20, e em conseqüência, foi acrescentada uma nova abordagem denominada subdiv de eventos. A
terminologia e os conceitos básicos da subdivisão de eventos foram apresentados por [ e Palmer,
1984] e estendidos por [ e Mellor, 1985].
7.3 O SURGIMENTO DAS FERRAMENTAS AUTOMATIZADAS DE ANÁUSE
Quando as técnicas de modelagem gráfica da análise estruturada começaram a se disseminar pelas
empresas de desenvolvimento de siste mas no final dos anos 70 e início dos 80, os analistas de
sistemas come çaram a perceber que existia um problema importante: o trabalho artís tico
necessário para criar diagramas de fluxo de dados, diagramas de entidades-relacionamentos,
diagramas estruturais, diagramas de transi ções de estado e outros modelos gráficos era muitas
vezes excessivo, O problema, na maior parte dos casos, não era a criação inicial dos diagra mas,
mas a revisão e a manutenção. A criação do diagrama inicial consome tempo mas, pelo menos dá a
satisfação de ser uma atividade desafIadora, criativa e intelectual. Em um projeto típico, o analista

Página 118 de 584
de sistemas sabe que terá de redescnhar os modelos gráficos várias vezes até que ele e o usuário
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 vários diagramas de transições de
estado; desse modo, o volu me de trabalho artístico envolvido pode ser realmente assustador. A con
seqüência prática disso, em muitas empresas, é que a análise estruturada clássica não foi tão bem-
sucedida quanto deveria. Ocorreram os seguin tes problemas:
• Após a segunda ou terceira revisão do diagrama, o analista de sistemas tornava-se
progressivamente hostil e relutante em fazer novas modificações. Assim, era possível encontrar
diagramas ‘congelados” que não refletiam verdadeiramente os requisitos do sistema do usuário.
157
• Em face do volume de serviço envolvido, o analista de sistemas por vezes não mais subdividia o
modelo do sistema em modelos de nível mais baixo - isto é, em vez de desenvolver um modelo
constituído de cinco níveis de diagramas de fluxo de dados, ele parava no quarto nível. O modelo
resultante continha funções “primitivas” (isto é, as bolhas do quarto nível) que de fato não o eram;
isso se tornava t complexo que o programador preci sava executar algumas tarefas de análise de
sistemas para poder escrever os programas .
• As alterações dos requisitos do usuário após a fase de análise do projeto muitas vezes não eram
incorporadas ao modelo do sis tema. Muitas dessas alterações ocorriam durante as fases de projeto,
programação e de testes do sistema, enquanto outras ocorriam depois de o sistema ter sido
implementado. O resul tado era uma especificação obsoleta.
Além do trabalho necessário para criar e manter os diagramas, a análise estruturada clássica exige
um grande volume de trabalho para verificar os diagramas para garantir que estejam completos e
consis tentes; essas normas são discutidas no capítulo 14 lO Nos anos 70 e na maior parte dos 80,
os analistas de sistemas dependiam de técnicas manuais de verificação (inspeções visuais dos
diagramas para localizar erros). Como esse trabalho é uma atividade intensa e aborrecida, tende a
ser sujeita a erros. Em conseqüência, muitos erros de especificação dei xaram de ser encontrados.
Muitos desses problemas podem ser resolvidos com um adequado apoio automatizado; isso era
bem conhecido mesmo quando a análise estruturada clássica foi apresentada pela primeira vez, mas
o custo da automatização era muito mais elevado do que o que as empresas po diam suportar.
Entretanto, o desenvolvimento de poderosos terminais gráficos em meados da década dc 80
conduziu a uma atividade total mente nova conhecida por CASE (computer-Aided , Engine ering);
algumas dúzias de fornecedores oferecem produtos (geralmente para PC) que desenham diagramas
de fluxos de dados e coisas seme lhantes, bem como executam diversas tarefas dc verificação de
erros. As características e exemplos dessas ferramentas são discutidas no apêndice 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 terão em 1990. Todavia, isso é
obviamente o caminho do futuro e podemos esperar que todos os analistas profissionais insistirão
nelas à proporção que o tempo passar. Isso levará, em princípio, a um melhor nível de qualidade
dos modelos dc sistemas produzidos; em
158

Página 119 de 584
segundo lugar, levará a modelos gráficos de sistema visualmente mais atraentes. À proporção que
os conceitos de verificação de erros discuti dos no capituio 14 forem automatizados, isso pode
eliminar a necessida de de os analistas de sistemas conhecerem o material do capítulo 14! E à
proporção em que as ferramentas CASE comecem eventualmente a gerar programas (em COBOL,
Pascal ou talvez em uma linguagem de quarta geração) diretamente a partir das especificações,
haverá uma redução na necessidade de programadores!
7.4 O USO DA PROTOTIPAÇÃO
Como mostramos no capitulo 3, alguns usuários têm dificuldade em lidar com os modelos gráficos
da análise estruturada, preferindo al gum Outro modo de modelar os requisitos e o comportamento
do siste ma. As ferramentas de prototipação, que começaram a se tornar ampla mente disponíveis
em meados da década de 80, têm sido vistas por alguns como uma alternativa à análise estruturada
para tais usuários.
Existe um outro motivo para a popularidade da prototipação: a análise estruturada clássica é vista
em algumas empresas como consumi dora exagerada de tempo; no momento em que a fase de
análise termi na, o usuário já esqueceu o que ele queria inicialmente do sistema. Isso, de hábito,
resulta dos seguintes problemas:
• A equipe de projeto gastou tempo demais desenvolvendo modelos do sistema atual do usuário 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 análise do sistema,
preferindo começar a codifi cação logo que possível. Em um ambiente assim, o prolongado
trabalho da análise de sistemas, que aparenta não produzir saídas exceto figuras com círculos e
quadros, pode parecer improdutiva.
• Os primeiros projetos utilizando a análise estruturada podem consúmir mais tempo do que o
normal, porque os analistas de sistemas estão aprendendo novas técnicas e consultando um ao
outro qual a melhor maneira de aplicá-las.
As ferramentas de prototipação (ferramentas de software que per mitem ao analista de sistemas
construir uma imitação do sistema) estão
159
sendo consideradas corno uma efetiva solução para esses problemas Observe também que a
prototipação tende a se concentrar no aspecto da interface humana de um projeto de
desenvolvimento de sistema.
Infelizmente, as ferramentas de prototipação às vezes são utilizadas
para evitar os detalhes combinados da análise e do projeto de sistemas;
o uso adequado da prototipação foi mostrado na seção 5.6.
7.5 O CASAMENTO DA ANÁLISE E DO PROJETO DE SISTEMAS
Como já foi anteriormente mencionado neste capítulo, os aperfei çoamentos na área da engenharia
de software se iniciaram com a progra mação estruturada e com o projeto estruturado. Na
realidade, esses dois tópicos foram tema de considerável debate em empresas de desenvolvi mento
de sistemas durante a primeira metade da década de 70. Foi também nessa época que começaram a

Página 120 de 584
surgir os primeiros livros sobre projeto estruturado (veja lMyers, 1975] e [ e Constantine, 1975]).
Esses primeiros livros não faziam referência à análise estruturada (uma vez que os conceitos ainda
não tinham sido desenvolvidos), enquanto os livros posteriores, como [ 1980], incluíam uma breve
vista geral do assunto. O trabalho sobre análise estruturada começou em meados dos anos 70, e os
primeiros livros começaram a aparecer no final daquela década; mas havia pouca ou nenhuma
conexão entre a discus são da análise estruturada e a sobre projeto estnsturado. O problema
principal estava em que a análise estruturada lidava com a especificação 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 análise 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 edições 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 ciência da engenharia, a análise de siste mas passou por uma série de
modificações evolutivas durante os últimos 20 anos. Como indicado no início deste capítulo, é
importante saber quais foram essas modificações, porque a atividade de desenvolvimen to de
software é tão grande e variada que ninguém utiliza as mesmas
160
técnicas que outros. Sua empresa pode estar no «bordo de ataque” da tecnologia ou no «bordo de
fuga”.
Podemos esperar que a área da análise de sistemas continue pro gredindo e que as técnicas
apresentadas neste livro terão evoluído ainda mais nos próximos cinco a dez anos, O capítulo 25
examina a provável natureza das futuras modificações evolutivas.
REFERÊNCIAS
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 Desígn, 1” cd. Nova lorque: YOURDON
Press, 1975.
8. Meilir Page-Jones, The Practical Guide to Structured Systems De sign, 1’ ed. Nova lorque:

Página 121 de 584
9. Meilir Page-Jones, The Practical Guide to Structured Systems De sign, 2’ ed. Englewood Cliffs,
10. Edward Yourdon e Larry Constantine, Siructured Design, 2’ cd. Englewood Cliffs, N.J.:
Prentice-hall, 1989.
1. Quais são os três principais motivos para que você conheça a evolução da análise de sistemas?
2. O que você deveria fazer se a organização em que você trabalha não tiver feito as modificações
discutidas neste capítulo?
3. Apresente quatro principais problemas de uma especificação narra tiva clássica.
4. Por que a redundância é indesejável na especificação de um siste ma? É possível remover toda a
redundância de uma especificação?
5. Você pode imaginar algum motivo pelo qual a redundância pode ria ser útil na especificação de
um sistema?
161
6. Quais são as três razões comuns pelas quais a redundância é intro duzida em uma especificação
clássica?
7. Que percentagem de erros em um sistema operativo pode ser atri buIda aos erros ocorridos
durante a fase de análise de sistemas do
projeto?
8. Projeto de Pesquisa: qual é a percentagem de erros em sua organi zação que pode ser atribuida a
erros ocorridos durante a fase de
análise de sistemas do projeto?
9. Quais são as conseqüências de uma especificação impossível de ser mantida?
10. Faça uma breve descrição de programação estruturada.
11. Faça uma breve descrição de projeto estruturado.
12. Por que algumas organizações descobriram que não são bem sucedidas quando utilizam a
programação estruturada e o projeto
estruturado?
13. Quais são as três principais características da especificação estruturada?
14. Quais são as cinco principais modificações que ocorreram na aná use estruturada clássica?
15. Qual o problema que a análise estruturada clássica apresenta ao lidar com sistemas de tempo-
real?
16. Quais são os riscos associados à modelagem do sistema atual de informações do usuário?
Quanto tempo se deve despender com
essa modelagem?

Página 122 de 584
17. Quais são os três principais problemas que o analista de sistemas talvez encontre se não dispu
ser de apoio automatizado em seu
trabalho?
18. É importante dispor de apoio automatizado nos projetos de desen volvimento de pequenos
sistemas de informações? Por quê?
19. Que problemas podem ser encontrados se o analista de siste mas tiver de executar manualmente
as atividades de verificação
de erros?
20. Por que, em sua opinião, apenas 2% dos analistas de sistemas nos Estados Unidos dispunham
de estações de trabalho para análise
automatizada de sistemas em 1987?
21. Que benefkios adicionais podem ser obtidos da introdução de uma rede de ferramentas
automatizadas de análise de sistemas?
(Obs.: um desses benefícios é a mala eletrônica).
22. Quais são os três problemas comuns que as organizações encon traram na implementação da
análise estruturada clássica?
23. Que problemas de interfacc existiam entre a análise estruturada e o projeto estruturado na
década de 70 e no início da de 80?
162
NOTAS
Isso não é uma sugestão frívola. Se essas organizações não se
modificarem, estarão fora do mercado em um determinado mo mento da década de 90.
2 Ou, em outras palavras, não havia sexo até a última página.
3 Existem várias teorias para explicar porque a redundância era uma característica tão comum. Pela
minha própria experiência a especi ficação funcional servia a três diferentes objetivos na empresa
(e por isso a mesma informação era apresentada em três modos diferentes): primeiro: ela era a
declaração ‘oficial” dos requisitos do usuário; segundo: ela era um manual de treinamento não-ofi
cial, destinado a explicar como os «estúpidos” usuários deveriam operar o sistema, e terceiro: ela
era uma ferramenta de vendas po liticamente orientada, destinada a fazer crer à direção que o
sistema iria ser tão bom que valeria o preço de sua elaboração.
4 Um dos melhores exemplos desse problema talvez seja o que ocor reu em uma importante
organização de PED de um banco nova iorquino em meados da década de 70. Reunidos em uma
típica “horda mongólica” de projeto de desenvolvimento de sistemas, o grupo de analistas de
sistemas entrevistou dúzias de usuários por todo o banco e desenvolveu gradualmente a
especificação vitoriana de tamanho entorpecedor. A datilografia do documento ocupou o pool de
datilógrafos por duas semanas e todas as copiadoras Xerox foram requisitadas por diversos dias
para que fossem feitas cópias suficientes para distribuição aos usuários. Foi dada uma se mana para
que a comunidade usuária lesse toda a especificação funcional e apontasse quaisquer modificações
ou correções; para grande surpresa (e imenso alívio) os analistas não receberam ne nhum

Página 123 de 584
comentário por parte dos usuários na data limite. Assim, a especificação funcional foi declarada
como “congelada” e deu-se a partida nos trabalhos de projeto e programação. Três semanas mais
tarde, seis membros da comunidade usuária anunciaram que ti nham finalmente terminado de ler
toda a especificação e, sim, eles tinham algumas pequenas alterações. Seguiu-se um pequeno pâni
co: o que seria feito com a especificação? Após duas furiosas reu niões nas quais os usuários e os
analistas de sistemas insultavam os ancestrais e a inteligência uns dos outros em termos que não po
dem ser repetidos em um livro como este, chegaram a uma de cisão: as modificações não seriam
incluidas na especificação datilo grafada (porque isso seria muito dificil), mas seriam incorporadas
ao sistema. Ou, em outras palavras: a equipe de projeto achou que seria mais fácil alterar o COBOL
do que o inglês.
163
5 Veja James Martin, An Information Systems Man (Englewood Cliffs, N.J.: Prentice-Hall, 1984).
6 Reveja a definição 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 capítulos às estruturas de dados.
Mas a notação utilizada (“diagramas de estruturas de dados”) é atualmente considerada obsoleta;
além disso, boa parte da ênfase dos primeiros livros estava na conversão de um conjunto arbitrário
de estruturas de dados para a terceira forma normal, que (1) é tão simpies que o processo foi
mecanizado e (2) é mais um problema
de implementação, ou de projeto, que de análise de sistemas.
8 Isso talvez não seja evidente para você por enquanto, porque vi mos apenas alguns diagramas de
análise estruturada no capítulo 4.
Contudo, no final da parte II, ficará bastante evidente; caso contrá rio, aguarde até o final de seu
primeiro projeto “real” de análise
estruturada!
9 Como veremos no capítulo 11, deve haver uma especificação de processo (habitualmente escrita
como uma tabela de decisão, um
fluxograma ou em formato de português estruturado) para cada bolha primitiva de último nível no
diagrama de fluxo de dados. Se
o sistema tiver sido adequadamente subdividido, a maioria das especificações de processos deve ter
menos de uma página.
10 Exemplos de normas de verificação: todos os fluxos de dados de um DFD devem ter nome, e
esses nomes devem estar definidos no
dicionário de dados. Todas as entradas do dicionário de dados devem corresponder a fluxos de
dados ou depósitos 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

Página 124 de 584
CARACTERÍSTICAS DAS FERRAMENTAS
DE MODELAGEM
Qualquer coisa á fácil, se você puder incluí-la em sua coleção de
modelos.
Seymour Papert, Mindstorins
1. Porque as ferramentas de modelagem de sistemas são habitualmente gráficas.
2. Porque as ferramentas de modelagem de sistemas são subdivisíveis na modalidade top-down.
3. Porque as ferramentas de modelagem de sistemas têm redundância mínima.
4. Porque as ferramentas de modelagem de sistemas auxiliam a modelagem do comportamento de
sis temas.
Os próximos capítulos 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 tórios que
precisamos rever.
Você se recordará do capítulo 4 que um modelo é um fac-simile
barato de um sistema complexo que desejamos estudar. Os modelos de
sistemas são construídos por três motivos:
1. Para focalizar características importantes de sistemas deixando de lado as menos importantes.
167
2. Para discutir alterações e correções nos requisitos do usuário a baixo custo e com mínimo risco.
3. Para confirmar que entendemos o ambiente do usuário e o do cumentamos de uma tal maneira
que os projetistas de sistemas e
programadores podem construir o sistema.
Mas existem muitas espécies diferentes de modelos que podemos construir para o usuário: modelos
narrativos, modelos de protótipos, vá rios modelos gráficos e assim por diante. Na realidade, o
sistema final que construímos para o usuário pode revelar ser um modelo - no sentido de que ele
pode representar, pela primeira vez, um meio de o usuário visualizar o que ele deseja.
Neste livro, focalizaremos nossa atenção nos modelos em papel (ou modelos em papel produzidos
por sistemas automatizados CASE). Existe, porém, uma grande variedade deles: como veremos em
maiores detalhes nos próximos capítulos, existem fluxogramas, diagramas HIPO, tabelas de
decisão, diagramas de fluxo de dados, fluxogramas de sistemas, dia gramas de transições de estado,
árvores de decisão, diagramas de entida de-relacionamentos, diagramas de Ferstl, diagramas de
Hamilton-Zeldin, diagramas DAP e um conjunto interminável de diagramas, tabelas e grá ficos que
podemos apresentar ao usuário. Qual deles deveremos utilizar?
A premissa básica deste livro é que você deve utilizar qualquer modelo que seja útil para você e
para a situação em que você se encon trar. Diferentes usuários podem precisar de diferentes
ferramentas de modelagem pela experiência anterior ou porque eles consideram que certas espécies

Página 125 de 584
de diagramas os confundem e intimidam’. Diferentes projetos podem exigir diferentes ferramentas
de modelagem face aos padrões de documentação impostos por organizações externas. E dife
rentes tipos de sistemas podem exigir modelos diferentes para realçar adequadamente as
características importantes.
Levando essa questão mais adiante, muitos sistemas exigem mode los múlt cada modelo focaliza
um número limitado de aspectos do sistema, deixando de lado (ou ignorando) outros aspectos do
sistema. Isso vale especialmente para muitos sistemas construídos hoje, uma vez que eles têm
complexas características funcionais, complexas estruturas de dados e complexas considerações
temporais.
Qualquer ferramenta que você utilize deve ter as seguintes
características:
• Ela deve ser gráfica, 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 mínima redundância.
• 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 GRÁFICOS
A maioria dos modelos de sistemas mais conhecidos, e todos aque les usados neste livro, apóia-se
firmemente em gráficos. O uso de gráfi cos não é obrigatório em um modelo de sistema, porém o
velho adágio de que numa figura vale por mil palavras” é uma boa justificativa para a nossa
preferência por gráficos em lugar de textos narrativos. Uma figura bem escolhida pode englobar
uma imensa quantidade de informações de forma concisa e compacta.
Isso não significa que uma figura possa descrever, necessariamen te, tudo sobre um sistema; para
isso poderia criar algo tão confuso que ninguém se interessaria em examinar. Geralmente usamos
gráficos 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 seqüência?” etc.) são
apresentadas em documentos textuais de apoio. Os documentos textuais de apoio descritos neste
livro são a especificação do pmcesso e o dicionário de dados.
Isso não significa que todos os analistas de sistemas devam usar o conjunto de ferramentas de
modelagem orientadas para gráficos e textos apresentado neste livro. O Grande Analista de
Sistemas celestial não o fulminará com seus raios pela não utilização de diagramas de fluxo de
dados. No entanto, você provavelmente será atingido por raios se escolher um ou outro dos
extremos de tudo em gráficos (sem texto de apoio) ou tudo em texto (sem gráficos). E você será
queimado com pelo menos um pequenino raio se fizer do texto a parte dominante do modelo, com
gráficos desempenhando um papel menor e subordinado. Um ou mais gráficos devem ser o
principal documento a que o usuário poderá recorrer para compreender o sistema; os documentos
textuais devem servir como material de referência a ser consultado quando necessário.

Página 126 de 584
169
8.2 MODELOS SUBDWLSÍVEIS NA MODALIDADE TOP-DOWN
Um segundo aspecto importante de uma boa ferramenta de mode lagem é a sua aptidão para
retratar um sistema de forma subdividida top down. Isso não é importante para pequenos sistemas,
porque podemos dizer tudo que precisa ser dito em uma ou duas páginas, e qualquer um que
necessite conhecer qualquer aspecto do sistema poderá aprender tudo do sistema.
Entretanto, os projetos reais do mundo real não são geralmente pequenos Na realidade, a maioria
dos projetos em que você provavel mente se envolverá variará de médios a gigantescos. Em
conseqüência, será impossível para qualquer um, sejam eles usuários, analistas de sistemas ou
programadores, focalizar todo o sistema de uma só vez. Nem seria possível apresentar um modelo
gráfico 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 pés! Dessa maneira, nossas
ferramentas de modelagem devem nos permitir retratar partes individuais do sistema de uma forma
isolado, juntamen te com um modo díreto de passar de uma pan do modelo do sistema para outro.
Entretanto, necessitamos bem mais do que isso: não seria apropria do, por exemplo, criar um
enorme modelo gráfico de 30 X 30m e, em seguida, dividi-lo em 9 mil pedaços separados de 0,1 X
O,lm, com milha res de conectores de páginas. 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 pedaços do tamanho de páginas.
Na realidade, nossa experiência com mapas e atlas demonstra como precisamos organizar um
modelo de sistema complexo. Um atlas dos Estados Unidos, por exemplo, normalmente começa
com um dia grama de uma única página de todo o país, como mostrado na figura 8.1. Essa página
mostra os estados, e pode mostrar também as principais interfaces entre os estados (rios, rodovias
interestaduais, ferrovias, rotas aéreas etc.). As páginas subseqüentes são habitualmente dedicadas a
cada estado, de forma individual, com cada página apresentando as ci dades e municípios de um
estado, bem como as rodovias estaduais lo cais que não foram mostradas no mapa a nível de pais.
Pode-se imaginar mapas de nível inferior, que mostram detalhes sobre cada município, cada cidade
dentro de um município e cada bairro dentro de uma cidade.
Um bom modelo de um complexo sistema de informações deve
proceder da mesma forma top-down. Uma visão geral de alto nível de
uma parte do modelo deve dar ao leitor uma boa idéia dos principais
170
componentes de alto nível e das interfaces do sistema. As partes subse qüentes do modelo
forneceriam informações sobre componentes deta lhados de baixo nível do sistema. E, assim como
um atlas fornece um mecanismo prático para percorrermos todo o conjunto de mapas indivi duais
(isto é, partindo do mapa de nível de país para o mapa em nível de município sem grandes
dificuldades), um bom modelo de um sistema de informações fornece um modo prático para passar
suavemente de alto para baixo nível.
8.3 MODELOS DE MÍNIMA REDUNDÂNCIA
Os modelos são representações de algum sistema do mundo real, e o próprio sistema pode ser

Página 127 de 584
estático (inalterável) ou dinâmico. O mapa dos Estados Unidos, por exemplo, é uma representação
gráfica do país onde moramos. E, embora muitos aspectos do nosso país sejam cla ramente muito
dinâmicos, pode-se objetar que os aspectos modelados por um mapa são relativamente estáticos:
estados individuais não apa recem ou desaparecem com freqüência, e as fronteiras entre os estados
têm estado relativamente constantes por um longo período (em con traste, não podemos dizer o
mesmo em relação a um mapa do mundo inteiro!).
Em que isso interessa a uma pessoa ao construir um modelo?
Simplesmente porque é desejável 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, preferiríamos modificar apenas um correspondente aspecto local do modelo, sem
sermos forçados a alterar qualquer outro aspecto dele. Na realidade, se forem necessárias múl tiplas
mudanças, existe uma boa possibilidade de que elas não 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. Poderíamos
imaginar, no caso mais simples, uma página apresentando o país inteiro, e 50 páginas subseqüentes
mostran do os detalhes de cada estado. Agora imagine o que aconteceria se o es tado de Nova
Jersey desaparecesse : o mapa do país precisaria ser re desenhado para mostrar o novo país de 49
estados, e o mapa original do estado de Nova Jersey seria descartado.
Porém, seria um pouco mais difícil com atlas reais porque, como é típico com muitos modelos de
Sistemas, existe alguma redundância em butida. Cada mapa de estado mostra não somente o estado
que está sendo descrito, mas partes dos estados vizinhos - informações que são adequadamente
fornecidas no mapa do país, mas que convém tê-las em nível de estado, também. Isso quer dizer,
portanto, que se Nova Jersey desaparecesse, teríamos, provavelmente, que redesenhar os ma pas de
Nova lorque e da Pensilvânia, e talvez Maryland e Delaware. Que aborrecimento!
Cartógrafos profissionais poderiam desaprovar isso e argumentar que uma certa redundância é
necessária para tornar o atlas mais fácil de ser lido. Entretanto, é evidente que quanto maior for a
redundância que o modelo contiver, maior será a dificuldade para mantê-lo. Imagine, por exemplo,
que nosso atlas mítico mostre as rodovias interestaduzis no mapa a nível de país e todos os mapas a
nível de estado. Imagine, tam bém, que um fabricante de mapas tenha decidido mostrar toda a ex
tensão de cada rodovia interestadual em cada mapa de estado através do qual passa a estrada.
Assim, a Interestadual 95, que corre do Maine à Flórida, apareceria nos mapas de cerca de uma
dúzia de estados, cada um dos quais estaria afetado pelo (redundante) fato de que toda a estra da
tem aproximadamente 1.700 milhas de extensão, O que aconteceria se fosse descoberto que essa
figura estava errada ou que parte da estrada tenha sido prolongada ou redesenhada? Obviamente,
uma dúzia de diferentes mapas estaduais teriam de ser alterados.
8.4 MODELOS TRANSPARENTES
Para finalizar, um bom modelo deve ser tão fácil de ler que o

Página 128 de 584
leitor não precise parar para pensar que ele ou ela está olhando para a
172
representc.ção de um sistema, em vez do próprio sistema. Isso não é sempre fácil de ser
conseguido, e muitas vezes requer alguma educação e prática de parte do leitor. Pense em um
mapa, por exemplo: quantas vezes você pensou estar olhando para uma representação abstrata do
estado de Nova Jersey em lugar do próprio estado? Por outro lado, observe uma pequena criança
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 distância de Nova Jorque. “Não, não é”,
a criança dirá, “Newark fiGa somente a meia polegada de distância da cidade de Nova lorque.
À proporção que ficamos mais velhos, no entanto, tornamo-nos gradualmente mais familiarizados
com o conceito de representações abstratas desde que elas se acomodem confortavelmente em
nossas ca beças. Cientistas estudaram o comportamento e organização do cérebro humano e
descobriram que o lado esquerdo do cérebro lida com pro cessamento seqüencial, uma coisa de
cada vez; é, também, o lado es querdo do cérebro que lida com texto, por exemplo, as palavras que
você está lendo, uma de cada vez, nesta página de papel. O lado direito do cérebro lida com figuras
e com processamento assíncrono, «mui tas coisas ao mesmo tempo”. Isso nos mostra que se
experimentarmos modelar alguma coisa que seja intrinsecamente linear e seqüencial, 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 cérebro, 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 gráfica.
8.5 RESUMO
Não tenho dúvidas de que você estará tão ocupado aprendendo as ferramentas de modelagem
apresentadas neste livro que não pensará na póssibilidade da existência 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 princípios básicos e diretrizes
apresentados neste capítulo.
173
1. Quais são as três principais razões para se construir modelos de sistemas?
2. Descreva três diferentes tipos de modelos de sistemas.
3. Quais são as principais características que uma ferramenta de modelagem de sistemas deve ter?
4. Por que as ferramentas de modelagem gráfica são geralmente pre feridas em relação às
ferramentas de modelagem textual?
5. É necessário utilizar ferramentas de modelagem gráfica para desen volver um sistema de
informações? Você pode imaginar alguma si tuação em que não desejaria utilizar tais ferramentas?

Página 129 de 584
6. Que coisas os modelos gráficos normalmente não mostram sobre um sistema?
7. Por que é importante que uma ferramenta de modelagem retrate um sistema de forma top-down?
Existe alguma situação em que
isso não é importante?
8. A descrição top-down de um sistema exige que esse sistema seja projetado na modalidade top-
down?
9. Descreva uma situação onde seria aceitável incluir redundância no modelo de um sistema.
NOTAS
1 Um corolário disso é que as boas ferramentas de modelagem nor malmente envolvem notações
muito simples, com muito poucas re gras, simbolos e novas palavras para o usuário aprender. Um
puris ta poderia mesmo argumentar que uma boa ferramenta de modela gem não requer
explanações e nem treinamento; em qualquer caso, não deve ser necessário ler as 700 páginas 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 estão sendo desenvolvidos pelos
usuários sem . assistência de analistas de sistemas e programadores. Com a crescente
disponibilidade de computadores pessoais, pacotes de planilhas eletrônicas e lingua gens de quarta
geração, muitas tarefas que exigiriam alguns dias (ou mesmo semanas) de trabalho de um
profissional em processa mento podem agora ser feitas em questão de minutos ou de horas pelo
usuário. Entretanto, continuam a existir muitos sistemas de
174
informações, hoje, que necessitam de mais de 10 milhões de instru ções de programa para executar
seu objetivo.
3 Se você vive em Nova Jersey ou tem alguma outra patológica cone xão 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 função.
Louis Henry Suilivan
‘The Tal! Office Building Artistically Considered”,
Lippincott ‘s Magazine, março de 1986
Neste capítulo aprenderemos:
1. Os componentes de um diagrama de fluxo de dados.
2. Como desenhar um diagrama de fluxo de dados simples.

Página 130 de 584
3. Diretrizes para desenhar diagramas de fluxo de da dos com sucesso.
4. Como desenhar diagramas de fluxo de dados nivelados.
Neste capítulo vamos explorar uma das três principais ferramentas de modelagem gráfica da
análise 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 usuários, você pode usar qualquer um dos termos
abaixo como sinônimo 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 representação 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 fi4nçães do sistema sejam de fundamental
importância mais complexas do que os dados manipulados pelo sistema. Os DPII foram utilizados
pela primeira vez na área da engenharia de softwar como uma representação 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
representação, por sua vez, foi trazid de antigos trabalhos sobre a teoria dos grafos e continua a ser
usada como uma forma cômoda de notação por engenheiros de softwar interessados na
implementação direta de modelos dos requisitos dc usuário.
Isso é um retrospecto interessante, mas provavelmente írrelevant para os usuários a quem são
mostrados os modelos do sistema em DFD Em realidade, é provável que a pior coisa que se pode
fazer é dizer: “Sr Usuário, gostaria de lhe apresentar um modelo iop-down, particionado
fundamentado na teoria dos grafos, dc seu sistema”. Muitos usuário estão familiarizados com o
conceito subjacente dos DFD, porque mesmo tipo de representação tem sido utilizado por
cientistas pesquisa dores de operações durante cerca de 70 anos para elaborar os modelo do fluxo
de tarefas das organizações. É importante lembrar isto: os DFL podem ser usados não só para
modelar sistemas de processamento d informações, mas também como um meio de se modelar
organizaçõe inteiras, isto é, como uma ferramenta para o planejamento comercial estratégico.
Iniciaremos nosso estudo de diagramas de fluxo de dados pek exame dos componentes de um DFD
típico: o processo, o fluxo, o depó sito e o terminador. Empregaremos uma notação amplamente
padroniza da para DFD, seguindo a notação de livros clássicos como [ 19781, [ e Sarson, 19771 e
outros. Coniudo, também incluiremos representação de DFD para a modelagem de sistemas de
tempo-rea (fluxos de controle e processos de controle). Essa representação suple mentar
geralmente não é necessária para sistemas orientados para comércio, mas torna-se essencial para a
modelagem de vários sistema:

Página 131 de 584
de engenharia e científicos.
178
A seguir, vamos rever algumas diretrizes para a construção 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 método de
modelar sistemas complexos.
Lembre-se que o DFD é apenas uma das ferramentas de modela gem disponíveis para o analista de
sistemas e que ele oferece apenas uma visão do sistema - a visão orientada para funções. Se
estivermos desenvolvendo um sistema no qual os relacionamentos entre os dados sejam mais
importantes que as funções, podemos dar menor importância aos DFD (e até não desenvolvermos
nenhum) e nos dedicarmos ao de senvolvimento de um conjunto de diagramas de entidades-
relaciona mentos como podemos ver no capítulo 12. Como alternativa, se o com portamento
tempo-dependente do sistema sobrepujar todos os outros aspectos, podemos nos dedicar aos
diagramas dc transições de estado discutidos no capítulo 13.
9.1 OS COMPONENTES DE UM DFD
A figura 9.1 mostra um DFD típico de um pequeno sistema. Antes
de analisarmos seus componentes em detalhe, observe que:
Ele não precisa de explicações; basta olharmos para ele para compreendê-lo. A representação é
simples e sem intrusões e, de uma certa forma, bastante intuitivo. Isso é especialmente impor tante
quando lembramos quem supostamcnte examinará a fi gura - não o analista dc sistemas, mas o
usuário! Se precisar de uma enciclopédia para ler e entender o modelo do sistema, provavelmente
não se interessará por nada daquilo.
O diagrama acomoda-se facilmente em uma página. Isso tem dois significados: (1) uma pessoa
pode examinar o diagrama sem se confundir e (2) o sistema que está sendo modelado não é muito
complexo. Que fazer se o sistema for intrinsecamente tão complexo que haverá literalmente
centenas de círculos e linhas no diagrama’ Dicutiremos isso na seção 9.4.
O diagrama foi desenhado por um computador. Nada existe de errado com diagramas desenhados à
mão, mas a figura 9.1 e muitos dos DFD mostrados neste livro foram desenhados com auxílio do
programa MacDraw da Macintosh. Isso quer dizer que o diagrama é desenhado com mais exatidão
e de um modo mais padronizado do que seria possível se tivesse sido desenhado à
179
nome do cliente,
detalhes de faturas
Figura 9.1: Um DFD típico
mão e que as alterações podem ser feitas e novas versões pc
dem ser produzidas em questão de minutos
9.1.1 O Processo
O primeiro componente dc um DFD é conhecido como pmcess Os sinônimos mais conhecidos são
bolha, função e transformação. ( processo mostra uma parte do sistema, a que transforma entradas

Página 132 de 584
em sa:
das - isto é, mostra como uma ou mais entradas são convertidas er saídas. O processo é
representado graficamente por um círculo, como s vê na figura 9.2(a). Alguns analistas de sistemas
preferem usar um ov ou um retângulo de vértices curvos, como mostrado na figura 9.2(b outros
preferem ainda um retângulo, corno na figura 9.2(c). As dif renças entre esses três formatos são
puramente cosméticas, embora sej obviamente importante utilizar o mesmo formato de maneira
consistent para representar todas as funções do sistema. Neste livro usaremos serr pre o círculo ou
bolha 2•
180
CALCU LAR
IMPOSTO
SOBRE
VENDAS
Figura 9.2 (a): Um exemplo de processo
( CALCULÃM
1 IMPOSTO
SOBRE
EN DAS
Figura 9.2(b): Representação alternativa de um processo
CALCULAR
IMPOSTO
SOBRE VENDAS
Figura 9.2 (c): Outra representação de um processo
Observe que o processo é denominado ou descrito com uma única palavra ou sentença simples. Na
maioria dos modelos de DFD que vere mos neste livro, o nome do processo descreverá o que o
processo faz. Na seção 9.2, falaremos mais sobre a adequada atribuição de nomes às bolhas de
processos; por enquanto, é suficiente dizer que um bom no me geralmente é composto por uma
frase constituída 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 divisão de um empresa, p.ex.), ou de um computador ou de um dispositivo
mecânico. 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 capítulo 17, quando
estudarmos o conceito de modelo essencial, e na parte IV, quando examinarmos os modelos de
implementação.
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

Página 133 de 584
181
é utilizado para mostrar o movimento de fragmentos ou de pacotes informações de um ponto a
outro do sistema. Desse modo, o flu representa dados em movimento, enquanto os depósitos
(descritos m adiante na seção 9.L3) representam dados cm repouso.
Na maioria dos sistemas que você modela como analista de síst mas, os fluxos, na realidade,
representam dados, isto é, bits, caractere mensagens, números de ponto flutuante e os diversos
outros tipos de i formações com que o computador lida. Mas os DFD também podem s usados para
modelar outros sistemas além dos automatizados o computadorizados; podemos, por exemplo, usar
um DFI) para model uma linha de montagem onde não haja componentes computadorizado Em um
caso assim, os pacotes ou fragmentos transportados pelos fluxc poderão ser materiais físicos (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 têm nomes. O noni representa o significado do pacote
que se move pelo fluxo. Um corolári disso é que o fluxo transporta apenas um tipo de pacote, o que
é indic do pelo nome do fluxo. Os analistas de sistemas não devem atribuir um fluxo de dados um
nome como MAÇÃS E LARANJAS E VÁRIA OUTRAS COISAS. Entretanto, como veremos na
parte 111, existem exa ções a essa convenção: às vezes é útil reunir diversos fluxos de dadc
elementares em um fluxo consolidado. Desse modo, poderíamos ter ui único fluxo de dados
denominado VEGETAIS em lugar de vários fluxc diferentes rotulados como BATATAS, CEBOlAS
e ERVILHAS. Como v remos, isso exige algumas explicações no dicionário de dados, que e
tudaremos no capítulo 10.
Embora isso possa parecer um tanto óbvio, lembre-se que um me mo conteúdo 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 NÚMERO-DE-TELEFONE e quando passa pelo fluxo denominado NÚMERO-DE-
TELEFONE- VÁLIDO. No primeiro caso ele indica um número de telefone que pode ser válido ou
não, enquanto que no segundo ele indica um número de telefone que, no contexto do sistema, é
sabido ser válido.
MISTURA PARA BOLOS
BOLO
Figura 9.4: Um DFD com fluxos mdteriais
FONE AR NÚMERO NÚMERO-DE-TELEFONE-VÁLIDO
Figura 9.5: Um DFD típico
Outro modo de se interpretar isso é ver o fluxo denominado “número de telefone” como um duto,
capaz de permitir a passagem in discriminada de números de telefone válidos e inválidos através

Página 134 de 584
dele; o fluxo NÚMERO-DE-TELEFONE-VÁLIDO é mais estreito, ou mais discri minativo,
permitindo que passe por ele apenas um conjunto estreitamente definido de dados.
Observe também que o fluxo mostra dítvção: 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 número de telefone está sendo
enviado para o processo rotulado VALIDAR NÚMERO DE
183
TELEFONE. E o fluxo rotulado ESCAIA-DE-ENTREGM)ORES na figura 9.6(b) é claramente um
fluxo de saída gerado pelo processo GERAR- ESCALA-DE-ENTREGADORES; os dados que se
movimentam por aquele fluxo ou irão transitar para outro processo (como entrada) ou para um
depósito (como discutido na seção 9.1.3) ou para um terminador (como discutido na seção 9.1.4).
O fluxo com duas setas mostrado na figura 9.6(c) é um diãIo uma prática junção de dois pacotes de
dados (consulta e informação ou pergunta e resposta) no mesmo fluxo. No caso de um diálogo, 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 tributários reunindo-se em
um maior. Isso, entretanto, tem especial significado em um DFD típico no qual pacotes de dados
transitam pelo sistema: no caso de um fluxo divergente, isso quer dizer que cópias de um pacote de
dados são enviadas para diferen NÚMERO
Figura 9.6 (a): Um fluxo de entrada
Figura 9.6 (b): Um fluxo de saída
CONSULTA-SOBRE-SITUAÇÃO-DE-PEDI DO
Figura 9.6 (e): Umflu.xo de diáloRo
18 /
tes partes do sistema, ou que um pacote complexo de dados está sendo dividido em vários 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 vários pacotes elementares de dados estão 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 cópias dos mesmos pacotes para os
processos GERAR DOCUMENTOS DE EMBARQUE, ATUALIZAR INVENTÁRIO e GERAR
FATURA. A figura 9.7(b) apresenta o fluxo rotulado como ENDEREÇO-DE-CLIENTE
subdividido em pacotes mais simples rotulados como NÚMERO-DE- TELEFONE, CÓDIGO-
POSTAL e ENDEREÇO, que são remetidos para três processos diferentes de validação ¶
‘EDIDOS INVÁLIDOS
Figura 9.7 (a): Um fluxo diz
185
PEDIDO

Página 135 de 584
‘DETALHES DE
1
Figura 9.7 (b): Outro exemplo defluxo divergente
Observe que o fluxo não 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 saída. 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 usuário de ui
sistema on-line, indicando que deseja uma entrada? Ou será que
pacotes de dados transitam pelo fluxo por suas próprias vontades, sei serem chamados? De modo
semelhante, a figura 9.8(b) mostra um flux simples de saída emanando de GERAR RELATÓRIO
DE FATURA; Sei que as FATURAS transitam por aquele fluxo quando GERA RELATÓRIO DE
FATURA as quer remeter, ou quando outro setor d sistema reclama o pacote? Para finalizar,
considere a situação, ma comum, apresentada na figura 9.8(c), na qual existem múltiplos fluxc de
entrada e de saída; em que seqüência chegam os fluxos de dados ei que seqüência são gerados os
fluxos de saida? Existe uma proporçã um-para-um entre os pacotes de entrada e os de saída? Isto é,
o process
186
E N DEREÇO-DE-CLIENTE
CÓDIGO-POSTAL
Q exige exatamente um pacote dos fluxos de entrada A, B e C para pro duzir exatamente um
pacote de saída para os fluxos X, Y e Z? Ou são dois A para cada três B?
A resposta a todas essas perguntas é muito simples: não 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 não trata desses
aspectos. Se essas perguntas tiverem importância
Figura 9.8 (a): Um fluxo de entrada
ÚAT
Figura 9.8 (b): Um fluxo de saída
A
B
Figura 9.8 (c): Combinação defluxos de entrada e de saída
187
para você, então será necessário modelar o procedimento interno de di versos processos; as
ferramentas para isso são estudadas no capítulo 11.
9.1.3 O Depósito
O depósito é utilizado para se modelar uma coleção de pacotes de dados em repouso. A
representação para um depósito são duas linhas paralelas, como na figura 9.9(a); uma notação

Página 136 de 584
alternativa é mostrada na figura 9.9(b) outra representação, usada no estudo dc caso do apêndi ce F,
é apresentada na figura 9.9(c). Normalmente o nome escolhido para identificar o depósito é o
pluraldo nome dos pacotes transportados pelos fluxos para dentro e para fora do depósito.
PEDIDOS
Figura 9.9 (a): Representação gráfica de um depósito
D J PEDIDOS
Figura 9.9 (b): Urna representação aliernativa para um depósito
( PEDIDOS
Figura 9.9 (c): A representação utilizada no Apêndice F
Para o analista de sistemas com retrospecto de processamento de dados, é tentador referir-se aos
depósitos como arquivos ou bancos de dados (ex.: um arquivo em fita magnética 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 depósitos são muitas vezes
implementados em sistemas compu tadorizados; mas um depósito também pode conter dados
armazenados em cartões perfurados, microfilmes, microfichas, discos óticos e várias outras
modalidades eletrônicas. Um depósito também pode ser compos to por cartões de 3 por 5
indexados em uma caixa, ou nomes e endere ços em um livro de endereços, ou por algumas pastas
de arquivos em um armário ou por diversas outras formas não computadorizadas. A fi gura 9.9(d)
mostra um exemplo típico de um “depósito” de um sistema manual. É precisamente por causa da
variedade de implementações
188
1
Figura 9.9 (d): Outra forma de depósito
possíveis de um depósito que dcliberadamente escolhemos uma repre sentação gráfica simples e
abstrata e o termo depósito em lugar de, por exemplo, banco de dados 6
Além da aparência fisica que o depósito assume, existe ainda a questão de seu propósito: o
depósito existe por causa de um requisito básico do usuário ou por um aspecto prático da
implementação do sis tema? No primeiro caso o depósito existe como uma necessária á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 questão de mtina
do usuário (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 depósito PEDIDOS tem que existir dc
alguma forma, em disco, fita, cartões ou em tabuinhas de argila.
A figura 9.11(a) mostra um tipo diferente de depósito: o depósito de implementação. Podemos
imaginar o projetista de sistemas interpon do o depósito PEDIDOS entre INTRODUZIR PEDIDO
e PROCESSAR PEDIDO porque:
• Ambos os processos devem ser executados no mesmo computa dor, mas não há memória
sufkiente (ou algum outro recurso de hardware) para acomodar ambos os processos
simultaneamente. Assim, o depósito PEDIDOS foi criado como arquivo interme diário, tendo em

Página 137 de 584
vista que a tecnologia de implementação dis ponível forçou que os processos sejam executados em
momen tos diferentes.
• Um ou ambos os processos devem ser executados em uma configuração de hardware não
totalmente confiável. Por causa disso, o depósito PEDIDOS foi criado como um mecanismo de
backup para a eventualidade de um dos processos ser mal sucedido.
189
CONFIRMAÇÃO
Figura 9.10: Um depósito necessário
• 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 depósito PEDIDOS foi, assim, criado para servir co mo facilidade para testes e depu
ração de modo a que se o sis tema inteiro não funcionar, ambos os grupos possam examinar o
conteúdo do depósito para descobrir o problema.
• O analista e o projetista de sistemas imaginaram que o usuário poderia eventualmente querer ter
acesso ao depósito PEDIDOS para alguma finalidade, mesmo que não tivesse indicado tal
interesse. Nesse caso, o depósito foi criado em antecipação a fu turas necessidades do usuário (e
como vai custar alguma coisa a implementação do sistema com esse recurso, o usuário vai pagar
por um recurso do sistema que não foi solicitado).
Se excluíssemos os problemas e modelássemos somente os requisi tos essenciais do sistema, não
haveria necessidade do depósito PEDI DOS; teríamos, assim, um DFD como o da figura 9.11(b).
Como pudemos ver pelos exemplos apresentados até agora, os depósitos são interligados aos
processos por fluxos. Dessa maneira, o contexto em que um depósito 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 depósito
• Um fluxo para um depósito
Na maioria dos casos os fluxos são rotulados como vimos na seção
9.1.3. Entretanto, muitos analistas dc sistemas não se preocupam em rotular o fluxo se todo um
grupo de um pacote entra ou sai do depósito Para exemplificar, a figura 9.12 mostra um fragmento
de DFD.
Um fluxo que parte de um depósito é normalmente interpretado
como uma leitura ou um acesso feito às informações desse depósito.
Especificamente, pode significar que:
• Um pacote isolado de dados foi recuperado do depósito: este é, de fato, o exemplo mais comum

Página 138 de 584
de um fluxo que sai de um de pósito. Imagine, por exemplo, um depósito chamado CLIEN TES,
onde cada pacote Contém informações de nome, endereço e telefone de clientes. Um fluxo típico
que saísse desse depósito
HES DE PEDIDOS
PEDIDO
PEDIDOS
EDIDO /ÁuDO
RESPOSTA
Figura 9.11 (a): Um depósito de “implementação”
PEDIDOS
(
EDIDO JÁLIDO
RESPOSTA
Figura 9.11 (b): O depósito de implementação removido
191
Figura 9.12: Depósitos com JZu não-rotulados
envolveria a recuperação de um pacote completo de infor
mações sobre um cliente.
• Mais de um pacote foi recuperado do depósito. Por exemplo o fluxo poderia recuperar pacotes de
informações sobre todo os clientes da cidade de Nova lorque a partir do depósit
CLIENTES.
• Apenas uma parte do pacote foi recuperada do depósito Em alguns casos, por exemplo, apenas a
parte do número d telefone de um cliente poderia ser recuperada do depósit
CLIENTES.
• Partes de mais de um pacote foram recuperadas do depósito Por exemplo, um fluxo pode
recuperar do depósito CIJENTE
o código 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 depósito: o fluxo
represent um único pacote, múltiplos pacotes, partes de pacote ou partes de vá rios pacotes? Em
alguns casos, essas dúvidas podem ser respondida pelo simples exame do rótulo do fluxo; se o
fluxo não possuir um rótulo isso quer dizer que um pacote inteiro de informações está send
recuperado (como indicado acima, isso é apenas uma convençã
192
PEQUENOS OBJETOS VERMELHOS INGREDIE
MAÇÃS

Página 139 de 584
NÃO-MAÇÃS
prática); se o rótulo do fluxo for o mesmo que o do depósito, então um pacote inteiro (ou múltiplas
instâncias de um pacote inteiro) está sendo recuperado; e se o rótulo do fluxo for algo diferente do
nome do de pósito, então um ou mais componentes de um ou mais pacotes estão sendo recuperados
8•
Embora algumas das perguntas procedurais possam ser respondi das pelo exame cuidadoso dos
rótulos dos fluxos, nem todos os detalhes são evidentes. Na verdade, para sabermos tudo o que
queremos sobre um fluxo que parte de um depósito, temos que examinar os detalhes - a espec de
processos- do processo ao qual o fluxo está interliga do; as especificações de processos serão
discutidas no capítulo 11.
Há um detalhe procedural do qual podemos estar certos: o depósi to é passivo e os dados não
transitam a partir dele pelos fluxos a menos que um processo os solicite explicitamente. Existe
outro detalhe proce dural que é pressuposto, por convenção, para os sistemas de processa mento de
informações: Um depósito não se altera quando um pacote de informações se movimenta a partir
dele por um fluxo. Os programa dores referem-se a isso como leitura não-destrutiva; em outras
palavras, uma cópia do pacote é recuperada do depósito, que permanece em suas condições
originais .
Um fluxo para um depósito é muitas vezes descrito como uma
escrita, uma atualização ou possivelmente uma eliminação. Em termos
específicos, ele pode ter um dos seguintes significados:
Um ou mais novos pacotes estão sendo introduzidos no depósito. 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 implementação (con trolado pelo específico
sistema de gcrcnciamento de banco de dados), caso em que o analista dc sistemas não deve se
preocu par com isso. Entretanto, pode ser uma questão de orientação do usuário.
• Um ou mais pacotes estão sendo eliminados ou removidos do depósito.
• Um ou mais pacotes estão sendo modificados ou alterados. Isso pode envolver a alteração de todo
um pacote, ou (mais habitual) apenas parte dc um pacote ou parte de múltiplos pacotes. Para
exemplificar, suponha que uma delegacia mantenha um depósito de possíveis criminosos e que
cada pacote contenha o nome e endereço de um suspeito; a delegacia poderia oferecer
193
uma nova “identidade” para um suspeito que colaborasse, caso em que todas as informações
relativas àquele suspeito seriam alteradas. Como alternativa, considere o depósito CLIENTES que
contém informações sobre os clientes residentes em Man hattan; se os Correios decidissem alterar
o código postal de uma área de Manhattan (como ocorreu em 1983, quando a área de Manhattan
onde eu morava teve o código postal alterado de 10028 para 10128), seria necessária a alteração de
uma parte de vários pacotes.
Em todos esses casos é evidente que o depósito se altera em resul tado da entrada do fluxo. O
responsável pela alteração do depósito é o

Página 140 de 584
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 depósito só podem trans portar pacotes de informações que o depósito pode
aceitar. Desse modo, um fluxo interligado ao depósito CLIENTES só pode transportar infor
mações relativas aos clientes que o depósito contenha, não podendo transportar pacotes de
inventário ou de fabricação nem dados astronômicos.
9.1.4 O Ter
O componente seguinte do DFD e o tenntnador ele é grafi camente representado por um retângulo,
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 organização externa ou uma empresa do governo ou um grupo ou setor que esteja
dentro da mesma companhia ou organização, 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: Representação gráfica de um terininador
194
Costuma ser muito fácil identificar os terminadores do sistema em modelagem. às vezes o
terminador é o usuário; isto é, em nossas discus sões com o usuário, 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 usuário 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 formulários tipo 321 do Departamento de Contabilidade
e temos de remeter semanalmente Rela tórios Orçamentais para a Comissão de Finanças’. Nesse
último caso, é claro que o Departamento de Contabilidade e a Comissão de Finanças são
terminadores separados com os quais o sistema se comunica.
Existem três importantes aspectos a serem lembrados sobre termi nadores:
1. Eles são externos ao sistema que estamos modelando; os fluxos que interligam os terminadores
aos diversos processos (ou de- pósitos) de nosso sistema representam a interface entre o sis tema e
o mundo externo.
2. Como conseqüência, é evidente que nem o analista nem o pro jetista de sistemas estão em
posição de modificar o conteúdo de um terminador ou o modo como o terminador funciona. Na
linguagem de vários livros clássicos sobre análise de sistemas, o terminador está fora do domínio
das modificações. O que isso quer dizer é que o analista de sistemas está modelando um sistema
com a intenção de proporcionar ao projetista um considerável grau de flexibilidade e liberdade de
escolher a melhor (ou mais eficiente ou mais confiável etc.) implementa ção possível. 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

Página 141 de 584
sistema de um modo que pareça consideravelmente diferente da forma com que o usuá rio imagina
o sistema agora (mais sobre isso na seção 9.4 e na parte III). Mas o analista de ststemas não pode
mod o con teúdo, ou a organização ou os procedimentos relativos aos terminadores.
3. Qualquer relacionamento existente entre terminadores não será mostrado no DFD. Alguns
relacionamentos desse tipo podem existir de fato, mas, por definição, eles não 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, então, por definição, os tem nadores são 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 típi do mundo real, pode haver literalmente
dúzias de terminador diferentes interagindo com o sistema. A identificação d terminadores e a
interação deles com o sistema é parte d processo de construção do modelo amhicntal, que será visto
n capítulo 17.
9.2 DIRETRIZES PARA A ELABORAÇÃO DE DFD
Na seção precedente vimos que os diagramas de fluxo de dado são compostos por quatro
componentes simples: processos (bolhas; fluxos, depósitos e terminadores. Munido dessas
ferramentas, você agor:
pode começar a entrevistar usuários e a construir DFD de sistemas.
Entretanto, existem algumas diretrizes adicionais necessárias par:
utilizar DFD com sucesso. Algumas dessas diretrizes o auxiliarão 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
atenção pelo usuário.
As diretrizes são as seguintes:
1. Escolher nomes significativos para os processos,fluxos, depósi tos e terminadores.
2. Numerar os processos.
3. Refazer os DFD tantas vezes quantas forem necessárias até obte uma boa estética.
4. Evitar DFD complexos demais.
5. Certificar-se de que o DFD seja internamente consistente alén de manter a consistência com os
outros DFD.
9.2.1 Escolher Nomes Sign para os Processos, Fluxos, Depósitos e Terminadores
Como já vimos, um processo cm um DFD pode representar um:
fi nção que esteja sendo executada ou pode indicar como a função est
196
sendo executada, pela identificação da pessoa, grupo ou mecanismo envolvido. No último caso,
torna-se evidente a importância dc rotular acuradamente o processo para que as pessoas que
examinem o proces so, principalmente os usuários, sejam capazes de confirmar de que aque le seja

Página 142 de 584
um modelo correto. Entretanto, se o processo for executado por uma só pessoa, é recomendável
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 razão para isso é tripla:
1. Fred pode ser substituído na próxima semana por Maria ou por João. Para que introduzir
obsolescência no modelo?
2. Fred pode desempenhar diversas tarefas no sistema. Em lugar de desenhar três bolhas, todas com
o rótulo Fred mas re presentando atividades diferentes, é preferível 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 identificação de Fred provavelmente atrairá atenção para o modo como ele executa seu
trabalho. Como veremos na parte III, devemos geralmente nos concentrar na onentação comercial
subjacente que deve ser seguida, sem referências aos proce dimentos (que podem ser baseados em
costumes e antecedentes não mais relevantes) empregados no cumprimento daquela orientação.
Se pudermos evitar o uso de nomes de pessoas (ou de grupos) e
de funções políticas, podemos rotular os processos de modo a identificar
pedidos
válidos
pedidos
Figura 9.14 (a): Um nome de processo inadequado
197
as fi que o sistema executa. Um bom método para nomes de pro cessos é utilizar um verbo e um
objeto. Isto é, empregar um verbo que represente ação (um verbo transitivo, que exige um objeto) e
um objeto adequado formando uma sentença descritiva do processo. Eis alguns exemplos de nomes
de processos:
• CALCULAR TRAJETÓRIA 1)0 MÍSSIL
• PRODUZIR RELATÓRIO DE INVENTÁRIO
• VAliDAR NÚMERO DE TELEFONE
• DESIGNAR ALUNOS PARA SALAS
Você verá, ao seguir esta diretriz, que é consíderavelmente mais fácil empregar verbos e objetos
espccfficos se o próprio processo for simples e bem definido. Mesmo nos casos simples, todavia,
existe a tentação de usar nomes vagos como FAZER, MANIPULAR e PROCESSAR. Quando são
utilizados verbos desse tipo «elástico” (verbos cujo sentido pode ser estendido para significar quase
tudo), muitas vezes significa que o analista de sistemas não está bem certo de qual função está
sendo executada ou que várias funções foram reunidas mas que não o deve riam ser. Eis alguns
exemplos de maus nomes de processos:
198
• FAZER SERVIÇO

Página 143 de 584
• FUNÇÕES DIVF’
• MANIPULAR ENT1(AI)i
pedidos
pedidos
pedidos inválidos
Figura 9.14 (b): Um nome de processo mais adequado
1
• CUIDAR DOS CLIENTES
• PROCESSAR DADOS
• EDIÇÃO GERAL
Os nomes escolhidos para os processos (e também para os fluxos e os terminadores) devem provir
de um vocabulário conhecido pelo usuá rio. Isso acontecerá naturalmente se o DFD for desenhado
como resulta do de uma série de entrevistas com o usuário e se o analista de sistemas tiver um
mínimo conhecimento do objeto subjacente da aplicação. Porém duas precauções devem ser
tomadas:
1. Existe a natural tendência por parte dos usuário sem utiliza rem as abreviações e acrônimos 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 são feitas agora. Assim, o usuário poderia dizer: «Bem, nós pegamos uma cópia do
formulário 107 - o cor-de-rosa, você sabe - e o enviamos para o José para ser riscado”. Uma boa
maneira de evitar termos ex cessivamente idiossincrásicos é escolher verbos (como “riscar”) e
objetos (como “formulário 107”) que serão compreensíveis para alguém da mesma indústria ou
aplicação, mas trabalhando em outra empresa ou organização. Se você estiver elaborando um
sistema bancário, os nomes dos processos e dos fluxos de vem, idealmente, ser compreensíveis
para os que trabalham em outros bancos.
2. Se o DFD estiver sendo desenhado por alguém com retrospecto em programação, haverá
tendência de serem utilizados termos provenientes daquela atividade como “ROTINA”,
“SUBSISTEMA” e “FUNÇÃO”, embora tais termos possam não ter significado no mundo do
usuário. A menos que você ouça os usuários uti lizarem essas palavras em conversas entre eles
mesmos, evite-as nos DFD.
9.2.2 Numerar os Processos
Como um método prático de referenciar os processos de um DFD, a maioria dos analistas de
sistemas costuma numerar cada bolha. Não 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 números.
199
A única coisa que você dcve ter cm mente é que o esquema numeração implicará, para os eventuais
leitores do seu DFD, uma det miixada sequência de execução. 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

Página 144 de 584
a bolha 3?”. Na verdade você po obter a mesma pergunta de outros analistas de sistemas e
programac res; qualquer um que conheça fluxogramas cometerá o engano dc pres mir que os
números das bolhas implicam uma sequência.
Mas não é assim, O DFD é uma rede de processos assíncronos qi
se intercomunicam, e é, de fato, uma exata representação do modo c
mo realmente funciona a maioria dos sistemas. Uma certa seqüência p
de ser deduzida pela presença ou ausência de dados (ex.: pode ser
sível que a bolha 2 não possa executar sua função antes de receber d
dos da bolha 1), mas o esquema de numeração nada tem a ver com iss Sendo assim, então para que
numerar as bolhas? Em parte, com
explicado acima, como um meio prático de identificar os processos; muito mais fácil em uma
discussão sobre um DFD dizer-se “bolha 1” ei vez de «EDITAR ERROS DE TRANSAÇÕES E
DE RELATÓRIOS”. Aind mais importante, os números são a base para o esquema de numer ção
hierárquica quando apresentarmos diagramas de fluxo de dadc nivelados na seção 9.3.
9.2.3 Evitar DFD Complexos Demais
O propósito de um DFD é modelar corretamente as funções qu um sistema deve executar e as
interações entre elas. Porém um ouu objetivo do DFD é ser lido e compreendido, não somente pelo
analisi de sistemas que elaborou o modelo, mas também pelos usuários que sã os conhecedores do
assunto correlacionado. Isso significa que o DF deve ser prontamente compreendido, facilmente
absorvido e agradávi aos olhos.
Na próxima subseção discutiremos algumas diretrizes estética mas há uma diretriz principal que
deve ser sempre lembrada: não cr um DFD com demasiados pmcessos, fluxos, depósitos e
terminaderes. maioria dos casos isso quer dizer que não se deve incluir mais dc me dúzia de
processos e depósitos, 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 exceção, como veremos no capítulo 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 típico, e você pode notar que ele é capaz de assustar muitos analistas de sistemas,
quanto mais um usuário despreparado! Normal mente os diagramas de contexto como o da figura
9.15 não podem ser simplificados, por representarem, mesmo no nível mais elevado de deta
lhamento, uma realidade que é intrinsecamente complexa”.
Figura 9.15: Um diagrama de contexto típico
9.2.4 Refazer o DFD Tantas Vezes Quantas Forem Necessárias
Em um projeto de análise de sistemas do mundo real, o DFD que discutimos neste capítulo terá de
ser feito, refeito e novamente refeito, por dez ou mais vezes, até que esteja (1) tecnicamente
correto, (2) acei tável pelo usuário e (3) tão bem desenhado que você não fique constran gido em

Página 145 de 584
mostrá-lo à junta de diretores de sua empresa. Isso pode parecer muito trabalho, mas vale o esforço
de desenvolver um modelo correto, consistente e agradável dos requisitos do sistema. Isso também
é válido em qualquer Outra atividade de engenharia: você gostaria de viajar em um avião projetado
por engenheiros que ficassem entediados com seus desenhos após a segunda iteração 12?
O que torna um diagrama de fluxo de dados esteticamente agradá vel? Isso logicamente é uma
questãp de gosto pessoal e de opinião, e pode ser determinado por padrões estabelecidos por sua
empresa ou pelas características idiossincrásicas de algum pacote automatizado de
201
diagramação em terminais de vídeo que você esteja utilizando. Além disso, a opinião do usuário
pode ser um tanto diferente da sua; dentro dos limites do que seja razoável, o que quer que o
usuário considere como esteticamente agradável deve nortear a maneira como você deve desenhar
os diagramas. Alguns dos problemas que costumeiramente surgem para discussão nessa área SãO:
Tamanho e forma das bolhas. Algumas organizações desenham diagramas de fluxo de dados com
retângulos ou ovais em vez de círculos; isso é naturalmente uma questão de estética. Além dis so,
alguns usuários preocupam-se quando as bolhas do DFD não são 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
tão 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 versão de um DFD
202
Figura 9.16 (b): Uma versão dzferente do mesmo DFD
Qual deles é mais agradável esteticamente? Muitos observado res encolheriam os ombros, dizendo,
«Eles na realidade são iguais”. Mas, Outros - e essa é a questão - escolherão um e rejeitarão
vivamente o outro. É, evidentemente, uma boa idéia, saber de antemão qual a opção que será aceita
e qual será rejei tada. O problema das setas que se cruzam é mais ou menos da mesma categoria:
são ou não permitidas?
Diagramas desenhados à mão ve diagramas gerados por máquina. Dentro de poucos anos,
virtualmente todos os dia gramas de fluxo de dados e os modelos de sistemas serão dese nhados
por sistemas de processamento gráfico; hoje em dia, contudo, muitos desses diagramas ainda são
desenhados à mão porque os analistas de sistemas não têm acesso a essas ferra mentas. O
problema, entretanto, é a reação do usuário a esses diagramas: alguns demonstram forte preferência
pelos diagra mas gerados em máquina por serem mais limpos, enquanto Outros preferem as figuras
desenhadas à mão porque lhes dão a sensação de que os diagramas ainda não foram terminados ou
“congelados” e ainda podem sofrer modificações.
203
9.2.5 Cerqflcar-se de que o DFD Seja Logicamente Consistente
Como veremos no capítulo 14, existem algumas normas e diretrizes que auxiliam a garantir que o

Página 146 de 584
diagrama de fluxo de dados seja consisten te com os outros modelos do sistema - o diagrama de
entidades-relacio namentos, o diagrama de transições de estado, o dicionário de dados e a
especificação de processos. Entretanto, existem algumas diretrizes que são utilizadas para fazer
com que o próprio DFD seja consistente. As principais diretrizes para a consistência são estas:
• Evite os poços sem fundo, bolhas que têm entradas mas não têm saídas. Também conhecidas
pelos analistas de sistemas como “buracos negros”, em analogia a estrelas cujo campo gra
vitacional é tão forte que nem mesmo a luz pode lhes escapar. Um exemplo de poço sem fundo é
mostrado na figura 9.17.
• Evite bolhas com geração espontânea; bolhas que têm saídas mas não entradas são suspeitas e
geralmente incorretas. Um exemplo plausível de bolha de saída-apenas é um gerador de números
aleatórios, mas é difícil imaginar outro exemplo ra zoável. Uma bolha típica de saída-apenas é
mostrada na figura 9.18.
• Cuidado com os fluxos e processos sem rótulo. Isso geralmente é sinal dc desatenção, mas pode
revelar erros mais Sérios: às vezes o analista de sistemas omite o rótulo de um fluxo ou de um
processo porque simplesmente não conseguiu encontrar um nome satisfatório. No caso de um fluxo
sem rótulo, isso pode significar que vários itens elementares de dados não relaciona dos foram
arbitrariamente reunidos; no caso de um processo não rotulado, isso pode indicar que o analista de
sistemas estava tão confuso que desenhou um fluxograma disfarçado em lugar de um diagrama de
fluxo dc dados O
• Cuidado com depós ilos de leitura -apenas ou escrita-apenas. Esta diretriz é análoga à diretriz
sobre processos de entrada- apenas ou de saída-apenas; um depósito típico deve ter entra das e
saídas A única exceção a esta diretriz é o depósito 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
ações com um legítimo depósito de escrita-apenas
204
9.3 DFD COM NÍVEIS
Até o presente momento, neste capítulo, os únicos diagramas de fluxo de dados completos que
vimos são o sistema simples de três bo lhas da figura 9.1 e o de uma só bolha da figura 9.19. Mas
os DFD que veremos em projetos reais são consideravclmcnte maiores e mais com plexos.
Considere, por exemplo, o DFD mostrado na figura 9.20. Já ima ginou mostrá-lo a um usuário
típico?
Na seção 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 dúzias ou mesmo centenas de funções a serem
modeladas, como podemos evitar o tipo dc DFI) da figura 9.20?
A resposta está em modelar o DFI) geral em uma série de níveis de modo a que cada nível ofereça
succssivamcntc mais detalhes sobre uma parte do nível que lhe seja superior. Isso é análogo à
organização dos mapas em um atlas, como discutido no capítulo 8: podemos examinar um mapa de
visão geral de todo um país, ou mesmo dc todo o mundo;
a
x

Página 147 de 584
Figura 9.17: Um exemplo de poço sem fundo
a
x
Figura 9.18: Um exemplo de bolha de saída-apenas
205
Dados do
relatórios anuais DADOS DO MERCADO
Figura 9.19: Um caso legítimo de depósito de escrita-apenas
Figura 9.20: Um DPI) complexo
206
os mapas subseqüentes nos mostrarão os detalhes de países de modo individual, de estados dentro
de países e assim por diante. No caso dos DFD, a organização dos níveis á mostrada
conceitualmente na figura
9.21.
O DFD dc nível 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 depósi tos externos que possam
estar presentes, como ilustrado pela figura
9.19). Esse DFD especial é conhecido como dia,grama de contexto e é
O DFD imediatamente abaixo do diagrama de contexto é conheci do como figura O. Ele representa
a visão de mais alto nível das principais funções do sistema bem como as principais interfaces
entre essas fun ções. Como vimos na seção 9.2.2, cada uma dessas bolhas deve ser numerada para
mais fácil identificação.
Os números também servem como um meio prático de se relacio nar uma bolha com o DFD de
nível imediatamente inferior que descreve
essa bolha de modo mais completo. Por exemplo:
• A bolha 2 da figura O está associada ao DFD de nível inferior conhecido como figura 2. As
bolhas da figura 2 são numeradas
como 2.1, 2.2, 2.3 etc.
• A bolha 3 da figura O está associada ao DFD de nível inferior conhecido como figura 3. As
bolhas da figura 3 são numeradas
como 3.1, 3.2, 3.3 etc.
• A bolha 2.2 da figura 2 está associada ao DFD de nível inferior conhecido como figura 2.2. As
bolhas da figura 2.2 são numera das como 2.2., 2.2.2, 2.2.3 etc.
• Se uma bolha possuir um nome (e de fato deve possui-lo!), então esse nome é transportado para a
figura de nível imedia tamente abaixo. Assim, se a bolha 2.2 tem o nome de CALCU LAR TAXA

Página 148 de 584
DE VENDAS, então 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 manipuláveis. Mas existem algumas coisas que
devem ser acrescentadas a essa descrição da subdivisão em níveis:
207
DIAGRAMA DE CONTEXTO
FIGURA O
FIGURA 3
Figura 9.21: Diagramas defluxo de dados em níveis
208
1. Como saber quantos níveis deve ter um DFD? A resposta a esta pergunta foi sugerida na seção
9.2.3: cada figura de DFD deve ter não mais de meia dúzia de bolhas e de depósitos a elas
relacionados. Assim, se você tiver subdividido um sistema grande em três níveis, mas os DFD de
nível mais baixo ainda contêm 50 bolhas cada um, você deve estabelecer pelo menos mais um
nível abaixo desse. Um ponto de verificação alternativo é oferecido no capítulo 11, onde
discutimos as especificações de processos para as bolhas dos DFD do nível mais baixo: se não
pudermos escrever uma razoável especificação de processo para uma bolha em uma só página,
então ela provavelmente está demasiado complexa, e deve ser subdividida em um DFD de nível
mais baixo antes de tentarmos escrever a especificação do processo.
2. Existem diretrizes sobre o número de níveis que devem ser es perados em um sistema típico?
Em um sistema simples, encon tram-se provavelmente dois ou três níveis; um sistema de médio
porte apresenta costumeiramente de três a seis níveis; e um sis tema grande terá de cinco a oito
níveis. Deve-se ter cautela com pessoas que afirmam que qualquer sistema pode ser modelado em
exatamente três níveis - alguém assim também vai tentar vender-lhe a ponte Rio-Niterói. Por outro
lado, lembre-se de que o número total de bolhas cresce exponencialmente quando se passa de um
nível para o imediatamente inferior. Se, por exemplo, cada figura tiver sete bolhas, então haverá
343 bolhas no terceiro nível, 16.807 bolhas no quinto nível e 40.353.607 de bolhas no nono nível.
3. Todas as partes do sistema devem ser subdivididas até o mesmo nível de detalhamento? Por
exemplo, se a bolha 2 da figura O exigir mais três níveis de detalhamento, é necessário subdividir
também a bolha 3 em mais três níveis? 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 é ‘Não”. Algumas partes de um sistema podem ser mais complexas que
outras e podem exigir a sub- divisão em mais um ou dois níveis. Por outro lado, se a bolha 2 da
figura O do nível mais elevado for primitiva, enquanto a bolha 3 requer subdivisão cm sete níveis,
então o modelo geral do sistema está assimétrico 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

Página 149 de 584
4 Como se mostram esses níveis para o usu€ Muitos usuários só desejarão ver um diagrama. Um
usuário executivo de alto nível pode querer ver apenas o diagrama de contexto ou talvez a figura O;
um usuário de nível operativo pode querer ver apenas a figura que descreve a área do sistema em
que ele esteja interessado. Mas se alguém quiser ver uma grande parte do sistema ou talvez o
sistema intciro, então faz sentido apresentar- lhe os diagramas na metodologia top-down:
começando pelo diagrama de contexto e descendo aos níveis inferiores de maior detalhamento.
Muitas vezes é prático 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 nível superior que oferece um contexto de alto nível.
5. Como garantir que os níveis dos DFD sejam consistentes entre si? O aspecto da consistência
reveste-se de tanta importância porque os diversos níveis dos I)FD são 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 nível supe rior,
seguimos uma regra simples: os fluxos de dados que en tram e saem de uma bolha em um nível
devem corresponder aos fluxos que entram e saem de uma figura inteira do nível 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 níveis de um DFD não- equilibrado.
6. Como mostrar depósitos nos dive’ níveis? Esta é uma área em que a redundância é
deliberadamente introduzida no modelo. A diretriz é a seguinte: mostre um depósito no nível mais
alto onde ele setve primeiramente como interface entre duas ou mais bolhas; em seguida, mostre-o
novamente em CADA diagrama de nível inferior que descreva (ou subdivida) as bolhas interfa
ceadas. A figura 9.23 mostra um depósito compartilhado por dois processos de alto nível, A e B; o
depósito seria novamente mostrado nas figuras de nível mais baixo, que ampliam a descrição de A
e B. O corolárho disso é que os depósitos locais, utilizados apenas pelas bolhas de uma figura de
nível inferior, não serão mostrados nos níveis superiores, porque estarão incluídos em um processo
do nível imediatamente superior.
210
o
FIGURA 3
Figura 9.22 (a): Um fragmento de DFD equilibrado
211
o
FIGURA 3
Figura 9.22 (b): Um fragmento de DFD desequilibrado
212
7. Como realmente se faz a subdivísão dos DFD em níveis? A dis cussão até agora orientou mal de
um modo um tanto sutil:

Página 150 de 584
embora seja verdadeiro que os DFD devam ser apresentados aos usuários na modalidade top-down,
não é necessariamente verdadeiro que o analista de sistemas deva desenvolver os DFD segundo
essa modalidade. A abordagem top-down é intuitivamente muito atraente. Pode-se imaginar
começar pelo diagrama de contexto e depois desenvolver a figura O e, em seguida, des cer
metodicamente aos níveis inferiores de detalhamento”. Entretanto, veremos no capítulo 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 esboço de DFD. No capítulo 20, veremos que essa primeira versão do DFD pode ter de ser
subdividida para cima (pára criar DFD de níveis mais
Figura 9.23: A exibição de depósitos nos níveis inferiores
213
elevados) e para baixo (para criar DFD de níveis mais baixos). Por enquanto, é suficiente que você
compreenda apenas que a organização e a apresentação de um conjunto de DFD em vários níveis
não corresponde necessariamente à estratégia de se desenvolver esses níveis em primeiro lugar.
9.4 EXTENSÕES AO DFD PARA SISTEMAS DE TEMPO-REAL
Os fluxos discutidos neste capítulo são [ de dados; eles atuam como dutos pelos quais transitam
pacotes de dados entre processos e depósitos. 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 necessário 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 interrupções) 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 binário
(isto é, pode estar ligado ou desligado). Contrariamente aos outros [ discutidos neste capítulo, o [
de controle não 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 implicação, 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 saídas consistem apenas
em fluxos de controle. Os fluxos de controle que partem do processo de controle são utilizados
para despertar outras bolhas; os que chegam geralmente indicam que uma das bolhas terminou a
execução de alguma tarefa, ou que alguma situação extraordinárir 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; após
desperto, o processo normal executa sua tarefa, descrita por uma especificação de processo (veja o
capítulo 11). O comportamento interno de um processo de controle é, portanto, diferente: é onde o
comportamento tempo-dependente do sistema é
214
4

Página 151 de 584
do satélite
PROCESSA
sinal do satélite DADOS DO
SATÉLITE
- _- ativar
processamento
CONTROLAR do satélite
DADOS DE VIGILÂNCIA
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
transições de estado, que mostra os vários esta dos em que todo o sistema pode estar e as
circunstâncias que conduzem a uma mudança de estado. Os diagramas de transições de estado são
discutidos no capítulo 13.
9.5 RESUMO
Como vimos neste capítulo, o diagrama de fluxo de dados é uma ferramenta simples mas poderosa
para a modelagem das funções de um sistema. O material das seções 9.1, 9.2 e 9.3 deve ser
suficiente pa ra modelar a maioria dos sistemas comerciais clássicos de informações. Se você
estiver trabalhando em um sistema de tempo-real (p.ex., con trole de processos, orientação de
mísseis ou comutação telefônica), as extensões para tempo-real discutidas na seção 9.4 serão
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 são tudo de
que precisam saber sobre análise de sistemas. Se você perguntar a um de seus colegas se ele está
familiari zado com a análise 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 análise estruturada! No entanto, isso é uma situação
perigosa: sem as ferramentas de modelagem adicionais apresentadas nos próximos capítulos, os
diagramas de fluxo de dados não têm valor. Mesmo que os relacionamentos de dados e o compor
tamento tempo-dependente do sistema sejam triviais (o que é pouco provável), ainda é necessário
combinar os DFD com o dicionário de dados (discutido no capítulo 10) e a especificação de
processos (dis cutida no capítulo 11).
Portanto, não guarde o livro ainda! Ainda há mais a aprender!
REFERÊNCIAS

Página 152 de 584
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:
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 Techníques, 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.sícs in Software Engíneering. 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.
1. Dê uma breve descrição de um diagrama de fluxo de dados. Qual é a diferença entre um DFD e
um fluxograma?
2. Apresente seis sinônimos para diagrama de fluxo de dados.
3. Em que os DFD podem ser usados além da modelagem de siste mas de informações?
4. Quais são os quatro principais componentes de um DFD?
5. Quais são os três sinônimos comuns para processo em um DFD?

Página 153 de 584
6. Existe alguma importância na escolha de um círculo paia um pro cesso? Seria melhor usar um
triângulo ou um hexágono? 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
REGISTRO
DE CLIENTE
12. Por que um analista de sistemas desenharia um DFD com un
processo composto do nome de uma pessoa ou de um grupo d
organização?
13. Os fluxos de um DFD restringem-se a mostrar apenas o moviment
de informações? 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 situação.
218
17. Qual é o significado do DFD abaixo?
xi x
\S
18. Existe algum limite para o número dc entradas e saídas que um processo pode ter em um DFD?
Qual seria sua reação ao ver um
processo com 100 entradas e 100 saídas?
19. O que está errado no DFD abaixo?
1
21. O que está errado nos DFD abaixo?
b
219

Página 154 de 584
a
c
b
c
b
24. Descreva um fluxo de diálogo.
25. O DFD abaixo é válido? Existe alguma outra maneira c
desenhá-lo?
Y
x
220
26. O DFD abaixo é válido? Existe alguma outra maneira de desenhá-lo?
27. Sob que circunstâncias você poderia ver cópias duplicadas de um fluxo de saída de um
processo?
28. Por que os DFD evitam mostrar detalhes procedurais?
29. No diagrama abaixo, quantos elementos x e quantos elementos y são necessários para produzir
uma saída z?
x
z
30. O que um depósito mostra em um DFD?
31. Qual é a convenção para a atribuição dc nomes de depósitos em um DFD?
32. Quais são os nomes alternativos para um depósito? É aceitável o emprego do termo arquivo?
Por quê?
33. Que nomes são costumeiramente utilizados para descrever pacotes de informações em um
depósito?
34. Quais são os três motivos habituais para se mostrar depósitos de implementação em um DFD?
35. Você concorda com a exibição de depósitos de implementação em um DFD? Por quê?
36. Qual é o significado de um fluxo sem rótulo entrando ou saindo de um depósito?
37. Existe algum limite para o númem dc fluxos que chegam ou saem de um depósito? Se assim
for, determine esse limite.
221
(a)

Página 155 de 584
b/
(c)
(d)
o
(e)
222
39. Quais são as quatro possíveis interpretações de um fluxo de dados que parte de um depósito
para um processo?
40. O DFD abaixo faz sentido? Por quê?
CLIENTES
registro de cliente
41. Dê um exemplo de uma situação onde um processo pode extrair partes de mais de um registro
de um depósito em um único acesso
lógico.
42. Dê um exemplo de uma situação onde um processo pode extrair mais de um pacote de
informações de um depósito em um único
acesso lógico.
43. Examinando os diagramas a seguir você pode dizer se os DFD estão corretos?
(a) _______________________
CLI ENTES
número-de-telefone
223
(b)
Cc)
CLIENTES
44. O que ocorre com um depósito depois que dados saem dele por um fluxo, para um processo?
Isso é verdadeiro para todos os tipos
de sistemas ou apenas para sistemas de informações?
45. Quais são as três possíveis interpretações da chegada de um fluxo a um depósito?
46. Como podemos mostrar pacotes de dados sendo eliminados Cdeletados”) de um depósito?
CLIENTES
dados-de-inventário
trajetória-do-míssil
224

Página 156 de 584
48. Qual é o propósito 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?
(a)
(b) ________
CLIENTE 1
SISTEMA
DE PEDIDOS
(c)
impostos
(d)
225
52. O analista de sistemas pode alterar o conteúdo ou a organização de um terminador como parte
de seu projeto? E se ele achar que deve
ser modificado’
53. Por que um processo não deve ter o nome da pessoa que pre sentemente desempenha aquela
função?
54. Qual é uma boa diretriz para atribuir nomes a processos em um
DFD?
55. Dê cinco exemplos de nomes de processos que você não gostaria de ver em um DFD.
56. Como você pode afirmar se o nome escolhido para um processo é significativo?
57. Qual é o erro de interpretação que o usuário pode cometer em relação aos números das bolhas
de um DFD?
58. Como se pode saber se um DFD será muito complexo para ser entendido pelo usuário?
59. Quão rigidamente deve ser obedecida a diretriz da complexidade? Deve ser permitida alguma
exceção? Por quê?
60. Por que é freqüentemente necessário redesenhar um DFD muitas vezes?
61. Quais são os principais aspectos que determinam se um DFD é esteticamente agradável? Você
acha que esses aspectos podem ser
expressos como padrões?
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 são as

Página 157 de 584
vantagens e desvantagens de cada tipo? Esse aspecto é importante?
64. O que é um poço sem fundo? Por que a presença dele deve ser considerada um erro em um
DFD típico?
65. Que são bolhas de geração espontânea em um DFD? Por que devem ser evitadas em um DFD?
66. Por que os fluxos e processos sem rótulo são perigosos?
67. Por que os depósitos de leitura-apenas e de escrita-apenas con figuram-se habitualmente como
um erro em um DFD?
68. Por que os DFD em níveis são importantes no modelo de um sistema?
69. Quantos níveis de DFD um analista de sistemas deve esperar encontrar em um típico sistema de
grande porte? Você pode sugerir
um limite superior para o número de níveis em um DFD?
70. Em um DFD em níveis:
(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 nível superior existem acima da figura na qual aparece a bolha 2.3? Como
são chamadas?
71. É necessário que todas as partes de um sistema sejam subdivididas nos mesmos níveis de
detalhamento? Por quê?
72. Suponha que alguém lhe mostre um DFD no qual a bolha 1 esteja subdividida em dois níveis
inferiores e a bolha 2 esteja subdividi da em 17 níveis inferiores. Qual seria sua reação? Que reco
mendações, se houver alguma, você faria?
73. Que significa equilíbrio, no contexto deste capítulo? Como se pode dizer se um DFD está
equilibrado?
74. Por que a figura 9.22(b) deste capítulo está desbalanceada?
75. Qual é a diretriz para a exibição de depósitos em diferentes níveis de um DFD?
76. O que é um depósito local? Quais são as diretrizes para a exibição de um depósito local em um
DFD em níveis?
77. Projeto de Pesquisa: qual é a relação entre a diretriz para a exibição de depósitos locais e o
conceito de projeto orientado para o objeto?
Para isto detalhes sobre isso, leia os capítulos 19 e 20.
78. Que problemas podem estar associados ao desenvolvimento de um conjunto de DFD em níveis
na metodologia top-down (em comparação 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 depósito de controle? Por que é diferente de um depósito normal de um DFD?

Página 158 de 584
82. Desenhe um diagrama de fluxo de dados para modelar a seguinte receita de Fruits de Mer au
Riz (Mexilhões com Arroz), tirada do Tbe New York Times 60-Minute Gourmet, por Pierre Franey
(Nova lorque: TIMES Books, 1979).
“1. Para começar, prepare e meça todos os ingredientes para o arroz. Para
ganhar tempo, pique uma xícara extra de cebola e 2 dentes extras de
alho para a mistura. Deixe de lado.
2. Aqueça 2 colheres de sopa de óleo para o arroz em uma panela e acrescente 1/4 de xícara de
cebola, pimentão e alho e aqueça até ficar
cozido. Acrescente o açafrão e cozinhe por mais 2 minutos.
3. Acrescente arroz, água, sal e pimentão e tampe. Aqueça 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. Aqueça, em uma caçarola, 1/4 de xícara de óleo e acrescente uma xícara de cebolas e 2 dentes de
alho. Mexa e aqueça até ficar cozido. Acrescente pimentão vermelho, tomates, vinho e orégano.
Acrescente sal e pimenta. Tampe e cozinhe por 10 minutos.
5. Coloque os mariscos e mexilhões na panela e tampe de novo. Aqueça por 3 minutos e acrescente
os camarões, escalopes, sal e pimenta a seu
gosto. Tampe e aqueça 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 organização. Antes de cozinhar, pique o que for preciso
picar e meça o que tiver de ser medido. Providencie as panelas e caçarolas que forem necessárias
para o serviço - neste caso, duas frigideiras (uma para os escalopes e outra para os tomates) e uma
caçarola (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 não se
toquem para que não grudem.
3. Os escalopes devem ser cozidos em fogo alto em pequenas quantidades. Aqueça 3 colheres de
sopa de óleo e 1 de manteiga em uma frigideira grande. Quando a mistura estiver bem quente, mas
não fumegando, acrescente metade dos escalopes, mexendo-os e agitando- os na frigideira de modo
a que cozinhem rápida e uniformemente até adquirirem um marrom dourado.
4. Use uma colher fendida para transferir os escalopes para uma travessa quente. Acrescente as 2

Página 159 de 584
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 aqueça até ficar marrom claro ou acastanhado. Salpique os escalopes com suco
de limão 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 começar a preparar os omeletes, quebre três ovos para cada omelete em tantas tigelas
quantas forem necessárias 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 também podem
ser batidos para acelerar o preparo dos omeletes.
1. Aqueça 2 colheres de sopa de manteiga em uma caçarola e junte farinha de trigo. Bata com um
batedor de ovos até que fique bem mis turado. Junte o caldo de frango e aqueça, batendo
vigorosamente com o batedor. Coloque o creme e deixe ferver. Ferva por cerca de 10 minutos.
2. Enquanto isso, aqueça outra colher de sopa de manteiga em uma caçarola e acrescente cebola.
Aqueça, 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. Aqueça 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 suíço ralado. Aqueça 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. Aqueça as 3
colheres restantes de manteiga em uma omeleteira ou em uma frigideira de Teílon 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 parmesão ralado. Ponha
para assar na grelha até ficar marrom-dourado.
NOTAS
Entretanto, a desvantagem do MacDraw (e de outros programas do
gênero) é 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

Página 160 de 584
retângulos, círculos e linhas. Os produtos do estojo de ferramentas
do analista de sistemas, discutidos no apêndice A,são 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 análise
estruturada. O círculo é associado ao campo “Yourdon/DeMarco’,
por ser utilizado em vários 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 várias outras
empresas. O retângulo é comumente associado ao campo ‘SADT”,
por ter sido popularizado em vários artigos sobre a Softech
Structured Analysis Design Technique (SADT); veja, por exemplo,
[ e Schoman, 1977],
3 Uma alternativa aceitável para o diálogo é a utilização de vários
fluxos, um mostrando a entrada (consulta) para o processo e o ou
tro exibindo a saída (resposta). Essa é, de fato, a melhor maneira
de manipular casos em que uma entrada pode levar a várias ações
(e respostas) completamente diferentes por parte do processo. No
caso de uma situação simples de consulta-resposta, o uso de um
fluxo de diálogo ou de fluxos separados de entrada e saída é uma
questão de escolha. A maioria dos analistas de sistemas prefere a
representação de diálogo porque (1) ela atrai a atenção para o fato
de que a entrada e a saída são 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 multiplicação e/ou decomposição de
pacotes de dados ocorre é considerado um problema de
implementação, isto é, algo com que o projetista de sistemas terá
de se preocupar, mas não é algo que o analista de sistemas precise
mostrar no modelo do sistema. Ele pode eventualmente ser

Página 161 de 584
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 multiplicação/de composição dos
dados. Discutiremos isso mais detalhadamente na parte III.
5 A notação Dl na figur” 99(b) é apenas um esquema de numeração
para que se possa distingüir aquele depósito dos demais depósitos
do diagrama. A convenção seguida neste livro não envolve a ro
tulação e a numeração dos depusitos (por parecer desnecess rio e
230
inútil), mas (como veremos na seção 9.2) envolve a numeração das bolhas.
6 Também é comum alguém se referir a um pacote de informações do depósito como um registro e
aos componentes de cada pacote como campos. Nada há de errado com essa terminologia, mas ela
é usada com tanta freqüência 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 ocorrência de uma coleção de objetos relacionados no depósito.
7 Neste capítulo mencionaremos várias convenções como essa, bem como convenções semelhantes
relativas a outras ferramentas de modelagem. Seu gerente de projeto, o manual de padrões de sua
empresa ou a ferramenta CASE que você usa em seu projeto (veja o apêndice A) podem obrigá-lo
a utilizar uma determinada convenção; mas você pode perceber que existe uma certa flexibilidade
quanto às ferramentas de modelagem e notação de modelagem aqui apresentadas. O importante é a
consistência:
todos os fluxos com pacotes entram ou saem dos depósitos quer estejam consistentemente
rotulados quer estejam consistentemente não-rotulados.
8 Como sabemos que os rótulos do fluxo têm algo a ver com os componentes de um pacote de
informações do depósito? Como sa bemos, por exemplo, que um fluxo rotulado NÚMERO-DE-
TELEFONE tem algo a ver com os pacotes de informações do depósito CLIENTES? Existe a
tentação, 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 definição da composição de um pacote
de CLIENTES, que é encontrada no dicionário de dados, que discutiremos no capítulo 10.
9 Se você estiver utilizando um DFD para modelar algo além de um sistema de puro
processamento de informações, isso pode não ser verdadeiro. Por exemplo, o depósito pode conter
itens físicos e o fluxo pode ser um mecanismo para transportar material de depósito para o
processo. Neste caso, um pacote seria removido fisicamente do depósito, e o depósito sofreria uma
redução em seus itens como resultado. Em um modelo de sistema contendo depósitos de
informações e depósitos físicos, é importante acrescentar notas ao DFD (ou colocar uma explicação
no dicionário de dados) para que o leitor não se confunda.
10 Essa diretriz provém de ‘The Magical Number Seven, Plus or Minus

Página 162 de 584
Two”, de George MilIer, Psychology Review, 1956.
231
11 Na verdade, existem algumas coisas que podemos fazer: se houver
vários fluxos de dados entre um terminador e a bolha única do
sistema, podemos consolidá-las em um único fluxo de dados, O di
cionário de dados, discutido no capítulo 10, será usado para
explicar a composição 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 usuários com diferentes
interesses), podem ser desenhados diferentes diagramas de con
texto para realçar apenas os terminadores e fluxos em que cada
grupo de usuários estiver interessado. Porém, na maioria dos casos,
não há como escapar disso: se o sistema como um todo for in
trinsecamente complexo, o diagrama de contexto também o será.
O capítulo 18 apresenta mais detalhes sobre esse aspecto.
12 A não ser que você considere que os aviões sejam diferentes dos
sistemas automatizados de informacões ou que eles sejam mais
críticos, lembre-se que os sistemas de processamento hoje con
trolam a maioria dos aviões em que você viaja; um grande avião
de passageiros de tipo comum pode ter uma dúzia ou mais de
complexos sistemas de processamento, que, por sua vez, têm
interface com complexos sistemas de tempo-real como o que é
utilizado pela Federal Aviation Administration para monitorar o
espaço aéreo em torno dos aeroportos.
13 Existe uma convenção idiomática que viola essa diretriz, que é
discutida na seção 9.13: um fluxo sem rótulo entrando ou saindo
de um depósito é, por convenção, uma indicação de que toda uma
instância (ou um registro) está sendo introduzido ou retirado desse
depósito.
14 Por vezes pode não ser evidente de imediato se o depósito tem
tanto entradas como saídas. Como veremos na próxima seção, os
DFD são muitas vezes subdivididos em partes; desse modo,
emos nos deparar com uma parte do sistema que aparenta ter
depósitos de leitura-apenas (ou escrita apenas). Algum outro

Página 163 de 584
trecho do sistema, documentado em um DFD separado, pode ter a
atividade de escrita-apenas (ou leitura-apenas) que falta. São
necessárias muitas tediosas verificações de consistência 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 análise de sistemas discutidos no apêndice A são extre
mamente valiosos.
15 Também é 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 inclusão de depósitos de controle ou depósitos
de eventos, que são análogos ao conceito de semáforos, apresentados primeiramente por Dijkstra
em [ 1968]. Para detalhes complementares, veja [ e Melior, 19851.
233
lo
O DICIONÁRIO DE DADOS
Os dicionários são como relógios; o pior é melhor do que nenhum, e não
se pode esperar que o melhor seja totalmente fieL
Mrs. Priozzi, Anecdotes ofSamuelJohnson, 1786
1. Porque precisamos de um dicionário de dados em um projeto de desenvolvimento de sistemas.
2. A notação para definições de dicionários de dados.
3. Como um dicionário de dados deve ser apresentado ao usuário.
4. Como implementar um dicionário de dados.
A segunda ferramenta importante de modelagem que estudaremos é o dicionário de dados. Embora
ele não tenha o fascínio e o encanto gráfico dos diagramas de fluxo de dados, dos diagramas de
entidade reladonamentos e dos diagramas de transições de estado, o dicionário de dados é
fundamental. Sem ele, seu modelo de requisitos do usuário não pode ser considerado completo;
será apenas um esboço grosseiro, uma “representação artística” do sistema.
A importância do dicionário 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, também, os cursos
de línguas estrangeiras, especialmente aquelas que exigiam
235

Página 164 de 584
que você lesse livros e revistas. Sem um dicionário, você estaria perdido. O mesmo pode ser dito
em relação ao dicionário de dados em análise de sistemas: sem ele, você estará perdido, e o usuário
não terá certeza de você haver entendido os detalhes da aplicação.
A expressão dicionário de dados é quase auto-explicativa. O di cionário de dados é uma listagem
organizada de todos os elementos de dados pertinentes ao sistema, com definições precisas e
rigorosas para que o usuário e o analista de sistemas possam conhecer todas as entra das, saídas,
componentes de depósitos e cálculos intermediários, O di cionário de dados define os elementos de
dados da seguinte maneira:
• Descrevendo o significado dos fluxos e depósitos mostrados nos diagramas de fluxo de dados.
• Descrevendo a composição de pacotes agregados de dados que se movimentam pelos fluxos, isto
é, pacotes complexos (como o endereço de um cliente) que podem ser divididos em itens mais
elementares (como cidade, estado e código postal).
• Descrevendo a composição dos pacotes de dados nos depósitos.
• Especificando os relevantes valores e unidades de partes ele mentares de informações dos fluxos
de dados e depósito de
dados.
• Descrevendo os detalhes dos relacionamentos entre os depósi tos realçados em um diagrama
entidades-relacionamentos. Esse aspecto do dicionário de dados será estudado em mais detalhes no
capítulo 12 após termos apresentado a notação de entidades- relacionamentos.
10.1 A NECESSIDADE DA NOTAÇÃO DE DICIONÁRIO DE DADOS
Na maioria dos sistemas do mundo real em que vamos trabalhar os pacotes ou elementos de dados
serão suficientemente complexos para que você precise descrevê-los em termos de outras coisas.
Os elementos de dados complexos são definidos em termos de elementos de dados mais simples, e
elementos de dados simples são definidos em termos das unidades válidas e dos valores que eles
podem assumir.
Pense, por exemplo, na maneira como você responderia à seguinte
pergunta de um marciano (que é como muitos usuários vêem os ana listas de sistemas!) sobre o
significado do nome de uma pessoa:
236
Marciano: «Então, o que é um nome?”
Você (demonstrando impaciência): «Bem, você sabe, é somente
um nome. Quero dizer, é como, bem, é como nós 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 ignorância desse estranho):
“Não, certamente que não. Um nome é sempre o mesmo. O nome de
uma pessoa é o que nós usamos para distingui-la de outras pessoas.”

Página 165 de 584
Marciano (entendendo subitamente): “Ahh, agora eu entendi.
Nós fazemos a mesma coisa no meu planeta. Meu nome é
3.141592653589793238462643.”
Você (incrédulo): «Mas isso é um número e não um nome.”
Marciano: “E é um nome muito bom, também. Eu Sinto orgulho dele. Ninguém 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? Não entendi. Eu tenho somente um
nome, e é sempre o mesmo.”
Você: “Bem, não é assim que fazemos aqui. Nós temos um primei ro nome, e um último nome, e às
vezes temos um nome intermediário
também.”
Marciano: “Isso quer dizer que você pode ser chamado de 23
45 99?”
Você: “Não, nós não permitimos números em nossos nomes. Só utilizamos os caracteres
alfabéticos 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 não têm noção do
significado de um nome. Mas isso não está muito distante das discussões que ocorrem (ou
deveriam ocorrer) entre um analista de sistemas e um usuário, nas quais as seguintes perguntas
poderiam ser feitas:
237
• Todos devem ter um primeiro nome? E o personagem “Mr. T conhecida série de TV, “The A
Team”?
• E os caracteres de pontuação no último nome de urna pes como, por exemplo, “D’Arcy”?
• Os nomes centrais podem ser abreviados, como, por exemj “John X James”?
• Existe a exigência de um comprimento mínimo para o nome uma pessoa? Por exemplo, o nome
“X Y” é válido? (Podc imaginar que isto poderia causar grandes problemas nos temas de
processamento através do país, mas, existe algu razão legal/comercial para que uma pessoa não
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, legítimo, mas o Jr. deve ser considen parte do
último nome ou uma nova categoria especial? E se uma nova categoria, devemos permitir também
dígitos num cos como Sam Smith 3rd?
Observe, a propósito, que nenhuma dessas perguntas tem alg ver com a maneira como
eventualmente armazenamos as informaçi no computador; estamos tentando apenas determinar,
como um assu de interesse da orientação comercial, o que constitui um nome válidi
Como se pode imaginar, é um tanto tedioso descrever a comj sição de elementos de dados em

Página 166 de 584
forma de narrativa. Precisamos de u notação concisa e compacta, como um dicionário padronizado
Webst que tem uma notação compacta e concisa para definir o significado palavras comuns.
10.2 NOTAÇÃO DE DICIONÁRIO DE DADOS
Existem muitos esquemas de notação 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)
{} iteração
238
E 1 escolha uma das opções alternativas
‘ comentário
@ identificador (campo chave) de um depósito
1 separa opções alternativas na construção E]
Para exemplificar, podemos definir nome para nosso amigo marciano da seguinte maneira:
nome - título-cortesia + primeiro-nome + (nome
Intermediário) + último-nome
título-cortesia - [ 1 Srta. 1 Sra. Sras. 1 Dr. 1 Professor]
primeiro-nome - (caracter-válido)
nome-intermediário - (caracter-válido)
último-nome - (caracter-válido)
caracter-válido - [ II
Como se pode ver, os sImbolos parecem bastante matemáticos; você talvez receie que isso seja
demasiadamente complicado para se compreender. Como logo veremos, a notação é muito fácil de
ler. A experiência de alguns milhares de projetos de PD e algumas dezenas de milhares de usuários
nos mostraram que a notação também é compreen sível para quase todos os usuários se apresentada
apropriadamente, estudaremos isso na seção 10.3.
10.2.1 Definições
Uma definição de elemento de dados é apresentada com o símbolo
““““; neste contexto, o “=“ é lido como “é definido como”, ou «é compos to de”, ou simplesmente
“significa”. Então, a notação
A-B+C
poderia ser lida de qualquer das maneiras seguintes:
• Sempre que dissermos A, queremos dizer B e C

Página 167 de 584
• A compõe-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 usuário. Isso é normalmente
apresentado como um co mentário, usando-se a notação “
• A composição 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 não possa ser decom posto.
Deste modo, se estivéssemos construindo um sistema médico que
controlasse pacientes poderíamos 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: centímetros; intervalo: 20-200 *
Observe que descrevemos as unidades e os Inteivalos relevantes com caracteres «‘“ cor
Novamente, essa é uma convenção de notação considerada prática por muitas organizações, mas
que pode rá ser alterada se necessário.
Além das unidades e do intervalo, você também pode precisar es pecificar a exatidão ou a precisão
com que o elemento de dados é me dido. Para um elemento de dados como preço, por exemplo, é
impor tante indicar se os valores serão expressos na forma inteira, até o último centavo etc. E, em
muitas aplicações de engenharia e científicas, é importante indicar o número de dígitos
significativos no valor dos ele mentos de dados.
10.2.2 Elementos de dados elementares
Elementos de dados elementares são aqueles para os quais não existe decomposição significativa
no contexto no ambiente do usuário. Isto é, muitas vezes, uma questão de interpretação e que deve
ser explo rada cuidadosamente com o usuário. Por exemplo, vimos na discussão acima que o termo
nome poderia ser decomposto em último-nome,
240
primeiro-nome, nome-Intermediário e título-cortesia Mas, talvez, em alguns ambientes nenhuma
dessas decomposições seja necessária, relevante ou mesmo significativa (isto é, onde os termos
último-nome etc, não têm significado para o usuário).
Quando os itens de dados elementares tiverem sido identificados, devem ser introduzidos no
dicionário de dados. Como indicado acima, o dicionário de dados deve apresentar um ligeiro
comentário narrativo, entre os caracteres ‘“, descrevendo o significado do termo no contexto do
usuário. Certamente, poderão existir alguns termos que sejam auto- explicativos, isto é, termos

Página 168 de 584
cujos significados são universalmente os mesmos em todos os sistemas de informações, ou que o
analista de sistemas pode concluir que não é necessária nenhuma outra elaboração. Por exemplo, os
seguintes termos podem ser considerados como auto- explicativos em um sistema que mantenha
informações sobre pessoas:
altura-atual
peso-atual
data-de-nascimento
sexo
telefone-residencial
Nesses casos, nenhum comentário narrativo é necessário; muitos analistas de sistemas utilizam a
notação “‘“ 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 não presente como um
componente dc um elemento de dados composto. Existem muitos exemplos de elementos de dados
opcionais em sistemas de informações:
• Um nome de cliente poderá ou não incluir um nome interme diário.
• Um endereço de cliente poderá ou não incluir alguma infor maçào secundária como o número do
apartamento.
• Um pedido de um cliente poderá conler um endereço de co brança, um endereço para remessas ou
possivelmente ambos.
Situações como esta última devem ser cuidadosamente conferidas
com o usuário e devem ser cuidadosamente documentadas no dicionário
de dados. Por exemplo, a notação
endereço-cliente = (endereço-de-remessa) + (endereço-de cobrança)

Página 169 de 584
significa, literalmente, que o endereço do cliente poderia constituir-
se de:
• apenas do endereço de remessas
ou
• apenas do endereço de cobrança
ou
• o endereço de remessas e o endereço de cobrança
ou
• nem do endereço de remessa nem do endereço de cobrança
A última possibilidade é um tanto duvidosa. É bem mais provável que o usuário realmente pretenda
que o endereço de cliente deva con sistir em um endereço de remessas ou em um endereço de
cobrança ou em ambos. Isto poderia ser expresso da seguinte maneira:
242
endereço-de-cliente - [ 1 endereço-de cobrança 1 endereço-de-embarque+
endereço-de-cobrança]
Alguém também poderia objetar que em uma atividade de pedidos pelo correio, é sempre
necessário o endereço de remessa para onde deve ser enviado o pedido do cliente; um endereço de
cobrança separado (p.ex., departamento de contabilidade do cliente) é opcional. Assim sendo, é
possível que a política verdadeira da empresa do usuário ficaria mais bem expressa por:
endereço-do-diente - endereço-de-remessa + (endereço-de cobrança)
Porém, certamente, o único meio de ter certeza disso é chamar o
usuário e explicar-lhe, cuidadosamente, as implicações das diferentes
notações mostradas acima 2•
10.2.4 Iteração
A notação de iteração é usada para indicar a ocorrência repetida de
um componente de um elemento de dados. Ela é lida como “zero ou
mais ocorrências de”. Deste modo, a notação
pedido - nome-do-cliente + endereço-de-remessa + fitem)
significa que um pedido deve conter sempre o nome do cliente e o en dereço de embarque, e
conter, também, zero ou mais ocorrências de um item. Dessa maneira, poderemos lidar com um
cliente que apresente um pedido envolvendo apenas um item ou dois itens, ou alguém em fúria
compradora que decide pedir 397 itens diferentes .
Em muitas situações do mundo real, o usuário desejará especificar os limites superior e inferior da
iteraçáo. No exemplo acima, o usuário provavelmente afirmará que não faz sentido que um cliente
apresente um pedido com zero itens; deve haver pelo menos um item no pedido. E o usuário pode
desejar especificar um limite superior; talvez 10 itens seja o máximo que será permitido. Podemos
indicar limites superiores e inferiores da seguinte maneira:

Página 170 de 584
pedido - nome-de-cliente + endereço-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 especificações a
seguir são válidas:
243
a 1{b}
a - (b}1O
a = 1(b}1O
a = {b}
10.2.5 Seleção
A notação de seleção indica que o elemento de dados consiste er exatamente uma escolha de um
conjunto de opções alternativas. A opções são delimitadas por colchetes “E” e “1” e separadas pelo
caracter de barra vertical “1”. Exemplos típicos S
sexo [ 1 Feminino]
tipo de cliente = [ 1 Indústria 1 Universidade 1 Outro]
É importante rever as opções de seleção com o usuário para garan tir que todas as possibilidades
foram identificadas. No último exemplo, usuário podia tender a concentrar sua atenção nos clientes
“do governo’ “da indústria” 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 Sinônimus
Um sinônimo (um “alias”), como o termo indica, é um nome altei nativo para um elemento de
dados. É uma ocorrência comum quando s lida com grupo diversificado de usuários, muitas vezes
em departamer tos diferentes ou localizações geograficamente diferentes (e algumas ve zes com
diferentes nacionalidades e línguas), que insistem em utiliza nomes diferentes para indicar a mesma
coisa. O sinônimo é incluído n dicionário de dados por uma questão de completude, e deve ter uma
rc ferência cruzada com o nome principal ou oficial do dado. Por exemplc
cliente = sinônimo de cliente
Observe que a definição de cliente não mostra a composição (i5
to é, não mostra que um cliente consiste em nome, endereço, telefon
244
1
etc.). Tcdos esses detalhes devem ser fornecidos somente no nome principal para diminuir a
redundancia no modelo ‘.
Mesmo que o dicionário de dados relacione corretamente os sinô nimos aos nomes de dados, deve-
se evitar o uso de sinônimos sempre que possível. Isso porque os nomes de dados são comumente
vistos primeiro, e são mais visíveis por todos os usuários, nos diagramas de fluxo de dados, onde
possa não ser evidente que freguês e cliente sejam sinônimos. É muito melhor, se for possível,

Página 171 de 584
conseguir que os usuários concordem com um nome comum
10.3 APRESENTAÇÃO DO DICIONÁRIO DE DADOS AO USUÁRIO
O dicionário de dados é criado pelo analista de sistemas durante o desenvolvimento do modelo do
sistema, mas o usuário deve ser capaz de ler e compreender o dicionário de dados para conferir o
modelo. Isso dá origem a algumas perguntas óbvias:
• Os usuários são capazes de compreender a notação do di cionário de dados?
• Como os usuários verificam se o dicionário está completo e correto?
• Como é criado o dicionário?
A questão da aceitação pelo usuário da notação do dicionário é ‘uma tentativa para se desviar do
assunto” em muitos casos. Sim, a nota ção do dicionário parece um tanto matemática; mas, como já
vimos, o número de simbolos que o usuário tem que aprender é pequeno. Os usuários estão
habituados a diversas notações formais no trabalho e na vida pessoal; considere, por exemplo, a
notação de pauta musical, que é muito mais complexa.
:
Piar 1 ao!!
J’i
H
-
HHHL
,
Figura 10.1: A notação da pauta musical
245
--
1
4
Á
Á
1
.:..
I
1
k
::::
.:.. .
:...•:

Página 172 de 584
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: Notação de xadrez
Similarmente, a notação para bridge, xadrez e para diversas outras
atividades é, pelo menos, tão complexa quanto a notação de dicionário
de dados mostrada neste capítulo.
A questão da verificação do dicionário de dados pelo usuário cos tumeiramente leva á pergunta:
«os usuários devem ler o dicionário intei ro, item por item, para se certificarem de que esteja
correto?” É difícil imaginar que algum usuário queira fazer isso! É mais provável que o usuário
verifique a exatidão do dicionário de dados em combinação com o diagrama defluxo de dados, com
o diagrama de entidades-relaciona mentos, com o diagrama de transições de estado ou com as
espec ções de processos que esteja lendo.
Existem alguns problemas de correção que o analista de sistemas pode executar pessoalmente, serr
a assistência do usuário: ele pode assegurar que o dicionário esteja :ompleto, consistente e sem
contradi ções. Desse modo, ele pode exan mar o dicionário e formular as seguin tes perguntas:
• Todos os fluxos no diagrama de fluxo de dados foram definidos no dicionário de dados?
246
• Todos os componentes dos elementos de dados compostos foram definidos?
• Algum elemento de dados foi definido mais de uma vez?
• A notação correta foi utilizada em todas as definições do di cionário de dados?

Página 173 de 584
• Existe algum elemento de dados no dicionário de dados que não esteja referenciado nos
diagramas de fluxo de dados, nos diagramas de entidades-relacionamentos ou nos diagramas de
transições de estado?
10.4 A IMPLEMENTAÇÃO DO DICIONÁRIO DE DADOS
Em um sistema de médio ou grande porte, o dicionário de dados pode representar um volume
muito grande de trabalho. Não é incomum vermos um dicionário de dados com milhares de
entradas, e mesmo um sistema relativamente simples poderá ter várias centenas de entradas. Deste
modo, alguma atenção deve ser dada à maneira com que o dicio nário estará sendo desenvolvido,
ou a tarefa provavelmente sobrecarre gará o analista de sistemas.
A abordagem mais fácil é fazer uso de um recurso automatizado (computadorizado) para introduzir
as definições do dicionário, verificá las relativamente à complementação e consistência, e produzir
informa ções adequadas. Se a sua organização estiver usando algum qualquer sistema moderno de
gerenciamento de banco de dados (p.ex., IMS, ADABAS, TOTAL, IDMS), um recurso de
dicionário já está disponível. Nesse caso, você pode tirar proveito dessa vantagem e utilizá-la para
construir o seu dicionário de dados. Entretanto, cuidado com as seguin tes possíveis limitações:
• Você poderá ser forçado a limitar os nomes em um certo com primento (p.ex., 15 ou 32
caracteres). Isso, provavelmente, não será um grande problema, mas pode acontecer de o seu
usuário in com um nome como destino-da-remessa-do-cliente e que o seu pacote de dicionário de
dados o obrigue a abreviar o nome para dest-rem-dli.
• Outras limitações artificiais podem ser colocadas no nome. Por exemplo, o caractere hífen “-“
pode não ser permitido, e você
talvez seja forçado a utilizar no lugar dele o sublinhado “_“. Ou
247
você pode ser forçado a prefixar (ou sufixar) todos os nomes com um código do projeto indicando
o nome do projeto de desenvolvimento dos sistemas, con duzindo a nomes como
acct.pay.GHZ.345P14.fornecedor_telefone_número.
• Você pode ser forçado a designar atributos fisícos (p.ex., o nú mero de bytes ou blocos de
memória em disco, ou certas repre sentações de dados como decimais compactados) para um item
de dados, mesmo que não seja uma exigência do usuário, O dicionário de dados estudado neste
capítulo deve ser um di cionário de análtses e não deve cxig decisões desnecessárias ou irrelevantes
de implementação.
Alguns analistas de sistemas também estão começando a usar pa cotes automatizados de
ferramentas que incluem recursos gráficos para diagramas de fluxo de dados, e congêneres, bem
corno aptidões de di cionário de dados. Novamente, se tal recurso existir, você deve usá-lo. As
ferramentas automatizadas serão discutidas em maiores detalhes no apêndice A.
Se você não dispuser de nenhum recurso automatizado para construir o dicionário 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 definições do dicionário 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

Página 174 de 584
Apple Macintosh) para construir e gerenciar o seu dicionário de dados.
Somente nos casos mais extremos você deve recorrer a dicionários de dados manuais, isto é, 3 a 5
cartões indexados para cada entrada do dicionário. Esse recurso foi muitas vezes necessário 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 organizações mantiveram seus
programadores e analistas de siste mas na Idade Média. Os filhos do sapateiro, como se diz, são
habitual mente os últimos a ganharem sapatos. Mas isso hoje é imperdoável; se você estiver
trabalhando em um projeto onde não tenha acesso a um pacote de dicionário de dados ou a uma
ferramenta automatizada de análise ou a um computador pessoal ou a um sistema de proces
samento de palavras, então, você deve (1) desistir e encontrar um tra balho melhor, ou (2) obter seu
próprio computador, ou (3) as duas coisas simultaneamente.
248
10.5 RESUMO
A construção de um dicionário de dados é um dos aspectos mais tediosos e consumidores de tempo
da análise de sistemas. Mas é também um dos aspectos mais importantes: sem um dicionário
formal que defina o significado de todos os termos, não haverá esperanças de precisão.
No próximo capítulo veremos como usar o dicionário de dados e o
diagrama de fluxo de dados para construir especificações de processos
para cada um dos processos de baixo nível.
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.
1. Defina dicionário de dados.
2. Por que é importante um dicionário de dados em análise de sistemas?
3. Quais as informações que um dicionário de dados fornece sobre um elemento de dados?
4. Qual é o significado da notação ‘=“ em um dicionário de dados?
5. Qual é o significado da notação “+“ em um dicionário de dados?
6. Qual é o significado da notação “O” em um dicionário de dados?
7. Qual é o significado da notação { }“ em um dicionário de dados?
8. Qual é o significado da notação “liii em um dicionário de dados?
9. Você acha que os usuários com os quais trabalha podem enten der a notação padrão de dicionário
de dados apresentada neste ca pítulo? Em caso negativo, pode sugerir uma alternativa?

Página 175 de 584
10. Dê um exemplo de um item de dados elementar.
11. Dê três exemplos de elementos de dados opcionais.
12. Quais são os possíveis significados das expressões abaixo?
(a) endereço = (cidade) + (estado)
(b) endereço end-rua + cidade + (estado) + (código postal)
249
13. Dê um exemplo do uso da notação { 1 de iteração.
14. Qual é o significado de cada uma das notações 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 + endereço-de-remessas + 6{Item}
Por quê?
16. Dê um exemplo da construção ( de seleção.
17. Qual é o significado de um sinônimo (alias) em um dicionário de dados?
18. Por que a utilização de sinônimos deve ser minimizada sempre que for possível?
19. Que espécie de anotação pode ser usada em um DFD para indicar que o elemento de dados é
um sinônimo?
20. Quais os três principais problemas que o usuário encontra ao exa minar um dicionário de
dados?
21. Na sua opinião os usuários na sua organização serão capazes de compreender a notação de
dicionário de dados?
22. Na sua opinião a notação de dicionário de dados mostrada neste capítulo é mais complexa ou
menos complexa do que a notação
musical?
23. Quais são as três atividades de verificação de erros que o ana lista de sistemas pode executar no
dicionário de dados sem o
usuário?
24. Quais são as possíveis limitações de um pacote de dicionário de dados automatizado?
25. Dê uma definição de dicionário de dados para nome-de-cliente baseada na seguinte
especificação verbal de um usuário: “Quando nos lembramos do nome de um cliente, temos o
cuidado de incluir um título de cortesia que pode ser “Sr.”, ‘Srta.”, “Sra.”, “Srs.”, ou “Dr.”
(Existem muitos outros títulos como “Professor”, “Sir” etc., porém não nos ocuparemos deles).
Cada um dos nossos clientes tem um primeiro nome, mas nós permitimos uma única inicial se eles

Página 176 de 584
preferirem. Nomes intermediários são opcionais. E, natu ralmente, o último nome é obrigatório;
permitimos muitos tipos de últimos nomes, incluindo nomes com hifens (“Smith-Frisby”, por
exemplo) e apóstrofos (“D’Arcy”) 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 definições de dicionário 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 seção 9.2, quais são as implicações da definição de altura e peso?
Comentário: ela indicaria que somente medimos em unidades integrais e não controlamos os
centímetros, e assim por diante.
28. Escreva uma definição de dicionário de dados das informações contidas na sua carteira de
motorista. Se você não a possuir, en contre um amigo que possua uma.
29. Escreva uma definição de dicionário de dados das informações contidas no cartão de crédito de
um banco adequado (p.ex.,
Mastercard ou Visa).
30. Escreva uma definição de dicionário de dados das informações contidas em um passaporte.
31. Escreva uma definição de dicionário de dados das informações contidas em um cartão de
loteria.
NOTAS
Por outro lado, é provável que a política de negócios atualmente em vigor seja fortemente
influenciada pelos sistemas de processa mento que a organização vem utilizando nos últimos 30
anos. Há cinqüenta anos, uma pessoa poderia ser considerada excêntrica se decidisse se chamar
“Fre5d Smi7th mas isso provavelmente seria aceito por muitas organizações, porque os nomes
eram transcritos para pedaços de papel por mãos humanas. Os primeiros sistemas de
processamento (e a maioria deles, atualmente) têm um pouco mais de dificuldades com nomes fora
do comum.
2 Existe uma possibilidade que poderia explicar a ausência do en dereço de remessas e do endereço
de cobrança em um pedido do cliente: o cliente eventual que deseja comprar um item e levá-lo
consigo. É provável que quiséssemos 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

Página 177 de 584
tratados de modo diferente (por exemplo, seus pedidos não terão quaisquer cobranças de embar
que), e (2) é um bom meio de efetuar a dupla verificação e garan tir que a falta do endereço-de-
embarque ou do endereço-de- cobrança constitui um erro.
3 Lembre-se uma vez mais que estamos definindo o significado técnico intrínseco de um elemento
de dados, sem considerar a tecnologia que será usada para implementá-lo. É provável, por
exemplo, que nossos projetistas de sistemas venham solicitar um limite superior razoável para o
número 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 número de itens em 64. É improvável que qualquer pessoa deseje pedir mais do que 64
itens diferentes, e se isso acontecer, basta apresentar mais de um pedido”. E o usuário pode ter suas
próprias limitações, funda mentadas nos formulários em papel ou nos relatórios impressos com que
ele lida; isso faz parte do modelo de implementação do usuã rio, que discutiremos no capítulo 21.
4 Você pode ignorar esta advertência se estiver usando um pacote automatizado de dicionário de
dados que possa gerenciar e con trolar a redundância, embora isso seja bastante incomum, O ponto
principal a ser lembrado é que se modificarmos a definição de um elemento primário de dados (p.
ex., se decidirmos que a definição de um cliente não mais deve incluir o número do telefone) a
modificação também deve aplicar-se a todos os sinônimos.
5 Uma alternativa é anotar o fluxo no día de fluxo de dados para indicar que ele é um sinônimo de
alguma coisa; um asterisco, por exemplo, pode ser acrescentado no final dos nomes sinôni mos.
Por exemplo, a notação freguês poderia ser utilizada para indicar que freguês é um sinônimo de
algum outro nome. Mas isto também não é muito prático.
252
11
ESPECIFICAÇÕES
DE PROCESSOS
Nossos pequenos sistemas têm seu dia.
Alfred, Lord Tennyson
In Memoriam, 1850
1. Como escrever especificações de processos em lin guagem estruturada.
2. Como escrever especificações de processos com condições pré/pós
3. Como utilizar tabelas de decisão para escrever espe cificações de processos.
4. Quando utilizar ferramentas alternativas de especifi cação.
Neste capitulo vamos explorar a espec de processos, a descrição do que ocorre dentro de cada
bolha primitiva, do nível mais baixo, em um diagrama de fluxo de dados. Vários livros, inclusive [
1978], [ e Sarson, 19771 e [ 1978] também usam o termo minispec (abreviação de «miniature
specification”) como alterna tiva para especificação de processos. Qualquer que seja seu nome, ,o
propósito de uma especificação de processos é totalmente direto: ela define o que deve ser feito
para transformar entradas em saídas. Ela é uma detalhada descrição da orientação empresarial do

Página 178 de 584
usuário execu tada pelas bolhas.
Como veremos neste capítulo, existem diversas ferramentas que
podemos utilizar para produzir uma especificação de processos: tabelas
2
de decisão, linguagem estruturada, condições pré/pós, fluxogramas, diagramas de Nassi-
Shneiderman, e outras. Embora a maioria dos ana listas de sistemas prefiram a linguagem
estruturada, não devemos esquecer que podemos usar qualquer método, desde que ele satisfaça
dois essenciais requisitos:
A espec de processos deve ser expressa de uma forma que possa ser verificada pelo usuário epelo
analista de sistemas. É precisamente por essa razão que evitamos a linguagem comum como
ferramenta de especificação: ela é notoriamente ambígua, principalmente para descrever ações
(decisões) alter nativas e repetitivas (laços). Por sua natureza, ela também tende a causar grande
confusão ao expressar condições booleanas compostas (isto é, combinações dos operadores
booleanos
AND, OR e NOT).
• A especificação de processos deve ser expressa de uma forma que possa ser efetivamente
comunicada às diversas audiências
envolvidas. Embora costumeiramente seja o analista de sistemas quem redige a especificação de
processos, normalmente há uma diversificada audiência de usuários, gerentes, auditores, contro
ladores de qualidade e outros, que irão ler a especificação. A especificação de processos talvez
possa ser expressa em cálculo de predicados, ou em Pascal ou em uma abordagem de dia gramação
formal como o USE-IT’ da Higher Order Software, porém se a comunidade usuária recusar-se a ler
tais especifi cações, elas serão inúteis, O mesmo pode ser dito a respeito de tabelas de decisão,
linguagem estruturada ou sobre outras fer ramentas de especificação; trata-se mais de uma função
da per sonalidade, retrospecto e da atitude dos usuários com os quais
lidamos.
Como já dissemos, a maioria dos analistas de sistemas usa a lingua gem estruturada como método
preferido para redigir especificações de processos. Talvez seja mais importante dizer que a maioria
dos analistas de sistemas e das empresas usa uma ferramenta para elaborar todas as especificações
Isso, na minha opinião, é um grande erro: deve-se ter a liberdade de se empregar uma combinação
de ferramentas de especifi cação, dependendo de (a) a preferência do usuário, (b) suas próprias
preferências e (c) a natureza dos diversos projetos.
A boa ferramenta de especificação de processos deve possuir uma terceira característica também:
não deve impor (ou implicar) deci sões arbitrárias de projeto e de implementação. Isso muitas
vezes é difí cil, porque o usuário, de quem dependemos para estabelecer a “política”
254
LI
seguida em cada bolha no DFD, está disposto a descrever a orientação em termos de como ela é
executada hoje. É tarefa sua, como analista de sistemas, destilar dessa apresentação a essência do
que seja a orientação e não como ela é executada atualmente.

Página 179 de 584
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 especificação para a bolha rotulada
como CAL CUlAR FATOR IIIP0TÉ11C0. Como o analista de sistemas não está fa miliarizado com
a aplicação, ele entrevistou o usuário e aprendeu que a doutrina para calcular fatores hipotéticos
para qualquer valor do elemen to de dados de entrada, x, é a seguinte:
1. O fator hipotético não é produzido como resultado de um cálcu lo simples. Na realidade, temos
de começar por uma suposição. O usuário nos disse que gosta muito do 14 como suposição inicial.
2. Em seguida, fazemos outra suposição. Dividimos o número x, com que começamos, pela
suposição corrente.
3. Tomamos o resultado desse cálculo e o subtraimos da suposição corrente.
4. Tomamos o resultado do item 3 e o dividimos por dois. Essa é a nossa nova suposição.
5. Se a nova suposição e a suposição corrente estão muito próxi mas uma da outra, digamos, dentro
dc 0,0001, podemos parar; a
x
FATOR HIPO(X)
Figura 11.1: Cálculo do fator hipotético
255
nova suposição é o fator hipotético. Caso contrário, voltamos ao item 2 e fazemos tudo novamente.
Você poderia argumentar que essa especificação de processo é dificil de ser lida e compreendida
porque está escrita em linguagem nar rativa. De fato, a descrição a seguir é muito mais compacta
(observe que as barras verticais “1” na cláusula UNTIL significam “valor absoluto” da expressão
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 também tem um defeito: descreve a norma da empresa em termos de uma
determinada implementação procedural. A norma, como pode ter ficado evidente (mas que também
pode não ter ficado evidente), é o algoritmo de Newton-Raphson de aproximação da raiz quadrada
. A especificação de processo abaixo descreve a mesma norma, porém dá ao projetista/programador
completa liberdade na esco lha de seu próprio algoritmo:
PRÉ-CONDIÇÃO
Existe um número X, não negativo.
PÓS-CONDIÇÃO
Um fator-hipo é produzido de modo que
X = fator-hlpo * fator-hipo
O programador pode até escolher o algoritmo do usuário para calcular a raiz quadrada, mas ele não

Página 180 de 584
ficará restrito a utilizá-lo pelo analista de sistemas. Na verdade, a extraordinária atenção dada ao
algoritmo procedural, principalmente na primeira versão da especificação acima, não permitiu
que se percebesse de que processo se tratava!
Antes de explorarmos as diversas ferramentas de especificação de processos, devemos enfatizar um
ponto: as especificações de processos só são desenvolvidas para os processos do nível mais baixo
dos diagra mas de fluxo de dados em níveis. Como podemos ver na figura 11.2, todos os processos
de um determinado nível são definidos pela rede de processos do nível inferior seguinte. Em outras
palavras, a espe cificação de processos para uma bolha de um nível é o DFD do nível
256
Não há especificações de
processos para estas bolhas
Estas bolhas têm especificações de processos, presumindo-se
que sejam bolhas do nível mais baixo
FIGURA 3
Figura 11.2: Fspec de processos de bolhas do nível mais baixo
257
imediatamente inferior. Escrever uma especificação adicional de processos em linguagem
estruturada seria não somente supérfluo mas também redundante; isto é, criaria uma especificação
que seria mais difícil de ser mantida atualizada ¶
Vamos nos concentrar nas três principais ferramentas de especifica ção de processos neste capítulo:
• Linguagem estruturada
• Condições pré/pós
• Tabelas de decisão
Faremos também alguns rápidos comentários sobre outras ferra mentas de especificação 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 restrições quanto ao tipo de sentenças que podem ser utilizadas
e à maneira como essas sentenças podem ser reunidas. Ela também é co nhecida por outros nomes,
como LPP (Linguagem de Projeto de Programas) e LEP (Linguagem de Especificação de
Problema). Seu propósito é obter um razoável equilíbrio entre a precisão de uma linguagem de
programação formal e a casual informalidade e legi bilidade da língua que utilizamos normalmente.
Uma sentença em linguagem estruturada pode consistir em uma
equação algébrica, por exemplo,
X=(YZ)/(Q÷14)
ou em uma simples sentença imperativa composta por um verbo e um objeto. Observe que essa
sentença não tem o ponto-e-vírgula que ter mina uma sentença de programação em muitas
linguagens de progra mação; ela pode ou não terminar por um ponto (“.“), dependendo de sua

Página 181 de 584
preferência quanto a esse tipo de coisa. Observe também que sen tenças que descrevem cálculos
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 também podemos escrever cálculos 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 ação 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 organizações considera que 40 a 50 verbos são sufi cientes para descrever qualquer
política em qualquer especificação de
processos.
Os objetos (o tema de sentenças imperativas simples) devem ser compostos apenas por elementos
de dados que tenham sido definidos no dicionário de dados ou em termos locais. Termos locais são
palavras explicitamente definidas na especificação de um processo individual. Elas só são
conhecidas, relevantes e significativas nessa especificação de processo. Um exemplo típico de
termo local é um cálculo intermediário, utilizado para produzir a saída final do processo . Por
exemplo, a es pecificação de processo em linguagem estruturada abaixo examina uma série de

Página 182 de 584
registros de pedidos no depósito PEDIDOS para calcular um total diário.
total-diário - O
DO WHILE existirem mais podido. em PEDIDOS como data fatura - data-hoje
READ próximo podido em PEDIDOS como data-fatura =
data-hoje
259
DISPLAY em Contab nun noi total geral
total-diário - total-diário + total-geral
ENDDO
DISPLAY em Contab total-diário
A linguagem estruturada permite ainda a combinação de senten ças em algumas formas limitadas;
as que se seguem são baseadas nas co nhecidas construções da programação estruturada 6•
• A construção ff-THEN-ELSE é utilizada para descrever sen tenças alternativas que devem ser
executadas de acordo com o resultado de uma decisão binária. Essa construção pode tomar uma das
duas seguintes formas:
1W condição-1
senença-1
2IDIF
ou
1W condição-1
sentença-1
sentença-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-cobrança em categ-senior
set categ-cobrança em categ-normal
2
• A construção CASE é utilizada para descrever sentenças alterna tivas a serem executadas com
base no resultado de uma decisão multivalorada (diferente da decisão binária que ocorre com a
construção IF-TIIEN). A construção CASE assume a forma geral:

Página 183 de 584
DO CriSE
260
CASE variável - valor-1 sentença-1
CASE variável - valor-n
seniença-n
OT1
sentença -n+1
SE
Dessa maneira, o analista de sistemas poderia escrever:
DO CASE
CASE idad.-c] < 13
set catQg-cobzança em cat.g-irifant
CASE idada-clionte > 12 e idade-cliente < 20
set categ-cobrança em categ-a
CASE idade-cliente > 19 e idade-cliente < 65
set categ-cobrança em categ-adulto
OTHERWI SE
set categ-cobrança em categ-senior
END CASE
Ou, como outro exemplo, considere o seguinte trecho de uma
especificação 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 cláusula OTHERWISE é muitas vezes utilizada para resolver situações em que o
usuário esquece de especificar e que o analista de sistemas esquece de perguntar a respeito; ela vai
muitas vezes induzir algumas discussões entre o usuário e o analista de sistemas que de outro modo
não ocorreriam até que o sistema estivesse em operação. Considere o seguinte exemplo:
261
DO CASE

Página 184 de 584
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 usuário poderia questionar essa especificação de processo e perguntar porque o analista de
sistemas incluiu a cláusula 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 construção DO-WH1LE é usada para descrever uma sentença que deve ser executada
repetidamente até que uma determinada condição booleana seja verdadeira. Sua forma geral é:
DO WHILE condição-1
sentença-1
DO
O teste (“condição-1” no exemplo acima) é feito antes da execução da sentença-1; assim sendo, se
a condição não for satisfeita, é possível que sentença-1 seja executada zero vezes.
Por exemplo, o analista de sistemas poderia escrever:
DO WHILE enquanto houver mais itens no pedido do
cliente
preço = preço_unit*quant_item
DO
Muitas organizações utilizam uma outra estrutura que executa uma especificada sentença ao menos
uma vez antes de testar se ela deve ser repetida. Essa variação, conhecida habitualmente como
REPEAT-UNTIL, tem a seguinte forma:
sentença-1
UNTIL condição-1
Pode-se construir sentenças compostas a partir de combinações de sentenças simples L das
estruturas simples acima apre sentadas, de acordo com as s regras:
262
1. Uma seqüência linear de sentenças simples é equivalente (estru turalmente) a uma sentença
simples. Portanto, a seqüência
sentença-!
sentença-2
sentença-n

Página 185 de 584
é estruturalmente equivalente a uma única sentença simples e pode ser utilizada onde quer que seja
esperada uma sentença simples. Isso nos permite construir estruturas como esta:
IF condição-!
sentença-!
sentença-2
sentença-3
sentença-4
sentença-5
2
ou
DO WRILE condição-! sentença-1
sentença-2
sentença-3
wO
2. Uma construção IF-THEN-ELSE simples é considerada estrutu ralmente equivalente a uma
única sentença 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 condição-!
sentença-!
IF condição-2
sentença-2
sentença-3
sentença-4
sentença-5
2
263
senrença-6
sentença- 7
IF condição-3
sentença-8
IT
sentença-9
3. Uma estrutura DO-WHILE simples é considerada estru turalmente equivalente a uma única
sentença simples. Isso permite que as estruturas DO-WHILE sejam aninhadas dentro de outras

Página 186 de 584
estruturas DO-WHILE, ou dentro de estruturas if THEN-ELSE ou dentro de estruturas CASE.
Dessa forma, podemos ter a seguinte especificação em linguagem estruturada:
total-geral O
DO WHILE houver pedidos a serem processados
total-faturas - O
READ próximo 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 sentença
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 descrições arbitra riamente complexas da política
da empresa, mantendo-se estrito controle sobre o vocabulário, a organização e a estrutura da
descrição. Entretanto, essa complexidade arbitrária é também a maior desvantagem da lingua gem
estruturada: se o analista de sistemas compuser uma especificação de processos que seja
demasiadamente complexa para o usuário enten der e verificar, ele terá fracassado. Isso pode
normalmente ser evitado pela adoção das três seguintes diretrizes:
264
1. Restrinja a especificação de processos em linguagem estrutura da a uma única página de texto
(ex.: uma folha de 8 X 11, com 66 linhas de texto em um editor de texto). Se a especificação exigir
mais de uma página, então o analista de sistemas (com auxílio do usuário) deve recorrer a um
modo inteiramente diferente de formular a política (p.ex.: utilizar um diferente algoritmo simples).
Se isso não puder ser feito, é possível que o próprio processo (isto é, a bolha no DFD) seja
complexo demais e deva ser subdividido em uma rede de processos mais simples, de nível mais
baixo.
2. Não use mais de três níveis dc aninhamento (isto é, três níveis de estruturas !F-THEN-ELSE
aninhadas ou três níveis de estru turas CASE aninhadas etc.). Principalmente no caso de es truturas
IF-THEN-ELSE, mais do que dois níveis de ani nhamento já representam um forte indício de que
seria pre ferível a especificação de uma tabela de decisões; isso será discutido na seção 11.3.
3. Evite confusões sobre níveis de aninhamento utilizando a en dentação, como mostrado nos
exemplos acima. Isso pode ser feito e controlado com muita facilidade se você utilizar algum tipo
de auxílio automatizado para desenvolver as especificações de processos (mesmo algo simples
como um sistema comum de processamento de palavras). Se as especificações de processos forem
digitadas manualmente por um funcionário não versado em programação estruturada ou análise
estruturada, será necessário explicar-lhe minuciosamente o tipo de endentação desejado; também

Página 187 de 584
será necessário verificar cuidadosamente a correção do texto resultante.
Muitos analistas de sistemas perguntam se devem esperar que o usuário leia e compreenda uma
especificação de processos redigida em linguagem estruturada. Minha experiência tem sido
uniformemente posi tiva nesse aspecto: os usuários podem ler a linguagem estruturada, com as
seguintes condições:
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 construção IF-THEN-ELSE e outras coisas do
gênero.
265
2. Não se refira à especificação de processos como «lingua gem estruturada”. Se necessário, refira-
se a ela como “uma descrição formal da política da empresa para a execução dessa atividade”.
3. Dê especial atenção ao formato geral e á diagramação (layout) do documento; a endentação de
blocos aninhados é par ticularmente importante. Alguns usuários preferem o tipo numerado de
endentação, no qual os níveis recebem números como 1.1, 1.1.1, 1.1.1.1, e assim por diante.
O estudo de caso do apêndice F mostra alguns exemplos de espe cificação de processos em
linguagem estruturada.
11.2 CONDIÇÕES PRÉ/PÓS
As condições pré/pós são um modo prático de descrevermos a função 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 usuário tende a expressar a política 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
não deseja se envolver pes soalmente nesses detalhes, e princi não quer se en gajar em discussões
com o usuário sobre os méritos relativos desses algoritmos.
Um exemplo de especificação de processo escrita com a condição
pré/pós é mostrada na figura 11.3:
ESPECIFICAÇÃO DE PROCESSO 3.5: CALCULAR IMPOSTO
SOBRE VENDAS
Pré-condição 1
DADOS-DE-VENDA ocorre com TIPO-DE-ITEM que
266
coincide com CATEGORIA-DE-ITEM em CATEGORIAS- DE-IMPOSTOS
Pós-condição 1

Página 188 de 584
TAXA-VENDAS é ajustado em TOTAL-VENDAS *
VALOR-TAXA
Pré-condição 2
DADOS-DE-VENDA ocorre com TIPO-DE-ITEM que não coincide com CATEGORIA-DE-
ITEM em CATEGORIAS- DE-IMPOSTOS
Pós-condição 2
MENSAGEM-ERRO é gerada
Figura 11.3: Uma espec de condições pré/pós
Como se pode ver, uma especificação tem duas partes principais:
pré condições e pós condições. Além disso, essas especificações podem conter termos locais, como
foi explicado na seção 11.1 (veja também a nota 5).
As pré-condições descrevem tudo que deve ser verdadeiro (se houver algo) antes que o processo
inicie seu funcionamento. Às vezes é prático imaginar o processo como uma «princesa
adormecida” e as pré- condições como o ‘beijo mágico” que despertará o processo e o porá a
trabalhar. Como alternativa, as pré-condições podem ser consideradas como uma garantia do
usuário: «Garanto que quando este processo for ativado, as seguintes coisas serão verdadeiras”.
Costumeiramente, as pré- condições descreverão o seguinte:
• Que entradas devem estar disponíveis. Essas entradas serão 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 vários fluxos chegando a um processo, porém só um deles seja uma pré-
condição necessária à ativação do processo. Por exemplo, se víssemos uma especificação que
começasse por
Pré-condição
o elemento de dados X ocorre
em combinação com o diagrama de fluxo de dados mostrado na figura 11.4, nossa interpretação
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 não são necessários para que o processo inicie seu funcionamento.
Que relacionamentos devem existir entre as entradas ou no in terior delas. Com muita freqüência
uma pré-condição especifi cará que devem chegar duas entradas com campos correspon dentes
(ex.: detalhes de pedidos e detalhes de remessas com o mesmo número de conta). Ou a pré-
condição 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 depósitos de dados. Uma pré-condição pode
estipular que exista um regis tro em um depósito que coincida com algum aspecto de um ele mento
de dado de entrada (ex.: a pré-condição poderia dizer:

Página 189 de 584
«existe um pedido-de-cliente com um número-de-conta-de- cliente que coincide com um número-
de-conta-de-cliente no depósito de clientes”).
• Que relacionamentos devem existir entre diferentes depósitos ou no interior de um depósito.
Desse modo, a pré-condição poderia dizer: «existe um pedido no depósito de pedidos cujo número-
de-conta-de-cliente coincide com o número-de-conta-de-cliente no depósito de clientes». Ou a pré-
condição poderia estabelecer:
“existe um pedido no depósito de pedidos com uma data-de- embarque igual à data atual”.
As pós-condições descrevem de forma análoga 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- condições habitualmente
descrevem o seguinte:
• As saídas que serão geradas ou produzidas pelo processo. Essa é a forma mais comum de pós-
condição (ex.: “Será produzida
uma fatura”).
• Os relacionamentos que existirão entre os valores de saída e os valores origina is de entrada. Isso
é comum nas situações em que uma saída é função matemática direta de um valor de en trada.
Assim, uma pós-condição poderia dizer: “O total-fatu rado será calculado como soma dos preços-
unitários-de-Item mais taxas-de-embarque”.
• Os relacionamentos que existirão entre os valores de saída e os valores em um ou mais depósitos.
Isso é comum quando as in formações devem ser recuperadas de um depósito e usadas com parte
de uma saída do processo. Por exemplo, a especificação de um processo poderia ter como pós-
condição o seguinte: “O balanço-pendente no depósito INVENTÁRIO será aumentado pelo valor-
recebido e o novo inventário-pendente será pro duzido como saída deste processo”.
• As alterações que deverão ser feitas nos depÓsitoS: acréscimo de novos itens, modifIcação ou
eliminação de itens já existentes. Desse modo, poderíamos ver declarações como: “O pedido será
acrescentado ao depósito PEDIDOS” ou “O registro cliente será eliminado do depósito
CIJENTES”.
Quando for elaborar a especificação de uma condição pré/pós, comece por descrever em primeiro
lugar as situações de processamento normal. Podem existir diversas situações normais diferentes
(ex.: combi nações únicas de relacionamentos válidos entrada/depósito) cada uma das quais
expressa por uma pré-condição distinta e separada. Para cada uma dessas pré-condições, você deve
descrever a condição da bolha de processo quando as saídas tiverem sido produzidas e os depósitos

Página 190 de 584
te nham sido modificados. Após terem sido descritas as situações normais de processamento,
devem ser incluídas as pré e pós-condições adequa das para os casos de erros e situações anormais.
Considere a especifica ção de condições pré/pós mostrada na figura 11.5(b) que seriam desen
volvidas para um novo sistema a partir da especificação narrativa da figura 11.5(a).
269
Se um cliente me diz ter crédito ao vir à caixa registrar sua despesa, eu verifico sua conta em meu
arquivo. Se eu a erícontrar e ela não estiver marcada com suspensa’ ou cancelada”, eu preencho o
formulário do débito com o número da conta e o valor da venda. Caso contrário, eu informo ao
cliente que ele terá de pagar em di nheiro ou conversar com o gerente.
Figura 11.5 (a): Um exemplo de especificações narrativas
Pré-Condição 1
O cliente se apresenta com um número-de-conta Coincidente com um número de conta em
CONTAS,
cujo código-de está ajustado em “válido”.
Pós-condição i
A fatura é emitida contendo número-de e
valor-da-venda
Pré-Condição 2
A Pré-condição i falha por algum motivo (o
número-de não é encontrado em CONTAS ou o
código-de. não é igual a “válido”.
PÓS-Condição 2
E emitida uma mensagem de erro.
Figura 11.5(b): Um exemplo de condições pré-pós
Embora a abordagem de condições pré/pós seja útil e apresente diversas vantagens, há ocasiões em
que ela pode não ser adequada. A falta de etapas intermediárias entre as entradas (pré-condições) e
as saídas (pós-condições) é deliberada e consciente - mas pode tornar a especificação dificil de ser
entendida se o leitor não puder visualizar algum tipo de procedimento que conduza das entradas
para as saídas. Além disso, se houver relacionamentos complexos entre as entradas e as saídas,
pode ser mais fácil escrever a especificação usando a lingua gem estruturada. Um exemplo de uma
especificação de pré-condição/ pós-condição que é possivelmente muito complexa pode ser visto
na figura 11.6.
270
DETERMINAR EMPRÉSTIMO COM BASE NOS FATORES DO
CLIENTE
Pré-condição 1
pedido-de-empréstimo ocorre

Página 191 de 584
e tempo-de-serviço > 5 ou valor-líquido > valor-do- empréstimo e despesas-mensais < 0.25 * valor-
do- empréstimo
ou garantia-colateral > 2 * valor-do-empréstimo e idade> 25 ou garantia-colateral > valor-do-
empréstimo e idade > 30
ou tempo-de-serviço > 2 e valor-líquido > 2 * valor-do- empréstimo e idade> 21 e despesas-
mensais < 0.5 * valor- do-empréstimo
Pós-condição 1
valor-aprovado = valor-do-empréstimo
Figura 116: Uma espec de condições pré/pós demasiadamente
complexa
Assim como em todas as formas de especificações de processos, você deve deixar que seu próprio
julgamento e reações do usuário o guiem; se o usuário considerar dificil ler a especificação de pré-
condi ções/pós-condições, escolha outro formato. A abordagem de pré-condi ções/pós-condições é
mostrada no estudo de caso do apêndice G; a abordagem alternativa de linguagem estruturada é
utilizada no estudo de caso do apêndice F. Examine cuidadosamente esses dois estudos de ca sos
para determinar a adequabilidade dessas duas ferramentas de especi ficação de processos.
11.3 TABELAS DE DECISÕES
Existem situações em que nem a linguagem estruturada e nem as condições pré/pós são adequadas
para se elaborar uma especificação de processos. Isso é especialmente verdadeiro quando o
processo deve produzir alguma saída ou executar ações com base em decisões comple xas. Se as
decisões forem baseadas em diversas variáveis (p.ex.: elemen tos de dados de entrada), e se essas
variáveis puderem assumir muitos valores diferentes, então a lógica expressa pela linguagem
estruturada ou pelas condições pré/pós será provavelmente tão complexa que o usuário não a
entenderá. A abordagem mais recomendável será possivelmente a tabela de decisões.
271
1234 5678
ldade>21
S
S
S
S
N
N
N
N
Sexo
M

Página 192 de 584
M
F
F
M
M
F
F
Peso>150
S
N
S
N
S
N
S
N
Medicação 1
X
X
X
Medicação 2
X
X
Medicação 3
X
X
X
Nenhuma medicação X X
Figura 11.7: Uma tabela de decisões típica
Como se vê na figura 11.7, uma tabela de decisões é criada relacio nando-se todas as variáveis
relevantes (também conhecidas como condi ções ou entradas) e todas as ações relevantes no lado
esquerdo da ta bela; observe que as variáveis e as ações estão separadas por uma linha horizontal
grossa. Neste exemplo, todas as variáveis são lógicas, o que significa que podem assumir valor
verdadeiro ou falso.
Em muitas aplicações, é fácil (e preferível) expressar as variá veis como binárias

Página 193 de 584
(falso/verdadeiro), mas as tabelas de decisões também podem ser construídas a partir de variáveis
que podem assu mir muitos valores diferentes; por exemplo, pode-se construir uma tabela de
decisões com uma variável chamada “idade-do-cliente” cujos valores relevantes sejam “menor que
10”,”entre 10 e 30’ e “maior que 30”.
Em seguida, cada combinação possível de valores das variáveis é listada em uma coluna separada;
costuma-se chamar cada coluna de norma. Uma norma descreve a ação (ou ações) que deve ser
tomada para uma específica combinação de valores das variáveis. Pelo menos uma ação deve ser
especificada para cada norma (isto é, para cada colu na vertical na tabela de decisões), ou o
comportamento do sistema para aquela situação não será especificado.
Se houver N variáveis com valores binários (falso/verdadeiro), en tão haverá 2 normas distintas;
assim, se houver três condições, haverá 8 normas, e se houver 7 condições, haverá 128 normas. A
enumeração de todas as normas é um processo bastante direto: considerando-se o Sim (ou D como
um zero binário e o Não (ou F) como um um (1) binário, é fácil gerar uma seqüência de 000, 001,
010, 011, 100, 101 e assim por diante, até que todas as 2N combinações tenham sido geradas ‘.
Você deve discutir cada norma com o usuário para garantir que tenha sido identificada a ação
correta, ou ações corretas, para cada combinação de variáveis. É muito comum, quando se faz isso,
descobrir que o usuário nunca pensou em certas combinações de variáveis ou que
272
elas nunca ocorreram anteriormente R• A vantagem da tabela de decisões é que você pode se
concentrar em uma norma de cada vez.
Outra vantagem da utilização das tabelas de decisões é que elas não implicam qualquer forma de
implementação em particular. Isto é, quando o analista de sistemas entrega a tabela de decisões
(juntamente com os DFD e etc.) ao projetista/programador, há uma imensa liberdade de escolha em
termos de estratégia de implementação: a tabela de de cisões pode ser programada com sentenças
IF aninhadas, com uma cons trução CASE ou com uma construção GO TO DEPENDING ON em
COBOL; no caso extremo, o gerador de código de tabela de decisões po de gerar código
automaticamente a partir da tabela de decisões. Assim, as tabelas de decisões são muitas vezes
consideradas como uma ferra menta não-proceclural de modelagem de sistemas, porque não deter
minam qualquer específico algoritmo procedural para executar as ações necessárias.
Para resumir, devemos seguir as etapas abaixo para a criação de
uma tabela de decisões para uma especificação de processos:
1. Identifique todas as condições ou variáveis na especificação. Identifique todos os valores que
cada variável pode assumir.
2. Calcule o número de combinações de condições. Se todas as condições forem binárias, haverá 2
combinações de N
variáveis.
3. Identifique cada ação possível na especificação.
4. Crie uma tabela de decisões “vazia”, relacionando todas as con dições e ações no lado esquerdo
e numerando as combinações
de condições no alto da tabela.

Página 194 de 584
5. Relacione todas as combinações de condições, uma para cada coluna vertical da tabela.
6. Examine cada coluna vertical (norma) e identifique as ações adequadas a serem empreendidas.
7. Identifique todas as omissões, contradições e ambigüidades da especificação (ex.: normas da
tabela de decisões para as quais a
especificação não indique que ações devem ser empreendidas).
8. Discuta as omissões, contradições e ambigüidades com o usuário.
273
11.4 OUTRAS FERRAMENTAS DE ESPECIFICAÇÃO DE PROCESSOS

11.4.1 Grafos e Diagramas
Em alguns casos pode ser apropriado expressar uma especificação de processos por meio de um
grafo ou de um diagrama. Na verdade, o usuário pode já dispor de um grafo ou de um diagrama
que seja presen temente usado para executar aquela parte da aplicação. Se for assim, use-o! Não 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 programação quando for a hora de implementar o sistema.
Considere, como exemplo, uma especificação de processos que
determina o prêmio de seguro de um cliente em função da idade. O
usuário informou que a orientação atual da empresa é estabelecer o
prêmio a partir do grafo mostrado na figura 11.8.
Presumindo que a orientação não se altere quando for elaborado um novo sistema e presumindo
que o prêmio de seguro seja função apenas da idade, não há necessidade de o analista de sistemas
executar qualquer trabalho adicional. A figura 11.8 é a especificação de processos.
Prêmio 300
Idade
Figura 11.8: Prêmio de seguro em função da idade
11.4.2 Linguagem Narrativa
Como ficou implícito por diversas vezes neste capítulo, a lingua gem narrativa não é uma
ferramenta recomendável para se redigir espe cificações de processos. Isso porque:
274
• Um vocabulário irrestrito (com indiscriminado uso de substan tivos, verbos e adjetivos) torna
provável que a descrição do pro cesso inclua termos que não estejam no dicionário de dados e cujo
significado não seja claro.
• As ações alternativas (decisões) são muitas vezes expressas de uma forma mal feita e ambígua.
Isso torna-se pior se as decisões
forem expressas com utilização do aninhamento.
• As ações repetitivas (laços) também são expressas de forma de sajeitada e ambígua. Os laços

Página 195 de 584
alinhados são extremamente peri gosos quando expressos em linguagem comum.
• O conceito de estruturas de bloco só pode ser expresso com endentação ou com apresentação em
estilo de sumário; se al guém quisesse ir até esse ponto poderia também utilizar a nota ção da
linguagem estruturada formal.
Se, por alguma razão, você for forçado a utilizar a linguagem narra tiva, convém pelo menos
conservar algumas das vantagens da análise estruturada altamente subdividida que vimos
discutindo neste livro. Isto é, sob nenhuma circunstância admita ser obrigado a escrever uma espe
cificação tipo novela vitoriana monolítica de 2 mil páginas. Em último caso, subdivida a
especiflcação em pequenas partes, de forma a que você possa escrever 2 mil “historinhas”
independentes.
11.4.3 Fluxogramas
Temos evitado a utilização de fluxogramas até agora em nossa discussão, mas isso é um reflexo do
atual desinteresse em fluxogramas e não uma acusação contra eles . Grande parte das críticas em
relação aos fluxogramas deve-se à mt utilização deles nas seguintes áreas:
1. Como ferramenta de modelagem de alto nível de sistemas, os fluxogramas são muito
prejudicados. Os fluxogramas apre sentam lógica procedural e seqüencial. Como vimos no capítulo
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 ordenação (sort)
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 símbolos equivalentes às construções da linguagem
estrutu rada descritas na seção 11.1, nada haverá de errado com seu emprego. Para criar um
fluxograma estruturado, o analista de sistemas deve orga nizar sua lógica com combinações
aninhadas dos simbolos de fluxogra ma mostrados na figura 11.10.10
Figura 11.9: UmJluxograma não-estruturado
Figura 11.10: Os símbolos dofluxograma estruturado de Bôbm-Jacopini
276
Uma alternativa é o emprego dos diagramas de Nassi-Shneiderman, discutidos na seção 114.4.
Contudo, deve-se dizer que muito poucos analistas de sistemas usam fluxogramas para especificar
processos (e nem para projetos de programas, também). Embora as ferramentas auto matizadas
descritas no apêndice A possam ser utilizadas para criar e manter fluxogramas, a verdade é que a
linguagem estruturada, as tabelas de decisões e as especificações de condições pré/pós são mais
fáceis para criar e manter.
11.4.4 Diagramas de Nassi-Shneiderman
Quando a programação estruturada tornou-se popular em meados dos anos 70, os diagramas de
Nassi-Shneiderman foram apresentados como uma técnica de fluxogramação estruturada; veja

Página 196 de 584
INassi e Shneider man, 19731 e [ 19741. Um diagrama de Nassi- Shneiderman típico toma a forma
Observe que uma sentença imperativa simples é representada por
um retângulo, como se pode ver na figura 11.12(a); o retângulo também
pode ser usado para representar um bloco de sentenças seqüenciais. A
N.
\
Figura 11.11: Um diagrama de Nassi-Shneiderman típico
Figura 11.12 (a): Representação de uma sentença seqüencial
sentença 1 sentença 2
277
construção binária IF-TIIEN-EISE é representada pela notação gráfica mostrada na figura 11.12(b);
e a construção repetitiva DO-WHILE é representada pela notação gráfica mostrada na figura
11.12(c).
Os diagramas de Nassi-Shneiderman são geralmente mais organiza dos, mais estruturados e mais
abrangentes que os fluxogramas comuns; por esse motivo, eles são por vezes preferidos como
ferramenta para a criação de especificações de processos. Entretanto, eles exigem uma quantidade
não trivial de gráficos, e não está bem claro se os gráficos 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 sentenças!”.
Por outro lado, uma pesquisa recente conduzida por David Scanlan na Universidade do Estado da
Califórnia (IScanlan, 19871) mostrou que 75% a 80% dos estudantes de ciência do processamento
preferem deckli damente os diagramas de Nassi-Shneiderman em lugar de pseudocódigo no
aprendizado de algoritmos complexos. Embora isso esteja em oposi ção à típica reação negativa
dos programadores experientes em relação aos fluxogramas, as conclusões de Scanlan são baseadas
em cuidadosos estudos analíticos dos fatores de algumas centenas de estudantes. Ainda que os
usuários finais não tenham necessariamente as mesmas preferên cias dos estudantes da ciência do
processamento, existe pelo menos a possibilidade de que eles prefiram a representação gráfica da
especifica ção de um processo em vez de uma representação narrativa/textual.
condição
T F
sentençal sentença2
Figura 11.12 (b): Representação de uma construção IF-77-IEN-ELSE
11.5 RESUMO
O propósito deste capítulo foi mostrar que existem muitas maneiras diferentes de descrever a
orientação detalhada do usuário no interior de cada bolha primitiva de um diagrama de fluxo de
dados. Embora a lin guagem estruturada seja a técnica mais comumente utilizada nos dias de hoje,

Página 197 de 584
você deve considerar o uso de tabelas de decisões, fluxogramas, condições pré/pós e outras
abordagens que podem ser verificadas e transmitidas facilmente a seus usuários.
278
Condição DO UNTIL
sentença 1
sentença 2
sentença n
Figura 11.12 (c): Representação de uma construção DO-WHILE
Lembre-se que as especificações de processos representam o maior volume de trabalho minucioso
na construção do modelo de um sistema; podem existir centenas e até milhares de especificações
de processos, e cada uma pode ocupar uma página. Face ao volume de esforço envol vido,
considere a abordagem da implementação top-down discutida no capítulo 5 - comece a fase de
projeto e implementação de seu sistema antes do final das especificações de processos. Lembre-se
também que a atividade de escrever especificações de processos serve como um «teste de
sanidade” dos diagramas de fluxo de dados que já foram desenvolvi dos. Você pode descobrir que a
especificação de processos necessita de fluxos de dados de entrada adicionais (fluxos que não
foram mostrados no DFD) e, ao escrever a especificação de processos, pode surgir a necessidade
de mais funções; por exemplo, ao escrever a especificação de processo para uma função que
acrescente um novo registro ao de pósito CLIENTES, você pode observar que o DFD não tem uma
bolha que modifique ou suprima um registro daquele depósito. Assim, você deve esperar que sejam
necessárias modificações, revisões e correções no DFD fundamentadas no minucioso trabalho de
escrever as especifi cações de processos.
REFERÊNCIAS
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, Techníques ofProgram Siructure and Design, 2 ed. Englewood Cliffs, N.J.:
4. James Martin e Carma McClure, Diagramming Technique.s for Soft ware Engineeríng.
5. Victor Weinberg, Slructured Analysis. Englewood Cliffs, N.J.: Pren tice-Hall, 1978.
6. Edward Yourdon, Classics in Software Engineering. Nova lorque:
7. Corrado Bõhm e Giuseppe Jacopini, “Flow Diagrams, Turing Ma chines, and Languages with
Only Two Formation Rules”, Commu nication.s of lhe ACM, Volume 9, Número 5 (maio de 1966),
pgs. 366-371. Reimpresso em Classics in Software Engineei (op. cit.).

Página 198 de 584
8. 1. Nassie B. Shneiderman, “Flowchart Techniques for Structured Programming”, ACM
SIGPLAN Notíces, Volume 8, Número 8
(agosto de 1973), pgs. 12-26.
9. Ned Chapin, «New Format for Flowcharts”, Software - Pracace and Expertence, Volume 4,
Número 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 Author’s Conference, 5 de
dezembro dc 1987.
1. Considere a especificação a seguir, apresentada em forma narra- uva. Qual das ferramentas de
especificação vistas neste capítulo
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 disponíveis. Natura! mente, alguns são eliminados de imediato por causa de seus attos
preços, ou porque estão 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 endereço 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 não sei porque ainda faço isso
2. O que é uma especificação de processos? Quais são seus objetivos?
3. Cite cinco ferramentas comuns para modelar especificações de processos.
4. Quais são os três requisitos que uma especificação de processos deve satisfazer?
5. Um projeto de desenvolvimento de sistemas deve usar apenas uma ferramenta para especificação
de processos? Por quê?
6. Projeto de Pesquisa: que ferramentas de especificação são utiliza das em sua empresa? Existem
restrições quanto às ferramentas que podem ser usadas? Você acha que estejam sendo empregadas
as ferramentas adequadas?

Página 199 de 584
7. Que bolhas de um DFD exigem especificações de processos?
8. Quais são as conseqüências de escrevermos especificações de pro cessos para bolhas não-
atômicas (não-primitivas)?
9. Como o analista de sistemas deve determinar quais devem ser as especificações de processo para
uma bolha?
10. Como as especificações de processos por vezes impõem decisões arbitrárias de projeto e de
implementação? Quais são as conse qüências disso?
11. Projeto de Pesquisa: encontre um exemplo de especificação de processos em sua empresa que
apresente decisões arbitrárias de projeto ou de implementação. Como você a reescreveria para
evitar esse problema?
12. Dê uma definição para a expressão linguagem estruturada. Apre sente alguns sinônimos dessa
expressão.
13. Quantos verbos são necessários para formar sentenças em lingua gem estruturada? Sugira uma
lista de 20 verbos.
14. Por que as equações algébricas costumam ser necessárias em uma especificação de processos
em linguagem estruturada?
15. Que características devem ter os objetos em uma especificação de processos em linguagem
estruturada?
16. Que são termos locais?
17. Devem os termos locais ser incluídos em um dicionário de dados? Por quê?
18. Os termos locais aparecem como fluxõs nos DFD?
19. Apresente um exemplo específico de um termo local.
20. Quais construções da programação estruturada são utilizadas em linguagem estruturada?
21. Qual é o propósito da cláusula OTHERWISE na linguagem estruturada?
281
22. Qual é a diferença entre a construção DO-WIIILE e a construção REPEAT-UNTIL em
linguagem estruturada?
23. O que é uma sentença composta?
24. A construção CASE é necessária à linguagem estruturada? Quais são as vantagens e
desvantagens da construção CASE?
25. Quais são os quatro componentes de uma sentença composta?
26. Qual é a diferença entre (a) e (b)?
(a) 11 A ‘fliEN
IF B T1
senrença-1
sentença-2

Página 200 de 584
sentença-2.
(b) IF A AND B T1 sentença-!
i
sentença-2.
Quais desses dois exemplos você considera mais fácil de compre ender? Por quê?
27. Projeto de Pesquisa: construa alguns exemplos semelhantes ao da pergunta 26 e faça um
levantamento entre os usuários para verifi car qual versão eles preferem.
28. Quais são as três diretrizes que devem ser seguidas para garantir que uma espeçificação em
linguagem estruturada será legível?
29. Você concorda em que três níveis de IF aninhados em uma especi ficação em linguagem
estruturada são aceitáveis? Por quê
30. Projeto de Pesquisa: prepare alguns exemplos de especificações de processos em linguagem
estruturada envolvendo dois, três e quatro níveis de IF aninhados. Faça um levantamento para
determinar, em média, quantos níveis os usuários em sua empresa estão dispostos a aceitar.
31. Qual é o propósito da endentação em uma especificação de pro cessos em linguagem
estruturada?
32. Por que é importante conduzir caminhamentos (walkthroughs) em uma especificação de
processos em linguagem estruturada com o
usuário apropriado?
33. Qual é o propósito de se utilizar numeração em estilo de sumário em uma especificação em
linguagem estruturada?
34. Dê uma definição da técnica de especificação pré-condição/pós condição.
282
35. Qual é a diferença entre a técnica de especificação em linguagem estruturada e a técnica de pré-
condição/pós-condição?
36. Sob quais circunstâncias a técnica de especificação pré-condição/ pós-condição é recomendável
para ser utilizada pelo analista de
sistemas?
37. Dê uma definição de pré-condição.
38. Quais são as três coisas que uma pré-condição habitualmente descreve?
39. Qual é o relacionamento entre pré-condições em uma especifi cação de processos e fluxos de
entrada em um DFD?
40. Que acontece se as pré-condições de uma especificação de proces sos não forem satisfeitas?
41. Dê uma definição de pós-condição.
42. Quais são as quatro coisas que uma pós-condição habitualmente descreve?
43. Qual é o relacionamento entre pós-condições e fluxos de saída em um DFD?

Página 201 de 584
44. Se uma especificação de processos tiver quatro conjuntos de pré- condições, quantos conjuntos
de pós-condições deverá possuir?
45. Qual é o número mínimo de pré-condições que uma especificação de processos pode ter?
46. Quais são as potenciais desvantagens da abordagem pré-condição/ pós-condição?
47. Projeto de Pesquisa: encontre um exemplo de uma especificação de processos do mundo real
que não se adequaria bem à aborda gem de especificação de pré-condição/pós-condição. Por que
ela não se adequaria bem?
48. Examine a figura 11.6. Qual seria a melhor ferramenta de mo delagem para criar uma
especificação de processos para aquela
situação?
49. Projeto de Pesquisa: encontre um exemplo de uma especificação de processos do mundo real
que se adequaria bem à abordagem
de pré-condição/pós-condição. Por que ela se adequaria?
50. O que é uma tabela de decisões? Quais são os componentes de uma tabela de decisões?
51. Sob que condições uma tabela de decisões é uma boa ferramenta para especificações de
processos?
283
A
52. O que está errado na tabela de decisões abaixo?
Idadesuperiora2
T
E
F
Sexo masculino
T
T
F
Medicação 1
Medicação 2
X
Altura superior a 1,80m
T
T
E

Página 202 de 584
F
Pesosuperiora9
T
F
T
E
Prêmiodeseguro=$100
>
X
Prêmio de seguro = $200
X
X
Altura superior a 1,80m
T
T
E
F
Pesosuperiora9okg
T
E
T
F
Prêmiodeseguro=$100
x
>
x
X
x
284
55. Qual é a diferença entre uma tabela de decisões com variáveis binárias e uma tabela com

Página 203 de 584
variáveis que podem assumir múltiplos
valores?
56. Se uma tabela de decisões tiver N variáveis binárias, quantas nor mas ela deverá ter?
57. Sob que circunstâncias o analista de sistemas deve usar um grafo para elaborar a especificação
de processos?
58. Quais são as vantagens de um grafo sobre a linguagem estruturada como ferramenta de
modelagem para especificações de
processos?
59. Quais são as quatro maiores desvantagens da linguagem narrativa como ferramenta de
modelagem para especificações de processos?
60. Que diretrizes devem ser seguidas se a linguagem narrativa tiver de ser utilizada como
ferramenta de modelagem para especificações
de processos?
61. Quais são as duas maiores críticas aos fluxogramas como ferramen tas de modelagem?
62. Quais são os três componentes de um fluxograma estruturado?
63. Apresente a um usuário a mesma especificação em linguagem es truturada e em forma de
fluxograma. Qual abordagem ele prefere?
Para maiores informações sobre isso veja EScanlan, 19871.
64. O que é um diagrama de Nassi-Shneiderman? Qual é a diferença 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 decisões para a seguinte especificação narrativa e
indique quaisquer omissões, ambigüidades e contradições 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 comissão paga sobre os itens que eles venderem,
mas alguns são empregados que recebem salário + comissões; isto é, recebem um salário fixo, não
importando a quantidade ou o tipo de itens que vendam, mais uma comissão sobre certos itens. A
Swell Store comercia com várias diferentes linhas de mercadorias, algumas das quais são
conhecidas como itens comuns (uma lata de sopa de tomates, por exemplo) porque são amplamente
aceitas e não exi gem técnicas criativas de venda; além disso, existem itens privilegia dos que são
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 preços, ensanduichando um grande número de itens no meio do espectro.
Os clientes também são divididos em categorias. Alguns são conhe cidos como regulares, porque
fazem compras com tanta freqüência
285
que não há necessidade de vendas criativas. A maioria dos fregueses, contudo, faz um pequeno
volume de compras na Swell Store; vêm da rua, entram na loja, compram alguma coisa e desa

Página 204 de 584
parecem para sempre.
O critério de comissões da direção é o seguinte: se um empregado não-assalariado vender um item
que não seja comum nem privile giado para alguém que não seja um freguês regular, recebe uma
co missão de 10 por cento, a menos que o item custe mais de $10.000, em cujo caso a comissão é
de 5 por cento. Para todos os vendedores, se um item comum for vendido ou se qualquer item for
vendido a um freguês regular, não é paga qualquer comissão. Se um vendedor assalariado vender
um item privilegiado, receberá uma co missão de 5 por cento, a menos que o item custe mais de
$1.000, caso em que ele recebe uma comissão simples de $25. Se um vende dor não-assalariado
vender um item privilegiado a alguém que não seja um freguês regular, recebe comissão de 10 por
cento, a menos que o item custe mais de $1.000, caso em que receberá uma comis são simples de
$75.”
NOTAS
1 Para maiores informações 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 introdução de todo um conjunto de padrões de análise
estruturada na organização. Embora os pa drões sejam um admirável esforço no combate à
indolência, à igno rância e à anarquia total, eles às vezes vão longe demais e impõem uma rígida e
uniformizadora solução 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 especificação es crita para processos de nível elevado. Isso ocorrerá se o
usuário de cidir que quer mostrar a especificação a seu chefe e estiver preo cupado em que ele não
aceite a idéia de DFD em níveis. Desse mo do, o usuário lhe dirá: “Bem, eu sei que você não
precisa de uma especificação de processos para as bolhas de nível 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 diplomática usada para solucionar todos os outros
problemas políticos em seu projeto.
286
5 Termos locais são definidos dentro da especificação do processo
onde eles ocorrem e não são definidos no dicionário de dados. Eles
são muitas vezes derivados (calculados diretamente) de termos que
já constam no dicionário, assim, seria redundante incluir os termos
locais. Além disso, por definição, os termos locais só são conheci
dos em um contexto local (isto é, no interior de uma bolha de um
diagrama de fluxo de dados). Eles não devem aparecer como um
fluxo no DFD e habitualmente não fazem parte do vocabulário
normal orientado-para-a-aplicação utilizado pelo usuário.

Página 205 de 584
6 Se você não estiver familiarizado com a programação estruturada,
consulte um dos textos padrões sobre o assunto, ou veja alguns
dos primeiros artigos sobre esse tema coligidos em EYourdon,
1979].
7 Naturalmente, haverá situações em que as condições da tabela de
decisões não serão binárias por natureza, mas são capazes de assu
mir diversos valores (p.ex.: uma aplicação 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 número total de nor
mas em uma tabela de decisões desse tipo, é preciso multiplicar o
número de valores que a variável 1 pode assumir pelo número de
valores que a variável 2 pode assumir pelo ... número de valores
que a variável N pode assumir. Portanto, se tivermos uma aplicação
onde a variável 1 pode assumir 3 valores, a variável 2 pode assumir
5 valores e a variável 3 pode assumir 4 valores, serão necessárias
3 X 5 X 4 = 60 normas distintas.
8 Existem diretrizes para simplificar tabelas de decisões e para com
binar diversas normas em normas compostas, mas não 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 Califórnia em Sacramento mostrou que os estu
dantes de programação preferem os fluxogramas aos métodos mais
apreciados para o aprendizado de algoritmos. Se isso é verdadeiro
para estudantes de programação, talvez também o seja para os
usuários. 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 informações sobre fluxogramas estruturados, veja o clás
sico artigo [ e Jacopini, 1966].
287
12
DIAGRAMAS DE

Página 206 de 584
ENTIDADES-
RELACIONAMENTOS
Obviamente, a capacidade de julgamento de um homem não pode ser melhor do que as
informações em que ele está fundamentado. Dêem-lhe a verdade e ele pode continuar errado
quando tiver a oportunidade de estar certo, mas pnvem-no de notícias ou apresentem-lhe somente
dados dístorcidos ou incompletos, com relatórios ignorantes, mal feitos ou tendenciosos, com
propaganda e falsidades deliberadas, e destruirão seus proc de raciocínio e o transformarão em algo
inferior a um homem.
Arthur Hays Sulzberger
Address, New York State Publisber’s Association, 1948
1. Porque os modelos de dados são úteis em análise 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 capítulo vamos explorar uma notação gráfica para modela gem de dados. O diagrama de
entidades-relacionamentos (também
conhecido como diagrama DER ou E-R) é um modelo em rede que
289
descreve a diagramação dos dados armazenados de um sistema em alto nível de abstração. Ele é
inteiramente diferente de um diagrama de fluxo de dados que modela as funções executadas por
um sistema e é diferente do diagrama de transições de estado, que modela o compor tamento
tempo-dependente de um sistema.
Por que estaríamos interessados no modelo de dados de um siste ma Primeiro porque as estruturas
de dados e os relacionamentos podem ser tão 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 usuários executivos de alto nível na
organização (vice-presidentes ou chefes de departamentos que podem não estar interessados nos
detalhes operacionais do dia-a-dia do sistema). Esses usuários estão muitas vezes mais interessados
em: de que dados precisamos para nossos negócios? 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 organização. O grupo de administração de dados
(ou grupo de AD) muitas vezes é responsável pelo gerenciamento e controle das informações
essenciais da empresa; sempre que for iniciar a construção de um novo sistema de informações
você precisará conversar com essas pessoas para poder coordenar as informações de seu sistema
com o modelo global de informações de nível 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 organização: o grupo de

Página 207 de 584
administração 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
administração de dados não 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 tação
responsável por tomar um modelo essencial (independente de uma tecnologia específica) e traduzi-
lo para um projeto de banco de dados fisico eõeaz 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 comunicação com o grupo de ABD.
Com base nas informações apresentadas pelo DER, o grupo de administração de bancos de dados
pode iniciar a verificação de que tipo de chaves, índices ou ponteiros serão necessários para obter
acesso eficiente aos registros dos bancos de dados.
290
Para o analista de sistemas o DER também é um importante bene ficio: ele realça os
relacionamentos entre os depósitos de dados de um DFD que de outro modo só seriam percebidos
nas especificações de processos. Por exemplo, um DER típico é mostrado na figura 12.1. Cada um
dos retângulos corresponde a um depósito de dados de um DFD (essa correspondência será
examinada mais adiante, no capítulo 14) e pode-se ver que existem relacionamentos (conexões)
que normalmente não seriam vistos em um DFD. Isso se deve ao fato de que o DFD focaliza a
atenção do leitor para as funções que o sistema executa e não para os dados de que ele necessita.
Consideremos um caso extremo: e se não houvesse funções a executar? E se o propósito do sistema
em construção não fosse fazer alguma coisa, mas apenas ser o repositório de um grande volume de
informações de interesse? Um sistema assim poderia ser chamado de sistema de consultas ad hóc
ou sistema de apoio a decisões. Em tal sis tema, podemos nos concentrar inteiramente no modelo
de dados sem nem mesmo nos preocuparmos na elaboração do modelo de DFD orien tado para as
funções. Essa situação é, de fato, muito rara: a maioria dos sistemas tem funções a serem
executadas; com freqüência descobrimos que construir o modelo de dados em primeiro lugar
facilita descobrir quais são as funções necessárias.
Naturalmente que a notação do DER da figura 12.1 é inteiramente misteriosa por enquanto. Nas
próximas seções examinaremos a estrutura e os componentes de um DER; depois discutiremos
diretrizes para dese nharmos um DER bem estruturado. A notação apresentada neste capítulo
REP. DE VENDAS
Figura 12.1: Um diagrama de entidades-relacionamentos típico
291
deriva de LFlavin, 19811 e é semelhante à notação 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

Página 208 de 584
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 retângulo em um diagra ma de entidades-
relacionamentos; a figura 12.2 mostra um exemplo. Ele representa uma coleção ou um conjunto de
objetos (coisas) do mundo real cujos membros individuais (exemplares ou instâncias) têm as
seguintes características:
• Cada um deles só pode ser identificado de uma única forma. Existe algum modo de diferençar as
instâncias 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 número de
conta, pelo último sobrenome ou pela inscrição 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 construção. Isto é, para que o tipo de objeto seja
legítimo é necessário que o sis tema não 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, além dos clientes, a loja tem um grupo de serventes, cada um dos
quais é identificado individualmente pelo nome. Embora os serventes, presumivelmente, exerçam
um papel útil na loja, o sistema de entrada de pedidos pode funcionar perfeitamente sem eles,
portanto, eles não merecem ter um papel de tipo de objeto no modelo de nosso sistema.
Obviamente, isso é algo que deve ser confirmado com os usuários 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, endereço,
limite de crédito e número do telefone. Muitos livros sobre bancos de dados descrevem isso como
sendo atribuição 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, endereço,
limite de crédito, número dc telefone, e assim por diante.
Em muitos dos sistemas que desenvolvemos, os tipos de objetos serão a representação de uma
coisa material do mundo real. Desse modo, objetos típicos são clientes, itens de inventário,
empregados, peças fabricadas e coisas semelhantes. O objeto é a coisa material do mundo real, e o
tipo de objeto é a representação no sistema. Entretanto, um objeto também pode ser imaterial:
escalas, planos, padrões, estraté gias e mapas são apenas alguns exemplos.
Como pessoas são 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 vários tipos
diferentes de objetos em modelos de dados diferentes ou até no mesmo modelo de dados. José da

Página 209 de 584
Silva, por exemplo, pode ser um EMPREGADO em um modelo de dados e um CLIENTE em um
outro modelo; ele poderia ser também 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 não é obrigatório, mas é uma convenção útil. Como veremos no capítulo
14, existe uma correspondência entre os objetos do DER e os depósitos do DFD; assim, se existe
um objeto CLIENTE no DER, deve haver um depósito CLIENTES no DFD.
293
1
12.1.2 Relacionamentos
Os objetos são interligados por relacionamentos. Um relaciona mento representa um conjunto de
conexões 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 conexões. Cada instância
do relacionamento representa uma associação entre zero ou mais ocorrências de um objeto e zero
ou mais ocorrências de outro objeto. Dessa forma, na figura 12.3, o relacio namento rotulado
COMPRA pode conter as seguintes instâncias individuais:
• instância 1: cliente 1 compra item 1
• instância 2: cliente 2 compra iteris 2 e 3
• instância 3: cliente 3 compra item 4
• instância 4: cliente 4 compra itens 5, 6 e 7
• instância 5: cliente 5 não compra itens
• instância 6: clientes 6 e 7 compram item 8
• instância 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 instâncias do mesmo objeto.
Observe que o relacionamento representa alguma coisa que deve ser recordada pelo sistema -
alguma coisa que não pode ser calculada ou derivada mecanicamente. A&m sendo, nosso modelo
de dados da figura 12.3 indica que existe alguma importante razão relativa ao usuário
294
para recordar o fato de que o cliente 1 compra o item 1 etc. O relacio namento também indica que
não há nada a priori que nos permitisse determinar que o cliente 1 comprasse o item 1 e nenhum
outro item. O relacionamento representa a memória do sistema’ (um objeto também representa a
memória do sistema, é claro).
Observe também 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 MÉDICO. À primeira

Página 210 de 584
vista, você poderia pensar que isso é insistir no óbvio: a cada vez que o médico atende o paciente
ele cobra alguma coisa desse mesmo paciente. Mas a figura 12.4 sugere que a situação pode ser
diferente; ela pode revelar, por exemplo, que existem diversas instâncias diferentes de um “tra
tamento” entre um médico e o mesmo paciente (uma consulta inicial, as consultas subseqüentes
etc.). A figura 12.4 mostra também que o rela cionamento de cobrança é 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 situação mais corriqueira é haver múltiplos relacionamentos
entre múltiplos objetos. A figura 12.5 mostra o relacionamento que
Figura 12.4: Múltiplos relacionamentos entre objetos
295
tipicamente existe entre um comprador, um vendedor, um corretor imóveis, 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 é típico não 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 são válidos. 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 preço em qualquer das maneiras seguintes:
1. Corretor de imóveis negocia preço entre compradoi vendedor.
2. Comprador negocia preço com vendedor por intermédio corretor de imóveis.
3. Vendedor negocia preço com comprador por intermédio corretor de imóveis.
Figura 12.5: Múltiplos relacionamentos entre múltz objetos
Observe que, em alguns casos, podemos ter relacionamentos cn diferentes instâncias 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 instâncias de diferentes tipos de objetos
(p.ex. “inscreve-se”, “ensina” etc.). Entretanto, podemos precisar modelar o relacionamento “é pré-
requisito para” entre uma instância e outra de CURSO.
12.1.3 Notação Alternativa para Relacionamentos
Como vimos na seção 12.1.2 os relacionamentos no diagrama E-R são multidlreciona podem ser
udos em qualquer direção. Vimos tam bém que o diagrama E-R não apresenta cardinalidade, isto é,
não mostra o número de objetos que participam de um relacionamento. Isso é algo consciente e
deliberado: é preferível colocar esses detalhes no dicionário de dados. Isso será discutido na seção
12.3.
Uma notação 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 notação adicional indica que

Página 211 de 584
(1) O CLIENTE é o ponto dc fixação, 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 instância de um relacionamento. Isso impediria, por exemplo, o caso
em que vários clientes estejam envolvidos na compra do mesmo item.
Ii NI
Cliente . Item
Figura 12.6 (a): Notação de ponto defira ção para diagramas E-R
Outra notação 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
Cliente Item
Figura 12.6 (b): Notação alternativa para relacionamentos um-para-muitos
297
Diagramas E-R assim são discutidos detalhadamente em [ 1976], [ 1982] e lDate, 19861.
Entretanto, eu prefiro não incluir esses detalhes porque eles podem ser facilmente incluídos no
dicionário de dados (como pode ser visto na seção 12.4), e eles favorecem o desvio da atenção do
propósito principal do diagrama E-R, que é dar uma visão geral dos componentes de um sistema e
das interfaces entre os elemen tos de dados desse mesmo sistema. Apesar de não haver nada
intrinseca mente errado com anotações procedurais no diagrama, minha experiên cia ensina que os
analistas de sistemas muitas vezes levam uma boa idéia longe demais e sobrecarregam o diagrama
com muito mais informações do que seria adequado.
12.1.4 Indicadores de Tipos de Objetos Associativos
Uma notação 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 informações .
Considere, por exemplo, o caso simples de um cliente que compra um item (ou itens), representado
na figura 12.6. Não importando se incluímos a anotação procedural ou não, 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 instância de uma
compra (ex.: a hora do dia em que ela ocorreu). Onde poderíamos armazenar essa informação?
“Hora do dia” não é certamente um atributo de CLIENTE nem de ITEM. Em vez disso, atribuímos
“hora do dia” á própria 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 retângulo e que está ligada por uma linha

Página 212 de 584
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 informações. Neste caso,
queremos lembrar a hora em que ocorreu a compra e o desconto oferecido ao cliente (novamente se
presume que tais informações não 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 estão. Eles existiriam ocorrendo ou não uma compra .
Por outro lado, uma COMPRA depende obviamente de CIJENTE e
de ITEM para sua própria existência. 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 também 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 típico: a categoria geral
é EM PREGADO e as subcategorias são EMPREGADO ASSALARIADO e EMPREGADO
HORÁRIO. Observe que os subtipos são 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 notação 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 são descritos por:
• Nome
• Anos de serviço
• Endereço
• Nome do supervisor
299
Figura 12.8: Um indicador de supertzpo/sub:ipo
Entretanto, cada subtipo é descrito por diferentes elementos de dados; caso contrário, nada haveria
que os pudesse distinguir. Por exem plo, podemos imaginar que um EMPREGADO
ASSALARIADO seja des crito por:
• Salário mensal
• Percentagem anual de bônus
• Total permitido para o carro da empresa E o EMPREGADO HORÁRIO fosse descrito por:
• Salário horário

Página 213 de 584
• Valor da hora extra
• Hora de início
12.2 DIRETRIZES PARA A CONSTRUÇÃO DE DIAGRAMAS DE ENTIDADES-
RELACIONAMENTOS
A notação 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 estão em primeiro lugar?”. Seu modelo inicial
300
de tipos de objetos e relacionamentos derivará habitualmente de (1) seu conhecimento da aplicação
do usuário, (2) entrevistas com o usuário e (3) alguma outra pesquisa e coleta de dados que você
faça (as técnicas para entrevistas e coleta de dados são discutidas no apêndice E).
Você não deve esperar que o primeiro diagrama de E-R que você desenhar será uma versão final
que será revista com a comunidade usuária 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 aperfeiçoa dos várias vezes. A primeira versão será
normalmente nada mais que um esboço, e as versões subseqüentes serão produzidas com a
utilização de uma série de diretrizes de refinamento apresentadas nesta seção. Algu mas das
diretrizes de refinamento conduzirão à criação de tipos de obje tos adicionais, enquanto outras
levarão à eliminação de tipos de objetos e/ou de relacionamentos.
12.2.1 A Inclusão de T de Objetos Adicionais
Como dito acima, seu DER inicial será normalmente criado a partir de entrevistas iniciais com o
usuário e de seu conhecimento do ramo da empresa do usuário. Isso, naturalmente, proporcionar-
lhe-á uma boa indicação de como identificar os principais objetos e relacionamentos
Após o desenvolvimento da versão 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ê conheça quais são os elementos de dados! Isso pode ocorrer em uma de três maneiras:
1. Se o modelo do processo (DFD) já foi desenvolvido ou estiver sendo desenvolvido em paralelo
com o modelo de dados, então já existe um dicionário de dados. Ele pode ainda não estar completo,
mas será suficiente para se dar início ao processo de designações.
2. Se o modelo do processo não foi desenvolvido (ou, no caso extremo, você não pretende
desenvolver um), então você terá de começar a entrevistar todos os usuários apropriados para
elaborar uma lista completa de elementos de dados (e suas definições). 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 frustrações).
301
3. Se você estiver trabalhando com um grupo de administração de dados ativo, há uma boa
possibilidade de que o dicionário de dados já exista. Você poderá recebê-lo logo nas etapas iniciais
do projeto, a partir de quando você poderá iniciar o processo de designações.
O processo de designações pode apresentar um destes três motivos para a criação de novos tipos de

Página 214 de 584
objetos:
1. Você pode descobrir elementos de dados que podem ser desig nados para algumas instâncias de
um tipo de objeto, mas n
para outros.
2. Você pode descobrir alguns elementos de dados que sejam apli cáveis a todas as instâncias 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 designação de elementos de dados a tipos de objetos, você descobrir que
alguns elementos de dados não podem ser aplicados a todas as instâncias 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
extraordinário brilho e criatividade!) um tipo de objeto chamado EMPREGADO. Ao revisar os
elementos de dados disponíveis, você descobriu que muitos deles (Idade, altura, data-de-admissão
etc.) são aplicáveis a todas as instâncias de um empregado. Entretanto, posteriormente você
descobre um elemento de dado chamado número-de-gravidezes; isso é, evidentemente, um ele
mento de dado importante para empregados mulheres mas não para empregados homens. Isso o
levaria a criar EMPREGADO-HOMEM e EMPREGADO-MULHER como subtipos para a
categoria geral de empregado.
Obviamente, não estou sugerindo que todos os sistemas de pes soal devam controlar o número de
gravidezes que cada empregado teve; o exemplo foi escolhido apenas porque é do consenso geral
que os empregados homens não podem engravidar. Compare isso, no en tanto, com o elemento de
dado nome-do-cônjuge: existem diversas instâncias de EMPREGADO para as quais nome-do-
cônjuge talvez não possa (N.T.: no original “may not”) se aplicar (porque não estão presentemente
casados), mas esta é uma situação muito diferente da de
302
um elemento de dado que não pode (NT.: no original «cannot”) ser aplicado 6
Na maioria dos casos, o processo de criação dc novos subtipos e de designação de elementos de
dados de forma apropriada é muito direto. Entretanto, lembre-se de uma exceção: 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 não a
ambos. Suponha que os únicos elementos de dados que podemos designar para empregados sejam
número-de-gravidezes e anos-de-ex periênc lorque. Poderíamos decidir com razão (depois de
imaginar que tipo de lunático seria o usuário responsável por tal sistema!) que o supertipo geral de
EMPREGADO não é aplicável.
A situação oposta também pode ocorrer: os elementos dc dados podem descrever instâncias 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-CARTÃO- DE-CRÉDITO como dois tipos de

Página 215 de 584
objetos distintos ao elaborarmos o pri meiro DER para um sistema dc entrada dc pedidos (talvez
porque o usuário nos tenha dito que eram duas categorias distintas). Entretanto, pode logo tornar-se
evidente que os elementos de dados nome-do- cliente e endereço-do-cliente descrevem ambos os
tipos de cliente da mesma forma; isso levaria à criação dc um supertipo, como mostrado na figura
12.9.
De modo semelhante, se um elemento de dados descrever a
interação de um ou mais tipos de objetos, devemos substituir o
CLIENTE DE CLIENTE A
CARTAO DE DINHEIRO
CRÉDITO ____________
Figura 12.9: Criação 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 versão mostrado na figura 12.10(a) na qual existe o relacionamento
COMPRA entre CLIENTE e 1TEM. Durante a designação 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 interação de um
CLIENTE e um ITEM. Isso sugere que deveríamos 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): Substituição dc um relacionamento por um tipo de objeto
associativo
Por vezes o diagrama dc E-R inicial contém um tipo de objeto que em melhor análise merece ser
um tipo dc objeto associativo. Por exem plo, a figura 12.11(a) mostra um diagrama de l com três
objetos rela cionados entre Si: CLIENTE, PEDIDO e PRODUTO. I)urante o processo de
designação de elementos dc dados para os diversos objetos, descobri mos que data-da-entrega deve
pertencer ao objeto PEDIDO; afinal, os clientes não são “entregues” e os produtos só são entregues
como resul tado de um pedido. Na verdade, o raciocínio 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 endereço. 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. Também se poderia
argumentar que existem (po tencialmente) múltiplas instâncias de informações relativas a filhos

Página 216 de 584
asso ciadas a cada instância de um empregado e que cada instância de in formações 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): Visão inicial de um objeto
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 remoção de objetos embutidos é parte de uma atividade de refinamento mais
abrangente conhecida como normaliza ção, O objetivo da normalização é produzir tipos de objetos
em que cada instância (ou membro) consiste em um valor de chave primária que identifica alguma
entidade, juntamente com um conjunto de valores de atributos mutuamente independentes que
descrevem aquela entidade de algum modo, O processo dc normalização é descrito cm detalhes no
capítulo 14 de [ 19861 e no capítulo 19 dc IDeMarco, 19781.
12.2.2 A Supressão dc’ Tipos de Objetos
A seção anterior tratou dc refinamentos cm DER que criam objetos e/ou relacionamentos
adicionais. Entretanto, existem algumas situações em que o refinamento do DER conduz à
supressão de tipos de objetos e relacionamentos redundantes ou errôneos. Vamos examinar quatro
si tuações comuns:
1. Tipos de objetos compostos por apenas um identificador
2. Tipos de objetos para os quais existe apenas uma instância
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 construímos um dia grama de E-R inicial como mostrado na figura
12.13(a) para um sistema de pessoal:
EM PREGADO
ado com
CÔNJUGE
Figura 12.13(a): Um diagrama de E-R inicial
Durante o processo de designação de elementos de dados para os diversos objetos, entretanto,
podemos descobrir que a única informação que o sistema de pessoal conserva sobre um cônjuge é
o nome (isto é, o identificador que distingue um cônjuge de todos os outros cônjuges no sistema).

Página 217 de 584
Nesse caso, um refinamento óbvio é eliminar CÔNJUGE como tipo de objeto e incluir nome-do-
cônjuge como elemento de dados no objeto EMPREGADO.
Observe que esse refinamento só faz sentido quando existe uma correspondência de um-para-um
entre as instâncias do objeto a ser elimi nado e as instâncias do objeto que lhe seja relacionado. O
exemplo imediatamente acima faz sentido porque a sociedade moderna presume
307
que uma pessoa dcva ter, no máximo, um cônjuge, 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 redução ainda maior se descobrirmos que nosso diagrama de E-R inicial
contém um objeto para o qual o único fato é o identificador e que é um objeto de uma única
instância Considere o diagrama de E-R inicial most.rado na figura l
À primeira vista, parece ser um modo razoável de mostrar o relacionamento entre pacientes e
remédios (ou drogas, medicinais, é claro!) em um hospital. Mas, suponha que a única informação
que temos sobre o remédio 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 também significa que nosso sistema não terá um
depósito
308
chamado remédios). O diagrama reduzido ficaria como o da figura 12.14(b).
Figura 12.14 (b): Diagrama de E-R reduzido
Tendo cm vista a situação acima, é possível criar um tipo de obje to associativo alternativo.
Considere a seguinte variação do exemplo anterior do hospital, como mostrado na figura 12.15(a).
Se, como acima sugerido, REMÉDIO for um objeto somente identificador e dc instância ú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 válido (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 capítulo, 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 LICENÇA puder ser derivado (com base na data de aniversário 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

Página 218 de 584
qualquer critério que seja utilizado pelo DETRAN), deve, então, ser eliminado. Isso nos conduz à
figura 12.16 na qual os tipos de objetos não são interligados. Isso é inteiramente válido em um
DER; não é ne cessário que todos os upos de objetos se interliguem.
12.3 EXTENSÕES AO DICIONÁRIO DE DADOS PARA DIAGRAMAS DE E-R
Para finalizar, observamos que o dicionário de dados discutido no
capítulo 10 precisa ser estendido para que seja incluída a notação para o
Figura 12.15 (b): O diagrama de E-R reduzido
Figura 12.16 (a): Um ERD inicial
MOTORISTA
LICENÇA
310
DER discutida neste capítulo. Em geral, os objetos do DER correspondem aos depósitos do DFD; o
capítulo 14 apresenta mais detalhes sobre este assunto. Isso significa que na definição de dicionário
de dados abaixo, CLIENTE tanto é uma definição do tipo de objeto como uma instância do
depósito CLIENTES.
CLIENTES - (CLIENTE)
CLIENTE - @NC*4E-DO--CLIENTE + ENDEREÇO + NÚM TZr
Observe também que a definição de um CLIENTE inclui uma espe cificação do campo de chave,
que é o elemento de dado (ou atributo)
que distingue uma instância de um cliente de outra, O símbolo “arroba”
(@) é utilizado para indicar o(s) campo(s) chave(s) .
Contudo, também precisamos incluir no dicionário de dados uma definição de todos os
relacionamentos mostrados no DER. A definição dos relacionamentos deve incluir a descricão do
significado do relacio namento, dentro do contexto da aplicação; e deve indicar os objetos que
compõem a associação. Devem ser especificados adequados limites superior e inferior para indicar
se a associação é 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 dicionário de dados da
seguinte maneira:
compra - *a associação 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 múltiplos depósitos (objetos) e
complexos relacionamentos de dados. Como vimos neste capítulo, ele é inteiramente voltado para
os re lacionamentos de dados, sem oferecer quaisquer informações sobre as flsnções que criam ou
utilizam os dados.

Página 219 de 584
Embora tenhamos utilizado o DER neste livro como ferramenta de modelagem gráfica para
mostrar os relacionamentos de dados, você de ve estar cônscio de que várias outras ferramentas de
modelagem são 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 necessário desenvolver
ambos os modelos, uma vez que tanto o DFD como o DER oferecem tantas informações de
interesse. A resposta à primeira pergunta é simples: não importa qual seja o modelo desenvol vido
em primeiro lugar. Dependendo de suas próprias preferências ou das preferências do usuário, ou da
natureza do próprio sistema (isto é, se ele é rico em funções 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 contém um grupo distinto de projeto de bancos de dados, ou
quando o setor de PED tem um grupo dc administração 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 capítulo 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 clássicos 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 então foi enfatizado
o DFD, enquanto o DER foi muitas vezes ignorado. De maneira inversa, muitos dos sistemas de
apoio à decisão e sistemas de consulta a bancos de dados ad hoc construídos 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 características temporais dos sistemas de tempo-real construí dos nos anos 60 e 70
pareciam (pelo menos superflcialmcnte) domi nar quaisquer considerações sobre funções e
relacionamentos de dados. Nesses sistemas o modelo de transições de dados (discutido no capítulo
13) foi muitas vezes enfatizado a ponto de excluir os DFD e I)ER.
Os sistemas do final da década 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 décadas passadas; na verdade,
muitos deles são de 100 a 1.000 vezes maiores e mais complexos. Muitos desses sistemas grandes
e complexos têm funções e relacionamentos e comportamento tempo- dependente incrivelmente
complexos; considere, por exemplo, o siste ma Star Wars, que se estima necessitar de 100 milhões
de instruções de processamento e que terá um comportamento de tempo-real de espanto sa
complexidade. Para sistemas assim tão complexos, é óbvio que todas as três ferramentas de
modelagem discutidas neste livro serão critica mente importantes. Por outro lado, se você estiver
envolvido em um sim ples sistema unidimensional, você talvez decida que pode se concentrar
312

Página 220 de 584
na ferramenta de modelagem que ilumina e realça o aspecto mais importante do sistema.
No capítulo 14 veremos como o DER, o DFD, o diagrama de tran sições de estado, a especificação
de processos e o dicionário de da dos podem ser verificados um em relação aos outros para que se
possa produzir um completo modelo do sistema que seja internamente consistente.
REFERÊNCIAS
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,
Número 1 (março 1976), pgs. 9-36.
3. Peter Chen, Tbe Entlty-Relatíonship 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.
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 além 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 são os quatro principais componentes de um diagrama de entidades-relacionamentos?
7. Qual é a definição de um tipo de objeto?
8. Qual é a diferença entre um objeto e um tipo de objeto?
9. Quais são os três critérios que um tipo de objeto deve satisfazer?

Página 221 de 584
:10 Que itens da lista abaixo podem ser tipos de objetos aceitáveis em um sistema comercial
típico? Para os que você considerar como
não aceitáveis, explique o porquê.
(a) «cliente”
(b) ‘calcular imposto sobre vendas”
(c) ‘altura”
(d) ‘produto”
(e) «tomate”
(f) «religião”
(& ‘temperatura”
(h) “transação de edição”
(i) ‘peça fabricada”
(j) “mapa”
(k) ‘caracter ASCII”
11. Qual é a definição de relação?
12. Quantos tipos de objetos podem ser interligados por uma relação?
13. Que itens da lista abaixo podem ser considerados como relacio namentos em um DER e quais
não podem? Por quê?
(a) ‘compra” (verbo)
(b) ‘cliente”
(c) “pertence a”
(d) ‘peso”
(e) ‘produz”
(f) “cálculo do imposto sobre vendas”
14. Qual é a diferença 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 descrição narrativa dos objetos e dos relaciona mentos.
(b) Quantas faturas podem existir entre uma instância de fabri cante e uma instância de cliente?
(c) Quantos produtos um cliente pode comprar em uma instância do relacionamento compra?
18. Os DER apresentam cardinalidade?

Página 222 de 584
19. Use a notação da figura 12.6 para mostrar uma versão aceitável do diagrama da figura 12.5.
20. Que argumentos existem contra se mostrar ordinalidade e cardina lidade em um DER?
21. Apresente uma notação alternativa para DER que mostre tanto a ordinalidade como a
cardinalidade.
22. Desenhe um DER que represente a seguinte situação para uma empresa de linhas aéreas:
“A empresa de linhas aéreas XYZ possui três importantes recursos:
aviões, pilotos e tripulantes. Os pilotos e os tripulantes têm suas res pectivas bases domésticas, para
as quais retornam após um vôo para o qual tenham sido designados. Um vôo deve ter pelo menos
um piloto e um ou mais tripulantes escalados para um avião. Cada avião tem uma base dc
manutenção.”
23. Desenhe um DER para descrever a seguinte situação 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; além disso, alguns
livros foram escritos em conjunto por vários autores. A ABC também trabalha com múltiplas
impressoras; cada livro, portanto, é impresso por apenas uma impressora. Um editor da ABC Press
trabalha com vários autores ao mesmo tempo, editando e produzindo os projetos de livros; é tarefa
do editor levar a cópia final para a impressora quando o manuscrito está copieditado e composto.”
24. Desenhe um DER para a seguinte situação 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 consultoria com um cliente pode envolver vários consultores
diferentes. Durante a vigência do contrato, o vendedor não é envolvido e os consultores tratam
diretamente com o cliente.”
25. Desenhe um DER para a seguinte situação:
“Um professor pode dar aulas a diversas classes, desde que ele ou ela esteja qualificado para
ensinar a matéria. Cada classe deve ter um professor, mas pode ser freqüentada por vários alunos.
No início de cada semestre as classes são 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 fixação?
28. Dê três exemplos de tipos de objetos associativos.
29. Examine a figura 12.7. Suponha que não 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ê três exemplos de subtipos/supertipos.
32. Por que nos preocuparmos em termos subtipos/supertipos em um DER? Não basta termos os
tipos “comuns” de objetos?

Página 223 de 584
33. Que refinamentos o analista de sistemas deve esperar fazer depois de desenhar a primeira
versão de um DER?
34. Quais são os três meios que o analista de sistemas possivelmente usará para descobrir os
elementos de dados em um modelo de
dados?
35. O que significa designação no contexto deste capítulo?
36. Como o analista de sistemas deve continuar com o DER se o DFD já tiver sido desenvolvido?
316
37. Quais são os três motivos para criarmos tipos de objetos adicionais em um DER depois que a
primeira versão está pronta?
38. O que deve fazer o analista de sistemas se descobrir elementos de dados que podem ser
designados para algumas instâncias de um
tipo de objeto mas não para outras?
39. O que deve fazer o analista de sistemas se descobrir elementos de dados que sejam aplicáveis a
todas as instâncias 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 são os quatro básicos comuns para se remover um tipo de objeto da primeira versão 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 versão de um DER, um tipo
de objeto constituído por apenas um
identificador?
46. O que deve fazer o analista de sistemas se descobrir, na primeira versão de um DER, um tipo
de objeto do qual só há uma instância?
47. O que deve fazer o analista de sistemas se descobrir, na primeira versão de um DER, um
relacionamento derivado?
48. Que extensões devem ser feitas ao dicionário de dados para apoiar o DER?
49. O que significa a notação @ em um item do dicionário de dados?
NOTAS
1 Entre os objetos podem existir outros relacionamentos que não são mostrados no DER. Como o

Página 224 de 584
DER é um modelo de dados armaze nados, os relacionamentos que podem ser calculados ou
derivados não aparecem ali. Considere, por exemplo, o objeto MOTORISTA e o objeto LIcENÇA.
Pode haver o relacionamento de data de re novação entre os dois, que é calculado em função da
data de nas cimento do motorista (o motorista deve renovar sua licença a cada ano na data de seu
aniversário). Tal relacionamento não deve ser mostrado no DER, por não ser um relacionamento de
dados arma zenados. Entretanto, se a data de renovação fosse escolhida alca toriamente, ela
provavelmente teria de ser lembrada pelo sistema.
2 A expressão ponto de fixação foi introduzida por IFlavin, 1981].
317
3 Alguns livros sobre bancos de dados referem-se a isso como dados de interseção.
4 Um purista poderia argumentar que isso não é verdadeiro a longo prazo. Se não houvesse
ITEM(NS) por diversos dias na prateleira, os CLIENTE(S) desapareceriam de cena e fariam suas
compras em outro lugar. E se não houvesse CLIENTE(S) a loja eventualmente fecharia e os
ITEM(NS) desapareceriam. Mas na estável situação a curto prazo, é óbvio que os clientes e itens
podem coexistir tranqüilamente sem terem necessariamente algo a ver uns com os outros.
5 Entretanto, provavelmente não identificará todos os relaciona mentos entre os objetos. Dado um
sistema com N objetos, a quanti dade de relacionamentos possíveis é proporcional a N!, que nor
malmente é um número muito grande. Muitos dos (teoricamente) relacionamentos possíveis
revelar-se-ão como não tendo (1) um significado legítimo em qualquer lugar do sistema ou (2)
relevância no contexto do sistema em modelagem. Alguém poderia imaginar, por exemplo, um
sistema em que o principal relacionamento entre clientes e o pessoal de vendas seja VENDE.
Também 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 não será representado no modelo do sistema a menos que seja relevante.
6 Nesse exemplo obviamente estamos ignorando algumas exceções obscuras. Ignoramos, por
exemplo, o caso de urna empregada que depois de três gravidezes submeteu-se a uma operação de
mudan ça de sexo. E, no caso do nome do cônjuge, supusemos que ne nhum dos empregados sejam
crianças menores de idade, para as quais o casamento é presumivelmente uma impossibilidade.
7 Alguns livros usam a convenção de sublinhar o(s) campo(s)
chave(s). Desse modo, poderíamos definir cliente como
= nc* + andar + num
318
13
DIAGRAMAS
DE TRANSIÇÕES
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 forças que
lhes sejam aplicadas.

Página 225 de 584
Sir Isaac Newton,
Philosopbtae Naturalts Princ Mathematica,
LeL do Movimento, 1, 1687
Neste capítulo aprenderemos:
1. A notação para diagramas de transições de estado.
2. Como desenhar diagramas de transições de estado subdivididos.
3. Como elaborar um bom diagrama de transições de estado.
4. O relacionamento entre DTE e outros modelos.
Nos capítulos anteriores vimos ferramentas de modelagem que realçam as ftinções 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 transições de estado (tam bém 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 capítulo 2) são controle
de processos, sistemas de comutação telefô nica, sistemas de obtenção rápida de dados e sistemas
de comando e controle militares. Alguns desses sistemas são passivos no sentido de que não
procuram controlar o ambiente em que se encontram e, em vez disso, reagem a ele e obtêm dados
sobre ele. Muitos Sistemas de obten ção rápida de dados pertencem a essa categoria (ex.: um
sistema que obtém, em alta velocidade, dados científicos de um satélite). Outros sis temas de
tempo-real são 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 saída com suficiente rapidez para interagir com
o ambiente exter no. Uma parte importante da especificação desses sistemas é a descrição do que
acontece quando.
No caso dos sistemas orientados para o comércio, esse problema não tem sido tão importante. As
entradas podem chegar ao sistema de muitas fontes diferentes e em velocidades relativamente altas,
porém essas entradas podem habitualmente ser retardadas se o sistema estiver ocupado com
alguma outra coisa. Um sistema de pagamento, por exem plo, não tem de se preocupar com
interrupções nem com sinais de uma unidade externa de radar. Em casos típicos, os únicos
problemas de tempo que encontramos nesses sistemas são especificações de tempo de resposta, que
é incluído no modelo de implementação do usuário, que veremos no capítulo 21.
Entretanto, estão começando a surgir alguns grandes e comple xos sistemas de orientação
comercial que têm 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

Página 226 de 584
dispositivos de comunicação via satélite, ele poderá ter o mesmo tipo de problemas de dependência
do tempo que tem um clássico sistema de tempo-real. Assim, embora você não 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 NOTAÇÃO PARA OS DIAGRAMAS DE TRANSIÇÕES DE ESTADO
Um diagrama típico de transições de estado é mostrado na figu ra l3.1(a) (embora ele seja algo
mais simples que os diagramas que
320
veremos depois neste capítulo). Esse diagrama mostra o comportamento de uma máquina comum
de respostas telefônicas.
Os principais componentes do diagrama são os estados e as setas que representam alterações de
estado. Existem diversas notaçôes alterna- Uvas para diagramas de transições de estado; uma
bastante comum é mostrada na figura 13.1(b). Embora seja equivalente em conteúdo à figu ra
13.1(a) ela tem a desvantagcm de ser muito parecida com um diagra ma de fluxo de dados. Para
evitar confusões, 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 Webster’s New World Dictionary define estado (state) da
seguinte maneira:
Conjunto de circunstâncias ou atributos que caracterizam uma pes soa ou objeto em determinado
momento; modo ou forma de ser;
condição.
Dessa maneira, os estados típicos de um sistema podem ser um dos
seguintes:
• Aguardando que o usuário introduza uma senha
• Aquecendo uma mistura química
• Aguardando o próximo comando
• Acelerando um motor
• Misturando ingredientes
• Aguardando dados para instrumentos
• Enchendo o tanque
• Ocioso
Observe que muitos desses exemplos apresentam o sistema aguardando pela ocorrência de alguma
coisa e não indicam que o com putador esteja fazendo algo. Isso se deve ao fato de o diagrama de
tran sições de estado ser utilizado para desenvolver um modelo essencial do sistema um modelo de
como o sistema se comportaria se tivéssemos
321

Página 227 de 584
Figura 13.1 (a): Um típico diagrama de transições de estado
tecnologia perfeita. Uma característica da tecnologia perfeita seria o computador funcionar com
rapidez infinita, de modo a que qualquer processamento ou cálculo que o sislema tivesse de
executar ou qualquer ação que ele tivesse de empreender fosse feita em tempo zero. Dessa forma,
qualquer estado observável em que o sistema esteja só pode corresponder a períodos de tempo em
que ele esteja (1) aguardando a ocorrênca 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 não quer dizer que nossos sistemas sejam incapazes de empre ender uma ação ou que não
pretendamos mostrar essas ações. Significa apenas que essas ações, que ocorrem instantaneamente
em nosso mo delo de tecnologia perfeita, não são iguais a estados, que representam as condições
observáveis em que o sistema pode estar. Desse modo, um estado represênta um comportamento do
sistema que é observável e que perdura por um período finito de tempo.
13.1.2 Mudanças de Estado
Um sistema que existisse em apenas um estado não seria muito
interessante de ser estudado: ele seria estático. Na realidade, os sistemas
322
Figura 13.1 (b): Uma notação alternativa de diagrama de transições de estado
que costumamos modelar podem ter dúzias de estados diferentes. Mas como um sistema passa de
um estado a outro? Se o sistema tiver normas regulamentares dirigindo seu comportamento, então
somente certos ti pos de mudanças de estado serão significativas e válidas.
As modificações válidas de estado no DTE são 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 também 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 não 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 arbitrário número de estados sucessores.
Embora a figura 13.2 nos dê algumas informações interessantes sobre o comportamento tempo-
dependente de um sistema, ele nada nos diz sobre algo que pode vir a ser muito importante: quais
são 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 reconhecível estado inicial e outro, final; isso é mostrado na figura 13.3.
323
ESTADO 1
ESTADO 2
ESTADO 3
Figura 13.2: Mudanças de estado
O estado inicial normalmente é desenhado no alto do diagrama, embora isso não seja obrigatório; o

Página 228 de 584
que realmente identifica o estado 1 na figura 13.3 como estado inicial é a seta que não está ligada a
qualquer outro estado. Analogamente, o estado final muitas vezes é desenhado na base do
diagrama, mas isso também não é mandatório. O que de fato identifica o estado 5 como estado
final é a ausência de setas que partam dele. Em outras palavras, ao se chegar ao estado 5 não se vai
a qualquer lugar mais!
O senso comum nos diz que um sistema só pode ter um estado inicial; entretanto, ele pode ter
múltiplos estados finais; esses estados finais são mutuamente exclusivos, o que quer dizer que
apenas um deles pode ocorrer durante a execução do sistema. A figura 13.4 mostra um exemplo no
qual os possíveis estados finais são estados 4 e 6.
Como estamos utilizando DTE para construir um modelo essencial, vamos também presumir que
as mudanças de estado ocorram instanta neamente; isto é, o sistema não precisa de tempo
observável para passar de um estado a outro. Quando os projetistas e programadores come çarem a
construir o modelo de implementação isso será um problema real: normalmente são necessários
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 não fique fora
de controle.
324
Figura 13.3: Estados inicial efinal
Figura 13.4: Múlt estados finais de um sistema
325
13.1.3 Condições e Ações
Para tornar completo nosso diagrama de transições de estado, pre cisamos acrescentar mais duas
coisas: as condições que causam uma mu dança de estado e as ações que o sistema empreende
quando muda de estado. Como mostra a figura 13.5, as condições e ações são exibidas junto à seta
que liga os dois estados inter-relacionados.
ESTADO 1
Condição
Ação
ESTADO 2 1
Figura 13.5: Indicação das condições e das ações
Uma condição é um evento no ambiente externo que o sistema seja capaz de detectar, podendo ser
um sinal, uma interrupção 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 mudança de estado, o sistema normalmente empreenderá uma ou mais ações;
produzirá uma saida, apresentará uma mensagem no terminal do usuário, efetuará um cálculo etc.
Portanto, as ações mostradas no DTE ou são respostas enviadas ao ambiente externo ou são
cálculos cujos resultados são memorizados pelo sistema (geral mente em um depósito de dados
constante no diagrama de fluxo de da dos) para reagir a algum evento futuro 2•

Página 229 de 584
13.2 DIAGRAMAS SUBDIVIDIDOS
Em um sistema complexo pode haver dúzias de estados distintos:
tentar mostrá-los todos no mesmo diagrama seria dificil, senão impossí vel. Assim, da mesma
forma que utilizamos níveis e subdivisões nos dia gramas de fluxo de da&’s, podemos subdividir
os DTE. A figura 13.6(a) apresenta um exemplo . dois níveis de diagramas de transições de estado
de um sistema complexo
Observe que nesse caso, qu ‘ -uer estado individual de um dia grama de nível mais elevado pode
tornar-se o estado inicíal de um
326
diagrama de nível inferior que descreva mais detalhadamente aquele estado de nível mais elevado;
e o(s) estado(s) final (finais) de um dia grama de nível mais baixo corresponde(m) às condições de
saída do estado associado de nível superior. Em outros casos, o analista de siste mas pode precisar
mostrar, explicitamente, como um DTE de nível in ferior sai para um ponto adequado do diagrama
superior.
Um exemplo da necessidade de um diagrama subdividido de tran sições de estado pode ser o dos
caixas automáticos hoje vistos na maioria dos bancos; um DTE para essa aplicação é apresentado
na figura 13.6(b).
L_L_ ESTADO3
Figura 13.6 (a): Dois níveis de D7E
327
“start” press Exibir “inserir cartão”
AGUARDANI
CARTÃO
“Reset”
Cartão inserido pressionado ou senha errada
Exibir “introduza senha” Limpar tela
IAGUARDANDO
Exibir “quanto deseja?
AGUARDANDO
ENTRADA
Cliente introduz importância
4 Exibir “por favor, aguarde, dinheiro sendo providenciado”
ENTREGANDO
DINHEIRO
Dinheiro disponivel
4 “por favor, recolha o dinheiro”

Página 230 de 584
AGUARDANDO
RECOU-BMENTO Retornar ao estado de “AGUARDANDO ESCOLHA”
na figura superior
Flgural3.6 (b): Um DTE subdividido para uma máquina de caixa automático
328
Senha introduzida
Exibir “selecione função”
-j
“Reset” pressionado
4 Limpar tela
IAGUARDANI
ESCOLHA
“Recolha o dinheiro”
1
13.3 A CONSTRUÇÃO DO DIAGRAMA DE TRANSIÇÕES DE ESTADO
Agora que já vimos a notação para diagramas de transições de
estado, vamos discutir rapidamente as etapas da construção deles. Pode mos seguir uma destas
duas abordagens:
1. Você pode começar pela identificação de todos os estados pos síveis do sistema, representando
cada um deles como um re tângulo em uma folha de papel. Em seguida, você pode explorar todas
as conexões significativas (ex.: mudanças de estado) entre os retângulos.
2. Como alternativa, você pode começar pelo estado inicial, conti nuando metodicamente seu
caminho para o(s) estado(s) se guinte(s); e depois, do(s) estado(s) secundário(s) para o(s)
terciário(s) e assim por diante.
A abordagem que você vai adotar será, em muitos casos, ditada pelo usuário com quem você
estiver trabalhando, principalmente se ele for o único familiarizado com o comportamento tempo-
dependente do sistema.
Após haver terminado de elaborar o DTE preliminar, você deve
executar as seguintes diretrizes de verificação de consistência:
• Foram definidos todos os estados? Examine detidamente o siste ma para verificar se há qualquer
outro comportamento ob servável ou qualquer outra condição em que o sistema possa estar além
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 têm saída? Como já dissemos, o sistema pode ter um ou mais estados finais com
múltiplas entradas; mas todos

Página 231 de 584
os outros estados devem ter um estado sucessor.
• Em cada estado, o sistema reage adequadamente a todas as condições possíveis? Este é o erro
mais comum na elaboração de um diagrama de transições de estado: o analista de sistemas
identifica as mudanças de estado quando ocorrem as condições normais, mas esquece de
especificar o comportamento do sis tema em condições inesperadas. Suponha que o analista tenha
modelado o comportamento de um sistema como mostrado na
329
figura 13.7; ele espera que o usuário pressione uma tecla de função do terminal para causar uma
transição do estado 1 para o estado 2 e uma outra tecla de função para passar do estado 2 para o
estado 3. Mas, e se o usuário acionar a mesma tecla duas vezes seguidas? Ou alguma outra tecla?
Se o comportamento do sistema não for especificado, provavelmente os projetistas e pro
gramadores não programarão para essa eventualidade, e o sis tema apresentará um comportamento
imprevisível sob diversas circunstâncias.
13.4 O RELACIONAMENTO COM OS OUTROS COMPONENTES DO MODELO
O diagrama de transições de estado pode ser utilizado isoladamen te como ferramenta de
modelagem. Entretanto, ele pode ser usado em
combinação com as outras ferramentas, o que normalmente acontece.
Na maioria dos casos, o diagrama de transições de estado repre senta a especificação de processo
de uma bolha de controle de um diagrama de fluxo de dados. A figura 13.8 ilustra este fato;
observe que as condições do DTE correspondem aos fluxos de controle que chegam de um DFD, e
as ações do DTE correspondem aos fluxos de controle que saem em um DFD. Como ferramenta de
alto nível, o diagrama de
ESTADO 1
tecla de função 1
exibir mensagem 1
ESTADO 2
tecla de função 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
transições de estado pode servir como especificação 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 transições de estado para mostrar a seqüência das ativi dades
dentro do sistema.

Página 232 de 584
13.5 RESUMO
O diagrama de transições de estado é uma poderosa ferramenta de modelagem para descrever o
necessário comportamento de sistemas de tempo-real e a parte de interface humana de muitos
sistemas on-line. Apesar de não ser amplamente conhecido ou utilizado no desenvolvi mento de
sistemas comerciais de informações, ele é uma ferramenta que você deve procurar conhecer
porque, no futuro, podemos esperar que mais e mais sistemas de natureza comercial, científica ou
de engenharia, se aproximarão dos de tempo-real.
331
REFERÊNCIAS
1. Webster’s New World Dicttona Second Coliege Edition. Nova lorque: Simon & Schuster, 1980.
1. O que é um diagrama de transições de estado? Para que serve?
2. Em que tipo de sistema se costuma utilizar o DTE como ferramen ta de modelagem?
3. Os DTE são ferramentas importantes para se descrever os requisi tos de um típico sistema de
informações comerciais? Por quê?
4. Os DTE são ferramentas importantes para se descrever o projeto e a implementação de um típico
sistema de informações comerciais?
por quê? Caso afirmativo, de que tipo de sistemas comerciais?
5. Quais são os dois principais componentes de um DTE?
6. Apresente uma notação alternativa para um DTE, isto é, uma que seja diferente dos diagramas
comuns mostrados neste capítulo e
em todo este livro.
7. Qual é a definição de estado?
8. Dê três exemplos de estado.
9. O que é uma mudança 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 são condições em um DTE? Como são mostradas?
14. O que são ações em um DTE? Como são mostradas?
15. Quantas condições pode haver em um diagrama de transições de estado?
16. Quantas ações podem estar associadas a cada condição em um diagrama de transições de
estado?
17. Quais dos estados abaixo são aceitáveis? Para os que não o forem explique porquê.
(a) Calcular imposto sobre vendas

Página 233 de 584
(b) Monitorando mistura de reagentes
(c) Endereço-de-cobrança-de-cliente
(d) Arquivo-de-produtos
(e) Ascensão de elevador
(f) Temperatura do reagente fora da medida
332
(g) Atualizar total faturado
(h) Parar elevador
(i) Tecla de interrupção pressionada
Ci) Processando dados
18. O que é um diagrama de transições de estado subdividido?
19. Qual é o relacionamento entre os estados iniciais e os estados finais de um DTE subdividido?
20. Quantos níveis podem existir em um DTE subdividido?
21. Quais são as duas abordagens comuns para a elaboração de um
DTE?
22. Quais são 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
333
334
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.
condição-1

Página 234 de 584
condição-1
33. Em um sistema complexo, deve o analista de sistemas começar desenhando um conjunto de
DFD para o sistema, ou começar
pelos DER ou pelos DTE?
34. Onde devem ser descritos os detalhes das condições e ações do DTE no modelo de um sistema?
35. Desenhe um diagrama de transições de estado para um gravador de fila ou para um toca-fitas.
36. Desenhe um diagrama de transições de estado para o caixa eletrônico de seu banco.
37. Desenhe um diagrama de transições de estado para um relógio digital de pulso (a maioria dos
relógios digitais de hoje tem apa rência “normal” bem como um despertador e um cronógrafo).
condição-1 ação-1
condição-1
335
1
38. Desenhe um diagrama de transições de estado para um forno de microondas.
39. Desenhe um diagrama de transições 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
capítulo 17.
2 Observe que para executar uma ação o sistema pode precisar de entradas adicionais do ambiente
externo. Assim, podemos dizer que cada condição corresponde a um evento externo ao qual o sis
tema deve responder e que esses eventos externos serão habi tualmente reconhecidos pelo sistema
pela chegada de um fluxo de dados. Entretanto, não é necessariamente verdadeiro que cada flu xo
de dados que chega ao sistema seja um evento correspondente a uma condição do DTE.
3 Esse diagrama é conhecido como diagrama de contexto. O diagra ma de contexto será discutido
em detalhes no capítulo 18.
336
14
O EQUILÍBRIO DOS MODELOS
Todas as pessoas estão 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 capítulo, aprenderemos
1. Como equilibrar um diagrama de fluxo de dados em relação ao dicionário de dados.
2. Como equilibrar um diagrama de fluxo de dados em relação à especificação de processos.

Página 235 de 584
3. Como equilibrar uma especificação de processos em relação ao dicionário de dados.
4. Como equilibrar um DER em relação ao DFD e à especificação de processos.
5. Como equilibrar um DER em relação ao dicionário de dados.
6. Como equilibrar um diagrama de fluxo de dados em relação ao diagrama de transições de estado.
Nos últimos cinco capítulos examinamos diversas ferramentas de
modelagem importantes para a análise estruturada:
• Diagramas de fluxo de dados
• Dicionário de dados
337
1
• Especificação de processos
• Diagramas de entidades-relacionamentos
• Diagramas de transições 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 também está focalizando um dos aspectos fundamentais, isto é, o aspecto para o qual sua
atenção está sendo atraida pela própria ferramenta de modela gem. Como o sistema subjacente
possuí muitas diferentes dimensões de complexidade, queremos que o diagrama de fluxo de dados
atraia a atenção do leitor para as frnções do sistema sem que os relacionamentos entre os dados
distraiam sua atenção; e queremos também que o diagra ma de entidades-relacionamentos focalize
a atenção sobre os relaciona mentos entre os dados sem permitir que as características funcionais
distraiam a atenção do leitor; queremos, ainda, que o diagrama de tran sições de estado focalize a
atenção para as características do timing do sistema sem distrações com funções ou dados.
Mas chega o momento de combinar todas as ferramentas de mode lagem, e é sobre isso que
falaremos neste capítulo. A situação com que o modelador de sistemas se defronta é um tanto
análoga à antiga fábula dos três sábios cegos indianos que esbarraram em um elefante. Como
mostra a figura 14.1, eles emitiram três opiniões diferentes concernen tes à “realidade” com que se
deparavam tocando diferentes partes do elefante:
Figura 14.1: Três 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 dúvida,» 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”.

Página 236 de 584
De modo semelhante, quando modelamos três diferentes aspectos de um sistema (funções, dados e
“timing”), bem como quando modela mos as características detalhadas do sistema em um
dicionário de dados e um conjunto de especificações de processo, é fácil desenvolver várias
interpretações inconsistentes diferentes da realidade. Isso representa um perigo particularmente
sério em grandes projetos, onde várias pessoas e vários grupos de interesses especiais
provavelmente estarão envolvidos. Também é arriscado quando uma equipe de projeto (e/ou a
comunidade usuária) envolve pessoas com formações muito diferentes.
Existe um outro motivo para se focalizar a consistência do modelo:
quaisquer que sejam os erros eles serão encontrados em algum momen to, mas isso se torna cada
vez mais difícil e caro nas fases finais do projeto. Na realidade, os erros que forem introduzidos no
modelo de requisitos durante a fase de análise provavelmente se propagarão e se ampliarão nas
fases de projeto e de implementação do projeto. Isso representa um risco especialmente sério em
grandes projetos em que a análise de sistemas é muitas vezes feita por diferentes pessoas (ou mes
mo por diferentes empresas!) e não as de projeto e implementação. Assim, Martin aponta que 50%
dos erros detectados em um sistema e 75% do custo da remoção de erros relacionam-se aos erros
cometidos na fase de análise do sistema e os estudos em lBoehm, 19811 mostraram que o custo de
correção de um erro cresce exponencialmente nos estágios derradeiros de um projeto; é dez vezes
mais barato corrigir um erro de análise durante a fase de análise do que corrigi-lo na fase de
projeto.
Alguns desses erros são, naturalmente, erros simples em cada modelo (ex.: um diagrama de fluxo
de dados com um poço sem fundo). Alguns desses erros podem ser caracterizados como
interpretações errô neas do que o usuário realmente desejava. Porém, muitos desses erros mais
difíceis e insidiosos são inter-modelos, isto é, inconsistências entre um modelo e outro. Uma
especificação estruturada na qual todas as ferramentas de modelagem são verificadas mediante
referências cruza das em relação a cada uma das outras em busca de consistência é dita ser
equilibrada.
339
O erro de equilíbrio mais comum envolve afaltade uma definição:
alguma coisa definida (Ou descrita) em um modelo não está adequada mente definida em outro.
Veremos alguns exemplos disso nas próximas seções (ex.: um depósito mostrado no DFD mas não
definido no dicio nário de dados, ou um objeto no DER não mostrado como um corres pondente
depósito de dados no DFD). O segundo tipo comum de erro é a inconsistência: a mesma
“realidade” é descrita de modos diferentes e contraditórios em dois diferentes modelos.
Vamos examinar alguns dos principais aspectos do equilíbrio:
• Equilibrar o diagrama de fluxo de dados em relação ao dicionário de dados.
• Equilíbrio do diagrama de fluxo de dados em relação às especi ficações de processos.
• Equilíbrio das especificações de processos em relação ao dicio nário de dados.
• Equilíbrio do DER em relação ao DFD e às especificações de processos.
• Equilíbrio do DER em relação ao dicionário de dados.
• Equilíbrio do DFD em relação ao diagrama de transições de estado.

Página 237 de 584
Como veremos, as regras do equilíbrio são todas muito diretas; elas
exigem muito pouco raciocínio ou criatividade para serem executadas.
Mas elas devem ser executadas e de maneira diligente.
14.1 O EQUILÍBRIO DO DFD EM RELAÇÃO AO DD
As normas para equilibrar o diagrama de fluxo de dados em rela ção ao dicionário de dados são as
seguintes:
• Cada fluxo de dados (uma flexa no DFD) e cada depósito de dados deve ser definido no
dicionário de dados. Se não constar no dicionário de dados, o fluxo de dados ou o depósito é con
siderado como indefinido.
• Inversamente, cada elemento de dados e cada depósito de da dos definido no dicionário de dados
deve aparecer em algum
340
lugar de um DFD. Caso negativo, o elemento ou depósito de dados em questão é um “fantasma” -
algo definido mas não “utilizado” no sistema. Isso pode acontecer se os elementos de dados forem
definidos para corresponderem a uma versão anterior do DFD; o perigo está em que o DFD pode
ser alterado (isto é, um fluxo ou um depósito de dados pode ter sido supri mido) sem uma
correspondente alteração no dicionário de dados.
Isso, naturalmente, significa que o analista de sistemas deve rever meticulosamente os DFD e o
dicionário de dados para se certificar que estejam equilibrados. Não 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 dicionário de da dos. Como todas as outras atividades de
equilíbrio (balanceamento) neste capítulo, esse é um serviço entediante e que se presta muito bem
aos produtos automatizados.
14.2 O EQUILÍBRIO DO DFD EM RELAÇÃO À ESPECIFICAÇÃO DE PROCESSOS
Eis as normas para o equilíbrio do DFI) em relação às especifica ções de processos:
Cada bolha no DFD deve estar associada a um DFD do nível imediatamente inferior ou a uma
especificação de processos, mas não a ambos. Dessa forma, se o DFD mostrar uma bolha
identificada como 1.4.2, então deve existir ou uma figura correspondente, identificada como figura
1.4.2, cujas bolhas são identificadas como 1.4.2.1, 1.4.2.2 etc., ou a especificação es truturada deve
conter uma especificação dc processo para a bolha 1.4.2. Se ambas existirem, o modelo é
dcsnecessariamente (e perigosamente) redundante.
Cada especificação de processo deve estar associada a uma bolha do nível básico de um I)FI).
Como a especificação de processos não exige grande volume de isabalho, poder-se-ia pensar ser
altamente improvável que possa haver especificações de processos “errantes” flutuando no sistema.
Mas isso pode acontecer: a especificação de processos pode ter sido escrita para uma versão
preliminar do DFD, após o que algumas das bolhas do DFD poderiam ter sido eliminadas em
algum pro cesso de revisão.
341
• Entradas e saídas devem corresponder. O DFD deve apresentar fluxos que chegam e que saem de

Página 238 de 584
cada bolha, bem como co nexões com os depósitos. Tudo isso também deve estar evidente na
especificação 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 comentários aplicam-se especificamente a bo lhas de pmcessaniento. Para as
bolhas de conirole de um DFD existem correspondências entre essas bolhas e os diagramas
associados de transi ções de estado, como discutimos na seção 14.6.
14.3 O EQUILÍBRIO DAS ESPECIFICAÇÕES DE
PROCESSOS EM RELAÇÃO AO DFD E AO DD
As normas para equilibrar as especificações de processos em rela ção ao diagrama de fluxo de
dados e ao dicionário de dados podem ser descritas da forma que se segue: cada referência 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 pósito de dados interligado à bolha
descrita pela especificação
de processos, ou
• ela é um termo local, explicitamente definido na especificação de processos, ou
• ela aparece como um componenlecm um item do dicionário de dados para um fluxo ou depósito
de dados interligado à bolha. Desse modo, os elementos de dados X e Y aparecem na espe
cificação de processo da figura 14.2, mas não como um fluxo de dados interligado no DFD
mostrado na figura 14.3. Entretanto, o dicionário 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, concluímos que o modelo é equilibrado 1•
342
ESPECIFICAÇÃO DE PROCESSO 3.5: CALCULAR FATOR HIPOTÉTICO
* P E O SÃO TERMOS LOCAIS UTILIZADOS EM RESULTADOS INTERMEDIÁRIOS
P = 3.14156 *
O = 2.78128 * Y - 13
FATOR-HIPOTÉTICO = P * Q + 2
Figura 14.2: Um componente de uma espec de processo de um modelo
de sistema
Z fator-hipotético
Figura 14.3: Um componente de DFD de um modelo de sistema
X = * componente horizontal do fator frammis *
* unidade: centímetros; intervalo: O - 100 *
= * componente vertical do fator frammis *
* unidade: centímetros; intervalo: 0- 10 *

Página 239 de 584
Z = * fator frammis, como definido pelo Dr. Frammis *
x+Y
Figura 14.4: Um componente do dicionário de dados de um modelo de sistemas
343
14.4 O EQUILÍBRIO DO DICIONÁRIO DE DADOS EM RELAÇÃO AO DFD E ÀS
ESPECIFICAÇÕES
DE PROCESSOS
Da discussão acima, pode-se ver que o dicionário de dados está
consistente com o restante do modelo se obedecer à seguinte regra:
• Cada item do dicionário deve ser referenciado por uma especi ficação de processo, ou por um
DFD, ou por outro item do di cionário de dados.
Isso naturalmente pressupõe que estamos modelando o compor tamento essencial de um sistema.
Um dicionário de dados complexo e completo de uma implementação existente dc um sistema
pode conter alguns elementos de dados que já não são mais usados.
Alguém poderia também argumentar que o dicionário de dados poderia ser planejado de tal forma
que permitisse sua futura expansão; isto é, ele contém elementos que não são necessários hoje, mas
podem vir a ser úteis no futuro. Um bom exemplo disso é um dicionário de dados que contém
elementos que possam ser úteis para pesquisas id boc . A equipe de projeto, talvez em combinação
com o usuário, pode determinar se esse tipo de modelo desequilibrado é realmente algo adequado a
ser feito. Entretanto, é importante ao menos ter cautela com essas decisões deliberadas.
14.5 O EQUILÍBRIO DO DER EM RELAÇÃO AO DFD E Às ESPECIFICAÇÕES DE
PROCESSOS
O diagrama de entidades-relacionamentos, como vimos no capítulo 12, apresenta uma visão 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 depósito do DFD deve corresponder a um tipo de objeto ou a um relacionamento ou à
combinação de um tipo de objeto e de um relacionamento (isto é, um tipo associativo de objeto) do
DER. Se houver um depósito no DFD que não apareça no DER, algo está errado; e se houver um
objeto ou um relacio namento no DER que não apareça no DFD, também há algum erro.
344
• Os nomes de objetos no DER e os de depósitos de dados no DFD devem coincidir. Como vimos
nos capítulos 9 e 12, a con venção neste livro é usar a forma plural (ex.: CLIENTES) no DFD e a
forma singular no DER.
• Os itens do dicionário de dados devem aplicar-se tanto ao mo delo de DFD como ao de DER.
Dessa forma, o item do di cionário de dados para o exemplo acima deve incluir definições para o
objeto no DER e para o depósito no DER. Isso implica uma definição no dicionário de dados como
a que se segue:
CLIENTES = ICLIENTE}

Página 240 de 584
CLIENTE = nome + endereço + número-de-telefone +...
Os itens do dicionário de dados para a forma singular (ex.:
CLIENTE) devem informar o significado e a composição de uma única instância do conjunto de
objetos mencionados (no singular) no DER e (no plural) no depósito de dados de um DFD. Os
itens do dicionário de dados para a forma plural (ex.: CLIENTES) dão o significado e a com
posição do conjunto de instâncias.
De modo semelhante, existem normas para assegurar que o DER esteja consistente com a parte da
especificação de processos relativa ao modelo orientado para funções (lembre-se que as
especificações de processos são os componentes detalhados do modelo cuja “encarnação” gráfica é
o DFD). As normas estabelecem que o conjunto combinado de todas as especificações de
processos deve, em sua inteireza:
• Criar e suprimir instâncias 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 depósito
CLIENTES corresponde ao objeto CLIENTE. Alguma coisa deve ser capaz de criar e suprimir
instâncias de um cliente, o que significa que alguma bolha do DFD deve ter um fluxo de dados
interligado ao depósito CLIENTES. Mas a tarefa real de escrever no depósito (isto é, de criar ou
suprimir uma instância do objeto CLIENTE correspondente no DRD) deve ocorrer den tm dessa
bolha, o que quer dizer que deve ser documentado pela especificação de processo associada àquela
bolha 2
• Alguma bolha do DFD estabelece valores para cada elemento de dado atribuído a cada instância
de cada tipo de objeto, e algum processo do DFD usa (ou lê) valores de cada elemento de dado.
14.6 O EQUILÍBRIO DO DFI) EM RELAÇÃO AO
DIAGRAMA DE TRANSIÇÕES DE ESTADO
A condição de estado pode ser considerada equilibrada em relação
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 transições de estado como sua
especificação de processo. De modo semelhante, cada diagrama de transições de estado no modelo
geral do sistema deve estar associado a um processo de controle (bolha) no DFD.
• Cada condição no diagrama de transições de estado deve cor responder a um fluxo de controle
que chega ao processo de controle associado ao diagrama de transições de estado. De modo
semelhante, cada fluxo de controle que chega à bolha de controle deve estar associado a uma
condição apropriada no correspondente diagrama de transições de estado.
Figura 14.5: Criação e eliminação de instâncias do DER
CLIENTES
detalhes-de-cliente
ITENS
346
• Cada ação no diagrama de transições de estado deve correspon der a um fluxo de controle que sai
no processo de controle associado ao diagrama de transições de estado. Do mesmo modo, cada

Página 241 de 584
fluxo de controle que sai na bolha de controle deve estar associado a uma ação apropriada no
correspondente dia grama de transições de estado.
Essas correspondências são mostradas na figura 14.6.
Figura 14.6: Correspondências entre o DFD e o DTE
14.7 RESUMO
Observe que todas as normas de equilíbrio neste capítulo foram apresentadas como se você fosse
examinar pessoalmente todos os com ponentes de um modelo de sistema para descobrir possíveis
erros ou inconsistências. Isso poderia exigir que você desenhasse, no chão ou em um quadro de
avisos de grandes dimensões, todos os DFD, especifica ções de processos, DER, DTE e dicionário
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 organizações de desenvol vimento de sistemas no mundo. Se você tiver a sorte de o
estar lendo por volta de 1990, a estimativa pode ter caído para 90%. E se você ainda estiver lendo
este livro em 1995 (quando meu editor já deve ter-me obrigado a produzir uma nova edição na qual
toda esta seção terá sido eliminada), a perspectiva deverá ser de 50%. O importante é que as
normas de equilíbrio que apresentamos neste capítulo podem ser auto matizadas, e já existem
diversas ferramentas para estações de trabalho, baseadas em PC, que executarão mecanicamente
algumas ou todas as verificações de erros.
Vimos, porém, exatamente o mesmo fenômeno em várias outras áreas. Alguém poderia objetar que
a proliferação dos baratos sistemas de processamento de palavras eliminou a necessidade de se
aprender a escrever à mão; na verdade, também se poderia argumentar que a dispo nibilidade de
verificadores da correção 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 divisões. Do mesmo modo a ubíqua presença dos carros de mudança
automática de marcha eliminou a necessidade dc se aprender a dirigir automóveis com alavanca de
mudança.
Eu, na verdade, não consigo imaginar qualquer razão para se en sinar uma pessoa na América do
Norte a dirigir um carro com alavanca de mudança quando já nos aproximamos do final do século
XX. Nem posso imaginar qualquer motivo para se enfatizar a arte da caligrafia e da escrita à mão
(exceto, naturalmente, como uma forma de arte) em uma época em que os sistemas de
processamento de palavras estão prestes a serem substituídos pelos sistemas de reconhecimento de
voz. Mas posso entender a necessidade de se aprender os princípios básicos de uma longa divisão,
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 mínimo, nos ajudará a
sabermos se a resposta produzida com a calculadora tem o ponto decimal no lugar correto.
Alguém pode defender os méritos de se aprender a escrever ma nualmente em 1987, quando (1)
menos da metade das crianças privile giadas nos Estados Unidos tem um computador pessoal em

Página 242 de 584
casa; (2) apenas cerca de 3% da população americana em geral tem um computa dor pessoal em
casa; (3) cerca de somente 10% dos professores america nos tem seu próprio PC e (4) apenas uma
pequenina percentagem das escolas nos EUA está preparada para ensinar as habilidades mecânicas
da digitação. A escrita manual é tecnologícamenje obsoleta, e é doloroso para os pais versados em
computação (para não mencionar os filhos versados em computação!) serem forçados a ensinar
essa antiga e
348
primitiva técnica de comunicação; mas ela provavelmente ainda é uma habilidade necessária na
sociedade de hoje. Afinal de contas, foi apenas há uns poucos anos atrás que a maioria dos pais
parou de ensinar aos filhos como substituir as velas, trocar o óleo e consertar um pneu baixo do
automóvel.
Estou igualmente convencido de que o analista de sistemas profis sional precisa conhecer os
princípios dc equilíbrio apresentados neste capítulo. Como analista de sistemas é provável que
você não tenha outra alternativa senão executar essas normas de verificação de erros
mecanicamente pelos próximos anos até que as ferramentas adequadas de engenharia de software
estejam amplamente disseminadas. O processo manual de verificação de erros será normalmente
validado em ambiente de caminhamentos (walkthrough); essa técnica é discutida no apêndice D.
REFERÊNCIAS
1. James Martin, An Information Systems Manifesto. Englewood Cliffs,
2. Barry Boehm, Software Engineering Economics. Englewood Cliffs, N.J.: Prentice-Hall, 1981.
1. Por que é importante equilibrar os modelos da especificação de um sistema? Quais são os riscos
de uma especificação desequilibrada?
2. Por que é importante descobrir os erros do modelo de um sistema o mais cedo possível?
3. Que percentagem do custo da eliminação de erros está associada à fase de análise de sistemas de
um projeto?
4. Quais são as duas formas mais comuns de erros de equilíbrio?
5. O DFD deve ser equilibrado em relação a quais partes do modelo do sistema?
6. O DER deve ser equilibrado em relação a quais partes do modelo do sistema?
7. O DTE deve ser equilibrado em relação a quais partes do modelo do sistema?
8. O dicionário de dados deve ser equilibrado em relação a quais partes do modelo do sistema?
9. A especificação de processos deve ser equilibrada em relação a quais partes do modelo do
sistema?
349
10. Existem outros componentes do modelo do sistema que devam scr equilibrados?
11. Quais são as normas para equilibrar o DFD em relação ao dicio nário de dados?
12. Sob que condições pode um item ser definido no dicionário de dados sem aparecer em algum

Página 243 de 584
lugar de um DFD?
13. Quais são as normas para equilibrar o DFD em relação às especifi cações de processos?
O que aconteceria se uma especificação de processo fosse escrita para uma bolha não-primitiva (ou
não-atômica) do DFD?
Deve existir uma especificação de processo para processos de controle do DFD? Se assim for, ela
deve ter a mesma forma que a especificação de um processo normal?
Quais são as normas para equilibrar a especificação de processos em relação ao DFD e ao
O que são «dados errantes”?
Sob que condições é aceitável haver um termo (Ou referência de dado) na especificação de
processos para não ser definido no di cionário de dados?
Quais são as normas para equilibrar o dicionário de dados em relação ao DFD e à especificação de
processos?
Sob que condições é possível que a equipe de projeto coloque deliberaa’amenje itens no dicionário
de dados que não constem no
DFD?
Quais são as normas para equilibrar o DER em relação ao DFD? Qual é a convenção para nomes
no DER coincidentes com depósi tos no DFD?
Quais são as normas para equilibrar o DER em relação à especifi cação de processos?
Quais são as normas para equilibrar o DTE em relação ao DFD? Sob que circunstâncias é válido
não haver um DTE no modelo de um sistema?
Como as normas de equilíbrio apresentadas neste capítulo devem ser observadas em um típico
projeto de desenvolvimento de siste mas? Quem deveria ser o responsável cm verificar se isso foi
feito? Se você dispuser de uma estação automatizada de trabalho para análise de sistemas, é
necessário conhecer as normas de equilíbrio apresentadas neste capítulo? Por quê?
Se os modelos de sistema tiverem sido equilibrados, podemos confiar em que estejam corretos? Por
quê?
29. Mostre três erros de equilíbrio no modelo de sistema abaixo
NOTAS
Contudo, pode valer a pena fazer mais algumas verificações nesse ponto: se X for o único
componente de Z utilizado na espe cificação 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 Implementação arbitrária de um sistema, em vez de um modelo do comportamento essencial
do sistema.
2 A situação pode ser um pouco mais complicada: a bolha mostrada no DFD pode não ser uma
bolha do nível mais baixo. Desse modo, é possível que a bolha rotulada INTRODUZA-NOVO-
CLIENTE na figura 14.5 possa ser descrita por um diagrama defluxo de dados de nível inferior,

Página 244 de 584
não por uma especificação de processo. Se for esse o caso, então uma das bolhas de nível inferior
(talvez não um nível, mas vários níveis abaixo) será primitiva e terá acesso ao depósito
diretamente. Lembre-se, do capítulo 9, que pela nossa convenção no DFD o depósito é mostrado
no mais alto nível em que ele é uma interface entre duas bolhas e é repetido em todos os diagramas
de nível inferior.
z
Y
30. O DTE deve ser equilibrado em relação ao DER? Por quê?
351
á’
15
FERRAMENTAS
ADICIONAIS DE
M ODELAGEM
A necessidade de descobrir a ineficiência o quanto antes torna impor tante que se externalize (isto
é, que se torne visível) cada estágio de um projeto em andamento. As plantas de engenharia, por
exemplo, cum previ esta finalidade e são úteis não somente para um projetista, atrain do sua
atenção para pontos duvidosos e potenciais inconsistências, mas, também, para uma equ ou toda
uma organização que esteja desen tolvendo um produto. Os planos são os principais meios de
comunica ção, crítica e refinamento coletiva. Além disso, os métodos de representa ção devem ser
relativamente simples e diretos para transpor o espaço entre a realidade e o programa; e devem ser
eficientes em todas as múltiplas etapas iterativas.
L.A.Belady, prefácio a Software Design, EPeters, 19811
1. Como identificar diversas variações dos fluxogramas.
2. Como desenhar diagramas FIIPO e diagramas estruturais.
3. Como identificar diversas variações dos DFD.
4. Como identificar diversas variações dos DER.
As ferramentas de modelagem apresentadas nestes últimos capítu 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 não 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 capítulo incluem:
• Fluxogramas e suas variantes.
• Fluxogramas de sistemas.
• Diagramas HIPO e gráficos estruturais.

Página 245 de 584
• Variações nos diagramas de fluxo de dados.
• Variações nos diagramas de entidades-relacionamentos.
O propósito deste capítulo não é fazer de você um perito em qual quer dessas ferramentas de
modelagem, mas apenas mostrar-lhe que elas existem como alternativas possíveis. Detalhes
suplementares de cada ferramenta de modelagem podem ser encontrados nas referências do final
do capítulo.
15.1 FLUXOGRAMAS E SUAS VARIANTES
15.1.1 O Fluxograma Clássico
Uma das mais antigas e melhores ferramentas de modelagem co nhecidas é o fluxograma clássico;
um fluxograma típico é mostrado na
figura 15.1.
Se você já teve algum contato com computadores, ou programa ção, ou processamento de dados, é
provável que tenha tido pelo menos alguma relação informal com os fluxogramas. Não os
estudaremos em detalhe neste livro, e somente daremos uma olhada em um subconjunto da notação
de diagramação. Para detalhes sobre notação de fluxogra mas, recorra a [ 19701.
A notação apresentada na figura 15.1 tem somente três compo nentes:
• O quadro retangular representa uma instrução executável de computador ou uma sequência de
inslruções conlí
• O quadro em forma de losango representa uma decisão; no caso mais simples representa uma
decisão binária.
• 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 típico
isto é, quando uma instrução termina sua execução, o fluxo pode prosseguir para alguma instrução
ou decisão única sub seqüente. De modo semelhante, só pode haver duas setas ori ginando-se de
uma decisão.
Como você pode ver, os fluxogramas nos permitem representar graficamente a lógica procedural
de um programa de computador. É nessa área que os fluxogramas são mais usados, embora a
introdução de linguagens de programação de alto nível nos anos 60 e 70 tenha elimi nado grande
parte da necessidade de fluxogramas detalhados.
Porém, se os fluxogramas são uma das ferramentas de programa ção, por que’discuti-los nesse
livro? A resposta já lhe deve ter ocorrido:
alguns analistas de sistemas usam fluxogramas como um meio de docu-, mentar as especificações
de processos (isto é, como uma alternativa à linguagem estruturada e às outras ferramentas
apresentadas no capitulo 11). Como se pode recordar do capítulo 11, minha opinião é que qual quer
técnica de documentação que descreva corretamente as exigências do usuário e que comunique
efetivamente essas exigências, é aceitável. Desse modo, se o usuário gosta de ler fluxogramas e se
estes descrevem

Página 246 de 584
355
com exatidão 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 especificações de processos. Existem
diversas razões 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 típico fluxograma não-estruturado é mos
trado na figura 15.2.
• Embora o suporte automatizado (em estações de trabalho basea das em PC) esteja agora
disponível, ele ainda requer um tra balho considerável para se desenvolver os gráficos de um
fluxograma. E, se os detalhes da orientação do usuário se modi ficarem, ou se o analista de
sistemas tiver que alterá-los muitas vezes até que tenha alguma coisa que o usuário aceite como
correta, será uma tarefa tediosa e consumidora de tempo rede senhar o fluxograma a cada vez. Se a
especificação de processos estiver representada sob alguma forma textual que possa ser manipulada
com um processador de palavras, as mudanças costumam ser muito mais fáceis.
• Os modelos gráficos são geralmente mais eficazes como meio de ilustrar uma realidade
mullklimensional. Os diagramas de fluxo de dados, por exemplo, ilustram de forma vívida 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 especificação de um processo individual pode ser descrito sob forma
unidimensional; isto é, a lógica pode ser organizada de forma a fluir uniformemente de “alto a
baixo” l:ace a isso os gráficos tornam-se desnecessários.
15.1.2 Variações dos Fluxogramas
Embora os fluxogramas clássicos sejam os mais utilizados - quan do são utilizados - existem
algumas variações que você deve conhecer.
Mencionaremos quatro delas:
1. Diagramas de Nassi-Shneiderman
2. Diagramas de Ferstl
3. Diagramas de Hamilton-Zeldin
4. Diagramas de análise 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
reforçar a estrita abordagem da programação estruturada. A figura 15.3 mostra um dia grama de
Nassi-Shneidcrman típico. Como se pode ver, o diagrama é fácil de ser lido. Entretanto, pode-se
objetar que os diagramas de Nassi Shneiderman nada mais são do que declarações cm linguagem
estruturada com quadros ao redor.
Os diagramas de Fersil são uma outra variação do fluxograma clás sico; [ 19781 apresenta uma

Página 247 de 584
completa descrição deles. A figura 15.4(a) mostra um diagrama de Fcrstl típico. Além de mostrar a
lógica seqüencia! normal de programas, o diagrama de Ferstl também pode ser usado para mostrar
o processamento em paralelo; a notação Ferstl para processamento em paralelo é mostrada na
figura 15.4(b).
Os diagramas de Jíamilton-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 típico diagrama de Hamilton-Zeldin,
também conhecido por diagrama estruturado de projeto. Nesses diagramas, os quadros retangulares
têm o mesmo significado que os dos fluxogramas ANSI: um comando executável ou um grupo de
comandos executáveis
Figura 15.2: Umfluxograrna não-estruturado
357
Obter registro mestre
Obter registro de transação
N DO WHILE existirem mais transações OR existirem mais registros mestres
Imprimir mestre ver - mestre <transação?
Z
atualizar mestre
dadeiro falso
obter novo mestre Imprimir mestrel imprimir erro
obter nova transação
Fechar arquivo mestre
Fechar arquivo de transações
contínuos.Um pentágono alongado é empregado para mostrar coman dos IF e iterações DO-
WHILE/REPEAT- UNTIL. O controle flui normal mente de cima para baixq no diagrama, exceto
no caso de testes IF e de iterações (DOs e REPEA que vão da esquerda para a direita.
Diagramas de análise c problemas (DAP), deseiwolvido na
Hitachi Corporation (veja IFutam’ Kawai, Horikoshi e Tsutsumi,
1981]), são uma representação bidimensional, com estrutura em árvore,
Figura 15.3: Um diagrama de Nassi-Shneiderman típico
Figura 15.4 (a) Um diagrama de Fers:1 típico
358
da lógica de programas. Os componentes dc um DAP são mostrados na figura 15.6(a). Assim comt
os diagramas de Ilamilton-Zeldin, os DAP são lidos de cima para baixo, com as estruturas dc IF e
as iterações 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 também
utiliza uma combinação de fluxo se qüencial vertical com níveis dc aninhamento horizontais (cx.:

Página 248 de 584
laços dentro de laços dentro de outros laços) semelhante à dos diagramas de Hamilton Zeldin.
15.2 FLUXOGRAMAS DE SISTEMA
As abordagens de fluxogramas vistas nas seções precedentes são úteis para mostrar lógica
detalhada, em um programa de computador ou em uma especificação de processo para uma
determinada bolha de um DFD. Contudo, uma visão de alto nível da organização 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 típico.
.
Isso indica que o processo P é composto pelos processos P1 Pn, que podem ser executados em
paralelo
Figura 15.4 (b): Notação 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
CONDIÇÃO
(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, execuções e outras uni dades de software de processamento). O fluxograma
de sistema também mostra diversos tipos de arquivos fisicos (ex.: arquivos em fita magnética ou
em discos), podendo mostrar ainda a presença de terminais on-line e elos de telecomunicação.
O fluxograma de sistema é muitas vezes um diagrama bastante útil para os projetistas de sistemas
que têm de desenvolver a arquitetura
360
ATÉ c2 P2
P3
NQUANTOc3 P4
Figura 15.6(b): Um DAP típico
geral de hardware e software de um sistema para implementar os requi sitos do usuário. Entretanto,
minha opinião é que esse recurso não é uma ferramenta adequada de modelagem para a análise de
sistemas pela simples razão de que ele enfatiza os detalhes fisicos da implementação que o usuário
e o analista de sistemas não devem discutir. Em lugar de tecerem considerações sobre um arquivo
em disco, por exemplo, o ana lista de sistemas e o usuário devem discutir o conteúdo do arquivo;

Página 249 de 584
em vez de falarem sobre programas individuais eles devem discutir as funções que devem ser
executadas.
Existe uma situação em que o fluxograma de sistema pode ter muita utilidade como ferramenta de
modelagem: no final da atividade da análise do sistema, quando o modelo de implementação do
usuário esti ver sendo elaborado. Naquele ponto, o usuário, o analista de sistemas e a equipe de
implementação (projetistas e programadores) discutem as restrições da implementação que devem
ser impostas ao sistema; essas restrições incluem coisas como a determinação da fronteira da
automati zação (que partes do sistema serão automatizadas e que partes serão manuais) e a
interface humana (detalhes da interação entre o sistema e os usuários humanos).
361
Figura. 15.7: Um típico fluxograma de sistema
15.3 OS DIAGRAMAS HIPO
Os diagramas HIPO foram desenvolvidos pela IBM nos anos 70 (veja [ 1974] e EKatzan, 1976]) e
têm sido utilizados por alguns analistas de sistemas para apresentar uma visão de alto nível das
funções executadas por um sistema, bem como a decomposição de funções em subfunções etc. A
figura 15.8 mostra um diagrama HIPO típico.
Em alguns ambientes usuários, 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 não mostra os dados utilizados ou
produzidos pelo sistema; embora seja compreensível que
362
Figura 15.8: Um diagrama HIPO típico
alguém queira deserifatizar os relacionamentos de dados em um modelo,
não creio que isso ajude a eliminar todas as informações sobre os dados.
Em realidade existe um segundo componente do diagrama HIPO que não mostra os dados. O
diagrama mostrado na figura 15.8 é conhe cido como VTOC (visual table of contents). Cada
função 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 típico.
Embora os detalhes dos dados sejam de fato mostrados nesse nível, não o são no diagrama VTOC
de alto nível. Assim, alguém que examine uma vista geral do sistema não verá com facilidade as
interfaces entre os diversos componentes do sistema.
15.4 DIAGRAMAS ESTRUTURAIS
Uma variação dos diagramas HIPO que tem ampla utilização é o
diagrama estrutural. A figura 15.10 mostra um diagrama estrutural
363
,eniente de ATUALIZAR-CAMPO-MESTRE
ENTRADA PROCESSO: Obter transação válida SAÍD
POINTER = O

Página 250 de 584
CALL INICIALIZATRANS transação
REPEAT UNTIL fim do arquivo OR
fim da transação
primeiro CALL OBTER CAMPO VÁLIDO primeir3
cartão daT IF NOT fim do arquivo or fim cartão da
transação da transação transaçãc
ENDIF COLETAR CAMPOS seguinte
ENDREPEAT
do-ar
Para: INICIALIZATRANS
OBTER CAMPOS VÁLIDOS
COLE1rAR CAMPOS
Figura 15.9: Um diagrama IFV típico
típico; observe que além de mostrar a hierarquia funcional, ele também
mostra as interfaces de dados entre os componentes.
De modo diverso de muitos dos diagramas anteriores, o quadro retangular em um diagrama
estrutural não representa uma única de claração computacional ou um grupo contíguo de
declarações; em vez disso, ele representa um módulo (exemplos comuns de módulos são sub-
rotinas FORTRAN, procedimentos Pascal, subprogramas e seções COBOL). As setas que
interligam os módulos não representam coman dos GOTO e, sim, chamadas a sub-rotinas; a
notação implica em que a sub-rotina sairá ou retornará para o ponto de onde foi chamada, ao
terminar de executar sua função.
Embora o diagrama estrutural seja mais utilizado que o diagrama HIPO, ele de fato não tem uso na
área da análise de sistemas. Por quê? Porque ele é utilizado como uma ferramenta de projeto para
modelar a hierarquia sincrontzada de módulos de um sistema; sincronizada quer
364
Figura 15.10: Um diagrama estrutural típico
dizer que apenas um módulo é executado a cada momento, o que é uma acurada representação 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 assíncronas dc processos; isso é efetivamente realizado com o conjunto de diagramas dc
fluxo de dados em vários níveis.
O diagrama estrutural é extensivamente utilizado em projeto de programas; veremos isso
detalhadamcnte no capítulo 22.
15.5 VARIAÇÕES DOS DIAGRAMAS DE FLUXO DE DADOS
Como dissemos no capítulo 9, existem diversas diferenças “cosmé ticas” entre os diagramas de
fluxo de dados deste livro e os apresentados em outros livros. As principais diferenças são,

Página 251 de 584
geralmente, relativas a detalhes como a utilização de retângulos ou ovais em lugar de bolhas para
mostrar as funções 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 variação do diagra ma de fluxo de dados clássico;
essa variação é conhecida como diagrama
365
SADT, tendo sido desenvolvido pela Sofiech (veja lRoss e Schornan, 19771). A figura 15.11
mostra um diagrama SADT típico.
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 restrições
topológicas no diagrama, o que muitos analistas de sistemas consideram complicado.
mecanismo
de suporte
Figura 15.11: Um diagrama SÁDT típico
15.6 VARIAÇÕES DOS DIAGRAMAS DE ENTIDADES- RELACIONAMENTOS
Os diagramas de entidades-relacionamentos apresentados no capí tulo 12 são considerados pela
maioria dos analistas de sistemas como sendo o recurso mais geral e abstrato de representar
relacionamentos de dados. Contudo, existem pelo menos três outras conhecidas notações 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
década de 60. A figura 15.12 mostra um diagrama de Bachman típico. Observe que ele é
semelhante ao diagrama de entidades-relacionamen tos discutido no capítulo 12, porém não mostra
explicitamente o relacio namento entre os objetos. Observe também 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 derável popularidade nos
últimos dez anos; a figura 15.13 apresenta um diagrama de estrutura de dados típico. Observe que
além de mostrar cada objeto do modelo de dados, o diagrama mostra o campo chave; como você
deve recordar, a convenção usada neste livro é mostrar o campo chave no dicionário de dados.
Embora os diagramas de estrutura de dados de Jackson não sejam largamente utilizados nos
Estados Unidos atualmente, eles são 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 são um tanto mais populares nos Estados Unidos. Em vez de focalizarem

Página 252 de 584
os relacionamentos entre os
Figura 15.12: Um diagrama de Bach man típico
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 gráfico para
mostrar a estrutura hierárquica de um único objeto. Os componentes de um diagrama de Jackson
são mostradõs na figu ra 15.14(a); observe que essa mesma estrutura hierárquica também pode ser
documentada diretamente no dicionário de dados utilizando- se a notação apresentada no capítulo
11, como se mostra na figura 15.14(b).
15.7 RESUMO
A lista de ferramentas de modelagem apresentada neste capítulo não é completa e nenhuma das
ferramentas alternativas de modelagem foi discutida detalhadamente; para obter mais detalhes você
terá de consultar as referências no final do capítulo. Entretanto, lembre-se que você pode jamais
ver qualquer desses diagramas em um projeto real (com a provável exceção do ubíquo
fluxograma); desse modo, não recomendo que você conheça 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 técnicas de
diagramação totalmente idiossincrásicas que não tenham sido vistas
neste livro (e talvez não discutidas em nenhum livro!). Isso não deve
368
O asterisco ‘ é usado para indicar iteração, e
o “o” é usado para indicar uma opção (“either-or”).
Dessa forma, este modelo indica que o elemento de dados (ou objeto) X consiste em zero ou mais
ocorrências 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 típico diagrama de estrutura de dados deJackson
X = {A} + B + E
B = IC 1 D
Figura 15.14 (b): Notação de dicionário 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 diferença entre boas e m4s ferramentas de modelagem;
se você se deparar com novas técnicas de diagramação, releia o capítulo 8 para identificar os
critérios para boas ferramentas de modelagem.
REFERÊNCIAS

Página 253 de 584
1. Ned Chapin, “Flowcharting with the ANSI Standard: A Tutorial’, ACM Computíng Su?veys,
Volume 2, Número 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, Número 5 (maio de 1966), pgs.
366- 371. Também 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, Número 8 (agos to de 1973), pgs. 12-26.
4. Ned Chapin, “New Format for FlowcharLs”, Software - Pract and Experience, Volume 4,
Número 4 (outubro-dezembro de
1974), pgs. 341-357.
5. O. Ferstl, “Flowcharting by Stepwise Refinement”, ACM SIGPL4N Notices, Volume 13,
Número 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, Número 1, janeiro dc 1977, pgs. 6-15. Rcimpresso em Classics
in Software Engineeríng, E. Yourdori (editor). Nova lorque:
370
11. C.W. Bachman, “Data Structure Diagrams”, Data Base, The Quar terly Newsletler of lhe
Special lnlerest Group on Business Data Pro cessín,g ofthe ACM, Volume 1, Número 2 (Verão de
1969), pgs. 4-10.
12. Tom DeMarco, Structured Analysis and Systems Speczfication. Nova lorque: YOURDON
Press, 1978.
13. Michael Jackson, Principies of Program Desígn. Londres: Academic Press, 1975.

Página 254 de 584
14. Larry Peters, Software Design: Methods and Techniques. Nova lor que: YOURDON Press,
1981.
15. Ken Orr, Structured Systems Deveiopment. Nova Jorque:
16. Jean-Dominique Warnier, Logícal Construction of Programas, 3 ed., traduzida por B. Flanagan,
Nova Jorque: Van Nostrand
Reinhold, 1976.
1. Por que é importante conhecer outras ferramentas de modelagem além de DFD, DER e DTE?
2. Quais são os três principais componentes de um- fluxograma?
3. Projeto de Pesquisa: Que ícones adicionais são às vezes utilizados em fluxogramas? (Consulte
Chapin IChapin, 1970] para maiores
informações).
4. Quantas setas podem emanar de um quadro de processo em um fluxograma?
5. Qual é a diferença entre um fluxograma e um diagrama de fluxo de dados?
6. Desenhe um fluxograma para um algoritmo de pesquisa binária.
7. Desenhe um fluxograma para um algoritmo de ordenação (sort) de simples troca.
8. Desenhe um fluxograma para uma aproximação de Newton-Ra phson para o cálculo da raiz
quadrada.
9. Quais são os três principais motivos para não se usar os fluxogramas?
10. Quais são as quatro principais variações dos fluxogramas?
11. O que é um diagrama de Nassi-Shneiderman? Apresente um sinôni mo conhecido para esse
diagrama.
12. Desenhe um diagrama de Nassi-Shneiderman para um algoritmo de pesquisa binária.
13. Desenhe um diagrama de Nassi-Shneidcrman para uma ordenação (sorO de simples troca.
14. Desenhe um diagrama de Nassi-Shneiderman para aproximação da função raiz quadrada pelo
método de Newton-Raphson.
371
15. O que é o diagrama de Ferstl
16. Desenhe um diagrama de Ferstl para um algoritmo de pesquisa binária.
17. Desenhe um diagrama de Ferstl para uma ordenação (sort) de simples troca.
18. ‘Desenhe um diagrama de Ferstl para o método 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 não pode?

Página 255 de 584
20. O que é um diagrama de Hamilton-Zeldin? Apresente um sinônimo para esse diagrama.Onde
ele foi desenvolvido?
21. Desenhe um diagrama de Hamilton-Zeldin para um algoritmo de pesquisa binária.
22. Desenhe um diagrama de Hamilton-Zcldin para uma ordenação (sort) de simples troca.
23. Desenhe um diagrama de 1-lamilton-Zeldin para a aproximação da raiz quadrada pelo método
dc Ncwton-Raphson.
24. O que é um DAP? Onde ele foi desenvolvido?
25. Desenhe um DAP para um algoritmo de pesquisa binária.
26. Desenhe um DAP para uma ordenação (sort) de intercâmbio simples.
27. Desenhe um DAP para a aproximaçào da raiz quadrada pelo méto do de Newton-Raphson.
28. Quais as características que os diagramas de Ferstl e os DAP têm em comum?
29. O que é um fluxograma de sistema? Para que serve?
30. Em que estágio do desenvolvimento de um sistema de informações é provável 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-saída (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 binária.
35. Desenhe um diagrama IPO para uma ordenação (sorO de simples troca.
36. Desenhe um diagrama IPO para a aproximação da raiz quadrada pelo método de Newton-
Raphson.
37. O que é um diagrama estrutural?
38. Qual é a diferença 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
análise de sistemas?
41. O que é um diagrama SADT’ Qual é a diferença entre um diagrama SADT e um diagrama de
fluxo de dados?
42. O que é um diagrama de Bachman? Qual é a diferença 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 diferença entre um diagrama
de estrutura de dados d DeMarco e
um diagrama de entidades-relacionamentos?

Página 256 de 584
44. O que é um diagrama de estrutura de dados de Jackson? Qual é a diferença entre um diagrama
de estrutura de dados de Jackson e
um diagrama de entidades-relacionamentos?
NOTAS
1 Como conseqüência disso, uma espeqflcação desenvolvida com fluxogramas seria enormemente
maior do que uma especificação desenvolvida com as outras ferramentas de modelagem estudadas
neste livro.
2 O fato de que qualquer lógica arbitrária de fluxograma possa ser reorganizada em seu equivalente
fluxo de alto a baixo é o funda mento da programação estnsturada. Bõhm e Jacopinil2l foram os
primeiros a provar que isso podia ser feito em termos de fluxogra mas; em termos de programação,
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 ilustração r quer com a fragilidade e palidez de uma e4ressão simbólica.
James Clerk Maxwell
Address lo lhe Malhematics and Physics Section
Brit Associalion for lhe Advancement ofScience 1870
1. Porque a gerência necessita de suas próprias 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 INTRODUÇÃO
Embora este não seja um livro sobre gerenciamento de projetos, devemos fazer uma pequena pausa
aqui, neste último capítulo sobre ferramentas de modelagem, para apresentar algumas ferramentas
de modelagem úteis para se gerenciar o projeto de desenvolvimento de um sistema; focalizaremos
nossa atenção principalmente nas ferramentas de modelagem conhecidas como diagramas PERT e
diagramas de Gantt.
375

Página 257 de 584
Por que você deveria se interessar por ferramentas gerenciais de modelagem? Existem diversos
possíveis motivos:
• Além 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 níveis mais
elevados da di reção ou pode solicitar a um dos seus subordinados que os desenvolva para você.
• Como o mais graduado técnico da equipe, o gerente do projeto pode solicitar-lhe que desenvolva
modelos gerenciais para ele ou ela. Nesse cenário, você pode ser o aprendiz de gerente de projeto, a
quem ele dá assistência e orientação em diversos pro blemas de natureza gerencial e técnica.
• Mesmo que você não seja responsável pelo desenvolvimento dos modelos, é importante conhecê-
los, porque eles refletem a percepção da gerência sobre como está o andamento dos trabalhos do
projeto. Você pode tirar suas próprias conclusões sobre o provável sucesso ou possível fracasso do
projeto pela comparação dos modelos com a sua própria percepção da realidade.
• A organização do trabalho e a distribuição de pessoas para as diversas atividades, muitas vezes
conhecidas como a subdivisão das tarefas do projeto, será habitualmente feita em paralelo com a
subdivisão técnica do projeto. Como você estará estreitamente envolvido com a decomposição do
sistema em suas funções e objetos de dados, você poderá ter alguma influência no modo como o
projeto será organizado 1
No restante deste capítulo 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 bém como as ferramentas de gerenciamento de projetos relacionam-se com as demais
ferramentas de modelagem de sistemas discutidas nos últimos capítulos.
16.2 POR QUE A GERÊNCIA PRECISA DE MODELOS?
Existem três principais razões para que a gerência de projetos
precise de modelos relativos a projetos de desenvolvimento de sistemas:
376
1 IL
1. Para estimar o dinheiro, tempo e pessoal necessários 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.
Orçamentos e estimativas são, naturalmente, uma importante ativi dade dos gerentes em qualquer
projeto; elas se constituem nas at.ivida des mais difíceis em muitos projetos de desenvolvimento
porque cada projeto é (ou pelo menos parece ser) inédito, O apêndice B discute algumas das
fórmulas e alguns dos métodos para se estimar o volume de trabalho a ser executado em um projeto
e a quantidade dc pessoas que será necessária. Entretanto, a gerência necessita de modelos - e os
modelos gráficos são desejáveis, pelos mesmos motivos que esses modelos são úteis em outros
aspectos da análise dc sistemas - para saber quando as pessoas estão disponíveis para desempenhar
tarefas no projeto, o que acontecerá se essas pessoas não estiverem disponíveis, e assim por diante.
Esses aspectos serão examinados detalhadamente na seção 16.5.

Página 258 de 584
Mesmo o melhor dos planos, entretanto, pode fracassar se for implementado às cegas. As
circunstâncias mudam continuamente duran te o projeto: os recursos fundamentais podem não estar
disponíveis no exato momento em que se fazem necessários; 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 usuário pode subitamente anunciar que o sistema precisa estar operacional um
mês antes da data prevista; o gerente pode descobrir que o trabalho está sendo feito com mais
lentidão que o esperado. Desse modo, é importan te para o gerente de projeto dispor dc modelos
que lhe possibilitem resolver as conseqüências das alterações do plano.
E, por fim, o gerente de projeto deve não só chefiar tarefas, mas também deve chefiar pessoas. O
gerente deve assegurar que todos os analistas de sistemas, os programadores, os projetistas de
sistemas e todos os demais façam o que devem fazer no momento certo. Assim, o gerente precisa
dc ferramentas de modelagem que se focalizem nas pessoas, além das-que se focalizam nas tarefas.
377
16.3 OS DIAGRAMAS PERT
PERT é um acrônimo para Program Evaluation Revlew Technlque. Essa técnica 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 são geralmente creditadas pelo desenvolvimento do conceito. Os diagramas PERT têm
sido amplamente usados em projetos industriais e governamentais desde então; muitos os
denominam atual mente de diagramas de atividades.
A figura 16.1 mostra um típico diagrama PERT para um projeto hipotético. Cada retângulo
representa uma tarefa ou atividade (isto é, uma parte reconhecível de um serviço que precisa ser
feito). Os quadros com cantos arredondados são conhecidos como marcos, e têm um signi ficado
óbvio no contexto de um projeto. As linhas que interligam os quadros mostram dependências; isto
é, mostram que atividades devem ser terminadas antes do início de alguma outra atividade. As
linhas mais grossas e escuras, que formam um caminho contínuo do início ao fim do projeto
representam o caminho crítico, as atividades cujo atraso causará o atraso de todo o projeto (as
atividades fora do caminho crítico têm uma «folga”; elas podem ser iniciadas em data mais tardia
que a prevista até o total das folgas disponíveis, 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 serão dependentes de outras tarefas. Em muitos casos, a dependência é relacionada aos dados:
a ati vidade N + 1 exige, como entrada, algo que seja produzido como saída pela atividade N. Em
outros casos, a dependência representa um ponto de verificação do projeto (ex.: o marco N pode ser
uma reunião de revisão da gerência 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 contém apenas dez atividades e
termina quando a atividade de análise de siste mas começa. Um projeto típico, naturalmente,

Página 259 de 584
prossegue após a conclu são da atividade de análise dc sistemas e dcspcndc um considerável
volume de tempo na área de projeto, codificação, testes etc. Na realida de um projeto típico terá
provavelmente algumas centenas de atividades que serão mostradas em um diagrama PFRT. Esse
diagrama pode ser colocado na parede do escritório do gerenle do projeto, mas certamente não
caberia nas páginas deste livro.
Um aspecto da maior importância é que a maioria dos projetos identifica as principais atividades
que são depois subdivididas em outras menores. Por exemplo, a figura 16.1 mostra uma atividade
rotulada ‘Conduzir atividades de análise de sistemas”. Como temos visto neste livro, existem
muitas e muitas coisas que se enquadram sob o título de ‘conduzir” análise de sistemas: na
verdade, poderíamos ter um grande diagrama PERT dedicado a essas subatividades. Assim, do
mesmo modo como vimos o conceito de diagramas de fluxo de dados em níveis no capítulo 9,
podemos imaginar o conceito de diagramas PERT em níveis para auxiliar a organizar a
complexidade de muitas centenas, ou talvez de milhares, de atividades de um grande projeto.
A propósito, observe que o diagrama PER’F focaliza as atividades e interdependências entre as
atividades, mas informa pouco ou nada sobre muitos outros aspectos de um projeto que são do
interesse de um ge rente. Ele não indica, por exemplo, que pessoa ou grupo de pessoas deve
executar as diversas atividades e nada nos diz explicitamente sobre o tempo (ou número de
homens-dias) que cada atividade exige. Ele também não mostra que produtos ou saídas são
fornecidos em cada atividade. Algumas dessas informações são 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 seqüência esquerda-para-a direita das atividades. Na realidade, muitas vezes é necessário
voltar e refazer algumas das atividades anteriores no caso de serem encontrados problemas em
algum estágio posterior. Esse tipo de atividade iterativa não é bem mostrada em um diagrama
PERT típico.
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 dão a entender que as atividades devem ocorrer de modo se qüencial (veja, por
exemplo, a figura 5.1). Os gerentes de projeto geral mente querem tirar o máximo proveito possível
do “paralelismo”, uma vez que ele pode abreviar o tempo necessário 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 cronológica 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
indicação de quando se inicia e de quando termina; a área sombreada indica o tempo de folga,
enquanto as atividades em retângulos brancos são as que pertencem ao caminho crítico.
Como se pode ver, o diagrama de Gantt apresenta quase que o mesmo tipo de informações que o
diagrama PERT; a principal diferença é que ele mostra a duração de cada atividade 2, o que o
diagrama PERT não faz. Como ele é algo mais do que uma representação tabular do
4/1 1/2 29/2 28/3 25/4

Página 260 de 584
Início
F4ar com re do usuário
Desénvolver aspectos iniciais do projeto [ instalações do usuário
Apresentar estudo de viabilidade
Rever 9 reguladores
lnvestig alternativas financeiras
Conduzir atividades de análise de sistemas
Apresentar resultados da análise de siste
Figura 16.2: Um dia,grama de Gana
380
projeto, pode muitas vezes ser empregado para apresentar grandes volu mes de informações de
forma relauvamente compacta.
16.5 FERRAMENTAS ADICIONAIS DE MODELAGEM GERENCIAL
Além 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, poderíamos 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 hipotético; ela, obviamente, seria útil para se manter
controle sobre as diversas atividades sobre as quais cada membro do projeto é res ponsável. De
forma semelhante, podemos decidir que seria prático termos uma lista das diversas atividades do
projeto, possivelmente com a indicação da data mais próxima cm que cada atividade pode ser
iniciada e a data mais tardia para seu início sem prejudicar outras tarefas nem atrasar o término do
projeto.
É evidente que as informações da í 16.4 são uma outra visão dos aspectos gerenciais do projeto; ela
deve ser compatível com as ou tras visões, do mesmo modo como os modelos DFD, DER e DTE
de um sistema de informações são compatíveis entre si. Tendo criado qualquer um dos modelos de
gerenciamento do projeto, devemos poder derivar os outros mecanicamente; voltaremos a este
assunto na seção 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 funções) que são executadas, e ambos também mostram algumas
coisas relativas à interação entre essas fun ções. Entretanto, o DFD não mostra absolutamente nada
a respeito da seqüência em que as funções são executadas, enquanto o diagrama PERT indica as
atividades que funcionam dc maneira concorrente e as que são executadas de modo seqüencial.

Página 261 de 584
Além disso, vimos que o dia grama PERT não mostra a saída 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 usuário
Apresentar estudo de viabilidade
Conduzir ativida4s de análise de sist mas
Vary
Inicio
I insta ações do usuário
Conduzir ativida( es de análise de sistemas
Caro 1
-i
Falar com representantes do usuano
Jos
Figura 16.3: Uma lista de recursos
Como vimos no capítulo 5, os DFD podem ser utilizados para mostrar as atividades de um projeto,
e também as entradas e saídas; 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 crítico; precisariam ainda de informações adicionais,
como a duração de cada atividade e o pessoal envolvido em cada atividade. Assim, é comum ver se
o diagrama PERT clássico usado em combinação com o diagrama de Gantt e com a linha
cronológica de recursos que discutimos antes.
Mais significativo é o fato de que as atividades que aparecem em
um diagrama PERT são as atividades de desenhar DFD, DER etc. Portan to, embora a figura 16.1
mostrasse a atividade de alto nível “conduzir
382
análise de sistemas”, um diagrama PERT mais realista provavelmente mostraria uma lista de
atividades como esta:
• Desenhar os diagramas de dados do novo sistema

Página 262 de 584
• Desenhar os diagramas de entidades-relacionamentos do novo sistema
• Desenhar os diagramas de transições de estado do novo sistema
• Elaborar o dicionário de dados do novo sistema
• Redigir as especificações dc processos para as bolhas do nível mais baixo
• Equilibrar os modelos
• Executar os cálculos de custo/benefício
• Etc.
Como veremos na parte IV, os diagramas de fluxo de dados e outras ferramentas de modelagem
semelhantes são utilizadas para ela borar uma série de modelos do novo sistema. Assim, é provável
que encontremos as seguintes atividades dc alto nível:
• Desenvolver o modelo amhicntal
• Desenvolver a primeira versão do modelo comportamental
• Refinar o modelo comportamcntal
• Desenvolver o modelo de implementação do usuário
No presente momenio, nenhum desses itens deve fazer muito sen tido para você; discutiremos o
modelo ambiental no capítulo 18, o
modelo comportamental nos capítulos 19 e 20, e o modelo de imple mentação do usuário no
capítulo 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 elaboração de modelos que vimos discutindo
neste livro. É claro que um diagrama PERT real para um projeto, abrangendo todo o ciclo de vida,
também deve mostrar as atividades de desenho (projeto), programação, testes, conversão de bancos
de dados e instalação.
383
Início Término Início Término
Tarefa Dias mais mais mais mais
cedo cedo tardio tardio
1 Início 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 usuário
3 Desenvolver aspectos 20 1/4/88 2/1/88 1/4/88 2/1/88
iniciais
4 Visitar instalações do 4 1/11/88 1/15/88 1/26/88 2/1/88
usuário
5 Apresentar estudo de O 2/1/88 2/1/88 2/1/88 2/1/88
viabilidade

Página 263 de 584
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
análise 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 AUTOMATIZAÇÃO
Três coisas devem ter ficado evidentes após a discussão sobre fer ramentas de gerenciamento de
projetos deste capítulo:
1. Algumas das ferramentas de modelagem envolvem gráficos; portanto, para fazê-las funcionar,
alguém 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 têm que ser refeitos.
Isso acarreta um enorme volume de trabalho.
3. Todos os modelos relacionam-se uns com os outros; portanto, dispondo de suficientes
informações sobre o projeto, alguém deve ser capaz de criar um diagrama PERT, ou um diagrama
de Gantt, ou uma linha cronológica dc recursos e também o adequado suporte narrativo.
384
L
Isso leva a uma conclusão óbvia: seria extremanente útil se as ferramentas gerenciais de
modelagem pudessem ser computadorizadas. E de fato têm sido; existem atualmente diversos
pacotes de gerenciamen to de projetos disponíveis 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 ingênuo em gerenciar algo além de um projeto trivial sem essas ferramentas
automatizadas. Além das atividades de modelagem simples discutidas neste capítulo, as
ferramentas computadorizadas normalmente possuem as seguintes características:
• Capacidade de especificar o cu.slo de cada recurso do projeto. Isso é de enorme auxílio em
atividades orçamentárias.
• Capacidade de estabelecer o calendário dentro do qual o projeto deve correr (ex.: feriados, horas
normais de trabalho etc.). Al guns programas permitem até que cada recurso tenha seu próprio
calendário, considerando, desta maneira, o fato de que diferentes pessoas têm diferentes escalas de
férias, e coisas desse tipo.
• Capacidade de escalonar para diante ou para trás. 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
término é conhecida (porque um limite foi externamente im posto ao projeto), e o objetivo é

Página 264 de 584
determinar a data mais tardia de início para cada uma das atividades .
• Capacidade de diversos relatórios em vários formatos.
• Capacidade de interface com vários outros programas (ex.:
planilhas eletrônicas e programas gráficos).
• Capacidade de mostrar a comparação entre o desempenho real e o estimado de modo a que o
gerente possa verificar o grau de exatidão de sua estimativa e possivelmente usá-la como meio de
revisão de estimativas futuras.
Para projetos de pequeno ou médio 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 estão 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 necessário
um computador de grande porte. Além
385
disso, muitas grandes empresas reú nem os planos de projetos individuais em modelos e
orçamentos agregados; desse modo, é importante que cada um utilize um sistema de modelagem
compatível com o PC ou que compartilhem um sistema maior baseado em um computador de
grande porte.
16.8 RESUMO
O gerenciamento de projetos, naturalmente, não se resume a dese nhar diagramas PERT. O gerente
de projeto típico contrata, despede, negocia, motiva, comunica-se e persuade programadores,
analistas de sistemas, usuários e membros dos níveis mais elevados da direção. Mas, sem as
ferramentas de modelagem dos tipos descritos neste capítulo, é quase impossível para o gerente de
projeto controlar as atividades, os custos e os recursos envolvidos.
REFERÊNCIAS
1. Philip Metzger, Mana a I’rogramming J’roject, 2* cd. Engle wood Cliffs, N.J.: Prenticc-llall,
1983.
2. Tom Gildersleeve, Sucessful Data I’mcessin,g Systems Analysis, 2* ed. Englewood Cliffs, N.J.:
3. Marvin Gore e John Stubbe, Elemenis of Systems Analysis, 3* cd. Dubuque, Iowa: William C.
Brown, 1983.
1. Apresente três motivos pelos quais os gerentes de projeto neces sitam de modelos relativos a
projetos de desenvolvimento de
sistemas.
2. O que significa o acrônimo PERT?
3. Dê uma definição sucinta do diagrama PERT.
4. O que é o caminho crítico em um diagrama PERT? Qual é a sua importância?
5. Que informações relativas a um projeto o diagrama PERT não apresenta?

Página 265 de 584
6. Dê uma definição sucinta dc um diagrama dc Gantt. Apresente um sinônimo para esse diagrama.
7. Que informações o diagrama dc Gantt apresenta que o diagrama PERT não mostra?
8. Dê uma definição 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
elaboração 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 relação à estrutura da organização que o
constrói”.
2 Não indicamos exatamente como o gerente de projeto determina
a duração 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 façam essa avaliação. Se a tarefa for gran
de ou complexa, ela geralmente é subdividida em atividades
menores (subatividades). As fórmulas para se estimar o tempo e os
recursos de programação e coisas semelhantes são apresentadas no
apêndice B.
3 Na maioria dos projetos, o recurso que temos maior interesse em
gerenciar é o pessoal; mas há outros recursos, como uma máquina,
uma sala de conferências ou qualquer outra coisa que seja (1)
necessária 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 opções de pacotes de gerência de projetos para
o IBM PC.
5 Tom DeMarco gosta de referir-se a isso como “pensamento positivo
às avessas”.
387
1h

Página 266 de 584
17
O MODELO ESSENCIAL
Examine a essência das coi.sas, quer seiam aspectos de doutrina, de
prática ou de inleipretação.
Marco Aurélio, Meditações VIII
1. Os quatro principais modelos do ciclo de vida.
2. Porque é arriscado modelar o sistema atual do usuário.
3. A distinção entre o modclo essencial e o modelo de implementação.
4. Como “logicalizar” um modelo de implementação.
Na seção anterior (capítulos 9 ao 16), examinamos algumas ferra mentas dc modelagem que todos
os analistas de sistemas devem ter à sua disposição. Entretanto, dc posse dessas ferramentas, que
tipo de modelos devemos elaborar? Um modelo da atual implementação de um sistema do usuário?
Um modelo da nova implementação proposta? Ou um que seja independente da tecnologia de
implementação? Ou todos esses três? Essas perguntas serão tratadas nos próximos capítulos.
Começaremos por examinar a clássica abordagem de análise de sistemas para desenvolver modelos
dc sistemas; como veremos, existem sérios problemas com essa abordagem. Discutiremos, em
seguida, o modelo essencial, que é o principal modelo da análise de sistemas que recomendamos
construir. Por fim, discutiremos algumas diretrizes para a
391
construção de um modelo essencial a partir dc um modelo de implemen tação existente.
17.1 A ABORDAGEM CLÁSSICA DE MODELAGEM E
PORQUE ELA NÃO FUNCIONAVA
17.1.1 Os Quatro Modelos de Sistemas
Quando a análise estruturada foi apresentada pela primeira vez, era
comumente dito que o analista de sistemas devia desenvolver quatro
modelos distintos. Eles são mostrados na figura 17.1
O modeloflsico atualé um modelo do sistema que o usuário pre sentemente utiliza. Ele pode ser um
sistema manual, um sistema automa tizado ou uma combinação 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 saídas. Um exemplo disso é mostrado na figura 17.2. Observe também
que os fluxos de dados geralmente mostram formas físicas de dados sendo transportados de bolha
em bolha; além disso, os depósitos de dados podem ser representados por pastas de arquivos,
arquivos em fitas magnéticas ou alguma outra tecnologia.
O novo modelo lógico é um modelo dos requisitos puros ou essen ciais do novo sistema que o
usuário deseja. No caso ideal (do ponto de vista do analista de sistemas), ele é igual ao modelo
lógico atual, isto é, contém as mesmas funções e os mesmos dados. Essa situação pode ocorrer se o

Página 267 de 584
usuário estiver plenamente satisfeito com a funcionalidade do sistema atual, mas não com a
implementação Na maioria dos casos, entretanto, o usuário solicita novas funções: “Aproveite, e
inclua uma nova transação para cuidar da seguinte situação...”. Ou o usuário pode solicitar que o
sistema controle uma nova forma de dados. Desse modo, embora 80 a 90% dos novos modelos
lógicos possam ser idênticos ao modelo lógico atual, é provável que haja pelo menos algumas
pequenas modificações e acréscimos.
O modelo lógico atualé um modelo dos requisitos puros ou essen ciais executados pelo sistema
atual do usuário. Assim, são suprimidos os detalhes arbitrários dé implementação e o modelo
resultante mostra o que o sistema faria se uma perfeita tecnologia estivesse disponível 2 A figura
17.3 mostra um exemplo de um modelo lógico atual.
O novo modelo fisico mostra as restrições de implementação im postas pelo usuário. Uma das
restrições mais importantes é a determina ção das fronteiras da automatização (isto é, a
determinação de que funções no novo sistema serão automatizadas e quais serão executadas
392
modelo lógico atual
novo modelo lógico
novo modelo físico Figura 17.1: Os quatro modelos de sistema
393
contrato do projeto
atual
pedidos
acarbonodo formulário 2107
CAIXA DE ENTRADA
formulário 2107
ARQUIVO DE PEDIDOS
COMPUTADOR DE PROCES SAMENTO
blocos de DE PEDIDOS
tamanho fixo
manifesto de em ba rq u e
FUNCIONÁRIO
DO
EMBARQUE
lista de emba
pedidos
Figura 17.2: Um modelo físico atual
pedido inválido

Página 268 de 584
relatório de pedid
fatura
Figura 17.3: O modelo lógico atual
394
manualmente). O novo modelo físico corresponde ao que agora deno minamos de modelo de
implementação do usuário, que discutiremos mais detalhadamente no capítulo 21.
17.1.2 Porque a Aborda8em Clássica Não Funcionava
A abordagem clássica, que acabamos dc descrever, baseava-se em
três importantes suposições:
1. O analista de sistemas pode não conhecer a aplicação ou o ra mo comercial: ele pode ser um
perito em tecnologia de processamento de dados, mas conhecer apenas superficialmente as
atividades bancárias, dc seguros, de controle de inventários de material ou de qualquer outra área
em que o usuário trabalhe. Por causa disso, é importante que o analista de sistemas comece por um
modelo físico atual como meio de se auto-instruir. O modelo desenhado será fácil de verificar, por
que conterá diversos marcos físicos que podem ser observa dos no ambiente físico atual. Após ter
obtido o conhecimento necessário, o analista de sistemas pode prosseguir, transfor mando o modelo
físico cm modelo lógico.
2. O usuário talvez não queira ou não possa trabalhar com o novo modelo lógico no início do
projeto. O motivo mais comum para isso é a desconfiança na capacidade do analista de sistemas
em desenvolver o modelo lógico do novo sistema. Mesmo que o analista de sistemas julgue ser
perito na área da empresa do usuário, este pode não 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?” Além disso, alguns usuários consideram difícil examinar um modelo
abstrato do sistema sem marcos re conhecíveis; eles podem precisar dc um modelo do sistema
físico atual como meio de se familiarizarem com o processo de análise estruturada e de se
certificarem de que o analista não deixou de lado alguma coisa (uma alternativa é a abordagem de
protoupação discutida no capítulo 5).
3. A transformação do modelo lógico atual em um novo modelo lógico não exige muito trabalho e,
cm particular não exige muito desperdfcio de trabalho. Como já dissemos, o usuário normalmente
acrescentará algumas novas funções, ou novos dados, ao sistema á existente, mas a maior parte do
sistema lógico existente (ou talvez todo ele) permanecerá intacta.
395
Essas suposições 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
esforço que o usuário poderá se tornar fn e impaciente, chegando ao ponto de cancelar o projeto.
Para entender este problema, lembre-se do seguinte:
• Alguns usuários (e alguns gerentes e programadores-analistas) vêm qualquer forma de análise de
sistemas como uma perda de tempo - um modo de “descansar” antes que o trabalho ver dadeiro
(isto é, a codificação) se inicie.
• Muitos usuários têm compreensíveis dúvidas sobre os méritos da cuidadosa modelagem de um

Página 269 de 584
sistema que, por definição, será superado e substituído como resultado do desenvolvimento do
novo sistema.
O problema ocorre com mais freqüência 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
especificações de processos, o analista de sistemas muitas vezes desenha todos os diagramas de
fluxos de dados, documenta todas as especificações de processos e desenvolve um dicionário de
dados completa
Infelizmente, essa abordagem quase sempre envolve um grande desperdício de tempo. Pode-se, de
fato, esperar que cerca de 75% do modelo físico sejam jogados fora na transição do modelo físico
para o modelo lógico atual; ou, em outras palavras, o modelo físico atual é tipicamente três ou
quatro vezes maior que o modelo lógico atual. Isso se deve à redundância (a mesma função é
executada cm várias partes do sistema atual e diversos elementos dc dados são duplicados ou
triplica dos) e à verificação, validação e correção de erros, que são adequadas no sistema físico
atual mas não no sistema lógico atual .
Isso tudo pode parecer um tanto óbvio para o leitor ocasional. Entretanto, projeto após projeto, os
analistas dc sistemas têm-se visto tão envolvidos no processo de modelagem que esqueceram o
objetivo final do usuário: um sistema que funcione. Como disse Steve McMenamin (co-autor de
lMcMenamin e Palmer, 198’ll), “As bolhas não são compiláveis” .
Em conseqüência, este livro recomenda que o analista de sistemas evite, tanto quanto possível,
modelar o sistema atual do usuário. As ferramentas de modelagem discutidas na parte II devem ser
utilizadas para, assim que for possível, desenvolver um modelo do novo sistema
396
desejado pelo usuário. Esse novo sistema, mencionado na literatura sobre a análise estruturada
clássica como o novo sistema lógico, é aqui tratado como o modelo essencial do sistema.
Ocasionalmente pode haver uma situação em que o analista de sistemas deva construir o modelo do
sistema atual do usuário; isso ocor re, por exemplo, quando o analista de sistemas precisa modelar
o siste ma físico atual para descobrir quais são, de fato, os processos essenciais. Esta situação é
abordada com mais detalhes na seção 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
usuário, mencionando o mínimo possível (de preferência nada) sobre como o sistema será
implementado. Como á foi dito, isso significa que o nosso modelo de sistema pressupõe que
dispomos de perfeita tecnologia e que pode ser obtido a custo zero.
De uma forma específica, isso significa que quando o analista de sistemas conversar com o usuário
sobre os requisitos do sistema, deve evitar descrever as implementações específicas dos processos
(bolhas do diagrama de fluxo de dados) do sistema; isto é, ele ou ela não deve mostrar as funções
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 são opções arbitrárias de como o sistema poderia ser imple
mentado; mas é uma decisão que deve ser protelada até que se inicie a atividade de projeto do

Página 270 de 584
sistema . A figura 17.4(c) mostra um modelo essencial mais adequado do que a função do sistema
deve executar independentemente de sua implementação.
Isso também vale para fluxo de dados e depósitos de dados: o modelo essencial deve descrever o
conteúdo dos fluxos e dos depósitos de dados, sem considerar o meio (isto é, disco ou fita) ou a
organização física dos dados.
17.2.2 Dificuldades na Construção do Modelo Essencial
Apesar de as diretrizes acima poderem parecer simples e óbvias, muitas vezes torna-se bastante
difícil eliminar completa mente do mode lo essencial todos os detalhes da implementação. Os
exemplos mais comuns de detalhes de implementação são os seguintes:
397
• Seqüência arbitrária de atividades em um modelo de fluxo de dados. A única seqüência 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, não pode iniciar seu trabalho até que a bolha
1 tenha terminado o dela) ou pelos eventos externos ao sistema.
• Arquivos desnecessários, depósitos de dados que não seriam necessários se estivesse disponível a
tecnologia perfeita. Os ar quivos temporários (ou intermediários) fazem-se necessários em um
modelo de implementação porque os processos são 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 também são intro duzidos nos modelos de implementação para fins
de backup e recuperação, uma vez que a tecnologia da implementação é propensa a erros, assim
como as pessoas que operam os computadores.
• Desnecessárias verifica ções de erros e validação de erros e processos dentro do sistema. As
atividades de validação são necessárias em um modelo de implementação por ser necessá rio
trabalhar com processos tendentes a erros (ex.: algumas funções são executadas por seres humanos
que são notoria mente sujeitos a erros) e por ruidosos caminhos de dados entre esses processos.
• Dados redundantes ou derivados. Por vezes são incluídos ele- - mentos de dados redundantes em
depósitos de dados em prol da eficiência; embora isso normalmente seja razoável, deve ser feito
durante a fase de projeto e não durante a modelagem das
folhas de tempo
ARQUIVO DE EMPREGADOS
Figura 17.4 (a): Um modelo de como uma função do sistema executa sua tarefa
398
cartóes de tempo
Figura 17.4 (b): Outro modelo de como a/unção será executada
horas trabalhadas
EMPREGADOS
Figura 17.4 (c): Um modelo do que a/unção é
funções e dados essenciais. Além disso, o analista de sistemas pode inadvertidamente incluir

Página 271 de 584
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 capítulo 19; como veremos, ele compõe-se de um dia grama de contexto, uma
lista de evcntos e uma pequena descrição do propósito do sistema.
O modelo comportamcntal descreve o comportamento, do interior do sistema, necessário para
intcragir com sucesso com o ambiente. Os capítulos 20 e 21 descrevem uma estratégia para se
derivar o modelo comportamental; o modelo compõe-se dos conhecidos diagramas de fluxo de
dados, diagramas de entidades-relacionamentos, diagramas de transições de estado, itens do
dicionário de dados e especificações de processos que já estudamos anteriormente neste livro.
17.3 O QUE FAZER SE VOCÊ TIVER QUE ELABORAR UM MODELO DE
IMPLEMENTAÇÃO
Como já foi dito neste capítulo, existem circunstâncias em que você pode achar necessário ou
desejável elaborar um modelo de implementa ção antes dc construir o modelo essencial do sistema.
Isso geralmente ocorre porque o usuário não 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 visão geral do sistema existente. Não é seu objetivo
documentar o siste ma atual em suas minúcias. Dessa forma, será provavelmente útil e ade quado
criar um ou mais níveis de diagramas de fluxo dc dados para o sistema atual; será também
provavelmente adequado elaborar um dia grama de entidades-relacionamentos. Também poderia
ser útil escrever especificações de processos para algumas das mais críticas (ou obscuras) funções
do sistema; podena ser útil reunir alguns dos documentos físicos que representariam um dicionário
de dados físico. Mas você não deve tentar escrever especificações de processos para todas as
funções nem desenvolver um completo dicionário de dados para o sistema existente.
Quando tiver terminado dc desenvolver o modelo da implemen tação atual, sua próxima tarefa é
torná-la lógica (isto é, suprimir tantos detalhes orientados para a implementação quantos forem
possíveis). 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 são transmitidos jun tos a
partir de um computador para outro através de um elo de telecomunicação comum; ou que alguns
elementos de dados
400

Página 272 de 584
não relacionados são copiados em um formulário de papel a ser transmitido para diversas funções.
Procure fluxos a,gregados ou empacotados que sejam remetidos para bolhas (representando
pessoas, computadores etc.) que não 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 conveniência, a implementação atual empacotou X e Y em um elemento de dado
agregado Z; a “logi calização” deste modelo resulta no diagrama de fluxo de dados mostrado na
figura 17.5(b).
Faça a distinção entre o trabalho essencial feito por um processo e a idenl do processador mostrado
no modelo de implementação. 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 múltiplos processos
fator
framm is
401
x
fator widget
Figura 17.5 (a): (Jm modelo fi
r
fator widget
essenciais. Como veremos no capítulo 20, os processos essen ciais devem ser agrupados se forem
provocados pelo mesmo evenio externo.
• Elimine os processos cujo único propósito seja o de Ira nsporlar dados de um ponto a outro do
siçtema. Elimine também as bo lhas responsáveis pelas entradas e saídas físicas entre o sistema e o
ambiente externo. O modelo físico de um sistema pode mostrar, por exemplo, uma função dc
correio ou de entrega de mensagens; ela deve ser eliminada do modelo essencial. Mui tos DFD
físicos têm processos com nomes como “obter entra da do usuário” ou “imprimir relatório” que
também 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 verificaçõcs cruzadas não são necessários. É, con tudo, aconselhável, introduzir
veriflcaçõcs 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 versão com lóRica
402

Página 273 de 584
vistos com suspeita, a menos que estejam nas fronteiras do sis tema e lidem com entradas externas.
• Venfique a presença de situações em que depósitos essenciais tenham sido a no mesmo depósito
de implementação (ex.: arquivos cm disco, arquivos em fita OU cm papel); isso é muito comum
cm sistemas de segunda geração e em sistemas que tenham sido otimizados durante um período dc
alguns anos para manipular grandes volumes dc dados com eficiência. Sepa re o conteúdo do
depósito do meio dc armazenamento.
• Remova dos depósitos quaisquer elementos de dados se não forem utilizados por qualquer
processo; além disso, remova também dos depósitos os elementos de dados que possam ser
calculados ou derivados diretamente de outros elementos de dados (observe que elementos dc
dados derivados e cópias redundantes dc elementos dc dados podem ser reinseridos mais tarde,
quando o modelo Je implementação for desenvolvido durante a fase de projeto de sistemas).
• Para finalizar, supnma todos os depósitos de dados que existam entre processos apena.s como
retardos dependentes da imple mentação. Isso inclui arquivos intermediários, arquivos dc re
latórios, arquivos spool e outros congêneres.
17.4 RESUMO
O conceito de modelo essencial aparenta ser algo muito natural, mas ele não é tão fácil dc ser
pcparado cm projetos do mundo real como se pode pensar. A maioria dos usuários está tão
envolvida nos detalhes da implementação dc seu sistema atual que para eles é difícil entender a
visão de “tecnologia perfeita” dc um sistema. E isso também é difícil para muitos analistas dc
sistemas veteranos, porque passaram tantos anos construindo sistemas que para eles se torna difícil
evitar fazer suposições de implementação ao descreverem um sistema.
Lembre-se que é de suma importância desenvolver o modelo es sencial de um sistema, porque
(como já foi dito diversas vezes neste livro) a maioria dos grandes sistemas de informações tem um
ciclo de vida de 10 a 20 anos. Durante esse período de tempo podemos contar com o
aperfeiçoamento da tecnologia de hardware de computadores por um fator de mil, no mínimo, e
provavelmente próximo de um fator de um milhão ou mais. Um computador que seja um milhão de
vezes mais rápido, menor e mais barato que um computador atual está, de fato,
i03
próximo da perfeita tecnologia; é preciso começarmos hoje a ri nossos sistemas como se já
dispuséssemos dessa tecnologia.
REFERÊNCIAS
1. Tom deMarco, Structured A nalysis and Systems Speqflcatlon. Nova
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:
4. Victor Weinberg, Stnsctured Analysis, Nova lorque: YOURDON
Press, 1978.

Página 274 de 584
5. Steve McMenamin e John Palmcr, Essential Systems Analysis, Nova
1. Quais são os quatro modelos recomendados pelos livros clássicos
sobre análise de sistemas?
2. O que é o modelo físico atual?
3. Dê três exemplos de processos físicos (Ix)lhas).
4. Dê três exemplos de depósitos flsicos.
5. Dê três exemplos de fluxos de dados físicos.
6. O que é um o modelo lógico atual?
7. Qual é a diferença entre o modelo físico atual e o modelo lógico
atual?
8. O que é tecnologia perfeita no contexto deste capítulo?
9. O que é o novo modelo lógico?
10. Qual é a diferença entre o modelo lógico atual e o novo modelo
lógico?
11. Sob quais circunstâncias podem ser iguais o modelo lógico atual e
o novo modelo lógico de um sistema?
12. Que grau de sobreposição deve o analista de sistemas esperar que
ocorra entre o modelo lógico atual e o novo modelo lógico de um
sistema?
13. O que é o novo modelo físico?
14. Apresente um outro nome para o novo modelo físico.
15. Qual é a principal restrição descrita pelo novo modelo físico?
16. Quais são as três principais suposições em que se apóia a abor
dagem clássica da análise estruturada?
/404
17. Projeto de Pesquisa: Em sua organização, qual é o percentual de projetos que têm analistas de
sistemas que não estão intimamente familiarizados com o ramo dc negócios do usuário? Em sua
opinião, esse percentual é aceilável? Ele está se modificando?
18. Quais são os dois maiores motivos para que o usuário encontre dificuldades em ler e
compreender um modelo lógico?
19. Qual é o principal problema com a abordagem clássica da análise estruturada?
20. Por que alguns usuários têm dúvidas sobre os méritos de se modelar seu sistema atual?
21. Que fração do modelo físico atual será provavelmente desprezada na transição para o modelo

Página 275 de 584
lógico atual?
22. Quais são os motivos para que o modelo f atual seja tão maior que o modelo lógico atual dc um
sistema?
23. Apresente um sinônimo para o novo modelo lógico.
24. Que tipo de verificação de erros é adequada em um modelo lógico? Que tipo não é? Por quê?
25. Dê uma definição do modelo essencial de um sistema.
26. O que significa protelação construtiva no contexto deste livro?
27. Quando, no projeto de desenvolvimento de sistemas, deve-se decidir se a implementação de
uma função (isto é, um processo do
DFD) será feita com uma pe.ssoa ou com um computador?
28. Quais são os quatro erros ou enganos comuns normalmente cometidos ao tentarem criar um
modelo essencial?
29. Por que os arquivos temporários não devem aparecer em um modelo essencial?
30. Quando os arquivos temporários 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 são 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 implementação atual de um sistema, o que você deve ter o
cuidado de evitar?
37. É uma boa medida documentar todos os fluxos de dados da implementação atual de um
sistema? Por quê?
38. É uma boa medida documentar todas as especificações de processos da implementação atual de
um sistema? Por quê?
39. É uma boa medida documentar todos os elementos do dicionário de dados da implementação
atual dc um sistema? Por quê?
405
40. Quando se introduz lógica (logicaliza”) o modelo físico atual, o
que se deve fazer com os fluxos essenciais que tenham sido
empacotados no mesmo meio?
41. Quando se “logicaliza” o modelo físico atual, o que se deve fazer
com fluxos empacotados enviados para processos que não necessi
tam de todos os dados?

Página 276 de 584
com os processos cujo único propósito seja transportar dados de
um lugar para outro?
com as bolhas cujo único propósito seja o de verificar dados que
são criados dentro do sistema?
com os depósitos essenciais que tenham sido empacotados no
mesmo meio?
com os elementos de dados que existem nos depósitos mas que
não são utilizados em lugar algum do sistema?
com os arquivos temporários encontrados no sistema físico atual?
NOTAS
1 Existem muitos possíveis motivos para isso, O sistema pode estar
implcmentado em hardware já obsoleto ou cujo fabricante já esteja
fora do mercado. Pode acontecer também o sistema ter mau de
sempenho ou tempo de resposta inadequado. O usuário pode
solicitar que alguns dados de manutenção manual (ex.: arquivos
em papel) sejam computadorizados. Ou, o que ocorre cada vez
mais nos dias dc hoje, o software pode estar tão mal documentado
que já não pode mais ser mantido ou modificado.
2 Perfeita tecnologia pode ser interpretada como hardware que nada
custa, que não ocupa espaço, que não consome energia nem gera
calor, que funciona cm velocidade infinita (isto é, que execute
qualquer operação 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 lógico
(essencial) ou físico (de implementação), costuma ser apropriado
executar algumas verificações de erros de dados que entram no
sistema a partir do mundo exterior. Entretanto, como os dados são
transmitidos de ponto para ponto dentro do sistema, o modelo

Página 277 de 584
406
lógico (essencial) não faz verificaçõcs de erros por presumir que o sistema será implementado com
tecnologia perfeita. No modelo físico (de implementação), pnncipalmente em um modelo do
sistema físico atual, a verificação 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 comunicação empregado e (3) o
armazenamento e a recuperação de dados de depósitos físicos de dados pode ser uma atividade
também propensa a erros.
4 Eventualmente as bolhas podem ser compiladas. Isto é, a combi nação de diagramas dc fluxos dc
dados, de dicionários de dados e de rigorosas especificações dc processos podem ser a entrada de
um gerador de código que produz programas executáveis. Entre tanto, mesmo nesse caso, o esforço
para produzir um modelo flsico completo e detalhado é um desperdício dc tempo. Ninguém quer
uma réplica computadorizada do sistema atual.
5 Existe um nome popular para iSSO: “protelação construtiva”. Meu colega Steve Weiss prefere
“protelação de segurança” que é menos pejorativo, e que é, na verdade, o princípio em que se
baseia a abordagem top-down.
407
18
O MODELO AMBIENTAL
A estabilidade do meio inwrno é a condição básica para a liberdade e
independência de certos Corpos viventes era relação ao ambiente que os
cerca.
Claude Bernard, Leçons sur les Phenomênes de la
Vie Communs au.x Animaux ei aux Vegetaux, 1875-1879
1. Porque as fronteiras do sistema são arbitrárias porém 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 difícil na especificação de um sistema é, muitas vezes, a
determinação dc) que faz parte dc) sistema e o que não faz. Qualquer sistema que você desenvolva,
não importando quão ambicioso ou grandioso, fará parte de um sistema ainda maior. Como foi
visto no capítulo 2, virtualmente todos os sistemas com os quais temos experiência humana são,
meramente, subsistemas dc siste mas ainda maiores: mesmo se nossa tarefa fosse “projetar o
mundo”, teríamos que reconhecer que o mundo é somente uma parte do sistema solar, que é parte
de uma galáxia 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

Página 278 de 584
é um que não faça nada mais do qu definir as interfaces entre o sistema e o resto do universo, isto
é, o am bíente. Por razões ó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 capítulos 20 e 21.
Além de determinar o que está dentro do sistema e o que está fora (o que se consegue pela
definição da fronteira entre o sistema e o am biente), também é fundamentalmente importante
definir as interfac entre o sistema e o ambiente. Precisamos conhecer que informações pe netram
no sistema provenientes do ambiente externo, e devemos conhecer que informações que o sistema
produz como saídas para serem transmitidas ao ambiente externo.
Naturalmente, entradas e saidas não São produzidas ao acaso:
nenhum sistema de informações engloba todos os dados disponíveis do universo, nem qualquer
sistema real emite saídas alcatoriamcnte para consumo do ambiente externo. Os sistemas que
construímos são racionais e objetivos; especificamente, eles produzem saídas como resposta a um
evento, ou a um estímulo, do ambiente. Desse modo, um outro aspecto básico do modelo ambiental
é a identificação 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, é
arbitrária. Ela pode ser estabelecida por deter minação da direção, ou como resultado de uma
negociação política, ou, simplesmente, por acidente. E é algo cm que o analista de sistemas,
habitualmente, tem alguma oportunidade de influenciar.
Em geral, o usuário tem uma boa idéia dos limites gerais entre o sistema e o ambiente. Mas, como
ilustrado na figura 18.2, existe muitas vezes uma “área cinzenta” aberta para negociações, uma área
em que o usuário (1) não está muito seguro, (2) ainda não pensou, (3) tem algu mas idéias
preconcebidas que precisam ser repensadas, ou (‘i) tudo isso em conjunto.
Assim, para exemplificar, o usuário 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 inventário,
controle de caixa, faturamcnto, e controle de pedidos como uma abrangência 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 usuário pode ter sabiamente identificado o sintoma do problema
(p.ex., “nossas contas a receber estão fora de controle”) em vez da causa do problema. E, se o
analista de sistemas, por excesso de confiança, ingenuidade ou exuberância escolher um escopo

Página 279 de 584
grande demais para o projeto, ele estará predestinado a falhar, porque estará lidando com uma
situação política muito mais complexa, e estará tentando desenvolver um sistema que será
provavelmente grande demais para ser desenvolvido sob quaisquer circunstâncias. E ele podcrá
estar lidando com problemas com que o usuário não se importa ou que não podem ser modificados
de forma alguma. Desse modo, é importante gastar o tempo que foi necessário e obter suficiente
participação do usuário 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 estão:
412
\
• O desejo do usuário em obter uma certa fatia do mercad’T para o produto ou para aumentá-la
além do seu nível 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 tomático e sistemas bancários domésticos on-line). Ou o usuário poderia tentar aumentar a
participação no mercado pela oferta de um serviço melhor e mais rápido (p.ex., “Todos os nossos
pedidos são remetidos em 2’i horas, e temos um sofisticado sis tema que localiza o seu pedido,
possibilitando-nos saber onde ele está a qualquer momento”).
• A legislação decretada pelo governo municipal, estadual, oufe deral. A maioria desses sistemas é
de sistemas de relatórios, 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 construído para acomodar alterações nas leis de impostos.
• Um desejo do usuário 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 estão instalando hoje seu primeiro computador. Porém a maioria das
organizações que têm compu tadores instalados há 10 anos ou mais já se beneficiou das evi dentes
oportunidades de reduzir o excesso de funcionários.
• Um desejo do usuário em obter alguma vantagem estratégica para a linha de produtos ou área de
negócios que ele está ope rando. O usuário poderia tentar fazer isso organizando e geren ciando
informações sobre o mercado para que ele possa pro duzir mercadorias dc urna forma mais
oportuna e econômica. Um bom exemplo disso são as linhas aéreas (bem como muitas outras
indústrias que tiveram, recentemente, suas restrições abolidas) onde melhores informações sobre
tendências de mer cado e preferências dos clientes podem conduzir a escalo namentos e preços
mais eficientes.
A área dentro das fronteiras do sistema é algumas vezes chamada de domínio da mod Com isso
queremos simplesmente dizer que tudo que estiver no interior das fronteiras do sistema está sujeito
a modificações (p.ex., reorganização e/ou automatização), enquanto tudo que estiver fora dos
limites deverá permanecer na sua forma atual, não sendo examinado pelo analista de sistemas.
413
Para ver dois exemplos dc limites dc sistemas, examine os estudos de casos nos apêndices F e G.

Página 280 de 584
No caso do YOURIX)N Press Information System (apêndice F), o limite do sistema é um tanto
maior do que se poderia esperar: ele inclui o faturamento e a manipulação 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 apêndice G tem uma fronteira um
tanto menor do que o desejado: um sistema bem diferente poderia ter sido desenvolvido se os
painéis de controle do elevador tivessem sido consi derados parte do sistema em vez de parte do
ambiente. Em ambos os casos, as escolhas foram arbitrárias.
18.1 FERRAMENTAS UTILIZADAS NA DEFIMÇÃO DO AMBIENTE
A modelagem ambiental consiste em três componentes:
1. Declaração dc objetivos
2. Diagrama de contexto
3. Lista de eventos
Cada um desses componente será discutido a seguir.
18.1.1 A Declaração de Objetivos
O primeiro componente do modelo ambiental é uma declaração textual concisa e breve dos
objc’livos dc) sistema. Ela é voltada para a direção superior, direção usuária e Outros que não estão
diretamente envolvidos no desenvolvimento do sistema.
Um exemplo de uma declaração típica de objetivos é:
O propósito do Afaz Book Processing Sysiem é manipular todos os detalhes dos pedidos de lic’ros,
bem como remessas, faturamento e cobranças a clientes com faturas em atraso. Informações
sobrepe didos de livros devem estar disponíveis para outros sistemas, tal como rnarketing, vendas e
contabilidade.
A declaração de objetivos pode ter comprimento de uma, duas ou diversas sentenças. Entretanto,
poderia ter apenas um único parágrafo,. pois ela não se destina a dar uma descrição detalhada e
abrangente do sistema. Tal esforço seria inútil: é tarefa do restante do modelo ambiental e do
modelo comportamcntal preencher Lodos os detalhes.
414
Como resultado, a declaração de objetivos será deliberadamente vaga em relação a muitos detalhes.
No exemplo da Ajax, poderíamos
perguntar:
• Exatamente que esp de informação é 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 crédito? Isto é
determinado pelo próprio sistema ou por intermédio de recomendações do departamento de
contabilidade?
• Como o sistema toma conhecimento que novos livros foram pu blicados e já estão disponíveis
para venda?
Essas perguntas detalhadas somente podem ser respondidas com o exa me do modelo

Página 281 de 584
comportamental, que discutiremos nos capítulos 19 e 20.
Embora as perguntas detalhadas de comportamento não sejam res pondidas pela declaração de
objetivos, é geralmente suficiente respon der a uma série de perguntas de alto nível:
• O sistema de pedidos de livros é responsável pelas atividades de folha de pagamento? Não,
virtualmente qualquer um que leia o material acima concordaria que a folha de pagamento está fora
do escopo do sistema e está provavelmente incluída no sistema de contabilidade.
• O sistema de pedidos de livros é responsável pelo envio de fatu ras aos clientes que encomendam
livros? Sim, a declaração 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 declaração de objetivos.
• O sistema de pedidos de livros é responsável pelo controle de inventário, isto é, pela
determinação de quando se deve enco mendar livros que estão esgotados? Não, a declaração de
objeti vos não faz tal declaração. É altamente concebível que o con trole de inventário seja um dos
muitos outros sistemas (ou de partamentos) que farão uso das informações sobre pedidos de livros,
produzidas pelo sistema de pedidos de livros.
Muitos analistas de sistemas também consideram que a declaração
de objetivos deve relacionar os benefícios tangíveis e quantificáveis que
415
serão obtidos pelo novo sistema; por exemplo, «o propósito do sistema é reduzir o tempo
necessário para processar um pedido de três para um dia”. Embora isto possa ser muito útil em
pequenos projetos for temente direcionados, não é fácil de ser conseguido em grandes pro jetos.
Em seu lugar, costuma ser exigida uma análise 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 começa por responder algumas das perguntas levantadas
pela declaração 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 estão apresentados nos apêndices F e G.
O diagrama de contexto realça diversas características importantes do sistema:
• As pessoas, organizações ou sistemas com os quais nosso sis tema comunica-se. Esses elementos
são conhecidos como
ter,nínadores.
• 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 depósitos de dados que são compartilhados por nosso sistema e os terminadores. Esses

Página 282 de 584
depósitos de dados ou são criados na parte externa do sistema e usados por nosso siste ma ou são
criados por nosso sistema e usados externamente ao sistema.
• Os limites entre o nosso sistema e o resto do mundo.
As técnicas para construção do diagrama de contexto são discuti das na seção 18.2.
18.1.3 A Lista de Eventos
A lista de eventos é uma lista narrativa dos “estímulos” 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. Direção solicita relatório de vendas. (T)
4. Pedido de reimpressão de livro chega ao depósito. (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 ocorrência 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, não existe necessariamente uma correspondâncía 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 indicação que o evento ocor reu) oué exigido pelo sistema
com a finalidade de processar um evento.
Figura 18.6: Um diagrama de contexto parcial
Além dos eventos fluxo-orientados, um sistema pode ter também eventos temporais. Como o nome
diz, eventos tcmporais S disparados em um determinado momento. Desse modo, exemplos de
eventos tem porais podem Ser:
• Um relatório diário de todos os pedidos de livros é solicitado às 9:00 horas.
• As faturas devem ser geradas às 15:00 horas.

Página 283 de 584
• Os relatórios para a direção devem ser gerados uma vez a cada hora.
Observe que os eventos temporais não são disparados por fluxos de dados de entrada; pode-se
imaginar que o sistema tem um relógio 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 não representem o próprio evento.
418
Os eventos de controle podem ser considerados casos especiais de wenlos telnporais: um estímulo
externo que ocorra em algum momento mprevisível. Ao contrário dc um evento temporal normal, o
evento de :ontrole não se relaciona com a passagem regular do tempo, assim o ;istema não o pode
prever pelo uso do relógio interno. E ao contrário de im evento fluxo-orientado normal, o evento dc
controle não marca sua resença 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 ação imediata. Os sistemas de informações orientados ara empresas não costu ter
fluxos dc controle nos diagramas le contexto; o YOURDON Press Information System descrito no
tpêndice F, por exemplo, não os apresenta. Porém, 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 apêndice 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 definição de objetivos são
suficientes. Entretanto, dois componentes dicionais podem ser úteis, dependendo da natureza e da
complexidade lo sistema:
• Dicionário de dados inicial, definindo fluxos e depósitos externos.
• Modelo de entidades-relacionamentos dos depósitos externos.
419
Mesmo um sistema dc médio 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
capítulo 20), pode ser útil iniciar agora a preparação de um dicionário de dados. Isso pode ser
importante se as interfaces entre o sistema e os diversos terminadores estiverem sujeitas a
mudanças e negociações; quanto mais cedo começar-se a definir formalmcnte essas interfaces (de
finindo a composição e o significado dos depósitos), mais cedo elas poderão ser finalizadas.
De forma análoga, um diagrama dc entidades-relacionamentos pode ser construído a partir dos
depósitos externos (se houver algum). Isso pode ajudar a expor os relacionamentos entre os

Página 284 de 584
depósitos que, dc outra maneira, não se tornariam evidentes até que o modelo comportamental
estivesse sendo desenvolvido. Pela concentração nesses relacio namentos, nesse primeiro estágio,
teremos um meio dc duplicar a verifi cação das interações entre os terminadorcs (que costuma
incluir os usuá rios finais do sistema) e o próprio sistema.
18.2 A CONSTRUÇÃO DO MODELO AMBIENTAL
A discussão acima provavelmente faz com que o modelo ambien tal pareça ser um tanto simples e
direto: afinal dc contas, existe somente um processo, alguns fluxos de dados e tcrminadorcs, uma
pequena des crição narrativa do objetivo do sistema, e uma lista de eventos. Embora isso seja
verdadeiro, muitas vezes o modelo ambíental exige muito trabalho; além disso, ele é habitualmente
desenvolvido com uma série de refinamentos iterativos, com detalhes adicionais sendo
introduzidos e refinados.
Urna importante razão pela qual tantos refinamentos e revisões costumam ser necessários é que
ninguém 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á viável falar
sobre ele com os usuários que estão presentemente executando as funções do sistema; de um certo
modo, eles têm a pers pectiva de pessoas localizadas no lado interno, olhando para fora, como
ilustrado pela figura 18.8. Entretanto, mesmo nesse caso, os diversos usuários internos
normalmente estão familiarizados com apenas uma parte do sistema, e suas diferentes visões são
por vezes conflitantes. Pior ainda, as suas entrevislas iniciais com a comunidade usuária podem
omitir um ou dois usuários importantes, cujas interações com os terminadores externos ao sistema
devem ser modeladas
420
Figura 18.8: A visão que o usuáno tem do sistema
É importante gastar tempo e energia no modelo ambiental, pois ele muitas vezes é o ponto central
de várias reuniões e apresentações im portantes desde o início 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 usuários de alto nível e diretores (aqueles que têm o dinheiro para continuar
patrocinando o projeto e o poder de cancelá-lo!) chegarão a ver. Depois de construído 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 Construção do Diagrama de Contexto
O diagrama de contexto, como já vimos, compõe-se de terminadores, fluxos de dados e fluxos de
controle, depósitos de dados e um único processo representando todo o sistema. Estudaremos cada
um deles a seguir:
A parte mais fácil 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 acrônimo convencionado para o
sistema. Alguns exemplos são mostrados na figura 18.9(a) e (b).
Observe que, no caso mais extremo, o novo sistema pode repre sentar toda uma organização; nesse
caso, o nome do processo seria, nor malmente, o da própria organização, como mostrado na figura

Página 285 de 584
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, são rcprcscntados por um quadro retangular no diagrama dc
contexto. Os tcrminadores comunicam-se diretamente com o sistema através dos fluxos dc dados
ou dos fluxos de controle, como mostrado na figura 18.10(a), ou através dc depósitos dc dados
externos, como mostrado na figura 18.10W).
Observe que os terminadores não se comunicam diretamente entre Si; desse modo, o diagrama dc
contexto mostrado na figura 18.11 está incorreto. Na realidade, os terminadores têm comunicações
entre si, mas uma vez que, por definição, os terminadores são externos ao sistema, a natureza e o
conteúdo das interações terminador-para-terminador são 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, então os tcrminadores são 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 organização
Figura 18.10 (a): Comunicação direta terminador-sistema
422
DADOS DE PESQUISA DE MERCADO
FIRMAS DE PESQUISA
Figura 18.10 (b): Comunicação através de um um depósito externo
Três outras observações devem ser feitas sobre os terminadores:
1. Alguns terminadores podem ter um grande número de entradas e saídas. 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 são
marcados com um asterisco; uma convenção alternativa é representar os tcrminadores duplicados
com uma linha diagonal, como mostrado na figura 18.12(b).
anúncio
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

Página 286 de 584
424
Figura 18.12 (a): Terminadores duplicados no diaR rama de contexto
2. Quando o terminador é urna só pessoa, é geralmente preferível 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 é desejável que o diagrama de contexto permaneça
estável e correto, mesmo que ocorram mudanças no pessoal. E, segundo, uma só pessoa pode
desenpenhar diver sos diferentes papéis no sistema; ao invés de mostrar um terminador rotulado
“John Smith” com diversos fluxos não inter- relacionados de entrada e dc saída, é mais
significativo apre sentar os vários papéis 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 são, muitas vezes, conhecidos e visíveis aos usuários da implementação atual do sistema,
existe, iuitas vezes, uma tendência para mostrar o manipulador, em lugar da verdadeira fonte dos
dados. Entretanto, como o novo sistema normalmente terá a opção de modificar a tecnologia pela
qual os dados são trazidos para dentro e enviados para fora do sistema, o mani pulador não deve ser
mostrado. Desse modo, o diagrama de contexto mostrado na ígura 18.l’í(a) é preferível 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 usuário 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
são transportados para fora dele bem como os sinais de controle recebidos pelo sistema ou gerados
por ele. Os fluxos de dados serão incluídos no diagrama dc contexto se forem necessários para
detectar um evento no ambiente ao qual o sistema deva responder, ou se forem necessários (como
dados) para que seja produ zida uma resposta. Os fluxos de dados também podem aparecer no
diagrama de contexto para mostrar dados que sejam transportados entre terminadores para o
sistema. Finalizando, os fluxos de dados são mostra dos no diagrama de contexto quando os dados
são produzidos pelo sistema para responder a um evento.
Como já afirmamos, o diagrama de contexto de um modelo essen cial evita (sempre que possível)
mostrar os manipuladores orientados

Página 287 de 584
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 implementação que transportam dados para dentro e para fora do sistema. Além disso,
desejamos evitar a apresentação das mensagens e handshakings orientados para a implementação
pelos quais o sistema e os terminadores informam-se que estão prontos para entradas e saídas.
Desse modo, queremos evitar o desenho dc diagramas de contexto como o mostrado na figura
18.15(a), porque ele incorpora pressuposi ções de implementação 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 são
causadas e iniciadas pelos terminadores, e de que as saídas são causadas e iniciadas pelo sistema.
Evitando-se as mensagens indesejáveis e as entradas e saídas orientadas para a imple mentação,
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 desnecessárias
427
Ent.retanto, haverá ocasiões cm que um terminador não iniciará entradas, porque, mesmo face à
tecnologia perfeita, o terminador não sabe que o sistema necessita da sua entrada. Similarmente, há
ocasiões em que o sistema não inicia a geração de saídas, pois ele não 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 saída com um fluxo de diálogo (uma seta de duas pontas), como mostrado ria Figura
18.15(c)
18.2.2 A Construção 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 não é 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 ocorrência do evento. Um nome mais apropriado para o evento poderia ser
“Cliente entrega pedido”
Isso pode parecer um exercício semântico, mas não é. Se descre vermos o evento do ponto de vista

Página 288 de 584
do sistema (isto é, visto de dentro), poderemos identificar erroneamente os fluxos de chegada que
não são eventos por eles mesmos, mas que são necessários 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 fácil para identificar os eventos relevantes para um sistema é
visualizar o sistema em ação: examinamos cada terminador e nos perguntamos qual o efeito que as
ações do termi nador podem ter no sistema. Isso á habitualmente feito em combinação com os
usuários do sistema, que podem desempenhar o papel dos terminadores. 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 instâncias do
evento envolvem os mesmos dados; se os dados estiverem presentes em algumas instâncias e
ausentes em outras, podemos ter de fato dois eventos distintos. Por exemplo, se
428
consulta sobre
resposta sobre situa
SISTEMA DE
solicitação de CONTROLE
verificaçáo de crédito DE PEDIDOS
resposta à
verificação de crédito
PARTAM ENTO
DE
INTABILIDADE
CLIENTE
consulta sobre situação de pedido
Figura 18.15 (c):, Um meio alternativo de mostrar fluxos de diálogo
itaçáo de ficação de cr
situação de pedido
resposta à verificação de crédito
Figura 18.15 (b): Fluxos de diálogo para mostrar mensagens essenciais
429
examinarmos cuidadosamente o evento “cliente entrega pedido”, vere mos que algumas instâncias
do evento incluem o elemento de dad’s ‘vendedor-ID” e outros nãO; e veremos que a resposta do
sistema será diferente quando um vendedor estiver envolvido do que quando não houver vendedor.
Desse modo, seria mais apropriado termos dois even tos separados: “cliente entrega pedido”, e
“vendedor entrega pedido de cliente”.

Página 289 de 584
Além disso, lembre-se que a lista dc eventos deve incluir não somente as interações normais entre
o sistema e seus terminadores, mas, também, situações de falhas. Como estamos criando um
modelo essen cial, não temos de nos preocupar com falhas do sistema; mas temos de levar em
consideração as possíveis 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 estão, por definição, fora dos limites do esforço da construção do sistema
representados pelo modelo, os im plementadores não podem modificar a tecnologia do terminador
à sua vontade para melhorar a confiabilidade. Ao invés 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 não 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 depósito”. Porém e se o pedido não chegar dc forma oportuna
(p.ex., dentro de uma semana da data prometida pela gráfica)? 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 gráfica 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 não
importa, à medida que você eventualmente produz componentes do modelo ambienial e confirma
que eles estejam consistentes entre si
Você também pode encontrar-se falando com pessoas que estão
cientes de tudo o que entra e sai do sistema; alguns usuários podem ser
capazes de fornecer-lhe essa informação, ou os programadores de
430
manutenção responsáveis pela manutenção dc uma versão 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 transações que os usuários 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 situação onde o dia grama de contexto não esteja
disponível. Isso é particularmente comum no início de alguns projetos de desenvolvimento de
sistemas: pode não ser fácil identificar imediatamente os terminadores e os vários fluxos que
entram e saem do sistema. Nesse caso, muitas vezes é mais prático começar com um diagrama
DER que mostra os objetos e os relaciona mentos. Os eventos candidatos podem, depois, ser
encontrados pela procura de atividades ou operações que fazem com que sejam criadas ou
eliminadas instâncias de um relacionamento. A criação 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 usuário também poderia dizer-nos que existe um relacionamento “pedidos” entre
CLIENTE e LIVRO. Um evento provável, então, seria uma ação que criasse uma ins tância do

Página 290 de 584
relacionamento de pedidos: um outro evento seria uma ação que anulasse uma instância do
relacionamento. Isso nos conduziria a identificar “Cliente pede livro” e “Cliente cancela pedido de
livro” como eventos da lista de eventos. Não é preciso muita investigação para perceber que
“cliente” é um terminador para o sistema (enquanto “livro” não é); em seguida poderemos começar
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 necessário ao sistema para a produção de uma resposta a um evento,
ou ambos.
• Cada fluxo de saída deve ser uma resposta a um evento.
• Cada evento não 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 saída imediata como res posta, ou armazenar dados para
serem emitidos como saída
posteriormente (como resposta ou parte de uma resposta para
i31
DE EVENTOS
Figura 18.16: Criação 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 transações de estado).
18.3 RESUMO
A construção do modelo ambicntal é a prime!ra e mais importante parte da construção de um
modelo completo dos requisitos do usuário para um novo sistema. A essa altura, isso poderia
parecer uma tarefa fácil; 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

Página 291 de 584
CONTABILI - DADE
liiL
centena de fluxos de dados chegando e partindo. E a lista de eventos é também um importante
esforço em grandes sistemas; pode existir facil mente mais de uma centena de eventos com que o
sistema terá de lidar, e todos deverão ser identificados. Além disso, pode ser difícil conseguir uma
declaração simples consensual do motivo da existência do sistema.
Uma vez construído o modelo ambicntal, ele deve ser minucio samente revisto por todos os
representantes dos usuários principais, bem como pela equipe do projeto. Depois disso, você estará
pronto para iniciar a construção do modelo comportamental, o modelo do interior do sistema. Isso
será discutido nos capítulos 19 e 20.
1. Quais são as três coisas definidas pelo modelo essencial?
2. Que espécie 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 provável conseqüência de o analista de sistemas escolher
um escopo demasiado pequeno para o projeto?
. Qual é a provável conseqüência de o analista de sistemas escolher um escopo demasiadamente
grande para o projeto?
6. Que fatores devem ser levados em conta na definição dc um escopo para o projeto?
7. Como o desejo do usuário de conseguir uma certa participação no mercado afeta o âmbito de um
sistema?
8. Como a legislação decretada pelos diversos níveis governamentais afeta o escopo de um
sistema?
9. Como o desejo do usuário para minimizar (Ou reduzir) despesas operacionais afeta o âmbito dc
um sistema?
10. Como o desejo do usuário em obter alguma vantagem estratégica contra os competidores afeta
o escopo dc um projeto?
11. Projeto de Pesquisa: examine um projeto da sua própria organi zação. Que fatores você
considera que mais influíram na escolha do escopo do sistema? Você acha que o usuário, o analista
de sistemas e a equipe do projeto estavam cientes dele e estavam de acordo?
12. Na sua opinião, de um modo geral, quais serão os principais fatores dos sistemas desenvolvidos
nos anos 90? Por exemplo, a redução das despesas operacionais será mais importante do que as
mudanças causadas pela legislação governamental?
13. Quais são os três principais componentes do modelo ambiental?
433
14. Qual deve ser aproximadamente a extensão da declaração de
objetivos?

Página 292 de 584
15. Quais são as cinco características dc um sistema mostradas pelo
diagrama de contexto?
16. Quais são os componentes dc um diagrama dc contexto?
17. O que é uma lista de eventos?
18. Quais são os três 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 além do diagrama de contexto, a lista de eventos
e a declaração de objetivos?
22. Por que costuma ser necessário fazer muitas revisões 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 condições 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 diferença entre urna fonte e um
manipulador?
32. Por que devem ser mostradas fontes e não manipuladores em um
diagrama de contexto?
33. O que deve fazer o analista de sistemas se o usuário insistir em
mostrar os manipuladores no diagrama de contexto?

Página 293 de 584
34. Sob que condições os fluxos são mostrados em um DFD?
35. Por que as mensagens (prompts) e handshakings em geral não são
mostrados em um diagrama de contexto?
36. O que significa a expressão fluxo limpo de dados?
37. Sob que condições um terminador não inicia a entrada em um.
sistema?
38. Sob que condições o sistema não inicia a saída para um
terminador?
434
39. O que deve ser desenvolvido primciro, o diagrama de contexto ou a lista de eventos? Por quê?
40. Quais são 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 usuários podem não ser importantes em termos de hierar quia organizacional; eles podem
ser considerados como funcioná rios subalternos, secretários ou administradores. Contudo, as
funções que eles desempenham podem ser vitais, e pode ser fun damental modelar exatamente as
entradas que eles recebem do mundo exterior e as saídas 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 usuário de nível mais elevado (isto é, o chefe) informará ao analista de sistemas com
quem deve falar. “Não aborreça nenhum dos meus funcionários”, dirá o chefe ao analista, “eles
estão 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 capítulo 3, pode não haver um meio
diplomático para evitar isso; mas é essencial verificar cuidadosamente o modelo ambiental para ga
rantir que nada esteja faltando.
2 Esse é um improvável cenário para o projeto de desenvolvimento de um sistema, mas está
começando a ocorrer gradualmente mais, à proporção que as pessoas estão utilizando diagramas de

Página 294 de 584
fluxo de dados e outras ferramentas de modelagem descritas neste livro para a construção de
modelos de empresas. Isso pode ser feito sem qualquer intenção de se computadorizar toda a
empresa, mas sim plesmente para abranger o que já existe - principalmente para. abranger os dados
de que a organização 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 Não é obrigatório o uso dc um fluxo dc diálogo, mas ele faz com que o diagrama de contexto
fique mais legível pela agregação das entradas e saídas associadas de forma a que fiquem
imediatamente visíveis ao leitor. Além disso, a utilização de uma seta para mostrar que o diálogo,
em oposição 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 interações
com terminadores externos.
437
IL
19
A CONSTRUÇÃO
DO MODELO
COMPORTAMENTAL
PRELIMINAR
As coisas são sempre melhores no início.
Blaise Pascal, Leilres Provinciales, 1656-165Z nr. 4
1. Porque a abordagem top-down á difícil para o mo delo comportamental.
2. Como desenvolver um modelo comportamental pre liminar usando a subdivisão de cvcntos.
3. Como desenvolver o modelo dc dados DER inicial.
No capítulo 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 declaração de objetivos. Além disso, você teria iniciado a
preparação do dicionário de dados, com pelo menos a definição dos elementos de dados que
representam as intcrfaces entre os terminadores externos e o sistema. Nossa tarefa agora á começar
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 elaboração dos itens iniciais dc) dicionário de dados.

Página 295 de 584
Essa abordagem envolve fundamentalmente o desenho da primei ra versão 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 depósitos cm nossa primeira versão de DFD para modelar s dados que devem ser
memorizados entre eventos assíncronos. Finalizando, interligamos os fluxos adequa dos de entrada
e de saída às bolhas e verificamos nosso conjunto de DFD em relação ao diagrama dc contexto
para manter a consistência.
Feito isso, damos partida cm um processo de limpeza, descrito no capítulo 20, para produzirmos
um modelo bem organizado de processos e de dados para apresentação ao usuário final. A esta
abordagm foi dado o nome de subdivisão dc evcntos cm lMcMenamin e Palmer, 198/d.
Começaremos comparando esta abordagem com a clássica aborda gem top-down.
19.1 A ABORDAGEM CLÁSSICA
A abordagem sugerida neste capítulo é substancialmente diferente da abordagem top-down descrita
em livros clássicos como DeMarco [ 19791, Gane [ e Sarson, 19791 e outros. A abordagem
clássica presume que você já desenhou o diagrama de contexto; mas também presume que você
prosseguirá direlarncnie da bolha única do diagrama de contexto para um 1)11) de alto nível
(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 nível mais baixo, e cada bolha dessas
figuras dc nível mais baixo são tam bém divididas, e assim por diante, até que se alcance o nível de
bolhas “atômicas”, que já não exigem mais decomposições. 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 análise. Em muitos sistemas grandes e complexos, simplesmente não 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 inspiração divina, ou por alguém que lhe diga que o projeto ultrapassou o tempo
para análise e que já é hora de se iniciar a codificação.
• O fenômeno 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 serviço 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. Desnecessário dizer que isso pode não ser a melhor subdivisão do sistema, O que
acontecerá, por exemplo, se o mesmo sistema for especificado por três analistas de sistemas? E por
nove? E por um só?
A subdivisão fl arbitrária. Em muitos casos o novo sistema fundamenta-se em outro sistema já

Página 296 de 584
existente ou é a computa dorização de uma organização. A subdivisão em alto nível do sistema
atual (ex.: as unidades atuais da organização ou os sis temas de processamento existentes) é muitas
vezes utilizada como base lógica 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 freqüentemente tem um Subsistema de Compras e um Subsis tema de Controle de
Qualidade mesmo que essa não seja (e muitas vezes não é) a melhor forma de subdividir (do ponto
de vista funcional) o sistema.
441
A abordagem descrita neste capítulo não é puramente top-down e também não é puramente bottom-
up. Ela é, dc certa forma, uma aborda gem “do meio”; depois que o DFI) inicial está pronto, pode
ser preciso criar alguns níveis para cima e alguns outros níveis para baixo.
19.2 A IDENTIFICÀÇÃO DE RESPOSTAS A EVENTOS
A abordagem dc subdivisào 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 saídas apropriadas de modo a que a bolha seja capaz de emitir a
resposta necessária e desenham-se depósitos, como for mais adequado, para comunicação entre as
bolhas.
4. O resultante DFD inicial é verificado em relação ao diagrama de contexto e à lista de eventos
para que se confirme se está
completo e consistente.
A primeira etapa é direta, quase mecânica 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
capítulo 20, rcnumerarcmos as bolhas adequadamente).
A segunda etapa também é direta e mecânica: cada bolha recebe um nome apropriado, de acordo
com sua necessária 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 tão específicos quanto possível. 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 não á mecânica, mas é normal mente bastante direta. Para cada
bolha desenhada, é preciso identificar as entradas que a bolha necessita para executar sua tarefa; é
preciso identificar as saídas (se houver alguma) que a bolha produz, sendo ainda
442
necessário identificar os depósitos a que a bolha deve ter acesso. Isso normalmente é feito mediante
entrevistas com os usuários apropriados e focalizando cada evento e sua bolha associada. “De que

Página 297 de 584
necessita esta bolha para fazer seu serviço?” - você perguntará ao usuário - e “Que saídas ela
gera?”
Em muitos casos, o evento é dirigido pelos fluxos; isso quer dizer que o sistema se torna
interessado na ocorrência 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
necessário para responder àquele evento. Porém, como mostram as figuras 19.2(a) e (b), podem ser
necessárias entradas adicionais (de ou tros terminadores e possivelmente de depósitos de dados)
para que o processo possa produzir a necessária saída.
Do mesmo modo, é preciso desenhar as saídas apropriadas produ zidas pelo processo como parte
da resposta. Em muitos casos, isso en volverá saídas que são encaminhadas de volta aos
terminadores fora do sistema; entretanto, isso pode envolver saídas enviadas aos depósitos, 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 verificação de consistên cia semelhante às etapas de
equilíbrio descritas no capítulo 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
saída produzida por um processo no DFD preliminar seja
1 ___
Figura 19.2 (a): Fluxo de dados sinalizando a ocorrência de um evento
443
Figura 19.3 (a): Uma saída enviada de um processo para um terminador
enviada para um depósito ou seja uma saída externa mostrada no diagra ma de contexto.
Existem dois casos especiais: (1) eventos unitários que provocam múltiplas saídas e (2) eventos
múltiplos que causam a mesma resposta. No primeiro caso, um evento unitário pode provocar
múltiplas respostas, sendo cada uma delas modelada com sua própria bolha no DFD preliminar.
Isso é ilustrado na figura 19.4. Isso só é adequado se todas as
444
Y
Figura 19.2 (b): Entradas adkionajs necessárias para a produção da resposta
Figura 19.3(b): Uma saída sendo enviada de um processo para um depósito
edido de cliente
Figura 19.4: Múltiplas 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 saída de uma parte da resposta geral deve ser necessária como entrada para outra
parte da resposta geral
De forma inversa, haverá ocasionais situações em que um pro cesso esteja associado a mais de um
evento; isso é mostrado na figura
19.5. Isso só é válido e adequado se a resposta emitida pela bolha for
445

Página 298 de 584
pedido/
dinheiro
idêntica para os diversos evcntos e somente se os dados de entrada e os
de saída forem idênticos para as diversas resposlas aos eventos.
19.3 A INTERLIGAÇÃO 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 não falam diretamente com outras bolhas. Ao invés disso,
as bolhas se intercomunicam através dos depósitos 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 são, no caso geral, assmncronos. Isto é, não
temos meios de garantir que dois eventos ocorrerão 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
• não tenhamos meios dc saber quando os eventos ocorrerão, e
• tenhamos de presumir, em um modelo essencial, que cada pro cesso executará sua tarefa de modo
infinitamente rápido, e
pedido!
cartão de crédito
Figura 19.5: Eventos múltiplos com a mesma resposta
446
daí depreende-se que o único modo dc sincronizarmos múltiplos even tos interdependentes é
através dc um depósito. Atente para o fato de que esse é um depósito essencial: necessário, não por
causa dos retardos de tempo relacionados à tecnologia impcrfcita, mas devido ás considera ções
temporais do ambiente.
Desse modo, você não deve ver um diagrama de fluxo de dados preliminar como o mostrado na
figura 19.6(a); como os evcntos associa dos são assíncronos, a figura 19.6(a) só poderia funcionar
se um depósi to de dados com retardo estivesse oculto cm um dos processos ou no próprio fluxo de
dados. Assim sendo, a figura 19.6(b) é a maneira correta de mostrar as comunicações entre
processos.
19.4 O DESENVOLVIMENTO DO MODELO DE DADOS INICIAL
Como vimos, o procedimento dc esboçar o DFD inicial engloba
o desenho de depósitos de dados entre processos assmncronos. Na maioria dos casos, a natureza
desses depósitos será óbvia e os nomes pode rão ser escolhidos a partir do seu conhecimento do
objetivo do projeto.
Todavia, enquanto isso, você ou um dc seus colegas deve ter co meçado a trabalhar na versão
inicial do diagrama de entidades-re lacionamentos como atividade independente, em paralelo com

Página 299 de 584
o desen volvimento do DFD inicial, o que deve ser feito com o emprego das técnicas descritas no
capítulo 12.
Como o DER e o DFD são desenvolvidos cm paralelo, eles podem ser usados para verificações
cruzadas entre eles. Dessa forma, os depósitos 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 depósitos adequados no DFD preliminar. Nenhum dos modelos deve ser considerado
como sendo o modelo dominante, que controla os demais; todos estão no mesmo pé dc igualdade e
podem dar inestimável auxílio ao outro.
Você também descobrirá que a lista de eventos é tão útil na elabo ração do DER inicial como na do
DFD inicia!. Os substantivos na lista de eventos muitas vezes se mostrarão 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 verificação 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
situaçáo de pedido
Figura 19.6 (a): Modelo incorreto de comunicação com retardo entre processos
pedido de cliente
SSAR
PEDIDO DE
3
PEDIDOS
situação de pedido
Figura 19.6 (b): Modelo correto de comunicação 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 conclusão mais importante deste capitulo e que você não produ zirá um modelo comportamental
que esteja pronto para ser mostrado ao usuário. Ele não está terminado, não está atraente e não é
suficientemen te simples ou bem organizado para ser inteiramente compreendido. Pode-se ver um
exemplo disto examinando-se o estudo de caso do apêndice F.
Então, o que ele é? Qual é o momento de executar as etapas descri tas na seção 19.3? Muito

Página 300 de 584
simples, ele á um começo, uma estrutura sobre a qual você pode assentar o desenvolvimento da
versão final, completa, do modelo essencial.
Neste momento você não deve estar preocupado com a preparação do modelo comportamental, ou
com sua complexidade ou compreensi bilidade. Você deve resistir resolutamente á tentação de
reorganizar, empacotar, decompor ou “recompor” qualquer bolha do DFD prelimi nar. Tudo com
que você deve se preocupar neste momento é com a correção subjacente do modelo: ele tem um
processo para cada evento? Eie apresenta as necessárias entradas e saídas para cada evento? E ele
mostra as necessárias conexões entre os eventos?
Depois de haver estabelecido Ludo isso,você pode começar a traba lhar na reorganização do
modelo. Isso será discutido mais detalhada-
mente no capítulo 20.
REFERÊNCIAS
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 AnalysLís. Nova lorque: YOURDON
Press, 1984.
1. O que é o modelo comportamental de um sistema? Para que serve?
2. Quais são os três principais componentes do modelo comportamental pre1imina
449
3. Qual é a abordagem clássica de construção do modelo comporta-
mental? Por que ela é caracterizada como uma abordagem top
down?
4. Quais são os três principais problemas normalmente encontrados
pelos analistas de sistemas ao tentarem seguir a abordagem top
down clássica para preparar o modelo comportamental de um
sistema de informações?
5. Por que você acha que alguns analistas de sistemas são 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 subdivisão fisica arbitrária?
7. O que significa a expressão subdivisão de eventos?
8. Quais são as quatro etapas da subdivisão dc eventos?

Página 301 de 584
9. Se o analista de sistemas tiver descoberto 13 eventos no modelo
ambiental, quantos processos (bolhas) deve haver na primeira
versão do modelo comportamental?
10. Que tipo de esquema de numeração é utilizado para se numerar as
bolhas na primeira versão do DFD do modelo comportamental?
11. Que base lógica é utilizada para se dar um nome a cada bolha na
primeira versão do DFD do modelo comportamentaP
12. Como o analista de sistemas deve determinar as entradas, saídas e
depósitos necessários a cada bolha na primeira versão 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 são as diretrizes dc verificação dc consistência que o analista
de sistemas deve seguir ao desenhar a primeira versão do DFD do
modelo comportamental?
15. Como deve ser desenhada a primeira versão do DFD para o caso
de um evento que produz múltiplas respostas?
16. Sob que condições pode urna bolha única na primeira versão do
DFD estar associada a mais dc um evento?
17. Na primeira versão do DFI), como as bolhas comunicam-se entre
si? Isto é, como a saída produzida por uma bolha torna-se a entrada
de outra bolha?
18. Como a primeira versão do l)Fl) mostra a sincronização de eventos
múltiplos, assmncronos e interdependentes?
19. O que deve ser desenvolvido primeiro: a primeira versão do DFD
ou a primeira versão do modelo de dados (I)ElO? Por que?
20. O que o analista dc sistemas dcvc fazer com a primeira versão do
DFD e do DER depois de havê-las completado?
21. Quando a primeira versão do I)FD está pronta, deve ser revista
com o usuário? Por quê?
450
22. O que está errado na primeira versão dc DFD abaixo?
23. O que está errado na primeira versão de DFD abaixo?
crédito
o)

Página 302 de 584
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
Dêem-nos as ferramentas e completaremos nossa tarefa.
Winston Churchill,
transmissão radiofônica, 194
1. Como subdividir um DFD inicial em níveis deforma ascendente.
2. Como ocultar depósitos dc dados locais.
3. Quando e como subdividir dc forma descendente as bolhas de um DFD inicial.
4. Como completar o dicionário de dados inicial.
5. Como completar as especificações dc processos.
6. Como completar o modelo de dados.
7. Como completar o diagrama de transições de estado.
No capítulo anterior, apresentei um estratégia para desenvolver uma versão inicial do modelo
comportamental. Entretanto, é evidente que aquele modelo não pode ser apresentado ao usuário
para verifica ção. Por que não? Em primeiro lugar porque ele é complicado demais. Como vimos
no capítulo 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
versão inicial do DER é provavelmente muito tosca para ser revista com os usuá rios; como
discutimos no capítulo 12, é necessário algum refinamento para eliminar os objetos desnecessários
e/ou acrescentar novos objetos.
453
Existe um segundo problema com o modelo: ele é composto po muitos gráficos, com pouco ou
nenhum suporte textual. Embora o dia grama de fluxo de dados e o de entidades-relacionamentos

Página 303 de 584
sejam exce lentes veículos de apresentação dc uma vista geral do sistema a usuário eles necessitam
do apoio de um dicionário de dados e de um conjunt completo de especificações dc processos.
20.1 COMO COMPLETAR O MODELO DE PROCESSOS
20.1.1 A Subdivisão do DE!) em Níveis
O primeiro passo é reorganizar o DFD que desenvolvemos no capítulo 19. Como vimos, ele
compõe-se de um único nível, com dema siadas bolhas. Então, precisamos subdividir o I)FD em
níveis ascenden tes. Isso quer dizer que desejamos agrupar processos relacionados em agregados
significativos, cada um representando uma bolha de um dia grama de nível mais elevado. Isso é
ilustrado na figura 20.1.
Existem três 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 apareçam no nível
inferior. Assim, se você en contrar um grupo de processos no DFD preliminar relativo ao mesmo
depósito, sem que oulros processos no DFD preliminar se refiram a esse depósilo, então você deve
criar uma bolha em nível mais alto que oculte aquele depósito. Isso é ilustrado na figura 20.2.
3. Lembre-se de que a pessoa que examinar seus diagramas de fluxo de dados, seja ela um usuário
ou um analista de sistemas, não 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 pr»c (e os fluxos que lhe sejam relacionados) ou um depósito
possa ser considerado um fragmento
Isso, naturalmente, significa qu )odemos precisar de algum esfor ço de subdivisão em níveis
ascendentes. Por exemplo, se começamos
454
1 RESULTADO DA SUBDIVISÁO
EM NÍVEIS ASCENDENTES
DFD PRELIMINAR
Figura 20.1: Subdivisão de um DFD em níveis ascendentes
com um DFD preliminar que tinha (para fins de argumentação) 98 processos e organizamos o
diagrama em grupos de 7 bolhas (ignorando, para favorecer a simplicidade, todos os depósitos),
poderíamos criar um diagrama de nível mais alto com 14 bolhas, cada uma delas representan do
uma “abstração” de sete bolhas do n inferior. Mas 14 bolhas é um número elevado para se
manipular e muito grande para ser mostrado ao usuário de uma só vez; desse modo, nós
possivelmente criaríamos um diagrama de nível ainda mais elevado, como na figura 20.3, com
apenas duas bolhas.
Observe que este exemplo envolve números inteiramente artifi ciais. Você não deve orientar sua
atividade de subdivisão em níveis de forma a garantir que cada diagrama tenha exatamente sete

Página 304 de 584
bolhas! Na verdade, as duas primeiras diretrizes acima citadas, agrupar bolhas se gundo os dados
comuns e buscar oportunidades de ocultar depósitos
455
RESULTADO DA SUBDIVIS EM NÍVEIS ASCENDENTES
DFD PRELIMINAR
Figura 20.2: A ocultação de um deposito local no nivel superior
locais, devem ser sua principal base lógica para a subdivisão em nívei
ascendentes, e não uma lei aritmética.
Observe ainda que você também pode precisar fazer subdivisõe em níveis descendentes. Isto é, os
processos idcntifkados no DFD preli minar podem não ser processos primitivos e exigirem
subdivisões par baixo, em DFD de níveis inferiores. Isso significa apenas que os proces sos
iniciais, cada um dos quais é responsável pela produção da respost a um evento, podem ser
demasiadamente complexos para serem descri tos em uma especificação de processos de uma
página. Isso muitas ve zes torna-se evidente quando se examina cuidadosamente o processo ou
quando se solicita ao usuário uma explicação do que a bolha dev fazer. Se o usuário hesitar por um
instante, inspirar profundamente
456
Figura 20.3: Mú1t subdivisões ascendentes de um DFD
disser “Bem, é uma longa história, mas é mais ou menos o seguinte é uma boa indicação de que
aquela bolha preliminar terá de ser subdividida!
Em outros casos, a necessidade dc subdividir cm níveis no sentido
descendente pode não se tornar evidente até que você realmente tente
redigir a espccifkação de processos; se você notar que já escreveu três
FIGURA o (duas bolhas>
lesultado da primeira su bdivisáo m níveis ascendentes
(14 bolhas)
o
o
o
o
o
DFD preliminar (98 bolhas)
o
o
457
páginas sobre uma bolha preliminar e ainda há mais, muito mais a se escrito, é outra indicação da

Página 305 de 584
necessidade da subdivisão.
Eis algumas diretrizes para a subdivisão em níveis descendentes:
Em alguns casos, a abordagem de decomposição funciona pura é adequada. Isto é, se você
encontrar uma bolha de proces. so que execute uma função complexa, tente identificar sub.
funções, cada uma das quais podendo ser uma bolha de níve, mais baixo. Suponha, por exemplo,
que tenhamos um processc chamado “Ajustar trajetória do míssil”; ele poderia ser a bolha
responsável pela manutenção dc um evento temporal em uni sistema de direção dc mísseis cm
tempo-real. A função geral de ajustar a trajetória do míssil poderia ser decomposta em vária5
subfunções:
Calcular a variação da coordenada x.
- Calcular a variação da coordenada y.
- Calcular a variação da coordenada z.
- Calcular o novo fator de “arrasto” atmosférico.
- Calcular a nova velocidade do vento.
- Calcular força de impulsão da coordenada x.
- Calcular força de impulsão da coordenada y.
- Etc.
• Em outros casos, os fluxos de dados que chegam e que saem da bolha darão a melhor indicação
para a subdivisão em níveis descendentes. Por exemplo, suponha que tenhamos uma bolha como a
da figura 20.4. É provável que um DFD de nível inferior possa ser criado com a forma geral
mostrada na figura 20.5. Evidentemente, pode ser necessário mais de uma bolha para combinar ou
agregar os elementos de dados, mas a idéia é a mesma: deti os dados seivirein de guias.
Enquanto você estiver envolvido com a atividade de subdivídir os níveis de maneira ascendente ou
descendente lembre-se da impor tância do equilíbrio. Isto é (como vimos no capítulo 14), é preciso
veri ficar se as entradas e saídas de urna bolha de um determinado nível
458
x
p
correspondem às entradas e saídas dc um diagrama do nível ime diatamente inferior. Para ver um
exemplo da atividade de subdivisão ascendente, leia o estudo de caso do Sistema dc Informações
da YOURDON Press no apêndice F. Naquele caso começamos com um DFD preliminar contendo
40 bolhas; tornou-se necessário um nível de ;ubdivisão ascendente, conduzindo-nos a um DFD da
figura O com nove olhas.
Figura 20.4: Decomposição de uma bolha complexa em níveis descendentes
entrada intermediária (X’)
Figura 20.5: O DFD de nível inferior
459
20.1.2 Como Completar o Dicionário de Dados

Página 306 de 584
Quando você começou a desenvolver o DFD preliminar no capí tulo 19, deve também ter iniciado
o desenvolvimento do dicionário d dados; na verdade é bastante comum começar-se o dicionário de
dado quando o diagrama de contexto está sendo desenvolvido. Entretanto, dc ainda está longe de
estar completo. Normalmente, ainda será necessáric fazer a descrição do st dc cada itcm de dado;
por uma questãc de clareza,podc também ser necessário dividir os itens de dados comple xos em
subitens.
Quando o dicionário 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 dicionário
não contra- diz alguma outra parte). Certifique-se também que o dicionário está equilibrado em
relação ao diagrama de fluxo de dados em níveis, ao dia grama de entidades-relacionamentos e às
especificações de processos.
20.1.3 Como Completar as Espec de Processos
Quando desenvolvemos o diagrama de fluxo de dados preliminar, utilizando a abordagem da
subdivisão dc eventos mostrada no capítulo 19, há grandes possibilidades dc que não tenhamos
feito qualquer espe cificação de processo. Poderá haver algum caso de uma determinada
especificação ter sido esboçada face a um interesse particular de sua parte ou de parte do usuário,
mas sua principal preocupação será apenas com a preparação do próprio DEr).
Na verdade, muitas vezes é uma má idéia gastar tempo com a escrita de especificações de
processos antes que o DFD esteja pronto, porque o desenvolvimento inicial do I)Fl) está sujeito a
muitas modifica ções, correções e revisões. As bolhas podem aparecer, desaparecer, ser movidas e
rebatizadas. Quando o DFD preliminar começa a se assentar e passa pelo teste da subdivisão cm
níveis ascendentes (isto é, essa ativi dade não descobre maiores falhas no modelo), você pode
começar a redigir as especificações de processos.
Esse trabalho é muitas vezes prolongado e consumidor de tempo, porque cada bolha do nível mais
baixo do I)FD exige uma especificação de processo. Desse modo, pode ser possível a um grupo de
dois ou três analistas de sistemas desenhar algumas dezenas de DFD; mas será neces sário um
grupo maior de analistas para completar todas as especificações. de processos em tempo
satisfatório.
Quando as especificações de processos estiverem prontas, devem
ser equilibradas e passar por uma verificação cruzada em relação ao
460
[ de dados e ao DER, observando-se as diretrizes apresentadas Lo capítulo 14.
O.2 COMO COMPLETAR O MODELO DE DADOS
Como dissemos no capítulo 12, o DER é desenvolvido em uma nodalidade um tanto semelhante à
que foi apresentada sobre o DFD:
sboçamos 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 identificação de novos tipos de objetos ou de tipos de objetos lesnecessários.
Lembre-se, contudo, que o DER muitas vezes é desenvolvido mais )u menos ao mesmo tempo que
o DFD. É muito comum encontrar tlguém (ou um pequeno grupo) da equipe de projeto trabalhando

Página 307 de 584
no )ER, enquanto outra pessoa (ou um outro pequeno grupo) trata do )FD. Ou então o DFD pode
ser desenvolvido pela equipe de projeto, nquanto o DER é desenvolvido por um grupo de
administração centra izada de dados dentro da organização 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 (existência de Jepósitos, fluxos de dados etc.) pode muitas vezes ser usado
para refinar fazer verificações cruzadas do DER
O.3 COMO COMPLETAR O DIAGRAMA DE
TRANSIÇÕES DE ESTADO
Se o seu sistema possuir características de tempo-real, você desen olverá um diagrama de
transições de estado em acréscimo 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 capítulo 13, você deve examinar o diagrama inicial de tran ições 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 condições possíveis?
461
20.4 RESUMO
Atingimos, aqui, o final do modelo essencial. Se você acompanho todas as etapas dos capítulos 18,
19 e este capítulo, deve estar de poss de um modelo completo, detalhado, formal e rigoroso de tudo
o que sistema deve fazer para satisfazer os requisitos do usuário. Ele contén todos os itens abaixo:
• Diagrama de contexto
• Lista de eventos
• Declaração de objetivos
• Um conjunto completo de diagramas de fluxo de dados ezr níveis
• Diagrama de entidades-relacionamentos terminado e completo
• Um conjunto completo de diagramas de transições de estado
• Dicionário de dados completo (para a fase de análise dc projeto)
• Um completo conjunto de especificações de processos, con uma especificação para cada processo
do nível mais baixo.
Presumindo que você tenha revisado os componentes da especi. ficação para certificar-se de que
estão completos e consistentes e que c usuário revisou e aprovou o documento, você terminou.
Você pode passar um belo laço vermelho em volta do pacote e entregá-lo à equipe de
projeto/programação cuja tarefa será construir o sistema. Em seguida, pode recolher-se ao
aconchegante conforto de seu escritório até que suna o próximo projeto.
Mas, espere! Ainda há uma última etapa. Tudo o que desenvol vemos no modelo essencial
pressupunha a existência de perfeita tecno logia, mas também que o usuário não teria restrições de

Página 308 de 584
implementaçãc a impor ao sistema. Perfeita tecnologia é uma fantasia de nossa ima ginação, mas
podemos deixar que a equipe de implementação decida como alcançar um compromisso razoável
coma tecnologia existente.
A idéia de que o usuário vai ignorar todas as restrições de imple. mentação também é uma fantasia,
com a qual teremos de lidar ante5 de passarmos a versão final da especificação para a equipe de
imple mentação. Essa atividade final, que deve ser feita com a colaboração do
462
usuários, dos analistas e de al,guns membros da equipe de implemen tação, é o desenvolvimento do
modelo de implementação do usuário. Esse assunto será discutido no próximo capítulo.
1. Por que a primeira versão do modelo comportamental não pode ser apresentada ao usuário?
2. A primeira versão do modelo comportamcntal é completa? Se não é, que elementos lhe faltam?
3. O que significa subdivisão em níveis ascendentes no contexto des te capítulo?
4. Qual é a base lógica que o analista de sistemas deve usar para agrupar bolhas cm um DFI)?
5. Quais são as três diretrizes que o analista dc sistemas deve lembrar ao fazer uma subdivisão em
níveis ascendentes?
6. O que significa o conceito de ocultação de dados armazenados no contexto deste capítulo?
7. Quantos níveis de DFD dc nível mais elevado devem ser criados a partir de um único DFD de
primeira versão? Existe alguma fórmula matemática que possa ser utilizada para dar uma
aproximação do número necessário de níveis?
8. Sob que condições a subdivisão de um DFD em níveis descenden tes torna-se necessária?
9. É possível que o analista de sistemas precise executar a subdivisão de um DFD em níveis
ascendentes e descendentes? Por quê?
10. Por que o dicionário de dados normalmente deve estar pronto du rante o estágio de
desenvolvimento do modelo comportamental?
11. Que tipo de verificação de erros deve ser feita no dicionário de dados durante esse período do
projeto?
12. Por que muitas vezes não é uma boa medida que o analista de sistemas despenda tempo
redigindo especificações de processos antes que o DFD preliminar esteja completo? Sob que
condições faria sentido escrever pelo menos algumas especificações?
13. Quais são os oito principais componentes do modelo terminado dos requisitos do usuário?
NOTAS
1 Esse número aparentemente arbilrário (sete mais ou menos dois) é
uma diretriz para controlar a complexidade em diversas situações
de resolução de problemas. Ela se fundamenta na obra de George
463
Milier, que foi o primeiro a perceber a dificuldade das pessoas err lidar com múltiplos fragmentos

Página 309 de 584
de informação, em um clássico ar tigo intitulado “The Magical Number Seven, Plus or Minus l’wo
Some Limits on Our Capacity for Processing Information”, publica do em Psycholo Revíew,
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 comunicação, 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 IMPLEMENTAÇÃO
DO USUARIO
Deve ser observada uma simplicidade espartana. Nada poderá ser feito apenas porque contribui
para a beleza, conveniência, conforto ou prestígio.
Office of lhe ChiefSi.gnal Offícer, U. S. Ar?ny,
29 de Maio de 1945
1. Como escolher as fronteiras da automatização para um sistema.
2. Como selecionar os dispositivos de entrada e os dis positivos de saída para o usuário.
3. Como desenvolver os formatos dc entrada e os for matos de saída.
4. Como projetar formulários para o sistema.
5. Como desenvolver esquemas de codificação para entradas de sistemas.
6. Como identificar atividades manuais de suporte.
7. Como descrever as restrições operacionais do sistema.
Ao finalizarmos o último capítulo terminamos o desenvolvimento do modelo essencial de um
sistema dc informações. Esse modelo con tém uma descrição completa do que o sistema deve fazer
para satisfazer o usuário. Especificamente o modelo essencial descreve:
465
1
• A ação essencial ou lógica das funções que devem s executadas.
• O conteúdo essencial dos dados armazenados pelo sistema que se movimentam através dele.
• O comportamento essencial tempo-dependente que o sistern deve exibir para lidar com os sinais e
as interrupções do arr
biente externo.
No melhor de todos os mundos (do ponto dc vista do analista d sistemas e da equipe de
implementação), isso representa informaçõc suficientes para os projetistas e programadores: nós
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 programação, dentro da restrições gerais de tempo, dinheiro e recursos humanos para

Página 310 de 584
o projetc Entretanto, isso não é tão simples: em virtualmente todos os projeto de desenvolvimento
dc sistemas, o usuário insistirá em que se incluar informações adicionais.
Essas informações adicionais envolvem problemas de imp1emei lação - mas problemas de
implementação que sejam suficientementi importantes e que tenham impacto suficiente na
capacidade do usuári em utilizar o sistema para que precisem ser especificados agora. O pro biema
mais evidente de implementação de interesse do usuário é a fron teira da automatização, isto é, que
partes do modelo essencial serã implementadas em computador, e que partes serão executadas
manual mente na organização do usuário? O analista de sistemas pode ter um opinião sobre isso, e
o grupo projetista/programador pode também que rer exprimir sua opinião, mas este, naturalmente,
é um problema sobre qual o usuário tem a última palavra.
De modo análogo, ofonnaio das entradas do sistema (também co nhecido como interface humana)
é de grande interesse para o usuário- muitas vezes, ele parece ser dc interesse maior do que as
funções dc sistema! Desde que os sistemas dc processamento começaram a gerai relatórios
impressos, os usuários têm manifestado fortes opiniões sobre organização e o layout das
informações do relatório. Onde devem ficai os números das páginas? Onde devem ser colocados os
títulos das pá ginas? Como deve ser arrumada cada linha de informação para máxima legibilidade?
Deve haver um resumo ou um subtotal ao final de cada página ou somente ao final do relatório? E
assim por diante.
Com o advento dos sistemas on-line nos anos 70, esse problema
expandiu-se incluindo o interesse do usuário na formatação das telas dc
entrada do terminal de vídeo. Onde devem ser apresentadas na tela as
466
mensagens de entrada? Que espécies de mensagens de erros devem ser exibidas? Como o usuário
deverá mover-se de uma tela para outra?
Mais recentemente diversas outras opções e possibilidades vieram
aumentar a importância desses problemas de implementação do usuário:
Os usuários finais muitas vezes têm a oportunidade de usar computadores pessoais (PC) como
parte de uma rede distribuí da de computadores (p.ex., são-lhes dados PCs interligados ao
computador de grande porte da organização). Isso levanta uma série de questões: que partes do
mode essencial serão desig nadas para o PC (sob controle do usuário) e quais ao main frame? Que
partes dos dados serão designadas para o PC e que partes ao mainframe? Qual será o formato da
entrada que o usuário fornecerá ao PC? Quais as atividades adicionais de apoio que devem ser
oferecidas para assegurar que o usuário não danifique inadvertidamente os dados do PC ou do
mainframe?
Os usuários finais atualmente estão tendo cada vez mais opor tunidades para escrever seus próprios
programas em linguagens de quarta geração como FOCUS, NOMAD e IDEAL em computa dores
de grande porte, ou dBASE-III e Rbase-5000 nos PCs. À proporção que se envolvem com tais
problemas de implemen tação, eles precisam especificar os formatos das entradas e saídas do
sistema. E mais, eles podem querer decidir que partes do sistema serão implementadas usando
linguagens de quarta geração e que partes serão implementadas com linguagens con vencionais de
terceira geração

Página 311 de 584
Em muitas situações hoje em dia, o usuário e o analista de sis temas podem decidir prototipar
partes do sistema, usando ou uma linguagem de quarta geração de alto nível ou um pacote gerador
de aplicações. A prototipação pode ser feita porque o usuário está inseguro da ação detalhada que
eventualmente terá de ser escrita nas especificações de processos do modelo essen cial; porém, a
atividade de prototipação está, na maioria das vezes, interessada na exploração e experimentação
com forma tos de entrada, diálogos on-line e formatos de saída para telas e relatórios.
• Para muitas aplicações da empresa, uma opção disponível ao usuário é a escolha e aquisição de
um pacote de software, isto é, um produto de software que pode ser utilizado sob licença ou
adquirido de um fornecedor. Nesse caso, os mesmos problemas de implementação são importantes
para o usuário: que partes
467
das funções essenciais serão implementadas pelo pacote adqui rido e que partes terão dc ser
executadas pelo usuário (ou im plementadas pelo setor dc SIG do usuário como um sistema se
parado)? Que partes dos dados essenciais serão mantidos pek pacote e que partes terão dc ser
mantidas pelo usuário? serão a forma e a seqüência das entradas exigidas pelo sistem adquirido e
serão elas aceitáveis
E’ problemas devem ser tratados como parte do modelo de Im plementa do usuário. Eles podem ser
originados pelo aumento, pek inclusão de observações e pela revisão do modelo essencial, como ve
remos nas seções subseqüentes deste capftulo. Recomendo, entretanto que você mantenha sempre
intacta uma cópia do modelo essencial origi na!; isto permitirá que você experimente modelos
alternativos de imple mentação do usuário no futuro.
Em termos gerais, o modelo dc implementação do usuário abrang
os quatro aspectos seguintes:
. A alocação do modelo essencial a pessoas versus máquinas.
2. Detalhes da interação homem/máquina.
3. Suplementares atividades manuais que podem vir a se necessárias.
4. Restrições operacionais que o usuário deseja impor ao sistema.
Todos esses aspectos serão discutidos cm maiores detalhes
seguir.
21.1 A DETERMINAÇÃO DOS LIMITES DA AUTOMATIZAÇÃO
Lembre-se de que o modelo de sistema em que estamos traba lhando neste momento identifica
todas as atividades (funções) essenciai e todos os dados essenciais. A pergunta a esta altura : que
funções que dados serão manipulados manualmente, e quais serão automatiza dos? Embora possa
ter havido uma experimental escolha preliminai dos limites da automatização durante o estudo de
viabilidade não de. vemos considerá-los como fixados. Na realidade, o limite da auta matização é
quase irrelevante no modelo essencial, pois embora c usuário obviamente deseje que
desenvolvamos um sistema auto matizado, ele também necessita de uma bem elaborada declaração
dc
468

Página 312 de 584
requisitos das funções e dos dados que ficarão fora das frontLiras da automatização.
Existem três casos extremos que mencionaremos sucintamente:
O usuário pode não se importar com onde esteja a fronteira da automatização. É improvável que
isso aconteça, mas é uma possibilidade teórica. Na prática, o usuário solicita à equipe de
implementação, “Diga-me que partes do sistema devem ser manuais ou automatizadas”. Além do
fato de que o usuário normalmente tem grande sensibilidade sobre esse problema, es pera-se que o
analista de sistemas produza (como produto se cundário do seu trabalho) uma análise revisada de
custo/be nefício de todo o projeto. Isso costuma exigir pelo menos al guma decisão preliminar de
que partes do modelo essencial serão automatizadas e quais serão manuais.
O usuário pode optar por um sistema inteiramente automati zado. Essa é uma situação muito
comum, principalmente se o sistema estiver sendo desenvolvido para substituir um outro sis tema
já existente e suas fronteiras não serão alteradas. Desse modo, as atividades manuais executadas
pelo usuário podem já estar fora dos limites do sistema - representadas no diagrama de contexto
como terminadores com os quais o sistema se comunica.
• O usuário pode optar por um sistema inteiramente manual. F.ssa é uma opção bastante incomum,
especialmente nesta era da automatização, pois o analista dc sistemas habitualmente tem interesse
em computadorizar o quanto for possível. Entretanto, isso pode ocorrer em ocasiões cm que a
intenção expressa do usuário não seja computadorizar coisa alguma, mas simples mente
reorganizar a maneira com as atividades estejam presen temente sendo executadas em uma
organização.
Normalmente, esses casos extremos não ocorrem; com base nas interações entre o usuário, o
analista de sistemas e a equipe de imple mentação, algum acordo será ajustado. Isto é, al,guinas das
atividades do modelo essencial serão automatizadas, e outras serão identificadas como funções
manuais; de forma análoga, alguns dos dados essenciais serão identificados como candidatos certos
para computadorização (sendo, presumivelmente, colocados sob o controle de uma organização de
SIG) e alguns serão deixados sob o controle direto do usuário. A menos que o usuário faça uma
escolha imediatista e arbitrária por ordem, será aconse lhável que as trê.s partes (o usuário, o
analista dc sistemas e a equipe de
469
implementação) examinem diversas opções. Como as figuras 21.1(a), (b e (c) demonstram, pode
haver diversas alternativas razoáveis para detei minar o limite da automatização. Cada alternativa
terá custos diferente (em cuja estimativa a equipe de implementação deve auxiliar, uma ve
PARTE
MANUAL
Figura 21.1 (a): Uma opção para afronteira da automatização
Figura 21.1 (b): Outra opção para os limites da automatização
470
PARTE
AUTOMATIZADA

Página 313 de 584
Figura 21.1 (c): Uma terceira opção para os limites da automatização
que eles têm o conhecimento das possibilidades da tecnologia de imple mentação) e ramificações
organizacionais diferentes na área do usuário.
A tarefa de determinar os limites da automatização não é da alça da do analista de sistemas e nem
da equipe de implementação; ela é, em última análise, da responsabilidade do usuário, e este livro
não apresentará qualquer diretriz para determinar qual seria a melhor escolha. Mas, observe como o
modelo essencial serve como uma útil ferramenta para o usuário e para a equipe de implementação
exami narem as diversas opções. Uma vez que a fronteira da automatização tenha sido escolhida, o
analista de sistemas pode pensar que ele tem o privilégio de eliminar os processos manuais e dados
manuais (isto é, as bolhas e depósitos que não serão automatizados) sem maiores con siderações.
Porém, geralmente não é 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 usuária saibam como executar as funções requeridas. E o analista pode ter de
fornecer alguma orientação na organização de depósitos que não serão automatizados Observe que
esse aspecto do modelo de implementação do usuário precisa apenas que sejam feitas observações
no DFD e no PRD para indicar quais atividades e dados são manuais e quais são automatizados.
471
PARTE
UTOMATIZADA
Figura 21.2 (a): Um modelo essencial com os limites da automatização
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, radiação, iluminação, aspectos ergonômicos do
terminal de vídeo, espaço de trabalho e assim por diante. Quase sempre o novo sistema desorganiza
o ambiente normal dc trabalho do usuário (p.ex., ele fará com que um terminal dc vídeo seja
colocado na mesa do usuá rio, onde nunca tinha existido um antes) Ou pode introduzir atividades
de processamento de informações em um ambiente onde nunca tinham sido executadas essas
atividades antes (ex., um piso dc fábrica em um ambiente de manufatura). Assim, é importante
garantir que esses fatores humanos tenham sido cuidadosamente estudados antes da determina ção
final das fronteiras da automatização. O usuário muitas vezes tem importantes opiniões a expressar
sobre esses aspectos, porém se ele não tiver experiência anterior em sistemas dc informações, pode
não ser capaz de adiantar quais serão os problemas. Você pode se aconselhar com Outros
profissionais dc sistemas que desenvolveram e instalaram sistemas semelhantes em iguais
condições ambientais.
Para finalizar, observe que uma vez que tenha sido decidida a fronteira da automatização, pode ser
necessário 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 pressupõe
que o sistema esteve sempre funcionando e assim continuará para sempre. Desse modo, podemos

Página 314 de 584
precisar incluir processos (bolhas no DFD), fluxos de dados e depósitos adicionais para mostrar as
atividades inicializadoras e tcrminadoras do sistema; isso pode incluir relatórios para a direção (ou
para os usuários ou para o de partamento de operações) sobre as características operacionais do
sistema.
21.2 A DETERMINAÇÃO DA INTERFACE HUMANA
A atividade mais consumidora dc tcmpo e na qual o usuário estará
mais interessado, é provavelmente a especificação da interface humana.
Isso envolve quatro problemas relacionados:
1. A escolha de dispositivos dc entrada e saída (p.ex., terminais de vídeo, dispositivos de k’itura
ótica, cartões perfurados etc. para entrada e relatórios impressos, imagens na tela do monitor, ou
luzes piscantes como saída).
2. O formato de todas as entradas que fluem dos terminadores para o sistema.
473
3. O formato de todas as saídas que fluem de volta do sistema para os terminadores.
4. A seqüência e o “timing” de entradas e saídas em um sistema on-line.
21.2.1 Dispositivos de Entrada e Saída
A escolha dos dispositivos de entrada e saída pode ser imposta pelos terminadores externos ao
sistema; por exemplo, se o sistema pro duzir relatórios de saída a serem enviados ao governo, pode
não haver outra escolha senão produzir relatórios impressos. Os dispositivos que costumam ser
usados para entrada de dados incluem:
Cartões perfurados. Os cartões perfurados foram a forma mais comum de entrada de dados, porém
são raramente utilizados atualmente, exceto em alguns sistemas batch de processamento muito
grandes. Uma vantagem dos cartões perfurados é que eles podem ser usados como documentos
fonte pelo usuário externo (p.ex., considere os cheques produzidos por alguns sistemas do governo;
eles são documentos negociáveis, mas também são usados como entrada direta para um sistema de
processamento). As maiores desvantagens dos cartões perfurados são o tamanho volumoso,
capacidade limitada de armazenamento de dados, o fato de só poderem ser utilizados uma vez e a
suscetibilidade a
erros do operador.
• Fita magnética. A fita magnética pode ser uma forma apro priada de entradas provindas de outros
sistemas; ela também
pode ser um meio adequado de entrada se o usuário dispuser de um dispositivo de entrada de dados
teclado-fita. A principal vantagem desse recurso é, naturalmente, que o volume de da dos de
entrada que pode ser armazenado em uma fita é muito maior que em um cartão; a desvantagem é
que os dados não podem ser manipulados com facilidade, uma vez que eles estão gravados na fita.
O cartão perfurado, por outro lado, é mais pri mitivo, mas oferece ao usuário a possibilidade de
rearrumar os cartões ou anular alguns deles (jogando-os fora) antes de sub metê-los ao sistema.
• Discos flexíveis. Com o aparecimento dos computadores pes soais no início dos anos 80, os
discos flexíveis tornaram-se uma

Página 315 de 584
forma popular de meio de entrada. Os dados normalmente são
474
gravados nos discos flexíveis pela interação off-line com um computador pessoal (por off-line
queremos dizer que a ati vidade não tem conexão com o sistema de informações em de
senvolvimento). Um disco flexível comum pode armazenar entre 360.000 e 1.2 milhões de
caracteres; isso não é tanto quanto uma fita magnética, mas é satisfatório para muitas apli cações de
tamanho médio.
Terminais e computadores pessoais. Os terminais de vídeo, tor naram-se um dos mais comuns
meios de entrada durante os últimos dez anos à medida que o preço caiu de $3000 (ou mais) para
$300 (ou menos). É importante distinguir entre os terminais comuns (não inteligentes) que não
oferecem nada além de um teclado e uma tela, os terminais inteligentes que oferecem diver sos
recursos de edição local e capacidade de armazenamento local e os computadores pessoais, que
têm capacidade de ar mazenamento muito maior e todos os poderes computacionais de um
computador de emprego geral. Terminais inteligentes e PCs possibilitam que o usuário faça
alterações e corrija erros triviais imediatamente, em vez de esperar pela demora do envio das
entradas através de linhas de telecomunicações ao computa dor principal; a capacidade de
armazenamento local torna possível ao usuário introduzir um grande volume de entradas, ainda que
o sistema principal de processamento não esteja operacional durante todo o tempo.
Leitoras óticas e leitoras de códigos de barra. Leitoras óticas e leitoras de códigos de barra podem
ler informações impressas ou codificadas em vários tipos de documentos; isso é especial mente
vantajoso para aplicações como a cobrança em uma loja, onde o usuário precisa introduzir o código
e outros dados rele vantes sobre um produto. Como esses dispositivos podem ler diretamente os
dados, elimina-se a necessidade de o usuário digitar manualmente os dados em um terminal.
Algumas leitoras óticas podem ler documentos datilografados da forma normal e algumas podem
ler documentos manuscritos. A maior desvan tagem desse tipo de meio de entrada é o seu custo;
outra des vantagem é sua tendência a erros.
• Telefone. Para algumas aplicações, o telefone Touch-Tone pode ser um meio de entrada
apropriada 6• Isso é particularmente van tajoso para os sistemas que devem lidar com o público em
geral:
poucas pessoas têm um terminal ou um PC em suas casas, mas aproximadamente 98% da
população dos Estados Unidos têm
475
/
pelo menos um telefone cm suas casas. Uma vez que o telefone somente fornece entradas
numéricas, as aplicações são um tantc limitadas; ele é prático para situações onde o usuário
necessita fornecer informações como um número de conta, mas não prático para situações que
requerem entrada de texto.
Entrada de voz. Para finalizar, alguns sistemas podem usar a voz humana como meio de entrada. A
tecnologia de entrada de voz no final dos anos 80 é capaz de reconhecer um vocabulário com
algumas centenas de palavras para um usuário individual; esse recurso precisa ser reensinado para
cada novo usuário. As vantagens desse meio dc entrada são óbvias; as desvantagens, no momento

Página 316 de 584
atual, são (1) o custo do dispositivo, (2) seu voca bulário limitado, (3) o longo tempo dc resposta e
(4) problemas reais se a voz do usuário se alterar significativamente por causa de um resfriado ou
por outros motivos.
Assim como o usuário tem a opção de escolher entre diversos meios diferentes de entrada para seu
sistema, existem vários meios possíveis de saída. Os meios mais comuns usados para saída são os
seguintes:
Saída impressa. A forma mais comum de saída em sistemas de processamento, hoje, é, de longe, a
saída impressa. Ela pode ser produzida em vários dispositivos: impressoras de matriz de ponto
(muitas vezes ligadas ao terminal utilizado para entrada), impressoras de linha de alta velocidade,
impressoras laser de alta velocidade, impressoras pessoais a laser, impressoras pes soais de
margarida e outras. A principal vantagem da saída im pressa é que ela é um documento
permanente, que pode ser usado em diversas aplicações externas ao sistema. As desvan tagens dos
relatórios impressos são o seu volume, a probabili dade de que serão impressas mais informações
(ou mais có pias de informações) do que é realmente necessário, e a rela tivamente baixa
velocidade com que as informações são produzidas.
• cartões perfurados. Assim como os cartões perfurados podem servir como meio de entrada,
também podem servir como meio de saída. Como já foi mencionado, OS cartões perfurados podem
ser usados como documentos legais; como Marjorie Leeson afirma ILeeson, 19811, os cartões
perfurados podem servir como um “documento de turnaround” (isto é, um documento que é
476
enviado para fora do sistema a um terminador externo e depois torna-se entrada para o sistema a
partir do mesmo terminador). Mas, de um modo geral, os cartões perfi.irados são volumosos e não
podem abrigar muita informação; e, por isso, não são usa dos na maioria dos sistemas de
informações atuais.
Terminal. Os sistemas on-line que usam terminais como meio de entrada costumam utilizá-los
também como meio de saida. A vantagem do terminal é que ele pode exibir uma quantidade
substancial de informações em alta velocidade; com terminais modernos, podemos exibir
combinações práticas de texto e gráficos. A principal desvantagem do terminal é que ele não
representa uma saida impressa; a saída é transiente e é perdida ao ser exibida a tela seguinte.
• Saída de zxz Para algumas aplicações, a voz é um meio ade quado de saída. Isso é verdadeiro em
aplicações onde o telefone é usado como um meio de entrada (veja acima); o mesmo tele fone pode
ser usado para conduzir a saída de voz para o usuá rio. Alguns terminais também são equipados
com dispositivos de saída de voz, ainda que isso seja um tanto raro. A principal vantagem da saída
de voz é que ela pode ser usada para con duzir breves mensagens de saída em um ambiente (ex.:
um dis positivo de manufatura) onde o usuário possa não ter oportuni dade de ler saídas impressas.
• Plotador. Um plotador é normalmente usado para produzir dia gramas e desenhos grandes e
intricados (p.ex., desenhos arqui tetônicos e impressos em azul). Desenhos que se acomodam em
uma página de papel de tamanho normal, podem ser habitual mente produzidos, hoje, por
impressoras laser ou impressoras de matriz de ponto, mas os plotadores, muitas vezes, produzem
saídas medindo dois ou três pés de largura por vários pés de comprimento. A desvantagem desse
meio de saída é o seu custo, seu volume físico e o tempo necessário para produzir a saída.

Página 317 de 584
• Fita ou disco magnéticos. É evidente que se a fita magnética e o disco magnético podem ser
usados para entrada, também po dem ser usados para saída. Isso normalmente só é prático nos
casos em que a saída será enviada para outros sistemas de processamento (isto é, onde o terminador
do sistema não é uma pessoa, mas um computador).
477
• COM. COM é um acrônimo para o Compuler Output Microform. A saída COM é normalmente
reservada para saída para arquivos (p.ex., grande volume de material de referência que seria muito
caro e excessivamente volumoso para ser produzido como re latórios impressos normais).
Exemplos de COM são rolos de mi crofilmes (usados, por exemplo, por bancos para conservar có
pias de cheques cancelados) ou microfichas.
21.2.2 Formatos de Eniradas/Saídas
Depois que os dispositivos dc entrada/saída foram cscoinidos, a etapa seguinte é determinar os
forma/os das entradas e saídas do siste ma. Em alguns casos, os formatos dessas entradas e saídas
podem não ser assunto de negociação, mas simplesmente o caso dc o usuário infor mar ao analista
de sistemas “como devem ser as coisas”. Isso é especial mente verdadeiro quando o novo sistema
deve comunicar-se com outros sistemas de processamento ou com pessoas (Ou grupos de pessoas)
ex ternas à organização que elabora o novo sistema. Organizações externas ou outros sistemas de
processamento podem fornecer dados para o novo sistema em um formato fisico prescrito que não
pode ser alterado. E eles podem exigir saídas do sistema cm um formato igualmente pres crito
rigidamente.
Se o diálogo homem-máquina não tiver sido inteiramente ajustado, o que existe para ser
negociado? Não a representação interna dos dados no sistema de processamento; o usuário não se
interessa e nem sequer deve ter consciência dessa informação. E não aspectos como valores e
intervalos válidos dos elementos de dados dc entrada, porque eles de vem ter sido especificados
como parte do modelo essencial. No entanto, esse é um lugar para negociar razoáveis restrições de
implementação de vários aspectos dos elementos de dados. Seguem-se alguns exemplos:
• O modelo essencial pode haver identificado o elemento de dados ÚLTIMO-NOME-DO-
CLIENTE. Sendo um assunto de in teresse essencial, pode não haver limite para o comprimento
(número de caracteres) desse elemento de dados. Afinal, o que está errado com um último nome
que por acaso tenha 357 ca racteres de comprimento? Embora isso não aconteça com freqüência,
alguns membros da aristocracia européia podem querer demonstrar suas linhagens pela inclusão
dos nomes de todos os seus ancestrais no último nome. Isso é interessante e pode ser de alguma
significância histórica, porém o usuário e o analista de sistemas podem, contudo, concordar em
restringir ÚLTIMO-NOME-DO-CLIENTE para 25 caracteres. Observe, a
478
propósito, que isso vai exigir uma alteração na(s) apropriada(s) especificação(ões) de processo que
lida(m) com a entrada do IíL11MO-NOME para garantir que seja válida, de acordo com essa
restrição dc implementação.
Em um sistema de controle dc pedidos, um PEDIDO-DE- CLIENTE pode ser definido da seguinte
maneira: PEDIDO-DE- CLIENTE - NOME + ENDEREÇO + (ITEM-PEDIDO). No mo delo
essencial pode não haver motivo para limitar o número de itens diferentes que um cliente pode

Página 318 de 584
comprar em um pedido. Da perspectiva de implementação do usuário, entretanto, pode haver
diversas razões: (1) como atividade de suporte manual (discutida mais detalhadamente na seção
21.3, o usuário pode desejar que o funcionário do setor dc vendas preencha o pedido em um
formulário prá-impresso que só tenha espaço para, diga mos, oito itens; (2) o usuário pode estar
preocupado em que o funcionário do setor dc vendas poderá cometer um engano se tentar lidar com
mais do que um número limitado de itens em cada pedido; (3) o usuário pode ficar preocupado em
que o dispêndio excessivo de tempo no atendimento a um só cliente com seus 597 diferentes itens,
possa aborrecer outros clientes que esperam para ser atendidos. E, assim por diante. Por esta razão,
pode haver alguns bons motivos para impor-se uma restrição de implementação definida pelo
usuário sobre os ele mentos de dados.
Observe que os problemas da implementação do usuário, desse tipo, envolvem observações
suplernentares no dicionário de dados e ló gica adicional (se isso for apropriado) nas especificações
de processo que tratam da validação dos elementos dc dados de entrada. Mas existe um outro
aspecto do diálogo homem-máquina que exige algo mais do que observações no dicionário de
dados: a seqüência de entradas e saídas, principalmente em um sistema on-line, pode ser
conveniente- mente modelada com a utilização do diagrama dc transições de estado. A figura 21.3
mostra um exemplo típico de um diagrama de transições de estado usado para modelar a seqüência
das telas dc vídeo que o usuário final utiliza para se comunicar com o sistema.
Isso é útil especialmente para lidar com perguntas como: “Posso retornar à tela do menu principal a
partir da tela 12?” e “Quais são os meios para atingir a tela de entrada dc pedidos”? Outros
importantes problemas de entrada/saída incluem a organização física de elementos de dados de
entrada em uma tela de vídco, a natureza das mensagens de erro quando se comete um erro de
entrada; e a organização física de elementos de dados de saída nas telas e em relatórios. Com o
imenso
479
Cancela
pedido
Introduzir Cancelar det
detalhes de pedidos
de pedidos __________
Figura 2 1.3: Um diagrama de transições de estado para a modelagem de telas de
vídeo
conjunto atual das linguagens de quarta geração, ferramentas de prototi pação e PCs, eu recomendo
que você dê ao usuário a oportunidade de divertir-se com diversas variações de telas de entrada,
imagens de saída e coisas desse tipo Uma vez obtido o consentimento do usuário, você deve
vincular uma cópia das imagens de tela, formatos de relatório e adequados diagramas de transições
de estado ao modelo essencial, com apropriadas referências cruzadas aos elementos de dados
essenciais do dicionário de dados.
É claro que em muitos casos o usuário não terá grandes sugestões para fazer porque não tem
experiência anterior em trabalhar com um sistema de processamento; isso é um tanto análogo a

Página 319 de 584
alguém que tenha morado em um apartamento durante toda a sua vida e agora deseja es pecificar
os detalhes da sua primeira casa sob encomenda em estilo de rancho. No caso dos sistemas de
informações computadorizadas, as se guintes diretrizes o ajudarão a desenvolver uma interface
humana amis tosa ao usuário na maioria dos casos.
1. Seu sistema \deve requisitar entradas e produzir saídas em uma forma c?fr Isso é particularmente
verdadeiro nos sistemas on-line em que o usuário pode introduzir uma entre diversas transações
diferentes e/ou receber uma de diversas imagens diferentes. Suponha, para exemplificar, que o seu
sis tema solicite a data ao usuário sempre que uma transação for introduzida; seria desastroso se
um tipo de transação exigir a - data na forma 12/23/87, enquanto outra transação exige a data na
forma 87/12/23. E também seria desastroso se uma parte do
480
sistema exigisse que o usuário especificasse o estado como um código de dois caracteres (p.ex., RJ
para Rio de Janeiro), en quanto outra parte do sistema exigisse que o nome do estado fosse escrito
por extenso. De forma análoga, se uma parte do sistema exigir que o usuário forneça um código de
área quando introduzir um número dc telefone, todas as partes do sistema devem exigir um código
de área quando for intro duzido um número de telefone.
2. Peça Informações em uma seqüência lógica. Em muitos casos, isso depende da natureza da
aplicação e exigirá minuciosos entendimentos com o usuário. Por exemplo, suponha que você
esteja desenvolvendo um sistema de controle de pedidos, e deseje que o usuário especifique o
nome do cliente. Se a in formação for introduzida em cartões perfurados ou (com maior
probabilidade) a partir de um terminal de vídeo, você terá de especificar a seqüência na qual deseja
que sejam introduzidos os componentes de “nome de cliente”. Uma seqüência lógica seria solicitar
ao usuário que introduzisse a informação na se guinte seqüência:
título (Sr./Sra. etc.)
primeiro nome
inicial do nome intermediário
último nome
Porém o usuário pode achar isso muito desajeitado; suponha que o usuário tenha obtido o nome do
cliente de alguma fonte externa como um catálogo de telefones. Nesse caso, seria muito mais
prático que o usuário introduzisse
último nome primeiro nome
inicial do, nome intermediário
título
A única coisa sobre a qual podemos ter certeza á que a seguinte
seqüência seria definilivamenle desaprovada pelo usuário:
inicial do nome intermediário
481
482

Página 320 de 584
primeiro nome título
último nome
3. Evidencie ao usuário o tipo de erro que cometeu e onde está. Em muitos sistemas, o usuário
fornece uma quantidade substancial de informações ao sistema para cada evento ou transação. Em
um sistema dc controle de pedidos, por exem plo, o usuário pode especificar o nome do cliente,
endereço e número do telefone, bem como informações sobre os itens que estão sendo pedidos,
desconto aplicável, instruções de em barque e imposto sobre vendas. Todas essas informações po
dem ser introduzidas em urna única tela de informações antes de serem enviadas ao sistema; e,
certamente, o sistema poderá determinar em seguida que parte da entrada está errada ou toda ela. O
importante é ter certeza de que o usuário com preenda a espécie dc erro que foi cometido e onde o
erro está localizado; não é aceitável que o sistema simplesmente emita um sinal sonoro e exiba a
mensagem MÁ ENTRADA. Cada erro (presumindo-se que haja mais de um) deve ser identificado,
ou com uma mensagem descritiva ou (no caso de um sistema on une) ressaltando ou codificando
em cores os dados errados. Dependendo da natureza do sistema e do nível de sofisticação do
usuário, pode ser também importante exibir uma men sagem explicativa; isso será discutido em
maiores detalhes no item 5.
4. Faça a distinção entre edições de campos e edições de telas. Em muitos casos, o seu sistema será
capaz de determinar se o elemento de dados fornecido pelo usuário está correto ou in correto, sem
referência a quaisquer outros elementos de dados. Por exemplo, se o usuário introduzir um código
de dois ca racteres para um estado, o sistema deverá ser capaz de de terminar, imediatamente, se os
dois caracteres representam um dos cinqüenta estados, ou uma das províncias canadenses, e assim
por diante. Mas, se o usuário tiver que introduzir um código post elemento de dados individual,
existirá somente um volume limitado de edições de campo que o siste ma poderia realizar sem
entradas adicionais; necessitaríamos do código postal e do código dc estado para determinar se o
código postal deveria ser um código de cinco (ou de 9 dígitos) ou um código postal canadense de 6
caracteres. O sistema
poderia comparar, também, o código de estado e o código de zona para ver se o código postal está
dentro do intervalo certo (p.ex., se o código de estado for NY, o código postal come çaria com o
dígito 1). O relacionamento entre os elementos de dados podem ser evidentes para o analista de
sistemas; en tretanto, isso pode exigir conhecimento íntimo e detalhado da aplicação que pode ser
obtida somente do usuário.
5. Torne a edição e a verificação de erros dependentes do usuá rio. Como já dissemos, é
normalmente uma boa idéia que o sis tema exiba uma mensagem explicativa quando for detectado
um erro. Mas isso só é verdade se o usuário não for capaz de determinar por etc mesmo o que fez
de errado. Se o usuário tiver digitado um código postal dc três dígitos, por exemplo, não deve ser
necessário que o sistema exiba uma mensagem muito elaborada sobre o comprimento dos códigos
postais; en tretanto, isso seria apropriado se o usuário digitasse um código postal de cinco dígitos e
o sistema estivesse esperando por um dos novos códigos postais dc nove dígitos. Observe também
que (a) alguns usuários são mais capacitados do que outros e podem ficar aborrecidos ainda mais
rapidamente se eles ti verem de ler mensagens de erros longas e volumosas e (b) de pois do uso
repetido, até mesmo o usuário novato tornar-se-á perito em algumas partes do sistema. Portanto é
muitas vezes importante fazer com que as mensagens de erros sejam flexíveis e talvez mesmo

Página 321 de 584
alteráveis pelo usuário; o compro misso mais fácil é urna combinação de mensagens de erro curtas
(que podem consistir em nada mais do que o realce das entradas erradas e um sinal sonoro para
atrair a atenção do usuário) e mensagens de erro longas (com texto explicativo e uma referência à
parte adequada do manual de treinamento do usuário). O item 7 apresenta mais detalhes sobre este
assunto.
6. Ofereça ao usuário um modo de (a) cancelar parte de uma transação e (b) cancelar toda uma
transação. É ingênuo pressupor que o usuário sempre terminará a introdução de uma transação
inteira sem ter interrompido. Com um sistema de processamento batch, isso não representa um
problema; o sistema normalmente não examinará qualquer coisa prove niente do usuário até que
diversas transações individuais tenham sido compostas Mas em sistemas on-line isso é um
problema importante: o usuário pode ter introduzido um no me e endereço de cliente antes de
descobrir que estava tra balhando com o cliente errado; ele desejará ser capaz de
483
484
anular o que foi digitado e começar dc novo. Ou o usuário pode haver terminado a introdução da
maior parte das infor mações do cliente e, então, perceber que escreveu mal o pri meiro nome do
cliente; ele vai querer poder retornar àquele elemento de dados e corrigi-lo sem perder todas as
outras in formações já digitadas.
7. Providencie um mecanismo prático de ‘ Nos sistemas on-line, é cada vez mais importante
oferecer ao usuário um mecanismo prático para a obtenção de informações sobre como usar o
sistema. Em alguns casos, a facilidade do “socorro” simplesmente fornecerá urna explicação se o
usuá rio cometer um erro; cm outros casos, o “socorro” poderia ser usado para explicar os detalhes
dc vários comandos ou transa ções disponíveis ao usuário. Existem muitos meios de imple mentar
essa facilidade, e você e o usuário devem examinar diversos exemplos típicos (a maioria dos
pacotes de software disponível no IBM PC e no Apple Macintosh tem facilidades de “socorro”; são
bons para iniciar) antes de tomar uma decisão.
8. Faça a distinção entre os sistemas clirigidos por menus e sistemas dirigidos por comandos; se for
adequado dê a opção ao usuário. Um sistema dirigido por menu é o que apresenta ao usuário uma
lista de escolhas alternativas (ou funções, ou transações etc.); ao escolher urna, pode ser
apresentado um Outro submenu, que poderá conduzir a submenus de níveis ainda mais baixos
antes que o sistema finalmente execute algu ma ação. Um sistema dirigido por comandos, por outro
lado, espera que o usuário apresente um detalhado (e, às vezes, muito longo) comando indicando o
que ele quer que o sistema faça. Os sistemas dirigidos por mcnus são considerados mais amistosos,
uma vez que eles exibem todas as opções dispo níveis ao usuário; por esta razão, a abordagem de
menus é muitas vezes considerada preferível para novos usuários ou quando o sistema tiver dc
interagir com uma grande variedade de usuários com diferentes experiências e níveis de habilidade.
Mas o sistema dirigido por menu é considerado tedioso pelo usuário experiente, pois ele
freqüentemente exige duas ou três interações separadas com o sistema (cada uma com algum
tempo de antes que ele finalmente saiba o que o usuário des experimentado geralmente prefere um
sistema dirigido por comandos para que ele possa executar o que deseja tão rapidamente quanto
possível.
a

Página 322 de 584
9. Se o seu sistema estiver empenhado em um processamento muito prolongado, exiba uma
mensagem para que o usu4rio não pense que o sistema caiu. Se o seu sistema tiver de exe cutar
cálculos extensos ou se ele provavelmente apresentará demoras periódicas por causa de entradas
volumosas, é importante exibir uma adequada mensagem para o usuário; caso contrário é possível
que ele imagine que o seu terminal “congelou” ou “ficou preso”, ou que o sistema “caiu”, ou que
ocorreu uma falta dc energia. O sistema deve, no mínimo, emitir uma mensagem (p.ex., SISTEMA
OPERANDO - POR FAVOR, ESPERE) em intervalos regulares. Melhor ainda seria uma série de
mensagens informando ao usuário quanto do trabalho já foi executado e aproximadamente quanto
tempo falta para completá-lo.
10. Forneça defaults para entradas padronizadas. Em muitos ca sos, o sistema pode fazer uma boa
suposição sobre o provável valor de uma entrada fornecida pelo usuário; tornando-o um default,
você pode economizar para o usuário um considerável tempo e a atividade dc digitação. Essa
abordagem é válida pa ra todos os tipos de sistemas, mas é especialmente aparente em sistemas on-
line, cm que o usuário pode não ser um digi tador profissional. Um exemplo de valor default é a
data: em muitas aplicações a data mais provável que o usuário intro duzirá é a data atual. Ou,
suponha que você esteja construindo um sistema de controle dc pedidos, e o usuário diz que 95%
dos clientes vivem nas redondezas; em seguida, quando você pedir que o usuário informe o número
do telefone do cliente, o sistema deve presumir que o código de área default é o seu código de área
local.
11. Beneficie-se das cores e do som, mas não exagere. Os moder nos terminais on-line têm diversos
efeitos de cores e som; eles podem ser bastante úteis para a enfatização de tipos diferentes de
entrada ou para atrair a atenção do usuário para aspectos importantes da interface humana. Dessa
forma, você node usar a cor verde para tudo o que for exibido pelo sisten. ul para todos os dados de
entrada fornecidos pelo usuário, e vermelho para todas as mensagens de erro. Entretanto, não se
deixe ar rebatar: a maioria dos usuários poderá não gostar se as telas ficarem parecendo árvores de
Natal. Isso também vale para efeitos sonoros; uma ocasional campainha ou hipe é útil, mas o
usuário não deseja que o terminal produza todos os efeitos sonoros do filme Guerra nas Estrelas.
485
21.2.3 O Desenho de Formulários
O desenho dos formatos de entradas e saídas dos sistemas tem tra dicionalmente sido chamado de
desenho de formulários, porque maioria dos sistemas nos anos 60 e 70 exigia que o usuário
codificasse a entradas em formulários de papel que eram depois transcritas para car tões perfurados
antes de serem introduzidas em um sistema de processa mento batch. Porém, mesmo nos sistemas
on-line de hoje, podem existii alguns desenhos de formulários a serem feitos; considere, por
exemplo a situação comum em que a entrada do sistema origina-se com um clien te externo. O
cliente pode fornecer a entrada exigida preenchendo un formulário de papel e enviando-o aos
usuários que interagem com c sistema; um exemplo de um formulário do mundo real é mostrado n
figura 21.4. Desse modo, alguma atenção deve ser dada ao desenho dc formulário.
Em alguns casos, o analista de sistemas poderá recorrer a um dc partamento doméstico de gráficos
ou a um fabricante externo de formu lários para auxiliar no desenho do formulário;
alternativamente o usuáric poderá já possuir formulários relacionados ao sistema existente que de
sejará continuar usando no novo sistema. Mas, existem também muita situações em que o analista

Página 323 de 584
de sistemas e o usuário devem desenhar urr novo formulário para um novo sistema. Embora
existam muitos estilos diferentes para um formulário, todos devem conter as seguintes infor
mações básicas:
• Título, para distinguir um formulário de quaisquer outros formu lários. O título é habitualmente
impresso cm letras grandes en negrito na parte superior do formulário para que o usuário saiba que
aquele é um “formulário de pedido” ou “um formulário dc relatório de problemas”.
• Instruções, para informar ao usuário como preencher as infor mações necessárias do formulário.
As instruções gerais são ha bitualmente colocadas no início do formulário perto da parte superior;
instruções específicas são normalmente apresentadas em seguida ou abaixo de cada item de dados
que precise ser preenchido.
• C a parte pi. pai do formulário na qual os dados são introduzidos. Este podc ser organizado cm
estilo aberto, em es:
tilo em quadros ou uma cov’ nação de ambos. O estilo em qua dros é normalmente utilizado para
informações binárias (ex.,
486
TOTAL
$6., R# doo, ool 9O6.OnIeo ,,,oohine o,m$a6ibiIity pie b soro ia sineck prodoal reqoiremenb.
Figura 21.4: Um exemplo deformulá rio
“confirme neste quadro se quiser o seu nome acrescido à nossa lista postal para futuras
informações sobre produtos”) ou de formalo fixo (ex., um número dc telefone ou código postal). O
estilo aberto costuma ser empregado para informações de com primento variável como nomes ou
endereços.
Decidir exatamente como o formulário deve ser diagramado é uma arte por si mesma e é mais bem
feita por pessoas experientes em projetos de formulários. Um dos erros mais comuns dos
projetistas novatos de for mulários, por exemplo, é não deixarem espaço adequado para o usuário
completar as informações exigidas. Isso vale especialmente em formu lários que exigem
informações manuscritas .
1 ITEMS ORDERED
G. A
II
_JI
ORDERS
800/228-8910
Good anywhere In LIS.
408/625-0465
MAILORDEAS
P0 600 911 • 00116 01077 • Mo,eecey. 04 93942 DATE OF ORDER
Sl l OESCP9P1IOÇ 2T0 UNFI POlO 50,0 157001 00FIC(

Página 324 de 584
SHIPPING/HANDLINC, CHARGE.S
BILL TO: (Plnao Pr:nt)
6626.
OTTEN1
$36940
900
1 5
6% SOLOS 003 - --
O-*
SI6PP $3
5
-- HUMO 574055
.9 StoP iaildI0.9 086290. ,00100i6l,d by 006 00 ilQo 9, de9 choro, la, 0. onde, chspp UPO G,oond
o, 11$ nnojL . add Oh, lhippiro] chaga $94 ao poro,8o,es 1 d4echy 011,000, 9002 loa 0208 0010
oldenod ood add $100 lo 1h, 10101 P,6ec6 secola. .ll.bke; ,,ii Iec sI
00656. 9. C620eOl 9 Boto,
II yea reqoone deh cabide lhe 0051)00153 000- ei Sbote.,. pi,ase add Ofle 01 lhese Sp,coal charges
lo yoor 0,01,, c 01 oron$ lhe 0501, ai 1611
Haoaa.4 ca8 lo, cha,o,s
C ach 8%. $15 nononornon.
Foreloeo 0000,0. ach 21%. $35 ,nnon$3nn
AI 99000,1110 Olilai Se ir U L doli
006: 001egn 0,11,1, sobj,cl lo FIC r,01005005 001
0 dela$
1 SHIP TO: ( diff Itian Bili To)
105500620 O 006600 ao O app,aron o, ,no,ag 19.5
NOME
COMPaPO 0 000o004l
0100155 570 00 lo, 540057
ara
s
1
zip
56059€ P006

Página 325 de 584
000€ P00000
METHOD OF PAYMENT
06 MOIOS l €N
,, 625510 O voa
Li COOOO
, P0 NUM610
LJ P 0062,00,6 0,6,1009.6 $01 ar. . 00 cr,dir 6.0,0.6
HHIIHHHII
OCCOUNI 50 (100 CIElOME CA
OITO
SIGNOTURE
487
Dependendo da aplicação, o analista dc sistemas pode desenhai formulários de corte ou formulários
especiais. Os formulários de cortc costumam ser impressos em folhas simples de papel e são
apropriado para a grande maioria de situações; com a disseminada disponibilidadc dos sistemas de
editoração de mesa e programas de desenho de formu lários, o usuário e o analista de sistemas
podem facilmente projetar seus próprios formulários.
Os formulários especiais são mais complexos e podem ser projeta dos com a assistência dc um
experiente projetista de formulários (nor malmente associado a um fabricanie de formulários), O
exemplo mais comum de formulário especial é um formulário multipartes, que pode tei folhas de
papel carbono entre as cópias de papel especial sem carbono, Os tipos mais conhecidos de
formulários especiais S
• Formulários encadernados como livros (ex., blocos de pedidos de vendas).
• Formulários com partes destacáveis, com um original e múltiplas cópias que podem ser separadas
(ex., formulários de cobrança
de cartão de crédito).
• Formulários contínuos, preenchidos manualmente ou gerados por computador.
• Postáveis: formulários pré-impressos já inseridos em um enve lope, fixados juntos como um
formulário contínuo. O computa dor pode então imprimir informações padronizadas tais como c
nome e endereço do cliente e (através do correto posicio. namento do papel carbono) a impressão
será feita no envelope e na carta que estiver em seu interior.
Os formulários especiais são, como era de se esperar, bem mais caros do que os formulários de
folha única. Assim sendo, deve-se ter cuidado em que eles não representem uma importante fonte
de custos do sistema. Os formulários especiais devem ser produzidos em quantida de razoável para
manter baixo o custo unitário: o custo de impressão de 10.000 cópias de um formulário especial é
muitas vezes apenas de 10 a
20% maior que o custo de impressão de 5.000 cópias. Deve-se utilizar formulários de tamanho
padronizado para que a impressora não tenha de executar dispendiosas atividades dc corte e ajuste;

Página 326 de 584
a maioria dos for mulários de tamanho padronizado é de 8,5 polegadas por 11 polcgada ou de 5,5
polegadas por 8,5 polegadas.
488
1.2.4 Códigos de Enirada e Saída
Como parte da tarefa de especificação de formatos de entrada e
uda, o analista de sistemas muitas vezes deve especificar códigos, isto
abreviações para informações que seriam de difícil manipulação e
)nsumidoras de tempo para serem descritas detalhadamente. Exemplos
códigos são Social Security Numbers (Números de Segurança Social), )digos postais, números de
livros publicados (ISBN) e Employer Ide nti cation Numbers (Números de Identificação de
Empregadores (EIN)) .ie o IRS atribui ás empresas que arquivam declarações de impostos.
Os exemplos acima representam códigos externos para a maioria
nós; isto é, qualquer que seja o tipo dc sistema, temos que usar os ;quemas de codificação
desenvolvidos pelo IRS, pelos Correios dos U.A., e pela Social Security Administration. Mas há
freqüentes situações ‘n que precisamos projetar novos códigos associados ao próprio siste a (ex.,
números de contas de clientes, números de fabricantes, núme )5 de formulários, códigos de
produtos, códigos de cores e números de os de linhas aéreas). Assim Como o desenho de
formulários é uma le, as técnicas de codificação também são uma área especializada de rícia; como
Gore e Stubbe mostram em IGore e Stubbe, 19831, um étodo de codificação deve ser:
• Expansível - O código deve dispor de espaço para entradas adicionais que possam ser necessárias.
• Preciso - O código deve identificar o itcm específico.
• Conciso - O código deve ser curto e ainda assim descrever adequada mente o item.
• Prático - O código deve ser fácil de ser codificado e descodificado.
• Significativo - O código deve ser útil às pessoas que lidam com ele. Se possível, deve indicar
algumas das características do item.
• Funcional - O código deve ser compatível com os métodos presentes e antecipados do
processamento de dados - manual ou à máquina.”
Em alguns casos pode não ser necessário, desejável ou prático que código tenha algum
relacionamento evidente com o item que ele des eve. Um bom exemplo é um número dc cliente,
um número de conta i um número de empregado em muitos sistemas: o código é simples- ente um
número, escolhido seqüencialmente. Entretanto, também é mum que a técnica de codificação
reserve blocos de números (ou tras) para itens que se enquadram em uma categoria comum; por
489
exemplo, um sistema de controle de pedidos poderia usar um númen de quatro dígitos como um
número de produzo, com os números de 1 500 reservados para itens comuns, e os números dc 501
a 999 reservado para itens especiais.
Ainda mais comum é o código de cIass que utiliza grupo de dígitos (ou letras) no código para
identificar classificações maiores intermediárias e menores no item que está sendo descrito. Por

Página 327 de 584
exemplo para ligar para meu escritório em Londres, eu disco os seguintes dígitos
011-44-1-637-2182
Os três primeiros dígitos identificam o número do telefone com um número internacional (em
comparação a um número chamado den tro da América do Norte). Os dois dígitos seguintes são o
código ± cidade, sendo 44 o código do Reino Unido. O dígito seguinte é o códig de área de
Londres, análogo ao código dc área de três dígitos uiilizad nos Estados Unidos. Os três dígitos
seguirnes representam um centrc telefônico e muitas vezes dará ao usuário esperto uma boa idéia
do bair ro londrino onde está localizado esse telefone. E, para finalizar, os úl timos quatro dígitos
identificam um telefone específico.
Os códigos alfabéticos também são muito usados em sistemas d informações. A maioria dos
códigos alfabéticos é uma tentativa de auxí lio mnemônico ou da memória, que o usuário será
capaz de lembrai com facilidade 10 Se a tentativa terá ou não sucesso dependerá d extensão do
código (isto é, dois caracteres contra dez caracteres), a di. versificação e a disparidade dos próprios
elementos dc dados, e a fami liarização do usuário com os elementos dc dados. Por exemplo,
conside re os códigos de duas letras usadas para identificar diferentes linhas aé reas; a maioria dos
cidadãos americanos percebe imediatamente que AA representa American Airlines e que UA
representa United Airlines. Toda via, quantos sabem que HW representa Havasu Airlines, ou que
AQ re presenta Aloha Airlines? Com códigos de três letras, temos uma chanc melhor na escolha de
códigos mnemônicos, como é demonstrado pelo5 códigos utilizados para identificar aeroportos.
Quase todos sabem que JFK representa o aeroporto John F. Kenriedy em Nova lorque e que SFC
representa o aeroporto dc São Francisco. Mas, mesmo assim há dificul dades, a menos que o
usuário tenha memorizado muitos códigos que não são mnemônicos (ex., ORD para O’Hare e
YYZ para o aeroporto de Toronto!).
Para finalizar, alguns códigos são dc au1o-venficaçãa isto é, con têm informações adicionais
(redundantes) que podem ser usadas para certificar que o código foi introduzido corretamente. Cm
conhecido exemplo de código de auto-verificação é o que contém um dígito veri ficador, que
costuma ser acrescentado ao final do código numérico.
490
) dígito verificador pode ser calculado de diversas maneiras, uma das luais é mostrada abaixo:
digito-verif - o
FOR cada digito no código numérico
soma - digito in. pelo número de sua
0 Si Ç
digito-verificador - digito-verificador + sorna
DO WHILE existir mais do que um digito em digito verif
digito-verificador soma de todos os digitos em
digito-verif
ENDDO
Por exemplo, se tivéssemos o código numérico 9876, o dígito veri icador seria calculado como (91)

Página 328 de 584
+ (82) + (73) + (64), que resulta em O. A soma dos dígitos 7 e O dará o resultado final 7 como
dígito verifica lor. O objetivo disso não é obrigar que o usuário faça todo esse cálculo, nas sim
utilizar um código que contém um dígito verificador embutido ex.: 9876-7). Em seguida, quando o
usuário introduzir o código no sis ema, o computador poderá recalcular automaticamente o dígito
verifica lor esperado (utilizando o algoritmo acima descrito) e compará-lo ao lígito verificador real.
Se houver algum erro, isso normalmente significa- á que um dos dígitos foi introduzido
erroneamente pelo usuário.
fl.3 A. IDENTIFICAÇÃO DE ATIVIDADES
COMPLEMENTARES DE SUPORTE MANUAL
No modelo essencial, presumimos a existência de uma tecnologia )erfeita - que significa, entre
outras coisas, que consideramos que nos- a tecnologia de implementação nunca falha nem comete
erros. Os isuários podem não estar dispostos a aceitar isso, e quem os pode cul )ar? Além disso, o
usuário pode decidir que certas partes do sistema Lutomatizado poderão ficar sob seu próprio
controle operativo (ex.: um
ou um minicomputador em sua área de trabalho) e ele pode ficar Lpreensivo com possíveis erros de
operação que o seu próprio pessoal )ode cometer. Lembre-se, ainda, que ele pode estar trabalhando
com lados financeiros, caso em que podem existir exigências legais (ou exi ências impostas pelos
auditores) para assegurar a integridade das en radas, saídas e dos arquivos do sistema. Na maioria
dos casos essas tividades complementares de suporte serão representadas por novos
491
processos no DFD do modelo comportamental. Um exemplo é apres tado na figura 21.5.
De um modo geral, temos que nos preocupar com a possibilida
da tecnologia defeituosa em quatro importantes áreas, como mostra
figura 21.6.
A Introdução da entrada no sislema. Se os dados de entra
forem introduzidos pelos terminais de vídeo interligados a
Figura 21.5: Uma atividade de verificação de erros de suporte manual terminal de entrada
Relatório de saidã Figura 21.6: Possíveis áreas de tecnologia defeituosa
492
computadores principais por linhas dc telecomunicação, é possível que alguma transação ou todas
elas sejam pcrdidas ou embaralhadas. O mesmo pode acontecer com quase todas as outras formas
dc enirada; por exemplo, um ou dois cartões de entrada podem ser perdidos pelo operador do
computador ou um dos discos flexíveis de um conjunto pode não ser lido para o sistema.
• A execução dos cálculos. Uma vez introduzida a entrada no sis tema, existe a remota
possibilidade dc que o próprio computa dor apresente um defeito e a possibilidade muito maior (!)
de que um erro nos programas de processamento produza um re sultado incorreto. Os erros dc
hardware do computador podem ocorrer em uma UCP individual ou na interface entre as divcrsas
UCPs na configuração do sistema.
• Armazenamento de dados por lon períodos. A maioria dos sistemas retém dados por longos

Página 329 de 584
períodos dc tempo em discos magnéticos, fitas magnéticas, discos flexíveis e congêncres. É
possível que alguns desses dados (ou todos) sejam dcstruídos por causa dc erros do hardware do
computador e/ou erros do software. Os erros de hardware podem consistir cm problemas no
próprio dispositivo dc armazcnamcnto ou problemas na co nexão entre a UCP e o dispositivo de
armazenamcnto. Os erros de software podem ocorrer nos programas dc aplicação desen volvidos
pela equipe do projeto ou no software de gerencia mento de banco dc dados do fornecedor.
A obtenção de saídas do sistema. Os potenciais problemas neste aspecto são análogos aos
prot)lemas da introdução dc entradas no sistema. Em alguns casos, a saída deve ser transmitida por
linhas de telecomunicação, muitas vezes para o mesmo terminal de vídeo utilizado para entrada.
Em outros casos, a saída é pro duzida em fitas magnéticas ou em relatórios impressos. Em to dos
os casos, é possível que as informações de saída sejam per didas ou modificadas incorretamente cm
conseqüência de erros de hardware ou de software.
O que deve ser feito em relação a essas possíveis áreas de tecno logia defeituosa Evidentemente,
isso vai depender muito (1) do nível estimado de conflabilidade do hardware e do software que
estiverem sendo utilizados, (2) da natureza da aplicação do usuário e (3) dos custos ou penalidades
associadas a entradas ou saídas defeituosas. É claro que isso exige um detalhado entendimento
entre o usuário, os analistas de
‘í93
sistemas e a equipe de implementação; eles podem resolver acrescen tar alguns dos seguintes itens
ao modelo essencial para lidar com a tec nologia defeituosa:
Entradas e/ou saídas redundantes. No caso mais extremo, po dem ser fornecidas cópias duplicadas
dc entradas proveniente de duas diferentes origens (ex.: de dois diferentes usuários en diferentes
terminais de vídco). E o sistema pode produzir saída:
duplicadas (ex.: duas cópias diferentes de um relatório de saíd impresso em diferentes
impressoras). Essa é uma hipótese inco mum, mas pode precisar ser considerada no caso de
aplicaçõe:
extremamente sensíveis.
Tecnologia de processador redundante. Os dados mantidos pclc sistema podem ser armazenados,
em duplicata, cm dois diferen tes discos ou em duas diferentes fitas magnéticas. E os cálculo
executados pelo sistema podem ser efetuados, cm duplicata em duas diferentes UCP. Em realidade,
pode ser exigida re dundância ainda maior: embora uma segunda UCP ou uma se gunda unidade dc
disco permita que o sistema continue, se primeira unidade falhar completamente, isso não reprcsent
proteção contra erros sutis. E se a UCPI e a UCP2 executaremc mesmo cálculo (cx.: o cálculo dc
juros em contas dc poupanç ou o cálculo da trajetória de um míssil para um vôo à Lua) (
produzirem respostas diferentes? Qual UCP estará correta? Nc caso mais extremo, podemos insistir
até em processadores tripli cados e armazenamento dc dados triplicados, com a maioria de cidindo
qual dos dois computadores tem a resposta certa. Mas, c se os três computadores divergirem?
Redundancia interna. Uma forma comum de lidar com tecnolo gia defeituosa é a redundância
parcial. Por exemplo, um fun cionário de banco que introduz dados sobre um depósito err um
sistema bancário on-line pode ser solicitado a fornecer c número da conta e o nome do depositante.
Embora o númerc da conta normalmente seja suficiente para identificar o registrc do cliente no

Página 330 de 584
sistema, sempre existe a possibilidade de o fun cionário do banco introduzi-lo incorretamente, ou
que c número da conta possa ser alterado por causa de um erro de telecomunicação, ou um erro no
terminal dc vídeo, ou um erro na UCP. Como alternativa, o sistema pode exigir que o fuft cionário
do banco introduza somente o número da conta, verifi cando se está correto pela exibição do nome
do cliente após o registro ter sido recuperado.
494
• Controles batch. Essa é uma técnica introduzida primeramente nos sistemas de processamento
batch de segunda geração, mas que ainda é importante cm muitos sistemas atuais. Ela exige que o
usuário mantenha um contador das transações que introduz no sistema, bem como um acumulador
de quaisquer itens de dados importantes dessas transações; em sistemas financeiros, a coisa mais
óbvia a ser totalizada seria o valor em dinheiro de cada transação. Entrementes, o sistema mantém
sua própria to talização à proporção que recebe as transações; periodicamente, o sistema e o
usuário comparam seus totais para assegurarem que nada foi perdido ou alterado. A mesma técnica
pode ser usada com as saídas: o sistema pode manter sua própria totali zação do número dc
transações que ele produziu, e isso pode ser comparado com uma totalização manual feita pelo
usuário.
• Verifica ções de seqüência. A técnica dc verificação de seqüência está relacionada ao conceito dc
controles batch. O usuário pode designar um número seqüencial ou um número de transação para
cada entrada, e o sistema pode verificar, à medida que pro cessa essas entradas, se elas estão cm
seqüência e se nenhuma transação foi perdida. De modo semelhante, o sistema pode atri buir um
número seqüencial para cada saída produzida, e o usuário pode confirmar manualmente que
nenhuma das saídas tenha sido perdida.
21.4 A ESPECIFICAÇÃO DE RESTRIÇÕES
OPERACIONAIS
No final de tudo, a equipe de implementação terá de deckiir que combinação de hardware, sistema
operacional, recursos de telecomuni cação, linguagens de programação e estratégia de projeto
implementarão melhor os requisitos. Mas, será difícil fazer isso sem o estabelecimento de algumas
restrições de operação, que o modelo essencial evita de liberadamente. Os principais problemas
são, normalmente:
• Volumes de dados. O usuário precisa especificar os volumes de transações de entrada e o tamanho
necessário dos depósitos de dados. Isso é especialmente importante se houver grandes va riações
no volume de transações (ex.: durante as horas mais tumultuadas do dia ou épocas mais
tumultuadas do ano). Assim, o usuário poderá dizer: “Normalmente processamos 2.000 pedi dos
por dia, porém, o volume salta para 4.000 pedidos ao dia durante o mês de dezembro”. Além disso,
o usuário precisa
495
estimar o aumento dos índices de transações e os requisitos d memória em relação à vida útil
estimada do sistema. Dess modo, o usuário pode dizer, “O depósito INVENTÁRIO precis; ser
capaz de manipular o movimento dc 4.000 peças diferente agora, e esperamos lidar com cerca de
6.000 peças dentro do próximos cinco anos”. De um modo geral, pode-se esperar qu o volume de
dados armazenados por um sistema de informa ções cresça de aproximadamente 10% ao ano ‘

Página 331 de 584
Tempo de resposta para várias entradas. Pode ser estahclecid em termos absolutos, mas é
estabelecido de modo mais realist como uma probabilidade: “90% dc todas as transações deven ter
tempo de resposta inferior a 2 segundos”. Em alguns casos pode ser especificado em termos dc
limites: “0 relatório XY2 deve ser produzido antes das 8:00 horas (AM) dc todas a manhãs”, ou
todas as transações dc depósitos devem ser proces sadas à meia-noite para que os clientes possam
saber seu saldc atual a partir de seus respectivos sistemas bancários.
• Restrições políticas em opções de implementação. o usuário po. de, por motivos racionais ou
irracionais, especificar a marca dc hardware a ser usado (ou a marca de hardware a ser evitada), a
linguagem de programação a ser utilizada (“a programação de verá ser feita em Ada”), o
fornecedor do equipamento de tele comunicação que será utilizado, e assim por diante. Isso deve
ser evitado sempre que possível, mas você deve esperar pelo menos algumas pressões dessa
espécie. Observe que é mais provável que as restrições dc implementação sejam impostas pelo
departamento dc operações da organização; isto é, você provavelmente ouvirá coisas como, “Bem,
esse novo sistema parece muito bom, mas naturalmente deverá ser processado no computador da
empresa. Portanto, certifique-se que ele não ocupe mais do que 8 mcgahytcs; alocaremos um p de
discos para você”.
• Restrições ambientais. Temperatu ra, umidade, interferência elétrica (RFI), consumo dc força,
limitações de peso, tamanho ou emissões elétricas, vibração, poluição, ruído, radiação e outras
restrições amhicntais podem ser impostas pelo usuário à equipe de implementação. Algumas vezes
o usuário não aborda rá explicitamente a questão; ele apenas partirá do princípio. que o novo
sistema funcionará satisfatoriamente no seu am biente normal (ex.: em refinarias de pctróleo, em
fábricas, ou em um ambiente aberto de escritório). Desse modo, pode ser
496
necessário documentar os recursos relevantes do ambiente do usuário para facilitar o trabalho da
equipe de implementação. Você pode preferir simplesmente indicar no modelo de imple mentação
do usuário que o sistema deve operar no ambiente do usuário, e deixar que a equipe de
implemenaçào descubra por si mesma o que isso significa.
Resinções de se e conJ?abilidade. O usuário pode es peciflcar o tempo médio entre falhas (MT e o
tempo médio entre paradas para manutenção (MTTR), do sistema. A confia bilidade exigida do
sistema também pode ser expressa em ter mos de disponibilidade; por exemplo, o usuário pode
dizer, “Não podemos admitir nada abaixo de 99.5% de disponibilidade do sistema.”
Restrições de se O usuário pode especificar uma va riedade de restrições com a intenção de
minimizar o uso não autorizado do sistema. Isso pode incluir números de contas e senhas (os
usuários terão de identificar-se). Também pode in cluir mecanismos para impedir acesso não
autorizado a dados confidenciais; alguns usuários podem ter permissão para ler registros em
diversos depósitos, enquanto outros usuários po dem ter permissão para modificar (ou eliminar)
dados existen tes, e ainda outros podem ter permissão para acrescentar no vos registros. E o usuário
pode exigir mecanismos para impedir que usuários não autorizados executem cerl2s funções do sis
tema (ex.: nem todos devem ser capazes de executar o sistema de pagamento). Várias medidas dc
segurança podem ser im postas sobre os dados que entram e saem do sistema; isso pode incluir, por
exemplo, a codificação de dados transmitidos por li nhas de telecomunicação 12 E, para fins de
segurança, o sistema pode ser obrigado a produzir uma Usta de audiloria: uma lis tagem completa

Página 332 de 584
de todas as transações introduzidas no sistema, todas as saídas produzidas e talvez mesmo um
registro de todas as alterações feitas nos arquivos do sistema.
21.5 RESUMO
O modelo de implementação do usuário é muitas vezes descrito como a “zona sombria” entre a
análise estruturada e o projeto estrutura do. Ele não pode ser feito apenas pelo analista de sistemas,
e é arriscado para o analista e para o usuário desenvolverem o modelo de implemen tação do
usuário sem a participação dos projetistas e programadores que
497
construirão o sistema. Embora as funções, os dados e o comportamentc tempo-dependente sejam,
cm última análise, as características mais im portantes de um sistema de informação, a intcrface
humana é muitas ve zes a área que provoca as reações mais emocionais do usuário. Formatos
complicados de entrada, mensagens dc erro confusas e tempo pro longado de resposta podem
tornar mesmo as funções mais elegantes do sistema inaceitáveis para o usuário. Também deve ser
lembrado que as restrições de implementação impostas pelo usuário (habitualmente de forma
inocente) podem destruir até o mais bem gerenciado projeto:
simplesmente pode não ser possível implementar o sistema dentro das restrições do usuário.
Quando o modelo de implementação do usuário iiver sido cons truído e revisto pelos usuários,
pelos analistas dc sistemas e pelo grupo projetista/programador, a tarefa dc análise dc sistemas
estará terminada. Nesse ponto, costuma ser necessário apresentar à direção os resultados de toda a
fase de análise de sistemas do projeto para que se obtenha aprovação para prosseguir com o projeto
e a implementação do sistema. A apresentação deve incluir as seguintes informações:
1. A situação atual do sistema existente (presumindo-se que exista).
2. Problemas (fragilidades, funções ausentes etc.) que foram identi ficados no sistema atual durante
o levantamento inicial ou es tudo de viabilidade.
3. Soluções alternativas que foram identificadas.
4. Uma visão geral do modelo essencial e do modelo de imple mentação do usuário, com tantos
detalhes quantos a gerência deseje ver. Normalmente, apresenta-se o modelo de DFD de alto nível
e os componentes detalhados do modelo são tornados dis poníveis à direção para subsequcn Les
consultas.
5. Custos e benefícios projetados do novo sistema
6. Estimativas de custos, cronogramas e recursos (horas de traba lho) para as fases restantes do
projeto.
7. Recomendações da equipe do projeto ou do analista de sistemas.
Admitindo-se que a aprovação da direção esteja próxima, o projeto
está apenas começando: existe ainda um grande volume de trabalho de
498
projeto, programação e testes a ser feito antes que o usuário finalmente receba o sistema desejado.
Essas áreas serão estudadas nos próximos capítulos.

Página 333 de 584
REFERÊNCIAS
1. Marjorie Leeson, Systems Analysis and Design Chicago: Science Research Associates, 1981.
2. Tom Gibb e Gerald Weinberg, Humanized Input. Cambridge, Mass.: Winthrop Publishers, 1977.
3. James Martin, Design of Man-machine Dialogues. Englewood Cliffs, N.J.: Prentice-Hall, 1973.
4. Marvin Gore e John Stubbe, Elements of Systems Analysis, 3a ed. Dubuque, Iowa: William C.
Brown Co., 1983.
5. Data Processing Techniques: Coding Methods, Form GF2O-8093. White Plains, N.Y.: IBM
Technical Publications Department.
1. Quais são as três principais coisas que o modelo essencial de um sistema descreve?
2. Por que o modelo essencial habitualmente não representa infor mação suficiente para os
projetistas de sistemas e programadores
para que seja iniciada a implementação do sistema?
3. Que informações adicionais precisam ser acrescentadas ao modelo essencial?
4. O que é um modelo de implementação do usuário? Quais são seus principais componentes?
5. Quais ão os dois principais problemas de implementação que sensibilizam fortemente os
usuários em relação a um projeto de in formação de sistemas?
6. Dê uma definição de fronteiras de automatização de um sistema. Que outros termos ou
sinônimos podem ser usados em lugar de
fronteira de automatização?
7. Por que os usuários muitas vezes têm importantes opiniões sobre o formato de entradas e saídas
de um sistema de informação?
8. Dê quatro exemplos de problemas de formatação (envolvendo en tradas, saídas ou as duas
coisas) que um usuário pode querer es pecilicar como parte do seu modelo de implementação.
9. Dê três exemplos de problemas de formatação associados a siste mas on-line, que um usuário
pode querer especificar como parte
do seu modelo de implementação.
499
10. Como o advento dos computadores pessoais afetou o trabalho que o analista de sistemas deve
fazer para desenvolver o modelo de implementação do usuário?
11 Dê três exemplos de perguntas que precisarão ser respondidas no
modelo de implementação do usuário se os PCs controlados por
usuários fizerem parte da implementação do sistema.
12. Como o advento das linguagens de programação de quarta gera ção em muitas organizações
afeta o trabalho que o analista de sistemas deve fazer para desenvolver o modelo de implementação
do usuário?

Página 334 de 584
13. Como o conceito de pmlolipação afeta o desenvolvimento do mo delo de implementação do
usuário em um típico projeto de desen volvimento de sistemas?
14. Como a possível compra dc um pacote de software de um forne cedor afeta o desenvolvimento
do modelo de implementação do
usuário em um típico projeto dc desenvolvimento de sistemas?
15. Que erro muitas organizações cometem no desenvolvimento de um modelo essencial em
situações em que esperam utilizar um
pacote de software de um fornecedor?
16. Quais são os três casos extremos que podem ocorrer quando as fronteiras da automatização são
determinadas para um sistema de
informações?
17. Sob que condições o usuário provavelmente não terá opinião sobre onde deverá ficar a fronteira
da automatização no projeto de de senvolvimento de um sistema? Qual é a probabilidade da
ocorrên cia disso em uma organização típica?
18. Sob que condições o usuário tende a optar por um sistema total mente automati;.ado quando a
fronteira da automatização está sendo determinada, com todas as funções executadas por compu
tadores e todos os dados armazenados de forma computadorizada?
19. Sob que condições o usuário tende a optar por um sistema total mente manual quando a
fronteira da automatização está sendo de terminada? Você acha isso provável?
20. Quantas fronteiras alternativas de automalização você acha que a equipe de projeto deve
examinar com OS usuários antes da defini ção final? Apresente uma justificativa para a sua
resposta.
21. Do ponto de vista do analista dc sistemas, qual é a coisa mais sim ples que pode ocorrer aos
processos e dados que foram deixados
fora da fronteira de automatização quando esta foi estabelecida?
22. Qual é a coisa mais provável que o analista deverá fazer com os processos manuais e com os
dados manuais depois da definição d
fronteira da automatização?
23. Quais são os três principais problemas que precisam ser tratados ao
500
se definir a fronteira de automatização no modelo de implementa
ção do usuário?
4. Onde o analista de sistemas deve documentar os detalhes da maio
ria dos problemas relativos à fronteira da automatização que foram
discutidos com o usuário?
5. Apresente dois exemplos de restrições de implementação de um
elemento de dados que possa ser definido como parte da fronteira

Página 335 de 584
de automatização.
6. Como o diagrama de transições de estado pode ser efetivamente
utilizado durante o desenvolvimento do modelo de implementação
do usuário?
7. Que tipo de atividades dc suporte manual pode precisar ser espe
cificado durante o desenvolvimento do modelo de implementação
do usuário?
8. Quais são os cinco principais tipos dc restrições operacionais de
um sistema que costumam precisar ser especificados no modelo de
implementação do usuárío?
9. Por que é importante especificar no modelo dc implementação do
usuário o volume de dados que o sistema deve manipular?
0. Apresente três exemplos de restrições políticas que podem ser
impostas a um sistema como parte do modelo de implementação
do usuário.
1. O sistema de caixa automático de seu banco é dirigido por menus
ou por comandos? Quais são as vantagens e as desvantagens da
técnica adotada pelo Sistema?
SOTAS
1 Isso ilustra a necessidade dc uma boa comunicação entre os usuá
rios e a equipe de implementação, bem como com os analistas de
sistemas. Embora os usuários possam estar muito interessados no
emprego de linguagens dc quarta geração, a equipe dc implemen
tação pode precisar investigar o desempenho da linguagem. Os
sistemas com grandes volumes dc entrada e saída podem descobrir
que as linguagens de quarta geração são demasiadamente inefi
cientes. Isso será analisado mais detalhadamente no capítulo 23.
2 Uma suposição muito importante está sendo feita aqui; o modelo
essencial deve ser desenvolvido primeiro, antes que o pacote do
fornecedor seja avaliado. Muitas organizações fazem justamente o
inverso: elas primeiro avaliam o pacote e, depois, tentam obter um
modelo dos requisitos essenciais dos recursos do pacote.
3 Os procedimentos do usuário para os processos manuais podem
basear-se na especificação daqueles processos. De fato, no caso

Página 336 de 584
501
mais simples, a especificação do processo é o procedimento d
usuário; entretanto, como as especificações do processo forar
cuidadosamente redigidas para evitar qualquer tendência de impk
mentação desnecessária, elas podem precisar. ser expandidas o
rcescritas para prover orientação aos usuários.
4 Pense por um momento sobre os tipos dc problemas que poder
ser criados pela simples colocação dc um terminal na mesa d
usuário. Primeiro, pode não haver espaço para ele: o usuário pod
precisar de todo o espaço dc trabalho disponível para outras coisa
que faça. Segundo, pode não haver suficientes tomadas elétrica
para ligar o terminal de vídeo, a impressora, o modem e a parafei
nália restante. Terceiro, a mesa pode ter altura correta para leitura
escrita, mas, talvez, não para digitação. Quarto, a iluminação d
escritório pode causar tanta claridade que torne difícil ler as infor
mações na tela do terminal. Quinto, o ruído causado pela digitaçã
do usuário no terminal pode desagradar os outros usuários d
mesma área.
5 Observe que estamos discutindo entradas fornecidas pelo usuário
Muitos sistemas (especialmente sistemas dc tempo-real) devem ne
gociar com dispositivos que forneçam entradas sem interferênci;
humana (p.ex., rãdar, gravadores de dados e sinais dc satélite).
6 Observe que estamos fazendo distinção aqui entre o uso do apare
lho telefônico (o aparelho propriamente dito) e a linha de tele
comunicações. Muitos terminais são interligados, através dc urr
modem, a uma linha telefônica; mas aqui estamos falando sobre c
aparelho telefônico como meio dc entrada.
7 Na realidade, você também pode precisar usar ferramentas de IA
de quinta geração, para fazer experiências com entradas cm lingua
gem material, entrada de voz, saída de gráficos e assim por diante.
8 Porém, mesmo em um sistema batch, o usuário pode achar que
introduziu alguns dados no sistema por engano. É quase sempre
necessário suprir o usuário com a facilidade de desfazer ou reverter
o que quer que tenha introduzido. Mas isso deveria ter sido desco

Página 337 de 584
berto durante suas entrevistas com o usuário, e já deveria ser evi
dente no DFD e nas especificações de processos para o sistema.
9 Deixe, pelo menos, meia polegada de espaço vertical para cada
linha de informação manuscrita em um formulário. Deixe pelo
menos 1/3 de polegada e alguns múltiplos de 1/6 de polegada para
cada linha de informação datilografada em um formulário. Certifi
que-se de que o datil6grafo não tenha de realinhar a máquina de
escrever para cada linha de informação.
10 Alguns outros esquemas de codificação alfabética parecem ser exa
tamente opostos aos mnemônicos; são os códigos derivados de um
ou mais dos atributos do elemento dc dado. Um exemplo disso é o
502
código encontrado no rótulo postal dc muitas revistas; o código do assinante costuma ser composto
por uma parte do último nome do assinante, seu endereço, código postal, data da expiração da as
sinatura e outros detalhes, não sendo, portanto, muito mnemônico:
não há como alguém possa memorizar um código que muitas ve zes atinge 20 ou 30 caracteres dc
comprimento. Entretanto, depois que o código é introduzido no sistema, o registro do assinante po
de ser recuperado com muita rapidez, o que pode ser muito im portante em um banco de dados de
assinantes com alguns milhões de registros. Mais informações sobre esses códigos derivados po
dem ser encontrados no IBM Form GF2O-8093, Data Processing Techníques. Coding Metbods.
11 Essa estimativa é baseada em um levantamento feito em aproxima damente 500 instalações de
computadores nos EUA, documentada por Lientz e Swanson em Software Maintenance
Management (Reading, Mass.: Addison-Wesley, 1980).
12 A segurança do computador é um importante aspeclo por si mesma e não é discutida em
detalhes neste livro. Para maiores in formações, consulte livros sobre segurança dc computadores e
crimes em computadores; além disso, estabeleça entendimentos com o Computer Security Institute
(Instituto de Segurança de Computadores).
13 Os cálculos de custo/beneficio serão discutidos no apêndice C.
503
1
22
A FASE
DE PROJETO
For dose desígns and crooked counseis fli,
Sagacious, bold, and turbuieni of wil,
Restiess, unfix’d in principies and place,

Página 338 de 584
in power unpleas’d, impatien: of dtsgrace
A fiery soul, which working oul zi way,
Fretted lhe pygmy-body lo decay....
John Dryden, Absalorn and Achitophel, 1680
1. Os três níveis do projeto de sistemas.
2. Os três principais critérios de avaliação do projeto de um sistema.
3. Como desenhar um diagrama estrutural.
4. Como utilizar o acoplamento e a coesão para avaliar um projeto.
Quando o modelo de implementação do usuário está pronto, a tarefa do analista de sistemas está
oficialmente terminada. Tudo que estiver além desse ponto passa a ser uma questão de
implementação. A parte visível desse trabalho são a programação e os testes, que discutire mos no
capítulo 23. A programação, todavia, deve ser precedida por uma atividade de nível mais elevado:
o pmj elo.
Como analista de sistemas, você pode não perceber que está in teressado nos detalhes de projeto de
sistemas ou de projeto de progra mas; entretanto, como vimos no capítulo anterior, as tarefas do
analista
507
de sistemas e do projetista não podem estar sempre separadas. Principal mente na área do modelo
de implementação do usuário, o analista dev certificar-se de que conhece os requisitos do usuário,
enquanto o proje. tista deve garantir que esses requisitos sejam corretamente implementa. dos com
a atual tecnologia existente. Dessa maneira, é importante que você tenha algum conhecimento do
processo que o projetista executar quando sua tarefa estiver terminada.
Existe mais um motivo para que você se interesse pelo projeto dc sistemas: pode acontecer de você
ter de fazer o serviço! Principalmente nos sistemas de pequeno e médio porte, é normal a mesma
pessoa do cumentar os requisitos do usuário e desenvolver o projeto. Assim, você pode ter de
decidir a melhor maneira de mapear o modelo dos requisitos do usuário em uma configuração de
várias UCP; você pode ter de decidir que o modelo de dados lógicos (documentado com os DER)
pode ser implementado melhor com um sistema de gerenciamenlo de banco de dados e ter de
decidir como as funções do sistema devem ser alocadas a diferentes tarefas em cada processador.
Não é propósito deste livro discutir as atividades do projeto de sistemas com muitos detalhes; isso
é mais bem feito em livros dedicados ao assunto, como [ 19881, EYourdon e Constantine, 19891, [
e Meilor, 1985], [ 1975], [ 1977] e outros. Contudo, examinaremos rapidamente os principais
estágios de projeto e alguns dos mais importantes objetivos que o projetista de sistemas deve tentar
alcançar. Como o projeto de sistemas e o projeto de programas são as suntos separados, você deve
consultar as referências ao final deste capítulo no caso de precisar de maiores informações.
22.1 OS ESTÁGIOS DO PROJETO
A atividade de projeto inclui o desenvolvimento de diversos mode los, quase do mesmo modo
como o analista de sistemas desenvolve modelos durante a fase de análise de sistemas. Os modelos

Página 339 de 584
de projeto e seu relacionamento com os modelos da análise de sistemas discutidos neste livro são
mostrados na figura 22.1.
Os modelos mais importantes para o projetista são o modelo de implementação de sL e o modelo
de implementação de pmg rama. O modelo de implementação de sistema subdivide-se em um
modelo de processador e um modelo de tarefa.
22.1.1 O Modelo de Processador
A primeira tarefa que o projetista enfrenta é decidir como o modelo
essencial (ou, para ser mais exato, a parte automaiizada do modelo de
508
Figura 22.1: Modelos de análise e modelos de projeto
509
ODELO ESSENCIAL
Incorpora diversos dei essenciais de dados
‘ DE NÍVEL DE PROCESSADOR
NÍVEL DE TAREFA
MODELO DE NÍVEL DE PROGRAMA
implementação do usuário) será alocado às principais peças de hardware e à tecnologia de software
de sistemas. Em nível de modelo de processa dor, o projetista de sistemas tenta decidir
principalmente como o mode lo essencial deverá ser alocado aos diferentes processadores (UCP) e
como esses processadores se intercomunicarão. Costumam existir várias opções:
• Todo o modelo essencial pode ser alocado a um só processador. Isso costuma ser chamado de
solução mainframe.
• Cada bolha no DFD figura O do modelo essencial pode ser aio- cada a uma diferente UCP
(tipicamente um mmi ou microcom putador)’. Isso costuma ser chamado de solução distribuída.
• Pode ser escolhida uma combinação de mainframes, minis e micros para minimizar custos,
maximizar a confiabilidade ou
alcançar algum outro objetivo.
Assim como os pmcessos podem ser designados para componen tes de hardware adequados, os
depósitos de dados podem também ser alocados. Desse modo, o projetista deve decidir se um
depósito será im plementado como um banco de dados no processador 1 ou no pro cessador 2.
Como a maioria dos depósitos é compartilhada por muitos processos, o projetista talvez tenha de
decidir também se será necessário designar cópias duplicadas de depósitos para processadores
diferentes. A atividade de alocar processos e depósitos para os processadores é mostrada na figura
22.2.
Observe que qualquer coisa além de uma implementação de pro cessador-único envolverá algum
mecanismo de comunicação entre pro cessadores; o que tradicionalmente é mostrado como fluxos
de dados deve agora ser especificado em termos físicos. Algumas das opções dis poníveis ao
projetista de sistemas em termos de comunicação processa dor-processador São:

Página 340 de 584
• Conexão direta entre os processadores. Isso pode ser implemen tado pela interligação dos
processadores por um cabo, ou por um canal ou por uma rede local. Esse tipo de comunicação
costuma possibilitar a transmissão de dados de um processador para outro a velocidades que
variam de 50.000 bits por segundo (às vezes abreviado como 50 KB) a vários milhões de bits por
segundo.
• Um elo de telecomunicações entre os processadores. Isso é al go bastante comum quando os
processadores são fisicamente
510
Figura 22.2: Alocação de processos e depósitos a processadores
separados por mais do que poucas dezenas de metros. Depen dendo da natureza do elo de
telecomunicações, os dados serão normalmente transmitidos entre os processadores a velocidades
entre 300 bits por segundo e 50.000 bits por segundo.
Um elo indireto entre os processadores. Os dados podem ser es critos em fitas magnéticas, discos
flexíveis, cartões perfurados ou em algum outro meio em um processador e em seguida levados a
outro processador para serem usados como entrada.
O último (por vezes chamado de ‘interface disfarçada») é um caso um tanto extremo, mas ilustra
um aspecto importante: a comunicação pro cessador-processador é normalmente muito mais lenta
que a comunica ção entre processos (bolhas) no mesmo processador. Por causa disso, o projetista
de sistemas habitualmente tenta agrupar processos e depósitos que tenham alto grau de
comunicação no mesmo processador. Vários fatores devem ser levados em conta pelo projetista de
sistemas ao fazer essas alocações. Normalmente, os principais problemas são:
511
• Custo. Dependendo da natureza do sistema, a implernentaçãc de processador-único pode ou não
ser a mais barata. Para algu mas aplicações, um grupo de microcomputadores de baixe preço pode
ser a solução mais econômica; para outras, a imple mentação no computador de grande porte da
empresa pode ser a mais prática e econômica 2
• Eficiência. O projetista de sistemas normalmente se preocupa com o tempo de resposta para
sistemas on-line e com o tempo de retorno para os sistemas de processamento em lotes. Assim, o
projetista deve escolher processadores e dispositivos de armaze namento de dados que sejam
suficientemente rápidos e podero sos para satisfazer os requisitos de desempenho especificados no
modelo de implementação do usuário. Em alguns casos, o projetista pode escolher uma
implementação de múltiplos processadores de modo a que diferentes partes do sistema pos sam ser
executadas em paralelo, acelerando, dessa forma, o tempo geral de resposta do sistema. Ao mesmo
tempo, o proje tista deve se preocupar com a ineficiência da comunicação processador-processador,
como já foi discutido.
Para exemplificar, suponhamos que o projetista veja que o sistema contém uma função de edição e
uma função de pro cesso, como mostrado na figura 22.3. Colocando cada função em um
processador separado, o projetista sabe que o sistema poderá editar uma transação enquanto
simultaneamente executa o processamento de outra transação, presumivelmente me lhorando a
eficiência geral do sistema. Por outro lado, as transações editadas terão de ser remetidas de uma
UCP para a outra; isso pode ser muito eficiente se puder ser feito através de uma conexão direta de

Página 341 de 584
hardware, ou muito ineficiente, se a comunicação se processar por meio de vagarosas linhas de
telecomunicação.
• Segurança. O usuário final pode ter requisitos de segurança que determinem a instalação de
alguns (ou de todos) processadores e/ou dados importantes em localizações protegidas. Os requisi
tos de segurança também podem determinar a natureza da (ou a ausência) comunicação
processador-processador; por exemplo, o projetista pode ser obstado de transmitir dados de um
proces sador para outro por linhas telefônicas comuns no caso de as- informações serem
confidenciais.
512
Figura 2 2.3: Comunicação processador-processador
• Confiabilic4ade. O usuário final normalmente especifica requisi tos de confiabilidade para um
novo sistema; esses requisitos podem ser expressos em termos de intervalo de tempo entre falhas
(mean time between failure - MTBF) ou intervalo de tempo entre reparos (mean time to repair -
MTI’R) ou de dis ponibilidade do sistema . Em qualquer ciso, isso pode ter in fluência decisiva no
tipo de configuração do processador escolhido pelo projetista: ele pode decidir separar os processos
do sistema em diversos processadores diferentes de modo a que alguma parte do sistema se
mantenha disponível ainda que outras partes estejam inoperantes face a uma falha de hardware.
Como alternativa, o projetista pode decidir implementar cópias redundantes de processos e/ou
dados em múltiplos processa dores, talvez até com processadores de reserva que possam entrar em
ação no caso de alguma falha. Isso é mostrado na figura 22.4; mesmo que a UCP falhe (o que é
mais provável, por ser um complexo computador de grande porte), as UCP indivi duais de edição
podem continuar operacionais - coletando, editando e armazenando transações para posterior
processa mento. De forma análoga, se alguma das UCP apresentar proble mas, as outras
possivelmente continuarão funcionando.
• Restriçõe políticas e operacionais. A configuração de hardware também pode ser influenciada
pelas restrições políticas dire tamente impostas pelo usuário final, pelas pessoas de outros níveis de
chefia da organização ou pelo departamento de ope rações responsável pela manutenção e operação
de .todos os sistemas de processamento. Isso pode levar a uma específica
513
transação
resposta
DC Cn
.0
o,
CD
(1)
CD
o DC
o DC

Página 342 de 584
Cfl
Figura 22.4: Múltiplos processadores visando a confia bilídade
escolha de configuração de hardware, ou pode obstar a escolha de certos fornecedores. De forma
análoga, as restrições ambien tais (temperatura, umidade, exposição a radiação, poeira/sujeira,
vibrações) podem ser impostas ao projetista, tendo forte in fluência na configuração do processador
que ele ou ela escolherá.
22.1.2 O Modelo de Tarefa
Depois de alocar processos e depósitos a processadores, o projetis ta deve, usando um método de
processador por processador, designar processos e depósitos de dados a tarefas individuais em cada
processa dor. A noção de tarefa é comum a virtualmente todas as marcas de hard ware, embora a
terminologia possa divergir de fornecedor para fornece dor: alguns utilizam a expressão partição,
enquanto outros preferem usar as expressões job step, overlay ou ponto de controle. Sem
considerar os nomes, a figura 22.5 mostra como um processador típico divide sua área de
armazenamento disponível em áreas separadas, cada uma gerencia da por um sistema operacional
central, O projetista de sistemas nor malmente tem de aceitar o sistema operacional do fornecedor
(embora possa escolher entre vários sistemas operacionais diferentes para um determinado
computador), mas o projetista tem a liberdade de decidir quais partes do modelo essencial
designado para aquele processador devem ser alocadas a tarefas individuais dentro do processador.
Observe que os processos em um mesmo processador podem
precisar se comunicar através de alguma forma de protocolo de
514
resposta
comunicação intertarefas. O mecanismo que se ocupa disso varia de for necedor para fornecedor,
mas é quase universalmente verdadeiro que a comunicação ocorre através do sistema operacional
do fornecedor, como ilustrado pela figura 22.6. Assim como a transmissão de dados de um
processador para outro processador é relativamente lenta e ineficiente, a comunicação de dados (ou
sinais de controle) de uma tarefa para outra tarefa no mesmo processador também é ineficiente. A
comunicação entre processos na mesma tarefa costuma ser muito mais eficiente. Assim sendo, o
projetista de sistemas normalmente tentará conservar na mesma tarefa os processos que tenham
grande volume de comunicações.
Em um processador individual nem sempre é evidente se as ativi dades ocorrem sincronizadamente
ou não; isto é, nem sempre é evidente se apenas uma coisa pode acontecer em um determinado
instante ou se múltiplas coisas. No caso típico, cada processador individual tem apenas uma UCP,
que só pode executar instruções para um processo de cada vez. Entretanto, se um processo estiver
esperando por alguma entrada ou saída de um dispositivo de armazenamento (disco, fita, terminal
de vídeo etc.), o sistema operacional do processador pode passar o con trole para outra tarefa.
Desse modo, o projetista de sistemas muitas ve zes pode simular que cada tarefa seja uma atividade
independente e assíncrona.
22.1.3 O Modelo de Implementação de Pro,g rama
Por fim, atingimos o nível dc tarefa individual; nesse ponto, o pro jetista de sistemas já preparou

Página 343 de 584
dois níveis de alocação dc processos e
SISTEMA OPERACIONAL
IAKtI-A 1
1 AKbI-A 2
1 ANLI-A
Figura 22.5; A organização de tarefas em um processador
515
III,!
liii I
armazenamento de dados. Em uma tarefa individual, o computado funciona na modalidade
assíncrona; só pode ocorrer uma atividade & cada vez. O modelo mais utilizado para organizar a
atividade com um só unidade sincronizada é o diagrama estrutural, que mostra a orga nização
hierárquica dos módulos de uma tarefa. Os principais com ponentes de um diagrama estrutural são
apresentados na figura 22.7.
A leitura dessa pequena estrutura deve ser feita da seguint
maneira:
notação de módulo
notação de chamada
(ca11) de um módulo
SISTEMA OPERACIONAL
Figura 22.6: Comunicação entre tarefas com um processador
4-módulo decha
notação de parâmetros de entrada sendo passados para o módulo chamado
de chamada
- o módulo ch
Figura 2 2.7: Componentes de um diagrama estrutural
516
• O módulo A é o módulo executivo mais elevado do sistema composto pelos módulos A e B. O
motivo pelo qual A é identi ficado como o módulo superior (superordenado) não é porque esteja
topologicamente situado acima do módulo B, e sim porque não é chamado por qualquer módulo, O
módulo B, por outro lado, é dito ser subordinado ao módulo A (presume-se que o módulo A seja
chamado pelo sistema operacional do computador).
• O módulo A contém uma ou mais instruções executáveis, in cluindo uma chamada ao módulo B.
Essa chamada pode ser im plementada por um comando CALL em linguagens como FOR TRAN;
ou um comando PERFORM ou CALL USING em COBOL; ou simplesmente pela chamada do
nome de B em outras lingua gens. O diagrama estrutural evita deliberadamente indicar quan tas
vezes o módulo A realmente chama o módulo B; isso vai de pender da lógica interna de programa

Página 344 de 584
no módulo A. Desse modo, pode haver no módulo A um comando como este:
‘ guerra-nuclear-correçar
CALL Módulo-E
em cujo caso o módulo B jamais será chamado. Mas também poderia existir um comando de
programa no módulo A do se guinte tipo:
DO WBILE existirem pedidos no arquivo PEDIDOS
CALL Módulo-B
DO
em cujo caso o módulo B poderia ser chamado milhares de
vezes.
• Quando o módulo B é chamado, a execução do módulo A é sus pensa. O módulo B começa a ser
executado a partir de sua primeira instrução executável e quando termina, sai ou retorna para o
módulo A, que reenceta sua execução a partir do ponto em que havia parado.
• O módulo A pode ou não passar parâmetros de entrada para o módulo B como parte de sua
chamada e o módulo B pode
retornar ou não parâmetros de saída ao restituir o controle para
517
o módulo A. No exemplo mostrado na figura 22.7, o módulo passa os parâmetros X e Y para o
módulo B, e este retorna o parâmetros P e Q. As definições detalhadas de X, Y, P e ( seriam
normalmente encontradas no dicionário de dados. mecânica real de transmissão de parâmetros
variam de uma lir guagem de programação para outra.
A figura 22.8 mostra um exemplo de um completo diagrama estru tural. Observe que ele contém
quatro níveis de módulos; isso normal mente representaria um programa de cerca de 500 a 1000
instmçõe presumindo-se que cada módulo represente de 50 a 100 instruções di programa ¶
Existe uma óbvia pergunta neste ponto: como o projetista de siste mas transforma um modelo de
processos em rede de um diagrama d4 fluxo de dados no modelo sincronizado representado por um
diagram estrutural? Alguns livros sobre projeto de sistemas, incluindo lPage-Jone 1988] e [ e
Constantine, 1989], discutem detalhadamente ess questão. Como a figura 22.9 mostra, existe uma
estratégia para transfor mar o modelo de rede de fluxo de dados em um modelo de diagram
estrutural sincronizado; na realidade, a estratégia é em geral conhecid como projeto centralizado na
transformação. O projeto centralizado ru transformação é apenas uma das diversas estratégias para
converte um modelo de rede de fluxo de dados em um modelo hierárquico sin
Figura 22.8: Um exemplo de diagrama estrutural
518
Diagrama estrutural derivado.
Figura 22.9: Estratégia de projeto centralizado na transformação
:ronizado; [ 1988], LYourdon e Constantine, 1989] e [ e v1ellor, 1985] discutem várias dessas
estratégias. Observe que cada bolha le processo no diagrama de fluxo de dados mostrado na figura

Página 345 de 584
22.9 :orna-se um módulo no diagrama estrutural derivado; essa situação é ealista se os processos
forem relativamente pequenos e simples (ex.: se i especificação do processo for menor que uma
página de linguagem struturada). Além do módulo que implementa os processos do fluxos le
dados, é evidente que o diagrama estrutural também contém módulos jara coordenar e gerenciar a
atividade geral, bem como módulos ledicados a trazer entradas para o sistema e levar saídas para
fora do ;istema.
519
)iagrama abstrato de fluxo de dados
Outras estratégias de projeto utilizam o diagrama de entidade relacionamentos ou outras formas de
diagramas de estrutura de dado como ponto de partida da derivação do adequado diagrama
estrutura veja [ 19751 e [ 19771 para mais informações sobre essa estratégias de projeto.
22.2 METAS E OBJETIVOS DO PROJETO
Além de ter de alcançar os objetivos de projeto especificados o modelo de implementação do
usuário, o projetista também se preocup com a qualidade geral do projeto. A capacidade dos
programadores er implementar um sistema de alta qualidade e livre de erros depende sc bremaneira
da natureza do projeto criado pelo projetista. Analogameni a capacidade dos programadores de
manutenção em fazer alterações ni sistema depois que ele entrar em operação depende da qualidade
di projeto.
A área do projeto estruturado contém diversas diretrizes detalhada que ajudam o projetista a
determinar que módulos e que interligaçôe entre eles implementarão de forma melhor os requisitos
especificado pelo analista de sistemas; todos os livros relacionados no final deste ca pítulo
baseiam-se nessas diretrizes. As duas diretrizes mais importante são o acoplamento e a coesão.
Essas e algumas outras diretrizes comun serão discutidas agora.
• Coesão. O grau em que os componentes de um módulo (tipica mente as instruções individuais de
processamento que com põem o módulo) são necessários e suficientes para executa uma função
única e bem definida. Isso na prática significa que 1 projetista de sistemas deve assegurar que ele
ou ela não subdi vidiu processos essenciais em módulos fragmentados; e o proje tista deve
assegurar também que ele ou ela não agrupou proces sos não relacionados (representados por
bolhas no DFD) en módulos sem significado. Os melhores módulos são os fisncic nalmente coesos
(isto é, módulos nos quais cada instrução d programa é necessária para a execução de uma tarefa
únic e bem definida) e os piores são os coesos por coincic (módulos cujas instruções de programas
não têm qualquer rela cionamento significativo entre si) .
• Acoplamento. É o grau em que os módulos se interligam ou s relacionam entre si. Quanto mais
forte for o acoplamento entn os módulos de um sistema, mais difícil será sua implementaçã e
manutenção, porque a modificação de um módulo necessitar
520
um cuidadoso estudo, assim como as possíveis alterações e mo dificações de um ou mais dos
outros módulos. Isso na prática significa que cada módulo deve ter interfaces simples e claras com
outros módulos e que o menor número possível de ele mentos de dados deve ser compartilhado
pelos módulos. Também significa que um módulo não deve modificar a lógica interna ou os dados
de outro módulo, o que é conhecido por conexão patológica (o temido comando ALTER do

Página 346 de 584
COBOL é um ótimo exemplo).
Tamanho do módulo. Se possível, cada módulo deve ser sufi cientemente pequeno de modo a que a
listagem de seu pro grama caiba em uma página (ou, como alternativa, que possa ser exibido erp
uma tela do terminal). Naturalmente, às veses não é possível determinar qual será a extensão do
módulo até que tenham sido escritas as instruções do programa real; mas as atividades iniciais de
projeto muitas vezes dão ao projetista uma boa pista do tamanho e complexidade que o módulo
terá. Se for o caso, o módulo grande e complexo poderá ser dividido em um ou mais níveis de
submódulos (em raras ocasiões, os proje tistas criam módulos extremamente triviais, por exemplo,
módu los com postos de duas ou três linhas de código. Nesse caso, vários módulos podem ser
reunidos em um supermódulo maior).
• Amplitude do contmle. É o número de subordinados imediatos que podem ser chamados por um
módulo gerenciador. Um módulo não deve chamar mais do que aproximadamente meia dúzia de
módulos de nível inferior. A razão para isso é evitar a complexidade: se um módulo tiver, digamos,
25 módulos de nível inferior, ele provavelmente conterá lógica de programas demasiadamente
complexa (na forma de declarações IF ani nhadas, iterações DO-WHILE aninhadas etc.) que
ninguém será capaz de compreender. A solução para uma situação dessas é introduzir um nível
intermediário de módulos gerenciadores, como um gerente em uma organização humana faz
quando percebe que está supervisionando diretamente 25 subordinados imediatos 6
• Escopo do efeito/escopo do controle. Esta diretriz sugere que qualquer módulo afetado pelo
resultado de uma decisão seja subordinado (embora não necessariamente subordinado ime diato) ao
módulo que toma a decisão. Isso é algo análogo a uma diretriz gerencial que diz que qualquer
funcionário afetado pela
521
conseqüência de uma decisão de um gerente (isto é, dentro d escopo do efeito da decisão) deve
estar dentro do escopo d controle daquele gerente (isto é, trabalhando em algum pont na hierarquia
de pessoas que se subordinam àquele gerente). violação dessa diretriz em um ambiente de projeto
estruturad habitualmente conduz à passagem desnecessária de sinais chaves (o que aumenta o
acoplamento entre os módulos), a de cisões redundantes ou (o que é pior) conexões patológicas
entr os módulos.
22.3 RESUMO
Ainda há muito o que aprender sobre projeto, mas com esta intro dução você deve compreender o
processo desenvolvido pelo projetist de sistemas. Como vimos, a primeira etapa é mapear o
modelo essencia dos requisitos do usuário em uma configuração de processadores. En seguida, em
cada processador, o projetista deve decidir como aloca processos e dados a diferentes tarefas. Por
fim, deve organizar os proces sos de cada tarefa em uma hierarquia de módulos, utilizando o
diagram estrutural como ferramenta de modelagem.
Observe, ainda, que provavelvente precisarão ser acrescentado, processos e repositórios de dados
adicionais ao modelo de implementa ção para acomodar os recursos específicos da tecnologia de
implementa ção. Por exemplo, podem ser necessários processos adicionais para au vidades de
verificação de erros, edição e validação que não foram mos tradas no modelo essencial; mais outros
processos podem se fazer ne cessários para o transporte de fluxos de dados entre UCPs. Depois

Página 347 de 584
diss pronto, a programação pode se iniciar. A programação e os testes SCrã discutidos no capítulo
23.
REFERÊNCIAS
1. Meilir Page-Jones, Tbe Practical Guide to Structured System
Deslgn, 2a ed. Englewood Cliffs, N.J.: Prentice-Hall. 1988.
2. Edward Yourdon e Larry L. Constantine, Structured Design: Funda
mentais of a D of Computer Program and Systems Desig
Englewood Cliffs, N.J.: P 1989.
3. Paul Ward e Steve Mellor, Structured Development for Rea1-Tin
Systems, Volume 3. Nova Jorque: YOURDON Press, 1986.
4. Michael Jackson, Principies ofProgram Design. Nova lorque: Aca
demic Press, 1975.
522
5. Ken Orr, Struclured Systems Development. Nova lorque:
1. Qual é a atividade que se segue ao desenvolvimento do modelo de implementação do usuário em
um projeto típico de desenvolvi mento de sistemas?
2. Quais são os três principais estágios da fase de projeto no desen volvimento de um sistema? Que
modelos ão preparados durante
essas três etapas?
3. Por que os modelos são importantes durante a fase de projeto?
1. Qual é o principal propósito do modelo de processador durante a atividade de projeto?
5. Dê três exemplos de como os processos em um modelo essen cial podem ser mapeados para as
UCP em um modelo de
implementação.
6. Que decisões devem ser tomadas durante a atividade de modela gem de processadores em
relação aos depósitos de dados que
foram identificados no modelo essencial?
7. Apresente três métodos conhecidos para a comunicação entre processadores.
8. Quais fatores o projetista deve levar em consideração ao escolher um desses três métodos? Qual
desses fatores você considera ser o
mais importante?
9. Se você estiver trabalhando em um projeto de desenvolvimento de sistemas em que a
confiabilidade tem alta prioridade, como isso afetaria sua decisão sobre a alocação dos processos
essenciais e dos depósitos essenciais a diferentes processadores?

Página 348 de 584
10. Dê um exemplo de como as restrições políticas podem influir na alocação de tarefas e depósitos
essenciais a diferentes
processadores.
11. O que é um modelo de tarefa no contexto deste capítulo? Quais são seus componentes?
12. Apresente três sinônimos conhecidos para tarefa.
13. Sob que circunstâncias tarefas diferentes podem funcionar simultaneamente?
14. Projeto de Pesquisa: escolha um computador comum e um sistema operacional. Explique como
diferentes tarefas funcionando sob o controle de um sistema operacional podem comunicar-se umas
com as outras. Qual é a sobrecarga típica (em termos de tempo de UCP, utilização de memória e de
outros recursos significativos de hardware) causada por essa comunicação intertarefas?
523
15. Dê uma definição de modelo de implementação de programa
Quais são seus componentes?
16. Como o projetista deve transformar um modelo essencial de DFI
assíncrono e orientado para redes em um modelo sincronizado
hierárquico?
17. Sob que condições cada bolha no modelo essencial torna-se ur
módulo no modelo de implementação de programa?
18. Apresente duas estratégias de projeto conhecidas. Faça uma resu
mida descrição de cada uma.
19. Qual é o principal objetivo que o projetista tenta alcançar quar
do ele ou ela converte o modelo essencial em um modelo d
implementação?
20. Que outros objetivos o projetista habitualmente tenta atingir quar
do ele ou ela cria um modelo de implementação?
NOTAS
1 Perceba que isso é algo irreal, em face da tecnologia computa
cional do final dos anos 80, para qualquer sistema não-trivial. S
um sistema tiver 500 bolhas primitivas no DFD do modeli
essencial, seria realista considerar a implementação do sistema er
500 UCP separadas? Isso mudará em meados da década de 90.
2 Lembre-se de que existe um orçamento para todo o projeto, qu
deve ter sido estabelecido como parte do processo de análise (vej
o capítulo 5). Assim sendo, o projetista deve escolher o sistem
mais eficiente que se enquadre nesse orçamento. Entretanto, nã

Página 349 de 584
se esqueça do fato de que os orçamentos podem se modificar: o
orçamentos feitos na fase de análise eram apenas estimativas
podem estar sujeitos a revisão se o projetista demonstrar que é ne
cessário gastar mais dinheiro para uma implementação aceitável.
3 Costuma-se definir disponibilidade de um sistema como a percen
tagem de tempo em que o sistema está disponível para o uso. El:
pode ser calculada com base no MTBF e no M1TR da seguint
maneira:
disponibilidade = MTBF/ (MTBF+MTTR)
4 Naturalmente, um módulo chamado EXTRAIR CARACTER nãi soa como se exigisse de 50 a
100 instruções; ele poderia precisa de apenas dois ou três comandos em uma linguagem de prc
gramação de alto nível típica. Entretanto, em uma linguagem d baixo nível, orientada para a
máquina, seriam exigidas muitas ins truções a mais.
524
5 Exemplos de módulos funcionalmente coesos são CALCULAR RAIZ-QUADRADA,
CALCULAR-SALÁRIO-LÍQUIDO e VALIDAR- ENDEREÇO-DE-CLIENTE. Um exemplo de
módulo coeso por coin cidência é FUNÇÕES-MISTAS.
6 Existe uma exceção para isso, conhecida como centro de transa ções. Se o módulo gerenciador
faz apenas uma decisão simples para chamar um dos subordinados imediatos, então a lógica do
programa desse gerenciador será provavelmente bastante simples. Nesse caso, não precisamos nos
preocupar com a amplitude de controle do gerenciador.
525
23
PRO GRAMAÇÃO
E TESTES
É impossível dissociar a linguagem da ciência ou a ciência da lingua gem, porque toda ciência
natural sempre enwke três coisas. a sequência dos fenô menos nos quais a ciência se fundamenta,
os conceitos abstratos que trazem esses fenômenos á mente; e as palavras em que os conceitos são
e Para espressar um conceito uma palavra é necessária; para descrever um fenômeno é necessário
um conceito. Os três refletem todos a mesma e única realidade.
Antoine Laurent Lavoisier
Traité Elementaire de Chimie, 1789
O que temos de fazer é estar sempre testando novas opiniões e procuran do novas impressões com
curiosidade.
Walter Pater, The Renaissance, 1873
1. O papel do analista de sistemas na programação e nos testes.

Página 350 de 584
2. Porque o fast-tracking é vantajoso durante a progra mação e os testes.
3. O que o analista de sistemas deve procurar quando examinar um programa.
4. As principais formas de testes que devem ser executados.
A programação e os testes normalmente começam, como era de se
esperar, quando termina a atividade de projeto. A programação, ou fase
527
de implementação de um projeto típico envolve a escrita de instruçõe em COBOL, Pascal ou em
alguma outra linguagem de programação par implementar o que o analista de sistemas especificou
e o que o projeti ta organizou em módulos. Os testes, como o próprio nome diz, envol vem a
experimentação do sistema para ver se ele produz as saídas corre tas e apresenta o comportamento
correto para um grande número.d’ entradas.
Por que isso deve interessar ao analista de sistemas’ Não é verdadi que você já deveria não estar
mais envolvido neste ponto’ Não, não ne cessariamente. Por vários motivos, o trabalho que os
programadores e o testadores fazem podem influir em seu trabalho, e a maneira como voo organiza
seu trabalho pode influir na maneira como eles realizam deles. Esse interrelacionamento entre a
análise de sistemas e a programa ção/testes é o assunto deste capítulo.
23.1 O PAPEL DO ANALISTA NA PROGRAMAÇÃO E NOS TESTES
No caso mais extremo, o analista de sistemas termina seu trabalh de especificar o sistema e, em
seguida, dcspcnde algum tempo com equipe de projeto quando o modelo de implementação está
desenvolvi do e quando ocorrem os primeiros estágios de projeto. Mas, quando programação se
inicia, o analista de sistemas pode ter se transferido par outro projeto. Porém, existem alguns
motivos para que você, como ana lista de sistemas, possa precisar permanecer envolvido no projeto
quan do começar a atividade de programação:
Um motivo simples. Você é o líder do projeto, e é o responsáve pelos programadores. É óbvio que
você não os pode abando nar. Você estará envolvido no projeto até os testes finais, aceita ção e
entrega ao usuário final. Portanto, é importante que voc saiba se os programadores escreveram
programas de alta quali dade, e é igualmente importante saber se eles testaram os pro gramas
adequadamente.
• Outro motivo simples. Você é um analista de sistemas júnior, e c seu cargo é programador/analista
ou analista/programador. As sim, além de desenvolver as especificações do sistema, você também
está envolvido na escrita dos programas.
• Um motivo mais inleressanle. Você faz parte do grupo qu prepara casos de testes que serão
usados para testar os pro.
gramas escritos pelos programadores. Em muitos projetos, voc
528
pode ser acompanhado nessa atividade por um ou mais usuários, de acordo com a teoria segundo
qual os usuários são as pessoas mais capacitadas a imaginar os mais incomuns e ex cepcionais
casos para teste. O desenvolvimento de dados de teste pode começar assim que a especificação
tiver terminado (na verdade, até antes de estar totalmente terminada); como Tom DeMarco diz, “A

Página 351 de 584
especificação é o teste do sistema”. Como nesse momento você só conhece o conteúdo lógico das
entra das e saídas, você provavelmente terá de esperar até que o modelo de implementação do
usuário esteja pronto antes de poder estabelecer o formato físico das entradas e saídas. Você
também precisará do modelo de implementação do usuário para saber quais restrições operacionais
(tempo de resposta, volu mes etc.) precisarão ser testadas. Mas essa atividade pode facil mente
mantê-lo ocupado até o final do projeto; afinal, se os pro gramas fracassarem nos testes, você terá
de trabalhar com os programadores pata ver se o caso de teste está errado ou se os programas estão
errados.
• Um motwo não tão Óbvio. Você pode estar envolvido no desen volvimento dos manuais,
treinando os usuários, planejando a instalação do novo sistema e a conversão dos dados do sistema
antigo. Na maioria dos casos isso pode ocorrer em paralelo com a programação e testes do novo
sistema. Sendo você o analista envolvido com o novo projeto desde o início, você muitas vezes
será visto como o candidato ideal para desempenhar essa tarefa.
• Um motivo de.sencorajador. Os programadores podem não en tender sua especificação. Ou ela
pode estar incompleta, incon sistente ou contraditória. Tsk! Tsk! Mas essas coisas acontecem, e
você pode perceber que os programadores precisam procurá-lo periodicamente para revisar e
esclarecer a especificação na medida em que eles a convertem para uma linguagem de pro
gramação. Outra variação deste tema: os programadores podem pedir-lhe que mod a especificação
porque estão tendo dificuldades para implementá-la. Nesse caso, naturalmente, você terá de ser o
mediador (e também o intérprete) entre os progra madores e os outros analistas de sistemas.
• Outro motivo desencorajador. Os usuários podem começar a mudar de opinião a respeito dos
requisitos quando os pro gramadores já estiverem implementando os requisitos que dis seram
desejar. Além do fato de alguns usuários serem irritadiços e fazerem isso só pelo prazer de o
fazerem, existem boas razões
529
para esse fenômeno; os usuários vivem em um mundo dir e muitas vezes precisam cumprir
alterações de normas que lhe são impostas pela legislação governamental, por exigência dc clientes
ou pelas condições gerais do mercado. Assim, pod ocorrer de você ter de modificar a especificação
justo quando o programadores a estejam implementando, algo que não faz nir guém feliz, mas pode
ter de ser feito. Isso será discutido n seção 23.4.
23.2 O IMPACTO DA ANÁIISE, DA PROGRAMAÇÃO 1 DOS TESTES NA ESTRUTURA
ORGANI7ACIONA]
Através deste livro, ficou evidente que a análise estruturada envo ve uma firme progressão desde os
aspectos de modelagem de alto nív (ex.: diagramas de fluxo de dados de nível superior) aos
aspectos d modelagem dos níveis mais baixos, como o desenvolvimento de especi ficações de
processos e de um dicionário de dados completo e detalh2 do. De forma semelhante, o processo de
projeto envolve o desenvolvi mento de modelos de projeto desde diagramas estruturais de alto
nível elementos de baixo nível, como pseudocódigo e fluxogramas. A progn mação deve seguir
esse mesmo padrão: os programas têm de ser escrito para módulos de execução de alto nível e
serão eventualmente deser volvidos para os módulos do nível mais baixo, que executam cálculo
detalhados, validação de elementos de dados etc.

Página 352 de 584
Uma coisa sobre a qual ainda não discutimos é o relacionament entre os níveis do síslema e os
níveis da oi que constrói sistema. Porém é provável que você tenha ficado com a impressão, apá ler
quase todo este livro, que as pessoas que ostentam o título de anali tas de sistemas são responsáveis
por todo o trabalho de análise de sistc mas, as que têm o título de projelistas de sistemas são
responsáveis pel trabalho de projeto e as que têm o título de programadores são as re ponsávcis
pelo trabalho de escrever os programas.
Não obstante, existe um problema com essa abordagem - de fatc dois problemas relacionados.
Primeiro, as pessoas que têm o título d analistas de sistemas são normalmente senhores com vários
anos d experiência. Embora esses senhores geralmente apreciem a tarefa d desenhar diagramas de
fluxo de dados e de entidades-relacionamento é improvável que se interessem pela perspectiva de
escrever centena de especificações de processos e de definir milhares de elementos d dados.
E, depois, há o outro lado desse problema: se o pessoal mais gr
duado executa de fato todo esse detalhado trabalho, o que sobra para o
programadores? A tarefa deles torna-se quase mecânica por natureza
530
convertendo cuidadosamente especificações de processos em COBOL ou FORTRAN. Qualquer
que fosse a criatividade que eles pensavam possuir em suas tarefas parece ter desaparecido 1
Uma solução para esse aparente dilema é permitir que o pessoal mais graduado execute todas as
atividades de alto nível do projeto e deixar os elementos de nível júnior fazerem todo o serviço
detalhado de baixo nível. Isso significaria, por exemplo, que o pessoal sênior (que possui o título
de analista de sistemas sênior ou algo igualmente respei tável) não somente executaria as atividades
de alto nível da análise de sistemas (desenhando diagramas de fluxo de dados e congêneres) mas
também as atividades de alto nível de projeto de sistemas e se encarre garia até (arquejem!
estremeçam!) da escrita de código de alto nível. Enquanto isso, o pessoal de nível júnior estaria
envolvido no projeto desde o princípio (ou tão logo os mais graduados tivessem terminado os
aspectos de alto nível da análise) e estaria também envolvido na tarefa de escrever especificações
de processos e de módulos, de redigir os itens do dicionário de dados e de escrever os programas
dos módulos de baixo nível.
A vantagem desse esquema para os programadores é que eles têm de fazer o trabalho criativo dc
escrever as especificações de processos e assim têm o prazer de transformar em código suas
próprias especifica ções de processos. Esse esquema os envolve no processo de análise de sistemas
desde os estágios iniciais de suas carreiras do que seria possível de outra forma. Apresenta ainda a
vantagem de conservar os elementos de nível sênior em contato com a tecnologia por forçá-los a
continuar executando tarefas de projeto e de programação.
Nem todos os analistas de sistemas sênior concordam em que isso seja uma boa idéia, embora
admitam que a eles não agrade a maçada de escrever todas as especificações detalhadas de
processos como parte de seu trabalho. Em qualquer caso, existe uma crescente concordância em
que a tarefa de programação, quando precedida por uma cuidadosa e detalhada análise de sistemas
do tipo descrito neste livro, torna-se uma tarefa servil e burocrática que pode desaparecer
completamente quando desenvolvermos geradores de código que possam compilar as especifi
cações de processos diretamente. Dessa forma, podemos esperar que as empresas modificarão

Página 353 de 584
gradualmente o modo de trabalhar nos próximos 5 a 10 anos para se adaptarem ás idéias acima
discutidas.
23.3 FAST-TRACKING E IMPLEMENTAÇÃO
TOP-DOWN 4’
Outra impressão que você pode ter tido da leitura deste livro: que
as atividades de análise dc sistemas devem ser executadas e completadas
531
antes que as atividades de projeto e programação sejam iniciadas. Einbc ra muitos projetos sejam
desenvolvidos dessa maneira, isso não é estri tamente necessário. As atividades de análise de
sistemas, de projeto e d programação podem avançar em paralelo umas em relação às outras.
O conceito de desenvolvimento paralelo da especificação, do pro jeto e da codificação de um
sistema é por vezes chamada de fast-trackin e é referenciada em alguns livros (veja, por exemplo,
lYourdon, 1988] como implementação top-down. Ela não é única na área do processa mento. A
idéia foi discutida de maneira sucinta no capítulo 5, mas voo pode rever o conceito de
implementação top-down como parte do ci cio de vida do desenvolvimento de sistemas que
discutimos naquel capítulo.
A indústria da construção e muitas disciplinas de engenharia se guem essa abordagem em muitos
projetos. Como muitos gerentes d projetos de construção dizem, ‘Não é necessário saber o número
d maçanetas de um edifício antes que os alicerces estejam prontos”. N caso do desenvolvimento de
um sistema de informações, isso signific que os produtos de alto nível da análise de sistemas, os
documento estruturais de diagramas de fluxo de dados, diagramas de entidades relacionamentos e
diagramas de transições de estado, podem ser usado como fundamentos para o projeto de alto
nível. E esse projeto de ait nível pode ser empregado como fundamento para se escrever código d
alto nível antes que os detalhes da análise de sislemas tenham sid completados.
Esta abordagem apresenta muita flexibilidae. Pode-se completa 80% do trabalho de análise de
sistemas antes de iniciar-se o projeto e programação, ou pode-se completar apenas 10%. Um plano
que exij:
um trabalho de análise dc sistemas quase completo antes do projeto di sistemas costuma ser
chamado de abordagem conservadora; um plan que necessite de quase total paralelismo da análise
de sistemas, do pro jeto de sistemas e da programação é conhecido como uma abordagen radical.
Todo gerente dc projeto pode decidir quão radical ou conserva dor deverá ser seu projeto, e pode
mudar de opinião dinamicamenti durante o projeto.
Por que o gerente do projeto escolheria a abordagem radical? Po que alguém iria quçrer começar o
trabalho de projeto de sistemas e di programação antes de terminar a análise de sistemas? Existem
muito motivos, dos quais os que se seguem são os mais importantes:
Como as atividades de análise de sistemas, de projeto e dc pro gramação são executadas de forma
concorrente, existe habi tualmente uma oportunidade de encurtar substancialmente tempo
decorrido de um projeto. Em alguns ambientes isso pod ser imensamente importante; por exemplo,
quando um sistem;
532

Página 354 de 584
tem, de maneira absoluta e positiva, de ser terminado até uma certa data.
• O trabalho de desenvolvimento concorrente pode ser utilizado como uma forma de prototipação:
ele possibilita que a equipe do projeto mostre uma versão esqueleto do sistema ao usuário antes
que todo o trabalho detalhado de análise de sistemas esteja terminado. Isso pode ajudar a evitar
maiores mal-entendi dos entre o usuário e o analista de sistemas que de outra forma poderiam
ocorrer mesmo com a especificação estruturada mais cuidadosamente desenvolvida.
• Começar o trabalho de programação em um momento anteci pado do projeto muitas vezes
suaviza diversas necessidades de recursos, como tempo de máquina, que, de outra forma, poderia
transformar-se em um gargalo. Por exemplo, a abordagem con servadora muitas vezes exigiu
enormes volumes de tempo du rante os estágios finais de testes, e isso pode ser um grande
problema.
Se o gerente de projeto vai decidir-se pela abordagem conservado ra ou pela radical está fora do
escopo deste livro; alguns ambientes de projeto podem favorecer a abordagem conservadora e
outros se mostra rão mais indicados para uma abordagem altamente radical. O principal a ser
lembrado é que a abordagem de análise estruturada descrita neste livro não desaconselha qualquer
abordagem e nem insiste em qualquer delas.
23.4 PROGRAMAÇÃO E LINGUAGENS DE PROGRAMAÇÃO
Se você ainda estiver envolvido no projeto durante o estágio de
implementação, você deve ter pelo menos um conhecimento geral dos
aspectos e técnicas de programação. Nesta seção, discutiremos:
• Linguagens de programação dc quarta geração
• Aspectos importantes de programação
• O que procurar quando você examinar a codificação do programador
533
23.4.1 As Quatro Gerações das Linguagens de Programação
Os programas vêm sendo escritos desde que os computadores d emprego geral foram
desenvolvidos a cerca dc 40 anos atrás. Os progra mas são escritos em linguagens de programação,
das quais BASIC COBOL e FORTRAN são exemplos conhecidos. É prático agrupar toda as
diferentes linguagens de programação (existem algumas centenas & linguagens diferentes em uso
pelo mundo) em quatro gerações distintas
• Linguagens de primeira geração. As linguagens de programa ção de primeira geração foram as
linguagens de máquina usada nos anos 50; os programadores que desejassem que o computa dor
fizesse alguma coisa codificavam as instruções em uns e ze ros binários. Hoje ainda há ocasiões em
que um computador de feituoso emite páginas de dígitos confusos; e ainda há alguns jo vens mal
orientados que pensam que linguagem de máquina é melhor meio de jogar com computadores
pessoais. Mas o restr do mundo parou de pensar em linguagem de máquina há cerca de 25 anos.
• Linguagens de segunda geração As linguagens de segunda ge ração são as sucessoras da
linguagem de máquina; elas são ge ralmente conhecidas como linguagens de montagem ou assem
bler. As linguagens de segunda geração são de baixo nível nc sentido de que a programadora tem

Página 355 de 584
de escrever uma instruçãc para cada instrução de máquina. Assim, embora ela conceitual mente
possa pensar em termos da instrução X = Y + Z, teria dc converter as seguintes declarações cm
linguagem de montagem
CLEAR ACUMULADOR
LOAD Y INTO ACUMULADOR
ADD Z TO CONTEUDO DE ACUMULADOR
STORE ACUMULADOR IN X
Mesmo este pequeno exemplo mostra a principal desvantageni da linguagem de montagem. Em
vez de ser capaz de raciocinai em termos do problema que ela quer resolver, a programadora tem
de pensar em termos de máquina. A partir de cerca de 1960, linguagens mais poderosas começaram
a aparecer; os pro. gramadores mais equilibrados abandonaram a linguagem d montagem desde
então. Infelizmente, ainda há algumas si tuações em que tais linguagens são necessárias. A maioria
delas envolve computadores muito pequenos e de baixa energia (que
534
podem ser fabricados a baixo custo e que são suficientemente pequenos para caberem, digar’ios,
em um relógio digital) que não têm capacidade para tolerar a sobrecarga associada ás linguagens de
alto nível.
Linguagens de terceira geração As linguagens de terceira gera ção são a norma hoje cm dia; elas
incluem BASIC, COBOL, FORTRAN, Pascal, C, Ada e muitas outras. Elas são de alto nível no
sentido de que um único comando (como “MOVE A TO B” em COBOL) habitualmente representa
de cinco a dez instruções em linguagem de montagem (e, às vezes, em torno de cem instruções);
elas são de alto nível no sentido, ainda mais impor tante, de que permitem que a programadora
expresse pensa mentos de uma forma mais compatível com a área do problema em que ela está
trabalhando. Entretanto, elas são de baixo nível sob alguns aspectos importantes. Elas exigem que
o programa dor esteja estreitamente envolvido no tedioso trabalho de forma tar a diagramação
(layout) dos relatórios e editar e validar as entradas do programa. O programador muitas vezes dirá
para si mesmo: «este relatório deveria ter o cabeçalho padrão no alto de cada página, com o
número da página à direita e a data à esquerda, como todos os nossos outros relatórios”, mas ele
pode ter de escrever 20 ou 30 comandos COBOL para obter isso
As linguagens de terceira geração também se caracterizam como linguagens procedurais. Elas
exigem que o programador medite cuidadosamente sobre a seqüência de cálculos, ou sobre o pro
cedimento, necessário para executar alguma ação. Em uma apli cação científica, por exemplo, o
programador pode saber que deseja somar o array A ao array B; entretanto, ele pode ser forçado a
escrever as etapas procedurais detalhadas para somar cada um dos elementos dos dois arrays, em
lugar de dizer sim plesmente “Some estes dois arrays” sem se preocupar com as etapas procedurais.
• Lín de quarta geração As linguagens de quarta gera ção, ou L4G, constituem a atração atual e são
consideradas por alguns consultores de computação como o mais importante avanço na área de
software dos últimos 20 anos. Algumas delas já existem por cerca de uma década, porém só
tornaram-se conhecidas há poucos anos. Exemplos de L4G 5 FOCUS, IDEAL, MARK IV,
MANTIS, MAPPER, dBASE-III Plus e Rbase 5000. A maioria dessas linguagens têm as
características da pro gramação estruturada de que carecem as antigas linguagens de

Página 356 de 584
535
terceira geração, mas elas dispõem ainda de outros recursos. En particular, a maioria dos tediosos
detalhes de programação asso ciados à obtenção de dados para o computador (via terminal) oculta
do programador; com um simples comando, o programa dor pode especificar que o computador
deve aceitar um deter minado tipo de dado a partir do teclado, validá-lo e armazená-k em um
elemento de dado indicado. A mesma tarefa poderi exigir 10 ou 20 comandos de uma linguagem de
prograrnaçãc de terceira geração ou de 100 a 200 instruções de uma lin guagem de segunda
geração.
De modo semelhante, muitos dos aborrecidos detalhes de pro gramação associados à produção de
relatórios de saída (ex. listas de inventários, cheques de pagamento, faturas ou um re sumo diário
dos pedidos) são manipulados automaticament pelas linguagens de quarta geração. Se o
posicionamento exat da informação no dispositivo de saída do computador for relati vamente sem
importância (o que freqüentemente é o caso), programador nem sequer precisa especificá-lo; caso
contrárü (como no caso de cheques de pagamento produzidos em com putador, onde os valores
devem ser impressos em local exato) os detalhes são facilmente especificados em poucas instruçõe
de L4G.
23.4.2 Aspectos Importantes da Programação
Qualquer que seja a linguagem de programação usada, existen alguns problemas que se deparam a
todos os programadores. Comc analista de sistemas você deve conhecê-los. Os problemas mais
comun são os seguintes:
Produtividade O mais importante problema de programaçãc hoje provavelmente é o da
produtividade: a obtenção de mai software escrito com mais rapidez do que nunca. O principa
motivo disso é o enorme backlog de sistemas e aplicações ainda não escritos nas grandes
organizações: a grande organizaçãc típica tem um backlog de quatro a sete anos dc novos serviços
serem feitos 2 Dessa maneira, as linguagens e técnicas de pro gramação que favorecem a
produtividade estão sendo adotada e, exceto em raros casos, a produtividade está sendo conside.
rada como mais importante hoje do que a eficiência.
536
• Eficiência: Em algumas aplicações, a eficiência ainda é impor tante. Isso vale para muitos
sistemas de tempo-real e pode valer para outros tipos de sistemas que processam grandes volumes
de dados (ex.: a maioria dos sistemas executados na Social Secu rity Agency, bem como outros
igualmente muito grandes em bancos, em operações de reserva de passagens aéreas, empre sas
corretoras de valores e empresas de seguros). Para essas aplicações, costuma ser importante
minimizar o tempo de UCP exigido pelo programa; pode também ser importante minimizar a
utilização da memória e a utilização de outros recursos como os discos. Observe que a meta da
eficiência está habitualmente em conflito com as outras metas discutidas nesta seção: quando se
despende mais tempo desenvolvendo um programa eficien te, ele provavelmente será menos
manutenível e menos portátil, tendo provavelmente sutis erros residuais e possivelmente de gradará
a produtividade de quem escreveu o programa.
• Correçãa Pode-se argumentar que este seja o aspecto mais im portante. Afinal, se um programa
não funcionar corretamente, não importa quão eficiente ele é. As linguagens de programação como

Página 357 de 584
Ada e Pascal são consideradas preferíveis quando a cor reção é um fator essencial (como seria, por
exemplo, para al guém trabalhando no sistema Star Wars ou construindo um sis tema de controle
para um reator nuclear) porque elas são “forte mente tipadas”: o programador é solicitado a
declarar a natureza de suas variáveis (se são inteiras, caracteres, de ponto flutuante etc.) e a
linguagem verifica cuidadosamente para impedir referências ilegais a dados, e coisas semelhantes.
• Portabilidacle Em alguns ambientes a portabilidade é impor tante; o usuário pode querer
processar o mesmo sistema em diversos tipos de computadores. Algumas linguagens de pro
gramação são mais portáteis do que outras; ironicamente, isso é mais válido para linguagens de
terceira geração (C, Pascal, FORTRAN, COBOL etc.) do que para as de quarta. Entretanto, nãq
existe uma linguagem inteiramente portátil; sempre existe uma forma para o programador
beneficiar-se dos recursos espe ciais de um determinado computador ou de um determinado
sistema operacional. Desse modo, além da linguagem de pro gramação, também devemos nos
preocupar com o estilo da programação quando a portabilidade for um fator importante.
• Manutenibilidade Por fim, devemos lembrar-nos que os sis temas vivem por um longo tempo e o
software precisa ser
537
mantido. A manutenção será discutida em maiores detalhes nc capítulo 24.
23.4.3 Aspectos a Serem Examinados
Como analista de sistemas, você pode ter ocasião de examinar ( serviço feito pelos programadores
do projeto; na verdade, você pode sei o supervisor deles. Como acima indicado, você develembrar-
se de que produtividade, eficiência, correção, portabilidade e a manutenibilidad são provavelmente
aspectos importantes. Mas, como essas metas poden ser alcançadas? Você deve consultar outros
livros, como lYourdon, 1976 e [ e Plaugher, 19751, que apresentam detalhes sobre a técnicas de
programação; contudo, eis alguns importantes aspectos ± programação:
Programação estruturada: Presumindo-se que os programas es tejam escritos em uma linguagem de
terceira ou quarta geração deve ser seguida uma abordagem de programação estruturada Ela
organiza toda a lógica do programa (decisões e laços) en combinações aninhadas de construções de
IF-THEN-ELSE e DO WHILE. Quase todos os livros modernos de programação ensi nam uma
abordagem de programação estruturada; veja, p0 exemplo, EWelis, 19861, IBenton e Weekes,
19851, lYourdon Gane e Sarson, 19761 e lYourdon e Lister, 19771.
Módulos pequenos: É essencial que os programas sejam organi zados em pequenos módulos para
que a lógica da programaçãc possa acomodar-se em uma página da listagem de um pro grama. É
importante lembrar que a complexidade de um pro grama não cresce linearmente com o tamanho
do programa: urr programa com 100 instruções será quase sempre mais de dua vezes mais
complexo que um dc 50 instruções. Como vimos nc capítulo 22, isso está principalmente sob o
centrole do proje tista; mas o projetista pode não estar apto a dizer quão grand será um módulo,
principalmente se não conhecer bem a lingua gem de programação que será empregada no projeto.
Assin sendo, o programador pode ter de exercer a tarefa de projeto dividindo o módulo em
submódulos de nível inferior de forma que cada um represente não mais de 50 instruções.
Simplicidade de eslílo: Muitos livros de programação, com FYourdon,19761 e FKernighan e
Plaugher, 19751, oferecem de talhadas diretrizes para a escrita de programas simples - 538

Página 358 de 584
programas que o programador médio pode compreender e que podem ser confiados ao
programador de manutenção; entre es sas diretrizes está a sugestão de que o programador deve
evitar instruções com expressões booleanas compostas. Por exemplo,
IF A AND B OR NOT C AND D THEN ADD 3 TO X.
É interessante observar que alguns modelos matemáticos da complexidade de programas foram
desenvolvidos nos últimos dez anos - um dos mais conhecidos é o modelo de complexi dade
ciclomática de McCabe (veja FMcCabe, 1976]), que oferece uma medida quantitativa da
complexidade intrínseca de um programa . Algumas empresas atualmente determinam que todos os
novos programas sejam executados através de um ve rificador automatizado de complexidade para
assegurarem-se de que eles não sejam demasiadamente complexos.
23.5 TESTES
O processo de testes provavelmente ocupará cerca de metade do cronograma de desenvolvimento
de seu sistema, dependendo do cuida do com que tenham sido executadas as atividades iniciais de
análise, projeto e programação. Mesmo no caso de ter sido executada uma tarefa rerfeita de análise
de sistemas, projeto e programação, é preciso algum esforço para verificar se não há erros. Se, por
outro lado, tiver sido feito um mau serviço (o que quase sempre acontece!), então os testes tornam
5e iterativos: a primeira rodada de testes denuncia a presença de erros e as rodadas subseqüentes
verificam se os programas corrigidos já estão Funcionando corretamente.
O que você precisa saber sobre testes como analista de sistemas? [ naturalmente dependerá de
quanto você estiver envolvido no pro :esso. Em muitos casos, o analista de sistemas trabalha em
estreita asso :iação com o usuário para desenvolver um conjunto completo e abran ‘ente de casos
de testes fundamentados no modelo essencial e no nodelo de implementação do usuário do sistema.
Esse processo de tesenvolvimento de casos de testes de aceitação pode ser executado em Daralelo
com as atividades de implementação de projeto e programação, te modo que, quando os
programadores tiverem terminado seus pro ramas e executado seus próprios testes locais, a equipe
usuário/analista stará pronta para seus próprios casos de testes.
Além desse conceito básico (que a descrição dos requisitos do
isuário forma a base dos casos de testes finais), você deve conhecer
539
os vários tipos de testes, bem como alguns conceitos estreitament relacionados com eles. É o que
discutiremos a seguir.
23.5.1 Tipos de Testes
A esta altura, pode não lhe haver ocorrido que existe mais de un
tipo de teste: que mais pode haver além de imaginar casos de testes
depois verificar se o sistema funciona corretamente?
A primeira coisa a compreender é que existem diferentes estraté glas de testes: as duas mais
conhecidas são os testes bottom-up e os top down. A abordagem bottom-up começa por testar os
módulos pequeno de forma individual; essa modalidade é muitas vezes chamada de tes te de
unidade, teste de módulo ou teste de programa. Em seguida, o módulos individuais são reunidos
em unidades cada vez maiores par; serem testadas em conjunto; isso costuma ser chamado de teste

Página 359 de 584
de sub sistemas. Por fim, todos os componentes do sistema são combinado para serem testados, o
que é conhecido como teste do sistema, e muitas vezes seguido pelos testes de aceitação, quando o
usuário pod submeter seus próprios casos de teste para verificar se o sistema est funcionando
corretamente.
A abordagem de testes top-down principia com um arcabouço d( sistema; isto é, a estratégia de
testes presume que os módulos de execu ção de alto nível do sistema foram desenvolvidos, mas
que os módulo de baixo nível existem apenas como simulaçõcs ou “stubs” Como; maioria das
funções detalhadas do sistema não foram implementadas, o testes iniciais são muito limitados, O
propósito é apenas começar a testa as interfaces entre os principais subsistemas. Os testes
subseqüentes tor nam-se em seguida cada vez mais abrangentes, testando aspectos cad; vez mais
detalhados do sistema. A abordagem top-down de testes geralmente considerada melhor para a
maioria dos sistemas atualment (para mais detalhes, veja [ 19861).
Além desses conceitos básicos, você deve conhecer os seguinte
tipos de testes:
• Testes funcionais: Esta é a mais conhecida forma de testes. ( objetivo é verificar se o sistema
executa corretamente suas fun ções normais. Portanto, os casos de testes serão desenvolvidos
introduzidos no sistema; as saídas (e os resultados da atuali zação de arquivos) serão examinadas
para testar sua correção.
• Testes de recupera ção O objetivo deste tipo de teste é verifica se o sistema pode recuperar-se
adequadamente de vários tipo
de falhas. Isso é especialmente importante em grandes sistema
540
on-line e em vários tipos de sistemas de tempo-real que con trolem dispositivos físicos e/ou
processos de fabricação. Os tes tes de recuperação podem exigir que a equipe de projeto simule (ou
provoque) falhas de hardware, faltas de energia, falhas do sistema operacional do fornecedor e
assim por diante.
Testes de desempenhct O objetivo deste tipo de teste é verificar se o sistema pode manipular o
volume de dados e transações recebidas especificadas no modelo de implementação do usuário,
bem como verificar se ele apresenta o tempo de res posta necessário. Isso pode exigir que a equipe
de projeto si mule uma extensa rede de terminais on-line, de modo a levar o sistema a pensar que
está funcionando sob uma grande carga.
Existe ainda um último conceito que você deve conhecer: a noção de testes completos. No projeto
ideal, geraríamos casos de testes que cobririam todas as entradas possíveis e toda possível
combinação de si tuações com que o sistema poderá se defrontar; então testaríamos exaus
tivamente o sistema para assegurar que seu comportamento seria per feito. Há um único problema
quanto a iSSO: não funciona! A quantida de de casos de teste para um típico sistema grande e
complexo é tão absurdamente grande, muitas vezes da ordem de 10 casos distintos ou mais que,
ainda que pudéssemos efetuar um teste a cada milissegundo, levaríamos mais tempo que a idade do
universo para executar todos os testes! Em conseqüência, ninguém efetua realmente testes
exaustivos em algo além de um sistema trivial; na melhor das hipóteses os desenvolvedores do
sistema podem esperar criar casos de teste que verificarão (ou cobrirão) uma grande percentagem

Página 360 de 584
dos diferentes cami nhos de decisão que o sistema pode seguir . Isso faz com que seja ainda mais
importante garantir que o modelo dos requisitos do usuário e os diversos modelos de
implementação sejam tão corretos quanto possível.
Suponha, por exemplo, que alguém quisesse preparar casos de teste para a parte de um sistema que
calcula o salário líquido de um empregado, como mostrado na figura 23.1. Imagine que salário
bruto esteja definido no dicionário de dados como um inteiro (isto é, um sa lário expresso por um
valor inteiro na moeda corrente) variando entre O e 10.000. Então, poderia parecer que um teste
completo consistiria em especificar qual seria o salário líquido correto para cada uma das 10.000
possibilidades do valor de salário bruto. Poder-se-ia supor que, se a equipe de implementação
executasse os 10.000 casos de teste e veri ficasse que fora produzido, de fato, o salário líquido
correto, pôdería mos confiar em que o processo estaria funcionando corretamente.
Espere! E os valores potencialmente incorretos do salário bruto? E
se o usuário introduzir um salário bruto negativo? E se ele introduzir
541
um salário bruto de 100.000? Como existe um número potencialmence infinito de valores possíveis
para salário bruto 6, e como não temos co nhecimento do comportamento interno do programa que
implementa CALCUlAR SAlÁRIO LÍQIJIDO, nós nos defrontamos com um aparen temente
infinito número de casos de teste. Se os casos de teste forem de senvolvidos no final da fase de
análise do projeto, com utilização do di cionário de dados e da especificação de processos, não há
meio de sa bermos como o programa funcionará quando o programador escrever o código e, desse
modo, somos forçados a executar um teste tipo caixa preta.
Quando conhecemos a lógica e a estrutura interna do programa (isto é, depois de o programador ter
escrito o programa), podemos Fun damentar os casos de testes na lógica do programa e executar o
que muitas vezes é chamado de testes de ‘caixa de vidro” ou de ‘caixa branca”. Geralmente
podemos demonstrar que se, por exemplo, o pro grama identificar corretamente um valor de salário
bruto inferior a zero, ele identificará corretamente todos os valores negativos de salário bruto. Em
geral, devemos ser capazes de demonstrar que o programa apresentará comportamento consistente
para diversos inte?valos de salário bruto, e, assim, reduzirmos o número necessário de testes a um
número gerenciável. Embora isso não se constitua em testes completos, podemos presumivelmente
alcançar um nível de confiança mais elevado de que desenvolvemos casos de testes para todos os
caminhos significativos que o programa pode tomar.
Mas, espere! CALCULAR SALÁRIO LÍQUIDO é apenas um pro cesso, uma bolha entre centenas,
e talvez milhares, de um grande siste ma. Se forem necessários, digamos, 1000 casos de testes para
verificar se CALCULAR SALÁRIO LÍQUIDO está funcionando corretamente (em termos de
correção funcional), então poderiam ser necessários 1000 testes para cada um dos, digamos, 1000
outros processos do sistema. A quantidade total de casos de testes distintos poderia, então, alcançar
1000 * 1000 = 1.000.000. E isso em uma estimativa moderada (sem considerar a dimensão de
complexidade adicionada pelos testes de desempenho, testes de recuperação etc.)!
Desse modo, temos de admitir que testes completos são uma
impossibilidade. Mas podemos, como explicamos acima, escolher
salário bruto

Página 361 de 584
salário líquido
Figura 23.1: Uma pequena parte de um sistema
542
judiciosamente casos de testes, de forma a verificarmos tantos caminhos lógicos do sistema
quantos sejam possíveis. Mesmo assim, precisamos estar preparados para um grande, senão
enorme, volume de testes. Para que esses testes sejam executados de maneira eficaz, a equipe de
desen volvimento de sistemas necessita de três coisas: planos de testes, descrições de testes e
procedimentos de testes. Um plano de teste é exatamente o que o nome diz, um documento
organizado que descreve alguma atividade de teste. Um plano de teste típico contém as seguintes
informações:
• Objetivo do teste: qual é o objetivo do teste e que parte do sistema será testada.
• Localização e cronograma do teste: onde e quando o teste será realizado.
• Descrições de testes: uma descrição das entradas que serão intro duzidas no sistema e as saídas e
resultados antecipados. As des crições das entradas de teste habitualmente são fornecidas no
formato do dicionário de dados discutido no capítulo 10.
• Procedimentos de testes: uma descrição de como os dados de testes devem ser preparados e
submetidos ao sistema, como os resultados de saída devem ser colhidos, como os resultados dos
testes devem ser analisados e de quaisquer outros procedimen tos operacionais que devam ser
observados.
23.5.2 Conceitos Relacionados
Embora muitas empresas executem os testes na modalidade acima
descrita, existem alguns conceitos relacionados que podem ser utilizados
para melhorar o processo padrão de testes. Entre eles estão os seguintes:
• Caminhamentos (Walkthroughs)
• Inspeções
• Provas de correção
Os caminhamentos, discutidos no apêndice D, são uma forma de revisão de produtos técnicos; são
amplamente utilizados na indústria de processamento de dados para revisar diagramas de fluxo de
dados (e outros produtos da análise de sistemas), diagramas estruturais (e outros
543
produtos de projeto) e também programas. Embora diferentes dos testes seus objetivos são os
mesmos: descobrir possíveis erros no sistema.
As inspeções são semelhantes aos caminhamentos, mas com um agenda um pouco mais formal de
itens que devem ser examinados n programa (ou na especificação, ou no projeto, dependendo do
tipo dc inspeção) para que ele possa ser aprovado. Para fazer uma analogia considere o que ocorre
a cada ano em que seu carro é inspecionado: c mecânico tem uma lista específica de verificação de
características - freios, faróis, descarga etc. - que devem ser examinadas para que elc aponha o
adesivo adequado no carro.

Página 362 de 584
Por fim, existe um número limitado de casos em que provas d correção formais serão
desenvolvidas para um programa; o processc aqui é um tanto análogo ao processo de obtenção de
provas geométrica que um dia estudamos no colégio. Infelizmente, é extremamente difici
desenvolver uma rigorosa prova de correção de programas, além dc tempo que ie gasta, e
raramente isso tem sido feito para coisas maiores que umas poucas centenas de instruções de
programa. Entretanto, pelc menos um projeto do governo americano desenvolveu uma prova dc
correção assistida por computador para um sistema que envolvia apro ximadamente 10.000
instruções; embora custasse cerca de $500.000 e exigisse 6 meses de trabalho, justificava-se para
certos sistemas de altc risco ou de alta segurança. Para uma discussão sobre provas de correção,
veja o capítulo 6 de LDunn, 19841 ou os levantamentos em EElspas et a1í 19721 e [ e Basili,
1982].
23.6 A MANUTENÇÃO DA ESPECIFICAÇÃO
DURANTE A PROGRAMAÇÃO: UM PRELÚDIO
PARA O CAPÍTULO 24
Como já dissemos, a especificação estruturada pode ser modificada durante o processo de
programação. Isso pode ocorrer como resultado da estratégia de fast-tracking anteriormente
descrita, ou porque a es pecificação original estava errada ou simplesmente porque os usuários
mudaram de opinião sobre seus requisitos, De qualquer forma, isso é uma realidade que ressalta
um aspecto importante: a especificação do sistema não pode ser considerada imutável após a fase
de análise de sistemas ter sido declarada como terminada. Ela deve ser considerada um documento
vivo que necessitará de continua manutenção antes mesmo que afase de manutenção do próprio
sistema tenha sido inicia da. O capítulo 24 estuda esse aspecto com mais detalhes.
544
23.7 E DEPOIS DOS TESTES?
Você talvez pense que seu trabalho esteja totalmente terminado quando os testes do sistema tiverem
sido feitos. Infelizmente, há mais a fazer, embora você possa não estar envolvido em seu papel de
analista de sistemas. Entretanto, alguém (e muitas vezes um grande grupo de pessoas) deve
executar as atividades finais de um projeto de desenvol vimento de sistemas.
• Conversão
• Instalação
• Treinamento
Conve?são é a tarefa de passar os atuais arquivos, formulários e bancos de dados do usuário para o
formato requerido pelo novo siste ma. Em alguns raros casos, isso pode não ser uma tarefa de
relevância, porque pode não haver dados. Contudo, se o usuário estiver trocando um sistema antigo
por um sistema novo, essa tarefa poderá ser delicada e difícil. Um plano de conversão deve ser
elaborado, de preferência, as sim que o modelo de implementação do usuário esteja pronto, para
tratar dos seguintes problemas:
• Se o usuário já possuir dados relativos a um sistema existente, ele provavelmente vai querer usá-
los até o último momento possível antes de passar para o novo sistema. Portanto, é difícil
considerar os dados existentes como estáticos.

Página 363 de 584
• Pode haver um volume tão grande de dados existentes que seja impraticável convertê-los todos de
uma só vez. Os arquivos e registros podem precisar ser convertidos de forma paulatina, quando
isso se fizer necessário. Isso, é claro, exigirá coorde nação e controle cuidadosos.
• A conversão deve ser executada dc modo automático; isso só pode ser feito se os arquivos e
dados atuais existirem sob al guma forma automatizada. Se assim for, será relativamente simples
escrever-se um programa (ou utilizar-se um pacote de .algum fornecedor) para converter os
arquivos atuais para o for mato requerido pelo novo sistema. Entretanto, às vezes é um tanto difícil
converter os dados de maneira automatizada, princi palmente quando os arquivos existentes estão
localizados em vários computadores diferentes, em diferentes formatos, e assim
545
por diante. Na verdade, o desenvolvimento de um software d conversão pode tornar-se, por ele
mesmo, um importante pro. jeto de desenvolvimento de sistemas!
Os dados existentes podem conter erros; na verdade, se esse dados foram criados e mantidos
manualmente, você pode estai virtualmente certo que haverá erros. Assim, parte do processo de
conversão é destinada à detecção e correção de erros, o que pode tornar o processo ainda mais
difícil e consumir mai5 tempo. Alguns arquivos e registros existentes podem revelar-se ilegíveis ou
incompreensíveis; em outros casos, pode ser evi dente que os dados existentes estejam errados,
mas pode não ser tão evidente quais sejam os valores corretos.
Além da conversão dos arquivos existentes, pode ser necessário converter programas e
procedimentos. Em alguns casos, os pro gramas e procedimentos existentes podem ser utilizados
na forma atual; em outros, terão de ser inteiramente substituídos.
A instalação do novo sistema pode ser uma atividade instantânea,
porém muitas vezes é uma tarefa importante. Habitualmente, duas coisas
precisam ser feitas:
• O preparo da localização do computador deve preceder a insta lação do novo sistema, de hábito
por vários meses. Isso envolve a construção ou o aluguel das acomodações do computador com
força, espaço, iluminação e controle do ambiente (tempera tura, umidade, poeira, eletricidade
estática etc.). Isso muitas vezes é feito mediante acordo com o fornecedor do hardware ou com o
setor de operações do computador da empresa.
• O preparo da localização do usuário também pode ser neces sário, principalmente no caso de
sistemas on-line que têm termi nais e impressoras no setor de trabalho do usuário. Nos casos mais
simples, os terminais podem ser distribuídos para a área de trabalho do usuário imediatamente
antes da instalação do sis tema; em alguns casos, todavia, pode ser necessária a cons trução de todo
um novo ambiente de trabalho (considere, por exemplo, um terminal de reserva de passagens em
um aeroporto).
• A instalação do hardware, presumindo-se que o novo sistema exija seu próprio hardware de
processamento, costuma ser le vada a efeito pelo fornecedor do hardware; por vezes estão
546
envolvidos múltiplos fornecedores, principalmente no caso de sistemas on-line e de tempo real. No
caso de um sistema simples desenvolvido para um computador pessoal, a instalação pode consistir

Página 364 de 584
apenas em retirar-se o computador da caixa e ligá-lo à tomada.
A instalação do software, que envolve o carregamento de todos os programas que foram escritos
para o novo sistema no(s) computador(es) apropriado(s) e sua preparação para funcionamento.
Lembre-se que os aspectos acima descritos presumem que exista apenas uma instalação em um
único lugar. Mas nem sempre é assim; no caso de um sistema distribuído, de grande porte, pode
haver uma única e centralizada localização do computador e dezenas ou mesmo centenas de
localizações de usuários. Desse modo, pode ser necessário instalar o sistema por estágios, com
equipes de instalação especialmente treinadas visitando cada localização de usuário de acordo com
uma es cala previamente preparada. Nesse caso, a instalação e a passagem para o novo sistema não
pode ocorrer de uma só vez, mas, ao invés disso, deve ser dividida em fases com períodos de dias,
semanas e mesmo meses.
O treinamento é a tarefa final da equipe de desenvolvimento de sistemas: treinamento dos usuários
(obviamente!) e do pessoal de opera ções, dos programadores de manutenção e dos diversos níveis
de dire ção. Um plano de treinamento deve ser desenvolvido no início do proje to, porque existe
um bom volume de trabalho a ser feito, e esse plano precisa estar pronto ao mesmo tempo (ou
antes) que o sistema esteja apto para entrar em operação. O plano de treinamento deve tratar dos
seguintes aspectos:
• Como o treinamento deve ser realizado? A maioria dos projetos de desenvolvimento de sistemas
apóia-se em manuais do usuário e guias de referência para oferecer documentação escrita para os
usuários. Entretanto, aulas e seminários ao vivo podem ser adequados, bem como palestras de
orientação para gerentés e outros que necessitem conhecer o sistema mesmo que não venham a
interagir com ele todos os dias. E, com a tecnologia atual, há uma gama de opções de meios de
treina mento: treinamento por videoteipe e videodisco, treinamento com uso do computador e até
versões simuladas do sistema real para que os usuários possam treinar a introdução de transações e
aprender como interagir com o sistema.
547
No caso mais extremo, o treinamento pode consistir em fac lidades de auxílio extremamente
sofisticadas embutidas n próprio sistema. Isso vem tornando-se crescentemente pop lar com a
proliferação dos computadores pessoais, mas não muito prático para grandes sistemas que
interagem cor uma comunidade grande e diversificada; por outro lado, pc de ser usado para
aumentar e reforçar outras formas d treinamento.
Quem ministrará o treinamento? Em alguns casos elementos d equipe de desenvolvimento do
sistema participam do process de treinamento, principalmente porque supostamente são o que mais
conhecem o funcionamento do sistema. Entretantc lembre-se de que o melhor programador (ou
analista de sis temas) nem sempre é o melhor treinador. Na verdade, os desen volvedores muitas
vezes comportam-se de um modo muito de fensivo quando os usuários começam a perguntar o que
ele consideram ofensivo. Além disso, os desenvolvedores estã (quase por definição) terrivelmente
ocupados com projeto, codi ficação e testes do sistema até o último minuto; o analista d sistemas
pode ter mais tempo disponível depois que o modek essencial e o modelo de implementação do
usuário estiveren prontos.
Quem será treinado e em que escala de tempo? Obviamente, O:

Página 365 de 584
usuários precisam ser treinados para que possam começar a uti lizar o sistema; por outro lado, não
é muito eficiente treiná-lo seis meses antes que possam ter acesso a ele.. Desse modo, treinamento
deve ser feito em um período bastante reduzido mas isso, por sua vez, muitas vezes vai interferir
com o trabalk diário normal que os usuários têm que cumprir. Portanto, é ne cessário negociar com
os usuários um cuidadoso calendário d atividades de treinamento.
23.8 RESUMO
Este capítulo discorreu sobre uma ampla gama de tópicos: progra mação, testes, conversão,
instalação e treinamento. O espaço não ofere ce ocasião para uma detalhada cobertura desses
tópicos, porém a sucinta cobertura apresentada neste capítulo deve dar ao analista de sistema uma
visão geral das atividades finais do projeto de desenvolvimento dc sistemas. Detalhes
complementares podem ser encontrados em muitas referências no final deste livro.
548
REFERÊNCIAS
1. Edward Yourdon, Managing tbe Systems Life Cycle, 2’ ed. Engle wood Cliffs, N.J.: Prentice-
Hall, 1988.
2. Edward Yourdon, Nations at Risk Nova lorque: YOURDON Press,
1986.
3. Edward Yourdon, Techniques ofPro Sfructure and Design, 2’ ed. Englewood Cliffs, N.J.:
4. Brian KernigJ e P.J. Plauger, The Elements ofProgramming Slyle. Reading, Mass.: Addison-
Wesley, 1975.
5. Timothy Wells, Structured Systems Development in COBOL Nova lorque: YOURDON Press,
1986.
6. Timothy Welis, Structured Systems Development in BASIC. Nova lorque: YOURDON Press,
1985.
7. Timothy Wells, Structured Systems Development in Pascal. Nova lorque: YOURDON Press,
1986.
8. Stan Benton e Leonard Weekes, Program It Right: Structured Ptv gramming in BASIC Nova
9. Edward Yourdon, Chris Gane e Trish Sarson, Leaniing to Program in Structured COBOL, Part 1.
Nova lorque: YOURDON PRESS,
1976.
10. Edward Yourdon e Timothy Lister, Learning to Program in Struc tured COBO4 Part II. Nova
11. Tom DeMarco, Controlling Software Projects. Nova lorque:
12. Glenford Myers, 7 Art of Software Testing. Nova lorque: Wiley,
1979.

Página 366 de 584
13. Tom McCabe, “A Complexity Measure”, IEEE Transactions on Soft ware Engineering, Volume
SE-2, Número 12 (dezembro de 1976),
pgs. 308-320.
14. Edward Yourdon, Managing the Structured Techníques, 3.” ed. Nova lorque: YOURDON
Press, 1986.
15. Robert Dunn, Software Defect Removal. Nova lorque: McGraw- Hill, 1984.
16. B. Elspas e outros, ‘An Assessment of Techniques for Proving Pro gram Correctness”, ACM
Computing Surveys, Vol. 4 (junho de
1972), pgs. 97-147.
17. D. Dunlop e V. Basili, «A Comparative Analysis of Functional Cor rectness”, ACM Computing
Su?veys, Vol. 14 (junho de 1982), pgs.
229-244.
549
1. Que atividades de um projeto de desenvolvimento de sistem
começam quando termina a fase de projeto?
2. Quais são os seis motivos pelos quais o analista de sistemas poc
precisar permanecer envolvido com um projeto durante as ativid
des de programação e testes?
3. Se o analista de sistemas for também o líder do projeto, você acn
dita que seja importante que ele conheça as técnicas de program
ção e de testes? Por que?
4. Em sua empresa espera-se que os analistas de sistemas tambér
participem das atividades de projeto e de programação? Você cor
sidera isso uma boa idéia? Por que?
5. Por que o analista de sistemas tende a participar do desenvolv
mento de dados dc teste para um sistema? Quem mais deverá sc
envolvido?
6. O que deve fazer o analista de sistemas se os programadores solici
tarem que ele modifique a especificação do sistema durante a fas
de programação do projeto?
7. O que deve fazer o analista de sistemas se os usuários solicitarem
modificação dos requisitos do sistema depois que os programado
res tiverem começado a implementação do sistema? Quão prováve
é uma situação dessas?

Página 367 de 584
8. Por que é possível que um usuário queira modificar os requisito
do sistema depois de terminada a fase de análise do projeto?
9. Que dificuldades podemos esperar se um analista de sistemas sé
nior tiver de executar todo o serviço de análise de um projeto?
10. Que tipo de reação negativa podemos esperar dos programadore
de uma empresa quando os analistas de sistemas executam toda
as atividades detalhadas dc especificação discutidas através destr
livro?
11. Que tipo de estrutura organizacional pode ser estabelecida para
acomodar a combinação de pessoal sênior/júnior e atividades téc
nicas de alto e baixo nível de um projeto?
12. Se as atividades de análise e de projeto de sistemas tiverem sido
executadas completa e detalhadamcnte podem os aspectos da pro
gramação ser automatizados? Por quê? Você acredita que essa situa
ção possa se modificar nos próximos 5 ou 10 anos?
13. É necessário executar as atividades de análise de sistemas até o
final para que a . possa começar? Por quê?
14. O que significa fast trackir
15. Em que Outras atividades, aléri o desenvolvimento de sistemas, é
utilizada a técnica do fast tracking?
550
16. O que é uma abordagem conservadora de implementação de um sistema? O que é uma
abordagem radical?
17. Quais são os três principais motivos pelos quais o gerente de pro jeto poderia adotar uma
abordagem radical na implementação de
um sistema?
18. Por que a especificação de um sistema não pode ser considerada imutável no final da fase de
análise do projeto?
NOTAS
1 Na verdade, as coisas poderiam ser piores e poderiam ser melho res. A pior situação (do ponto de
vista do programador) é que poderemos não precisar de programadores! Se a especificação de
processos for escrita em uma linguagem suficientemente formal, poderá ser compilada sem
qualquer intervenção humana! Isso já está acontecendo em casos isolados (ex.: especificações de
pro cessos escritas na linguagem ADA e compiladas diretamente). Por outro lado, existe a
possibilidade de que o programador continue a ter um grande trabalho criativo para fazer se o
analista de sistemas redigir a especificação de processos utilizando a abordagem pré- condição/pós-

Página 368 de 584
condição discutida no capítulo 11. Nesse caso, o analista terá especificado as entradas e saídas para
cada módulo, mas terá deixado para o projetista e, em última análise, para o pro gramador, a tarefa
de escolher o melhor algoritmo.
2 Isso não significa quatro a sete anos de trabalho para uma única pessoa, mas, sim, quatro a sete
anos de trabalho para toda a orga nização de sistemas de informações gerenciais. Para mais
detalhes, leia [ 1986].
3 Para linguagens de terceira geração como COBOL, a complexidade
ciclomática é aproximadamente igual ao número de comandos IF
no programa. Para maiores informações, veja [ 19821.
4 Um exemplo de “stub” é um módulo que não executa qualquer processo e se retira tão logo seja
chamado; outro exemplo é um módulo que retorna os mesmos parâmetros de saída, quaisquer que
tenham sido os parâmetros de entrada que lhe tenham sido passados ao ser chamado. Dessa
maneira, os testes top-down ini ciais de um sistema de pagamento podem conter módulos stub que
paguem a todos $100 por semana, independentemente de catego ria profissional; o módulo stub
para cálculo de impostos pode de duzir $10 de impostos do contracheque de cada um. O objetivo
do teste top-down inicial é apenas verificar se o sistema pode fun cionar e se é de fato capaz de
gerar uma série de contracheques de $100.
551
5 LDunn, 19841 e LMyers, 19791 apresentam detalhadas discussões sobre abrangência de testes.
6 Na realidade, o número de casos de testes não é infinito, em virtu de da limitada precisão dos
números armazenados na memória do computador. Se um número for armazenado como um
inteiro, um computador comum permitirá o armazenamento de números até 2 ou talvez 2 Se o
número for de ponto flutuante, poderemos representar números até 10100 ou maiores, mas
normalmente só disporemos dé oito ou nove dígitos significativos de precisão. Desse modo, isso
não representa infinidade, mas, de qualquer maneira, é um número muito, muito grande.
552
24
A MANUTENÇÃO
DA ESPECIFICAÇÃO
Até agora, o principal profissional de processamento de dados era al guém que podia aprender o
suficiente sobre as necessidades das organi zações para e. na linguagem do computador. No futuro,
quando nossa sociedade se tomar irrewgavelmente computadorizada, o principal profissional (será)
alguém que possa aprender o suficiente sobre sistemas computadorizados para espressá-los na
linguagem hu mana. Sem essa pessoa, teremos perdido o controle da sociedade. Essa pessoa é um
engenheiro às avessas. Os mantenedores de software são o inverso dos engenheiros da sociedade.
Nicholas Zvegintzov, editor,
Software Maintenance News
1. Porque é importante manter-se a especificação atualizada.

Página 369 de 584
2. Que tipos dc modificações precisam ser feitas em uma especificação.
Para muitos analistas dc sistemas o projeto está terminado quando as especificações estruturadas
estão prontas e aceitas pelo usuário. Nesse momento, a especificação é entregue à equipe de
implementação com posta por projetistas e programadores que construirão um sistema a partir da
especificação.
Naturalmente, alguns analistas dc sistemas permanecem com o sis tema durante as fases de projeto
e de implementação. Às vezes o analista
553
1
de sistemas atua como gerente de projeto, orientando e dirigindo o esforços da equipe de
implementação. Por vezes o analista de sistema permanece com o projeto para continuar fazendo
análise, isto.é, par continuar atuando como intermediário entre o usuário e a equipe d
implementação. E o analista de sistemas pode ainda estar incumbido d desenvolvimento dos
manuais do usuário, dos dados do teste de aceita ção, do planejamento das instalações e de diversas
outras atividade, complementares que podem ocorrer de forma concorrente com o pro cesso de
implementação.
Entretanto, quase todos os analistas de sistemas deixam o projet após o desenvolvimento ter sido
terminado e o novo sistema ter entrad em operação. Alguns programadores permanecem para
executar ativida des de manutenção, mas, quando termina a fase dc desenvolvimento, festa acaba, e
a maioria dos analistas dc sistemas, projetistas e programa dores é deslocada para novos projetos (e
muitas vezes novas empresas onde possam obter salário superior ao que seu atual empregador pod
pagar!).
Porém o trabalho feito pelo analista de sistemas (todo o trabalh( discutido neste livro) continua a
ser importante. Assim como os pmgra mas devem ser mantidos durante os 5, 10 ou 20 anos da vida
operaciona do sistema, também a especificação precisa ser mantida. Ou, dito d outra forma, vários
aspectos da implementação do sistema serão modi ficados durante o tempo dc vida do sistema, e
para cada uma dessa modificações deve ser feita uma alteração adequada e correspondente n
especificação.
Embora o analista de sistemas original possa não permanecer con o projeto durante seu tempo de
vida operacional, é importante qu deixe um legado que possa ser modificado. Este capítulo discute
manutenção da especificação do sistema.
24.1 PORQUE É IMPORTANTE
A essa altura, você pode estar um tanto confuso; afinal de contas você deve estar pensando, é
perfeitamente óbvio que a especificação d sistema deva ser atualizada. Por que alguém faria de
modo diferente Infelizmente, a história da área do desenvolvimento de sistemas indica outra coisa:
a imensa maioria, provavelmente mais de 80%, dos sistema presentemente em operação não tem
uma declaração exata e atualizada dos requisitos do usuário que o sistema executa.
Isto não é um fenômeno que ocorra apenas na área do processi
mento de dados. Quantas construções centenárias possuem documento
atualizados que descrevam a fiação, os encanamentos, o aquecimento

Página 370 de 584
554
outros detalhes arquiteturais? A verdade nua e crua é que muitas vezes é bem mais fácil fazer uma
correção, um aperfeiçoamento ou uma modificação “de qualquer maneira” cm um sistema do que
começar pela alteração do documento de requisitos, e depois ir propagando a modifi cação pelo
documento de projeto e pela própria implementação. Isso é particularmente verdadeiro quando as
modificações precisam ser feitas para corrigir um problema imediato, premente e urgente .
“Faremos as modificações do documento mais tarde” dirá o encarregado da manuten ção, “mas
primeiro temos que corrigir o problema”. A documentação é a última coisa que alguém deseja
fazer, e muitas vezes acaba por não sex feita.
Os sistemas de informações têm uma importante característica rela tiva á manutenção: eles duram
mais que os desenvolvedores ou os usuá rios que estiverem envolvidos no desenvolvimento
original do sistema. Isso também vale para construções; nem o arquiteto e nem o usuário final de
uma residência vitoriana de 1880 está disponível para consultas hoje. E isso vale também para
muitos sistemas dc informações; depois de 10 ou 20 anos, o sistema está sendo usado pela terceira
geração de usuários (alguns dos quais podem não ter idéia dos objetivos originais do
desenvolvimento do sistema) e está sendo mantido pela terceira ge ração de programadores dc
manutenção (alguns dos quais podem não ter idéia do motivo que levou os desenvolvedores
originais a adotarem uma determinada estratégia de projeto) Eis por que Nicholas Zve gintzov
descreve os programadores de manutenção como o “inverso dos engenheiros da sociedade”.
Existe outro ponto importante a respeito de sistemas de informa ções: eles tendem a ser complexos
desde o início, e a complexidade cresce durante os anos de manutenção. Quando um sistema é
simples (digamos, 250 instruções em Pascal) sua manutenção é fácil mesmo não havendo
documentação. Mas um sistema típico tem pelo menos 100.000 instruções de programas; muitos,
dos maiores sistemas em manutenção hoje têm bem mais de 500.000 instruções; e alguns têm mais
de um mi lhão de instruções. Ninguém pode compreender um sistema assim tão complexo,
principalmente se (1) essa pessoa não estava envolvida no desenvolvimento do sistema original e
(2) os requisitos e o projeto do sistema original não estiverem documentados. E, no entanto, isso é
exa tamente o que mais pedimos que os programadores de manutenção façam .
• Existem dezenas, e talvez centenas, de exemplos de organizações com graves problemas de
manutenção do gênero acima descrito. Virtual mente todas as maiores empresas que se
computadorizaram há 20 anos atrás agora estão se defrontando com problemas com, os sistemas de
20 anos cujas implementações são um mistério e, pior ainda, cujos re quisitos dos usuários também
são um mistério.
555
A única solução para essa crise no futuro é conservar a documen tação correta e atualizada por
tanto tempo quanto o sistema durar. Ma
como fazê-lo?
24.2 PRÉ-REQUISITOS NECESSÁRIOS
Não se pode conservar atualizado um sistema e a documentação ele associada se essa
documentação não estiver correta. Assim, eis ponto de partida: precisamos ,garanhir que, quando
um sistema entra em operação, todos os documentos a ele relativos estejam completos consistentes,

Página 371 de 584
corretos e atualizados.
Através deste livro, discutimos as características de um modelo cor reto dos requisitos do usuário e
as diretrizes para assegurar que o mo delo de sistema seja completo e internamente consistente.
Para que manutenção continuada tenha sucesso, essas diretrizes devem ser impos. tas e uma pessoa
ou grupo independente deve verificar se a documenta. ção está correta antes que o sistema seja
posto em operação.
Além de nos certificarmos de que os documentos estão corretos, devemos nos assegurar de que
existe um mecanismo para executa, modificações continuadas nesses documentos. Não convém
que a espe cificação estruturada tenha sido inscrita para sempre com uma pena de aço inoxidável
em placas de pedra como uma permanente recordação para as futuras gerações; a especificação
deve ser vista como um docu mento vivo, sujeito a alterações constantes, apesar de controladas.
24.3 COMO FAZER
A primeira e mais básica regra da manutenção de sistemas é esta:
qualquer modificação proposta do sistema operativo atual deve, em todos os casos, iniciar-se por
um exame dos impactos na especificação de requisitos do sistema. Isso deve ser feito em todos os
casos apresenta dos a seguir, juntamente com qualquer outra proposta de modificação do sistema:
• O usuário decide que gostaria de acrescentar uma nova função ao sistema atual.
• O usuário não está satisfeito com a maneira como uma função atual é executada e deseja
modificá-la.
• O usuário quer um novo relatório de saída além dos que já existem.
556
• O usuário quer modificar o formato ou a organizaç de um re latório de saída já existente.
• Os programadores de manutenção desejam refazer um módulo para torná-lo mais eficiente.
• O departamento de operações anunciou que planeja elevar o nível dos sistemas computacionais
da empresa e que serão ne cessárias determinadas modificações.
• O usuário reclama que o sistema produz saídas incorretas para determinada combinação dc
entradas.
• O setor de desenvolvimento dc sistemas decidiu adotar Ada como nova linguagem padrão de
programação. Estão sendo preparados os planos para converter todo o software existente para
aquela linguagem.
• Foi determinado que o sistema passasse a remeter relatórios de saída para uma nova agência do
governo, que ainda não existia
quando o sistema foi originalmente desenvolvido.
Qualquer modificação desse tipo deve ser ilustrada, documentada e verificada com o usuário,
fazendo-se as adequadas modificações no modelo do sistema. Isso costuma ser feito pelo
preenchimento de um formulário conhecido como solicitação de alteração de sistema. A modi
ficação de manutenção pode envolver algum dos itens abaixo ou todos eles:
• Pode ser necessário acrescentar novos terminadores ao dia grama de contexto, ou eliminar

Página 372 de 584
terminadores. Pode ser ne cessário acrescentar, eliminar ou modificar fluxos de dados entre o
sistema e os terminadores. Funções anteriormente executadas por terminadores podem precisar
agora ser executadas no inte rior do sistema; de modo inverso, funções executadas pelo sis tema
podem agora ser consideradas fora do sistema e dentro do domínio de um terminador.
• Pode ser necessário acrescentar novos eventos à lista de even tos, ou pode ser necessário eliminar
eventos existentes.
• Se a modificação for substancial, pode ser necessário alterar a declaração de objetivos no modelo
ambiental.
557
• Pode ser necessário modificar os modelos de fluxo de dados, d entidades-relacionamentos e/ou de
transições de estado.
• Pode ser necessário refinar ou modificar as especificações d processos e o dicionário de dados.
• Pode ser necessário modificar diversos aspectos do modelo d implementação do usuário,
envolvendo a interface homem máquina, as restrições de implementação relativas a tempo d
resposta etc.
Qualquer modificação desse gênero não será livre. É possível qu algumas modificações sejam
mínimas e só requeiram alguns minutos d trabalho para serem incorporadas - apenas alguns
minutos para seren feitas as necessárias alterações à especificação e aos programas existen tes.
Entretanto, a pessoa ou grupo responsável pela alteração tem a obri gação de escrever a declaração
de trnpacto: uma declaração precisa detalhada das mudanças que terão de ser feitas na
especificação do sis tema para implementar a modificação proposta. Juntamente com isso deve
haver uma declaração do impacto econômico: uma declaração dc custo da implementação da
alteração e o benefício estimado que deriva. rá daquela alteração. Isso é especialmente importante
se a atividade dc manutenção mudará o escopo do sistema.
Naturalmente, há algumas modificações que não causam impacto na especificação do sistema: a
correção de um erro de um programa, a modificação do código para melhorar a legibilidade ou a
eficiência do sistema ou uma mudança do hardware existente ou do software de siste ma (o
compilador, o sistema operacional, o sistema de gerenciamento de banco de dados etc.). Contudo,
mesmo nesses casos, deve ser emitida uma declaração do impacto econômico para que o usuário e
o setor de desenvolvimento de sistemas sejam informados dos custos e benefícios relacionados
àquela alteração.
Qualquer modificação feita em um sistema normalmente resulta em uma modificação no software
e/ou no hardware do sistema; pode tam bem causar a alteração dos manuais, dos procedimentos de
operação e de vários outros componentes do sistema. Porém o documento mais importante a ser
mantido atualizado é a declaração de requisilos do usuário! Sem isso, as futuras modificações serão
cada vez mais difíceis de serem feitas; e a mudança para um novo sistema será infinitamente mais
dispendiosa, mais consumidora de tempo e mais penosa do que
normalmente seria. -
Não há dúvida de que esta insistência por um especificação de
sistema atualizada seria vista com desconfiança por um veterano analista

Página 373 de 584
de sistemas com 20 anos de experiência. Afinal, o processo de análise de
558
sistemas tem sido tão difícil por tantos anos bem como a tarefa de desen volver especificações
corretas, que a idéia de mantê-la permanentemente atualizada parece quase ridícula.
A resposta, a longo prazo, será a automatização. Agora já estão disponíveis estações de trabalho
automatizadas de análise de sistemas do tipo descrito no ap&idice A a preços módicos. Elas
representam um substancial avanço sobre a tecnologia usada pela maioria dos analistas de sistemas
de hoje em dia, assim como os sistemas de processamento de palavras representam um enorme
aperfeiçoamento sobre as máquinas de escrever elétricas dos anos 60. Estão em andamento planos
mais ambiciosos para desenvolver ambientes de engenharia de software inte grados e abrangentes
que servirão como rcpositórios centrais para todos os documentos relativos ao desenvolvimento de
um sistema. Entretanto, essa avançada tecnologia provavelmente não estará totalmente desenvol
vida até meados dos anos 90.
Contudo, ainda há muito a ser feito mesmo com a tecnologia hoje disponível. Simplesmente não há
desculpa para fazer-se uma modifica ção em um sistema sem que se efetue a correspondente
alteração na especificação do sistema. Para fazer com que isso funcione, entretanto, é necessária
uma gerência forte e disciplinada na organização de gerencia mento de sistemas de informações.
24.4 RESUMO
Existe um crescente volume de obras sobre o tema da manutenção de software, e pelo menos uma
sociedade profissional (a Software Main tenance Association) dedicada aos problemas da
manutenção. Entretan to, a maior parte da ênfase atual é voltada para a gerência e para a renovação
de programas já existentes; existe também alguma ênfase no uso de boas técnicas de projeto para a
criação de programas manutení veis. Mas a indústria do desenvolvimento dc sistemas somente
agora está começando a compreender que sem espec manuteníveis nunca teremos software
manutenível.
REFERÊNCIAS
1. . Bennett Lienta e B. Swanson, Software Maintenance Management. Reading, Mass.: Addison-
Wesley, 1980.
2. James Martin e Carma McClure, Software Maintenace: Tbe Problem and lis Solution.
3. Girish Parikh, editor, Techniques ofProgram and Systems Mainte nance. Lincoln, Neb.:
Ethnotech, Inc., 1980.
559
4. Carma McClure, Managing Software Development and Maintena,
ce. Nova lorque: Van Nostrand Reinhold, 1981.
5. Robert Glass e R.A. Noiseux, Software Maíntenance Guidebocn
6. Ned Chapiri, ‘Software Mairitenance with fourth-generation Lar
guages”, ACM Software Engineering Notes, Volume 9, Número

Página 374 de 584
janeiro de 1984, pgs. 41-42.
7. R.N. Britcher e Jj. Craig, ‘Using Modern Design Practices to Uç
grade Aging Software Systems”, IEEE Software, Volume 3, Númer
3, maio de 1986, pgs. 16-24.
8. Salah Bendifallah e Walt Scacchi, ‘Understanding Maintenanc
Work”, JEEE Transaction.s on Software Engineering, Volume SE
13, Número 3, março de 1987.
1. Por que é necessário que a especificação de um sistema sej:
mantida mesmo depois que o sistema tenha sido totalmenti
desenvolvido?
2. Por que os programadores de manutenção são tentados a modifica
um sistema operativo sem atualizar os correspondentes documen
tos da especificação?
3. Projeto de Pesquisa: Encontre a idade média dos sistemas presen
temente em operação em sua empresa. Algo de maior interesse
descubra por quanto tempo eles devem continuar funcionandc
antes de serem substituídos por novos sistemas.
4. Projeto de Pesquisa: Descubra quantos dos sistemas presentement
em operação têm especificações atualizadas. Os usuários e geren
tes de sua empresa têm conhecimento dessas estatísticas?
5. Que dificuldades são causadas pelo fato de um sistema ser utiliza
do por usuários e mantido por programadores que não participa
ram do desenvolvimento original do sistema?
6. Dê seis exemplos do tipo de modificações que um usuário poderia
querer fazer a um sistema operativo.
7. Por que é possível que novos terminadores tenham que ser acres
centados ao diagrama de contexto durante a manutenção de urr
sistema?
8. Por que é possível que novos eventos tenham que ser acrescenta
dos à lista de eventos durante a manutenção de um sistema?
9. Sob que condições a declaração de objetivos de um sistema pod
ter de ser modificada durante a manutenção?
10. O que é a declaração de impactos? Por que ela é importante?

Página 375 de 584
560
11. Por que costuma ser difícil conservarem-se atualizados os docu mentos da análise de sistemas
(o modelo essencial do sistema) na
maioria das empresas?
12. Que tipos de desenvolvimentos tecnológicos serão provavelmente necessários para assegurar
que os documentos da análise de siste mas serão mantidos atualizados?
NOTAS
1 Um levantamento em lLientz e Swanson, 19801 mostrou que aproxi madamente 9 de todo o
trabalho de manutenção consiste em
“apuros emergenciais de programas”.
2 Um estudo efetuado nos anos 70 pela fabricante britânica de com putadores ICL indicou que o
sistema típico era mantido por sete aerações de programadores de manutenção antes de ser
finalmente alijado. Isso dá a entender que boa parte do que denominamos de programação de
manutenção poderia ser descrita mais exatamente como arqueologia.
3 Um dos exemplos mais extremos de um sistema grande e comple xo com requisitos de
manutenção continuada é o projeto da Esta ção Espacial presentemente em desenvolvimento pela
NASA. Seu objetivo: colonizar e industrializar as proximidades do sistema solar. Seu prazo
previsto de desenvolvimento: 30 anos. Ele necessi tará de permanenle manutenção.
561
25
O FUTURO DA ANÁLISE
E STRUTURADA
Todas as tentativas de previsão do futuro em qualquer nível de detalhe parecem ridículas em
poucos anos. Este livro tem um alvo mais realista, e também mais ambicioso. Ele não tenta
descrever o futuro, mas apenas definir as flvnteiras dentro das quais o futuro poderá estar. Se
encarar mos os tempos que se estendem adiante de nós como uma região ignota e inexplorada,
quero descobrir suas fronteiras e ter alguma idéia de sua extensão. Os detalhes geográficos de seu
interior permanecerão desco nhecidos - até que lá estejamos.
Arthur C. Clarke, Profiles of lhe Future
Através deste livro vimos a evolução de idéias e técnicas na área
da análise de sistemas. Elas enquadram-se em três largos períodos de
tempo:
1. Análise de sistemas convencional, até meados da década de 70; caracterizada (se o fosse) por
especificações narrativas seme lhantes a novelas vitorianas, dificeis dc ler e compreender, e
virtualmente impossíveis de manter.
2. Análise estruturada clássica, de meados dos anos 70 a meados dos anos 80, como descrito em [
19781, [ e Sarson, 1977] e outros. Ela caracterizava-se por versões iniciais de modelos gráficos e

Página 376 de 584
pela ênfase na modelagem de imple mentações atuais de um sistema antes da modelagem do novo
sistema.
3. Análise estruturada moderna, mostrada neste livro e em outras obras recentes, como IWard e
Meilor, 1985] e [ e
Palmer, 19841.
563
Este capítulo resume algumas das maiores mudanças ocorra desde a apresentação da análise
estruturada clássica no final dos anos e utiliza o tema como ponto de partida para uma discussão
sobre prováveis modificações nos próximos 5 a 10 anos.
25.1 O QUE MUDOU
Alguns aspectos da análise estruturada modificaram-se gradu:
mente durante os últimos dez anos. As principais áreas de mudanç
incluem:
Mudanças da terminologia. Agora utilizamos a expressão m delo ambiental como meio de
descrevermos o que se costuma’ chamar de diagrama de contexto. Isso deve-se ao fato de a an use
estruturada clássica não incluir a lista de eventos como par do modelo formal do sistema. Além
disso, agora utilizamos termo essencial ao invés de lógico, para descrever o modelo qi. se
concentra naquilo que o sistema deve fazer, e a palavra í plementação em lugar de fisico para
descrever o modelo volta para como o sistema deve ser desenvolvido. Essas são, evident mente,
modificações menores, mas elas auxiliaram a reduzir confusão ao se tratar com usuários que
pensam que o oposto um sistema lógico seja um sistema ilógico.
• Subdivisão de evento.s. Um dos mais significativos avanços análise estruturada, que discutimos
nos capítulos 20 e 21, é utilização de uma lista de eventos para orientar o desenvol mento inicial do
modelo comportamental. Ela substitui a abc dagem da estrita subdivisão top-down do diagrama de
contex ao diagrama de fluxo de dados de nível superior (figura 0) e figura O aos níveis inferiores, e
assim por diante. Embora abordagem top-down não seja errada sob qualquer sentido palavra, tem
sido de utilização dilicil para muitos analistas sistemas; a abordagem de subdivisão de eventos, que
é un abordagem middle-out, provou ter tido mais sucesso em muit projetos de análise.
• Diminuição da ênfase no modelo fisico atual. Como o capíti lo 17 ressaltou, existem vários
motivos para que o analista sistemas sea tentado a modelar a implementação atual de u sistema.
Porém, freqüentemente percebemos ser essa un
564
tentação perigosa e que o analista de sistemas despende mais tempo nessa atividade do que ela
merece. Embora não preten damos declarar fora da lei o modelo fisico atual, nós desencora jamos e
desenfatizamos sua utilização. A análise estruturada moderna enfatiza o desenvolvimento, logo que
possível, do modelo essencial do novo sistema do usuário.
Ferramentas de modelagem de tempo-real. A análise estruturada clássica era inicialmente voltada
para o desenvolvimento de sis temas comerciais diretos; ela não tratava de problemas de inter
rupções, sinais e tempo. Entretanto, muitos dos complexos sis temas de hoje incluem diversos
aspectos de tempo-real, e as ferramentas de modelagem da análise estruturada foram estendi das de

Página 377 de 584
acordo. Os fluxos de controle e processos de controle foram utilizados para aumentar os diagramas
de fluxos de dados; e os diagramas de transições de estado foram apresenta dos como uma nova
ferramenta de modelagem para representar os requisitos de tempo-dependência de um sistema.
• Estreita Integração entre a modelagem de processos e a modela gem de dados. A análise
estruturada clássica utilizava diagramas de estruturas de dados para modelar o relacionamento entre
os depósitos de um diagrama de fluxo de dados. Entretanto, os relacionamentos eram muitas vezes
obscurecidos pela notação, que tendia a provocar intensas discussões e debates sobre o projeto e a
implementação do banco de dados fisico. O dia grama de entidades-relacionamentos apresentado
neste livro oferece um modelo mais lógico ou conceitual dos dados exi gidos pelo sistema, e
possibilita que os relacionamentos entre as entidades de. dados sejam descritas rigorosa e
detalhadamente. Além disso, as normas de balanceamento discutidas no capítulo 14 asseguram que
o modelo de dados (documentado com os DER) seja totalmente consistente e compatível com o
modelo de processos (documentado com os DFD e especificações de processos).
Não é importante que você esteja familiarizado com essas modifi cações, porque você pode estar
trabalhando em uma empresa que ainda não incorporou as alterações a seus padrões; em 1987,
quando este livro estava sendo escrito, muitas grandes empresas que visitei nos Estados Unidos
ainda estavam utilizando métodos de desenvolvimento de siste mas de pelo menos 10 anos atrás.
565
25.2 FUTUROS DESENVOLVIMENTOS DA ANÁLISE
ESTRUTURADA
Ninguém pode ter a pretensão de conhecer o futuro; o máxim que se pode esperar é, como diz
Arthur C. Clarke na introdução dest capítulo, encontrar alguns sinais do futuro. Avanços recentes
sugerer várias tendências que provavelmente se estenderão à próxima décad As tendências SãO:
25.2.1 Maior Disseminação do Interesse pela Análise de
Sistemas
Os computadores, como sabemos, estão tornando-se uma part ubiqua da vida de todos. Em
conseqüência disso, uma parte gradua mente maior da sociedade está aprendendo a utilizá-los e a
falar sobr eles; um aspecto ainda mais importante (no contexto deste livro) é qu muitas pessoas
estão gradualmente tornando-se familiarizadas com análise estruturada e com outros aspectos da
engenharia de software. E estou particularmente interessado no futuro impacto da análise estrutun
da em três grupos: a alta direção de nossas organizações empresariais governamentais, crianças e
profissionais do processamento de dados no países do Terceiro Mundo.
Na maioria das grandes organizações, os componentes dos nívei superiores de direção são,
normalmente, pessoas entre 40 e 60 anos d idade, o que significa que foram educadas e passaram
pelos anos d formação de suas carreiras há 20, 30 ou 40 anos atrás. Os computadore como é sabido,
já existiam há 20 anos (e mesmo 30 anos atrás), mas nã estavam amplamente disponíveis nem
faziam parte da tecnologia ou d cultura com que essas pessoas cresceram. Mas isso está começando
mudar; estamos começando a ver pessoas de níveis elevados de chefi que ou (1) iniciaram suas
carreiras nos setores de processamento d dados ou de MIS (Management Information Systems -
Sistemas de Ir formações Gerenciais - SIG) 1, ou (2) começaram em alguma outra part da
organização (contabilidade, vendas, fabricação etc.) cuja operaçã diária foi substancialmente

Página 378 de 584
afetada pela tecnologia computacional. Iss quer dizer que você pode esperar, como analista de
sistemas, que a alt direção se torne progressivamente cônscia da estratégica importânci dos
sistemas de processamento de informações em sua empresa e pr gressivamente interessada em
examinar modelos de alto nível dos princ pais sistemas novos. Se você tentasse mostrar um fluxo
de dados a executivo principal de sua empresa hoje, é provável que ele não o er tendesse e nem
quisesse compreender porque devería entender. Der tio dos próximos 5 anos, creio que a alta
direção entenderá que é tã
566
importante ser capaz de ler (e criticar) um modelo de sistema quanto o é ler e criticar um balanço
ou um demonstrativo de lucros e perdas.
As crianças também tornar-se-ão mais familiarizadas com a análise estruturada nos próximos anos.
A programação estruturada e o projeto estruturado já estão sendo ensinados no segundo grau
escolar em algu mas partes dos Estados Unidos. A análise estruturada, que antes era matéria dos
seminários do nível de graduação, agora é ensinada no terceiro e quarto anos dos curriculos
universitários da ciência da compu tação e das escolas comerciais, e logo fará parte de uma matéria
padrão do primeiro ano universitário. Divisões longas eram assunto do curso superior e agora são
ensinadas às crianças; a análise estruturada será igualmente um tópico que as crianças aprenderão
durante seu processo educacional normal.
Foi feita uma estimativa de que uma criança nascida em 1980 estará formada na escola secundária
no final do século, tendo escrito 10.000 linhas de código; isso equivale aproximadamente a dois
anos de expe riência de programação em tempo integral de um programador adulto de hoje.
Durante essa experiência em programação, prevê-se que a geração atual de jovens adquirirá
crescente experiência com o projeto e a análise de sistemas. Nem todos os componentes dessa
geração seguirão a profis são de programador ou de analista de sistemas; na verdade, apenas uma
pequena fração se decidirá por essas carreiras. Mas as demais crianças dos dias atuais, quer
prefiram ser contadores ou engenheiros, comercian tes, professores ou políticos, formarão uma
comunidade de usuários finais inteligentes de sistemas de informações; os usuários saberão muito
mais sobre o que podem esperar de um analista de sistemas e sobre o que lhe pode ser solicitado.
Grande parte de nosso trabalho atual, de vida, aparentemente, à dificuldade de tratar com usuários
ignorantes, poderá ser desnecessária no futuro.
Existe um outro aspecto do crescente interesse pela análise estrutu rada que merece ser
mencionado: o impacto nas indústrias de software do Terceiro Mundo. Na década passada, a
competição internacional em diversas indústrias manufatureiras intensificou-se e as indústrias
america nas muitas vezes perderam terreno (ou foram alijadas) na competição com as indústrias
japonesa, coreana, chinesa ou brasileira, que oferecem produtos de alta qualidade a preços
competitivos. O mesmo fenômeno está começando a acontecer na indústria de desenvolvimento de
siste mas. As técnicas de engenharia de software, incluindo as técnicas de análise estruturada
discutidas neSte livro, podem auxiliar as organizações competitivas a desenvolverem sistemas com
produtividade dez vezes superior à de muitas organizações americanas e com nível de qualidade
(expresso em tempo médio entre falhas ou número de erros) cem vezes maior que os das
organizações americanas comparáveis 2 E, tendo em vista que, em grau crescente, todos os nossos
produtos e todos os nossos

Página 379 de 584
serviços dependem de sistemas de informações fundamentados ei computadores, isso tem
profundas implicações para toda a indústri americana.
25.2.2 A Pro4feração das Ferramentas Automatizadas
No decorrer deste livro mencionamos a possibilidade da utilizaçã de ferramentas baseadas em
estações de trabalho para automatizar clivei sos aspectos da análise estruturada, particularmente as
atividades d intenso labor como a criação de modelos gráficos de sistemas e a verifi cação da
completude e correção deles.
O apêndice A descreve as características de muitas dessas ferra mentas do analista que estavam
disponíveis no mercado por volta di 1987, bem como os recursos que provavelmente serão
acrescentados ao produtos comerciais nos próximos anos, O que interessa é que esse produtos
existem agora, e tornar-se-ão crescentemente poderosos n:
próxima década.
Porém, poucos analistas utilizam essas ferramentas hoje. Em 198 estimava-se que menos de 2%
dos analistas de sistemas na América dc Norte e na Europa tinham acesso pessoal a uma ferramenta
automatiza da adequada. Isso significa que a típica empresa de desenvolvimento d sistemas tem
uma ou duas estações de trabalho para desenhar diagrama de fluxo de dados, diagramas de
entidades-relacionamentos etc. Essa estações de trabalho podem ser compartilhadas por toda uma
organi zação de cem ou mais pessoas, mas são muitas vezes mais utilizadas poi uma equipe isolada
de projeto que teve a sorte, a tenacidade ou a c rividência de investir nessa tecnologia.
Estima-se que por volta de 1990 aproximadamente 10% dos analis tas de sistemas na América do
Norte e na Europa (e em outras regiõe civilizadas do mundo) terão suas próprias estações pessoais
de trabalho E em meados dos anos 90 é razoável esperar que pelo menos 50% do analistas terão
suas próprias estações de trabalho. Quando tivermos obti do essa massa crítica será razoável
argumentar que nossa abordagem análise de sistemas modificou-se fundamentalmente, porque a
maiorii dos analistas praticantes estará utilizando novas e poderosas ferramentas, Para fazer uma
analogia: é interessante falar a respeito dos melhoramen. tos que podem ser obtidos na área da
carpintaria utilizando-se uma serra elétrica ao invés de sua congênere manual, mas o assunto é
discutível sc apenas 1% das carpintarias dispuser de eletricidade. E o poder da ferra. menta afeta
realmente o modo como lidamos com o mundo à nossa volta; Craig Brod falou sobre isso com
muita eloqüência em um clássicc livro intitulado Technostress (EBrod, 19841):
568
As ferramentas sempre causaram grandes mudanças nas sociedades humanas. Elas nos criam da
mesma forma como nós as criamos. A lança, por exemplo, fez muito mais do que estender o
alcance do ca çador; ela mudou sua maneira de andar e a utilização de seus braços. Ela estimulou a
melhor coordenação olhos-mãos; ela con duziu às organizações sociais pelo rastreamento, abate e
reco lhimento de grandes presas. Ela ampliou a distância entre o caçador inábil e o caçador hábil e
tornou o acúmulo de informações mais importante quando as caçadas tomaram-se mais complexas.
Houve outros efeitos menos evidentes: alterações na dieta dos grupos caçadores levaram ao
compartilhamento da comida e à formação de novas relações sociais. O valor da habilidade
artesanal nasceu. As pessoas começaram a planejar antecipadamente, armazenando ar mas para
reutilização. Todas essas novas necessidades relativas às ferramentas, por sua vez, estimularam

Página 380 de 584
maior desenvolvimento do cérebro. A complexidade do cérebro levou a novos utensílios, e novos
utensílios tornaram os cérebros ainda mais complexos van tajosos para a sobrevivência da espécie.
A esta altura, parece evidente que a tecnologia de ferramentas automatizadas continuará a progredir
durante os próximos 10 anos. O estojo de ferramentas do analista dos meados da década de 90
quase certamente terá sofisticados recursos de verificação de erros e a capaci dade de gerar código
e até sugerir (usando técnicas de inteligência artificial) possibilidades de reutilização de códigos de
bibliotecas de software.
25.2.3 O Impacto dos Desastres da Manutenção
No capítulo anterior discutimos o uso do modelo de análise estruturada para facilitar a manutenção
e a modificação contínuas de sistemas. Porém, esse é um problema que muitas vezes parece
abstrato, filosófico e politicamente sem imporiancia durante a fase de desenvolvimento de um
projeto, quando a ênfase principal parece ser conseguir entregar o sistema ao usuário. De
preferência, um sistema que funcione; se possível o sistema que o usuário desejava. Mas, no caso
disso falhar, qualquer sistema que pareça funcionar e satisfaça ao menos alguns dos requisitos do
usuário. A realidade política é simplesmente a seguinte: a importância da análise estruturada e dos
rigorosos e formais modelos de sistemas não foi totalmente compreendida por muitos dirigentes de
nossas organiza çôes. Mesmo nas fileiras do gerenciamento de PED, a análise estruturada não
merece o mesmo entranhado sentimento de urgência que a necessi dade política de entregar-se em
tempo ao usuário um sistema que fun cione (ou que conste estar funcionando).
569
Como já sugeri anteriormente, essa situação pode modificar-s quando a população usuária
conhecer melhor a tecnologia do processa mento e quando a competitividade dos países do
Terceiro Mundo tomai se mais intensa. Existe, porém, um Outro fenômeno que evidenciará
necessidade de modelos de sistemas atualizados que sejam mantidos d forma tão diligente quanto
os programas-fonte: desastres de manurenØ que farão os sistemas atuais entrarem em colapso.
No caso mais extremo, isso pode fazer com que um sistema exi tente - um grande, complexo e não
documentado sistema - termin anormalmente, ou pare, sem que alguém seja capaz de imaginar com
repará-lo. Mas isso é difícil de ocorrer; é mais provável que a causa d falha seja identificada e
simplesmente expurgada. A advertência ser ‘Não se pode mais introduzir uma transação tipo X25
no sistema porqu causa problemas”.
Não, a causa provável de um grande desastre de manutenção é total impossibilidade de fazer-se
uma necessária e uigente mod de um sistema. Essas modificações muitas vezes são determinadas
pc nova legislação ou pela política governamental; mas também podem se necessárias por causa de
mudanças no ambiente da empresa ou n:
situação da competição.
Muitas empresas já estão enfrentando esse problema; muitos do sistemas projetados no final dos
anos 60 ou no início dos 70 estão à beir:
do colapso, e isso um dia acontecerá. Parte do problema estará relacio nado à Implementação do
sistema, isto é, o código já foi emendado remendado tantas vezes que não é mais possível
determinar com exati dão como o sistema funciona.
Mas o maioL problema, em minha opinião, é que ninguém sabe oi lembra o que esses iistemas

Página 381 de 584
realmente devem fazer. A terceira geraçã de programadores de manutenção está agora interagindo
com usuário de terceira geração para discutir possíveis modificações em um sistem:
cujos requisitos originais são um mistério para todos. Nesse ambiente, inevitável que os
programadores de manutenção um dia cruzem os bra ços e se recusem a fazer mais alterações.
Ao defrontar-se com um problema desse gênero, a alta direção ter:
provavelmente uma reação automática: comissões serão formadas, nor mas serão impostas e novos
procedimentos serão exigidos. Assim com temos visto líderes do governo reagirem a problemas de
resíduos tóxi cos, derramamentos de petróleo, corrupção e vários outros problemas somente depois
da ocorrência de um grande desastre, acredito qu muitos dirigentes da cúpula empresarial e
governamental reagirão a problema de modelos não existentes de sistemas somente após have
ocorrido um sério problema de manutenção.
570
25.2.4 O Casamento entre a Análise Estruturada e a Inteligência A rt
No momento em que este livro está sendo escrito, uma imensa atenção está sendo devotada pelas
empresas, pelo governo e pela indús tria do processamento de dados à inteligência artificial (IA):
sistemas especialistas, sistemas em linguagem natural, robótica e muitos assuntos conexos. Embora
a IA tenha um dia sido considerada um assunto aca dêmico de pouca aplicação prática, e apesar de
ter sido implementada em hardware exótico com linguagens de programação incomuns como LISP
e PROLOG, ela agora está tornando-se um tema de crescente impor tância - principalmente a área
de sistemas especialistas, os sistemas que podem imitar o comportamento de pessoas peritas em
certos campos estreitamente definidos.
Um crescente número de pacotes de software e de livros de IA está disponível para ambientes
baseados em COBOL e em PC (veja, por exemplo, [ 19851, [ 19851, [ 1985), [ 1986] e [ 19851.
Uma crescente quantidade de aplicações de IA, de diagnós ticos médicos a exploração de petróleo,
avaliações comerciais e planeja mento de impostos, estão entrando no fluxo principal do mundo
dos negócios .
O que isso tem a ver com a análise estruturada? A conexão entre a inteligência artificial e os
sistemas especialistas funciona em ambas as direções: a análise estruturada pode auxiliar no
processo de construção de um sistema especialista, e a tecnologia dos sistemas especialistas e
ajudar no processo de análise estruturada.
Quando se constrói um sistema especialista, três aspectos do siste ma podem ser dominantes: a
incerface homem-máquina, a representação do conhecimento e o mecanismo de inferência que
avalia e interroga o banco de conhecimentos. A interface homem-máquina pode envolver entradas
em linguagem natural (Inglês, Francês, Alemão etc.) e uma combinação de gráficos, texto e som
como saída. O banco de conheci mentos pode ser expresso como uma série de regras IF-THEN-
ELSE ou como uma série de quadros . O mecanismo de inferência pode basear- se na técnica de
caminhamento em avanço (forward chaining) ou na de carninhamento retrospectivo (backward
chaining) e ser implementado com uma ‘export shell” oferecida por um fornecedor.
Mas o que há de significativo sobre tudo isso é que os componen tes dos sistemas especialistas
estão agora tornando-se parte de um siste ma maior, por exemplo, um sistema operativo que
alimenta e atualiza o banco de conhecimentos ou que utiliza a saída do componente do siste ma

Página 382 de 584
especialista para executar outras funções do sistema. Assim, as fer ramentas de modelagem da
análise estruturada podem ser usadas para
571
auxiliar a modelar o sistema geral. Porém, ainda mais importante, is quer dizer que durante os
próximos 5 ou 10 anos, você terá que aprei der a tecnologia dos sistemas especialistas e artificiais
para poder ser ui bom analista de sistemas, O livro de Kelier (IKelIer, 1986)) é um boi meio para
começar, já que ele mostra muitas das interações entre análise estruturada e os sistemas
especialistas.
Em sentido inverso, a IA pode auxiliar no processo de análise e truturada, agindo como um guia
para um analista júnior através d; diversas etapas e processos descritos neste livro. Pode-se
facilmeni imaginar, por exemplo, um “analista assistente” que responderia un’ série de perguntas
do analista humano e que produziria um diagrama c contexto proposto ou uma lista de eventos.
Pense um pouco: você coi segue recordar, agora que atingiu o fim do livro, todas as normas
diretrizes das centenas de páginas lidas? Você acredita que se lembrai delas daqui a um ano? Não
seria ótimo ter um sistema especialista disp nível em um PC que o pudesse lembrar de como
desenhar DFD, DER STD que fossem corretamente equilibrados?
Embora isto seja entusiamante, você não deve imaginar que ( sistemas especialistas afastarão os
analistas humanos. Os pesquisador nesta área indicam que todos os sistemas especialistas bem-
sucedido de diagnosticadores médicos a analisadores de documentos, devem es sucesso ao fato de
concentrarem-se em um domínio muito limitado d conhecimento. Um analista de sistemas,
portanto, realmente precisa s perito em diversas áreas diferentes: ele precisa conhecer a tecnologia
d análise estruturada apresentada neste livro; precisa conhecer a área d aplicação do usuário; tem
que saber bastante sobre contabilidade, pai poder produzir cálculos exatos de custo/beneficio; deve
ser perito ei comunicações e psicologia cogniuva, para poder comunicar-se de mod eficaz com o
usuário; e também deve ser versado em hardware e sof ware de computadores, para poder
comunicar-se eficazmente com c projetistas e os programadores. As estimativas atuais (veja, por
exemph EBarstow, 19871 são de que os sistemas especialistas estarão aptos a aux liar na tarefa do
analista em sistemas simples em meados da década d 90, mas só depois do fim do século é que a
tecnologia dos sistemas ei pecialistas será capaz de fazer a análise de grandes sistemas.
25.2.5 O Impacto das Novas Gerações de Hardware
Enormes somas de dinheiro estão sendo gastas hoje por empresa privadas, universidades, órgãos de
pesquisa, estabelecimentos militares governos por todo o mundo, com o objetivo de produzir
hardware subi tancialmente mais poderoso durante os próximos 10 ou 15 anos. Uni recente
previsão feita em uma palestra na 1986 FalI Joint Çomput
572
Conference por Gordon Beil, da National Science Foundation, afirmou que a tecnologia do
hardware será aperfeiçoada por um fator de 10 nos próximos 5 anos, e depois por outro fator de 10
nos 5 anos seguintes, e por mais outr fator de 10 nos 5 anos subseqüentes. Na mesma confe rência,
o físico laureado com o prêmio Nobel, Ken Nilson, fez uma previsão ainda mais otimista: um
aperfeiçoamento por um fator de 100 nos próximos 5 anos, seguido por outro fator de 100 nos 5
anos seguin tes e por mais outro fator de 100 nos 5 anos subseqüentes. Desse modo, esses dois

Página 383 de 584
eminentes cientistas sugeriram que dentro dos próximos 10 a 15 anos podemos esperar que o
hardware seja de 10 a 106 vezes mais poderoso que os computadores de hoje.
O que tem isso a ver com análise de sistemas? Simplesmente isto: a definição dos requisitos do
usuário para um sistema de informações deve ser feita dentro do contexto do que o usuário e o
analista de sis temas consideram ser possível com a tecnologia disponível. Mas o que julgamos ser
possível fundamenta-se amplamente no que sabemos agora sobre a tecnologia de computadores.
Pode-se objetar que a maioria dos usuários finais e dos analistas de sistemas sequer utiliza a
tecnologia de hardware existente, e, portanto, o que farão com uma tecnologia um milhão de vezes
mais avançada?
A experiência passada com outros progressos tecnológicos, por exemplo, na área das comunicações
(dos sinais de fumaça ao telégrafo, telefone etc.) e dos transportes (dos cavalos aos automóveis,
aviões etc.) dá-nos uma pista; nossa primeira reação à tecnologia radicalmente aper feiçoada é
continuar fazendo o mesmo tipo de coisas que fazíamos an tes, porém de maneira um pouco mais
rápida e com mais facilidade (e mais economicamente, em muitos casos). Só mais tarde é que
começa mos a vislumbrar aplicações inteiramente novas para a nova tecnologia.
Como exemplo, considere o ramo dos transportes, que todos co nhecemos; embora as viagens
aéreas sejam relativamente novas (compa radas à história da espécie humana), elas têm estado
conosco durante toda a nossa vida e têm um importante impacto na idéia, consciente ou
inconsciente, explícita ou implícita, que fazemos do modo como deve mos viver nossas vidas.
Suponha que alguém lhe diga que um trem supersônico esteja disponível para levá-lo da costa
oriental dos Estados Unidos à costa ocidental à velocidade de 4.800 quilômetros por hora . Qual
seria o efeito disso em sua vida profissional? E em sua vida social? Que tipo de modificações você
começaria a fazer hoje se estivesse ra zoavelmente certo de que essa avançada tecnologia estaria
disponível dentro dos próximos 3 a 5 anos?
É exatamente nessa situação que nos encontramos como analistas de sistemas no restante deste
século; a cada vez que somos brindados com tecnologia de processamento mais poderosa, nossa
primeira reação (e a dos usuários finais, também) é reimplementar as aplicações já
573
existentes de uma forma um pouco mais eficiente, O desafio serã encor trar aplicações Inteiramente
novas - usos inteiramente novos e rad:
calmente d da tecnologia de computação - em relação a aplicações que são presentemente
desenvolvidas.
25.3 CONCLUSÃO
É importante que você tenha uma perspectiva voltada para o futun ao concluir este livro e começar
a praticar análise estruturada no mund real. Embora a modelagem, a resolução iterativa de
problemas, a subdi visão top-down e outras idéias discutidas neste livro serão quase segura mente
válidas para um futuro visível, muitos detalhes (ex.: a tecnologi:
disponível de apoio à análise estruturada e até outras técnicas como subdivisão de eventos) podem
ser modificados ou substituidos.
Você não deve supor que o que aprendeu neste livro seja imutável permanente e imune a
modificações. Como toda ciência, e principalmen te como todos os outros aspectos da ciência da

Página 384 de 584
computação, a área d análise de sistemas está destinada a continuar modificando-se, evoluind e
(esperamos) aperfeiçoando-se durante o século vindouro e além. Pan alguns, é assustador perceber
que metade do que se aprende ness área técnica estará obsoleto em 5 anos. Para outros, e espero
que voc se inclua nesta categoria, isso é uma fonte de constante renovação entusiasmo.
E com essa observação chegamos ao final deste livro. Você aindi não é um veterano analista de
sistemas, mas deve possuir suficiente:
ferramentas e técnicas para iniciar a profissão sem receio de fracassar Possa você desfrutar da
prática da análise estruturada em sistemas d informações que irão beneficiar a sociedade. E que
você retorne err menos de 5 anos para ver o que mudou. Tchau!
REFERÊNCIAS
1. Tom deMarco, Structured Analysis and Systems Spec Englewood Cliffs, N.J.: Prentice-Hall,
1979.
2. Chris Gane e Trish Sarson, Slnsctured Systems Analysis: Tools an Techniques. Englewood
Cliffs, N.J.: Prentice-Hall, 1978.
3. Arthur C. Clarke, Proj’iles of the Future. Nova Jorque: Holt Rinehart, and Winston, 1984.
4. Jared Taylor, “Lighiyear’s Ahead of Paper”, PC Magazine, 16 & abril de 1985.
5. Frank Derfier, “Expert-Ease Makes JÉs Own Rules”, PC Magazine
16 de abril de 1985.
574
6. Robin Webster, «M. 1 Makes a Direct Hit”, PC Magazine, 16 de abril de 1985.
7. Robert E. Kelier, Expert System Technology: Development and Applicalion. Englewood Cliffs,
N.J.: YOURDON Press, 1986.
8. Frank Rose, mb lhe Heart of lhe Mmd. Nova lorque: Harper & Row, 1985.
9. D. Barstow, «Artificial Intelligence and Software Engineering”, Proceedíngs of the 9th
Intemational Conference on Software Engi neering. Washington, D.C.: IEEE Computer Society
Press, março de 1987.
10. Paul Ward e Steve Melior, Structured Development of Real-Time Systems. Nova lorque:
11. Steve McMenamin e John Palmer, Essential Systems Analysis. Nova lorque: YOURDON
Press, 1984.
12. Craig Brod, Technostress. Nova lorque: John Wiley, 1984.
1. Quais são os três grandes estágios evolutivos da análise de sistemas ocorridos nos últimos 20
anos?
2. Quais são as cinco principais modificações ocorridas na área da análise de sistemas nos últimos
10 anos?
3. O que os termos lógico e físico significam no contexto deste capitulo?

Página 385 de 584
4. O que é subdivisão de eventos? O que ela veio substituir na área da análise de sistemas?
5. Por que a modelagem física do sistema atual foi relegada na análise de sistemas?
6. Que ferramentas foram acrescentadas à área da análise de sistemas para auxiliar na modelagem
de sistemas de tempo real?
7. O que é um diagrama de estrutura de dados? Como ele foi substi tuído na área de análise de
sistemas?
8. Como os computadores estão começando a afetar as tarefas e ati vidades dos chefes mais
graduados das organizações?
9. Por que o ensino da análise estruturada e do projeto estruturado às crianças nos anos vindouros
terá impacto nos projetos de desen volvimento de sistemas?
10. . Por que a análise estruturada possivelmente será um fator de competição internacional entre
os Estados Unidos, Europa e muitos
países do Terceiro Mundo?
11. Projeto de Pesquisa: qual a percentagem de programadores e analistas de sistemas que dispõe
de estações de trabalho com es tojo de ferramentas em suas organizações?
575
12. Por que as ferramentas automatizadas são importantes para
análise dé sistemas?
13. Por que os desastres de manutenção terão impacto na anális
estruturada no futuro?
14. Que relações possivelmente haverá no futuro entre a inteligência
artificial e a análise estruturada?
15. Por qual percentagem, ou múltiplo, espera-se que o hardware seja
aperfeiçoado nos próximos 10 a 15 anos?
16. Por que os contínuos aperfeiçoamentos do hardware terão impactc na forma como é feita a
análise de sistemas?
NOTAS
1 Três exemplos são John Reed, atual presidente da Citicop, Richard
Crandail, dirigente da American Airlines, e Frank Lautenberg, que
foi presidente da ADP (empresa de serviços de pagamento de pes
soal) e atualmente é um dos dois senadores por Nova Jersey.
Existem também diversas pessoas que foram programadores e
analistas de sistemas e que hoje são membros do Congresso.
2 Veja a discussão desse assunto em “The Computer Industry in
Japan’, de D. Tajima e T. Matsubara, Computer, Volume 14, n 5

Página 386 de 584
(maio de 1981), pgs. 89-96.
3 Um grande volume de trabalho ainda é executado em hardware de
processamento especializado, com utilização de linguagens de
programação especializadas, como Lisp e Prolog: Entretanto, (1) a
maioria das empresas preferiria integrar suas aplicações de IA com
as outras aplicações que executam em seu hardware de grande
porte padrão IBM, (2) a maioria dos programadores preferiria
utilizar linguagens conhecidas, como COBOL, do que linguagens
esotéricas como Prolog e (3) as aplicações de IA orientadas para os
negócios terão de obter informações por meio de “grampos” no
banco de conhecimentos, que já existe no computador de 8rand
porte.
4 Veja a descrição de quadros em IKelier, 19861.
5 Isso não é ficção científica. Planos sérios de engenharia para esse
trem supersônico foram preparados no MIT.
576
P.
1
4’
A
FERRAMENTAS
AUTOMATIZADAS
O homem é um animal que utiliza ferramentas.... Sem ferramentas ele nada r€presenta, com elas
ele é tudo.
Thomas Carlyle,
Sartor Resartus, Livro 1, Capítulo 4
A.1 OS ANTECEDENTES DAS FERRAMENTAS AUTOMATIZADAS
Uma ferramenta automatizada pode ser definida como algo que substitui o trabalho manual do
programador, do analista de sistemas, ou até do usuário final que precisa informar seus requisitos
aos profissionais da computação. Desse modo, existem muitas coisas que podem ser consideradas
como ferramentas:
Linguagens de programação de alto nível, desde o COBOL e Pascal, até as atuais linguagens de
quarta geração que permitem aos programadores o uso de sentenças semelhantes à linguagem
natural, de alto nível, que são automaticamente convertidas nas instruções primitivas, de baixo
nível, que o computador compreende.

Página 387 de 584
.. Listagens de referências cruzadas, programas de impressão de relatórios, e outros programas
utilitários que oferecem informa ções auxiliares e estáticas sobre seus programas.
Ferramentas de testes e de depura ção, simuladores e con gêneres, que prestam informações ao
programador sobre o
579
comportamento dinâmico de seu programa em tempo de e’ cu As ferramentas de testes auxiliam o
programador a cri uma grande variedade de casos de teste para garantir que u programa seja bem
testado. As ferramentas de depuração aj dam o programador a localizar erros depois de perceber qi
algo está errado. Os simuladores oferecem uma representaç mais visual e gráfica da execuçàó do
programa, por exempi apresentando o programa como um fluxograma na tela do t mina!, e
simulando o comportamento do programa durante execução mostrando o fluxo de controle através
do fluxograni
Terminais de time-sharing (tempo compartilhado) que subs tuem os ambientes de desenvolvimento
batch. Essa batalha travada e vencida há 15 anos na maioria das organizações software, mas é
importante compreender que o terminal time-sharing é uma ferramenta. Nos anos 60 e no início
dos an 70, os programadores tinham de escrever seus programa manualmente, em formulários
adequados; os comandos do pr grama eram depois perfurados em cartões (lembra-se d cartões
perfurados?) e, em seguida, alimentados no computad durante a noite. Se houvesse algum erro (se
o programador vesse escrito um comando sintaticamente incorreto ou se operador da perfuradora
tivesse errado alguma perfuração), s ria entregue um relatório de erros para o programador na m
nhã seguinte. E o ciclo recomeçaria. Tudo isso desapareceu e meados da década de 70 na maioria
das empresas atualmente, programador digita seu programa diretamente em um termin de time-
sharing, concorrentemente com centenas de outros pr gramadores e/ou usuários finais. O programa
pode ter sua cc reção sintática conferida de imediato, o mesmo acontecenc com os testes e com
depuração. Hoje é difícil imaginar-se u ambiente diferente. Mas isso é devido em parte ao fato de
terminais não-inteligentes poderem ser adquiridos por menos $500. Há dez anos o preço estava em
torno dos $3.000 ou mai e ninguém tinha certeza de que um programador merecesse u
investimento dessa envergadura.
Computadores pessoais que possibilitam o desenvolvimento programas ojj-line. Hoje, o
investimento de $3.000 é um comp tador pessoal. Os terminais não-inteligentes são bons, poré
somente se o computador de grande porte ao qual eles est iam ligados pode proporcionar tempo de
resposta rápido consistente para que os programadores possam trabalhar prodi tivamente. A
maioria deles não pode; muitas vezes levam
580
segundos para reagir à mais trivial entrada, e 10 para entradas mais significativas. Uma alternativa
atraente é um computador pessoal que o programador pode uti1izar para elaborar um pro grama,
fazer as correções necessárias e revisões utilizando um programa comum de processamento de
palavras, compilar o programa para ver se há erros de sintaxe que o computador principal rejeitaria,
e executar alguns limitados testes off-line.
Pacotes de controle de código fonte que impedem que um pro-. gramador faça modificações não
autorizadas nas versões oficiais de programas no meio da noite. Nos grandes projetos de pro

Página 388 de 584
gramação, uma das dificuldades é O gerenciamento da configu ração: assegurar a existência de
total controle sobre os vários componentes do sistema final. Cada programador trabalha em sua
própria tarefa e pode necessitar de dezenas de revisões daquela tarefa antes de completá-la. Mas a
parte dele interage com outras partes semelhantes da responsabilidade de diversos outros
programadores. A menos que todos saibam que versão de que parte deve ser considerada a versão
oficial a anarquia será geral. Um pacote de controle de código fonte é como um bibliotecário
automatizado: ele impede a retirada e a adulteração de documentos oficiais.
• Análise de sistemas e bancadas de proj ei o. As ferramentas acima descritas referem-se
principalmente à tarefa de escrever pro gramas (isto é, decidir quais comandos COBOL ou
FORTRAN devem ser utilizados para resolver um bem definido problema). Mas não é aí que reside
a maior dificuldade de se construir um sistema de software. O problema real está nos primeiros
estágios da análise de sistemas (descobrir o que o sistema deve fazer) e de projeto (descobrir como
deve ser a estrutura geral do sistema). Atualmente estamos começando a ver ferramentas que
oferecem auxílio aos analistas de sistemas e projetistas de sistemas.
A maioria das ferramentas acima descritas têm estado disponíveis nos últimos 10 a 15 anos e
muitas são largamente utilizadas nas organiza ções de sistemas de informações gerenciais (SIG).
As bancadas, por outro lado, são muito recentes e mal começam a aparecer na indústria de software
de 1987. São es.sas ferramentas que, em minha opinião, têm a potencialidade de salvar a indústna
amencana de software.
Como pudemos ver neste livro, a análise de sistemas bem-sucedida
é firmemente fundamentada nos modelos do sistema que deve ser
computadorizado. As ferramentas de bancada do analista e do projetista
581
estão relacionadas principalmente com o desenvolvimento eficier desses modelos. Por exemplo,
eles auxiliam o analista de sistemas construir diagramas gráficos que capacitam o usuário final a
entender que o sistema fará para ele. As bancadas também auxiliam o analista e projetista a garantir
que o modelo seja completo, acurado e consisteni de modo a que os erros descobertos no decorrer
da fase de prograrr ção serão apenas erros de programação, e não um reflexo de um m:
entendido permanente entre o usuário final e o analista de sistemas . para finalizar, as bancadas
podem prestar auxilio ao programador i conversão do modelo em um programa atuante.
Futuramente, presuni se que as bancadas automatizarão completamente esse processo.
A indústria de software vem falando em ferramentas como essa 1 cinco anos ou mais; entretanto,
não se fez muito a respeito. Isso se de’ em parte ao fato de a tecnologia de engenharia de software
ainda não i permeado a indústria, porém isso é mais uma questão econômica. Con afirmei, não foi
antes dos meados dos anos 70 que a maioria das orgai zações de SIG aceitou a idéia de que cada
programador deve ter u terminal não-inteligente em sua mesa, e passaram-se outros cinco an para
que muitas empresas realmente adquirissem os terminais e destin2 sem um computador de grande
porte em separado para a equipe desenvolvimento de sistemas (nesse ínterim, dois ou três
programador muitas vezes tinham de compartilhar um terminal, de modo muito sem lhante a duas
ou três pessoas compartilhando o mesmo telefone em u escritório e toda a equipe de
desenvolvimento de sistemas tinha compartilhar o mainframe com centenas de usuários finais

Página 389 de 584
tentan executar trabalho útil em seus terminais).
Nesse meio tempo, os computadores pessoais e as estações i teligentes começaram a aparecer no
mercado consumidor. No final d anos 70 e início dos 80, a maioria dos programadores ignorava
máquinas, por não serem muito poderosas, não pelos padrões mainframe pelos quais eles julgavam
a capacidade de um computadc Uma estação inteligente de poder suficientemente alto, capaz de
auxili o analista/projetista em seus modelos de engenharia de software custal entre $50.000 e
$100.000 por volta de 1980-1981, o que deixava o a sunto fora de cogitações para a maioria das
empresas de SIG. Apen umas poucas organizações com enormes projetos e imensos orçament4
poderiam considerar tal despesa; e o máximo que se podia esperar e uma estação inteligente para
todo um departamento com centenas pessoas. Algumas das primeiras estações foram desenvolvidas
em er presas aeroespaciais, contratadas da defesa e fabricantes de sofisticad estações gráficas de
computadores, mas a comunidade estudiosa corrente principal de SIG desconhecia a idéia.
Por volta de 1983, as coisas começaram a mudar. Poderos
computadores pessoais, com gráficos de alta resolução e adequa
582
capacidade de memória, caíram abaixo da mágica barreira dos $1O.OOO Alguns eram estações
inteligentes orientadas para a engenharia, construí das por novas e agressivas companhias de
computadores, como a Apolio Computer e Sun Computer; alguns foram verdadeiros lampejos de
luz como o computador Lisa da Apple.
A maioria, contudo, revelou-se como configurações personaliza das do popularíssimo computador
pessoal da IBM. Com sua arquitetura aberta, a IBM possibilitou a todos os interessados a
construção de confi gurações de empregos especiais adequadas às suas necessidades. Dessa forma,
a indústria de ferramentas de software pôde construir uma pode rosa estação inteligente composta
pelo chassis de um PC-IBM, pela placa gráfica do fornecedor A, pela expansão de memória do
fornecedor B e um monitor de vídeo de alta resolução do fornecedor C.
A capacidade de construir uma poderosa estação de trabalho com a sigla IBM na parte frontal é de
fundamental importância no mercado. A realidade é que nas empresas comerciais - bancos,
empresas de segu ros, e as agências governamentais não-militares - o computador pessoal deve ter
a sigla IBM no painel frontal; isto, infelizmente, é mais importan te que a superioridade
tecnológica do hardware. As empresas científicas e de engenharia não se preocupam tanto com o
computador que utili zam (embora muitas preferissem que qualquer computador pessoal que
comprassem fosse parecido com o DEC VAX) e as empresas de defesa não se importam com o tipo
de computador que usam, desde que seu custo possa ser incluído no contrato com o governo.
Existem atualmente algumas empresas nos Estados Unidos e na Europa adquirindo produtos de
software e estações de hardware para auxiliarem analistas e projetistas de sistemas. A tabela A.1
apresenta uma lista representativa dos fornecedores e dos produtos que estavam dis poníveis em
1987. Uma das forças impulsoras por trás deste quadro de empresas é a crença de que nos
próximos 5 a 10 anos virtualmente todos os funcionários de colarinho branco dos Estados Unidos e
especialmente todos os programadores, analistas de sistemas, projetistas de sistemas e os usuários
finais de sistemas de processamento, terão um poderoso computador pessoal em suas mesas. O
poder do hardware estará lá; agora tudo que precisamos fazer é ampliar esse poder com uns poucos

Página 390 de 584
recursos adicionais de hardware e alguns software muito poderosos.
A maioria dos produtos funciona nos IBM PC, embora alguns for necedores tenham escolhido o
Apple Macintosh ou os computadores mais poderosos Apollo ou VAX. Virtualmente todos os
produtos ofere cem ao usuário um conjunto de ícones (formas que podem ser utilizadas na criação
de desenhos) e um “mouse” para selecionar os ícones. Isso pode ser-lhe familiar se você já tiver
utilizado programas gráficos como o MacPaint ou MacDraw no Macintosh ou o PC-Draw ou o
EGA-Paint em IBM PC. Entretanto, os produtos de estaçõr3 de trabalho de analistas são
583
Tabela A.1: Fornecedores de Estações Inteligentes para Analista
Fornecedor Produto
AIMS Plus, Inc. Aims Plus
1701 Directors Blvd.
Austin, DC 75234
Cadre Technologies Inc. Teamwork S/A
222 Richmond Sreet
Providence, RI 02903
Cap Gemini Software !vlulti Pro
2350 VaIley View, #420
Dailas, DC 75234
CGI Systems Inc. Pacbase
One Blue Hill Plaza
P.O. Box 1645
Peari River, NY 10965
Computer Corp. ofAmerica PC/Workshop
Four Cambridge Center
Cambridge, MA 02142
Cortex Corp. CorVision
128 Roberts Road
Waltham, MA 02154
DBMS, Inc. Developer Workstauon
1717 Park Street
Napervilie, IL 60540
Iconix Software Engineering, Inc. Iconix
1037 Third Street, Suite 105
Santa Monica, CA 90403

Página 391 de 584
Index Technology Excelerator
101 Main Street
Cambridge, MA 02142
Ken Orr & Associates The Design Machine
1725 Gage Blvd.
Topeka, KS 66604
584
Knowledgeware Information Engineering
3340 Peachtree Road NE Workbench
Atlanta, GA 30326
Meta Systems Structured Architect
315 E.Eisenhower Parkway
Suite 200
Ann Arbor, MI 48104
Nastec Corp. DesignAid
24681 Northeastern Highway
Sothfield, MI 48075
Promod Inc. Promod
22981 Alcade Drive
Laguna Hilis, CA 92653
StarSys, Inc. MacBubbles
11113 Nortee Drive
Silver Spring, MD 20902-3619
Tektronix CASE
P.O. Box 500, Station Y3-314
Beaverton, OR 97077
Yourdon Inc. Analist/Designer Toolkit
1501 Broadway
New York, NY 10036
em número muito maior; eles abrangem o recurso de desenhos. E, como veremos a seguir, eles
dispõem de muitos recursos não encontrados em simples programas de desenho.
A.2 RECURSOS IMPORTANTES EM FERRAMENTAS AUTOMATIZADAS
É fácil pensar em bancadas automatizadas para analistas e projetis tas de sistemas como nada mais
que produtos para desenhar eletronica mente. Certamente é verdadeiro que a capacidade gráfica
desses produ tos é a parte mais visível e mais “sexy”, porém é apenas um de seus importantes

Página 392 de 584
recursos. As bancadas devem oferecer os seguintes recursos para que sua utilização seja
significativa no desenvolvimento de um sis tema complexo:
585
• Suporte gráfico para múltiplos tipos de modelos
• Recursos de verificação de erros para garantir a correção dc modelos
• Referências-cruzadas dos diferentes modelos
• Suporte adicional de engenharia de software
A. 2.1 Suporte Gráfico
Como temos visto neste livro, os modelos da análise estruturad apóiam-se em diversos tipos de
informações: texto, dicionários de dado e diagramas gráficos. Os textos e os dicionários de dados
podem ser au tomatizados com utilização de processadores de palavras e computadc res de grande
porte convencionais; o que sempre faltou foi o suport gráfico. O analista de sistemas precisa de
uma estação inteligente de tra balho que o permita compor, revisar e armazenar os seguintes tipos d
diagramas:
• Diagramas de fluxo de dados (DFD)
• Diagramas estruturais (DE)
• Fluxogramas (FG)
• Diagramas de entidades-relacionamentos (DER)
• Diagramas de transições de estado (DTE)
Desse modo, uma bancada de analista deve possibilitar a compo
sição do DFD mostrado na figura Ai(a).
A tela que o analista contempla ao compor um diagrama desse tipc
é mostrada na figura A.i(b).
Devo dizer que compus esse diagrama utilizando um simples pro grama de desenho chamado
MacDraw em um computador Apple Macintosh, que estou usando para escrever este livro Levei 15
minuro para compor o diagrama e mais 30 segundos para copiá-lo diretamente no texto deste
capítulo. Eu poderia ter desenhado o diagrama manual mente em 3 minutos, colando-o no capítulo
com tesoura e fita gomada em cerca de 3 minutos. A vantagem do suporte gráfico evidentemente
não provém do desenho inicial do diagrama, e sim da facilidade da modificações.
586
:
Figura A.1 (b): Uma típica tela de uma estação de trabalho de analista
587
Figura A.1 (a): Um DFD típico
Figure U.1( _____
Relatório de !defaturas

Página 393 de 584
Em um típico projeto de desenvolvimento de sistemas, um di grama como o da figura A. 1 pode ser
modificado uma dúzia de vezes. N realidade, um analista de sistemas da Tektronix disse-me que
ele e usuário final tinham modificado um DFI) como o da figura A. 1 mais cem vezes até que
finalmente concordassem que ele finalmente era ur modelo correto dos requisitos do usuário
Ninguém em sã consciênci deve pretender redesenhar manualmente um diagrama cem veze
entretanto a introdução de uma pequena mudança em um diagrama n tela de um computador
costuma levar cerca de apenas um minutc Alguns resultados iniciais do Hartford Insurance Group,
que tem mais d 600 estações de trabalho instaladas, apontaram uma melhora da prc dutividade em
torno de 40% devida unicamente ao apoio gráfic automatizado (veja ECrawford, 19851).
Também quero ressaltar que os programas gráficos de empreg geral como o MacDraw ou o
MacPaint (no Macintosh) ou o PC Draw oi EGAPaint (no IBM PC) não são de fato adequados ao
engenheiro d software. Para construirmos modelos formais de engenharia de software devemos
primeiro decidir que ícones, ou simbolos gráficos, serão em pregados. Em seguida devemos definir
regras que definam as proprieda des dos ícones e as conexões válidas entre esses ícones. A figura
AI, p0 exemplo, utiliza os quatro ícones associados a um DFD padrão: o círcu lo, o retângulo, a
notação para depósito de dados e uma linha represen tando o fluxo de dados entre um lugar e outro.
O MacDraw, todavia permitiu-me a inclusão de triângulos, hexágonos e qualquer outra repre
sentação gráfica no diagrama. E o MacDraw não sabe que quando un fluxo de dados é interligado a
uma bolha os dois objetos devem, daí en diante, ser tratados como um grupo ou um objeto
composto Em un nível mais simples, tive dificuldades em criar bolhas (círculos) de tama nho
uniforme, e levei uma eternidade para colocar ponta de setas na extremidades das linhas.
A.2.2 Recursos de Verificação de Erros
Embora o suporte gráfico seja indubitavelmente necessário, ele d modo algum justifica por si só o
dispêndio de $10.000 em uma estaçãc de trabalho. Uma bancada de analista deve examinar o
modelo criad pelo analista ou pelo projetista de sistemas para garantir que esteja completo e
internamente consistente. A figura A.1, por exemplo, deveri ser analisada do seguinte modo:
• Todos os ícones estão interligados? Existe algum depósito di dados ou bolha de processo
flutuando livres pelo diagrama, serr
entradas e saídas?
588
• Todas as bolhas de processo têm pelo menos uma saída? Se não, ela é um possível buraco negro
que devora os dados mas não
produz qualquer saída.
• Todos os fluxos dc dados (as linhas com nomes que interligam os quadros e bolhas) têm nome?
Todos os nomes constam no
• Todos os processos (as bolhas) têm nomes únicos (exclusivos)?
Podem ser feitas veriíicações de erros análogas nos DE, FG, DER e DTE. E essa verificação pode
ser estendida a diferentes níveis de mode lagem. A figura Ai, por exemplo, poderia ser um
subsistema de baixo nível representado por uma única bolha (bolha número 1) em um siste ma de

Página 394 de 584
contabilidade de nível mais elevado modelado na figura A.2.
A bancada do analista deve garantir qua as entradas e saídas mos tradas na figura A.1
correspondam às da bolha 1 da figura A.2. Se não houver essa correspondência o modelo estará
inconsistente e será um inferno algumas semanas (ou meses) mais tarde quando alguém tentar
declaraçóes
Figura A.2: Um DFD de nível mais elevado
589
o de de
-as
converter o modelo gráfico em COBOL. O mesmo tipo de bala ceamento (equilíbrio) pode ser
aplicado a diversos outros modelos qi compõem uma visão top-down de um sistema.
A.2.3 Verificação Cruzada de Diferentes Modelos
O recurso mais importante de uma bancada de trabalho de anali ta/projetista é sua aptidão em
efetuar verificações cruzadas da consi tência dos vários tipos diferentes de modelos de um sistema.
Existe dois aspectos: verificação cruzada de modelos em uma fase do projeto verificação cruzada
de modelos em diferentes fases do projeto.
Na fase de análise de um projeto, por exemplo, o principal objetis é determinar o que o usuário
deseja do sistema, com pouca ou nenhurr referência à específica tecnologia de processamento que
será utiliza para implementar os requisitos. Para isso, precisamos dos DFD para re saltar a divisão
dos requisitos em funções separadas e a interface enti as funções. Precisamos dos DER para
ressaltar os objetos de dados arm:
zenados no sistema e os relacionamentos entre esses objetos. E precis. mos de DTE para ressaltar
os estados em que o sistema pode se encoi trar e o comportamento tempo-dependente desse
sistema. Além dissi utilizamos um dicionário de dados para manter a definição de todos elementos
de dados do sistema e alguma forma de descrição textual pa definir a orientação formal da empresa
para cada função de nível ma baixo do sistema.
O ponto principal é que todos esses modelos devem ser conslstei tes entre si. Se o DFD referir-se a
um elemento de dados que não este presente no dicionário de dados, algo está errado; se o
dicionário d dados definir elementos de dados que não apareçam em qualquer outi modelo, algo
está errado. Se o DFD exibir depósitos de dados que n estejam definidos no DER, existe uma
inconsistência; e se o DER apn sentar objetos que não estejam definidos no dicionário de dados e n
estejam presentes em um DFD, também existe uma inconsistência. Com discutimos no capítulo 14,
toda essa verificação cruzada pode ser feii manualmente, mas, na melhor das hipóteses, é um
processo entediante sujeito a erros. Meus diversos anos de experiência com engenharia d software
em típicos ambientes de SIG permitem-me afirmar com algurr confiança (infelizmente) que essa
atividade não deve ser feita manua mente, apesar das exortações dos gerentes de projeto e das
melhor intenções dos técnicos.
Além da verificação de consistência entre os modelos de uma fa do projeto, é importante comparar
os modelos desenvolvidos em fas diferentes. Por exemplo, os modelos desenvolvidos durante a
fase d análise devem ser comparados com os modelos desenvolvidos durani

Página 395 de 584
590
a fase de projeto. A comparação deve demonstrar correspondência um- para-um entre eles: cada
requisito descrito no modelo de análise (DFD, DER etc.) deve estar representado em algum ponto
do modelo de proje to (DE etc.) e cada característica descrita no modelo de projeto deve
corresponder a um requisito descrito em algum ponto do modelo de análise. O problema mais
comum é, naturalmente, que um requisito no modelo de análise seja esquecido e não apareça em
lugar algum do modelo de projeto.
Isso ocorre com freqüência quando o modelo de análise de siste mas é elaborado por um grupo de
pessoas e o modelo de projeto (e a codificação e os testes subseqüentes) o é por outro grupo. No
caso mais extremo (que muitas vezes ocorre em projetos do governo), os dois grupos podem
trabalhar em empresas diferentes. Em qualquer dos casos, os dois grupo muitas vezes representam
diferentes interesses e pers pectivas, e podem não ter boas comunicações entre si em qualquer ní
vel. Dessa forma, um requisito que a equipe de análise tenha conside rado como perfeitamente
claro pode não ser compreensível para a equi pe de projeto.
Há ocasiões em que o problema é exatamente o inverso do que vimos acima: a equipe de projeto
decide introduzir características que nunca foram solicitadas pelo usuário nem documentadas no
modelo da análise. Isso pode acontecer inocentemente, mas costuma ocorrer quan do alguém da
equipe de projeto diz: «embora não tenham pedido, apos to que os usuários vão adorar este
recurso”. Ou o veterano e levemente cínico projetista comenta: «apesar de os usários não terem
pedido o recurso X, eu sei, pela minha experiência, que vão pedi-lo na próxima semana. É mais
fácil incluí-lo agora do que esperar que o peçam”. Não importa se esses motivos são ou não
razoáveis. O importante é que o assunto seja discutido em lugar de permitir-se que o projetista
tome uma decisão unilateral.
Da mesma forma, o modelo de projeto deve ser comparado com os programas codificados. Como
antes, deve haver uma correspondência de um-para-um entre os componentes do código (a
implementação real dos modelos de análise e de projeto) e os componentes do modelo de projeto.
A.3 A FUTURA TECNOLOGIA DAS FERRAMENTAS
• AUTOMATIZADAS
Muitos dos recursos acima descritos já existem nas bancadas de trabalho de analistas/projetistas à
disposição no mercado. Alguns desses recursos estão implementados de uma forma um tanto
primitiva, mas estão sendo aperfeiçoados quase que diariamente. Não obstante, todos
591
os produtos devem ser vistos como ferramentas de primeira geraçi eles representam apenas o início
de uma série de desenvolvimentos qi ocorrerão nos próximos 5 ou 10 anos.
O cronograma para a segunda e a terceira gerações de ferrament automatizadas de
desenvolvimento é pouco nítido. Algumas delas d pendem dos recursos das empresas que as estão
elaborando; outras d pendem do desenvolvimento continuado da tecnologia de hardware qi
proporcionará crescente capacidade às estações pessoais de trabalho. muitas ainda dependem do
problema da transferência de tecnologia. grandes empresas estão apenas começando a experimentar
com un ou duas estações em meados dos anos 80 e decorrerão alguns anos a que a tecnologia de
primeira geração permeie a indústria de dese volvimento de software.

Página 396 de 584
Entretanto, tenho esperanças de que se você visitar uma gran empresa profissional de SIG em
1995, descobrirá que cada program dor (se ainda houver programadores) e cada analista de
sistemas e ca usuário final e cada gerente de projeto tem em sua mesa uma estaçi inteligente que é
10 a 100 vezes mais poderosa que as estações atuai Elas oferecerão os seguintes recursos:
• Redes para utilização a nível de projetos
• Suporte personalizado de metodologia de engenharia d software
• Controle de documentos
• Recursos para gerência de projetos
• Métricas para estatísticas de produtividade e de software
• Verificação antecipada de complexidade excessiva
• Testes e simulações automatizados
• Provas de correção assistidas por computador
• Geração de código (codificação de programas)
• Suporte de IA de código reutílizável
• ‘Quadros negros” para a equipe de projeto
592
A.3,1 Redes para Utilização a Nível de Projetos
As ferramentas automatizadas são úteis mesmo em pequenos pro jetos de uma só pessoa; o mesmo
vale para a engenharia de software. Porém o projeto pequeno tem a vantagem de o serviço poder
ser refeito diversas vezes até ficar pronto, de modo que o uso de modelos e ferra mentas formais
não tem conotação de urgência.
As ferramentas automatizadas serão muito utilizadas nos grandes projetos de desenvolvimento de
software multipessoas, multianos e de muitos milhões de dólares. Em projetos desse tipo existem
alguns analis tas de sistemas (muitas vezes uma dezena ou mais), alguns usuários fi nais (muitas
vezes em diferentes localizações geográficas) e alguns pro jetistas e programadores. Em ambientes
assim, é importante que não somente o trabalho de cada analista de sistemas seja internamente con
sistente, mas também o trabalho dos analistas A e B sejam consistentes entre si.
Isso quer dizer que é necessário haver um nível de inteligência acima do nível do analista de
sistemas ou programador. Embora haja muitas maneiras de se implentar isso, uma das arquiteturas
mais atraen tes é mostrada na figura A.3. Muitos dos fornecedores listados na tabela A.1 estão
diligenciando para oferecer esse tipo de rede, principalmente em minicomputadores Wang ou DEC
VAX.
O minicomputador a nível de projeto deve ter suficiente capacida de de memória e suficiente poder
de processamento para executar a verificação de consistência em nível de projeto. Também deve
dispor de suficiente capacidade para desempenhar funções adicionais. Deve pos sibilitar que os
programadores possam ser diretamente interligados ao computador de grande porte da organização
para a execução dos testes
Estações remotas de trabalho

Página 397 de 584
Figura A.3: Uma bancada de anahsta/projetista a nível de projeto
593
e de outras tarefas de rotina. E é aí o lugar onde deve ser colocada inteligência associada a muitas
das funções descritas a seguir.
É evidente que a utilização de tal minicomputador, com sua capa dade de memória, canais de
comunicação, e outras características, onerar o custo do suporte automatizado. Em dólares de 1985,
o custo uma estação de trabalho de utilização exclusiva e adequadamente con gurada está entre
$8.000 e $15.000; com o hardware e o software para minicomputador de nível de projeto, o preço
pode facilmente dobn Trata-se de um preço bem pago, mas dificilmence será suportado por u
orçamento de operação para um só ano de uma grande equipe de SIi custaria milhões de dólares
para uma empresa com algumas centenas desenvolvedores de sistemas. Ele deverá ser reconhecido
como parte um investimento de capital no esforço de tornar a equipe mais produti’ e mais
profissional.
A.3.2 Suporte Personalizado de Metodologia de Engenharia de Software
As ferramentas automatizadas costumam suportar uma específi forma de notação e de
procedimentos de engenharia de software. ( diagramas deste apêndice, por exemplo, e os
apresentados anteriormej te neste livro, usam a notação descrita em diversos livros da YOURDO
Press. Surpresa! Mas diversos produtos CASE também suportam outr conhecidas metodologias de
engenharia de software, como a notaçi Gane/Sarson e a Warnier/Orr. Diversas outras ferramentas
automatizad de suporte atualmente disponíveis suportam mais de uma marca d metodologias de
engenharia de software.
Existe, contudo, algo bem mais importante que apenas suportar metodologia do fornecedor A ou do
fornecedor B: a ferramenta autom tizada deve possibilitar uma metodologia personalizada. Uma
organiz ção de SIG quase sempre percebe que qualquer das conhecidas met dologias de engenharia
de software não apresenta uma adequada not ção ou um adequado conjunto de diretrizes para o tipo
peculiar c sistema que está desenvolvendo. Para exemplificar, pode ser que organização de SIG
queira utilizar triângulos para ressaltar as entradas saídas de marcianos e dos exploradores da
Jornada nas Estrelas c Capitão Kirk (a maioria de nós não precisa se preocupar com tais entr das e
saídas, porque jamais pensamos em exigir triângulos em nossa fe ramenta automatizada). E talvez a
organização de SIG tenha resolvid publicar um edito pelo qual nenhum diagrama de fluxo de dados
podei ter mais de 13 bolhas; uma outra empresa pode decidir que nenhui sistema deverá ter mais de
três níveis de diagramas de fluxo de dados. assim por diante.
594
É claro que esse tipo de personalização deverá ser possível ou a ferramenta deixará gradualmente
de ser utilizada à proporção que os analistas de sistemas descobrirem que ela não preenche suas
necessida des. A maioria das ferramentas automatizadas atuais não dispõe desse recurso;
virtualmente todos os produtos da segunda geração o possuirão ou desaparecerão do mercado.
A.3.3 Controle de Documentos
Como vimos, a análise estruturada apóia-se em diversos modelos gráficos formais, suportados por
elementos textuais como dicionários de dados e especificações de processos; as estações
inteligentes automati zam o desenvolvimento e a manutenção desses documentos. Entretanto,

Página 398 de 584
possibilitam algo mais: o controle dos documentos. Isso, embora possa aparentar ser direto, é um
conceito radical na maioria das organizações de SIG. Muitas delas só recentemente começaram a
controlar o código fonte produzido na fase de programação do projeto.
Mas, assim como é desastroso permitir que um programador efetue “pequenas” modificações em
um programa operativo no meio da noite, também é perigoso permitir que um analista de sistemas
execute uma “ligeira” mudança em um DFD ou em um DER no meio da fase de análise de um
projeto, a menos que a alteração tenha sido autorizada e aprovada.
Para que esse recurso funcione, precisamos distinguir entre as bi bliotecas privativas que cada
membro do projeto mantém em sua estação exclusiva e o arquivo do projeto mantido no
minicomputador de nível de projeto mostrado na figura A.3. O que queremos controlar é o arquivo
do projeto. Uma vez que o analista ou o projetista tenha indicado que completou um modelo (ou
um diagrama) e está pronto para submetê-lo ao arquivo do projeto, o analista deixa de ser o único
proprietário do material.
A.3.4 Gerência de Projetos
O controle de documentos é um aspecto de outro recurso que pode ser provido por um
minicomputador de nível de projeto: a gerên cia de projetos. O gerente de um projeto pode ter sua
própria estação inteligente de trabalho e utilizar os recursos do minicomputador para coordenar e
supervisionar as atividades da equipe do projeto. Com ade quado suporte de software, ele pode ter
certeza de saber quando o analista A terminar o DFD em que estiver trabalhando; ele pode instruir
o minicomputador a encaminhar o DFD ao analista B para revisão e
595
comentários, podendo, assim, atribuir outra tarefa ao analista A. 1 poderá empregar todo esse
material para atualizar o cronograma e orçamento do projeto; e, tendo em vista que o
minicomputador cons va o registro imparcial de quando o analista A começou e terminou s DFD,
ele provavelmente terá uma entrada muito mais acurada e n tendenciosa para as atividades de
escalonamento do projeto. O gerer do projeto pode utilizar as aptidões de mala eletrônica que quase
ceji mente serão oferecidas pela arquitetura da figura A para comunicar- com sua equipe. Talvez
seja dificil fazer uma estimativa grosseira valor desse recurso, mas a maioria das equipes de
projetos descobri que não pode mais passar sem ele depois de tê-lo utilizado.
A.3.5 Métricas para Estatísticas de Produtividade e de Software
Como foi dito acima, o minicomputador de projeto pode cons var seu próprio registro das datas de
início e término de cada tarefa desenvolvimento de um DFD, a revisão do DFD, o caminhamento
pc DFD etc.) executada por um analista de sistemas, projetista ou progi mador, Dessa maneira, as
medições da produtividade podem ser efetL das de modo quase invisível, que esperamos que possa
reduzir o imp to do princípio da incerteza de Heiscnberg . Compare isso com o pro to de
desenvolvimento de software de hoje em dia, em que os progi madores e analistas de sistemas
gastam uma hora ou perto disso a ca semana registrando informações sobre como despenderam seu
temç Existe uma mal disfarçada tendência para preencher o formulário maneira a fazê-lo parecer-se
com o que o chefe deseja (os prograrr dores podem ser marotos e vigaristas, mas não estão
totalmente d ligados da realidade!) Além disso, se o processo de registro tomar ur hora, então ele
estará interferindo com o próprio trabalho; esta é a rr neira como os fïsicos nucleares referem-se ao

Página 399 de 584
princípio da incerteza Heisenberg.
Quase todas as outras métricas de software que a equipe de proje decidir controlar podem ser
executadas pelo minicomputador de ní de projeto. Assim, a equipe pode decidir que é importante
saber quant DFD serão necessários para o sistema, ou quantos elementos de dad( ou quantas
primitivas funcionais ou quantas revisões foram exigidas um DFD antes que ele fosse finalmente
aceito pelo usuário. Essas inft mações poderão ser valiosas para futuros projetos, podendo também
úteis para estimativas de tamanho e custo de projetos.
596
A.3.6 Verificação Antecipada da Complexidade Excessiva
Uma das métricas mais úteis a longo prazo é a da complexidade. Existem modelos matemáticos da
complexidade de programas que po dem ser usados para predizer a dificuldade de testar e manter
um progra ma Se os modelos matemáticos forem aplicados automaticamente a cada módulo ou a
cada programa do sistema em desenvolvimento, os desenvolvedores e o gerente do projeto terão
um aviso antecipado de partes potencialmente perigosas do sistema, possibilitando que sejam
experimentadas construções alternativas.
A.3.7 Testes e Simula ções Assistidos por Computador
Como já mencionado neste apêndice, já existem pacotes de testes e animadores assistidos por
computador que proporcionam ao programa dor a representação gráfica da execução de seu
programa. Não existe motivo pelo qual esse recurso inteligente não possa ser introduzido na
estação remota do minicomputador de nível de projeto.
Na realidade, quase todas as ferramentas convencionais de suporte de programas relacionadas no
início deste apêndice podem ser incorpo radas a bancadas automatizadas de trabalho. Quando as
estações pes soais inteligentes tornarem-se mais poderosas, deverá ser possível que o programador
acompanhe o processo de modelagem com a codificação (se não for possível gerá-la
automaticamente), com a compilação e com os testes. Somente quando o programa estiver pronto é
que o programa dor deverá carregá-lo no minicomputador de nível de projeto.
A.3.8 Provas de Correção Assistidas por Computador
Como discutimos no capítulo 23, a área de provas de correção assistidas por computador ainda não
está desenvolvida a um grau em que programadores e analistas médios possam utilizá-las. Mas
existe um Largo espectro entre a verificação informal de consistência e as provas formais de
correção. Com as ferramentas automatizadas de suporte avançaremos gradualmente da verificação
informal dc consistência, aproximando-nos das provas formais completas de correção. A obtenção
jisso exigirá um nível de treinamento e sofisticação por parte dos pro ramadores mais elevado que
o atual. Portanto, não se deve esperar a presença desse recurso na maioria das estações orientadas
para as em presas dentro dos próximos 5 anos.
597
A. 3.9 Geração de Código
Uma importante meta de muitos fabricantes de ferramentas é geração automatizada de código
COBOL ou FORTRAN pelas bancad de trabalho. Dessa maneira, não seria preciso examinar-se o
códig assim como hoje dificilmente alguém examina os Is e Os binários que hardware do

Página 400 de 584
computador realmente entende. Nesse contexto, estariam lidando com especificações computáveis,
desenvolvidas pelo usuár final e pelo analista de sistemas.
Talvez nunca sejamos capazes de conseguir isso para todos sistemas, nem sejamos capazes de
insistir no necessário nível de espec ficações rigorosas e formais de todos os usuários finais.
Porém, dando-:
mais ênfase às atividades de análise e projeto, podemos facilmente r duzir a programação a uma
simples atividade burocrática. Ainda que ni possamos automatizá-la completamente, podemos
fazer com que se executada pelos funcionários de nível júnior, em vez de ocupar os gr duados em
Ciência da Computação que ganham $40.000 por ano.
A.3.1O Suporte de IA de Código Reutilizável
Ainda mais atraente que o conceito da geração automática de cóc go é o conceito de código
reutilizável. Na imensa maioria dos projet( (orientados para o comércio e orientados para fins
científicos e de engi nharia) a maior parte do software que pretendemos desenvolver já f feito
antes. O novo sistema deste ano é, de fato, quase igual ao sisten do ano passado, e não muito
diferente do anterior a este. E muitas d primitivas funcionais de baixo nível já foram programadas
centenas c vezes antes e existem grátis como rotinas de bibliotecas oferecidas corr parte do sistema
operacional do fornecedor. A única coisa que distingL o novo sistema deste ano como único é a
exclusiva combinação d funções previamente implementadas ou alguns parâmetros que podei ser
introduzidos no programa ao começar sua execução. Por exemplo, sistema de pagamento deste ano
é basicamente o mesmo do ano pa sado, com a alteração de apenas algumas taxas.
Isso indica que o analista de sistemas (e mais ainda o projetista c sistemas) não deve encarar cada
novo projeto como uma grande expli ração científica mas como uma caç2da em busca de módulos
de bibliot cas, sub-rotinas.e programa já ex..stentes, que possam ser interligadc para atender às
necessidades do i.suário.
É nesse aspecto que a inteligência artificial pode ser um ótim auxílio. Comparando as
características de uma função identificada p analista de sistemas (ex.: número de entradas, natureza
das saídas e ei pecificações das transformações ou as normas que descrevem como
598
entradas convertem-se em saídas etc.) com uma biblioteca de funções implementadas, um sistema
especialista pode sugerir ao projetista diver sos potenciais candidatos a serem utilizados na
implementação do siste ma. E ele pode interagir com o analista de sistemas para mostrar-lhe que
com uma pequena modificação dos requisitos (isto é, com um ligeiro compromisso dos requisitos
originais do usuário) uma função existente de biblioteca pode ser usada in situ.
A.3. 11 Quadros Negros para a Equzje do Projeto
Alguns dos principais pesquisadores do país (em laboratórios de pesquisa como o MCC, em
Austin, Texas, por exemplo) acreditam que a melhora real da produtividade nos anos 90 virá dos
efeitos sinergéticos de uma equipe de projeto ao invés de provir de um indivíduo; isso porque os
grandes sistemas atuais não são construídos por indivíduos, mas por grupos de grupos de pessoas
(muitas vezes em empresas dife rentes). A maioria dos conceitos descritos até agora refere-se à
melhora da produtividade de um único funcionário, mas a inteligência do mmi computador de nível
de projeto poderia ser utilizada para prover uma visão prática a nível de projeto de todo um sistema

Página 401 de 584
à proporção que ele toma forma e cresce.
A idéia de um quadro negro de projeto está sendo implementada no MCC como parte do projeto
Leonardo; ele deve apresentar resultados fascinantes pelo final da década. O grupo de pesquisa está
realizando experiências com a idéia de um quadro negro para uso comum na forma de um vídeo
com as dimensões de uma parede. Estão também investi gando a idéia de usar as sensações de
aroma e som, bem como as cores, para acrescentar novas dimensões aos modelos gráficos descritos
neste livro. Se obtiver sucesso, o projeto Leonardo será a bancada automatiza da de trabalho de
terceira ou quarta geração para os desenvolvedores de sistemas de meados da década de 90!
A.4 CONCLUSÃO
‘Minha tendência e entusiasmo por este aspecto do desenvolvi mento de sistemas é evidente; não
posso esconder e não tenho porque me desculpar. Eu realmente creio que ele representa o único
mecanismo que nos pode auxiliar a alcançar e manter contato com as hordas de programadores
pelos países do mundo que dispensarão a mágica indús tria que criamos nos Estados Unidos nos
últimos 25 anos.
Alguns dirão que essa tecnologia é muito cara, que nenhum pro gramador vale um investimento de
$25.000. Talvez não, mas como os
preços do hardware estão sempre caindo, os $25.000 de hoje serã $10.000 amanhã e $5.000 no ano
seguinte. Parece-me uma grande ironi que um país que investe de $50.000 a $75.000 em
equipamento par seus fazendeiros e operários negue uns poucos milhares de dólare para seus
trabalhadores da informação. Essa relutância, essa negação en admitir que os investimentos possam
ser necessários, é o último suspin da Revolução Industrial, o último alento do que Alvin Toffler
denomino de «Segunda Onda”.
Admito que uma atividade de software dominada pelas estaçõe automatizadas origine algumas
perguntas relevantes: ela torna obsoleto os programadores? ela destruirá nossa criatividade?
podemos suporta os custos? ela garante que obteremos melhorias substanciais em noss capacidade
de produzir software de alta qualidade com maio produtividade?
Nada existe de mágico nas ferramentas automatizadas de software qualquer pessoa com senso
comum pode responder a essas perguntas As ferramentas automatizadas certamente não tornarão
obsoletos o programadores a curto prazo nem tornarão obsoletos os programadore de manutenção
pelos próximos 20 anos ou mais. Enquanto isso, seria bom desenfatizar a atividade da
programação, que manterá a tendênci apresentada desde a invenção da primeira linguagem de alto
nível err fins dos anos 50. Isso não ameaça o emprego de nenhum programador lembre-se que
temos uma demanda de sete anos de trabalho de desen. volvimento de sistemas na maioria das
organizações!
As estações automatizadas destruirão a criatividade dos de senvolvedores de software? Bobagem!
Tapeação! Os Sistemas CAD/CAI (computer-aided design) destroem a capacidade de um projetista
e projetar um automóvel ou um avião esteticamente belo? Não/Cem vezes Não, não e não! Muito
ao contrário. A disponibilidade de ferramenta automatizadas de suporte ajudam o programador e o
analista de sistema a concentrarem-se na parte realmente criativa da tarefa e a despendereni menos
tempo preocupando-se com os aspectos mundanos dela. Uma vez que a bancada de trabalho
possibilite que o analista de sistemas gaste mais tempo inventando mais modelos dos requisitos do

Página 402 de 584
usuário, ela o tornará mais criativo.
Podemos suportar o custo dessas estações de trabalho? A resposta simples é: não podemos suportar
o custo de não utilizarmos essas esta ções! Com elas, teremos uma oportunidade de salvar a
indústria america na de software; sem elas, não há esperanças. Para os que desejarem algo mais
prático, lembrem-se que o custo de uma sofisticada estação de trabalho, presumindo-se a inclusão
do suporte do minicomputador de nível de projeto, está em torno dL $25.000 . Esse valor equivale
aproxi madamente ao salário anual, em 1987, de um programador comum com um ou dois anos de
experiência. Se incluirmos o custo extra (seguridade,
600
pensões de 100%), isso representará cerca de seis mese do custo de um programador. Como
podemos facilmente justificar a amortização do custo do hardware e do software associado em 3
anos, o custo é aproxi madamente igual a 15% do custo anual de um programador. Em outras
palavras, se ela aumentar a produtividade do programador em 15% em cada ano, ela se paga por si
mesma.
Porém, uma bancada automatizada de desenvolvimento de soft ware garante o aumento da
produtividade por um fator de 10? Quem emite seriamente uma pergunta dessas ainda deve
acreditar no coelhi nho da Páscoa. Ir à igreja todos os domingos garante que você irá para o céu?
Estupidez, arrogância, preguiça, e outras fraquezas humanas sem pre tornarão possível o fracasso
apesar das melhores ferramentas e su portes; não há como impedir essa possibilidade. Mas, se
acreditarmos no poder dos sistemas de informações e dos suportes automatizados para a sociedade
e para as empresas, devemos acreditar nele para a atividade que constrói sistemas para o resto da
humanidade. Não deve ser sempre verdade que os filhos do sapateiro serão os últimos a usar
sapatos.
REFERÊNCIAS
1. Jack Crawford, palestra na Wang Computer Company, em 6 de maio de 1985.
2. James Martin, An Infor,nation Systems Man Englewood Cliffs, N.J.: Prentice-Hall, 1984.
3. Paul Ward e Steve Mellor, Structured Systems Development for Real-Time Systems, Volumes 1-
3. Nova lorque: YOURDON Press,
1985.
4. Meilir Page-Jones, Tbe Practical Gulde to Structured Systems De sign, 2’ ed. Nova lorque:
5. Steve McMenamin e John Palmer, Essential Systems Analysis. Nova
Torque: YOURDON Press,1984.
6. Paul Ward, Systems Development Without Pain. Nova lorque:
7. Brian Dickinson, Developing Structured Systems. Nova lorque:
8. Edward Yourdon, Managing the System L Cycle, 2. ed. Nova lorque: YOURDON Press, 1988.

Página 403 de 584
9. Edward Yourdon e Larry Constantine, Structured Design. Engle wood Cliffs, N.J.: Prentice-Hall,
1979.
10. David King, Current Praclices in Software Englneering. Nova lor que: YOURDON Press,
1983.
601
11. Tom DeMarco, Structured Analysis and System Specificatíoi-
12. Tom DeMarco, Concise Notes on Software Engineering. Nova lor
que: YOURDON Press, 1979.
13. Chris Gane e Trish Sarson, Structured Systems Ana 1y and Desig
Nova lorque: Improved Systems Technologies, 1977.
14. Ken Orr, Structured Systems Development. Nova Iorque
NOTAS
Isso é importante porque sabemos que 50% dos erros de um proje
to comum de desenvolvimento de sistemas, hoje, devem-se a mal
entendidos entre o usuário final e o analista de sistemas; 75% d
custo da remoção de erros de um sistema operativo são relativos
erros originados na fase de análise de sistemas.
2 Segundo a opinião da maioria dos programadores, é mais ou me
nos como duas ou três pessoas compartilhando a mesma escova d
dentes.
3 $10.000 é considerado mágico por ser o nível no qual são exigido
graus mais elevados de autorização para que se possa despende
fundos incorporados. Um gerente de projeto pode muitas veze.
observar os beneficios práticos de uma estação inteligente de eri
genharia de software e apresentar estudos realistas de custo/bene
ficio. Porém se a decisão envolver $20.000, ela subirá ao nível d
um vice-presidente assistente que passou semanas tentando man
ter-se acordado o tempo suficiente para fazer algo útil na empresa
Agora ele pode organizar uma comissão, estabelecer padrões, pes
quisar a indústria e endereçar memorandos a dezenas de outro
igualmente sonolentos vice-presidentes assistentes. Enquanto tod
essa tomada de decisão de alto nível está em andamento, o gerent

Página 404 de 584
de projeto encolhe os ombros, tenta esquecer que ele um dia sub
meteu a solicitação em primeiro lugar, e volta a utilizar suas técni
cas da Idade da Pedra de construção de sistemas. Como você pod
perceber, eu sou inteiramente objetivo e de forma alguma m
exalto emocionalmente com este assunto.
4 A maioria dos desenvolvedores de software usa produtos CASE qu
podem ser processados em computadores IBM PC, mas os diagra
mas deste livro não foram produzidos por esses produtos. Pan
utilizá-los eu teria de enconirar um modo de mesclar os diagrama.
com os arquivos de texto deste livro, que estou redigindo em un
Macintosh.
602
5 Tratava-se, evidentemente, de um diagrama mais complicado que o da figura A.1. Na realidade, a
maioria dos diagramas de fluxo de dados do mundo real é mais complexa; eles têm sete ou oito bo
lhas, três ou quatro depósitos, doze ou mais fluxos de dados e alguns terminadores externos.
6 Na realidade, você pode dizer a MacDraw que certos objetos do desenho deveriam ser agrupados,
de modo a que pudessem ser movimentados em conjunto; mas isso não garante que o resultado,
após a movimentação, fosse o desejado. Alguns outros pacotes de desenho, como o Design, da
Meta Software (55 Wheeler Street, Cambridge, MA 02138), são mais sofisticados no modo como
ma nipulam objetos e conectores. Mas, qualquer que seja a sofisticação que o pacote de desenho
apresente, isso não importa muito sem as regras de verificação de erros discutidas na seção A.1.2.
7 Embora o princípio da incerteza de Heisenberg seja habitualmente associado à área da fisica
nuclear, ele também é aplicável aqui. O princípio afirma que não é possível medir um fenômeno
sem se modificar o fenômeno. Se um trabalhador precisar despender 10% de seu tempo medindo
seu próprio trabalho, sua produtividade re duz-se em pelo menos 10% - e o fato de ele saber que
está sendo avaliado (face às medidas que ele próprio está fazendo) tende a modificar seu
comportamento.
8 Como discutimos no capítulo 23, um dos modelos mais conhecidos
é a medida de complexidade ciclomática de McCabe. Desejando
mais detalhes sobre esse e outros modelos, veja Controlling Soft ware Profects de Tom DeMarco
(Nova Jorque: YOURDON Press,
1982).
9 Programas simples de desenho estão disponíveis por menos de
$100, e mesmo os programas mais sofisticados de desenho custam apenas algumas centenas de
dólares. A mais barata estação inteli gente de trabalho para analistas, com os recursos descritos na
se ção A.2, custa cerca de $895 em 1987; esses preços provavelmente cairão gradativamente nos
próximos dois anos. Mesmo uma esta ção de trabalho dispendiosa está custando em torno de
apenas $8.000 em 1987.

Página 405 de 584
603
B
DIRETRIZES PARA
ESTIMATIVAS
B.1 INTRODUÇÃO
Como analista de sistemas, você provavelmente será solicitado a produzir várias estimativas em
relação a seu projeto. Na realidade, você pode ser o único responsável pela produção das
estimativas em alguns casos; em outras situações, o gerente do projeto pode pedir-lhe que de
senvolva algumas estimativas para seu uso.
Que coisas precisam ser estimadas em um projeto de desenvolvi mento de sistemas? Isso depende
do projeto, porém as principais coisas
que normalmente precisam ser estimadas SÃO:
• Recursos humanos. Quantos programadores, analistas de sis temas, projetistas de bancos de
dados, peritos em telecomuni cações, representantes do usuário e outros tipos de pessoas se rão
necessárias ao projeto?
• Cronog ramas. Por quanto tempo o projeto se estenderá? Quanto tempo deverá ser gasto em cada
uma das fases do projeto (ex.:
análise, projeto, programação, testes etc.)?
• Escalonamento do pessoal. Além de sabermos de quantas pes soas o projeto necessitará,
precisamos saber quando essas pes soas serão necessárias. Se o projeto precisa de dez programa-
• dores, serão os dez necessários ao mesmo tempo?
• Orçamento. Quanto custará o desenvolvimento do sistema? O principal custo será provavelmente
o causado pelos salários pagos á equipe de desenvolvimento, e isso habitualmente pode ser
calculado diretamente quando a equipe e o escalonamento dela já forem conhecidos. Mas,
naturalmente, existem outros
605
custos associados a um projeto; esses custos são tratados deta lhadamente no apêndice C.
Lembre-se de que você normalmente terá de fazer essas estimativa mais de uma vez. Geralmente é
feito um conjunto de estimativas no estágios iniciais do projeto (durante o estudo de viabilidade,
por exem plo), mas eles podem precisar ser feitos muitas vezes, quando os usuá rios e a direção
examinarem as ramificações das diferentes barganhas Um exemplo evidente disso é a barganha
entre tempo e funcionalidad (ex.: o gerente do projeto pode dizer ao usuário: ‘tenho certeza de qu
poderemos entregar o sistema em 1° de janeiro, se você abandonar a funções X, Y e Z”); outro
exemplo é a barganha entre tempo e pessoa (ex.: o usuário poderia dizer ao gerente do projeto: «se
você dispusess de mais três programadores, conseguiria prontificar o sistema em tem p0?”. Pode
haver algumas iterações até que a equipe de projeto, direção e a comunidade usuária atinjam um
compromisso aceitável
B.2 OS RISCOS DAS ESTIMATIVAS

Página 406 de 584
Costumamos ter uma grande experiência na área das estimativas basta pensarmos em todas as
situações originadas pela pergunta: “Quan to tempo você acha que levaremos até a casa de sua
avó?”. E todo conhecemos intuitivamente o conceito de uma estimativa otimista e d uma
pessimista. Mas estimar o projeto dc desenvolvimento de um siste ma é um tanto diferente, porque
(1) a abrangência da tarefa é muit maior e mais complexa e (2) as conseqüências de um erro de
estimativa costumam ser muito mais severas que as de chegarmos meia hora atrasa dos na casa de
nossa avó 2• Existem diversos problemas aos quais vod deve estar atento antes de começar a
estimar orçamentos, cronograma e requisitos de recursos:
• A diferença entre estimar e negociar
• A grande variação das habilidades técnicas
• O perigo de estimar seu próprio trabalho
• A falta de um banco de dados de estimativas
• A insistência da direção por prematuras estimativas detalhadas
• A dificuldade a nível industrial de medir-se a unidade di trabalho
606
• Estimativas fundamentadas em pressuposições de horas extras não remuneradas
Dependendo de sua posição no projeto e de sua influência junto à direção e aos usuários, você pode
conseguir evitar que alguns desses problemas venham a tornar-se sérios. Mas, ainda que você seja
um ana lista júnior no projeto, deve conhecer os problemas das estimativas, pois, afinal de contas,
são eles que determinam o sucesso ou o fracasso de seu projeto. Discutiremos em seguida cada um
desses problemas detalhadamente.
B.2.1 A D Entre Estimar e Negociar
Geralmente há muitas negociações no início de um projeto (e muitas vezes durante a fase de
desenvolvimento do projeto!). Isso é normal, porque a comunidade usuária muitas vezes tem pouco
conheci mento do volume de trabalho que envolve um complexo sistema de informações e tende a
“pedir a Lua”, isto é, uma imensa funcionalidade em um absurdamente reduzido espaço de tempo,
e por pouco ou ne nhum dinheiro. Entrementes, o gerente do projeto vê-se frente a uma limitada
equipe e um pequeno orçamento; portanto, ele precisa trabalhar com os usuários para ajudá-los a
descobrir quais os arranjos possíveis.
Porém esse processo de negociação, tão necessário e tão comum em projetos de desenvolvimento
de sistemas, não deve ser confundido com as estimativas. O que se deve evitar é o entendimento
entre o usuá rio e o analista (ou quem quer que faça as estimativas) em conversas deste tipo:
Usuário: “Então, quanto tempo você levará para construir o sistema XYZ?
Analista: “Bem, parece que ele estará pronto em l de abril”.
Usuário: “Não está bom, precisamos dele em 1 de janeiro”.
sem a intenção de discutir outras barganhas entre funcionalidade e recur sos rsso às vezes é seguido
por um apelo do usuário aos sentimentos de devoção, dever e patriotismo da equipe de projeto. Isso
será discutido como um problema à parte na seção B.1.8.
Em alguns casos, essa situação simplesmente reflete a falta de co nhecimento da parte do usuário;

Página 407 de 584
ela habitualmente pode ser corrigida com uma cuidadosa explicação das atividades de
desenvolvimento de um sistema. Em outros casos, entretanto, ela reflete a abordagem geral
607
do usuário, seu “paradigma” de ação para lidar com pessoas e organiz ções que lhe fornecem
produtos e serviços. Para o usuário típico, vo deve estar percebendo, a organização interna de
processamento dados não é muito diferente de um fornecedor externo; a negociaçã na tentativa de
baixar o preço ou reduzir os prazos em alguns meses, algo muito natural. E é razoável agir assim
(do ponto de vista dei quando a pessoa ou a organização que fornece o serviço tem uma rn gem de
lucro que pode ser reduzida mediante habilidosas negociaçõe
Mesmo no caso de uma organização interna de processamento dados, a negociação (sem aceitar
barganhas em funcionalidade, recu sos, orçamento ou prazos) pode ser razoável se as suas
estimativas incli rem uma margem de erro (também conhecida por fator de contingênci que o
usuário imagina ser excessivamente grande. Mas se você tiver feii estimativas cuidadosas e
realistas, e o usuário propuser a redução pa uma equipe menor, um orçamento menor e prazos mais
apertado então seu projeto terá adentrado o domínio dos altos interesses para quais as técnicas e
ferramentas discutidas neste livro provavelmente ni serão de muita ajuda. Pode ter chegado o
momento de acertar as su contas.
B.2.2 A Grande Variação das Habilidades Técnicas
É comum fazerem-se estimativas do trabalho a ser executado co base no talento médio (isto é, o
típico programador ou analista c sistemas, que pode escrever 15 linhas de código, ou desenhar
quati bolhas de DFD, em um dia médio). É importante ter-se em mente qu numerosos estudos
feitos nos últimos 10 anos documentaram uma o dem de diferença de magnitude entre profissionais
talentosos e mede cres na área . Se o seu projeto dispõe de um grupo dos assim chamadc
superprogramadores, você poderá superestimar drasticamente o tempo dinheiro necessários para
terminar o projeto. De importância maior é fato de que uma equipe composta por pessoal
tecnicamente limitad pode fazer com que seu projeto não cumpra os prazos e ultrapasse orçamento
de modo substancial.
Um grande problema dessa área é que o desempenho real d pessoal experiente não se correlaciona
fortemente com a maioria dc testes padronizados da capacidade de programar. Assim, você deve
fur damentar suas estimativas na reputação ou na experiência de trabalh anterior de cada pessoa,
podendo, também, partir do pressuposto d que todos no projeto estâo dentro da média. Como a
maioria das empr sas não mantém registros cuidadosos e detalhados sobre a produtividad de cada
pessoa em um ambiente de desenvolvimento de sistemas, se lhe-á muito difícil obter evidências
documentadas em que se poss
608
confiar. Tudo o que você tem a fazer é realizar seu próprio julgamento e modificar as estimativas,
do modo mais adequado, durante o desenrolar do projeto.
B.2.3 O Perigo de Fstimar seu Próprio Trabalho
Um dos piores erros que você pode cometer é estimar seu próprio trabalho; é quase tão arriscado
quanto utilizar a estimativa de uma só pessoa, uma vez que o julgamento dessa pessoa pode ser
afetado por uma série de fatores.

Página 408 de 584
Se você avaliar seu próprio trabalho, provavelmente acabará viti mado por um dos seguintes mitos:
• “Sou melhor que a maioria das pessoas aqui, e tenho certeza de que posso terminar o projeto
muito mais cedo” É muito comum sobrestimarmos a capacidade de alguém. Ao avaliarmos a capa
cidade de outra pessoa, tendemos a ser conservadores; ao esti marmos nossa própria capacidade,
tendemos ao otimismo.
• “Sei que o chefe precisa que este projeto seja feito muito rapida mente, e de fato quero ajudá-lo”.
Na maioria dos casos, isso é um sentimento altruísta; é muito natural querer que seu chefe seja
bem-sucedido. Mas isso pode nublar seu julgamento sobre o verdadeiro tempo necessário para
terminar o projeto. Na pior das hipóteses, as estimativas otimistas são feitas como um esforço para
impressionar seu superior (lembre-se que ele está fazendo o mesmo para o superior dele, que está
fazendo a mesma coisa para o chefe dele etc.) visando uma melhoria ou promoção. Se você souber
o que está fazendo e for capaz de aceitar o risco, ótimo mas não se esqueça de que estará brin
cando com fogo.
• ‘Quero trabalhar duro para terminar este projeto no prazo” A intenção de trabalhar além da hora é
elogiável, mas perigosa como já foi sugerido. Além disso, lembre-se de que a decisão de trabalhar
longas horas é muitas vezes feita em um momento de
• entusiasmo no início do projeto; seis meses mais tarde, pode não parecer uma idéia assim tão boa.
• ‘já trabalhei em sistemas assim antes, este vai ser fácil’ Bem, talvez, se você, de fato, já trabalhou
em um projeto exatamente como este, ou muito parecido. Entretanto, existe uma tendência no
início de um projeto para enxergarmos similaridades com
609
projetos anteriores e presumirmos de forma otimista que ser mos capazes de prontificar o novo
projeto com maior rapide; Você provavelmente descobrirá que o novo projeto é de fato ur tanto
diferente, ao entrar nos detalhes; e provavelmente e quecerá todos os problemas encontrados no
último projeto.
Por esses motivos, é muito importante que as estimativas sejar feitas por alguém que não seja a
pessoa responsável pelo trabalho. também altamente desejável que ninguém tenha um banco de
dados d estimativas (discutido na seção B.1.4) ou um pacote de estimativas co putadorizadas
(discutido na seção B.4) para obter estimativas de mais d uma pessoa. Obtenha avaliações
provenientes de pelo menos três pe soas; isso proporcionar-lhe-á estimativas do melhor caso e do
pior casc juntamente com uma avaliação do caso intermediário.
B.2.4 A Falta de um Banco de Dados de Estimativas
Quando nos defrontamos com um novo projeto, gostaríamos d dispor de estatísticas sobre uma
centena de projetos semelhantes par podermos produzir estimativas corretas. Algumas firmas de
consultoria ‘software houses” estão capacitadas a fazer iSSO: quando solicitadas avaliar o tempo e
o custo de, digamos, um sistema de controle de pedi dos, eles podem dizes: ‘Bem, este é quase
igual ao sistema de control de pedidos 137 que construímos, portanto ele levará X homens/mês,
dólares e Z pessoas”.
Mesmo dentro de nossa própria organização é possível que tenhan sido desenvolvidos 137 sistemas
de controle de pedidos nos últimos de ou vinte anos. Mas isso não significa necessariamente que
será fácil es timar o orçamento ou o cronograma para o l sistema de controle d pedidos; se os

Página 409 de 584
registros não tiverem sido cuidadosamente conservado tudo o que você poderá utilizar serão boatos
e rumores. Em uma or ganização de processamento de dados, que atua como um setor d serviços
internos, sem ter de se preocupar com aspectos de lucros/per das ou com considerações de fluxo de
caixa, não existe um incentiv real para conservar cuidadosamente esses registros.
Algumas grandes organizações de processamento de dados estã começando a modificar essa
atitude e estão iniciando o desenvolvimen to de grandes bancos de dados detalhados que podem ser
empregado na geração de estimativas muito mais acuradas para futuros projetos Algumas firmas de
consultoria que se estão especializando nessa áre desenvolveram bancos de dados de literalmente
milhares de projetos esses bancos de dados costumam ser usados para fornecer parâmetro:
aos modelos de estimativas computadorizadas discutidas na seção B.4.
610
Entrementes, existe uma grande probabilidade de que você se de fronte com a estimativa de algo
único. Certamente que você deve procu rar outros projetos semelhantes em seu local de trabalho,
mas lembre-se de que você poderá ver-se em uma situação análoga à do arquiteto a quem
perguntaram em quanto tempo ele construiria uma casa subterrâ nea em um pântano.
B.2.5 A Insistência da Direção por Estimativas Detalhadas Prematuras
Como regra geral, é quase impossível produzir-se estimativas deta lhadas de custos, de tempo e de
requisitos de recursos para um projeto antes de ter sido executado um considerável volume de
trabalho detalha do de análise e de projeto do sistema. Afinal, como informar ao usuário quanto vai
custar um sistema se você ainda não sabe o que ele deseja? Não obstante, muitas vezes há uma
grande pressão dos usuários e da direção para que se apresente uma estimativa, que ambos
presumem ser uma previsão exata e detalhada, em um estágio muito inicial do projeto. Por quê?
Simplesmente porque eles precisam tomar uma decisão tipo sim/não em investir tempo, dinheiro e
pessoal necessários à construção do sistema.
A demanda por uma estimativa prematura é bastante compreen sível; a única coisa que não é
realista é a pressuposição de que uma avaliação prematura pode ser detalhada ou acurada. É muito
mais ade quado oferecer-se à direção uma série de estimativas durante o projeto, sendo cada uma
progressivamente mais detalhada e mais exata do que a anterior. Desse modo, se a equipe de
projeto estiver desenvolvendo um sistema para uma aplicação, com a qual seus componentes
estejam bastante familiarizados, pode ser produzida a seguinte série de estimativas:
• Ao final do levantamento ou estudo de viabilidade: uma estima tiva que pode variar por mais ou
menos 50%. Isto é, a equipe de projeto pode informar à direção que o sistema tomará um ano e
custará $200.000, mais ou menos 50%. A direção deve, portanto, prever a possibilidade de o
projeto levar 18 meses e custar
$300.000.
• Ao final da fase de análise: uma estimativa que pode variar em
± 25%.
• Ao final da fase de projeto: uma estimativa revista que pode variar em ± 10%.
611
• Ao final da fase de programação (quando os testes ainda estã por serem feitos): uma estimativa

Página 410 de 584
final que não deve variar en
mais de ± 5%.
B.2.6 Uma D!ficuldade a Nível Industrial em Medir a
Unidade de Trabalho
Muitas indústrias têm meios padronizados de medir o volume d trabalho a ser feito em um projeto.
Alguém que esteja construindo um casa, por exemplo, pode medir a tarefa em termos do número
de tijolo a serem colocados ou o número de cômodos a serem construídos. Mas na área do
desenvolvimento de sistemas ainda não existe um mod convencionado de medir-se a unidade do
trabalho a ser feito.
O método mais comum é medir-se o número de instruções d programa a serem escritas. Esse
método também é conhecido como li nhas de código. Assim, em alguns projetos, podemos ver
referências KLOC, que significa kilo lines of code (quilolinhas de código). Mas exis tem muitos
problemas com as linhas de código como medida da unidad de trabalho.
• Os comentários em um programa devem ser contados com linhas de código?
• Devemos considerar somente o código entregue ao usuário, ot. também devemos contar o código
escrito para testes, programa
utilitários e outras atividades de suporte durante o projeto? (1
em uma escala maior, devemos contar as linhas associadas
projetos cancelados na tentativa de medir a produtividade d empresa?)
• E se o programador tiver escrito mais de uma instrução por li nha da listagem do programa? E as
sentenças complexas qu ocupam mais de uma linha?
• Ainda mais importante, como devemos considerar o fato de quc alguns programadores usam mais
linhas para escrever a mesma
função que outros programadores? Como vimos na seção B.2.2 isso pode representar uma ordem
de diferença de magnitude!
Como afirmou Capers Jones em Programming Produclivítj (EJones,1985]) maneiras diferentes de
medir a unidade de trabalho po dem distorcer de duas ordens de magnitude os resultados relatados
d produtividade; talvez seja por isso que alguns programadores propalarr
612
“
ser 10 e até 100 vezes mais produtivos que seus colegas! Em face desses problemas, algumas
organizações estão agora começando a utilizar pon tos de funções como unidade de trabalho; isso
corresponde grosseira mente às bolhas atômicas do nível mais baixo de um DFD
B.2.7 Estimativas Fundamentadas em Pressuposições de Horas Extras Não Remuneradas
Como já dissemos, os usuários e os gerentes de projeto podem reagir aos conflitos de cronogramas
sugerindo, implícita ou explicita mente, que a equipe de projeto trabalhe em horas extras, em fins
de se mana, dispense os feriados e adie as férias. Isso normalmente vem acom panhado por apelos
à lealdade, ao profissionalismo, dedicação, de voção, orgulho, honra e patriotismo dos participantes

Página 411 de 584
do projeto.
Deixo a você decidir se a determinação de trabalhar horas extras é uma necessária demonstração de
patriotismo. Em alguns estabelecimen tos isso pode ser verdadeiro: cada projeto pode ser
organizado de tal modo que só será bem-sucedido se a equipe de projeto trabalhar regu larmente 80
horas por semana. Alguns projetos (como o projeto Apollo, da NASA, que pôs os primeiros
homens na Lua no final da década de 60) podem ser tão estimulantes que todos ficarão mais do que
satisfeitos em apresentarem-se para o necessário serviço extraordinário. E não é inco mum
descobrir-se que um projeto que aparentava estar sob controle ultrapassou o prazo no último mês,
obrigando a algumas semanas de dias prolongados e fins de semana de trabalho.
Mas você deve lembrar-se que trabalhar é como correr: você pode correr à máxima velocidade por
algumas dezenas de metros, mas não pode correr em uma maratona à máxima velocidade. Da
mesma forma, você pode trabalhar 14 horas por dia durante algumas semanas, mas é irreal, na
maioria dos casos, presumir que possa trabalhar 14 horas por dia em um projeto de três anos.
Pessoas casadas, com filhos, ou Outros interesses, simplesmente se recusarão a continuar
trabalhando nesse horário após poucos meses; se necessário, pedirão demissão e procura rão outro
emprego. Pessoas jovens e solteiras podem estar mais decidi das a devotar todos os seus momentos
de vigília (bem como seus so nhos) ao projeto, principalmente se perceberem que isso pode
acelerar suas carreiras ou seu conhecimento profissional.
Mesmo que os membros da equipe concordem em trabalhar 14 horas por dia, nada garante que o
trabalho deles seja eficiente. Isso é principalmente válido no caso de o serviço extraordinário
prolongar-se por um período de vários meses: as longas horas vespertinas são muitas vezes
improdutivas, e pode-se notar que são cometidos mais erros quan do os funcionários trabalham
cansados e com suas mentes exauridas.
B.3 DIRETRIZES PARA ESTIMATIVAS
Existem quatro importantes diretrizes a serem lembradas ao fazer
mos estimativas do volume de trabalho a ser feito em um projeto d
desenvolvimento de sistemas:
• Faça as unidades de estimativa tão pequenas quanto possível.
• Faça as unidades de trabalho tão independentes quant possível.
• Leve em consideração o fator de comunicação.
• Faça a distinção entre serviço novo e serviço aproveitado.
Essas diretrizes serão discutidas a seguir.
B.3.1 Faça as Unidades de Estimativa Tão Pequenas
Quanto Possível
Esta deveria ser uma sugestão evidente, mas ela não é tão observa da quanto você imagina; ela
também tem algumas armadilhas, comc você poderá ver. Mas, em geral, é bem melhor estimar o
orçamento e cronograma para uma unidade de trabalho de uma semana do que fazei estimativas em
termos de ‘homem/milênio” . Grandes projetos têm gran de complexidade; se tentar estimar o
volume de trabalho envolvido você quase certamente cometerá grandes erros. É muito mais sensat

Página 412 de 584
fundamentar as estimativas em pequenos volumes de trabalho
Isso naturalmente implica em que todo o projeto seja fragmentad em pequenas unidades de
trabalho, o que acontece naturalmente com resultado da análise, projeto e programação
estruturados; infelizmente como vimos na seção B.1.5, você pode ser solicitado a preparar um
detalhada estimativa dos requisitos de orçamento e de recursos antes di ocorrência da subdivisão
detalhada do trabalho. Não existe uma soluçã mágica para este problema; tudo o que você pode
fazer é tentar conven cer seus superiores e os usuários que uma estimativa detalhada e corre ta
exige algum esforço inicial para identificar as unidades do trabalho ser feito.
Mas qual deve ser o tamanho das unidades de trabalho? Alguma empresas medem o trabalho em
unidades de um mês, o que parece sei muito grande - os projetos podem ficar seriamente fora de
controle fl( intervalo de um mês. Talvez seja iis razoável medir o trabalho err unidades iguais a
uma semana; como disse um veterano gerente &
614
projeto: “Nada útil pode ser feito em menos de uma semana». Entretanto, a unidade mais comum
talvez seja o dia; ele se ajusta à perfeição ao modo como organizamos nossa vida profissional.
Algumas organizações realmente medem seu trabalho em unidades de uma hora; embora de fato
existam muitas atividades que tomam uma hora ou menos (ex.:
definir um elemento de dados no dicionário de dados), essa unidade parece ser excessivamente
pequena para ser utilizada.
B.3.2 Faça as Unidades de Trabalho Tão Pequenas Quanto Possível
Um problema que tem prejudicado muitas estimativas é a intera ção, ou o acoplamento, entre dois
fragmentos de trabalho. Se um sistema estiver dividido em muitas e muitas interações, o volume
total de traba lho para desenvolver esse sistema será muito maior que a soma linear do trabalho de
todos os fragmentos. Se for feita uma modificação no fragmento 13, por exemplo, essa
modificação pode causar problemas no fragmento 14, e uma modificação no fragmento 14 pode
resultar em modificações no fragmento 15, e assim por diante. Esse efeito de onda tem feito
estragos em muitos projetos.
A solução é dividir o sistema em fragmentos pequenos e indepen dentes que se acoplem apenas
frouxamente com outros fragmentos. Isso requer um cuidadoso trabalho; esse aspecto foi discutido
no capítulo 20 como a principal razão lógica para agruparmos as bolhas de baixo nível no modelo
comportamental preliminar em agregados de nível mais elevado. A idéia de independência modular
também é importante duran te a fase de projeto; isso foi discutido no capítulo 22.
B.3.3 Leve em Consideração o Fator de Comunicação
Mesmo em um projeto em que todos os módulos sejam indepen dentes entre si, as pessoas
precisam falar umas com as outras. Se o projeto estiver sendo conduzido por uma só pessoa, então
as únicas comunicações necessárias serão com o usuário (e talvez alguns entendi mentos com a
direção). Porém um projeto típico tem muitos analistas de sistenías, projetistas, especialistas em
bancos de dados e programadores; pior ainda, algumas dessas pessoas podem trabalhar em
empresas dife rentes ou até falarem linguas diferentes.
Assim sendo, suas estimativas devem incluir algum tempo para a comunicação entre todos os
componentes do projeto. Essas comunica ções podem tomar a forma de reuniões, memorandos,

Página 413 de 584
conversas telefô nicas, e outras. Lembre-se que o volume de comunicações amplia-se à
615
proporção que cresce o tamanho da equipe do projeto: o número de vi; de comunicação entre os
membros da equipe cresce com o fatonal d número de indivíduos.
B.3.4 Faça a Distinção Entre Serviço Novo e Serviço Aproveitado
Se tiver sorte, a equipe do projeto poderá fazer uso de serviç feitos para projetos anteriores; muitas
vezes isso toma a forma de módi los em uma biblioteca comum de software . Entretanto, você não
de pressupor que os módulos reutilizáveis estejam livres; será preciso ui certo trabalho para (1)
encontrá-los, (2) examiná-los para ver se ek perfazem as funções desejadas e (3) conhecê-los
melhor, para sab como utilizá-los. É mais apropriado estimar que os módulos aproveit; dos exigirão
uma certa fração (talvez 25% ou talvez menos de 10%) d trabalho que seria necessário para
desenvolver esses módulos desde princípio.
B.4 FÓRMULAS PARA ESTIMATIVAS
Durante os últimos 20 anos, a indústria de desenvolvimento de si temas investiu um enorme
volume de tempo e esforço no desenvolv mento de modelos, ou fórmulas, para ajudar a predizer o
tempo a S despendido, os recursos e o custo de um sistema. Alguns desses modelc estão agora
amplamente em uso; talvez o mais conhecido seja o model COCOMO desenvolvido por Barry
Boehm na TRW . Mas, como diz Tor DeMarco em Controlltng Software ProfecLs,
Não existem modelos de custos transportáveis. Se você ficar espe rando que alguém em algum
lugar desenvolva um conjunto de fór mulas que você possa utilizar para prever os custos de seu
próprio negócio, você talvez fique esperando para sempre. Grande parte de nossa indústria
concluiu, lepois de admitir este fato, que a mode lagem de custos era irrelevante. Eu considero essa
conclusão errada. Se os modelos de custos desenvolvidos localmente puderem ser usados para
melhorar a precisão do processo de avaliação de custos, e a melhora vale o custo do
desenvolvimento dos modelos, então a idéia é viável.
Contudo, é interessante examinarmos algumas das fórmulas usada
em outras organizações; elas podem dar-nos um ponto dc partida para
desenvolvimento de nossas próprias fórmulas. Algumas dessas fórmula
616
nvolvem até 40 fatores ou parâmetros; mas, como veremos, algumas nvolvem apenas um fator.
B.4,1 Fórmulas para Estimar o Tempo de Trabalho
Três fórmulas comuns para a estimativa do esforço (medido em pessoas/mês) são baseadas em
linhas de código. Walston e Felix desen volveram um modelo na IBM (veja [ e Felix, 1977]),
fundamenta do em cerca de sessenta projetos, que é expresso como
E=5.2L 091
onde E é medido em pessoas/mês e L é medido em milhares de linhas
de código.
De forma semelhante, Bailey e Basii desenvolveram uma fórmula

Página 414 de 584
baseada em 19 projetos; ela é expressa como
E=3.4+0.72’DL 117 mais ou menos 25%
onde o esforço era também medido em pessoas/mês e DL significa mi lhares de linhas de código
entregues; veja IBailey e Basili, 1983].
Para finalizar, o modelo COCOMO, de Barry Boehm, tem uma
fórmula de esforço para três diferentes tipos de sistemas: sistemas orgâ nicos, sistemas
sernidestacados e sistemas embutidos:
E=2.4KDSI 105 (sistemas orgânicos)
E=3.OKDSI 1.12 (sistemas semidestacados)
E=3.6’KDSI 1.20 (sistemas embutidos)
onde KDSI representa “kilo delivered source in&ructions” (quilo-instru ções-fonte entregues); veja
maiores detalhes em [ 19811.
B.4.2 Fórmulas para a Estimativa do Tempo
Após desenvolver uma estimativa do volume do trabalho a ser feito, você pode pensar que seja
fácil estimar a extensão do tempo que o projeto exigirá. Afinal, se você tem um projeto estimado
em 10 pessoas/ mês de trabalho, e há 5 pessoas disponíveis, ele deve levar 2 meses para ser
completado. Mas, e se somente 2 pessoas estiverem disponíveis? O projeto levará 5 meses para
ficar pronto?
617
De um modo geral, a nossa preocupação aqui é com a bargan tempo e pessoal. Muitos anos de
dolorosa experiência ensinaram-n que a barganha não é simples: duplicar o número de pessoas em
i. projeto não reduz necessariamente a duração do projeto pela metade.] realidade, Fred Brooks, o
arquiteto do original sistema operacior OS/360, cunhou a frase: “O acréscimo de mais pessoas a
um projeto software atrasado apenas o atrasa ainda mais”. Há dois motivos para is (1) a inclusão de
mais pessoas aumenta as comunicações necessári entre os membros da equipe, o que reduz a
produtividade e (2) algum tarefas do projeto são indivisíveis, só podendo serem feitas por ur pessoa
e a inclusão de mais gente de nada adiantará. Embora seja uti idéia útil, ela não nos diz
especificamente de quantas pessoas um proje necessitará e nem quanto tempo será com ele
despendido. Essa ár também foi tema de pesquisa; Barry Boehm encontrou, por exempi que o
tempo de desenvolvimento de um projeto pode ser expresso pe seguinte fórmula:
T=2.5E 0.33
onde E é o esforço do projeto medido em pessoas/mês; veja os detalh
em EBoehm, 1981],
Também foram feitos estudos sobre “manpower loading” (lotaçi de capacidade humana) ótima para
um projeto; as três fórmulas ma conhecidas fundamentam-se na obra de Norden, Putnam e Parr; ve
[ 19631, [ e Fitzsimmons, 1979] e tParr, 1980]. Norden foi primeiro a descobrir que a equipe de um
projeto obedece a uma cun semelhante à mostrada na figura B.1.
O diagrama também é conhecido como a distribuição de Rayleig] com base na fórmula matemática
da curva. Putnam apresentou uma fó mula que determina o número de pessoas necessárias ao

Página 415 de 584
projeto ei função do tempo.
Pessoas(O=2K*a*t*exp( 2)
onde K é o esforço total do projeto (expresso em pessoas/mês) e a é ur fator de aceleração que
estabelece a subida inicial da curva (observe qu K representa a área total sob a curva).
Um modelo alternativo foi desenvolvido por Parr lParr, 1980 embora a forma geral apresente
alguma semelhança com a figura B.1, ei estima uma quantidade maior de pessoas nas fases iniciais
do projeto. ( modelo de Parr é descrito pela seguinte fórmula:
Pessoas(t)= 1/4sech 2
618
12 14 16 18 Tempo
Figura B.1: A alocação típica de pessoas em um projeto
B.5 MODELOS DE ESTIMATIVA COMPUTADORIZADA
A idéia de utilizar fórmulas com expoentes e secantes hiperbóli cas provavelmente não é muito
atraente; você pode ter certeza de que a maioria dos analistas de sistemas veteranos há muito já
esqueceu o que seja uma secante hiperbólica e não faz idéia de como calcular um ex poente! Mas
não é preciso guardar de memória qualquer das fórmulas, e nem é necessário executar os cálculos
manualmente. Existem disponí veis atualmente muitos pacotes de avaliação de projetos; a maioria
fun dona em PC e muitos deles utilizam o modelo COCOMO de Boehm e o modelo de Putnam,
acima descrito. Alguns também podem incorporar os diagramas PERT e GANTT discutidos no
capítulo 16.
Se estiver trabalhando em algo que não seja um sistema trivial, você definitivamente deve
examinar esses pacotes. Eles não somente executam os cálculos para você, mas possibilitar-lhe-ão
fazer simulações do tipo “e se” para verificar os efeitos da inclusão dc pessoas ao projeto ou d
diminuição de pessoas face a doenças ou outras calamidades.
REFERÊNCIAS
1. Tom DeMarco, Controllin Sof/ware /‘rojecls. Nova lorque:
619
2. Barry Boehm, Software Engíneering Econornícs. Englewood Cl
Nj.: Prentice-Hall, 1981.
3. Workshop on Quantítative Software Modeis for Relíability, Com
xíty, and Cost: An Assessment ofthe State ofthe Art. IEEE Cata
No. TH0067-9. Nova lorque: Institute of Electrical and Electror
Engineers, 1979.
4. Victor Basili, Tutorial on Model and Metrics for Software Mana
ment and Engineering. Nova Lorque: Institute of Electrical
Electronics Engineers, 1980.

Página 416 de 584
5. C.E. Waiston e C.P. Felix, «A Method of Programming Measu
ment and Estimation”, lBMSysteinsJournal, Volume 16, Númer4
(janeiro de 1977), pgs. 54-73. Reimpresso em Writings ofthe Re
lution, Edward Yourdori (editor). Nova lorque: YOURDON Pre
1982, pgs. 389-408.
6. j.W. Bailey e V.R. Basili, «A Meta-Model for Software Developm
and Resource Expenditures”, Proceedings of the 5th Internatioi
Conference on Software Engineering. Nova lorque, Institute
Electrical and Electronic Engineers, 1983.
7. P.V.Norden, “Useful Tools for Project Management”, Operat
Re in Research and Development. Nova lorque: Wiley, 19
8. Larry Putnam e A. Fitzsimmons, «Estimating Software Costs”, Da
mation, setembro de 1979, pgs. 89-98; outubro de 1979, pgs. r
178; novembro de 1979, pgs. 137-140.
9. F.N.Parr, «An Alternative to the Rayleigh Curve Model for Softw
Development Effort”, IEEE Transactions on Software Engineer
Volume SE-6, Número 3 (maio de 1980), pgs. 291- 296.
10. T.Capers Jones, Programming Productivity. Nova Iorque: McGra
Hill, 1985.
NOTAS
1 Lembre-se também que as estimativas quase certamente precisat
ser revistas durante o projeto à proporção que as circunstânc
mudarem. Fatores externos (condições comerciais, novos comI
tidores, fusões etc.) podem fazer com que o usuário mude s
opinião sobre a funcionalidade requerida, sobre as despesas or
mentárias ou sobre a data exigida de entrega. Fatores interr
(mudanças na equipe, dificuldades inesperadas de implementaç
etc.) também podem causar modificações nos orçamentos e cror
gramas, habitualmente de modo substancial.
2 Algumas avós talvez discordem totalmente dessa suposição!
3 Existe um Outro elemento de barganha, mas dificilmente fala
sobre ele explicitamente: a qualidade. Muitos gerentes de proj
620
tentam operar milagres entregando toda a funcionalidade exigida dentro dos prazos impostos pelo

Página 417 de 584
usuário e com os recursos menos- que-ótimos oferecidos; mas o inevitável resultado é um sistema
que tem mais erros e é menos manutenível do que seria se as coisas fossem diferentes.
4 Uma das primeiras indicaç disso foi um artigo intitulado “Ex ploratory Experimental Studies
Concerning Online and Offline Programming Performance”, de H. Sackman, Wj. Ericksn e E.E.
Grant na edição de janeiro de 1968 de Communtcations of the ACM O estudo mostrou uma
variação de 26/1 entre os melhores e os piores programadores, que haviam recebido a mesma tarefa
de programação. Essa variação entre bons e maus programadores foi observada diversas vezes
duranie os últimos 20 anos.
5 Deus está olhando por sobre meu ombro e está dizendo: “Não, não é ótimo”. Talvez você queira
assumir o risco de não ser capaz de entregar o projeto no prazo e orçamento otimistas que você
estiver prometendo, porém um fracasso fará mais do que prejudicar sua carreira. Fazer estimativas
otimistas e irreais é antiético, antiprofis sional e intelectualmente desonesto, quando seu superior,
seus usuários e toda a organização podem sofrer consideráveis perdas por sua incapacidade de
entregar o que prometeu.
6 A expressão ponto de função foi apresentada por A.J. Albrecht para descrever isso; veja
“Measuring Application Development Producti vity”, Proceedings of the Joint SI-IA RFJGUIDE
Application Develop ment Symposium (Chicago: GUIDE International Corp., 1979). Tom
deMarco utiliza a expressão “function bang” mais ou menos da mesma forma; veja seu livro,
Controlling Software Profects (Nova Jorque: YOURDON Press, 1982) para maiores detalhes. Veja
tam bém Programming Productivity, de Capers Jones (Nova lorque:
McGraw- Hill, 1986), onde consta uma completa discussão das di ficuldades de medir a
produtividade e os muitos fatores que a afetam.
7 Um homem/milênio é o mesmo que mil homens/ano de trabalho. Eu utilizo a palavra «homem”
deliberadamente, porque estou con vencido que as mulheres são demasiadamente inteligentes para
se deixarem induzir a fazer estimativas em unidades tão grandes e tão machistas! A expressão
«homem/milênio” foi sugerida originalmen te por um cliente da minha firma, uma grande empresa
de utilidade pública da Califórnia.
8 Mas também pode ser possível reutilizar partes de um projeto, partes de um modelo de requisitos
de usuário ou até partes de um estudo de viabilidade. No passado, normalmente não se fazia isso
porque o modelo de projeto, os modelos da análise e os estudos de viabilidade não eram bem
documentados e nem se fazia sua
621
manutenção. Agora, com a proliferação dos produtos de estaçô inteligentes de análise do tipo
discutido no apêndice A, isso e tornando-se mais prático.
9 Para uma discussão mais detalhada desse modelo veja Softwa
Engtneertng Economics, de Barry Boehm (Englewood Cliffs, N,
Prentice-Hall, 1981).
622
c
CÁLCU DE

Página 418 de 584
CUSTO/BENEFÍCIO
C.1 INTRODUÇÃO
Este apêndice dedica-se às técnicas de cálculo do custo/beneficio, uma importante parte do esforço
de analise de qualquer sistema. Seu objetivo é, naturalmente, demonstrar aos usuários do novo
sistema, bem como a outros grupos de diretores da empresa, que os benefícios do novo sistema
excedem os custos esperados.
Como analista júnior você talvez não seja envolvido nesse esforço, ou talvez receba a tarefa de
desenvolver o modelo de custo/beneficio para uma pequena parte do sistema geral. Mesmo como
analista de sistemas sênior a cargo de todo o projeto, você pode não participar dos cálculos de
custo/benefício; eles podem ser feitos, por exemplo, por um independente grupo de finanças, em
separado.
Ou ele pode não ser executado! Muitos sistemas são desenvolvidos em algumas organizações
simplesmente para satisfazer exigências governamentais obrigatórias (ex.: sistemas de relatórios
para o “Equal Employment Opportunity Act” ou novos sistemas para lidar com as modificações da
legislação sobre impostos). É claro que, mesmo nesses casos, quando não há benefícios a serem
auferidos do sistema (exceto pelo fato de evitar sanções e ter autorização de permanecer no merca
do!), normalmente a direção deseja saber qual será o custo do sistema; mas isso pode ser executado
como parte das atividades de avaliação discuiidas no apêndice B.
Existe um outro motivo pelo qual o estudo de custo/benefício pode não ser executado: o usuário
talvez não o deseje. Assim como um consumidor pode não ser capaz de justificar um Cadillac, em
termos de custo (ele talvez precisasse apenas de um pequeno Honda ou até de uma bicicleta),
muitos usuários são incapazes de justificar, quanto ao custo, um novo sistema que tenham
solicitado. Por vezes eles solicitam
623
um novo sistema pelos mesmos motivos que um consumidor adquire un carro dispendioso - para
manter o nível em relação a seus pares ‘.En outros casos, o usuário pode achar que existe a legítima
necessidade dc novo sistema, embora reconhecendo que todos os benefícios sâ intangíveis ou
extremamente difíceis de quantificar; o usuário podc justificar a solicitação do novo sistema
alegando uma “intuição d empresário” de que ele valerá o custo.
Como analista de sistemas, não é da sua competência insístfr en que deva ser efetuado um cálculo
de custo/beneficio; afinal de contas, sistema é do usuário, e se ele quiser construí-lo sem justificá-
lo, é prerro gativa dele. Entretanto, é uma boa idéia descobrir se foi feito um cálcuk de
custo/beneficio para o projeto e, caso afirmativo, se ele é razoável Se não existir esse estudo, ou se
os benefícios forem muito vagos (ou s os custos foram subestimados de forma gritante), você deve
compene trar-se de que o projeto é vulnerável.
No pior dos casos, você perceberá que o usuário não está muitc:
entusiasmado com o projeto, mas foi pressionado pela direção superior com base nos cálculos
otimistas do gerente do projeto que realment deseja construir o sistema (porque vai melhorar sua
carreira, porque ek acha que todos os usuários devem ser computadorizados, ou por cc outras
razões). No melhor dos casos, o usuário autorizou o sistema e est muito entusiasmado com ele a
despeito da falta de um cálculo raciona de custo/beneficio. Mas os usuários são volúveis: o sistema

Página 419 de 584
predileto di hoje pode tornar-se o sistema descartado de amanhã.
E os usuários vão e vêm: o usuário que autorizou o projeto onterr pode ser substituído amanhã por
um novo usuário que tem uma visãc muito diferente da conveniência do projeto. Desse modo, se
não houve um estudo de custo/benefício (e for evidente que ninguém quer elab rá-lo), meu
conselho é muito simples; mantenha seus assentamento atualizados, porque você poderá estar em
busca de um novo empregc antes do projeto terminar.
Nas seções a seguir, examinaremos diversos aspectos dos cálculo
de custo/benefício:
• Análise de custos
• Análise de benefícios
• Como expressar a economia
• Análise de riscos
624
C.2 ANÁUSE DE CUSTOS
O objetivo desta atividade é, naturalmente, calcular antecipada mente todos os custos associados ao
sistema - não somente o custo de construir o sistema, mas também o custo de sua Instalação,
operação e manutenção, bem como os custos agregados. Discutiremos todos eles a seguir.
C.2.1 O Custo da Construção do Sistema
No apêndice B discutimos as técnicas para estimar a extensão do tempo necessário para construir
um sistema e o número necessário de pessoas. Lembre-se que você não só precisa calcular o custo
dos progra madores e dos analistas de sistemas, mas também o de todas as outras pessoas
envolvidas no desenvolvimento do sistema:
• Burocratas
• Diretores
• Membros da comunidade usuária
• Consultores e programadores contratados
• Possivelmente membros da auditoria, do controle de qualidade ou da equipe de operações
Na maioria dos casos você poderá obter com a direção (ou com o departamento de contabilidade) o
salário médio das categorias de pes soas incluídas em seu projeto; esse salário médio pode ser
expresso em termos de custos horários, custos mensais ou anuais. Certifique-se de considerar o
fator de encargos de sua empresa; isto é, você provavel mente terá de multiplicar cada salário por
um fator de, digamos, 150% para cobrir os custos de seguros, beneficios, e diversos outros fatores
agregados de encargos. Você também pode obter esses valores com a direç ou com o departamento
de contabilidade.
Lembre-se de que as pessoas que trabalham no projeto não estarão disponíveis 100% do tempo:
algum tempo será necessariamente perdido face à inatividade, às férias, licenças e coisas
semelhantes. Sua firma pode ter um fator padronizado para aplicar a esse tempo perdido: caso
contrário, você pode admitir o valor mínimo de 10%; 20 a 25% não são tão irreais (é possível que

Página 420 de 584
isto já tenha sido considerado nas estimativas de recursos vista no apêndice B. Verifique esse
detalhe para assegurar-se
625
de que o fator de tempo perdido não tenha sido deixado de lado e ne seja aplicado duplamente).
Em muitos projetos você deve incluir também o custo do trem mento da equipe de
desenvolvimento. Os componentes da equipe p dem precisar ser adestrados em novas metodologias
de desenvolvimei to, novas linguagens de programação ou em diversos recursos de har ware e de
software relativos ao fornecedor do equipamento que estiv sendo utilizado. Outro custo que deve
ser levado em consideração é do tempo de máquina, terminais, estações de trabalho e ferramentas c
desenvolvimento (editores, pacotes de testes etc.) que sejam necessárk ao desenvolvimento do
sistema. Em alguns casos, os terminais e ferramentas de desenvolvimento podem já existir e seu
projeto pode n incorrer em despesas adicionais; em virtualmente qualquer cas( portanto, o projeto
deverá incluir os custos do tempo de máquina envo vido (observe que isso pode incluir os custos de
memória em disco, custos de telecomunicações, e os custos relativos a papel, formulários Outros
itens correlatos).
Alguns projetos novos são desenvolvidos com pessoas novas, ist é, pessoas que não trabalhavam
para a organização anteriormente a projeto e para as quais presumivelmente não existiam
acomodações nc escritórios. Assim sendo, você talvez tenha de incluir custos de recrut; mento
(despesas de transporte para os candidatos a empregos, taxas d recrutamento para as agências de
empregos etc.), assim como despesa com pessoal relativas ao treinamento de adaptação inicial pelo
qu devem passar todos os novos empregados. E pode ser necessário inclu o custo do espaço,
mobiliário, telefones e outros equipamentos para novo pessoal.
Em alguns projetos existem também custos de transporte de visit que precisam ser feitas a
instalações remotas dos usuários que precisei ser entrevistados. Evidentemente, este não é um fator
para um projet em que todos os usuários estejam localizados na mesma área geográfic da equipe de
desenvolvimento; mas, nos projetos em que existem dive sos grupos de usuários em diferentes
localizações (muitas vezes ei diferentes países), essa despesa pode ser importante. A propósito, a
dir ção muitas vezes presumirá que todas as informações necessárias podei ser coletadas em uma
viagem; nos projetos reais, muitas vezes são n cessárias diversas viagens para resolver dúvidas e
mal-entendidos .
Dessa forma, os custos do desenvolvimento de um sistema podei
ser muitos e diferentes entre si. A lista a seguir resume a discussão acim
ela pode não ser completa, mas cobre os itens mais importantes:
• Salários e encargos relativos a todo o pessoal ligado ao projeti
• Custos de treinamento
626
• Tempo de máquina e ferramentas de desenvolvimento para a equipe
• Custos do recrutamento da nova equipe
• Espaço e equipamento de escritório para a nova equipe

Página 421 de 584
• Despesas de transporte com visitas a usuários remotos
C.2.2 O Custo da Instalação do Sistema
Em um projeto simples, pode ser suficiente telefonar ao usuário e informar que o desenvolvimento
do sistema está terminado; você pode ser capaz de entregá-lo em um disquete, e deixar que ele o
instale em seu próprio computador pessoal. Mas, no caso de sistemas grandes e complexos, o
processo de instalação é muito mais do que isso, havendo muitos custos envolvidos. Entre eles
estão:
• Custos de treinamento de usuários
• Custos de conversão de bancos de dados
• Custos de instalação do fornecedor
• Custos da aprovação legal
• Custo do processamento paralelo
• Custo da equipe de desenvolvimento durante a instalação
Normalmente, toda a comunidade usuária precisará de algum trei namento para familiarizar-se com
a utilização do sistema. Pode ser ne cessário um treinamento adicional para os usuários
supervisores, poden do, ainda, ser necessário algum treinamento para a equipe de operações e para
diversos outros grupos auxiliares. Observe que isso significa que também devemos incluir o custo
do desenvolvimento dos cursos de treinamento do usuário, o custo dos manuais de treinamento ou
da do cumentação dos cursos, bem como o custo dos recursos de treinarnento dos usuários (salas
de aula etc.). Para terminar, não esqueça o custo do tempo do usuário durante o processo de
treinamento; você pode ser solicitado a calcular este último em termos dos salários dos usuários, ou
a ter de calculá-lo em termos do custo de substituição das pessoas que
627
estiverem desempenhando as tarefas dos usuários enquanto est estiverem sendo adestrados.
Os custos de conversão de bancos de dados podem ser ignorad se você estiver instalando um novo
sistema para o qual não existe prec cessor. Mas se esse novo sistema estiver substituindo um outro
sisterr então quase certamente haverá um banco de dados que precise 5 adaptado para o novo
sistema. Se o banco de dados já existente não computadorizado (isto é, pastas de arquivos repletas
de pedaços papel), poderá haver um substancial custo relacionado à entrada dados; isto é, alguém
(ou talvez um grande grupo de pessoas) provav mente terá de sentar-se a um terminal e introduzir
todos os dados impc tantes no computador. Se os dados existentes já estiverem computado zados,
poderá haver um custo um tanto menor envolvido na convers mecânica dos arquivos antigos para o
novo formato
Os custos de instalação do fornecedor não devem ser ignoradc principalmente se o sistema
envolver novo hardware, novo equipamen de telecomunicações e/ou novo software. Os
fornecedores geralmen dão uma boa estimativa dos custos de instalação, e você deve consegi. que
eles apresentem cotações a custos fixos.
Para alguns sistemas poderá haver um custo de licenças ou outr formas de aprovações de várias
autoridades, locais, estaduais ou do g verno federal. Isso também pode incluir testes ambientais dc
emissõ de radiação proveniente das telas dos terminais utilizados pelos oper dores de entrada de

Página 422 de 584
dados do usuário. Se a aprovação legal for u procedimento simples, envolvendo apenas o
preenchimento de formi lários, você poderá estimar os custos de modo bem acurado; se, invés, ela
envolver um processo de testes não rigorosamente fixados, si estimativa será apenas aproximada.
Os custos do processamento paralelo, se houver esse process mento, também deve ser incluído na
avaliação dos custos de instalaçã Em muitos tipos de sistemas o usuário insistirá em que o sistema
anti seja processado em paralelo com o novo por um certo período. Is. pode implicar na duplicação
temporária da equipe usuária ou outn despesas relacionadas. Você deve informar-se (se possível, na
especific ção do sistema) do período em que esse processamento em paralelo v perdurar; essa
informação poderá ajudá-lo a desenvolver uma estimatii adequada.
Tenha cuidado em não esquecer o custo da equipe de desenvc vimento envolvida na instalação.
Normalmente, os programadores analistas de sistemas que estiveram envolvidos no
desenvolvimento d projeto estarão fortemente envolvidos em sua instalação. Evidentementi além
de seus salários (e possivelmente as horas extras) e encargos, VO( também deve considerar
quaisquer despesas de transporte necessári; à instalação do sistema em uma localização remota do
usuário.
628
Finalizando, lembre-se que a instalação de grandes sistemas não ocorre de uma só vez; um novo
sistema bancário, por exemplo, pode ser instalado em uma agência de cada vez, durante um
período de vários meses. Isso significa que, de um modo geral, o custo de instalação das primeiras
ramificações (Ou áreas de usuários) serão mais caras do que as seguintes, porque a equipe de
instalação irá adquirindo mais expe riência e (esperamos) qualquer problema inicial com o sistema
será resolvido após as primeiras instalações. Por outro lado, se o processo de instalação prolongar-
se por diversos meses (ou mesmo anos), você deve considerar a possibilidade da renovação da
equipe: pessoas que adquiri ram experiência com a instalação do sistema e com o treinamento de
grupos usuários podem cansar-se do processo e transferirem-se para um novo emprego em outro
lugar.
C.2.3 O Custo do Dinheiro
O dinheiro necessário para desenvolver e instalar um sistema não dá em árvores; ele pode ser
obtido pela empresa através de um emprés timo ou pode provir de suas atuais reservas. Dessa
forma, existe um cus to relacionado à utilização do dinheiro. Dependendo de sua organiza ção,
você pode ser solicitado a expressá-lo como sendo o custo do em préstimo feito ou em termos dos
juros que o dinheiro poderia estar ren dendo se tivesse sido investido em lugar de ser utilizado em
seu projeto.
Essa é uma área em que você deve recorrer à orientação do depar tamento de contabilidade. Eles
certamente terão uma diretriz padr para tratar desses assuntos, e é importante que seu projeto
observe a mesma abordagem.
C.2.4 Custos Operacionais
Após haver instalado o sistema, haverá um custo para que o usuá rio possa continuar sua operação.
Entretanto, isso também deve repre sentar uma área em que seu novo sistema economizará
dinheiro, por quanto ele presumivelmente será mais barato que o atual sistema de que o usu dispõe
(a menos que você lhe tenha acrescentado um grande volume 4 funcionalidade). Os custos

Página 423 de 584
operacionais típicos São:
• Custos de hardware e de suprimentos e equipamentos correlatos
• Custos de software
• Custos de pessoal
629
• Custos de manutenção
• Custos dos recursos
Hardware é empregado aqui em um sentido muito abrangent incluindo o custo dos equipamentos
computacionais (presumindo- que eles ainda não tenham sido adquiridos em sua totalidade, mas ve
também a seção C.2.6), equipamentos de telecomunicações, terminai estações inteligentes e
suprimentos (papel, formulários, discos flexívei disk packs, fitas para impressoras etc.). Lembre-se
de que alguns iter de hardware podem ser considerados como material consumível un vez que se
desgastam com o uso e precisam ser substituídos. Isso mcli terminais, algumas impressoras e talvez
outros tipos de materiais c hardware. Certifique-se de que os períodos futuros reflitam os custos d;
substituições que forem necessárias.
Custos de software, nesta discussão, significam os custos continu:
dos de “leasing” de sistemas operacionais, pacotes de gerenciamento c bancos de dados e outros
softwares de sistemas que sua empresa poc ter com um fornecedor de software.
Custos de pessoal incluem a equipe de operações, o pessoal d suporte técnico, programadores de
manutenção, e o custo dos usuárk diretamente envolvidos na operação diária do sistema. Como já
foi disci tido, você provavelmente terá de expressar isso como um custo pai considerar seguros,
beneficios e outros encargos.
Custos de manutenção incluem o esperado custo mensal (o anual) da manutenção dos
equipamentos computacionais; sua estimati neste aspecto deve incluir não somente o custo da
manutenção prevei tiva oferecida pelo fornecedor, mas também qualquer custo complemei tar
relativo aos reparos provocados pelas falhas dos equipamento Também devem ser incluídos os
custos de manutenção do software dc fornecedores, se isto for aplicável; o contrato de manutenção
oferecid pelos fornecedores costuma incluir um telefone especial para supoil técnico, bem como
mudanças gratuitas (ou a preços reduzidos) pai novas versões de seus pacotes.
Além disso, o custo de manutenção deve incluir uma estimativa d custo do reparo e do
aperfeiçoamento do software aplicauvo, que pod ser um importante fator de custo, o que é
evidenciado pelo fato de qu a maioria das organizações despe ide mais de 50% de seus orçamentc
de processamento de dados em manutenção. Existem diversas maneir; de estimar os custos de
manutenção do novo sistema:
• Se o seu sistema for substituir um sistema antigo, você pode e timar que o novo sistema exigirá o
mesmo volume de esforço d
630
manutenção. Esse esforço é bastante conservador, por implicar em que o sistema antigo tenha sido
desenvolvido com utilização de técnicas de engenharia de software modernas e que o novo sistema

Página 424 de 584
não utilizará técnicas ainda mais modernas e mais efi cientes. Isso é improvável no caso de o
sistema antigo ter já 10 ou 15 anos, mas pelo menos representa um tipo de estimativa de pior
possibilidade.
• Uma estimativa otimista pode fundamentar-se na economia esperada na manutenção do sistema
atual. Muitas organiza ções descobriram, por exemplo, que seus custos de manuten ção reduziram-
se por um fator de cinco ou mais em virtude da utilização cuidadosa da análise estruturada, do
projeto estrutu rado e da programação estruturada Você deve examinar outros projetos semelhantes
no âmbito de sua própria empresa para verificar se foram obtidas economias desse tipo; se assim
for, pode ser razoável esperar economias semelhantes em seu projeto. Acautele-se, contudo, contra
a tentação de mostrar substanciais reduções no pessoal com base na instalação de seu projeto; isso
raramente ocorre, pelos motivos discutidos na seção C.3.1.
• Caso não exista um sistema atual para ser usado em compa rações (ou se você quiser evitar
estimativas excessivamente otimistas ou pessimistas), experimente determinar o custo médio de
manutenção de sistemas semelhantes em sua organização. Ele provavelmente será baseado em
alguma unidade normali zada (ex.: valor da manutenção por linha de código por ano ou valor da
manutenção por ponto dc função por ano), mas as es timativas que você fez no apêndice B devem
possibilitar que você efetue as adequadas estimativas de manutenção para o seu projeto.
Um custo final que deve ser estimado quando calculamos o custo operacional do novo sistema é o
das instalações físicas (a sala do compu tador e as comodidades de escritório para a equipe de
operações, para o pess de manutenção do fornecedor e para a equipe usuária). Se o novo sistema
for ser executado em um mainframe central já instalado, esses custos de comodidades podem já
estar embutidos no custo geral do hardware acima discutido. Entretanto, se você estiver
desenvolvendo um sistema totalmente novo que terá suas próprias comodidades de funcionamento,
isso pode ser um custo importante.
631
C.2.5 O Custo das Falhas
Existe ainda um outro custo a ser considerado: o custo das potei ciais falhas do novo sistema. É
prático embutir esse custo na categor dos custos de funcionamento, mas isso tende a ocultar o que
se tomai um aspecto de crescente importância dos sistemas de informações r futuro: a
confiabilidade.
Existem, como pode-se imaginar, diversas formas de falhas de ui sistema: em alguns casos, o
sistema torna-se completamente indispon vel até que o erro seja corrigido, enquanto que em outros
casos o si tema continua funcionando, porém uma ou mais de suas saidas est incorretas. Em alguns
casos, algumas funções do sistema podem nã funcionar, e em outros casos, alguns usuários podem
não consegu acesso ao sistema. Todas essas formas de falhas têm um custo associad custos de
hardware, custos de software, custos do pessoal envolvido r correção do erro, possíveis custos
legais se o sistema tiver provocad perdas financeiras ou alguma outra perda grave, e possivelmente
perd de receita ou perda de clientes.
Como devemos estimar coisas assim? Seria ingenuidade ignori toda essa área, pois ainda não
atingimos a capacidade de constru sistemas perfeitos; por outro lado, se você indagar a um dos
program; dores ou a um dos analistas de sistemas do projeto quantas falhas elc calculam que

Página 425 de 584
existam no novo sistema, eles irão olhá-lo como se voc estivesse sofrendo de alguma nova forma
de senilidade.
A atitude mais responsável que você pode adotar é (1) examinar taxa de falhas do sistema atual, se
você estiver construindo um nov sistema para substituir um já existente, e (2) examinar a taxa de
falhas d todos os outros sistemas de sua organização 6• Após isso você poderá e tar capacitado a
fazer algumas suposições razoáveis sobre a taxa de f lhas que pode ser esperada do novo sistema.
Seu projeto talvez sej construído com substancialmente menos erros que o sistema atual, o até
mesmo menos que o sistema médio de sua empresa; você deve, n verdade, empenhar-se em um
aperfeiçoamento de no mínimo dez vez ou mais.
Se não existirem estatísticas disponíveis sobre confiabilidade d software do sistema atual de sua
empresa e nem uma base sobre a qu; possa ser feita uma estimativa para o novo sistema, você deve,
pel menos, incluir este fato no documento da análise de riscos; veja maiorc informações na seção
C.5. Se você estiver construindo um sistema grar de e complexo no qual uma falha teria
conseqüências de longo alcanc potencialmente desastrosas, é profissionalmente inaceitável não
exist um modelo de confiabilidade de software, a despeito do fato de qu a maioria das empresas
atualmente não se preocupe com isso. Par
632
maiores informações nessa área, veja Software Reliabilily, de Glen Myers (Reading, Mass.:
Addison-Wesley, 1979).
C.2.6 Faça Distinção entre Custos de Capital e Custos de Despesas
Alguns dos custos relativos ao novo sistema serão despendidos durante o ano em que ocorrem; isto
é, sua organização reconhecerá esses custos na declaração de L&P (e nos pagamentos de impostos
arqui vados no IRS) durante o ano de sua ocorrência. Outros custos são capi talizados, isto é, os
custos são diluídos por um período de diversos anos. Embora isso não afete o custo total do
sistema, a classificação de um custo como de despesa e não como de capital pode ter grande
impacto na situação da empresa em relação aos impostos. De forma semelhante, a decisão de
incluir alguns custos como relativos a compras em lugar de aluguéis pode ter significativo impacto
no fluxo de caixa da empresa, ainda que o custo total permaneça o mesmo.
Normalmente as aquisições de hardware são consideradas como despesas de capital, e o custo é
distribuído por um período de 5 a 7 anos (dependendo das leis vigentes sobre impostos). O custo
do desenvolvi mento de software pode ou não ser capitalizado. Custos de instalação e de operação
são normalmente despendidos no período em que ocorrem, embora possa haver pequenas variações
nessa área.
Evidentemente, essa não é uma área em que você possa criar sua própria doutrina de
contabilização. É importante descobrir que padrões financeiros são utilizados em sua empresa e
segui-los de modo consistente.
C.3 ANÁUSE DE BENEFÍCIOS
É bem mais dificil calcular os beneficios esperados de um novo sistema de informações do que
calcular seus custos. Em alguns casos, como mencionado no início deste apêndice, pode ser
impossível - ou porque o sistema seja mandatório ou porque o usuário decidiu que quer o sistema
quaisquer que sejam os beneficios concretos que possam ser identificados.

Página 426 de 584
É a tentativa de calcular beneficios concretos que causa tantos problemas. Os usuários não
costumam se deixar levar pelo entusiasmo com coisas como “melhor controle” ou “informações no
momento apro priado” ou “melhores ambientes para tomadas de decisões”, mas se lhes for
perguntado quanto pensam economizar ou qual o proveito que será obtido, eles provavelmente
responderão vagamente: “Oh, muito, muito...
633
Tenho certeza que será ótimo!”. Na verdade, o novo sistema será 6h
- mas palavras como ótimo não se ajustam muito bem a uma plani que mostra comparações
numéricas de custos e benefícios.
Dessa maneira, seu maior trabalho ao executar um cálculo de c to/beneficio será o de fazer com
que os usuários estipulem benefi concretos que possam ser medidos e calculados de forma
quantitati Caso você não seja capaz de fazer isso (o que acontece em mui projetos e com muitos
analistas de sistemas), tente fazer com que analistas de sistemas comparem seu novo sistema com
algum outro si ma com benefícios conhecidos. Desse modo, você pode dizer ao us rio: “Suponha
que você tivesse de escolher entre o novo sistema so que estamos falando e o Sistema X. Qual
deles você considera mais portante? Se só pudéssemos implementar um deles, qual você escol ria?”
Presumindo que o Sistema X tenha alguns benefícios concreto ele associados, isso deve dar-lhe
pelo menos um modo grosseiro determinar o valor aproximado do novo sistema. Nas próximas seç
faremos a diferenciação entre os benefícios táticos e os benefícios esi tégicos oferecidos pelo novo
sistema. Neste contexto, um beneficio co é o que permite que a organização continue executando a
mes atividade comercial, mas a um custo mais baixo (ou com lucros maion um benefício
estratégico é o que possibilita que a organização inicie tipo inteiramente novo de atividade ou
inicie atividades em uma rn área ou com novos clientes.
C.3.1 Beneficios Táticos
Os benefícios táticos estão muitas vezes relacionados a reduçi do pessoal burocrata ou
administrativo; embora isso não pareça mús para os ouvidos dos usuários burocratas, é sem dúvida
um fato da vi Um novo sistema de informações pode possibilitar que uma função s executada com
a metade do número de usuários e até menos que is Isso geralmente é motivado pelo fato de que os
usuários estão presen mente executando cálculos ou registros de dados à mão, quando i poderia ser
computadorizado; ou são forçados a executar as mesn atividades (ou registrar os mesmos dados)
múltiplas vezes, quando i poderia ser feito pelo computador dc uma só vez; ou eles despend um
tempo considerável na recuperação de dados, o que poderia ser fc rapidamente por um computador.
Embora isso seja um evidente beneficio do novo sistema, cui em não superestimar o efeito. Em
alguns casos, pode haver menos e nomia do que foi estimado; as leis e a natureza paternal dos
níveis termediários de chefia da organização usuária podem impedir q alguns daqueles usuários
burocratas sejam despedidos. E, igualmei
634
importante, você deve compreender que os níveis mais graduados de direção estão cada vez menos
impressionados pela economia de um ou dois funcionários; eles estão interessados em maiores e
melhores benefïcios provenientes da introdução de um novo sistema.
Uma forma de benefício tático ligeiramente mais interessante é a economia advinda da capacidade

Página 427 de 584
de processar as transações da empresa com maior rapidez. O tempo de retorno mais veloz (ou a
capacidade de manipular mais transações por segundo) não somente proporciona a oportunidade de
reduzir os custos com funcionários como conduz a um melhor fluxo de caixa para a organização
(isto é, convertendo os pedi dos dos clientes em dinheiro mais rapidamente, acelerando o tempo de
entrega dos pedidos etc.). O que se tem a fazer é quantificar e expressar isso em dinheiro. Mas,
para exemplificar, considere o seguinte diálogo entre o analista de sistemas e o usuário:
Analista: Quantos pedidos você processa por dia?
Usuário: Bem, processamos 10.000 pedidos por dia. Mas, sempre há alguns atrasados - de modo
que, em média, um pe dido leva cerca de uma semana para ser processado e remetido.
Analista: E a fatura é enviada para o cliente juntamente com seu pedido, certo? Assim, o cliente
não tem que pagá-la
antes de receber o pedido, não é?
Usuário: Isso mesmo.
Analista: Então, se pudermos reduzir o tempo de processamento de um pedido de cinco dias para
apenas um, p0- deríamos receber o pagamento do cliente quatro dias mais cedo, em média. E se o
pedido médio gira em torno de $1000 e nós processarmos 10.000 pedidos por dia, significa que
estaremos lidando com cerca de $10 milhões ao dia. A posse de $10 milhões quatro dias mais cedo
do que antes, para os pedidos de cada dia, valeria
Um sistema novo também pode proporcionar economia em reta ção ao equipamento
computacional; o sistema antigo pode estar sendo processado em um dispendioso computador de
grande porte, enquanto o novo sistema é executado em um pequeno PC na mesa do usuário. Essa
mudança não somente diminui os custos do hardware de proces samento, como também economiza
dinheiro na área dos custos das
635
acomodações, dos operadores, e coisas semelhantes. E, se o novo s tema reduzir o volume de
papéis e formulários impressos, isso també deverá refletir-se como economia. Assegure-se de que
seus cálculos c tejam completos neste aspecto; lembre-se de que serão necessári menos armários
para arquivamento de documentos, menores escritórir menos máquinas de escrever e, talvez,
menos chamadas telefônicas e tre sua empresa e os clientes, e assim por diante.
Os custos de manutenção do novo sistema também devem propc cionar um beneficio, como vimos
na seção anterior. As despesas manutenção do hardware devem reduzir-se (a menos que o novo sist
ma seja processado no mesmo equipamento instalado na organização), os custos da manutenção de
software serão presumivelmente menor que os do sistema atual.
C.3.2 Beneficios Estratégicos do Novo Sistema
Em muitos casos, os beneficios de um sistema que realmente tê interesse e importância são os
estralégicas - não somente a oportunid de de economizar uns poucos funcionários ou algumas
folhas de pap mas a capacidade de a organização fazer coisas que não seriam possíw com o sistema
atual. Existem diversos exemplos de benefícios estratél cos em potencial:
• Localizar ou atrair novos clientes que a organização, de out modo, não seria capaz de localizar.
• Penetrar em novos mercados ou oferecer novos produtos qi não estavam disponíveis

Página 428 de 584
anteriormente.
• Obter, reproduzir ou distribuir conhecimentos e habilidad que antes eram exclusivos de um ou
dois funcionários empresa.
Em uma economia tão competitiva como parece ser a nossa, u sistema de informações que possa
atrair novos clientes ou que pos evitar a perda dos clientes atuais para os concorrentes é realmente
vali so. Em alguns casos, isso pode ser possível porque o novo sistema ofer ce funções que não
estavam disponíveis antes; em outros casos, pode s conseqüência da capacidade do sistema em
identificar possíveis nov clientes que a empresa desconhecia anteriormente. Qualquer que seja
situação, você deve tentar quantificar esse benefício em termos aumento de clientes ou do aumento
da participação no mercado e, partir daí, em termos de receita e lucros.
636
Uma forma mais difícil de beneficio estratégico é a capacidade do novo sistema em fornecer
informações não disponíveis anteriormente. O exemplo típico disso é a capacidade do sistema em
identificar tendên cias e padrões (ex.: tendências de vendas por território ou por época ou a
preferência dos clientes por diferentes produtos). Isso é possível em quase todos os sistemas
automatizados que substituem um sistema ma nual; e normalmente existe a oportunidade para
qualquer tipo de siste ma on-line ou de tempo-real de apresentar essas tendências de uma forma
mais oportuna do que seria possível com um sistema na modali dade batch. De modo análogo, um
sistema com aptidões gráficas pode fornecer informações de uma forma mais eficiente do que um
sistema atual que produz informações em formato tabular ou em relatórios numéricos. E um
sistema elaborado com uma linguagem de programa ção de quarta geração e um moderno sistema
de gerenciamento de banco de dados pode possibilitar a leitura de todo o banco de dados com essa
finalidade.
Uma forma relativamente nova de beneficio tornada possível pelos sistemas especialistas
comerciais é o encapsulamento de conhecimentos que anteriormente eram exclusivos de uma ou
duas pessoas. Esse conhe cimento é normalmente voltado para apreciações, diagnósticos ou ava
liações, e o perito humano que possua essas aptidões é habitualmente considerado um valioso bem
para a empresa; dessa maneira, a capacida de do novo sistema em simular essas aptidões é um
beneficio cujo valor deve poder ser calculado.
À proporção que as técnicas de inteligência artificial continuarem a crescer, poderemos identificar
como beneficio a capacidade do sistema em dfsseminar o conhecimento originalmente pertencente
a somente um ou dois peritos humanos da empresa. Assim, um perito humano da empresa pode ter
algumas normas de julgamento que ele utiliza para diagnosticar as prováveis causas das falhas de
algum sistema mecânico (uma plataforma de extração de petróleo, por exemplo). Evidentemente,
seria estrategicamente benéfico obter o conhecimento daquele perito hu mano e simulá-lo para
utilização por outras pessoas; mas a capacidade de estender essa perícia e aumentar a aptidão de
diagnosticar para lidar com falhas do sistema pode ser de uma ordem de grandeza mais valiosa.
C.4 COMO EXPRESSAR OS CUSTOS E BENEFÍCIOS DO SISTEMA
Se todas as despesas e todos os benefícios do sistema ocorressem de forma instantânea, seria
relativamente simples representar o valor do sistema como sendo a diferença entre os benefícios e
os custos. Porém, como já dissemos, os custos habitualmente ocorrem por um período de

Página 429 de 584
637
anos; e ainda que uma despesa realmente aconteça em um determinad momento (a compra de um
equipamento, por exemplo), as normas d contabilização da empresa podem desdobrá-la em um
período de vário anos.
Assim sendo, você talvez tenha de demonstrar os custos e os bene ficios do novo sistema proposto
ao longo de um determinado período d tempo. Existem quatro métodos conhecidos para iSSO:
• Fluxo de caixa
• Retornos de investimentos (RDI)
• Taxa interna de retorno (TIR)
• Valor atual líquido (VAL)
Examinaremos cada um deles a seguir.
C.4.1 Flu
Quer o seu sistema apresente ou não um eventual lucro (bene fícios que excedam os custos), a
direção poderá querer saber quant precisará ser investido para que se possa esperar um fluxo de
caix; positivo; evidentemente, eles estarão mais interessados nisso em relaçã aos grandes projetos
do que em relação aos pequenos. Observe que fluxo de caixa do projeto pode ser inteiramente
diferente da informaçã oficialmente divulgada como lucros e perdas da empresa. Por exemplo a
equipe do projeto pode ser responsável por uma despesa de $100.00( em salários durante um
esforço de um ano em desenvolvimento d sistemas; mas as leis dos impostos podem permitir que
esse custo sej; depreciado (ou amortizado) por um período de, digamos, 5 anos. Assim a
organização pode relatar custos dc apenas $20.000 em seus pagamen tos de impostos do ano, mas
os $100.000 em dinheiro já se foram. D forma semelhante, os benefícios do novo sistema podem
parecer to talmente diferentes do ponto de vista de fluxo dc caixa em relação a ponto de vista dos
lucros e perdas informados ao Internal Revenw Service.
Na maioria dos casos, é conveniente apresentar tantu o fluxo d
caixa anual çomo o agregado. Sua análise de custo/benefício pode pro
duzir, para a direção, uma tabela como esta:
638
Projeções Projeto X Fluxo dc Caixa
Ano 1
Ano 2
Ano 3
Ano 4
TOTAL
Economias de
Caixa
O

Página 430 de 584
10.000
50.000
100.000
160.000
Despesas de
Caixa
50.000
30.000
20.000
10.000
110.000
Caixa Líquida
-50.000
-20.000
30.000
90.000
50.000
Caixa Agregada
-50.000
-70.000
-40.000
50.000
50.000
C.4.2 Retornos de Investimentos
Outra maneira de avaliar os custos e benefícios do sistema é calcu lar o retorno de investimento.
Suponha, por exemplo, que você tenha investido $110.000 em ações ou em imóveis e que possa
revendê-los por $160.000 (observe que são os mesmos valores usados no exemplo do fluxo de
caixa). Isso significaria que você lucrou $50.000 em um investi mento de $110.000; em termos
perccntuais, isso representaria um retor no de investimento de 45%.
Isso soa melhor do que investir cm poupança! Mas, espere; no exemplo acima, o lucro não ocorreu
ao final do primeiro ano; na verda de, levou 4 anos. Assim, isso faz com que o retorno do
investimento esteja em torno de 11% ao ano. Mesmo isso pode conduzir a conclusões erradas,
porque não foi considerado o valor atual do dinbeiro futuro. Isso é discutido a seguir.
C.4.3 Valor Atual Líquido
Se alguém lhe desse $100 hoje, você saberia o valor desse dinheiro:

Página 431 de 584
você teria uma boa noção de quanto você poderia comprar com essa importância. Mas quanto
valem $100 se você souber que só os terá daqui a um ano? Isso é conhecido como o valor atual ou
o valor descontado. O valor atual da quantia que você receberá no futuro é definido como a
importância que você teria de investir hoje, à taxa de juros vigentes, para atingrr o montante
especificado. Desse modo, o valor atual de $100 do próximo ano é aproximadamente $95,24 à taxa
de juros de 5%.
Geralmente, quando queremos calcular o valor atual de alguma
quantia (que chamaremos de F), daqui a n anos, usamos a seguinte
fórmula:
P=F/(1 +iY
639
onde i é a taxa de juros. Assim, no exemplo acima, o valor atual do benefícios pode ser calculado
da seguinte forma (admitindo-se a taxa d juros de 5%):
Cálculos Projeto X Valor Atual
Ano 1
Ano 2
Ano 3
Ano 4
TOTA
Economias de
Caixa
O
10.000
50.000
100.000
160.00
Valor Atual
O
9.070
43.192
82.270
134.53
Como pode-se ver, isso torna os retornos financeiros do projet bem menos impressivos, mas é
muito mais realista. Para ser ainda mai realista, precisamos entender que os custos futuros precisam
sofrer des contos análogos aos dos benefícios futuros. Assim como um benefício d $10.000 no final
do segundo ano vale hoje apenas $9.070, um custo d

Página 432 de 584
$10.000 que ocorrerá no final do segundo ano representa um custo atua de apenas $9.070.
Isso leva à definição do valor atual líquido de um projeto: a dife
rcnça entre o valor atual dos benefícios e o valor atual dos custos. Para
nossa amostra de projeto, isso conduziria aos seguintes cálculos:
Cálculos Projeto X Valor Atual Líquido
Anol
Ano2
Ano3
Ano4
TOTAl
Economias de Caixa
O
10.000
50.000
100.000
160.00(
Valor Atual dos Benefícios
O
9.070
43.192
82.270
134.53
Despesas de Caixa
50.000
30000
20.000
10.000
110.00(
Valor Atual dos Custos
47.619
27.211
17.277
8.227
1O0.33

Página 433 de 584
Valor Atual Líquido
Acumulado
-47.619
-65.760
-39.845
34.198
34.19k
Assim, o valor atual líquido do sistema - o valor de hoje do bene fício que esperamos obter do
sistema ao final de 4 anos - é $34.198.
640
C.4.4 Taxa Interna de Retorno
A taxa interna de retorno é análoga à taxa percentual que os ban cos, os fundos de investimento e
outras instituições financeiras anunciam relativamente a suas contas de poupança e outras
modalidades de in vestimento. A taxa interna de retorno (TIR) é definida como a taxa de juros que
seria necessária para gerar as economias de caixa a cada ano (isto é, os benefícios do sistema, que
já identificamos) dado um investi mento igual às despesas de caixa que identificamos. No exemplo
acima, imagine que tivéssemos investido um total de $110.000 em uma conta de poupança
hipotética por um período de 4 anos. A questão é: qual a taxa de juros que deveria ser usada para
que pudéssemos ter direito a uma retirada de $160.000 no final do quarto ano, sem que fosse
deixado dinheiro no “banco” no final? Comparando isso com a «prime rate” e com várias outras
taxas de investimento, a direção pode verificar se o novo sistema é realmente um bom
investimento.
Suponha que descrevamos os futuros benefícios a serem obtidos ao final dos anos 1, 2, ... N como
BI, B2, ... Bn; suponha ainda que os custos futuros sejam descritos como C C2, ... Cn. Então, a
seguinte fórmula polinomial deve ser resolvida para encontrar-se a taxa de juros i:
C1/(1 +i)+C2/(1 +i) . . +Cnj(1 +j)N=B1/(1 +i)+B2/(1 +i) ..+BnI(1 ÷i)N
Essa não é uma fórmula que possa ser facilmente resolvida nas costas de um guardanapo ou
mesmo com uma simples calculadora de quatro funções. Contudo, pode-se obter calculadoras com
funções de TIR (IRR) embutidas; além disso, existem programas de emprego espe cial para
utilização em PC e em computadores de grande porte para es se tipo de análise financeira. Se você
não dispuser prontamente dessas ferramentas, solicite auxílio do setor de finanças ou de
contabilidade.
C.5 ANÁUSE DE RISCOS
Como parte dos cálculos de custo/benefício, você deve estar pre parado para executar uma análise
de riscos para o novo sistema; você deve prepará-la mesmo que a direção não a solicite. O motivo
para isso é quê não podemos predizer, com absoluta certeza, que obteremos os benefícios
estimados ou que ocorrerão os custos previstos. As coisas podem revelar-se melhores do que a
estimativa; o que causa maior preo cupação é o fato de elas poderem ser muito piores.
A direção normalmente desejará saber quais serão as conseqüên cias se as coisas não correrem bem

Página 434 de 584
durante o projeto; e desejarão saber
o que poderá não ir bem. Especificamente, desejarão saber as condições
641
sob as quais os custos estimados poderão ser significativamente maiore e sob quais condições os
beneffcios poderão ser significativamente infe riores ao esperado.
Como podem os custos ser superiores à sua estimativa? Aqui estãi
algumas possibilidades; cabe a você identificar os riscos específicos di
seu próprio projeto:
• O fornecedor do hardware pode entrar em falência.
• A equipe do projeto pode sofrer muitas substituições, doenças outros problemas.
• A tecnologia utilizada no projeto pode não funcionar conform foi anunciada, principalmente se
ela for uma nova tecnoIogi
que nunca foi usada antes.
• A oportunidade pode ser perdida; por exemplo, o sistema podi não estar pronto para ser instalado
até 2 de janeiro, e as norma governamentais podem impedir que o sistema seja realmenu instalado
até o 1 de janeiro seguinte.
• Problemas doutrinários ou contratuais podem surgir de uniões contratantes externos e outros.
• A equipe do projeto pode não ter o necessário conhecimento d aplicação ou pode ter outras
deficiências (treinamento inade quado e pouca experiência) que conduzam a uma produ tividade
inferior às expectativas.
• Negócios confusos ou circunstâncias econômicas podem forçai o cancelamento do projeto.
• Diversos custos ocultos podem originar-se, por exemplo, d uma sobrecarga adicional de papéis
que não eram necessário
no sistema anterior.
Os beneficios estimados, de forma análoga, podem não se materia lizar. Eis alguns possíveis
motivos:
• Os usuários operativos podem achar mais dificil do que espera vam a utilização do novo sistema,
levando a demoras e soluções de continuidade (isso é especialmente importante se os bene ficios
do sistema foram atribuídos a maior produtividade do usuários).
642
• Melhoras esperadas na participação no mercado podem não ocorrer. O sistema pode não originar
mais clientes, mais pedi dos, mais negócios ou maiores receitas.
• O sistema pode não apresentar o comportamento previsto; por exemplo, ele pode não processar
tantas transações por segundo
como era de se esperar.
• O valor das novas informações tornadas disponíveis pelo sis tema pode não ter nenhum beneficio
concreto.

Página 435 de 584
Para lidar com esses riscos, é muitas vezes uma boa solução com parar um pior caso, um melhor
caso e um caso esperado. Quanto mais precisa e realista for a maneira pela qual isto for feito,
melhor; não adianta enganar você mesmo e a direção com pressuposições desneces sariamente
otimistas sobre custos e beneficios. De forma semelhante, embora ninguém espere que ocorra a
situação do pior caso, é importan te para a direção saber quão mal as coisas podem ir.
Uma nota final sobre análise de riscos: a direção muitas vezes esta rá a par de mais riscos do que
você (ex.: uma potencial fusão entre sua companhia e uma outra empresa que tornará inútil o
sistema). Eles podem avaliar esses riscos, e muitas vezes nada lhe dirão sobre eles; eles precisam
que você avalie os riscos técnicos do projeto.
NOTAS
1 Isso é especialmente válido para algumas indústrias altamente competitivas, onde novos sistemas
de processamento de dados são desenvolvidos para oferecer novos tipos de serviços ao mercado
(ex.: novos sistemas bancários, de cartões de crédito e de «pas sageiro assíduo” de linhas aéreas.
Desse modo, seu usuário talvez não possa justificar, quanto ao custo, esse novo sistema por seus
próprios méritos, mas pode saber que ele ou ela deve desenvolver
o sistema para manter-se competitivo.
2 Como analista de sistemas sênior, você deve saber disso perfei tamente. Mas, para um analista de
sistemas júnior, trazido para o projeto depois deste já estar em andamento a seis meses, isso pode
não ser tão evidente. A essa altura, o projeto já tem vida própria e lutará por sua existência
independentemente do usuário e de qualquer processo racional de tomada de decisão.
3 Isso às vezes pode ser reduzido se a sua empresa dispuser de
extensivos recursos eletrônicos de comunicações ou de outras for mas de sistemas de comunicação
além do telefone.
643
Existe um custo oculto que você não deve esquecer: durante conversão do banco de dados antigo
para o novo, é inevitável descoberta de erros. Isso é especialmente válido, como se pod imaginar,
se o banco de dados existente for manual e as entrada tiverem sido feitas manualmente; você
encontrará dados ausente incompletos, e dados evidentemente incorretos. Quanto mais ant gos
forem esses dados, mais erros provavelmente serão encontn dos. Além disso, o próprio processo de
conversão pode ser sujeit a erros, principalmente se for um processo manual. Assim, prova
velmente haverá um custo relacionado à correção de dados. Seri possivelmente uma boa idéia obter
uma amostra aleatória do bar co de dados existente para conseguir uma estimativa do número d
erros que serão encontrados e, em seguida, estimar o custo d correção desses erros (na maioria dos
casos, as correções terão d
ser feitas manualmente).
5 Para cálculos detalhados dessas economias, leia Pro,çrammin,g Prc ducttvity, de Capers Jones
(Nova lorque: McGraw-Hill, 1985).
6 Isso naturalmente presume que alguém em sua empresa control esse tipo de coisas. Um
levantamento em cerca de 500 instalaçõe
americanas de processamento de dados, levado a efeito por Lient e Swanson em 1980, indica que

Página 436 de 584
aproximadamente 50% das eni presas não controlavam as falhas de operação de seus sistema leia
Software Maintenance Management, de Lientz e Swansor Reading, Mass.: Addison-Wesley, 1980.
644
D
CAMINHAMENTOS
(WALKTHROUGHS)
E INSPEÇÕES
D.1 INTRODUÇÃO
Este apêndice apresenta uma rápida visão geral de uma técnica conhecida como caminhamento.
Você poderá considerá-la útil para conduzir verificações das especificações desenvolvidas durante
um projeto de análise de sistemas. Entretanto, para utilizar esse conceito, você precisará saber o
que é um caminhamento, para que serve, quais são os seus participantes e quais são seus
procedimentos.
Depois de ler este apêndice, você pode precisar de mais informa ções. Duas possíveis fontes de
consulta são Structured Walkthroughs, 3’ ed., de Edward Yourdon (Nova lorque: YOURDON
Press, 1985) e Technical Inspections and Reviews, de Daniel Freedman e Gerald Weinberg
(Boston: Little, Brown, 1977).
D.2 OQUE É UM CAMINIIAMENTO?
De acordo com a utilização do termo na indústria de desenvolvi mento de sistemas, é uma revisão
coletiva de qualquer produto técnico. Isso significa que a revisão envolve outros analistas de
sistemas que es tejam trabalhando com você, bem como usuários, programadores, projetistas de
sistemas, pessoal de operações e outros que possam estar envolvidos em diversos aspectos do
projeto em que você está trabalhan do. Mas um caminhamento, sob condições normais, não inclui
seu che fe, ou a chefia do departamento, ou o vice-presidente da organização usuária.
É claro que essas eminentes pessoas desejarão Ler uma oportuni dade de rever diversos aspectos do
projeto, incluindo as especificações em que você estiver trabalhando. Mas eles normalmente estão
menos envolvidos nos detalhes técnicos do que você pensa, e podem não ser
645
capazes de oferecer qualquer sugestão detalhada. E os interesses sã habitualmente um fator nessas
revisões de alta potência. Isso não qu dizer que tais revisões sejam ruins ou que sejam irrelevantes,
sigriific apenas que são diferentes dos caminhamentos tratados neste apêndia O perigo de admitir
membros da direção em uma revisão de exarn coletiva é que geralmente introduzem-se os
interesses políticos, e/ou caminhamento tornar-se-á uma avaliação do desempenho de uma pe soa,
ao invés de uma revisão técnica de um pmduto.
Observe que pode haver muitos tipos diferentes de caminhamer
tos em um projeto comum:
• Caminhamentos de análise
• Caminhamentos de projeto

Página 437 de 584
• Caminhamentos de código
• Caminhamentos de testes
Como o tema deste livro é a análise de sistemas, focalizaremos c caminhamentos de análise. Em
termos práticos, isso significa que ur grupo de analistas de sistemas, juntamente com outras partes
interess das, reúne-se para rever diagramas de fluxo de dados, diagramas d entidades-
relacionamentos, diagramas de transições de estado, itens d dicionário de dados e especificações de
processos, isto é, todos os pr dutos técnicos desenvolvidos pelo analista de sistema.
D.3 POR QUE FAZER CAMINTIAMENTOS?
O principal motivo de realizar-se um caminhamento é localiza erros tão rápida e economicamente
quanto possível. Como já menciona mos anteriormente, é normalmente muito mais barato
descobrir e elim nar erros tão cedo quanto possível, cm vez dc esperar até que um prodi. to esteja
pronto e remetido para a etapa seguinte de desenvolvimento.
Existem outros meios de descobrir erros além dos caminhamento a pessoa que elaborou o produto
(ex.: um DFD) pode revisá-lo e tenta descobrir seus próprios erros. Mas o senso comum e muitos
anos d experiência na área do processamento de dados indicam que esse é urr modo muitas vezes
antteconômtco de Ça7.eT as co P pessoas m vezessão incapazes de perceber seus próprios erros,
não importando profundidade com que examinem seus próprios trabalhos. Isso vale par alguém
que esteja lendo um documr rto em busca de erros tipográficc ou que esteja lendo um programa de
computador à procura de “bugs
646
ou examinando um DFD em busca de erros. Um grupo de perscrutado res entendidos e
interessados no assunto pode muitas vezes encontrar erros com rapidez muito maior.
Outro meio de encontrar erros é usar uma estação de trabalho de analista do tipo discutido no
apêndice A; isso é grosseiramente análogo a usar um compilador para encontrar erros sintáticos em
um programa, ao invés de examinar visualmente a listagem do programa. Se você dispuser de uma
estação de trabalho de analista, não deixe de usá-la para identi ficar todos os erros de sintaxe que
ela for capaz de descobrir. Porém, assim como um compilador não descobre todos os erros de um
progra ma (p.ex.: ele não localiza erros em tempo de execução nem erros lógi cos, porque ele
executa uma análise estática ao invés de uma análise dinâmica do programa), uma estação de
trabalho de analista não conse gue encontrar todos os erros de um conjunto de modelos de
especifica ções. O caminhamento ainda constitui-se em um útil complemento a quaisquer
ferramentas que estejam disponíveis.
Na verdade, uma das coisas que a estação de trabalho é incapaz de fazer é a análise do estilo dos
produtos, que é algo que as pessoas são altamente qualificadas para fazer. Dessa forma, ao
examinarem um DFD, os revisores humanos podem fazer perguntas como:
• Existem bolhas em demasia no diagrama?
• Os nomes dos processos são significativos?
• Os diagramas foram desenhados de forma esteticamente agradá vel? É provável que o usuário
examinará realmente o diagrama
ou ficará confuso?

Página 438 de 584
• Os fluxos de dados foram agrupados de modo significativo entre um nível e outro?
• As atividades elementares foram agrupadas de um modo inteli gente para compor bolhas de nível
mais elevado?
Além disso, existem outros benefícios que as organizações costumam descobrir na técnica do
caminhamento: treinamento e segur Um processo de revisão coletivo é um excelente veículo para
ensinar os membros novos da equipe do projeto (e também aos membros antigos e desgastados da
equipe!) os detalhes relativos à aplicação, à análise de sistemas ou os detalhes da notação de
diagramas de fluxo de dados. E como todos os componentes do grupo de revisão tornam-se um
tanto familiarizados com o produto (e muitas vezes intimamente familiarizados com ele), o
caminhamento converte-se em
647
uma questão de segurança contra o inesperado, o extemporâneo afa tamento do produtor da equipe
do projeto; alguém deve ser capaz encarregar-se do trabalho feito pelo produtor e dar-lhe
continuidade.
O grande perigo de tudo isso é que o produtor pode não concc dar com os benefïcios e considerar
todo o processo de caminhameni como uma invasão de sua privacidade. Se o produtor considerar
os DF como sendo de sua propriedade (em vez de um bem comum), então e e ressentir-se de ter de
mostrá-los a outrem. Se sua idéia de estilo d ferir muito da dos examinadores, poderão ocorrer
violentas discussõ no caminhamento. E se o produtor for contrário à idéia de treinamento
segurança, ele pode muito bem rejeitar a idéia de um caminhamento.
Em geral, os caminhamentos são realizados em locais em que idéia de equipe já está aceita e
consagrada; em um projeto típico, sign fica que cada componente deve compreender que uma falha
ou err sério em seu trabalho pode comprometer o sucesso de todo o projeto, que quer dizer que a
possibilidade de erros em seu trabalho é urr legítima preocupação dos demais componentes da
equipe. Para maiorc detalhes sobre o conceito de equipes, especialmente as assim chamad «equipes
não-egocêntricas”, leia a clássica obra de Gerald Weinberg fl Psycbology of Computer
Programming (Nova Jorque: Van Nostran Renhold, 1971).
D.4 QUANDO O CAMINHAMENTO DEVE SER REALIZADO
Um caminhamento deve ocorrer em virtualmente qualquer pont do desenvolvimento de um
produto técnico - do momento em que el representa um brilho nõs olhos do produtor, ao ponto em
que o prc dutor esteja absolutamente convencido de que o produto está terminad e pronto para ser
entregue ao cliente (ou ao estágio seguinte do prc cesso de desenvolvimento). Geralmente é
preferível fazer um cami nhamento tão cedo quanto possível, mas não tão prematuramente que
produto ainda esteja incompleto e cheio de erros triviais que o autor pc deria ter eliminado.
Vamos utilizar o exemplo de um diagrama de fluxo de dados par ilustrar esse detalhe. O produtor
normalmente fará diversas iterações d (1) discutir a parte importante do sistema com o usuário; (2)
visualiza mentalmente um DFD; (3) esboçar diversas versões incompletas do DF em guardanapos
de papel e no verso de envelopes; (4) esboçar um:
versão relativamente limpa do DFD em uma folha de papel em branco (5) introduzir os detalhes do
DFD em uma estação automatizada d analista do tipo discutido no apêndice A; (6) conduzir
quaisquer opera ções de verificação de erros que estejam disponíveis no produto d

Página 439 de 584
648
estação para eliminar erros de sintaxe; (7) imprimir uma versão final do DFD em um plotadora ou
em uma impressora laser e (8) entregar o DFD ao chefe com o triunfante anúncio de que a tarefa
terminou antes do prazo.
Neste caso, é cedo demais para realizar-se um significativo cami nhamento nos estágios (1), (2) ou
(3); o caminhamento poderá ser rea lizado eficazmente nos estágios (4), (5) ou (6). Os estágios (7)
e (8) são muito tardios. O momento exato de se realizar o caminhamento depende do suporte
automatizado disponível, de quão rapidamente ele pode tor nar-se disponível (isto é, o analista terá
de esperar quatro dias para ter acesso à estação de trabalho, que é compartilhada por 27 outros
analis tas?), e quanto custa a utilização do suporte automatizado.
O principal motivo de evitar-se um caminhamento em um estágio tardio é que o produtor terá
investido tanto do seu ego no produto que normalmente relutará em efetuar qualquer modificação,
além das corre ções dos erros maiores (e as vezes nem mesmo esses!). Assim, o pro dutor pode ter
desperdiçado dcsnecessariamcnte um bom tempo eli minando erros de seu produto, quando a
equipe de revisão poderia fazê lo muito mais rápida e economicamente se tivesse examinado o
produto em um momento anterior.
E, para terminar, devemos lembrar a psicologia dos próprios revi sores: eles despendem seu próprio
tempo participando da localização dos erros de outrem, e ressentir-se-ão disso, não importa o
quanto sua equipe possa ser não-egocêntrica como eles propalam. Considerando esse sentimento,
não deve ser mostrado aos revisores um produto mal feito e incompleto; mas também não lhes
deve ser apresentado um pro duto terminado imutável e perfeito.
Se você vai gastar uma hora do seu tempo revisando o DFD do seu colega, é agradável saber que
você fez algo de útil ao encontrar um erro que o próprio produtor não viu. Se, por outro lado, você
gastar uma hora examinando um produto sem encontrar nada para criticar, existe uma natural
tendência humana para encarar esse esforço como algo semelhante a um desperdício de tempo e
para que você esteja menos disponível na próxima vez que for chamado para participar de um
caminhamento.
D.5 PERSONAGENS DE UM CAMINHAMENTO
Muitas organizações realizam caminhamentos sem nenhum trei namento ou formalismo do que o
que foi acima descrito porém muitas descobriram ser vantajoso introduzir algum formalismo ou
estrutura na revisão; daí a conhecida expressão caminhamento estruturado. Uma ca racterística
comum de um caminhamento estruturado é um conjunto de
649
personagens formais desempenhados pelos revisores. Diferentes revisc res podem desempenhar
diferentes papéis entre um e outro caminh2 mento; e em alguns casos um revisor pode
desempenhar mais de ur papel.
Eis os personagens que costumam ser encontrados em um cam
nhamento:
Apresentador, a pessoa que explica ao grupo revisor o que produto faz, que pressuposições foram
feitas quando ele f criado, e assim por diante. Em muitos casos, o apresentador é produtor, mas

Página 440 de 584
nem sempre. Algumas empresas acham que se produtor apresentar seu próprio produto, (1) o
produto pod ser tão enigmático que nunca seria aceito se o produtor nã estivesse imediatamente
disponível para explicá-lo e (2) o prc dutor pode sutilmente (e talvez inocentemente) fazer uma 12
vagem cerebral na audiência revisora e levá-la a cometer o mesmos erros, descuidos e erros de
omissão e cometimento qu cometeu.
• Presidente, a pessoa que organiza e controla a reunião. Seu o1 jetivo é manter a discussão
desenrolando-se de uma forma orde nada e construtiva para impedir discussões paralelas, bem com
críticas ao apresentador. Por motivos óbvios existe a tendênci de deixar o gerente de projeto servir
como presidente; mas pela razões descritas anteriormente neste apêndice, a presença d um gerente
na revisão coletiva muitas vezes modifica o caráte da revisão de um modo muito negativo.
• Escrivão, a pessoa que faz o registro escrito dos eventos impor tantes da revisão. Além de coisas
triviais como a data em qu ocorreu o caminhamento, que produto esteve sendo exami nado, e quem
compareceu ao caminhamento, o escrivão fa:
anotações sobre as questões técnicas significativas que foran levantadas, erros que tenham sido
encontrados e sugestões pan aperfeiçoamento ou modificações feitas pelos revisores.
• Porta-voz da manutenção, um revisor cuja principal orientaçã é a manutenção do produto a longo
prazo. Ele normalment estará interessado em que o produto não seja muito idiossin crásico ou não
seja insuficientemente documentado. Ele tende; desempenhar um papel mais importante nos
caminhamento relativos a projetos e códigos do que nos caminhamentos di análise.
650
• Mantenedor dos padrões, o papel dessa pessoa é evidente: asse gurar que o produto seja
consistente com os padrões gerais que tenham sido adotados pelo projeto e/ou pela organização. Às
vezes, o principal papel dessa pessoa é orientar o produtor e outros membros da equipe sobre se o
produto deverá em última análise ser considerado aceitável (em termos de obediência aos padrões)
por um grupo formal de controle de qualidade.
Existem duas últimas observações a serem feitas sobre esses per sonagens: primeiro, lembre-se que
os papéis podem mudar entre um e outro caminhamerito. Segundo, lembre-se de induir o usuário
como um desses personagens caso o usuário seja um ativo participante do projeto.
D.6 PROCEDIMENTOS DE CAMINHAMENTOS
Como indicamos na seção precedente, os caminhamentos bem- sucedidos normalmente
caracterizam-se por um conjunto de persona gens e procedimentos formais. Os procedimentos
variam de empresa para empresa, mas a seguinte lista é típica:
1. Programe o caminhamento com um ou dois dias de adianta mento e distribua adequado material
informativo aos revisores. Se o caminhamento for marcado sem um aviso suficientemente
antecipado, os revisores não terão oportunidade de estudar o produto antes que o caminhamento
seja iniciado.
2. Assegure-se de que os revisores tenham despendido algum tempo na revisão do produto. Um
modo fácil de fazer isso é solicitar que cada revisor traga para o caminhamento pelo menos um
comentário positivo e um negativo sobre o produto. O risco que existe é que alguns dos revisores
estejam tão ocupados ou tão desinteressados no produto que não façam qualquer tarefa antecipada
e apenas mantenham-se sentados silenciosamente durante o caminhamento sem prestar nenhuma

Página 441 de 584
contribuição.
3. Solicite ao apresentador que faça uma ligeira apresentação do produto. Isso muitas vezes é feito
com utilização de diagramas em páginas sucessivas, projetores dc transparências, e coisas desse
tipo. É aí que o grupo literalmente caminha através do produto.
651
4. Solicite comentários aos revisores. Isso normalmente é orqu trado pelo presidente, que pode
resolver andar pela sala, licitando a cada revisor que mostre um erro ou faça ui apreciação sobre o
produto.
5. Assegure que os problemas sejam apresentados, porém não. lucionados no caminhamento. Isso é
especialmente importar no caso de ser apontado um erro não trivial; deixe o produi discorrer sobre
como resolvê-lo em sua vez de pronunciar- em vez de permitir a ocorrência de um “brainstorm” c
sestruturado. Isso é também um importante procedimer quando surgem problemas de estilo: o
produtor pode discorc dos comentários, e é preferível que ele os considere após a re nião (ou fale
separadamente com a pessoa que fez a sugest sobre o estilo).
6. Faça o caminhamento relativamente curto - não superior uma hora. Não se pode esperar que
alguém mantenha um ai nível de concentração por mais do que uma hora; a atenção c meça a
divagar, e existe um sério risco de que o caminhamen degenere em uma conversa informal.
7. Estabeleça uma resolução de acordo com o resultado da reuni; de caminhamento. As
recomendações que costumam ser feit pelos revisores são (1) “Consideramos que o produto deva
pe manecer como está”, ou (2) “Pensamos que alguns erros deva ser corrigidos e alguns problemas
menores de estilo devem tratados, mas confiamos em que o produtor fará as modificaçõ necessárias
sem mais revisões” e (3) “Encontramos tantos em e/ou problemas de estilo que gostaríamos que
fosse feito u outro caminhamento quando o produtor tiver feito todas modificações apropriadas”.
Dependendo da natureza da equiç e do modo como as pessoas assumem a responsabilidade p suas
tarefas na empresa, essa recomendação pode ser tornac obrigatória, ou pode representar
simplesmente uma sugestã opcional feita pelos revisores.
D.7 RESUMO
Embora a técnica do caminhamcnto seja um processo simples direto de revisão, não é tão
amplamente utilizada como se possa pensai Um motivo disso é o aparente aumento do tempo
necessário para cor duzir-se os caminhamentos: eles podem tomar dc 5 a 1 do tempo tot;
652
do projeto. Por outro lado, a maioria das organizações que utilizaram o caminhamento relataram
substanciais reduções no número de erros que permaneceram ocultos.
O motivo mais importante para a não utilização do caminhamento talvez seja o fato de que alguns
programadores e analistas de sistemas continuam a considerar seus programas e diagramas de fluxo
de dados como de sua propriedade particular, ao invés de um bem comum. Desse modo, eles
preferem não mostrar seu trabalho para Outros e resistem fortemente às críticas e sugestões de
melhorias. Esse é um perigoso mo do de ver as coisas; cada vez mais empresas estão começando a
perceber que devem introduzir alguma forma de revisão coletiva para terem su cesso no aumento
da qualidade dos sistemas que produzem.

Página 442 de 584
653
E
TÉCNICAS DE
ENTREVISTAS E DE
COLETA DE DADOS
E.1 INTRODUÇÃO
Este apêndice discute algumas diretrizes para as entrevistas que vo cê fará durante a fase de análise
de sistemas do projeto de desenvolvi mento de um sistema. Você provavelmente entrevistará
usuários, geren tes, auditores, programadores que fazem a manutenção de sistemas já existentes e
várias outras pessoas.
Por que fazemos entrevistas durante a análise de sistemas? Os
motivos são estes:
• Precisamos coletar informações sobre o comportamento de um sistema atual ou sobre os
requisitos de um novo sistema de pes soas que têm essas informações armazenadas em algum lugar
em suas cabeças.
• Precisamos verificar nossa própria compreensão, como analistas de sistemas, do comportamento
de um sistema atual ou dos re quisitos de um novo sistema. Essa compreensão deve ter sido
adquirida através de entrevistas prévias em combinação com informações coletadas de modo
independente.
• Precisamos coletar informações sobre o(s) sistema(s) atual(is) para executarmos os estudos de
custo/benefkio (veja maiores
informações sobre essa área no apêndice C).
Este apêndice cobre os seguintes tópicos sobre o processo de
entrevistas:
• Tipos de entrevistas
655
• Problemas fundamentais das entrevistas
• Diretrizes gerais para a realização de entrevistas
E.2 TIPOS DE ENTREVISTAS
A forma mais comum de entrevista é uma reunião pessoal e dire entre você (talvez acompanhado
por um ou dois analistas auxiliares d mesmos projetos) e um ou mais interlocutores (entrevistados).
Norma mente tomam-se apontamentos com papel e lápis por um dos entrevist dores; menos
costumeiramente, a entrevista pode ser gravada ou um( secretário(a) tomará notas durante a
entrevista. Neste apêndice, vam presumir que sua entrevista será desse tipo geral, mas não farei
qualqu pressuposição sobre gravadores ou estenógrafas.
Você deve perceber que as informações obtidas em uma entrevisi também podem ser obtidas por
outros meios, por exemplo, solicitand se que os entrevistados respondam por escrito a um
questionário forma ou solicitando que descrevam por escrito os requisitos do novo sistem Também

Página 443 de 584
podemos aumentar as entrevistas pela presença de vários e pecialistas (que podem até conduzir a
entrevista enquanto o analista d sistemas participa como assistente), como peritos em indústria,
psicók gos comportamentais e negociadores. E, finalizando, você deve lembn que outros meios de
obtenção de dados (ex.: videocassete) podem s utilizados para registrar uma entrevista.
Durante a década de 80, uma forma especializada de entrevisi tornou-se popular em algumas
empresas de SIG; ela é conhecida com JAD (de Joint Application Development) ou projeto
acelerado, ou análi em equipe, e por vários outros nomes. Ela consiste em uma rápida entn vista e
um processo acelerado de coleta de dados em que todos c principais usuários e o pessoal da análise
de sistemas agrupam-se ei uma única e intensiva reunião (que pode prolongar-se de um dia a uni
semana) para documentar os requisitos do usuário. A reunião costuni ser supervisionada por um
especialista treinado que atua como mediad para encorajar melhores comunicações entre os
analistas de sistemas os usuários.
Embora todas essas variações tenham de fato sido usadas, elas sã relativamente raras e não serão
discutidas em maiores detalhes nesi apêndice. A entrevista mais utilizada ainda é a reunião pessoal
entre ur analista de sistemas e um usuário final.
656
E.3 PROBLEMAS FUNDAMENTAIS
À primeira vista, pode parecer que o processo de entrevistar um usuário seja uma questão simples e
direta. Afinal de contas, você é uma pessoa inteligente e capaz de expressar-se; e o usuário também
o é. Os dois são pessoas racionais e ambos têm o mesmo objetivo: passar infor mações relativas a
um novo sistema proposto da mente do usuário para a sua. Qual é o problema’
Na realidade, existem muitos problemas que podem ocorrer. Em muitos projetos de alta tecnologia,
tem-se observado que a maioria dos problemas dificeis não envolvem hardware nem software, mas
sim o »peopleware”. Os problemas de peopleware na análise de sistemas são muitas vezes
encontrados nas entrevistas: é a entrevista onde “o pneu toca na estrada» entre o usuário e o
analista de sistemas. Os problemas mais comuns a que você deve estar atento São:
ErUrev a pessoa errada no momento errado. É muito fácil, por causa dos problemas e interesses
organizacioriais, falar com a pessoa que é o perito oficial na orientação do usuário, que demonstra
nada saber a respeito dos verdadeiros requisitos do sistema; também é possível perder a
oportunidade de falar com o usuário desconhecido que realmente sabe quais são os requi sitos.
Mesmo que encontre a pessoa certa, você talvez tente entrevistá-la durante um período em que o
usuário não está disponível ou esteja mergulhado sob outras pressões e emergências.
• Fazer peiguntas erradas e obter respostas erradas. A análise de sistemas é, como Tom DeMarco
gosta de dizer, uma forma de comunicação entre estranhos. Os usuários e os analistas de sis temas
têm vocabulários diferentes, experiências básicas diferen tes e muitas vezes um diferente conjunto
de pressuposições, percepções, valores e prioridades. Desse modo, é fácil fazer ao usuário uma
pergunta racional sobre os requisitos do sistema e o usuário não entender absolutamente a pergunta,
sem que
• nenhum dos dois perceba o fato. E é fácil para o usuário prestar lhe algumas informações sobre os
requisitos e você não enten der essas informações, novamente sem que nenhum dos dois perceba o
fato. As ferramentas de modelagem apresentadas an teriormente neste livro são uma tentativa de

Página 444 de 584
fornecer uma lin guagem comum e sem ambigüidades para diminuir esses mal entendidos. Porém
as entrevistas costumam ser realizadas em uma língua comum (inglês, espanhol, francês, português
etc.),
portanto o problema é real. Isso explica porque é tão importar marcar entrevistas subseqüentes para
confirmar que ambas partes entenderam as perguntas e as respostas.
Criar ressentimentos recíprocos. Como veremos na seção E. existem algumas razões pelas quais o
usuário pode não se sen à vontade ou mesmo colocar-se em posição antagônica na e trevista com
um analista de sistema (ex.: porque ele percebe qi o verdadeiro objetivo do novo sistema que o
analista está e pecificando é tomar-lhe o emprego). E o analista pode ressent se do modo como o
usuário está respondendo as perguntas (e pode perceber que o usuário a está insultando sugerindo
qi ela é jovem demais e inexperiente para oferecer qualquer o nião sobre os requisitos do novo
sistema). Em qualquer caso, ressentimento pode surgir entre as duas partes, tornando comunicação
muito mais difícil.
Não existe um modo mágico de garantir que esses problemas ni ocorrerão; eles são a conseqüência
das interações pessoa-a-pessoa, cada uma dessas interações é única. Contudo, as sugestões dadas a
s guir podem ajudar a reduzir a probabilidade desses problemas; fora iss você dependerá de prática
para melhorar cada vez mais em cada ents vista subseqüente.
E.4 DIRETRIZES PARA A REALIZAÇÃO DE
ENTREVISTAS
As seguintes diretrizes podem ser de grande auxílio na direção c
entrevistas bem-sucedidas com seu usuário.
E.4. 1 Desenvolva um Plano Geral de Entrevistas
Antes de tudo, é extremamente importante que você descub quem deve ser entrevistado. Caso
contrário, você desperdiçará o temp de todos e criará um enorme tumulto, por falar com pessoas
erra± sobre coisas erradas.
Isso requer que você obtenha um organograma da empresa qu mostre as pessoas da organização
usuária, bem como a hierarquia entr elas. Se não existir um organograma formal, encontre alguém
que saib como a organização funciona e peça ajuda. Se o organograma existi certifique-se de que
esteja correto e atualizado; as empresas muitas veze
658
modificam-se com muito mais freqüência do que o ciclo editorial anual em que os diagramas são
produzidos!
O fato de conhecer o esquema organizacional não lhe diz necessa riamente com quem você deve
entender-se; às vezes, a pessoa que mais sabe a respeito de algum aspecto de um sistema é um
funcionário admi nistrativo ou burocrata que sequer aparece no organograma. Como vi mos no
capítulo 3, muitas vezes existem três níveis de usuários em uma organização grande e complexa - o
usuário verdadeiro, o usuário su pervisor operativo e o usuário supervisor executivo - e é muitas
vezes de grande importância falar com todos os três níveis.
Em muitos casos também é importante conversar com os usuários na seqüência adequada e na
combinação certa. Isto é, você pode estar entrevistando Marta, que diz: “Bem, eu, naturalmente,

Página 445 de 584
recebo todos os meus dados de entrada de Jorge; ele poderá falar-lhe sobre esses dados. E, em
seguida, faço o seguinte...”. Em um caso assim, muitas vezes é melhor falar primeiro com Jorge,
deixando para falar com Marta depois. Ou você pode estar entrevistando Paulo, que diz: “Bem, na
verdade, Susana e eu desempenhamos essa função juntos; ela faz uma parte e eu faço o resto...”.
Nesse caso, seria evidentemente mais produtivo entrevis tar Susana e Paulo simultaneamente. Por
vezes você poderá saber em que seqüência os usuários deverão ser entrevistados face a seu conheci
mento geral da organização e por vezes os próprios usuários lhe dirão uma vez que saibam que
serão entrevistados.
E.4.2 Cert de que Você Tem Autorização para Falar com os Usuários
Em algumas organizações ir formais não haverá restrições em sua escolha dos usuários com quem
você quer falar ou sobre como as entre vistas serão marcadas. Porém isso é incomum em empresas
grandes; é politicamente perigoso vagar pela organização usuária realizando entre vistas sem prévia
autorização.
Na maioria dos casos, a autorização virá ou do encarregado de um setor usuário (um departamento,
divisão ou grupo) ou do representante nomdado que estará adido ao projeto de desenvolvimento do
sistema. Em qualquer caso, os usuários têm legítimas razões em querer aprovar, antecipadamente,
quem você for entrevistar:
• Eles podem saber que alguns usuários não serão capazes de compreender ou exprimir bem os
requisitos do sistema.
• Eles podem desconfiar de que alguns dos usuários do ní operativo sejam “renegados” que
apresentarão requisitos fal
(ou requisitos que a direção não aprove).
• Eles podem recear que as entrevistas interfiram com as ai buições normais de trabalho que os
usuários tenham de e, cutar. Por causa disso, desejarão marcar as entrevistas para momentos
apropriados.
• Eles podem recear que as entrevistas sejam vistas como o iziíc de um esforço de substituição dos
usuários humanos port. sistema computadorizado, provocando demissões e coisas des gênero.
• Eles podem considerar que eles próprios (os diretores) sabc mais a respeito dos requisitos do
sistema do que qualquer out e por isso não desejam que você entreviste qualquer usuário nível
operativo.
• Pode estar havendo uma batalha política em andamento em ti nível de chefia muito mais elevado,
entre o setor usuário e organização de desenvolvimento de sistemas. Desse modo, gerente usuário
pode não ter reais objeções a suas entrevista porém, impedindo que elas sejam feitas, ele estará
envian uma mensagem política para o chefe do chefe do seu chefe.
Por todos esses motivos, é uma boa medida obter uma prévia aul rização. Na maior parte dos casos,
basta uma autorização verbal; se organização for terrivelmente burocrática ou paranóica, você pode
pre sar de uma autorização escrita. Isso, a propósito, também significa qi você deve estar cônscio e
atento à política organizacional se tiver certe da necessidade de falar com um usuário
(normalmente um usuário nível operativo) com quem você tenha sido avisado para não convers
Você talvez pense em combinar algumas reuniões clandestinas fora d instalações, mas geralmente é
mais seguro levar para cima a solicitaç através da cadeia de comando de seu setor de forma a que

Página 446 de 584
ela pos descer pela cadeia de comando da organização usuária 1•
E.4.3 Planeje a Entrevista para Fazer Uso Eficiente do
Tempo
O principal aspecto desta sugestão é que você deve compreend que está tomando o tempo do
usuário e que ele (ou o chefe dele) poi
660
achar até que você esteja desperdiçando o tempo dele. Assim sendo, é importante que você planeje
e prepare tão antecipadamente quanto possível para poder fazer uso eficiente da entrevista.
A primeira coisa a fazer é certificar-se de que o usuário conhece o assunto da entrevista. Em alguns
casos isso pode ser feito por telefone; em outros, pode ser adequado preparar uma lista das
perguntas que serão feitas, ou dos tópicos que serão abordados, ou dos DFD que você deseja
revisar, e remetê-la ao usuário com um dia ou dois de antecipa ção. Se você não puder fazer isso, é
um indício de que você de fato não está preparado para a entrevista. E se o usuário não tiver lido o
material remetido, é sinal de que (1) está muito ocupado, (2) está desinteressado, (3) opõe-se a toda
a idéia da entrevista ou (4) é incapaz de entender as perguntas apresentadas.
Um aspecto relacionado: colete, antes da entrevista, tantos dados pertinentes quanto possível. Se
houver formulários ou relatórios que sejam pertinentes à discussão, geralmente você poderá obtê-
los ante cipadamente. Se existirem outros documentos escritos do usuário des crevendo o novo ou
o antigo sistema consiga-os e estude-os antes da entrevista.
Se você tiver preparado suas perguntas antecipadamente, você deve ser capaz de realizar a
entrevista em uma hora ou menos. Isso é importante; não só o usuário é geralmente incapaz de
reservar mais do que uma hora de cada vez, mas também (como eu disse no apêndice D) as pessoas
normalmente não conseguem se concentrar intencionalmen te (principalmente se estiverem
examinando diagramas um tanto estra nhos) por mais do que cerca de uma hora. Isso naturalmente
significa que você deve organizar a entrevista para abranger um escopo relativa mente limitado,
focalizando normalmente uma pequena parte do siste ma. Isso também pode significar que você
tenha de marcar algumas entrevistas com o mesmo usuário para abranger inteiramente a área em
que ela ou ele está envolvido(a).
Finalizando, marque uma reunião subseqüente para rever o mate rial que você coletou.
Normalmente, você irá para sua mesa com todas as informações colhidas na entrevista, colocará
seu “chapéu de analista”, e executará bastante trabalho com os dados brutos. Pode haver DFD a
serem desenhados ou itens a serem criados no dicionário de dados; cálculos de custo/benefício
podem precisar ser feitos; as informações provenientes da entrevista podem precisar ser
correlacionados com dados de outras entrevistas, e assim por diante. Em qualquer caso, os dados
dessa entrevista serão manipulados, documentados, analisados e convertidos em uma forma que o
usuário pode nunca ter visto antes. Desse modo, você pode precisar marcar uma entrevista
posterior para verificar (1) que você não cometeu nenhum engano em seu entendi mento do que o
usuário lhe disse, (2) que o usuário não mudou de
661
opinião nesse ínterim 2 e (3) que o usuário entende a notação ou representação gráfica dessas
informações.

Página 447 de 584
E.4.4 Utilize Ferramentas Automatizadas que Sejam
Adequadas, Mas Não Abuse
Durante a entrevista, você pode achar conveniente utilizar ferr
mentas de prototipação, principalmente se o objetivo da entrevista f
discutir a visão que o usuário tem da interface pessoa-máquina, E
modo semelhante, se você estiver revisando um diagrama de fluxo
dados e discutindo possíveis modificações, achará prático usar uma d
ferramentas CASE estudadas no apêndice A.
Lembre-se, portanto, que o objetivo dessas ferramentas é facl1lt as discussões e não complicá-las;
elas devem permitir que você e usuário examinem alternativas e modificações com rapidez e
facilidad elas podem ajudá-lo a registrar seu conhecimento de um requisito c usuário e corrigir
imediatamente quaisquer erros que você teni cometido.
Se, entretanto, a tecnologia introduzir-se no assunto, deixe-a foi da entrevista. Se o usuário tiver de
aventurar-se além de seu ambieni normal de atividade (para outro prédio, na sala do computador)
podei encarar a ferramenta como um aborrecimento. Se o usuário não esLiv familiarizado com a
tecnologia de computadores e for solicitado a utilizi a ferramenta, poderá rejeitá-la. E se você não
estiver familiarizado com ferramenta (ou se a ferramenta for lenta, tendente a erros ou de empre
limitado) isso interferirá sensivelmente na entrevista. Em qualquer de ses casos, talvez seja
preferível usar a ferramenta “off-line” depois da ei trevista; você, então, poderá mostrar ao usuário
a saída da ferrameni sem causar quaisquer problemas desnecessários.
E.4.5 Tente Descobrir em Que Informações o Usuário
Está Mais Interessado
Se você tiver de desenvolver um modelo completo de sistema pai alguma parte de um sistema,
você possivelmente necessitará deterjnin; entradas, saídas, funções, caracterí: tempo-dependentes e
a mem ria armazenada do sistema. Poréri a ordem em que você obtém essa informações costuma
não ter muita importância, ou, pelo menos, nã deve significar muito para você.
Mas pode significar muito para o usuário, e você deve deiixá-l
começar a entrevista por onde ele preferir. Alguns usuários desejarã
começar pelas saídas, isto é, pelos relatórios e valores de dados que ek
662
querem que o sistema produza (na realidade, eles talvez nem saibam que entradas serão necessárias
para produzir as saídas desejadas). Ou tros usuários poderão estar mais interessados nas entradas
ou nos deta lhes de uma transformação funcional. Outros ainda preferirão falar sobre os detalhes
dos dados de um depósito de dados. Como quer que seja, faça o que puder para enxergar os
requisitos do sistema da perspectiva desses usuários, e conserve essa perspectiva em mente quando
lhes fizer as perguntas necessárias à sua entrevista.
E.4.6 Use um Estilo Adequado de Entrevistar
Como diz William Davis [ 19831:

Página 448 de 584
Sua atitude em relação à entrevista é importante na determinação de seu sucesso ou fracasso. Uma
entrevista não é uma competição.
Evite ataques; evite o uso excessivo do jargão técnico; conduza uma entrevista, não uma tentativa
de persuasão. Fale com as pessoas, não fale muito alto, nem muito baixo, nem indiretamente. Uma
en trevista não é um julgamento. Faça perguntas detalhadas, mas não faça perguntas para confirmar
outras respostas. Lembre-se que o en trevistado é o perito e que é você que precisa de respostas.
Para concluir, de modo algum critique a credibilidade de outras pessoas. Não diga “Fulano disse-
me algo diferente” ou “Você não sabe o que está dizendo”.
Fazer perguntas detalhadas nem sempre é fácil; dependendo da personalidade do entrevistado e do
tema da entrevista, você pode preci sar de uma gama de estilos para extrair as informações
necessárias. Eis aqui alguns estilos que podem mostrar-se úteis:
• Relacionamentos. Peça ao usuário para explicar o relaciona mento entre o que está em discussão e
as demais partes do sis tema. Se o usuário estiver falando sobre um assunto (p.ex.: um cliente),
peça-lhe que explique seu relacionamento com outros aspectos; se ele estiver descrevendo uma
função (ex.: uma bolha de um DFD), peça-lhe que explique seu relacionamento com
• outras funções. Isso não só o auxiliará a descobrir mais detalhes sobre o item em pauta, mas
também o ajudará a descobrir interfaces (ex.: fluxos de dados de uma bolha para outra no DFD) e
relacionamentos formais.
• Pontos de vista alternativos: Solicite ao usuário que descreva o ponto de vista de outros usuários
em relação ao item que esteja
sendo discutido. Pergunte ao usuário, por exemplo, o que seu
663
chefe pensa sobre uma bolha do DFD, ou um tipo de objeto DER; ou pergunte o que pensa seu
subordinado.
Detalhamenta Solicite ao usuário uma informal descrição n rativa do item em que você estiver
interessado. ‘Fale-me sobn modo como você calcula o valor das remessas”. Ou, se esti falando com
o usuário sobre um tipo de objeto no DER, vc cria dizer: ‘Fale-me a respeito de um cliente. O que
vc sabe (ou precisa saber) sobre um cliente?”
• Dependências: Pergunte ao usuário se o item em discussão pende, para sua existência, de alguma
outra coisa. Isso é es cialmente útil quando se discutem possíveis tipos de objeto relacionamentos
no DER. Em um sistema de controle de pc dos, por exemplo, você pode perguntar ao usuário se se
possível haver um pedido (se isso for o item em discussão) sc que haja um cliente.
• Confirmaçãa Diga ao usuário o que você acha que ouviu dizer; use suas próprias palavras em
lugar das dele e peça cc firmação. Desse modo, você pode dizer: ‘Deixe-me ver se tendi o que você
disse: sempre que algo entra no sistema, vc sempre tem que o processar e enviar uma mensagem de
tuação para o setor de auditoria”.
E.5 POSSÍVEIS FORMAS DE RESISTÊNCIA NA ENTREVISTA
Como já dissemos, você deve estar preparado para o fato de q alguns usuários serão contrários à
própria idéia de uma entrevista; ess uma das razões para garantir que o chefe ou alguém com
autoridade setor esteja ciente e tenha permitido a entrevista. Algumas das objeç mais comuns (e

Página 449 de 584
algúmas possíveis respostas a essas objeções) são seguintes:
• Você está tomando tempo demais de mim. A resposta a issc explicar que você compreende, e
desculpar-se pelo tempo q você precisa tomar, mas que você já preparou tudo e fará entrevista no
tempo mais curto que for possível. Isso nai ralmente exige que você chegue pontualmente na hora
marca para o início da entrevista, mantenha a discussão no rumo p visto, e encerre-a no momento
em que você tenha dito que faria.
664
• Você está ameaçando meu emprego. Isso muitas vezes é uma reação muito emocional que pode
ou não ter fundamento. Em bora você possa pensar em diversas maneiras de responder a esse
comentário, lembre-se de que você não é o patrão dessa pessoa e de que você não está em posição
de garantir que o emprego dela não esteja em perigo, ou de informá-la do con trário. Você pode
tentar negar a responsabilidade dizendo: “Eu nada tenho a ver com isso; estou apenas
documentando os re quisitos do sistema sob a direção da gerência”, mas o usuário entrevistado não
aceitará isso. Ele vai considerá-lo como o “pe rito em eficiência” cuja tarefa é orientar a direção em
como o emprego dele pode ser eliminado pela computadorização. A solução para esse problema,
caso ele ocorra, é fazer com que seja levado ao conhecimento dos níveis superiores dos usuários e
obter o pronunciamento oficial deles, pessoalmente ou por escrito, se possível.
• Você não conhece nossa empresa, como você quer dizer-nos como deve ser o novo sistema? A
resposta a essa pergunta é:
“Você tem razão! É por isso que o estou entrevistando para saber o que você pensa sobre quais
devam ser os requisitos!”. Por outro lado, se você for um analista engenhoso, deverá su gerir várias
maneiras de “melhorar” as coisas (especialmente se parte ôu todo o serviço feito atualmente pelo
usuário for uma manifestação de uma antiga e ineficiente implementação de um sistema); assim,
esse tipo de comentário pode ser inevitável. Entretanto, o verdadeiro truque é continuar sendo tão
respeitoso quanto possível e reconhecer constantemente a experiência do usuário em sua própria
área, embora continuando a perguntar se ele teria a fineza de explicar-lhe (e portanto ajudando a
que você aprenda) porque sua idéia não funcionaria.
• Você está tentando mudar o modo como as coisas são feitas aqui. Uma variação do comentário
acima. O artificio neste caso
é mostrar ao usuário que embora você possa estar propondo al
• gumas (radicais) mudanças na implementação do sistema atual, você não pensa em modificar as
características essenciais desse sistema, exceto nas áreas onde eles mesmos tenham solicitado uma
alteração. Lembre-se, contudo, que algumas características da implementação do sistema atual
podem ter de ser preser vadas, por causa das interfaces do sistema atual com outros sis temas
externos que exijam que as entradas ou as saídas apresen tem formatos prescritos.
665
• Não queremos esse sistema. Esta é uma variação da queixa “vo está querendo tirar meu
emprego”. A verdadeira resposta é qi você está ali, conduzindo a entrevista, porque a direção usuái
quer o novo sistema. Não é da sua competência convencer usuários operativos que eles devem
querer o novo sistema (n importa o quão maravilhoso você considere que ele seja); faz isso é
colocar o peso da responsabilidade sobre seus ombr onde ele não deve ficar.

Página 450 de 584
• Por que você está desperdiçando nosso tempo com esta enti vista? “Sabemos o que queremos, e
se você fosse competem você saberia imediatamente o que queremos. Por que você ni vai em
frente e constrói o sistema?” Esta é uma reclamação difi de se lidar, porque relaciona-se com o fato
fundamental de qi os usuários e os analistas de sistemas estão falando linguas dif rentes e
estranhas; se o usuário não perceber esse fato, ele te grandes problemas. Uma solução possível é
fazer uma analogi pergunte ao usuário se ele permitiria que um arquiteto o meçasse a construir-lhe
uma casa sem detalhados entendime tos e plantas, seguidos por estreita comunicação durante toda
construção da casa. Pergunte ao usuário se ele gostaria de diz’ ao arquiteto: “Construa-me uma bela
casa de três quartos. Vo sabe como ela deve ser, não?” Lembre-se, contudo, que com disseminada
disponibilidade das linguagens de quarta geração dos computadores pessoais, o usuário pode achar
que po construir ele próprio o sistema; sucessos fáceis com projet simples (planilhas eletrônicas,
por exemplo) podem ter-lhe d do a impressão de que todos os sistemas são fáceis de impl mentar.
Isso pode explicar a impaciência dele em relação você.
E.6 OUTROS PROBLEMAS
As diretrizes acima alertaram-no sobre os inúmeros problemas p líticos com que você pode se
defrontar em uma entrevista e os muit motivos pelos quais o usuário pode mostrar-se hostil. Mas
ainda existei alguns problemas para os quais você deve estar atento:
• Uma discussão que focalize mais os problemas de impleme tação do que os problemas dos
requisilos. Isso muitas vezc ocorre quando o usuário diz: “Eis como eu gostaria que voc construísse
o sistema...”. Isso acontece quase sempre quando
666
usuário está raciocinando em termos da implementação do sistema atual; e pode acontecer se o
usuário conhecer alguma coisa da tecnologia de computadores (ex.: quando ele possui um PC
particular ou quando ele é um ex-programador). Lembre- se que não é sua obrigação em uma
entrevista de análise des crever características de implementação do sistema a não ser que sejam
tão importantes que realmente pertençam ao modelo de implementação do usuário que discutimos
no capítulo 21.
Confusão entre sintomas e problemas. Isso ocorre em muitas áreas, não apenas na área do
processamento de dados. Imagine um paciente que esteja conversando com um médico e diga:
«Doutor, meu problema é que meu rosto está quente. O sr. pode resolver esse problema para mim?”
É de se presumir que isso seja um sintoma, uma espécie de febre, indicadora de algum tipo de
problema médico, O importante é compreender que isso seja um sintoma e não o problema real, e
descobrir qual seja esse problema. O mesmo acontece vezes sem conta nas entre vistas de análise
de sistemas. Entretanto, boa parte dele depende de onde a fronteira foi estabelecida no diagrama de
contexto:
se a queixa do usuário é um sintoma ou um problema depende de ela estar associada a alguma
coisa dentro dos limites do sis tema ou fora deles. Desse modo, você deve dar especial atenção ao
desenvolvimento do modelo ambiental; isso é detalhadamente discutido no capítulo 18.
• O usu4río pode ser incapaz de explicar o que ele quer que o
sistema faça ou pode mudar de opinião. Esse é um problema
comum e o analista de sistemas deve estar preparado para ele.

Página 451 de 584
Quanto maior for esse problema mais importante torna-se a
prototipação. Para maiores detalhes sobre a prototipação veja o
capítulo 5.
• Desentendimento entre usuários de mesmo nível, subordinados e chefes. Infelizmente, isso coloca
o analista de sistemas no papel de mediador entre as partes em desentendimento. Como analista,
você não pode abdicar desse papel; você não pode dizer: «Quando vocês decidirem o que querem e
entrarem em um acordo, procurem-me.” Em vez disso, você deve agir como um negociador
conduzindo todos os interessados a uma sala e trabalhando com eles na tentativa de chegar a um
consenso. Isso, infelizmente, envolve habilidades e procedimentos fora do escopo deste livro.
667
E.7 FORMAS ALTERNATIVAS DE COLETA DE DADOS
As entrevistas não são o único modo de coletarmos informaçô sobre os requisitos de um sistema.
Na realidade, quanto mais inform:
ções você puder colher de outras fontes, mais produtivas poderão s suas entrevistas pessoais. Entre
as alternativas para as en&evistas.pod mos citar:
• Questionários: Você pode remeter questionários escritos para usuários dentro de sua organização,
para as pessoas (ou setore
que interagem com o sistema, para os diretores que aprovarai o projeto e para outros.
• Demonstrações feitas pelos fornecedores. Os fornecedores c hardware e os fornecedores de
software podem já haver desei
volvido sistemas prontos para a aplicação em que você este interessado. Solicitando-lhes uma
demonstração dos recuru desses sistemas pode não somente auxiliá-lo a decidir se o pn duto é uma
boa solução, mas também revelar funções e dadc
armazenados que você pode não ter percebido.
• Vrsitas a outras instalações. Procure outras empresas que est jam no mesmo ramo de atividades
ou que tenham sistem
semelhantes àquele em que você esteja trabalhando. Combin uma visita à instalação para obter
informações diretas sobre
características e aptidões do sistema.
• Coleta de dados. Procure formulários, relatórios, manuais, pr cedimentos escritos, registros,
imagens de tela de terminais e l
tagens de programas que já existam na organização usuári:
Lembre-se, todavia, que esses recursos normalmente estão rel cionados com a implementação atual
do sistema; como vimc no capítulo 18, isso costuma incluir informações redundant e/ou
contraditórias e/ou obsoletas. Não obstante, isso muití vezes é um bom ponto de partida para você
familiarizar-se coi
o terreno antes de iniciar as entrevistas pessoais com o usuári
• Pesquisa externa. Se você estiver construindo um sistema p ra uma nova aplicação, para a qual o

Página 452 de 584
usuário não dispõe d
qualquer experiência para descrever os requisitos, talvez sej necessário tentar obter informações em
sociedades profissionai (ACM, IEEE ou DPMA), ou em periódicos e livros técnicos e ei relatórios
de pesquisas.
668
E.8 RESUMO
A habilidade de comunicação, a diplomacia e outros aspectos hu manos relativos a entrevistas não
são facilmente transmitidos por um li vro. Trata-se de algo que você tem de aprender fazendo ou
observando:
como analista de sistemas de nível júnior, é uma boa medida acom panhar um veterano para
participar de algumas entrevistas que ele reali ze. Além disso, solicite realimentação: peça a seus
superiores que des cubram o que os usuários pensam do modo como você está conduzindo suas
entrevistas. E ofereça realimentação aos usuários: diga-lhes o que acontecerá com os resultados das
entrevistas, para que não pensem que tudo tenha sido uma perda de tempo.
REFERÊNCIAS
1. Abraham Maslow, Motivation and Personality. Nova lorque:
Harper & Row. 1954.
2. Charles J. Stewart e Cash Stewart, Jntetviewing Principies and Practices, 2’ cd. Dubuque, Iowa:
William C. Brown,1978.
3. William S. Davis, Systems Analysis and Design: A Structured Appmach. Reading, Mass.:
NOTAS
1 Tudo isso envolve política organizacional que está fora do escopo deste livro. Para maiores
informações, leia um dos livros sobre a teoria gdrencial e organizacional; ou consulte o delicioso
livro de Robert Block 7 Poiitics of Projects (Nova lorque: YOURDON Press, 1981).
2 Por que o usuário mudaria de opinião entre uma entrevista e a seguinte? Normalmente porque a
entrevista faz com que ele foca lize sua atenção em algo em que até ali ele só pensou de forma
vaga. Suas perguntas durante a entrevista podem fazer com que ele veja os requisitos de modo
diferente.
669
F
ESTUDO DE CASO:
A YOURDON PRESS
F.1 INTRODUÇÃO
Nenhuma discussão sobre análise de sistemas estaria completa sem pelo menos um exemplo
ilustrativo das diversas ferramentas de modelagem e técnicas discutidas neste livro. Infelizmente,
quase todos os estudos de casos são inteiramente fictícios ou versões extremamente simplificadas e
“saneadas” de situações reais. Além disso, é difícil en contrar um exemplo que ilustre uma

Página 453 de 584
aplicação tanto comercial como científica.
Este estudo de caso descreve os requisitos para a computadoriza ção das atividades de
processamento de informações da YOURDON Press. Por um lado, ela é bastante representativa de
uma atividade edito rial real que funcionou por aproximadamente 10 anos. Na verdade, uma das
coisas que desejo mostrar neste estudo de caso é que nem tudo é feito por motivos racionais
(inclusive a formação de empresas e o início de muitos projetos de desenvolvimento de sistemas!),
e que muitos siste mas têm de lidar com muitas “incursões” aborrecidas e desagradáveis no mundo
real.
Por outro lado, a YOURDON Press agora reuniu-se às fileiras dos exemplos fictícios, uma vez que
foi adquirida pela Prentice-Hall em 1986, e suas atividades de processamento de informações
subordinaram- se ás da Prentice-Hall Desse modo, este estudo de caso descreve como teriam sido
os requisitos de processamento de informações da YOURDON Press, caso ela tivesse continuado
como uma editora independente.
As seções a seguir apresentam um rápido retrospecto das opera ções da YOURDON Press, o
modelo ambiental do sistema, o modelo
comportamental e o modelo de implementação do usuário.
671
F.2 ANTECEDENTES
Para se entender os trabalhos da YOURDON Press, é necessá gastar algum tempo explicando o
Contexto maior da corporação den da qual ela existia: YOURDON inc. Sem a YOURDON inc.
não haveri YOURDON Press; embora sem a YOURDON Press, é Claro qu YOURDON inc. não
teria alcançado o mesmo sucesso.
A YOURDON inc. foi formada como uma extensão de ativida independentes de consultoria e
palestras que exerci por alguns anos fins da década de 60 ao início da de 70. A empresa foi formada
em ai de 1973 porque meu contador me informou de que uma corporaç oferecia certas vantagens
fiscais que não me seriam oferecidas coi consultor autônomo. Não obstante essa orientação prática
sobre imp tos, a nova corporação não efetuou de fato qualquer operação antes dia da mentira
(primeiro de abril) de 974.
Como acontece com a maioria das empresas (e com muitos p jetos de processamento!), uma das
primeiras atividades foi criar o noi da empresa. Minha mulher e eu, que éramos os únicos
acionistas, di tores, funcionários e empregados, gostamos do nome “Artichokes A Other Fur-
Bearing Animals, Inc.”, mas percebemos que não caberia nossa fachada. Por fim, escolhemos o
nome “Superprogrammers, Lii ted”, e demos entrada nos papéis no estado de Nova lorque para reí
trar o nome. Depois de duas semanas, quando já íamos publicar alg anúncios de nossa primeira
série de seminários sobre programação truturada, o órgão competente nos avisou que o nome de
nossa empn não tinha sido aprovado: ele era muito parecido com o nome de ou companhia. Ao
investigarmos, descobrimos que a outra companhia denominada “Supermarkets Products, Inc. Sem
nos desesperarm rapidamente escolhemos um nome que tínhamos uma razoável cert de que não
seria cópia de alguma outra: meu próprio nome. Eni nasceu a YOURDON inc.
As atividades iniciais da empresa foram seminários profission sobre técnicas avançadas de

Página 454 de 584
programação e projeto de sistemas on-li dirigidos a programadores e analistas veteranos de grandes
empresa agências do governo. Os seminários compunham-se de cerca de horas de palestras em
salas de aula e eram acompanhados por cerca uma centena de páginas de anotações de aulas; as
anotações de au relativas ao seminário sobre técnicas avançadas de programação tori ram-se um
livro: Techniques of ProRram Struclure and Design, pul cado pela Prentice-Hall em 1975.
Face ao grande número de participantes do seminário, tornou econômico imprimir as anotações de
aulas em um volume modera& encadernar as páginas; desse modo, elas assumiram uma certa
semelk ça com um livro, embora algumas páginas estivessem impressas
672
cabeça para baixo e outras caíssem do livro à menor provocação. Apesar disso, alguns dos
participantes solicitaram a compra de cópias adicionais das notas de aula, e, dessa forma, como
atividade paralela, a YOURDON inc. entrou no negócio de venda de “livros”.
Entretanto, a YOURDON inc. ocupava-se principalmente em ativi dades de treinamento: o número
de cursos de treinamento distintos cres ceu para aproximadamente 50 pelos meados dos anos 80, e
a empresa atualmente já treinou cerca de 250.000 profissionais de processamento de dados nos
Estados Unidos e em 30 outros países. As atividades de consultoria profissional também
começaram a se expandir e muitos dos membros técnicos da companhia agora trabalham como
consultores, lideres de projetos e analistas de sistemas em importantes projetos de desenvolvimento
de sistemas na América do Norte e ria Europa. E em meados da década de 80, a empresa ingressou
no mercado CASE, com um produto tipo caixa de ferramentas para analistas do tipo descrito no
apêndice A. Em 1987, a YOURDON inc. possuía escritórios em 8 cidades, com uma equipe de
aproximadamente 150 pessoas.
A YOURDON Press começou como uma divisão da YOURDON inc. em 1976 com a publicação
em brochura de três livros: Structured Design, por Yourdon e Constantine; Learning lo Program in
Stru.ctured COBO4 por Yourdon, Gane e Sarson; e How To Manage Slructured Pro gramming, de
Yourdon. Assim como em tantas outras operações co mercias, isso ocorreu sem muito
planejamento ou preocupações de orga nização: os livros pareciam ser uma boa maneira de
popularizar os con ceitos das técnicas estruturadas desenvolvidas e comercializadas nos se minários
da YOURDON inc.
Os três primeiros livros foram produzidos em uma simples máqui na de escrever IBM Selectric e
preparados em folhas de 8.5 por 11 po legadas; tudo isso precedeu os dias da impressão e
editoração adequa da. A publicidade era bastante modesta, consistindo apenas em uns poucos
anúncios na Computerworld e remessas para a lista de clientes dos seminários da YOURDON. As
véndas eram igualmente modestas; na verdade, nos primeiros anos de sua existência, a YOURDON
Press re presentava somente uma pequena fração dos rendimentos gerais da empresa.
Em conseqüência, o sistema de informações que englobava as itil dais atividades da YOURDON
Press era pequeno e manual em sua natu reza. Os pedidos eram recebidos pelo telefone ou pelo
correio, mas pedidos por cartões de crédito não eram aceitos. As faturas eram datilo grafas à mão
em formulários de fatura em quatro vias e os pedidos eram manualmente empacotados um a um. O
material era armazenado em um dos mais elegantes espaços de armazenamento do mundo: os
escritórios envidraçados do 38 andar da YOURDON inc. na Avenue of the Ameri cas, 1133, com
vista para toda Manhattan.

Página 455 de 584
673
A automatização chegou à YOURDON inc. na primavera de 19; na forma de um minicomputador
PDP-I1/45, de segunda mão, e u misterioso sistema operacional chamado UNIX . Poucos meses
mais t de, uma fotocompositora, duas dúzias de terminais e o pacote TROFF composição foram
acrescentados. Isso facilitou imediatamente a prod çào, em composição, de livros da YOURDON
Press e terminou por co duzir à automatização de diversos aspectos das atividades de treiname to e
de contabilidade geral da YOURDON inc. Porém as atividades o racionais da YOURDON Press,
aquelas que poderiam ser considerad como um sistema de informações”, continuaram a funcionar
de mo manual por mais alguns anos.
Em 1980, um número limitado de aplicações computadorizadas 1 desenvolvido para a YOURDON
Press, com utilização dos práticos reci. sos de canalização do sistema operacional UNIX. Entre
1980 e 1985, linguagem de programação C e alguns shell scriprs do UNIX foram uti zados para
acrescentar gradualmente alguns programas simples pa processamento de pedidos, relatórios de
vendas, rótulos de embarque diversos relatórios contábeis. Embora esses programas fossem fáceis
serem desenvolvidos e de operação razoavelmente confiável, eles fora desenvolvidos a retalho, de
modo semelhante ao que se vê muitas vez hoje em uma organização de PED, onde os usuários têm
acesso a piar lhas eletrônicas, geradores de relatórios e linguagens de programação quarta geração.
Eles também eram um pouco limitados; por exemplo, os detalhes de um pedido precisassem ser
modificados após sua entrad o sistema não podia fazer isso. O editor de texto padrão do UNIX e
utilizado para fazer a modificação, que estava armazenada no comp tador como um simples texto
ASCII, finalizado por um caracter fim-de-linha.
Uma das mais dificeis atividades da operação diária da YOURDC Press era a tarefa de produzir
uma informação atualizada mosiran todos os pedidos, pagamentos, devoluções de livros e créditos
de u cliente relativos a um determinado período. Igualmente dificil era o pr cesso de conciliar essas
atividades (que ocorriam como interações ent os clientes e o pessoal administrativo da YOURDON
Press) com registros financeiros mantidos pelo setor de contabilidade da YOURDC inc. Por
diversos motivos, a YOURDON Press e o Departamento Contabilidade sempre pareceram estar
“fora de sincronia” entre si. Is tornava-se mais complicado pelo fato de que o escritório da
YOURDO inc. em Londres tinha seu próprio inventário de livros e fazia sei próprios embarques e
seu faturamento de maneira independente do e critório de Nova lorque; os preços eram estipulados
em libras esterlin em vez de dólares e geralmente eram um pouco mais elevados que preços
estabelecidos pelo escritório de Nova Iorque . A cada trimestr quando tinham de ser preparados os
documentos financeiros, era;
674
realizadas longas, frustrantes e entorpecedoras reuniões em que os rela tórios impressos em
computador do Departamento de Contabilidade eram comparados manualmente com os emitidos
pela YOURDON Press para que as diferenças fossem conciliadas. Os ânimos explodiam; grita
vam-se insultos, obscenidades e diversos epítetos reciprocamente; ás vezes voavam objetos em
todas as direções. Não era uma atividade agra d.ável para se esperar a cada trimestre.
Desse modo, por volta de 1986, era evidente que teria de ser de senvolvido um completo sistema
para que a YOURDON Press pudesse continuar crescendo; foi então iniciado o planejamento do
novo sistema. Contudo, também era evidente que seria necessário um vultoso volume de capital

Página 456 de 584
para continuar a ampliação dos negócios, não somente para o equipamento adicional de
computação, mas também para modernizar o equipamento de composição (que já estava obsoleto)
e aumentar as atividades editoriais e comerciais da divisão. Por fim, decidiu-se que seria mais
sensato permitir que as atividades editoriais fossem adquiridas por uma empresa maior, o que
conduziu á fusão com a Prentice-Hall. Assim, os modelos de sistema descritos a seguir
representam o que os requisitos seriam se a YOURDON Prcss continuasse a funcionar como
empresa independente.
O planejamento do novo sistema de informações também coincidiu com uma série de mudanças
organizacionais na YOURDON Press e no restante da YOURDON inc. De sua origem em 1974 a
aproxima damente 1983, a empresa utilizava a estrutura organizacional mostrada na figura F.1
Entre 1984 e 1986, a companhia adotou uma organização mais
regional e acrescentou uma nova divisão para seus produtos de software,
como se vê na figura F.2.
?ndas &
rcializaçã
Figura F.1: Est organizacional da YOURDON inc., 1974-1983
1
675
A
Soft ware
Figura F.2: Estrutura or da YO(JRDON inc., 1ÇÀS
E, durante esse período, a YOURI)ON Prc gradativamcnte desenvolve
a estrutura organizacional mostrada na figura F.3.
Como parte dessa reorganização, as operações de remessa c YOURDON Press mudaram-se das
elegantes acomodações ocupada pelo resto da equipe para um depósito cm Yonkcrs, Nova lorque.
Des forma, havia uma separação física dc umas 20 milhas entre as pesso que davam entrada a
pedidos e as que embalavam livros em caixas remetiam os pedidos aos clientes.
Os quatro grupos principais da YOURI)ON Prcss tinham as seguir
tes responsabilidades:
• Serviços administrativos responsabilizava-se pela maioria da interações diárias entre a
YOURI)ON Press e os clientes. Dc
se modo, esse grupo recebia pedidos; emitia faturas; recebi
Figura F.3: Estrutura organizacional da YOURDON Press
676
pagamentos; discutia devoluções de livros e créditos com os clientes; interagia com o depósito
quanto a remessas de livros; e também entendia-se com o Departamento de Contabilidade, como já
foi mencionado.

Página 457 de 584
Vendas e comercialização era responsável pela produção de catálogos dos diversos livros da
YOURDON Press; colocando anúncios em revistas sobre computadores e jornais de negócios;
enviando folhetos promocionais a várias listas postais; e propon do vendas via telefone a grandes
compradores de livros técnicos de computação.
• Aquisições era responsável pela procura de novos autores e no vos livros. Esse setor da
YOURDON Press encarregava-se de to dos os contatos com os autores até o momento da entrega
do manuscrito final.
• Editorial era encarregada de receber o manuscrito final e trans formá-lo em um livro publicado.
Isso não só envolvia a copiedi ção do livro, mas também entendimentos com gráficas visando
propostas das versões iniciais do livro. Editorial responsabiliza va-se também pelo acabamento
artístico e produção da capa e do conteúdo.
Deve-se lembrar que a YOURIX)N Press era um estabelecimento bastante pequeno em
comparação com outras editoras conhecidas como McGraw-Hill, Harcourt-Brace, Prentice-Hall e
Random House. Pode-se ter uma idéia da çscala do empreendimento examinando-se os seguintes
dados estatísticos:
• A YOURDON Press tinha aproximadamente 50 livros em sua lista; cerca de 4 a 6 novos títulos
eram incluídos à lista a cada
ano.
• Os livros eram escritos por cerca de duas dúzias de autores, e o grupo da aquisição tratava com
aproximadamente 200 poten ciais autores, isto é, pessoas que demonstravam interesse em
•escrever um livro, mas que de fato ainda não tinham nada escrito.
• A YOURDON Press processava em torno de 50 pedidos por dia.
• O valor médio de um pedido girava em torno de $100, que nor malmente representava três ou
quatro livros. Alguns pedidos,
677
naturalmente, eram de apenas um livro; outros eram maiore Havia grandes celebrações sempre que
aparecia um pedid superior a $5.000.
• Eram despachados cerca de 50.000 livros por ano.
Malgrado a pequena escala, a YOURDON Press funcionava d modo muito semelhante ao das
grandes editoras. As vendas eram feita via pedidos escritos, por telefone, ou diretamente (isto é, um
cliente qu entrava nos escritórios da YOURDON inc./YOURDON Press para corr prar um livro).
Os pagamentos podiam ser efetuados a dinheiro (o qu era raro), por cheque ou por cartão de
crédito. Como questão de norm; os pedidos inferiores a $100 tinham de ser pagos antecipadamen
os pedidos grandes, principalmente os de livrarias e empresas, norma mente exigiam fatura.
Para entender as operações de uma editora, é preciso conhecer conceito de devoluções. Se um
cliente individual ou uma corporaçã chegasse à conclusão de que um livro não se adequava a suas
necessid des ou que tinha sido danificado na remessa, geralmente devolviam livro e solicitavam um
reembolso. Isso ocorria normalmente dentro d alguns dias depois que a remessa tivesse sido
recebida pelo cliente. A livrarias, por outro lado, tinham o privilégio de devolver até a metad dos
livros de um pedido no prazo de um ano a partir da data de cntrad do pedido; isso é normal na

Página 458 de 584
indústria editorial, porque as livrarias muita vezes não sabem de antemão qual será a demanda por
um livro e quc rem evitar encalhes de estoque que não conseguem vender.
F.3 O MODELO AMBIENTAL
F.3. 1 A Declaração de Objetivos
O objetivo do YOURDON Press lnformauon System (YPIS) é mar ter informações necessárias à
venda de livros a clientes. Isso inclui entra da de pedidos, faturamento, geração de documentos de
remessas, cor trole de inventário e produção de relatórios sobre direitos autorais relatórios
contábeis.
678
F.3.2 O Diagrama de Contexto
Figura F.4: Diagrama de Contexto do sistema YPJS
F.3.3 A Lista de Eventos
A lista de eventos do YPIS compõe-se de 40 eventos. A maioria deles é dirigida pelo fluxo, embora
a maior parte dos eventos relativos ao Departamento de Contabilidade seja periódica. Os eventos
são rela cionados a seguir; os eventos periódicos estão marcados com um T após a descrição do
evento.
1. Cliente pede livro (isso também inclui pedidos urgentes).
2. Cliente envia pagamento.
3. Cliénte solicita informações sobre livros (preço etc.).
4. Cliente solicita permissão para restituir um livro.
5. Cliente indaga a situação de um pedido de livros.
6. Cliente indaga a situação de uma fatura.
679
7. Cliente necessita da posição (mensal). (1)
8. Cliente solicita crédito.
9. Cliente quer cheque de reembolso.
10. Contabilidade precisa (diariamente) da receita em dinheiro. (T)
11. Contabilidade precisa (diariamente) do relatório de receita. (1)
12. Contabilidade precisa (mensalmente) do relatório da receita líqu da. (1)
13. Contabilidade precisa (trimestralmente) do relatório de direit( autorais dos autores. (T)
14. Contabilidade precisa (mensalmente) dos dados de inventário. O
15. Contabilidade precisa (mensalmente) do relatório de comissões c vendas. Ç
16. A Direção estabelece novo limite de crédito para um cliente.
17. Contabilidade precisa (mensalmente) do relatório de contas a rec ber atrasadas. (D
18. Gráfica apresenta cotação para pedido dc impressão (ou reimpre sã o).

Página 459 de 584
19. Direção autoriza um pedido de impressão.
20. Gráfica informa quantidade exata de impressão e data de entrega
21. Gráfica remete fatura de impressão.
22. Direção solicita cotação de pedido de impressão.
23. Comercialização solicita etiquetas postais do banco de dados d clientes.
680
24. Comercialização precisa de estatísticas de vendas de livros.
25. Comercialização precisa data de entrada em estoque de novos títulos.
26. Editores anunciam novo título de livro (data de prontificação gráfica).
27. Autores precisam de relatórios de direitos autorais trimestrais. (D
28. Depósito precisa de dados para remessas e etiquetas postais. (1)
29. Depósito recebe livros da gráfica.
30. Depósito recebe devoluções de livros de cliente.
31. Depósito realiza (mensalmente) inventário fisico.
32. Depósito remete pedido de livros para cliente.
33. Depósito anuncia que um livro está em falta no estoque.
34. O Departamento de Aquisições anuncia o projeto de um novo livro.
35. Vendedor apresenta pedido cm nome de cliente.
36. Comercialização declara que um livro não é mais impresso.
37. Cliente informa mudança de endereço.
38. Autor informa mudança de endereço.
39. Cliente dcre ao plano da agência.
40. Fatura precisa ser rcmcUda para cliente. (1)
681
F.4 O MODELO COMPORTAMENTAL
F.4. 1 O Modelo Comportamental Preliminar:
Diagramas de Fluxo de Dados
Cada um dos 40 eventos listados na seção F.3.3 tem um diagraír de fluxo de dados associado. É
claro que a atividade de impressão de ui livro torna impossível, para dizer o mínimo, interligar
todos os 40 diagr; mas em um único diagrama composto representando todo o sistem Como
ressaltamos no capítulo 19, esse é o tipo de exercício que exi uma folha de papel muito grande - ou
várias folhas pequenas colada Deixo isso como exercício para o leitor.
Os diagramas foram desenhados com a Versão 2.0 do pacote d software Design, da Meta Systems
Inc., dc Cambridge, Mass. Embora nã seja uma completa caixa de ferramentas CASE, ele é mais
sofisticado qu a maioria dos pacotes gráficos simples; e tem a vantagem de funcion; em um

Página 460 de 584
computador Macintosh, que foi utilizado na preparação des livro. Para acomodar o programa
Dcsign, apresentei os depósitos nc DFD com a notação vista na figura F.5.
[ NOMEDODEPÓSIT
Figura F.5: Notação de depósitos no estudo de caso da YOURDON Press
Ao desenhar os DFD preliminares, tomei nota dos erros que encor trei e das modificações que
percebi que precisavam ser feitas em outra partes do modelo; essas notas estão relacionadas abaixo
dc cada DFD. motivo para isso é enfatizar que em um projeto do mundo real o analist de sistemas
raramente desenha um DFD perfeito da primeira vez; ap pensar sobre o sistema e depois de
continuas entrevistas com o usuáric é inevitável que se descubram erros no DFD cm exame ou em
algum outra parte do modelo do sistema.
Não foi feita qualquer tentativa de criar um dicionário de dadc organizado durante o
desenvolvimento do modelo comportament preliminar. Após a criação do modelo dc DFD inicial,
foram esboçada as especificações de processo para verificar se havia algum erro evider te; muitos
desses erros aparecem como comentário3 nas páginas seguir tes. Em seguida foi criado um
conjunto dc DFI) cm níveis, sendo tarr bém desenvolvido o dicionário dc dados.
682
Notas
Depois de desenhar a primeira versão deste diagrama, lembrei-me que os pedidos em cartão de
crédito normalmente exigem uma autorização se o valor estiver acima de um certo limite. A
YOURDON Press aceitava pedidos pagos pelo Mastercard, Visa e American Express, daí a
interface com o terminador “AGÊNCIAS DE CRÉDITO’.
2. Um pouco mais de raciocínio sobre a situação de crédito eviden ciou que a definição de cliente
no depósito CLIENTES teria de incluir o campo limite-de-crédito. Ficou também evidente que
havia a necessidade de um evento para mudar o limite de crédito do cliente (evento 16) que antes
não tinha sido percebida.
3. Observe que os pedidos não são despachados na modalidade de um por vez, com a exceção dos
pedidos urgentes. Os detalhes de um pedido urgente são enviados imediatamente para o Depósito;
todos os outros pedidos são simplesmente armazenados no depósi to PEDIDOS. Como um evento
separado (evento 28), o Depósito
683
Evento 1: Cliente pede livro
recebe etiquetas postais e instruções de embarque para um grup de pedidos (normalmente os
pedidos de um dia). Esqueci-me dc pedidos urgentes na versão inicial do diagrama.
4. Quando estava desenhando este diagrama, percebi também a n cessidade de um depósito
ARQUIVOS, que é uma cópia do pedid original do cliente (ou, no caso de pedido por telefone,
uma cóp do formulário do vendedor), mais uma cópia da fatura gerada pai o pedido. A cópia da
fatura não é necessária em um modelo esse cia! (uma vez que pode ser regerada), mas os outros
documentc são necessários no caso de uma dúvida posterior com o cliente, no caso de auditorias ou
investigações das autoridades fiscais etc
5. Perceba que os pedidos podem ser recebidos pelo correio, p telefone ou pessoalmente. Não

Página 461 de 584
mostramos isso no DFD acima, uni
vez que são funções transportadoras.
6. Observe que o sistema não renova pedidos de livros da gráfic automaticamente. Em vez disso, a
direção é informada nas diversa ocasiões em que o inventário caiu abaixo de um limite preestabek
cido. Isso pode ocorrer como resultado do evento 1, bem como d diversos outros eventos.
7. Os pedidos podem ser recebidos de novos clientes (principalmeni novas livrarias ou empresas
que encetarão contínuos negócios coi a YOURDON Press). Assim, um novo registro terá de ser
criado e:
CLIENTES com a taxa de desconto padrão etc. Esta é a razão d seta de duas pontas entre a bolha 1
e o depósito CLIENTES.
684
Evento 2: Cliente envia pagamento.
Notas
O pagamento pode ser referente a várias faturas diferentes, mas nem sempre é evidente que
fatura(s) está (estão) incluída(s). Às ve zes os clientes não identificam a fatura que está sendo paga;
al gumas vezes eles identificam faturas que já foram pagas e às vezes citam números de faturas
inexistentes.
2. Às vezes não fica bem definido dc onde vem o pagamento. Isso vale principalmente para as
cadeias dc livrarias: a livraria XYZ na cidade A pode pertencer a um conglomerado, PQR, na
cidade B. Se um cheque qualquer, oriundo da PQR Corp., chegar endereçado à YOURDON Prcss,
podemos não conseguir identificar a fatura e até a empresa envolvida. Pagamentos desse tipo são
incluídos em uma categoria contábil denominada dinheiro não aplicado. A pressupo sição é a de
que se continuarmos remetendo faturas atrasadas para a livraria XYZ eles informarão que a fatura
foi paga pela PQR.
3 Nada garante que o pagamento corresponda ao valor exato da
fa Alguns pagamentos são maiores ou menores por uma pe quena importância aleatória. Alguns
clientes tentam não pagar os impostos sobre vendas ou as taxas dc remessa; isso costuma resul tar
em pagamentos inferiores em um ou dois dólares ao valor devido.
685
ID-de-cl lente +
Evento 3: Cliente solicita informações sobre livros.
Notas
1. O cliente geralmente indaga coisas como o preço de um livro, o quando um novo livro deverá
estar em estoque, ou a tabela d
desconto por volume.
686
+ consulta
resposta-de informação-de-livro

Página 462 de 584
Notas
1. Os clientes devem obter permissão da YOtJRI)ON Press antes cc restituir livros. Eles nunca o
fazem.
2. As devoluções reais chegam mais tarde e podem ou não coincidir com a devolução pretendida e
que havia sido autorizada.
3. Observe que uma devolução solicitada tem que ser comparada com o pedido original.
Evento 4: Cliente solicita permissão para restituir um livro.
D-de-cliente +
solicitação-de-devoluçáo
Notas
1. A remessa de um pedido de cliente pode ser retardada por caus da demanda no depósito ou por
falta de estoque do livro. É a pc
tencial demora que provoca a consulta do cliente.
2. Se o cliente resolver cancelar o pedido nesse momento, isso considerado como um evento à
parte.
3. Outra possibilidade é que o pedido não tenha sido recebido n YOURDON Press (ou por extravio
pelos Correios ou em algur lugar na sala de despachos do escritório do cliente ou d; YOURDON
Press).
4. O pedido pode ter sido recebido na YOURDON Press e processa do; na realidade pode ser até
que o depósito tenha remetido pedido, mas ele tenha sido extraviado pelos Correios (ou po outra
agência de entregas) no caminho até o usuário. Esse caso tratado do mesmo modo (ex.: o usuário
pode resolver cancelar pedido nesse momento ou solicitar um crédito e entregar o pcdid
novamente).
5. Enquanto eslava preparando este I)Fl), percebi que as faturas nàc eram enviadas para o cliente (o
despacho dos livros pci
688
Evento 5: Cliente indaga a situação de um pedido de livros.
resposta-de ID-de-depósito + nade fatura + de-pedido
ID-de-cliente + consulta-de-
depósito(almoxarifado) e o envio da fatura pelo escritório central da YOURDON Press são dois
eventos distintos). Assim, precisamos de um depósito separado para faturas e um evento periódico
para fazer com que as faturas sejam remetidas.
Evento 6: Cliente indaga sobre a situação de uma fatura.
Notas
1. A pergunta do cliente pode ser relativa à taxa de desconto que foi cotada na fatura, ou às taxas de
remessa, impostos sobre vendas ou
outros detalhes da fatura.

Página 463 de 584
2. Se o usuário fizer uma indagação mais geral sobre todos os seus pedidos, pagamentos e coisas
assim, o evento 7 é a parte do siste ma que cuida do assunto.
3. Para este evento é necessário um número-de-fatura para que se possa recuperar informações
sobre o pedido (número-de-fatura é um componente de consulta-sobre-fatura, como será visto no
dicionário de dados).
689
Evento 7: Cliente necessita da posição (mensalmente).
Notas
1. Enquanto trabalhava neste DFD, descobri a ncccssidadc dc u evento para permitir que o cliente
solicitasse um crédito (evento 8
2. Observe que este evento é periódico (isto é, as posições são gcn das regularmente, uma vez por
mês).
690
Evento 8: Cliente solicita crédito.
Notas
1. O cliente pode receber um crédito por diversos motivos:
• Um erro no pedido original (o cliente pode ter recebido um des conto errado ou ter sido cobrado
um preço errado etc).
• O cliente recebeu mercadoria danificada (ex.: os livros foram rasgados pelo correio).
• O cliente recebeu uma remessa menor do que deveria por causa de um erro do depósito. Então ele
deseja um crédito pelos livros
não recebidos, em lugar de receber os livros que faltaram.
• O cliente pagou a mais por uma ou mais faturas anteriores e só agora descobriu o fato
(normalmente o pagamento excessi vo tornar-se-ia evidente quando ele recebesse sua posição
seguinte).
691
ID-de depósito + n de fatura + notificação-de-não-remessa
solicitação-de-aut-de-crédito/
resposta-de-a ut-de-créd ito
‘1
houve uma excessiva demora na remessa, de modo que o clier te resolveu cancelar o pedido.
2. A tarefa principal desta bolha é atualizar a situação do crédito d cliente.
3. Entretanto, observe que a direção pode autorizar o crédito. Fst evento foi desenhado para retratar
uma imediata resposta da dirc
ção, de forma a que uma resposta possa ser dada ao cliente. lss evita um depósito “pendente” dc
solicitações de auiorizações d

Página 464 de 584
crédito, que, de outra forma, seria necessário.
4. Observe que esta atividade nada tem a ver com devoluções d livros, que são tratadas
separadamente.
Evento 9: Cliente quer cheque de reembolso.
resposta-de solicitação-de cheque
reembolso de-reembolso
Notas
1. Nada há a opor se o cliente realmente necessita de um acerto d crédito. Na maioria dos casos, o
cliente aplicará um crédito suplc mentar em futuras compras. Entretanto, por vezes ele quer un
cheque, ou porque não pretenda fazer qualquer compra futura oi por algum outro motivo.
692
Evento 10: Contabilidade precisa (diariamente) da receita em dinheiro.
Evento 11: Contabilidade precisa (diariamente) do relatório da receita.
dinheiro + relatório-de-caixa
relatório
da - receita - diária
693
Evento 12: Contabilidade precisa (mensalmente) do relatório da receita líquida.
694
relatórios-da-receita
Evento 13: Contabilidade precisa (trimestralmente) do relatório de direitos autorais dos
autores.
Notas
1. Precisamos ter acesso ao depósito LIVROS para obtermos a taxa de direitos do autor do livro (o
mesmo autor pode ter taxas diferentes
de direitos para livros diferentes).
2. Precisamos ter acesso ao depósito AUTORES para obtermos o número do Seguro Social do
autor, seu endereço etc.
3 Também precisamos ter acesso ao depósito LIVROS para vermos se existe algum adiantamento
pendente (que pode ter sido con cedido como resultado do evento 34) e para atualizá-lo para refletir
os direitos cumulativos presentemente devidos.
4. Observe que os direitos relativos a qualquer período podem ser negativos se as devoluções de
livros relativas àquele período exce derem o número de novos livros pedidos.
695
5. Precisamos do depósito PEDIDOS porque a contabilidade quc detalhes sobre quem comprou os
livros. Não precisamos disso n

Página 465 de 584
evento 27.
Evento 14: Contabilidade precisa (mensalmente) dos
dados de inventário.
relatório de inventário
Notas
1. O inventário é atualizado dc forma não sincronizada em decoi rência de pedidos, devoluções,
recebimento dc novas remessas d
gráfica e de inventários flsicos.
2. Observe que este relatório mostra livros que foram pedidos, ma que podem não ter sido
remetidos pelos depósitos. Ele não corrc ponderia necessariamente a um inventário fisico feito
simultanca mente em virtude do duto dc pedidos que foram processados ma ainda não tenham sido
remetidos.
696
Notas
1. Presume-se que os vendedores recebem uma comissão mesmo que
o cliente não tenha pago pelo pedido. É ignorado o problema real
de restituir a comissão se o cliente nunca vier a pagar pelo pedido
e a fatura correspondente tenha que ser anulada.
2. Observe que muitas vendas não estão associadas a um determina do vendedor; os pedidos são
recebidos, sem serem solicitados, em decorrência de campanhas postais diretas, revistas sobre
processa mento de dados, e coisas semelhantes.
3. Este modelo também pressupõe que todos os vendedores recebem a mesma taxa de comissão, e
que a comissão é a mesma para todos os livros. Entretanto, a taxa dc comissão pode ser alterada
pela di.reção a cada vez que este evento ocorre.
4. O modelo também presume que temos dc mostrar os delalbes do pedido aos vendedores, porque
(sendo eles típicos vendedores
paranóicos) eles não acreditam no computador.
697
Evento 15: Contabilidade precisa (mensalmente) do relatório de comissões de vendas.
relatório de
Um ite-de-cródito
Evento 16: Direção estabelece novo limite de crédito para um cliente.
Notas
1. A direção pode decidir alterar o limite de crédito de um cliente p uma série de razões, das quais a
mais comum é o demorado pag mento de faturas anteriores. Entretanto, também pode ocorrer p*
motivo de falência do cliente ou se a direção perceber que condições gerais do mercado se
modificaram.

Página 466 de 584
698
Evento 17: Contabilidade precisa (mensalmente) do relatório de contas a receber atrasadas.
699
Evento 18: Gráfica apresenta cotação para pedido de
impressão (ou de reimpressão).
Notas
1. Observe que o sistema não processa a cotação da gráfica; ela simplesmente passada para a í
2. Como o sistema não faz qualquer processamento, não fica eviden ciado porque esse evento deva
ocorrer (por outro lado, pode-s objetar que o sistema tem a responsabilidade de servir como con
duto, ou interface, entre as gráficas externas e a direção d YOURDON Press). De qualquer forma,
isto permite a futura possi bilidade de o sistema fazer pedidos automaticamente, com base en
critérios preestabelecidos.
700
Evento 19: Direção autoriza um pedido de impressão.
código-de-livro +
quantidade-pedida +
data-de-disponibilidade
701
Evento 20: Gráfica informa quantidade exata de impressão e data de entrega.
Notas
1. A contabilidade precisa das informações de pedidos de livros revis tos para poder controlar os
custos unitários. Isso, em combinaçãc com o evento 14, permite que a contabilidade controle o
valor dc inventário na modalidade FIFO (primeiro a entrar - primeiro a sair).
2. Observe que isso pressupõe que a gráfica não faz modificações importantes em sua cotação
original. Na prática, a gráfica imprime uma quantidade menor ou maior que a originalmente
prevista em cerca de 1 a 2% (ex.; um pedido de impressão de 2.000 cópias de um livro pode
resultar na impressão de 2.037 livros). Normalmente, a gráfica também aguarda até esse momento
para cotar a remessa e outras alterações.
702
ID-de-gráfica + pedido-de-impressão-
Evento 21: Gráfica envia fatura de impressão.
Notas
1. Este diagrama pressupõe que a direção atenderá à fatura da gráfica imediatamente. Observe que
o YPIS não produz um cheque - apenas informa à contabilidade que deve ser emitido um cheque.
2. Este modelo também pressupõe que haverá uma fatura separada para cada pedido de impressão e
também que haverá somente um
pedido de impressão pendente em cada momento.

Página 467 de 584
3. ‘Observe que o faturamento ocorre de forma não sincronizada com a remessa dos livros pela
gráfica. Como um evento em sepa rado, o depósito informa ao sistema que os livros foram
recebidos da gráfica.
4. Presume-se também que o valor da fatura é igual ao que foi apre sentado na estimativa revista
(evento 20).
703
fatura-de-gráfica aprovada
código-de-livro + quantidade +
Notas
1. Observe que geralmente são consultadas diversas gráficas para quc se obtenha várias cotações de
preços. Essas cotações são recebida como um evento assíncrono, e cada cotação é enviada para a
dire ção (evento 18).
2. Observe que as gráficas não respondem com a cotação de imedia to; contudo, presume-se que
eventualmente o farão.
704
5. Observe que algumas gráficas insistem em um pagamento parcia adiantado sobre faturas; este
modelo não leva isso en consideração.
Evento 22: Direção solicita cotação de pedido de impressão.
solicitação-de cotação
{quantida
Evento 23: Comercialização solicita etiquetas postais do banco de dados de clientes.
etiquetas-postais
solicitação-de etiquetas
705
Evento 24: Comercia1izaç precisa de estatísticas de vendas de livros.
Evento 25: Comercialização precisa de dados de entrada em estoque de novos títulos.
706
Evento 26: Editores anunciam novo título de livro (data de prontificação gráfica).
Notas
1. Enquanto deseLlvolvia este modelo, percebi a necessidade de oca sionalmente suprimir livros do
sistema. Isso raramente acontece, mas a comercialização vez por outra decide «matar» um livro
decla rando-o fora de impressão (evento 36).
2. Embora este evento realmente crie um novo registro livro (o livro não é considerado real e
fazendo parte do sistema até que os editores tenham terminado de editá-lo e estejam prestes a
enviá-lo para uma gráfica), precisamos criar também um registro autor. Isso é feito pelo evento 34.
707

Página 468 de 584
Notas
1. Este evento é semelhante ao evento 13, exceto pelo fato de o rei tório ser entregue aos autores e
não à contabilidade.
2. Observe que a contabilidade quer ver informações detalhadas, ii duindo a identificação dos
clientes a quem foi vendido um livr
Essa informação não é dada aos autores.
708
Evento 27: Autores precisam de relatórios trimestrais de direitos autorais.
relatório trimestral- de-direitos
L IIUb
Evento 28: Depósito precisa de dados de remessas e etiquetas postais.
709
Evento 29: Depósito recebe livro da gráfica.
Notas
1. Não é levada em consideração a possibilidade de uma remess parcial da gráfica. Isso acontece
ocasionalmente: se houver um demanda fora do comum por um novo livro (Ou pela reimpressã de
um livro já existente), a gráfica pode acelerar a entrega da primeiras centenas de cópias (talvez por
via aérea) e remeter restante do pedido de impressão posteriormente.
2. Este modelo também presume que o volume recebido pelo depósi to seja igual ao especificado
no evento 20.
710
Evento 30: Depósito recebe livros de cliente.
Notas
1. O sistema pode instruir o depósito a recusar devoluções de livros que não tenham sido
autorizadas. Isso significa que o depósito de verá notificar os Correios (ou a empresa que efetuou a
remessa) que os pacotes deverão ser devolvidos ao remetente.
2. Observe que às vezes é impossível saber quem está fazendo a devolução; isto é, as informações
encontradas nos pacotes de livros
podem não corresponder a qualquer cliente.
711
Evento 31: Depósito realiza (mensalmente) inventário físico.
712
ID-de-depósito + contagem-física
LIENS.OE
Evento 32: Depósito remete pedido de livros para cliente.
Nota

Página 469 de 584
1. Presume-se que não haja remessas parciais relativas a um pedido.
713
Evento 33: Depósito anuncia que um livro está em falta no estoque.
Notas
1. Observe que a situação de falta de estoque pode ocorrer ou causa de um pedido de reimpressão
que ainda não foi recebido, em decorrência de um pedido inesperadamente grande ou p furtos
ocorridos no depósito etc.
2. Em conseqüência da situação de falta em estoque, os pedidos pr cessados subseqüentemente
podem não ser atendidos por compi
to, mas isso é problema do depósito.
714
ID-de-depósito +
titulo-de-livro +
fora-de-estoque
Notas
1. Este diagrama mostra que o evento 13 deve ler o depósito LIVROS para verificar se existe
algum adiantamento pendente.
2. Este evento também cria um novo registro de autor caso se trate de um novo autor.
715
Evento 34: O departamento de aquisições anuncia o projeto de um novo livro.
Evento 35: Vendedor apresenta pedido em nome de cliente.
Notas
1. Observe que este evento é igual ao evento 1, exceto pelo fato que o pedido é apresentado por um
vendedor em lugar do client
716
1.-
Evento 36: Comercialização declara que um livro não será mais impresso.
Notas
1. Isso pode ser executado externamente pela simples suspensão de toda a publicidade em torno de
um determinado livro. Em algum
momento não mais haverá pedidos dele.
2. Quando executado como aqui mostrado, ele impede novos pedi dos. Supõe-se que os depósitos
eliminarão o estoque remanescente
para abrir espaço de armazenamento.
3. Em situações reais, são tomadas medidas para “liquidar” o estoque existente do livro. Pode-se
vender o estoque remanescente ao autor ou a uma livraria que vende com descontos por, digamos,

Página 470 de 584
$O.1O o exemplar.
4. bbserve que o registro livro não pode ser eliminado de LIVROS pelo menos até que tenham sido
emitidos o relatório contábil mensal e a relação trimestral de direitos amorais. Além disso, pode
ainda haver pedidos pendentes que ainda não tenham sido despa chados pelo depósito.
717
5. Observe que todos os depósitos precisam ser informados da occ rência desse evento.
6. Nesta altura, estamos pressupondo que não há pedidos pendent na gráfica: se as vendas foram
insatisfatórias ao ponto de retirarm o livro de impressão, é virtualmente impossível imaginar que
teni sido emitido um pedido de reimpressão.
Evento 37: Cliente informa mudança de endereço.
718
Evento 38: Autor informa mudança de endereço.
719
Evento 39: Cliente adere ao plano da agência.
Notas
1. O plano da agência é conhecido por diversos nomes na área edit rial (ex.: “plano padrão dc
remessas”, “plano garantido de remc sas”, “plano permanente de pedidos” etc.). Ele é utilizado
qua’ que exc por livrarias. A livraria apresenta um pedi inicial de uma certa quantidade de livros e
concorda em aceitar u certo número de cópias de cada novo livro que a YOURDON Pre publicar.
720
ID-de-cliente +
resposta-a-plano da-agência
Evento 40: Fatura precisa ser remetida para cliente.
721
F.4.2 O MODELO COMPORTAMENTAL FINAL:
DIAGRAMAS DE FLUXO DE DADOS
O modelo comportamental inicial mostrado nas últimas páginas transformado em um conjunto de
DFD subdividido em níveis. A sub visão em níveis ascendentes produziu o diagrama de figura 1
mostra4 na página seguinte; ele é tão complexo que não mostrei os detalhes todas as entradas e
saídas de todas as bolhas. As figuras subseqüeni mostrarão quais eventos foram agrupados. Em um
dos casos, um ever isolado (o evento 26) não foi subdividido em níveis ascendentes, aparece como
o processo 5 na figura 1. Em um outro caso (evento 1) necessária uma adicional subdivisão
descendente por causa da coi plexidade do processamento.
722
Figura O: O DFD de nível mais elevado
723
entrada-de- saídas-de

Página 471 de 584
gráficas
724
Figura 1: Processar ped idos
Figura 1.1: Processar pedido
725
baixo
726
Figura 2: Gerenciar clientes
Figura 3: Produzir relatórios contábeis
727
728
Figura 4: Gerenciar gráficas
código-de etiquetas.postais
LIVRO
resposta-de-
Figura 6: Interagir com comercialização
729
ID-de-depósito +
número-de
fatura + data
Figura 7: Interagir com depósitos
730
relatório-de-
di
adiantamento/
resposta-de autorização-de adiantamento
resposta-de adiantamento
Figura 8: Interagir com autores
731
F.4.3 O DICIONÁRIO DE DADOS
O dicionário de dados está organizado na forma descrita no cap tulo 10. Os termos autodefinidos
(elementos de dados cujos significadc são suficientemente bem conhecidos e que não requerem
definição e plícita) são apresentados com a definição de . Veja, como exemplo, definição de “país”
e “estado”.
AUT-DE-DEVOLUÇAO-# = *depósjto de dados utilizad

Página 472 de 584
para controlar o número seguin
te de uma devolução autorizad
* aut-de-devoluçào-#
aut-de-devolução-# = *número seqüencial utilizad para identificar um conjunt específico de livros
devolvido que tenham sido autorizados* {dígito-numérico}
autor = *informaçõe$ existentes sobr
cada autor*
@ID-de-autor + detalhes-de autor + saldo-de-direitos
AUTORES = {autor}
autorização-de-
devolução-de-livro *resposta ao cliente quando
depósito notifica o sistema d que as devoluções de livro foram recebidas*
[ devolução não está au torizada” 1 “Esta devoluçã está autorizada”]
autorização-de-fatura-
de-gráfica = *resposta da direção depois d
verificação de uma fatura d gráfica*
[ 1 “NÃO”]
caracter-alfabético = *uma letra do alfabeto*
**
732
caracter-alfanumérico = *um número, uma letra ou um sinal de pontuaçâo* [ 1 dígito- numérico 1
sinal-de-pontuação
cliente - *um cliente da YOUPDON Press* @ID-de-cliente + (nome-de-em presa) + nome-de-
cliente + endereço-de-cl + saldo- atual + limite-de-crédito + nível-de-plano_da_agência
**CLIENTES - {cliente}
código-de-ano = *Q5 dois últimos dígitos do ano
atual. P.ex.: “88”, se o ano
atual for 1988*
2 {dí gito-numérico ) 2
código-de-livro = *código numérico que idez
cada livro*
l{dígito-numérico}
código-postal = *código postal americano, ca-
nadense ou inglês*

Página 473 de 584
**
comissão-total = *total pago em comissões a um
vendedor durante o período de
um mês com base em todos os
livros que ele tenha vendido.
Calculado no processo 3.6*
**
consulta-de-crédito = solicitação de autorização
a uma agência de cartões de
crédito para a compra de li
vros *
“Solicitação de autorização” +
número-do-cartão_de_crédito +
total-do-pedido
contagem-de-inve = *informação relativa a uma
contagem física efetuada por um
depósito*
(detalhe-de-inventário) + na-
data
733
contagem-fisica = *contagem do número de cópia
de um mesmo titulo encontrada
em um inventário fisico reali
zado por um depósito*
**
cotação-de-gráfica *cotaçâo de uma gráfica; um
oferta para a inpressão de uni
certa quantidade de livros po
um determinado preço*
código-de-livro + preço-de
gráfica
crédito *crédito pessoal dado a u
cliente face a algum problem
com um pedido*

Página 474 de 584
@número-da-fatura + ID-de
cliente + data-do-crédito
código-de-livro + quantidade
de-livros-de-crédito + valor
do-crédito
CRÉDITOS = (crédito)
créditos-de-vendas *créditos relativos a um deter
minado livro durante um period
especificado*
*unidades: dólares*
data-da-devolução = *data em que um grupo de livro
foi devolvido*
**
data-de-disponibilidade = *data em que um livro cuj
impressão foi solicitada dev
chegar ao depósito*
**
data-de-remessa = *data em que o depósito despa
cha um pedido*
**
data-de-vendas = *data após a qual todos o
pedidos, créditos e devoluções
devem ser incluidos no rela
tório de estatisticas de ven
das*
**
734
data-do-crédito - *data em que um crédito foi
concedido *
**
data-do-pagamento *data em que o pagamento foi
feito*
**
data-do-reembolso = *data em que o reembolso foi

Página 475 de 584
aprovado *
**
data-do-saldo-atual - *d na qual o saldo atual do
cliente foi calculado pela
última vez (normalmente sendo
produzido um extrato para o
clíente*
data-revista *nova data estipulada pela
gráfica para a entrega de um
lote de livros presentemente
sendo impressos*
**
desconto *percentual de desconto ofere-
ciclo a um pedido, expresso como
uma fração do preço a ser pago,
isto é: um desconto de 10% se
ria expresso cono 0.90*
*jntenjalo: O l.00
detalhe-de-inventário - *contagem fisica de um único
titulo*
código-de-livro + contagem
fisica
despesas-de-remessa = *importância despendida na re
messa de um livro para o clien
te. Ela pode ter um valor pa
dronizado, p.ex.: $1,50, ou po
de ser
*baseada nas despesas reais im-
postas por um transportador*
*unidades: dólares; intervalo:
o - 100*
735
detalhes-de-autor - *tjtulo_de.cortesja + primeirc
nome + último-nome + endereço

Página 476 de 584
cidade + código-postal + (pai
+ número_de_telefone*
detalhes-de-cliente - *jnfor provindas de
cliente para alterar dÁdoS c
seus registros; ex.: um no
endereço*
(nome-de-cliente) + (nome
da-empresa) + (endereço-de
cliente)
detalhes-de-devolução = **
fitem-de-devolução)
detalhes-de-pedido = *dados brutos a partir do
quais será preparado um pedid
válido e colocado no depósit
de dados PEDIDOs*\
ID de cliente experimental
{item-de-pedido} + taxa-de-im
posto-sobre-vendas + despesas
de-remessa + tipo-de-pagament
+ (pagamento-de-pedido)
(número-de-cartão-de-crédito)
pedido-sem-estoque-OK + tipo
de-pedido
detalhes -de-pedi do-
válido = *dadog brutos a partir do
quais um pedido válido pode se.
preparado e colocado no depó
sito de dados PEDIDOS*
*ID_de_cliente + {item-de-pe
dido} + taxa-de-imposto-sobre vendas + despesas-de-remessa - tipo-de-pagamento + (pagamento-
de-pedido) + (número-de-cartão de-crédito) + pedido-sem estoque-OK + tipo-de-pedido
detalhes-do-pagamento = *info detalhadas sobre
pagamento de um item ou fatur&
(número-da-fatura) + valor

Página 477 de 584
total
736
devolução - *jnfOz sobre um grupo de
livros devolvidos e aceitos
pela YOURDON Press*
data-da-devolução + código-de-
livro + quantidade-devolvida +
valor-da-devolução
devolução-autorizada - *jnfo sobre um grupo de
livros que a YOURDON Press te
nha autorizado um cliente a de
volver em troca de crédito*
@aut-de-devolução-# + detalhes-
de-devolução
DEVOLUÇÕES - (devolução
DEVOLUÇÕES-AUTORIZADAS * {devolução-autorizada
devoluções-de-vendas *devoluções relativas a um li
vro durante um período especi
ficado de tempo*
dígito-numérico - *um simples digito numérico!*
**
DINHEIRO - {dinheiro}
dinheiro *informações sobre cheques,
dinheiro vivo e outras formas
de moeda*
@data-do-dinheiro + ID-de- cliente + {número-da-fatura} + valor
direito-de-item = *direitos garantidos pela venda
de uma ou mais cópias do mesmo
livro em um único pedido*
737
documentos-de-remessa = *lista de separação e etiqueta postais enviadas aos depósito para que

Página 478 de 584
possam separar sufi cientes cópias de cada livro despachar os pedidos do dia, mais uma cópia de
cada pedidc para que o depósito saiba qu livros devem ser embalados para cada cliente* {ID-de-
depósito + lista-de- separação + {rótulo-de-remessa} + {pedido}}
endereço-de-cliente - *endereço para envio de contas:
para onde são remetidas as fa
turas de clientes* endereço + cidade + estado código-postal + (pais)
endereço-de-gráfica - *endereço em que a gráfica pode ser contactada*
endereço + cidade + estado + código-postal
escolha-de-plano-da-
agência - *escolha do cliente de acei
tação de um nível de plano da
agência*
O_4*
estado *estado ou província em um en dereço*
**
estatísticas-de-vendas = *relatório para a Comerciali
zação sobre as vendas liquidas
de livros relativamente a um
determinado período de tempo*
{código-de-livro + receita-de
vendas + devoluções-de-vendas +
créditos-de-vendas
etiquetas-postais - *etiquetas postais produzidas
para o departamento de comer
cialização*
{cliente}
738
fatura - *infor contidas em uma
fatura da YOURDON Press*
@número-da--fatura + nome-de-
cliente + endereço-de-clie +
pedido
fatura-de--gráfica - *fatura recebida de uma grá
fica, relativa a um pedido de

Página 479 de 584
impre as ão *
código-de-livro + valor-da-
fatura
fatura-de-gráfica
aprovada - fatura de gráfica aprovada
pela direção*
código-de-livro + valor-da-
fatura
FATURAS - {fatura}
gráfica = *jnfo sobre cada uma das
gráficas com que a YOURDON
Press tem negócios*
@ID-de-gráfica + nome-de-
gráfica + endereço-de-gráfica
GRÁFICAS - {gráfica}
ID-de *jdentjfjcação de cada autor da
YOURDON Press. Os números da
Social Security não são utili
zados porque nem todos os au
tores são cidadãos americanos*
último-nome + primeiro-nome
ID-de-cliente = *jdentjfjcação de um cliente da
YOURDON Presa. Clientes desco
nhecidos ou não identificados são
citados como “receita não apli
cada”, principalmente quanto a
pagamentos
[ 1 “receita
não aplicada”]
739
experimental = *informações sobre um cliente
ao ser apresentado seu primeiro
pedido*
[ + (nome-de-

Página 480 de 584
cliente) 1 “novo” + nome-de-
cliente + (nome-da-empresa) +
endereço-de-cliente)
lD-c1e- = *identificação dos diversos
depósitos onde são armazenados
os livros da YOUPDON Press*
[ 1 “LON” 1 “DC” “SF0” 1
“YONKERS” 1 “OTTAWA”]
ID-de-gráfica = *código único que identifica
uma gráfica*
(digito-numérico}
ID-de-vendedor = *identificação de um vendedoz
da YOURDON inc.
**
imposto-sobre-vendas = *iglposto local ou estadual so
bre vendas relativo a um pe
di do *
*unjdades. dólares*
indicador-de-fora-de-
impressão *indicação binária se um livrc
está fora do estoque de forma a
que pedidos subseqüentes (se
houver algum) serão rejeitados
[ NÃO)
informação-de-devolução-
de-livro *informações sobre um grupo de
livros que foi devolvido ao de
pósito por um cliente*
(ID-de-cliente) + (nome-de
cliente) + (código-de-livro 4
quantidade-devolvida} + autori
zação-de-devolução-#
740
instruções-de_devolução = *nstruções ao depósito sobre

Página 481 de 584
como lidar com um conjunto de
livros que o cliente devolveu*
(“Cliente não identificado;
aceitar livros, mesmo assim” 1
“Devolução não autorizada; fa
vor remeter de volta” 1 “Livro
não existe” 1 “Devolução au
torizada”]
instruções-de-pedido_de_
impres são *instruções da direção para re
imprimir um livro*
ID-de-gráfica + código-de-livro
+ quantidade-a-imprimir + data-
de-disponibilidade
inventário-total-de-
livro total de exemplares de
um determinado titulo, em todos
os depósitos da YOURDON Press*
**
item-de-devolução *infonpações sobre uma ou mais
cópias de um único titulo que o
cliente deseja devolver*
código-de-livro + quantidade-a-
devolver
item-de-inventárjo = *um grupo de livros, com o mes
mo titulo, localizado em um só
depósito*
@código-de-livro + @ID-de
depósito + quantidade-de-inve
ntário
item-de-pedido = @número-da-fatura + @código-de-
livro + quantidade-pedida +
preço-unitário + desconto
I1 {item-de-inventário}

Página 482 de 584
ITENS-DE-PEDIDO - {item-de-pedido}
741
limite-de-crédito - *valor do crédito que será con cedido a um cliente para pedi
dos não previamente pagos*
*unidades: dólares; intervalo
1-10. 000*
lista-de-separação = *jndicação do número de cópia de cade livro que um de
precisa separar para satisfaze os pedidos de um dia* {título-de-livro + quantidade a-separar
livro = *informaçôes existentes sobr
um livro da YOURDON Press* @código-de-livro + título-de livro + total-em-estoque -
quantidade-pedida + data-em- estoque + taxa-de-direitos indicador-de-fora-de-impressâc
+ estoque-mínimo
LIVROS = {livro}
mensagem-de-estoque-
baixo *mensagem enviada À direçâ
quando o sistema percebe que
estoque total de um livro cai
abaixo de um limite pré-esta
belecido*
código-de-livro + total-em-
estoque + “tempo para reim
pressão”
motivo-do-crédito * do cliente para solici
tar um crédito*
[ em excesso”
“Demora excessiva” 1 “Remessa
insuficiente” “Livros danifi
cados” 1
na-data = *a data em que foi realizado ux
inventário físico*
**
742
nível-de-plano-da-
agência *código que indica que nivel de

Página 483 de 584
“estatutos” o cliente escolheu
para os futuros livros da
YOURDON Press*
*inte O_4*
nome-da--empresa = *nome de uma empresa ou de uma
organização*
**
nome-de-cliente *tjtulo_de_cor + primeiro-
nome + último-nome
nome-de-gráfica *nome da empresa gráfica*
**
nome-de-vendedor = *nc,me de um vendedor da YOUPDON
inc. *
**
notificação-de-remessa *mensagem de depósito ao ser
recebida uma impressão da grá
fica *
(“Livro não existe” 1 “Recebido
da gráfica” + código-de-livro +
quantidade-recebida]
número-da-fatura - *n único atribuido a cada
fatura; um número típico de fa
tura é B88_5067*
“B” + código-do-ano + {dígito
numérico
número-de-telefone *um número de telefone*
**
número-do-cartão-de-
crédito = *um número de cartão de crédito
fornecido por um cliente quando
ele deseja carregar um pedido
de livros em seu cartão de cré-
dito*
**

Página 484 de 584
743
pagamento = *pagamento feito em relação
um pedido de livros ou em re
lação a uma fatura*
(ID-de-cliente) + data-do-pa
gamento + detalhes-do-pagamentc
pagamento-de-pedido = *pagamento feito p c1ient
COM o pedido*
*unidades: dálares*
PAGAMENTOS = {pagamento}
pais = *nome de um pais, ex.: “Ca
nadá” *
**
pedido = *um pedido de um livro d
YOURDON Press*
@número-da-fatura + ID-de
cliente + data-do-pedido
{item-pedido} + despesas-de-
remessa + imposto-sobre-vendas
+ data-de-remessa + (ID-de
vendedor) + total-do-pedido -
ID-de-depósito
pedido-de-impressão = *p de irr feito a urna
gráfica*
código-de-livro + quantidade-a- imprimir
pedido-de-impressão-
revisto = *revisão de um pedido de im
pressão, efetuada por uma grá
fica. Consiste habitualmente en
pequenas modificações na quan
tidade a ser impressa*
código-de-livro + quantidade-
revista + data-revista
pedido-sem-estoque-OK = *indicação de se um cliente

Página 485 de 584
apresentará um pedido mesmo que
não haja livros suficientes nc
estoque*
[ 1 “Não”]
PEDIDOS = {pedido}
744
preço-de-gráfica - *preço relativo a urna cotação
de gráfica*
**
preço-unitário - *preço estabelecido para um
exemplar de um livro da YOURDON
Press ou para um pedido uni
tário; observe que pode ser di
ferente do preço unitário “pa
drão” ou “a retalho” anunciado
para o livro*
primeiro-nome = *0 primeiro nome de uma pessoa*
**
quantidade-a-devolver *n de cópias do mesmo ti tulo que um cliente deseja res tituir para obter
crédito*
**
quantidade-a-imprimir *ni de cópias de um livro a
serem impressas*
**
quantidade-a-separar = *número de cópias de um livro
que precisam ser separadas para
satisfazer os pedidos de um dia
no depósito*
**
quantidade-de-inventário= *contagem do número de exem plares do mesmo titulo, locali zados em
um mesmo depósito*
**
quantidade-de--livros-

Página 486 de 584
do-crédito = *número de cópias de um livro
para o qual está sendo procu- rado um crédito*
**
quahtidade-devolvida *número de cópias de um livro
que foram restituidos ao de-
pósito por um cliente*
**
745
quantidade-do-pedido = *nún.iero de cópias de um livr
que foram solicitadas*
**
quantidade-pedida - *número de cópias de um livr
pedidas a uma gráfica como par
te de um pedido de impressAo*
quantidade-recebida - *núinero de cópias de um livn
que foram realmente recebida
da gráfica em conseqüência d
um pedido de impressâo*
**
quantidade-revista = *revisão do número de livros serem impressos pela gráfica como parte de um
pedido di impressão*
**
receita-de-vendas = *receita bruta de vendas de ur determinado livro durante ur especificado
periodo de ternpo
receita-total = *valor total da receita bruta
de todos os pedidos de livro
em um n
receita-total-de-livros = *receita total proveniente d venda de um livro durante un periodo de três
meses, conside rando-se créditos e devoluções
* dólares*
reembolso = *informações sobre um reem bol so*
@data-do-reembolso + @ID-de cliente + valor-do-reembolso
REEMBOLSOS = {reembolso}

Página 487 de 584
relatório-de-comissões = *relatórjo de comissões de vendas * {{ID-de-vendedor + número-da-
fatura + valor-da comissão} + total-da-comissào}
746
relatório-de-contas-
a-receber *relatório para a Contabilidade
mostrando o saldo atual de cada
cliente*
{ID-de-cliente + débito-atual}
relatório-de-direitos-
de-autor = *relatório para os autores mos
trando direitos ganhos ou per
didos em vendas, créditos e de
voluções de cada livro durante
um perlodo de três meses *
(total-de-cópias-de-livro + re
ceita-total-de-livro + total-
de-direitos-de-livro
relatório-de-inventário *relatório produzido para o
Departamento de Contabilidade*
({ID-de-depósito + código-de-
livro + quantidade-de-inven-
tário} + inventário-total-de-
livro)
relatório-de-receita-
diária *relatório enviado ao Depar
tamento de Contabilidade a cada
dia *
(número-da-fatura + nome-de-
cliente + nome-da-empresa +
total-do-pedido 1 + total-da--
receita-diária
relatório-de - receita -
mensal *relatório da receita total,
devoluções e créditos relativos

Página 488 de 584
a um único mês, enviado ao De
partamento de Contabilidade*
receita-total + total-de-devo
luções + total de crédito
relatório-trimestral-
1e-direitos - * relatório para o Departamento
de Contabilidade mostrando os
direitos ganhos ou perdidos em
vendas, créditos e restituições
de cada livro durante um perío
do de três meses*
747
{{ ID-de-cliente + nome-de-clienti + número-da-fatura + receita-de item + direito-de-item} + total
de-cópias-de-livro + receita-to tal-de-livro + total-de-direitos de-livro)
renda-de-item - *renda bruta da venda de uma 01 mais cópias do mesmo livro ei um único pedido*
resposta-a-alteração-
de-cliente - *resposta ao cliente que noti
ficou uma alteração de ende reço, etc*
(“Cliente não existe” “Ai’ teração aceita”]
resposta-a-fatura-de-
gráfica = *resposta do sistema à gráfic
quando recebe uma fatura d gráfica*
[ há pedidos pendente desse livro”]
resposta-a-fora-de-
estoque = *mensagem ao depósito em res
posta à sua indicação de que ur titulo está sem estoque naquei depósito *
[ não existe” 1 “Erro item de inventário não encon trado” 1 “mensagem de falta d estoque
recebida”]
resposta-a-informações-
de-livro = *i sobre titulo, preç
etc de um livro*
livro
resposta-a-inv-fisico - *mensagem do sistema a ur

Página 489 de 584
depósito em resposta a um invew
tário fisico realizado*
[ não existe”
“código de livro inválido”
codigo-de-l ivro]
748
resposta-a-limite-de-
crédito *resposta a instruções da di
reção para alterar o limite de
crédito de um cliente*
[ não existe” 1 “limite
de crédito inválido” 1 “Novo
limite de crédito OK”]
a-pedido = *resposta ao cliente ao intro
duzir um pedido*
[ da conpra excede valor
pago” 1 “Crédido solicitado ne
gado” 1 “Pedido excede limite
de crédito” 1 “Não há livros
suficientes para atender seu
pedido” “Cliente não existe”
1 “Livro não existe” 1 “Taxa de
imposto sobre vendas inválida”
1 “Despesas de remessa inváli
das” 1 “Pedido aceito”]
resposta-a-pedido-
de-impressão *resposta do sistema a um pe
dido de impressão da direção*
[ não existe” .1 “Quanti
dade de impressão inválida” 1
“Pedido de impressão aceito”]
resposta-a-pedido-de-
impressão-revisto _ *r do sistema ao ser re cebido da gráfica um pedido revisto*
[ não existe” 1 “Pedido de impressão revisto OK”]

Página 490 de 584
resposta-a-remoção-
de-livro = *resposta à comercialização
quando ela indicar que um livro
deve ser considerado fora de
impressão*
[ não existe” 1 “Livro
marcado como fora de im
pressão”]
749
resposta-a-solicitação-
de-devolução *resposta a um cliente que de seja devolver um livro* [ não encontrado” “Livros
foram remetidos há mai de um ano” “Quantidade d livros não pode ser devolvida’ 1 “Devolução
OK” “Favor iden tificar devolução real com” 1 aut-de-devolução-#]
resposta-de-adiantamento= *resposta ao editor de aqui
sições quando ele faz uma soli
citação de adiantamento de di
reitos para um autor*
[ não existe” “Livrc
não existe” 1 “Adiantamentc
aprovado” 1 “Adiantamento ne
gado”)
resposta-de-agência-
de-crédito = *resposta de uma agência dE
cartão de crédito a uma solici
tação de autorização de co
brança *
[ 1 “Não”]
resposta-de-autorização-
de-adiantamento = *resposta da direção a uma so
litação de adiantamento de di
reitos para um autor*
[ “Não”)
resposta-de-crédito = *resposta ao cliente que deseja uma carta de crédito* [ desse cliente n&c
existe” 1 “Crédito já conce dido” “Nenhum pagamento foi feito para esse número de fa tura” 1
“Crédito será mostradc na próxima declaração” 1 “Fa tura não foi paga em excesso” “Valor total do

Página 491 de 584
pedido credita do” 1 “Crédito por remessa in suficiente:” + valor-do-créditc 1 “Crédito por livros
danifica dos:” + valor-do-crédito]
750
resposta-de-em-estoque = * a consulta da comer
cialização sobre a data em que
estará em estoque uma remessa
de livros da gráfica*
[ não existe” “não há
remessas esperadas” 1 data-de-
disponibilidade]
resposta-de-fatura = *resposta à consulta de um
cliente sobre uma fatura*
[ há pedidos com esse número de fatura” 1 data-do- pedido + {itens-do-pedido} + despesas-de-
remessa + imposto- obre -venda s
resposta-de-reembolso = *resposta ao cliente que soli
citou reembolso*
[ não existe” 1 “Reem
bolso indevido” + “Saldo atual
é” + saldo-atual 1 “reembolso
aprovado”]
resposca-oe-remessa = *mensagem de erro a um depósito em resposta a sua notificação de que foi
remetido o pedido de um cliente*
“Pedido não encontrado”
resposta-de--situação-
de-pedido = *resposta a um cliente que con
sultou a situação de um pedido
que ele apresentou*
[ há pedidos para esse
número de fatura” 1 data-do-
pedido + {itens-de-pedidos} +
data-de-remessa]
rótulo-de-remessa = *rótulos postais para os pedi
dos do dia ao depósito*
nome-do-cliente + endereço-do-
cliente + número-da-fatura

Página 492 de 584
saldo-atual = *total em dinheiro presente
mente devido por um cliente, *
*NA DATA DO SALDO_ATUAL*
*unidades: dólares; intervalo:
1 000*
751
sinal-de-pontuação = *virg ponto, ponto de ex
clamação, etc.*
**
solicitação-de - adiantamento-de-
direitos = *soljcitaçâo do editor ae aqui
sições por um adiantamento de
direitos para um autor relati
vamente a um livro*
ID-de-autor + código-de-livro +
valor-do-adiantamento
solicitação-de- autorização-
de-adiantamento = *mensagem à direção, solici
tando aprovação para um adian
tamento de direitos para o
projeto de um livro*
solicitação-de-cheque-
de-adiantamento *mensagem ao Departamento de
Contabilidade, solicitando que
seja pago um adiantamento au
torizado de direitos*
solicitação-de-cheque-
de-reembolso *mensagem ao Departamento de
Contabilidade solicitando a
preparação de um cheque de re

Página 493 de 584
embolso para um cliente*
“Favor pagar” + ID-de-cliente +
valor-do-reembolso
solicitação-de-código-
de-livro = *mensagem à direção solicitando
a atribuição de um código-de
livro a um novo livro*
“Favor atribuir novo código de
livro ao seguinte livro;”
752
solicitação-de-crédito = *soljcitação feita por um cliente para crédito em relação a um pedido* ID-
de-cliente + número-da- fatura + código-de-livro + quantidade-de-livroa-do-crédito
+ nDtivo-do-crédito + valor-de- crédito-solicitado
solicitação-de-devolução= *info sobre um ou mais
livros que um cliente deseja
devolver em troca de crédito*
número-da-fatura + detalhes-de-
devolução
solicitação-de-etiquetas = *solicitação da Comercialização
para a produção de etiquetas
postais *
“Favor produzir etiquetas pos
tais”
solicitação-de-preço-
unitário *mensagem à Comercialização
solicitando o preço unitário de
um novo livro*
“Favor indicar preço unitário
para o seguinte livro:”
solicitação-de-reembolso= *solicitação de um cliente por um cheque no valor do seu saldo de
crédito atual* ID-de-cliente + “solicitação de reembol so”
solicitação-de-taxa-
de-direitos = *mensagem ao departamento de
aquisições solicitando uma taxa

Página 494 de 584
de direitos para um novo livro*
“Favor indicar taxa de direitos
para o seguinte livro:”
solicitação-de-vendas *solicjtação do departamento de Comercialização para que seja produzido
um relatório de vendas para todos os pedidos, cré ditos e devoluções que tenham ocor rido após a
data especificada* data-de-vendas
753
taxa-de-comissão *taxa de comissão paga a u
vendedor pela venda de livros É expressa por uma fração*
*inte O - 0.25*
taxa-de-direitos *taxa de direitos paga a u
autor por um livro express como uma percentagem. Ex.: 1 significa l0%*
*intervalo: 5_25*
taxa-de--imposto-sobre-
vendas = *percentual do imposto sobr
vendas, expresso como uma fra ção decimal. P.ex.: um inpost de 7% sobre vendas seria mdi cado
como 0.07*
*intex 0.00 - 1.00*
tipo-de-pedido = *indica se o pedido foi apre’ sentado por telefone, peL correio ou de forma
ocasional [ “Correio” 1 “Oca’ sional”]
-- q *modo como o cliente pretendi
pagar a compra de livros de U!
pedido*
[ “Cheque” 1 “Car
tão de crédito” 1 “Cobrança”]
titulo-de-cortesia = *prefixo antes do primeiro nomi de uma pessoa*
[ 1 “Sra.” 1 “Srs.” “Srta.” 1 “Dr.” 1 “Prof.”]
titulo-de-livro = *título completo de um livro d
YOURDON Press*
1 {caracter-alfanumérjco}
total-da-receita-diária = *valor total de novas venda
registrado a cada dia*
754
total-de-cópias-de-livro= *n total de cópias de um

Página 495 de 584
livro vendido, considerando
devoluções e créditos, durante
um período de três meses*
**
total-de-crédito = *valor total dos créditos con
cedidos a todos os clientes em
um único mês*
*unidades: dólares
total-de-devoluções - *importância total relativa a
livros que foram devolvidos por
todos os clientes em um mês*
total-de-direitos-de-
livro - *direitos totais ganhos (ou
perdidos) em vendas, devoluções
ou créditos de um livro durante
um período de três meses*
* dólares*
total-do-pedido = *total faturado de um pedido*
total-em-estoque *número de cópias de um livro
da YOtJRDON Press que temos em
estoque em todos os depósitos*
*inte 1 - 10.000*
último-nome *0 último nome de uma pessoa*
valor = *valor em dinheiro recebido em
um único pagamento*
valor-da--comissão = *valor da comissão paga a um
vendedor relativa a um pedido
de livros; calculada no pro-
cesso 3.6*
**
valõr-da-devolução = *valor de um grupo de livros

Página 496 de 584
que tenham sido devolvídos*
755
valor-da-fatura = *quantja cobrada por uma gr fica em uma fatura relativa
um pedido de impressào*
*unjdadeg: dólares*
valor-de-crédito-
solicitado *valor solicitado como créditc
*un idades: dólares*
valor-do-adiantamento - *jmportâncja solicitada con adiantamento de direitos*
* dólares*
valor-do-crédito = *valor dado como crédito*
*unjdades: dólares*
valor-do-reembolso - a ser restituida
um cliente*
*unidades: dólares *
vendedor = @IDdevendedor + nome-de-ver dedor
VENDEDORES = {vendedor}
756
F.4. 4 O Diagrama de Entidades-Relacionamentos
757
F.4.5 Espec de Processos
PRC 1.1.1 ITAR DETM1 DE P
BEGIN
IF Id-ds-cliente-exp.rin = “novo” ID-da-cliente = ID-de-cliente disponivel seguinte limite-de-
crédito - limite de crédito padrão saldo-atual O
nivel-da-plano-da-agôncia O
cliente ID-de-cliente + nome-de-cliente + (nome-da empresa) + endereço-de-cliente + saldo-atual +
limite-de-crédito + nival-de-plano-da-agêncie
APPEND registro de novo cliente a CLIENTES
ELSE
FIND cliente em CLIE2 com ID-de-cflent - ID-da-cliente em detalhe a -da-pedido
IF registro não encontrado resposta-a-pedido - “Cliente não existe” DISPLAY resposta-a-pedido
EXI T

Página 497 de 584
*obs. :isto significa que o pedido não mais será proces sado *
ENDIF
DO WHILE houver item-da-pedido em detalhes-da-pedido
FIND livro em LIVI com código-da-livro = código-da-
livro em item-d.-pedido
IF registro não encontrado resposta-a--pedido - “Livro não existe” DI SPLAY resposta-a-pedido
EXI T
*obs. : isto significa que o pedido não mais será processado *
END 1 F
END DO
IF taxa-de-iwposto-sc estiver fora do intervalc
resposta-a-pedido - “taxa de irposto sobre vendas
inválida”
DISPLAY resposta-a-pedido EXI T
*obs.: isto significa que o pedido não mais será processado*
ENDIF
IF despesas-da-remessa esti ier fora do intervalo resposta-a-pedido = “der ‘esas de remessa
inválidas” DISPLAY respo a-a-pedido
EXI T
758
*obs. :isto significa que o pedido não mais será proces sado*
ENDIF
d.tal.hea-de-pedido-válido = ID-de-cliente + (itein-da pedido) + taxa-de-imposto-sobre-vendas +
despesas-da r + tipo-da-pagamento + (pagamento-da-pedido) + (nun + pedido-sam-estoque-O +
tipo-de-pedido
DISPLAY (para o processo 1.1.2) detalhes-da-pedido-válido
END
1’RO 1.1.2: VERIFICAR ESTOQUE DE LIVRO
BEGIN
IF pedido-sem-estoqua-OK “Sim” DISPLAY (para a bolha 1.1.3) detalhes-de-pedido-válido
+ “YONKERS” ELSE
IF tipo-da-pedido = “Ocasional”
DO WHILE houver item-da-pedido em detalhes-da-pedido válido
FIND item-de-invantário em ITENS-DE-INVENT com código-da-livro = código-de-livro em
detalhes- de-pedido-válido e ID-de-depósito = local onde foi recebido esse pedido-ocasional

Página 498 de 584
READ registro item-da-inventário
IF quantidade-da-inventário < quantidade-pedida resposta-a-pedido = “Não há livr suficientes para
atender seu pedido”
EXI T
*obs: isto significa que este pedido não será
mais processado*
END 1 F
END DO
DISPLAY (para a bolha 1 . 1.4) detalhes-da-pedido-
válido + ID-da-depósito (do depósito onde foi
recebido este pedido ocasional)
ELSE
livros-suficientes = “Sim”
PEPEAT-UNTIL não haja depósitos em DEPÓSITOS ou
• livros-suficientes = “Sim”
• *obs.: isto significa que pelo menos um depósito será examinado*
livros-suficientes = “Sim”
DO WHILE houver item-da-pedido em detalhes-de- pedido-válido
FIND item-de-inventário em ITENS-DE-INVENTÁRIO com
código-de-livro = código-de-livro em detalhes-
759
de-pedido-válido e ID-de-depósito - ID-da depósito do registro depósito corrente
READ registro itexn-de-inventário
IF quantidade-da-inventário < quantidade-pedida livros-suficientes - “Não”
ENDIF
END DO
END REPEAT
IF livros-suficientes “Não”
resposta-a-pedido = “Não há livros suricientes par atender seu pedido”
DI SPLAY resposta-a-pedido ELSE
DISPLAY (para a bolha 1.1.4) detalhes-de-pedido válido + ID-de-depósito do registro depósito
corrente
ENDIF
ENDIF

Página 499 de 584
END
PRO 1.1.3 V AUTOPJZAÇÀO DE .tDITO
BEGIN
preço-total = O
PEPEAT UNTIL não haja itam-de--pedido em detalhes-de- pedido-válido
ADD (quantidade-pedida) * preço-unitário * desconto) a preço-total
END PEPEAT
MULTIPLY preço-total por (1 + taxa-de-inçosto-sobre vendas)
ADD despesas-de-remessa a preço-total crédito-OK = “Sim”
CASE tipo-de-pagamento de
CASE tipo-de-pagamento “Dinheiro” ou tipo-de- pagamento = “Cheque”
IF preço-total > pagamento-de-pedido
resposta-a-pedido “Valor de compra excede valor pago”
DISPLAY resposta-a-pedido
*obs.: isto significa que este pedido não será mais processado*
crédito-OK “Não” ENDIF
CASE tipo-de-pagamento = “Cartão de crédito”
consulta-da-crédito = “Solicitação de autorização” + preço-total
DISPLAY (para a agência do cartão de crédito)
760
consulta-de-crédito
ACCEPT (da agência de crédito) resposta-da-agencia da-crédito
IF resposta-da-agência-de-crédito “Não” resposta-a-pedido = “Solicitação de crédito negada” DI
SPLAY resposta-a-pedido
crédito-OK “Não”
*obs.: isto significa que este pedido não será mais
processado *
ENDIF
CASE tipo-da-pagamento - “Cobrança”
FIND client. em CLI com ID-da-client. - ID-de cliente em detalhes-da-pedido-válido
READ registro client.
IF saldo-atual. + preço-total > limite-de--crédito
resposta-a-pedido = “Pedido excede limite de
crédito”

Página 500 de 584
DISPLAY resposta-a-pedido crédito-OK - “Não”
*obs: isto significa que este pedido não será mais processado*
ENDIF
END CASE
IF crédito-OK - “Sim”
DISPLAY (para a bolha 1.1.4) detalhes-de-pedido-válido
+ preço-total + ID-de-depósito DISPL (para a bolha 1.1.5) detalhes-de-pedido-válido
+ ID-de-depósito ENDIF
END
PROCESSO 1.1.4 INTRODUZIR PEDIDO
BEGIN
DO WHILE houver item-da-pedido em detalhes-da-pedido- válido
CREATE registro item-de-pedido a partir do próximo
item-da-pedido em detalhes-da-pedido-válido
APPEND registro item-da-pedido em ITENS-DE-PEDIDO
ENJ) DO
CREATE registro pedido a partir de detalhes-de-pedido-
válido e ID-d.-depósito
APPEND registro pedido em PEDIDOS
CREATE registro fatura a partir de detalhes-da-pedido válido
P registro fatura em F
IF tipo-do-pagamento = “Dinheiro” ôu “Cheque” ou “Cartão
de crédito”
761
CPEATE registro dinheiro a partir de detalhes-de
pedido-válido
APPEND registro dinheiro a Dfl
CREATE registro pagamento a partir de detalhes-de-
pedido-válido
PPEND registro pagamento a PAG1
ENDIF
APPEND deta].hes-d-pedido-vál ido a 7 VOS
resposta-a-pedido - “Pedido aceito”
DI SPLAY resposta-a-pedido

Página 501 de 584
END
PRO 1.1.5 V INVENTÁRIO PARA REI
BEGIN
DO WHILE houver item-da-pedido em detalhes-da-pedido- válido
FIND item-de-inventárjo em ITENS-DE-INVENTÁRIO com
código-de-livro = código-de-livro em item-de-pedido ID-de-depó.ito coincidindo com ID-de-
dapósito fornecido como entrada neste processo
READ registro item-da-inventário SUBTRACT quantidade-pedida de quantidade-da-inventário
*obs.: esta operação pode resultar em saldo negativo,
*0 que significa que o depósito não poderá satisfazer’ o pedido até à chegada de uma reimpressão*
WRITE registro item-da-inventário
FIND livro em LIV com código-de-livro código-da- livro em itam-da-pedido
READ registro livro
SUBTRACT quantidade-pedida de total -em--estoque
WRITE registro livro
IF total-em-estoque < estoque-minimo mensagem-de-estoque-baixo = código-da-livro + total-
em-estoque + “hora de reimprimir”
DISPLAY mensagem-da-estoque-baixo
END 1 F
END DO
END
PRO 1.2: PI PEDIDO DE VE
A esta altura, a norma para o processamcnio do pedido ULI
vendedor é a mesma que a do processamento de um pedido normal dc
cliente. Veja os detalhes na figura 1.1.
762
PRO 1.3: REGISTR1 CLIENTE NO PLANO DA 7 Pré-condição -1
Existe um cliente em CLIENTES que coincide com ID-de client, com nível-de-plano-da-agência -
O e com escolha-de-plano--da-agência > O e escolha-da-plano-da- agência menor ou igual ao nível
máximo da agência.
Pós-condição-1.
nivel-de-plano-da-agência em cliente é ajustado em
escolha-de-plano-da-agência.
PROCESSO 1.4: ENVIAR FATURAS
BEGIN

Página 502 de 584
DO WHILE houver faturas em FPITURAS READ próxima fatura
DISPLAY fatura
END DO
END
PROCESSO 2.1: PROCESSAR PAGA
BEGIN
IF ID-da-client. presente
FIND registro em CLIENTES com ID-da-cliente coincidente
IF registro não encontrado
WRITE detalhes-de-pagamento em PA com
ID-de-client “receita não aplicada”
ELSE
StJBTRACT valor-total de saldo-atual
WRITE registro em CLI
WRITE detalhes-de-pagamento em PAGA ELSE
WRITE detalhes-da-pagamento em PA com ID-da cliente - “receita não aplicada”
WRITE data de hoje + ID-de-cliente + detalhes-de pagamento em DINREIRO
ENDIF
END
PROCESSO 2.2: FORNE INFORNAÇÕES SOBRE LIVROS
BEGIN
FIND registro livro em LIVROS com título-de-livro coincidente
resposta-a-informações-da-livro = conteúdo de todo o
registro livro
DISPLAY resposta-a-informações-de-livro
END
763
PRO 2.3: PRO SOLICITAÇ DE DEVOLUÇ
BEGI N
FIND pedido em P que satisfaça n ei solicitação-da-devolução
rasposta-a-solicitação-da-davolução = “Pedido não
encontrado”
DI SPLAY resposta-a-solicitação-da-davolução

Página 503 de 584
ELSE
READ registro pedido
IF data-d.-r mais de um ano atrás
resposta-a-solicitação-da-devolução - “Livros foram
remetidos a mais de um ano”
DI SPLAY resposta-a-solicitaç&o-da-davo
ELSE
tudo-OK = “sim”
REPEAT TJNTIL não haja itam-de-devolução em detalhes
de-devolução
FIND itam-da-pedido em ITENS-DE-PEDIDO que
satisfaça numero da fatura em solicitação-da devolução e código-da-livro em itezn-de-davoluçã4
DISPLAY “Livro não fez parte do pedido”
tudo-OK “não”
ELSE
REAl) registro item-de-pedido
IF quantidade-a-devolver em item-da-davolução maior que metade de quantidade-pedida em item-
da-pedido
resposta-a-solicitação-da-devolução = “Quantidade de livros não pode ser devolvida’ DI SPLAY
resposta-a-solicitação-da-devolução tudo-OK - “não”
ENDIF
ENDIF
END-REPEAT
IF tudo-OK = “sim”
REAl) aut-de-davolução-# de AUT-DE-DEVOLUÇAO-#
resposta-a-solicitação-da-devolução “Devolução
OK,” + “Favor identificar devolução real com” 1
aut-da-davolução-#
DISPLAY resposta-a-solicitação-da-devolução
WRITE detalhes-da-devolução, aut-da-davoluç&o-f
em DEVOLUÇÕES AUTORIZADAS
ADD 1 a aut-da-devolução-1
WRITE aut-da-devoluçào-# em AUT-DE-DEVOLUÇAO-#

Página 504 de 584
ENDIF
END 1 F
764
ENDIF
END
PRO 2.4: RE A c S SITUA% DE
PEDIDO
BEGI N
FIND pedido em PEDIDOS com numero-da-fatura coincidente
resposta-de “Não há pedidos para
esse número de fatura”
DISPLAY resposta-de
ELSE
REAl) registro pedido em PEDIDOS com número-da-fatura coincidente resposta_d. data-do-
pedido + (item-da--pedido) + data-da-remessa
DI SPLAY resposta-de-situaç ENDIF
END
PRO 2.5: RESPOND A CONSULTA SOBRE TURA
BEGIN
FIND pedido em PEDIDOS com número-da-fatura coincidente
resposta-de-fatura - “não há pedidos para esse número
de fatura”
DISPLAY resposta-da-fatura
ELSE
REAl) registro pedido
resposta-de-fatura = data-do-pedido + (item-da-pedido)
+ despesas-de-remessa + imposto-sobre-vendas DISPLAY resposta-de-fatura
ENDIF
END
PR 2.6: PRODUZIR CAR DE CRÉDITO
BEGIN
FIND pedido em PEDIDOS com ID-de-cliente coincidente e flúmero-da-fatura coincidindo com

Página 505 de 584
número-da-fatura em
solicitaç&o-da-cródjto
resposta-de-crédito “Pedido desse cliente não
existe”
DISPLAY resposta-da-crédito
ELSE
FIND crédito em C com número-da-fatura
765
coincidindo com número-da-fatura em solicitação-de crédito
resposta-da-crédito - “Crédito já foi concedido”
DI SPLAY resposta-da-créd
ELSE
CASE n OF
CASE motivo-do-crédito - “Pagamento em excesso”
FIND pagamento em P com numero-da-
fatura coincidente com número-da-fatura em
so
resposta-da-crédito “Nenhum pagamento foi
feito para esse número de fatura”
ELSE
read pagamento
FIND pedido em PEDIDOS com nun
número-da-fatura em solicitaçào-de-cré
IF valor-total > total-do-pedido
resposta-de-crédito - “Crédito será
apresentado na próxima declaração”
ELSE
resposta-de - “Fatura não foi
paga em excesso”
ENDIF

Página 506 de 584
DI SPLAY resposta-d.-cré
ENDIF
CASE motivo-do-cré - “Demora excessiva”
crédito número-da-fatura + ID-da-cljente +
datá-atual + total-do pedido
APPEND crédito em DITOS
resposta-d.-ci = “Valor total do pedido
creditado”
CASE motivo-do-crédito “Remessa insuficiente”
IF total-do pedido > valor-da-crédito_solicitado
crédito número-da-fatura + ID-da-cliente
+ data-atual + valor-da-crédito_solicitado
resposta-da-crédito “Crédito por
remessa insuficiente:” +
valor-da-crédito_solicitado
ELSE
crédito - numero-da-fatura + ID-da cliente + data-atual + total-do-pedido resposta-da-crédito -
“Crédito por remessa insuficiente:” + total-do-pedido
766
DISPLAY resposta-da-crédito ENDIF
APPEND crédito em CRÉDITOS
CASE motivo-do-crédito “Livros danificados”
IF total-do-pedido > valor-de-crédito-solicitado
crédito - número-da-fatura + ID-de-client.
+ data-atual + valor-de-crédito- sol. icitado
resposta-de-crédito “Crédito por livros
danificados: “+ valor-de-crédito-solicitado
DISPLAY resposta-de-crédito
ELSE
crédito - número-da-fatura + ID-de-cliant.
+ data-atual + total-do-pedido resposta-de-crédito - “Crédito por livros
danificados:” ÷ total-do-pedido

Página 507 de 584
DISPLAY resposta-de-crédito
ENDIF
APPEND crédito em DITOS
ENDCASE
ENDIF
ENDIF
END
PRO 2.7: INFC9W CONTABILIDADE DA MBCESSIDADE DE
R
BEGIN
FIND cliente em CLIE com ID-de-cliente igual a
ID-de-cliente em solicitaçao-da-reambolso
resposta-de-reembolso - “cliente não existe”
DISPLAY resposta-da-reembolso
ELSE
READ registro cliente
IF saldo-atual maior ou igual a zero
resposta-de-reembolso = “Reembolso indevido” +
“Débito atual é” + saldo-atual
DISPLAY resposta-de-reembolso
ELSE
resposta-de-reembolso “reembolso aprovado”
solicitaçao-de-cheque-de-reaxnbolao = “Favor pagar” +
ID-de-client. + saldo-atual
DISPLAY resposta-de-reembolso
DISPLAY solicitaçao-de-cheque-de-reembolso
WRITE zero em saldo-atual em registro cliente
WRITE data-atual + ID-de-cliante + saldo-atual em REEMBOLSOS
ENDIF
767
ENDIF
END
PROa.SSO 2.8: ESTABELEX NOVO LIMITE DE C

Página 508 de 584
BEGI N
FIND cliente em CLIENTES com ID-de-cliente coincidente IF registro não encontrado
resposta-a-limite-de-crédito “Cliente não existe”
ELSE
read registro cliente
IF novo-limite-de-crédito < O resposta-a-limite-de-crédito = “Limite de crédito inválido”
DISPLAY resposta-a-limite-de-crédito ELSE
resposta-a-limite-de-crédito “Novo limite de crédito OK”
DISPLAY resposta-a-limite-de-crédito REPLACE limite-de-crédito com novo-limite-de-crédito
WRITE registro cliente
ENDIF
ENDIF
END
PRO 2.9: ALT DETAI1 DE CLIENTE
BEGI N
FIND cliente em CLIENTES com ID-de-cliente coincidente
IF registro não encontrado resposta-a-alteração-de-cliente - “Cliente não existe”
DI SPLAY resposta-a-alteração-de-cliente
ELSE
read registro de cliente
REPLACE nome-de-cliente, nome-da-empresa, endereço-de-
cliente com nome-de-cliente, nome-da-empresa,
endereço-de-cliente em detalhes-de-cliente
resposta-a-alteração-de-cliente = “Alteração aceita”
DI SPLAY resposta-a-alteração-de-cliente
ENDIF
END
PflSSO 3.1: PRODUZIR RE DE CAD@
BEGI N
caixa = O
DO WHILE houver registros em DINHEIRO READ próximo registro dinheiro
768
DISPLAY dinheiro caixa - caixa + valor
END DO

Página 509 de 584
relatório-de-caixa - caixa
DI SPLAY relatório-de-caixa
END
PROCESSO 3.2: PRODUZIR RELATÓRIO DA RECEI DIÁRIA
BEGIN
total-diário - O
DO WHILE houver pedido em PEDIDOS com data-do-pedido = data-atual
READ próximo pedido com data-do-pedido = data-atual ADD número-da-fatura, nome-do-cliente,
nome-da- cpresa, total-do-pedido como uma nova linha em
relatório-da-receita-diária
ADD total-do-pedido a total-diário
END DO
ADD total-diário como uma nova linha em relatório-da- receita-diária
DISPLAY relatório-da-receita-diária
PROCESSO 3.3: PRODUZIR RELATÓRIO DA RECEI NSAL
receita-total O
total-da-devoluções O
total-de-crédito - O
DO WHILE houver pedido em PEDIDOS com data-do-pedido deste mês
ADD total-do-pedido a receita-total
END DO
DO WHILE houver devoluçao em DEVOLU( com data-da davoluç*o deste mês
ADD valor-da-devoluç a total-da-devoluções
END DO
DO WHILE houver créditos em CE com data-do-crédito
deste mês
ADD valor-do-crédito a total-de-crédito
END DO
relatório-da-receita-mensal = receita-total, total-da-
devoluções, total-da-crédito
DISPLAY relatório-da-receita-mensal
END
769
PROCZSSO 3.4: PRODUZIR RELATÕRIO TRI) DE DIREITOS

Página 510 de 584
BEGIN
DO WHILE houver livro em LIVROS
total-da-livros - O
receita-total = O
total-de-direitos - O
BF.AD próximo registro livro
DO WHILE houver pedido em PB com data-do-pedido deste trimestre
READ próximo registro deste pedido
DO WHILE houver itam-de-pedido em IT com numero-da-fatura igual a número-da-fatura no
registro pedido atual e código-de-livro igual a código-de-livro no registro livro atual READ itam-
da-pedido seguinte
ADD quantidade-pedida a total-de-livros
esta-receita - quantidade-pedida * preço-unitário * das conto
ADD esta-receita a receita-total
ADD (esta-receita * taxa-da-direitos) a total-de-
direitos
APPEND ID-de-cliante, noma-da-cliente, número-da- fatura, esta-receita, (esta-receita * taxa-de-
direitos) a próxima linha de relatório- trimestral-de-direitos
END DO
END DO
DO WHILE houver crédito em tDITOS com código-de- livro igual a código-de-livro no registro
livro atual e data-do-crédito deste trimestre READ crédito seguinte
SUBTRACT quantidade-da-livros-do-crédito de total- de-livros
SUBTRACT valor-de-crédito de receita-total
SUBTRACT (valor-do-crédito * taxa-de-direitos)
de total-de-direitos
APPEND ID-de-cliente, nome-de-cliente, número-da- fatura, valor-do-crédito, (valor-do-crédito *
taxa-de-direitos) à próxima linha de relatório- trimestral-da-direitos
END DO
DO WHILE houver devolução em DEVOLUÇÕES com código-da- livro igual a código-de-livro
no registro livro atual e data-da-devolução deste trimestre
READ devolução seguinte
ST.JBTRACT quantidade-devolvida de total -de-livros SUBTBACT valor-da-devolução de receita-
total SUBTRACT (valor-da-devolução * taxa-da-direitos)
770

Página 511 de 584
de total-de-direitos
APPEND ID-de-cliente, nome-de-cliente, número-da fatura, valor-da-davoluçào, (valor-da-
davoluçào * taxa-de-direitos) à próxima linha de relatório trimestral-da-direito3
END DO
APPEND total-de-livros, receita-total, total-de-
direitos à próxima linha de rai.atório-trixneatral d-direitos
END DO
DISPLAY relatório-trimeetral-da-direitos
END
PROCESSO 3.5: PRODUZIR RELATÓRIO DE INVENT
BEGIN
REPEAT UNTIL não haja livro em LIVROS READ próximo livro em LIVROS total-de-inventário
O
REPEAT UNTIL não haja iten-de-inventário em ITENS-DE INVENT com código-de-livro igual a
código-de-
livro em livro
ADD quantidade-da-inventário a total-de-inventário
ADD ID-de-dapósito, código-de-livro, quantidade-de- inventário à próxima linha de relatório-da-
inventário
END REPEAT
ADD total-de-inventário à próxima linha de relatório- da-inventário
END REPEAT
END
PRO 3.6: PP RELATÓRIO DE COMISSÕES DE VENDAS
BEGIN
DO WHILE houver vendedor em VE2 REPJD próximo registro vendedor comissão-de-vendedor -
O
DO WHILE houver pedido em PEDIDOS
com ID-de-vendedor igual a ID-de-vandedor em vendedor e com data-do-pedido deste mês
READ registro pedido seguinte
comissão taxa-de-comissão * total-do-pedido ADD comissão a comissão-de-vendedor
APPEND ID-de-vendedor, número-da-fatura, comissão à
próxima linha de relatório-da-comissões
END DO
APPEND comissão-de-vendedor à próxima linha de

Página 512 de 584
771
relatório-d.-conu
END DO
END
PRO(ZSSO 3.7: PRODUZIR DECLARAÇÕES
BEGIN
REPEAT tJNTIL não haja cliente em CLIENTES READ próximo registro cliente
novo-saldo - saido-atual
DO WHILE não haja pedido em P com ID-d-cliente
ID-de-cliente no registro cliente atual e data-do-
pedido posterior a data-do-saldo-atual
READ registro pedido seguinte
ADD total-do-pedido a novo-saldo
APPEND pedido à próxima linha de declaração
END DO
DO WHILE houver pagamento em PAGAZ. com
ID-de-cliente - ID-de-cliente no registro cliente atual e data-do-pagamento posterior a
data-do-saldo-atual
READ registro pagamento seguinte
SUBTRACT valor-total de novo-saldo
IPPEND pagamento à próxima linha de declaração
ENDDO
DO W}iILE houver reembolso em REEMBOLSOS com
ID-de-cliente = ID-de-cliante no registro cliente atual e data-do-reembolso posterior a data-do-
saldo-atual
PEAD próximo registro reembolso
ADD valor-do-reembolso a novo-saldo
APPEND reembolso à próxima linha de declaração
END DO
DO WHILE houver crédito em CR com ID-da-cliente
ID-de-cliente no registro cliente atual e
data-do-crédito posterior a data-do-saldo-atual
READ próximo registro crédito
SUBTRACT valor-do-crédito de novo-saldo

Página 513 de 584
APPEND crédito à próxima linha de declaração
END DO
DO WHILE houver devolução em DEVOLUÇÕES com
ID-da-cliente = ID-de-cliente no registro cliente
atual e data-da-devolução posterior a data-do-saldo atual
REAl) próximo registro devolução
SUBTRACT valor-da-devolução de novo-saldo
APPEND pagamento à próxima linha de declaração
END DO
772
APPEND novo-saldo à próxima linha de declaração
DISPLAY declaração
SET data-do-saldo-atual no registro pedido atual na data atual
SET saldo-atual no registro pedido atual em novo-saldo
END REPEAT
END
PR 3.8: PRODUZIR REIÂT( DE CON’ A RECEBER
BEGIN
REPEAT UNTIL nâo haja cliente em .IENTES PEAD próximo registro cliente novo-saldo saldo-
atual
DO WHILE houver pedido em PEDIDOS com ID-da-clienta =
ID-da---cliente no registro cliente atual e data-do-
pedido posterior a data-do-saldo-atual
READ próximo registro pedido
ADD total-do-pedido a novo-saldo END DO
DO WHILE houver pagamento em PP. com ID-de-oliente = ID-da-cliante no registro cliente atual
e data-do-pagamento posterior a data-do-saldo- atual
READ próximo registro pagamento
SUBTRACT valor-total de novo-saldo END DO
DO WHILE houver reembolso em REEMBOLSOS com ID-de-clienta ID-de-cliente no registro
cliente atual e data-da-reembolso posterior a data-do- saldo-atual
READ próximo registro reembolso ADD valor-do-reembolso a novo-saldo
END DO
DO WHILE houver crédito em CRÉDITOS com ID-de-cliente =
ID-de--cliente no registro cliente atual e data-do-

Página 514 de 584
crédito posterior a data-do-saldo-atual
READ próximo registro crédito
SUBTRACT valor-do-crédito de novo-saldo
APPEND crédito à próxima linha de declaração
-END DO
O WHILE houver devolução em DEVOLU com ID-da-cliente = ID-da-cliente no registro cliente
atual e data-de-devolução posterior a data-do- saldo-atual
REAl) próximo registro devolução SUBTRACT valor-da-devolução de novo-saldo
END DO
773
END BEPEAT
APPEND ID-da-cliente, novo-saldo â próxima linfla de
relatório-da-contas-a-receber
DI SPLAY relatório-da-contas-a--receber
END
PRO 4.1: RE CC71 DE c
REGI N
ACCEPT (da gráfica) ID-de-gráfica, cotação-de-gráfica
DISPLAY (à direção) ID-da-gráfica, cotação-de-gráfica
END
PRO 4.2: ESENTAR PEDIDO DE I
BEGI N
FIND livro em LIV com código-de-livro igual a códigc da-livro em instruçôes-de-pedido-da-
impras são
resposta-a-pedido-da-impressão - “Livro não existe”
DI SPLAY resposta-a-pedido-de-impressão
ELSE
IF quantidada-a-iitprimir < O resposta-a-pedido-de-iitç - “Quantidade de impres5ão inválida”
DI SPLAY resposta-a-pedido-de-impressão ELSE
resposta-a-pedido-da-impressão - “Pedido de irnpress
aceito”
DI SPLAY resposta-a-pedido-da-impressão
SET quantidade-pedida de livro em quantidade-a-

Página 515 de 584
imprimir
SET data-da-disponibilidade de livro em data-de-
disponibilidade em instruções-da-pedido-de impres são
pedido-da-impressão = código-da-livro + quantidade-a
imprimir
DI SPLAY pedido-da-impressão, ID-de-gráfica
ENDIF
END 1 F
END
PRO( 4.3: REVISAR PEDIDO DE LIVROS
BEGI N
FIND livro em LIVI com c go-da-livro igual a códigc da-livro em pedido-de-impressão-revisto
774
rosposta-a-pedido-do-in “Livro não
existe”
DISPLAY resposta-a-pedido-da-impress&o-revisto
ELSE
Read registro livro
Set quantidad. -podida n quant idada-revi ata
Set data-da-disponibilidade em data-revi sta
Write registro livro em LIV
resposta -a-pedido-ixrçres são-revisto - “Pedido de impressão revisto OK”
DISPLAY resposta-a-podido-da-impressão-revisto
ENDIF
END
PRO 4.4: P FATURA DE .FICA
BEGIN
FIND livro em LIVROS com código-de-livro coincidindo com código-de-livro em fatura-de-
gráfica
resposta-a-fatura-de-gráfica = “Não há pedidos
pendentes desse livro”

Página 516 de 584
DISPLAY resposta-a-fatura-de-gráfica
ELSE
DISPLAY fatura-de--gráfica (à direção para aprovação)
ACCEPT autorização-da-fatura-do-gráfica
IF autorização-da-fatura-da-gráfica “SIM”
resposta-a-fatura-de-gráfica - “Fatura rejeitada;
favor consultar a direção”
DISPLAY resposta-a-fatura-da-gráfica
ELSE
resposta-a-fatura-da-gráfica “Fatura aceita” DISPLAY resposta-a-fatura-do-gráfica
fatura-do-gráfica-aprovada = fatura-de-gráfica DISPLAY fatura-da-gráfica-aprovada
ENDIF
ENDIF
END
PPO( 4.5: SOLICITP.R COTAÇÀO DE URÁFICA
BEGI N
DO WHIIE houver gráfica em (i READ próximo registro gráfica
IF gráfica igual a qualquer ID-de-gráfica na entrada
desse processo
solicitação-da-cotação = código-da-livro +
775
(quantidade)
DI SPLAY solicitação-da-cotação ENDIF
ENDDO
END
PRO 5: CRIAR NOVO REGISTRO DE LIVRO
BEGIN
DISPLAY (à direção) titulo-de-livro + solicitação-da- código-de-livro
ACCEPT (da direção) código-da-livro
DISPLAY (para aquisições) titulo-da-livro + solicitaçãc da-taxa-da-direitos
ACCEPT (de aquisições) taxa-da-direitos
DISPLAY (à comercialização) titulo-da-livro + solicitação-da-preço-unitário
ACCEPT (da comercialização) preço-unitário
livro = código-de-livro + titulo-da-livro + ID-da-autor taxa-da-direitos

Página 517 de 584
SET total-em-estoque em zero
SET data-de-disponibilidad, em data-em-estoque
APPEND livro em LIVROS
END
PRO 6.1: PRODUZIR ETIQUETAS POSTAIS
BEGIN
SORT CLIENTES por código-postal em etiquetas-postais
DISPLAY etiquetas-postais
END
PRO 6.2: PRODUZIR ESTATtSTICAS DE VENDAS
BEGI N
REPEAT UNTIL não haja livro em LIVROS receita-da-vendas = O
devoluções-da -vendas O
créditos-da-vendas = O
DO WHILE houver pedido em P com data-do-pedido posterior a data-da-vendas
DO WHILE houver item-d.-pedido no registro pedido atual com código-de-livro código-da-livro
no
registro livro atual
READ próximo item-da-pedido
ADD (quantidade-pedida * preço-unitário * dasconto a receita-da-vendas
776
END DO END DO
DO WHILE houver devolução em DEVOLU( com data-da- devolução posterior a data-de-vendas e
código-de- livro - oódigo-d.-livro no registro livro atual
ADD valor-da-devolução a devoluções-de-vendas
END DO
DO WHILE houver crédito em CRÉDITO com data-do-crédito posterior a data-de-vendas e
código-de-livro =
código-de-livro no registro livro atual
ADD valor-do-crédito a créditos-de-vendas
END DO
APPEND código-de-livro, receita-da-vendas, devoluções-
de-vendas, créditos-de-vendas á próxima linha de
estatisticas-de-vendas

Página 518 de 584
END REPEAT
DISPLAY estatisticas-da-vendas
PRC 6.3: PRCOUZIR DATA EM ESTOQUE
BEGIN
FIND LIVRO em LIVROS com código-de-livro coincidente
IF registro n encontrado
resposta-de-em-estoque = “Livro não existe”
DI SPLAY resposta-de-em-estoque
ELSE
READ registro livro
IF data-em-estoque = “nulo”
resposta-de-em-estoque = “Não há remessas esperadas”
ELSE
resposta-da-em-estoque = data-da-disponibilidade
DISPLAY resposta-da-em-estoque
ENDIF
ENDIF
END
PRO(2SSO 6.4: REMOVER LIVRO
REGI N
FIND livro em LIVROS com código-de-livro co
resposta-a-ren = “Livro não existe”
DISPLAY resposta-a-remoção-da-livro
ELSE
READ registro livro
SET indicador-de-fora-da-impressão em SIM
777
resposta-a-re “Livro marcado como for de impressão”
DI SPLAY resposta-a-remoçÀo-da-livro
END 1 F
END
PRO 7.1: PR DOCUb DE R

Página 519 de 584
BEGIN
REPEAT UNTIL não haja depósito em D PEãO próximo registro depósito
*obs.: esta parte produz a lista de separação para o depósito*
PEPEAT UNTIL não haja livro em LIV
livros-a-separar = O
DO WHILE houver pedido em PEDIDOS com data-clo-pedid
= data-atual e ID-de-depósito coincidindo com
ID-de-depósito no registro depósito atual
DO WHILE houver itazn-de-padido com rum = número-da-fatura no registro pedido READ
próximo regi stro item-de-pedido ADD quantidade-pedida a livros-a-separar
END DO
END DO
APPEND titulo-de-livro, livros-a-separar à próxima
linha de documentos-da-remessa
END REPEAT
*obs.: esta parte produz as etiquetas_de_remessa* DO WHILE houver pedido em PEDIDOS com
data-do-pedido
data-atual e ID-de-depóeito = ID-de-depósito no registro depósito atual
APPEND nome-da-cliente, endereço-da-cliente, número- da-fatura à próxima linha de
documentos-de-remess
END DO
*obs.: esta parte produz uma cópia do pedido origina. para o depósito*
DO WHILE houver pedido em PEDIDOS com data-do-pedido data-atual e ID-de-dapósito = ID-
de-depósito no registro depósito atual
APPEND ID-da-cliante, data-do-pedido, despesas-da- remessa, imposto-sobre-vendas à próxima
linha de
documentos-de-remessa
PEPEAT UNTIL não haja itein-de-pedido em IT PEDIDO com numero-da-fatura igual a número-
da-
fatura no registro pedido atual
778
APPEND item-da-podido á próxima linha de

Página 520 de 584
documentos -da-rQmassa
END REPEAT
END DO
END REPEAT
END
PRO 7.2: REGISTE7 REMESSA DE ÁFICA
BEGIN
FIND livro em LIV1 com titulo-da-livro coincidente
IF registro nâo encontrado notificação-da-remessa = “Livro não existe”
DISPLAY notificação-de-remessa
ELSE
notificação-da-remessa “Recebido da gráfica” +
código-da-livro + quantidade-recebida
DISPLAY notificação-da-remessa
READ registro livro
ADD quantidade-recebida a total-em--estoque
SET qyantidada-padida em zero
WRITE registro livro em LIV
READ item-da-inventário em ITENS-DE-INVENTÁRIO com ID-da-dapósito = “YONKERS” e
código-da--livro
coincidente
ADD quantidade-recebida a quantidada-de-inventário
ENDIF
END
PRC 7.3: REGI STRJ DEVOLUÇÕES DE LIVROS DE CLIENTES
BEGIN
FIND cliente em CLIENTES com ID-da-clionta coincidindo com ID-de-cliente em informações-
de-devoluções-de- livros ou com nu-da-cliente coincidindo com r client. em informações-de-
devoluções-da-livros
instruções-de-devolução “Cliente não identificado;
• aceitar livros, mesmo assim”
• DISPLAY instruções-da-devolução ELSE
FIND davolução-autorizada em DEVOLUÇÕES-AUTORIZADAS com

Página 521 de 584
aut-da-davolução-# igual a aut-de-devolução-# em
informações-da-devoluções-de-livros
instruções-da-devolução = “Devolução não autorizada;
favor remeter de volta”
779
DI SPL instruçÕes-da-davoluç autorizaçao-da-davoluç*o-da-livro “Esta devolução
não está autorizada”
DISPLAY (para o cliente) autorizaçào-da-davoluçào-de livro
EXI T
ELSE
instruções-da-devolução “Devolução autorizada” DI SPLAY instruções-da-devolução autorização-
da-devolução-da--livro = “Esta devolução
está autorizada”
ENDIF
ENDIF
REPEAT UNTIL não haja código-da-livro em irifonsações-da devoluções-da-livros
FIND itam-da-inventário em ITENS-DE-INVENTÁRI0 com ID-da-dapósito coincidente e com
código-da-livro igual a código-da-livro em informações-da-devoluções- da-livros
instruções-da-devolução = “Livro não existe”
DI SPLAY instruções-de-devolução
ELSE
READ registro item-da-inventário
ADD quantidade-devolvida a quantidade-da-inventário
FIND livro em LIV com ID-da-livro coincidente
READ registro livro
ADD quantidade -devolvida a total-em-estoque
WRITE registro livro END 1 F
END REPEAT
APPEND informaçôas-da-devoluções -da-livros em DEVOLUÇÕES
END
PROCESSO 7.4: REGISTRAR INVENTÁRIO FfSICO

Página 522 de 584
BEGIN
FIND depósito em D com ID-de-depósito coincidente
IF registro não encontrado reaposta-a-inv-fisico “Depósito não existe”
DISPLAY reaposta-a-inv-fisico
ELSE
PEPF.AT tJNTIL não haja detalhe-da-inventário em
contagem-de-inventário
FIND item-de-invantário em ITENS-DE-INVENTÁRIO com
ID-da-dapósito e código-da-livro coincidentes
780
resposta-a-inv-fisico = “Código de livro inválido”
+ DISPLAY resposta-a-inv-fisico ELSE
dif quantidade-de-inventário - contagem-fisica SET quantidade-da-inventário em contagem-fisica
FIND livro em LIVROS com código-de--livro
coincidente
READ registro livro
SUBTRACT dif de total-em-estoque
DO WHILE houver pedido em PEDIDOS com data-do- pedido posterior a na-data e com ID-de-
dapósito coincidente
REJ registro pedido
DO WHILE houver itam-de-pedido em ITENS-DE PEDIDO com código-de-livro = código-de-
livro em detalhe-da-inventário e número-da-fatura
= número-da-fatura em pedido READ item-da-pedido SUBTRACT quantidade-pedida da
quantidade-de-
inventário
SUBTRACT quantidade-pedida de total-em-
estoque
END DO
END DO
WRITE registro item-de-inventário
WRITE registro livro ENDIF
END REPEAT
ENDIF
END

Página 523 de 584
PRO( 7.5: REGISTRAR R REAL
BEGIN
FIND pedido em PEDIDOS com numero-da-fatura coincidente
IF registro não encontrado resposta-de-remessa = “Pedido não encontrado”
DISPLAY resposta-da-remessa
ELSE
PEAD registro pedido
SET data-da-remessa em data-atual
WRITE registro pedido
ENDIF
END
781
PRO 7.6: RESPONDER A FPILTA DE ESTOQUE
BEGI N
FIND livro em LIVROS com titulo-da-livro coincidente
IF registro não encontrado resposta-a-fora-da-estoque = “Livro não existe”
DISPLAY resposta-a-fora-de-estoque
ELSE
READ registro livro para obter código-da--livro
FIND itein-de-inventário em ITENS-DE-INVENT1 com
ID-de-dapósito coincidente e código-da-livro
coincidente
resposta-a-fora-de-estoque = “Erro: item de
inventário não encontrado”
ELSE
READ item-da-invontário
SET quantidade-de-inventário em zero
WRITE item-de-invantário
resposta-a-fora-de-estoque “Mensagem de falta de
estoque recebida”
ENDIF
END 1 F
END

Página 524 de 584
PROCESSO 8.1: PRODUZIR RELA DE DIREITOS AUTORAIS
BEGIN
DO WHILE houver livro em LIVROS
total-de-livros O
receita-total = O
total-de-direitos = O
PEAD próximo registro livro
DO WHILE houver podido em P com data-do-pedido deste trimestre
READ próximo registro podido
DO WHILE houver itezu-de-podido em ITENS-DE-PEDIDO con numero-da-fatura igual a
número-da -fatura no registro podido atual e código-de-livro igual a código-de-livro no registro
livro atual
PEAD próximo itom-de-podido ADD quantidade-pedida a total-de-livros
esta-receita = quantidade-pedida * preço-unitário * desconto
ADD esta-receita a receita-total
ADD (esta-receita * taxa-de-direitos) a total-de-
direitos
END DO
END DO
782
DO WHILE houver crédito em ÉDITOS com código-da-livro igual a código-da-livro no registro
livro atual e data-do-crédito deste trimestre
READ próximo crédito
SUBTRACT quantidade-da-livros-do-crédito de total-de- livros
SUBTRACT val.or-do-crédito de receita-total
SUBTRACT (valor-do-crédito * taxa-da-direitos) de total-de-direitos
END DO
DO WHILE houver devolução em DEVOLUÇÕES com código-da- livro igual a código-da-livro
no registro livro atual e data-da-devolução deste trimestre
RFJ’.D próximo registro devolução
SUBTRACT quantidade-devolvida de total-de--livros
SUBTRACT valor-da-devolução de receita-total
SUBTPACT (valor-da-devolução * taxa-da-direitos) de total-de-direitos
END DO
APPEND total-de-livros, receita-total, total-de- direitos à próxima linha de relatÓrio-da-direitos

Página 525 de 584
autorais
END DO
DISPLAY relatório-da-direitos-autorais
END
PRO 8.2: INFORMAR CONTABILIDADE DE ADLAJ DE
DIREITOS
BEGIN
FINO autor em AUTORES com ID-da-autor igual a 10-da-autor
em solicitação-da-adiantamento-da-direitos
resposta-de-adiantamento = “Autor não existe”
DISPLAY resposta-da-adiantamento
ELSE
FINO livro em LIV1 com código-da-livro igual a
código-da-livro em solicitação-da-adiantamento-de-
direitos
• IF registro não encontrado
• resposta-da-adiantamento “Livro não existe”
DISPLAY resposta-da-adiantamento
ELSE
sóli zação-da-adiantamento =
solicitação-da-adiantamento-de-direitos
DISPIAY (para a direção) solicitação-de-autorização-
da-adiantamento
ACCEPT (da direção) resposta-da-autorização-de-
783
adiantamento
IF resposta-de_autorização -de = “Sim” rasposta-de-adjan = “Adiantamento aprovado DI SPLAY
resposta-d.-adjant
-
DISPLAY (para a Contabilidade) solicitação-de Cheque-da-adiantamento
PEAD registro autor
ADD valor-do-adjant a saldo-da-direitos
WRITE registro autor ELSE

Página 526 de 584
reaposta-da-adja “Adiantamento negado”
DISPLAY reaposta-da-adiant
END 1 F
ENDIF
ENDIF
END
PRO 8.3: ALT DETM DE AUTOR
BEGI N
FIND autor em AUTORES com ID-de-autor coincidente
WRITE detalhes-de-autor em autor
END 1 E’
END
784
NOTAS
Entrementes, as atividades de processamento de informações da Prentice-Hall estão subordinadas à
sua nova empresa proprietária, Simon & Schuster que, por sua vez, faz parte de uma empresa ainda
maior, a Gulf + Western, o que serve para demonstrar que os sistemas são quase sempre parte de
sistemas maiores.
2 Quando investigamos, descobrimos que a Supermarket Products estava localizada na periferia da
cidade de Nova lorque e ocupava- se principalmente da importação de bananas da Guatemala. Não
entendemos o que isso tinha a ver com computadores nem por que o estado decidiu que nosso
nome poderia prejudicar a pobre Supermarket Products, mas resolvemos não enfrentar a
burocracia.
3 O UNIX, naturalmente, já não é mais tão misterioso agora, mas, em meados dos anos 70,
dificilmente alguém estranho aos Laboratórios Beli e a algumas universidades já teriam ouvido
falar nele. Nem eu, nem a maior parte de meus colegas da YOURDON estávamos tão prescientes:
nós devemos essa decisão, que mais tarde viemos a muito apreciar, à insistência do Dr. P. J.
Plauger, que veio para a empresa, proveniente da Bell Labs em 1975. Plauger é amplamente
conhecido por seus livros cm co-autoria com Brian Kernighan, como The Elements of Programmin
Style (Reading, Mass.:
Addison-Wesley, 1973) e Software Tools (Nova lorque: McGraw- Hill, 1976).
4 A questão dos inventários separados, e vendas de escritórios sepa rados, começava a assomar no
horizonte como um problema cada vez maior. Cada um dos diversos escritórios da YOURDON
insistia na necessidade de ter um pequeno estoque local para atender os clientes eventuais que
desejassem poder adquirir um livro imedia tamente, em vez de terem de aguardar vários dias (ou
semanas) por uma remessa do Quartel General da Galáxia, O escritório cana dense reclamava a
necessidade de sua própria estrutura de preços (isto é, preços estabelecidos em dólares canadenses,

Página 527 de 584
em vez de dólares americanos) e sua própria campanha publicitária para quistar o mercado
canadense de forma diferente em relação ao mercado americano. Em alguns casos, os escritórios
remotos sim plesmente entregavam o livro ao cliente e solicitavam ao escritório
• central cm Nova lorque que gerasse a fatura. Em outros casos, o cliente pagava o livro à vista, e
solicitava recibo. As vendas do escritório londrino representavam cerca de 10% da receita total da
YOURDON Press, enquanto as dos demais escritórios respondiam por menos de 1% da receita
total da empresa.
785
L
G
ESTUDO DE CASO:
O PROBLEMA
DO ELEVA1
G. 1 INTRODUÇÃO
Este apêndice mostra o modelo essencial para um escalonador e controlador de elevadores. Seu
principal objetivo é ilustrar o uso dos modelos da análise estruturada para sistemas de tempo real;
você verá exemplos de fluxos de controle, de processos de controle e de diagra mas de transições
de estado que normalmente não seriam utilizados em uni sistema comercial.
Na próxima seção é apresentada uma descrição narrativa do pro blema. Em seguida vêm os vários
diagramas que compõem o modelo essencial, o dicionário de dados e as especificações de
processos. Obser ve que a maioria das especificações de processos utiliza a abordagem pré-
condição/pós-condição discutida no capítuL3 11.
O problema dos elevadores foi usado em um programa educacio nal patrocinado pela divisão da
ACM em Washington, D. C. em 1986. Os modelos aqui apresentados foram desenvolvidos
originalmente por Dennis Stipe, na época na YOURDON Inc. Os diagramas de fluxo de dados e o
dicionário de dados foram produzidos em um computador Macintosh II com o MacBubbles da
StarSys, Inc.: os diagramas de transi ções de estado foram produzidos com o MacDraw.
É importante notar como os diagramas deste capítulo são diferentes dos diagramas do apêndice E,
que foram produzidos pelo Design da Meta Software. MacBubbles é um produto CASE
especificamente prepa rado para desenhar diagramas de fluxo de dados (com equilíbrio entre
diagramas pais e filhos etc.). I)esign é um programa de desenho de emprego geral orientado para o
objeto, que pode ser utilizado para desenhar fluxogramas, diagramas de fluxo de dados e
virtualmente qualquer outro diagrama de software. Sob o ponto de vista da estética, os diagramas
produzidos pelos dois programas são muito diferentes; Penso que os editores que produziram este
livro prefeririam um
787
confiável artista humano a ambos os pacotes. Como foi dito no capítu lo 9, o estilo e formato de
diagramas dc fluxo dc dados pode ser uma questão sensível para muitos usuários; quando você
comparar os apêndices F e G você verá porquê.

Página 528 de 584
G.2 UMA DESCRIÇÃO NARRATIVA
O requisito geral é projetar e implementar um programa para esca lonar e controlar quatro
elevadores dc um edificio de 40 andares. Os elevadores serão usados para transportar pessoas entre
os andares na forma convencional.
Eficiência. O programa deve escalonar os elevadores de maneira eficiente e racional. Por exemplo,
se alguém chamar um elevador aper tando o botão de descida no quarto andar, o primeiro elevador
que passar descendo pelo quarto andar deve parar para embarcar o(s) passageiro(s). Por outro lado,
se um elevador estiver sem passageiros (sem chamadas pendentes) deve permanecer parado no
último andar por onde passou até que seja novamente solicitado. Um elevador não deve inverter o
sentido de seu movimento até que os passageiros que quiserem transitar no sentido atual tenham
atingido seus respectivos destinos (como veremos adiante, o programa não tem como saber quan
tos pas.sageíros realmente estão no elevador; ele só tem informações sobre os botões de destino
que foram apertados para um determinado elevador. Por exemplo, se algum passageiro nocivo e
anti-social tomar o elevador no primeiro andar e apertar os botões do quarto, quinto e vigésimo
andares, o programa fará com que o elevador ande e pare no quarto, no quinto e no vigésimo andar.
O computador e o programa não têm informações sobre os embarques e desembarques reais de
passagei ros). Um elevador que esteja com a lotação esgotada não deve atender a qualquer novo
chamado (existe um sensor de excesso dc peso para cada elevador. O computador e o programa
podem interrogar esses sensores).
Botão de destino: Cada elevador possui em seu interior um painel contendo 40 botões, um botão
para cada andar, marcados com os núme ros dos andares (1 a 40). Esses boties de destino podem
ser iluminados por sinais enviados do computador para o painel. Quando um passagei ro pressiona
um botão de destino ainda não iluminado, o circuito por trás do painel envia uma interrupção ao
computador (há uma interrupção separada para cada elevador). Quando o computador rece be um
desses sinais de interrupção (vetorizados), o programa lê os adequados registradores de entradas dc
oito hits mapeados na memória
788
(um para cada interrupção, portanto um para cada elevador) que contêm o número do andar
correspondente ao botão dc destino que causou a interrupção. Naturalmente, o circuito por trás do
painel escreve o número do andar no apropriado registrador de entrada mapeado na memória
quando ele provoca a interrupção vetorizada (como existem 40 andares nesta aplicação, somente os
seis primeiros bits de cada re gistrador de entrada serão utilizados pela implementação; porém o
hardware suportaria um edifício com até 256 andares).
Luzes dos botões de destino: Como já foi dito, os botões de destino podem ser iluminados (por
lâmpadas atrás dos painéis). Quando a rotina de serviço de interrupções do programa recebe uma
interrupção de bo tão de destino, ela deve remeter um sinal para que o painel adequado ilumine
aquele botão. Esse sinal é enviado pelo carregamento, feito pelo programa, do número do botão no
adequado registrador de saída ma peado na memória (existe um registrador desse tipo para cada
elevador). A iluminação de um botão informa ao(s) passageiro(s) que o sistema já anotou o pedido
e impede também outras interrupções causadas por novos (impacientes?) acionamentos do botão.
Quando o controlador pára um elevador em um andar, ele deve enviar um sinal para o painel do seu
botão de destino para desligar o botão de destino relativo àquele andar.

Página 529 de 584
Sensores de andar: Existe uma chave sensora de andar para cada andar de cada poço de elevador.
Quando um elevador está a oito pole gadas de um andar, uma roda do elevador atinge a chave
daquele andar e envia uma interrupção ao computador (existe uma interrupção separa da para o
conjunto de chaves em cada poço de elevador. Quando o elevador recebe uma dessas interrupções
(vetorizadas), o programa lê o adequado registrador de entrada de oito bits mapeado na memória
(exis te um para cada interrupção, portanto um para cada elevador) que contém o número do andar
correspondente à chave sensora de andar que provocou a interrupção.
Luzes de chegada. O interior de cada elevador contém um painel com um indicador luminoso para
cada número de andar. Esse painel localiza-se logo acima das portas. Seu objetivo é informar aos
passagei ros do elevador o número do andar ao qual o elevador está chegando (e no qual ele poderá
parar). O programa deve iluminar o indicador de um andar quando chegar a esse andar e apagá-lo
quando sair desse andar ou chegar a outro andar, O sinal é remetido pelo carregamento, pelo
programa, do número do indicador do andar no adequado registrador de saída mapeado na
memória (há um registrador para cada elevador).
789
Botões de chamada: Cada andar du edifido possui um painel q contém botões de chamada. Cada
andar, excetuando o térreo (P andar e o último (4 andar) apresenta um painel contendo dois botões
dc chamada, um com a indicação SOBE e o outro com a indicação 1)ESCE. O painel de chamada
do andar térreo tem apenas o botão SOBE e c último andar tem apenas o botão DESCE. Assim,
existem 78 botões dc chamada no total, 39 botões SOBE e 39 botões I)ESCE. As pessoas aper tam
esses botões para chamar um elevador (é claro que uma pessoa não pode chamar um determinado
elevador. O escalonador decide qual ele vador deverá atender a um chamado). Os boiões dc
chamada podem ser iluminados por sinais enviados do computador para o painel. Quando um
passageiro pressiona um botão de chamada ainda não iluminado, o circuito por trás do painel
remete uma interrupção vetorizada para o computador (há uma interrupção para os botões SOBE e
outra para os botões DESCE). Quando o computador recebe uma dessas duas inter rupÇÕeS
(vetorizadas), o programa lê o adequado registrador de entrada de oito bits mapeado na memória
que contém o número do andar cor respondente ao botão de chamada que provocou a interrupção.
Natural mente, o circuito por trás do painel escreve o número do andar no adequado registrador de
entrada mapeado na memória quando ele causa a interrupção vetorizada.
Luzes dos botões de chamada: Os botões de chamada podem ser iluminados (por lâmpadas atrás do
painel). Quando a rotina de serviço de interrupções do botão de chamada recebe uma interrupção
vetoriza da de um botão SOBE ou DESCE, ela deve enviar um sinal ao painel apropriado para
iluminar o boião adequado. Esse sinal é remetido pelo carregamento, pelo programa, do número do
botão no adequado regis trador de saída mapeado na memória, um para os botões SOBE e outro
para os botões DESCE. A iluminação de um botão informa ao(s) passageiro(s) que o sistema já
anotou o pedido e impede também outras interrupções causadas por novos acionamentos do botão.
Quando o controlador pára um elevador em um andar, ele deve enviar um sinal para o painel do
botão de chamada do andar para desligar o botão (SOBE ou DESCE) adequado para aquele andar.
Controles de motor de elevador (Sobe, Desce, Pára): Existe uma palavra de controle mapeada na
memória para cada motor de elevador. O bit O dessa palavra comanda a subida do elevador, o bit 1
comanda a descida e o bit 2 comanda a parada do elevador no andar cuja chave sensora esteja

Página 530 de 584
fechada. O mecanismo do elevador não obedece a qual quer comando inadequado ou perigoso. Se
não houver uma chave sen sora de andar fechada quando o compulador emitir um sinal de parada,
o mecanismo do elevador vai ignorar, esse sinal até que uma chave
790
sensora de andar seja fechada. O programa não tem de se preocupar com o controle das portas de
um elevador ou parar o elevador exata mente no nível (base) de um andar, O fabricante do elevador
utiliza chaves, relés, circuitos e engrenagens de segurança convencionais para aquelas finalida’des
de forma que ele pode garantir a segurança dos elevadores independentemente do controlador do
computador. Por exemplo, se o computador emitir um comando de parada para um eleva dor
quando este está a oito polegadas de um piso (de modo que a chave sensora de andar esteja
fechada), o mecanismo convencional, aprovado, pára e nivela o elevador naquele andar, abre as
portas e as segura ade quadamente, e em seguida as fecha. Se o computador emitir um coman do de
subida ou descida durante esse período (enquanto a porta está aberta, por exemplo), o mecanismo
do fabricante ignora esse comando até que as condições para a movimentação sejam satisfeitas
(dessa for ma, é seguro que o computador emita um comando dc subida ou desci da enquanto a
porta do elevador esteja aberta). Uma condição para o movimento de um elevador é que o boião
deparada não seja apertado. O painel de boiões de destino de cada elevador contém um botão de
parada. Esse botão não leva ao computador. Sua única finalidade é segu rar um elevador em um
andar com as portas abertas enquanto esse elevador estiver parado no andar. Uma chave deparada
de emergência, vermelha, páça e prende o elevador no andar seguinte a que ele atin gir
independentemente da escala do computador. A chave vermelha também aciona um alarme audível.
Essa chave não está interligada ao computador.
Máquina alvo O escalonador e o controlador do elevador podem
ser implementados para qualquer microcomputador contemporâneo
que seja capaz de manipular esta aplicação.
791
Diagrama de Contexto
Modelo Essencial do Elevador
792
G.3 O MODELO ESSENCIAL ______
Sensor de Andar
- _J________
793
Diagrama de Contexto Expandido
Lista de Eventos
1. Passageiro emite chamada de subida.
2. Passageiro emite chamada de descida.
3. Elevador atinge andar da chamada.

Página 531 de 584
4. Elevador não disponível para chamadas.
5. Elevador torna-se disponível para chamadas.
6. Passageiro emite solicitação dc destino.
7. Elevador atinge destino solicitado.
8. Elevador chega a um andar.
9. Elevador abandona um andar.
10. Elevador não se movimenta (sai do serviço).
11. Elevador retorna ao serviço normal.
12. Elevador sobrecarregado.
13. Carga do elevador torna-se normal.
794
S escalonamentos-de.dest gil
2 tivar/desatjvar-s
i Controlar ‘ A
andar .ØJ Elevador -
‘
/• c
‘00
- 0l
/
Figura O: Escalonar e controlar elevador modelo essencial do elevador
solicitações
-
1%
lo.
,
795
Situações -de-e levador
% ‘e
Ordens-de-movimento Solicitações
Figura 1: Armazenar e exibir soliciiação
796
S
/

Página 532 de 584
Controlar atiVaId
1 ordemde r -
e\ - - lato
‘o
1<
‘3
g
‘-
o
o.
ordem-de-movimento
Figura 1.1: Gerenciar ordem de movi rnento
797
Ativar Armazenar Ordem de Movimento Ativar Exigir Ordem de Movimento
Chamada Inativa
Ordem de Movimento Introduzida Andar Atingic
Sinalizar Entrada de Movimento Recebida Disparar Lim
Chamada Coi
Figura 1.1.1; Controlar ordem de movimento
798
Ativar Armazenar Solicitação de Destino Ativar Exibir Solicitação de Destino
Destino Inativo
Solicitação de Destino Introduzida Andar Atingido
Sinalizar Solicitação de Disparar Limpar
Destino Recebida Destinos Completados
Figura 1.2.1: Controlar solicitação de destino
799
o 1_
1.2.1
• Controlar ativar!
‘ Solicitaçâo -
de Destino -
/ r
-

Página 533 de 584
Io_ s
i9Q.
1<
Ic •
1 -,
o
, 1
e
Solicitações-de-destino
Figura 1.2: Gerenciar solicita ção de destino
800
- ‘ ti
--
-- S
- sobr - -
- dest - - -
Figura 2: Co;1 rolar elevador
801
.. .‘í_
-
Figura 2.1: Gerenciar destino de elevador
802
Destino Inativo
Destinos Pendentes Recebidos Destino Final Atingido
Ativar Determinar Direção Desativar Determinar Direção
Solicitada Solicitada
Ativar Referenciar Chegada Sinalizar Escalonamento
a Andar de Destino Completado
Ativar Determinar Destino Desativas Gerenciar Chegada
Final a Andar
Desativar Determinar Destino
Final
Destinos Pendentes
Figura 2.1.1: Controlar destino

Página 534 de 584
803
Situaçóes.de-elevacjor
Figura 2.2: Gerenciar chegada a andar
804
escajonamentosdedestjno
IL
Limpar controle de subida do elevador
Limpar controle de descida do elevador
Ajustar controle de parada do elevador
Ativar monitorar chegada a andar
Ajustar estacionar
Ativar armazenar situação do elevador
ESTACIONADO
DESTINO SOBE
controle de parada do elevador Limpar estacionar-elevador
controle de subida do elevador ir monitorar evento do elevador
ESCALONAMENTO
DE DESTINO
COMPLETADO
Ajustar
estacionar-elevador
DESTINO DESCE
SUBINDO
ANDAR NÃO
NO ANDAR DESEJADO
Sinalizar andar atingido
Disparar determinar
andar desejad9
__ 1
DESTINO SOBE
Dispara determinar andar desejado
DEST. ATINGIDO
npar controle de bida do elevador ustar controle de rada do elevador sativar monitorar coto do
elevador,

Página 535 de 584
Limpar controle de parada do elevador
Limpar estacionar elevador
Ajustar controle de descida do elevador
Ativar monitorar movimento do elevador
[ DESCENDO
ANDAR NÃO
NO ANDAR DESEJADO
Sinalizar andar desejado
__ 1
DESTINO DESCE
INTERVALO DE MOVIMENTO
Limpar controle de parada do elevador Ajuslar controle de subida do elevador Ativar monitorar
movimento do elevador
AND. DEST. ATINGIDO
Limpar controle de descida do elevador Ajustar controle de parada do elevador Desativar
monitorar movimento do elevador
ITERVALO DE MOVIMENTO
nalizar fora de serviço nalizar reescalonar elevador
Limpar controle de
parada do elevador
Ajustar controle de
descida do elevador Ativar monitorar movimento do elevador
PARADO -1
NO ANDAR
Sinalizar do volta ao serviço
NO ANDAR
Sinalizar de volta ao serviço
FORA-DE-SERVIÇO-SOBE
Sinalizar fora de serviço Sinalizar escalonar elevador
Figura 2.2.1: Mover elevador para andar
FORA DE SERVIÇO-DESCE
805
Ordens-de-movimento
Solicitações-de..Oestino

Página 536 de 584
Figura 3: Escalonar elevador
806
Situações-de-elevador
o
5
Is
Ic
/
Figura 3.1: Gerenciar escalonamento de chamadas
807
Ordens-de-Movimento
%0
%
ões-de-Elevador
REESCALONAR ELEVADOR
Disparar limpar chamados
Disparar escalonar chamadas
Escalonamento Inativo
MOVIMENTO RECEBIDA - ELEVADOR NÃO DISPONÍVEL
Disparar escalonar chamadas Escalonamento de Chamadas Pendentes
- !scalonamento de Chamadas
ANDAR ATINGIDO
Disparar escalonar cha
ELEVADOR SELECIONADO
Sinalizar escalonamento de chamadas
pendentes
Figura 3.1.2: Controlar escalonamento de chamadas
808
3.2.1 %
g Controlar “ -
1 Escalonamento - -
. ) de Destino g
1 __________________
- -

Página 537 de 584
1
‘o
t
‘3
1
/
Solicitações-de-Destino
Escalonamentos-de-Destino
Situações-de-E levador
Figura 3.2: Gerenciar escalonamento de destinos
809
Inativo
SOLICITAÇÃO DE DESTINO
RECEBIDA ANDAR ATINGIDO
Disparar escalonar Disparar atualizar escaIoname
solicitação de destino de destinos
Sinalizar escalonamento de
destinos pendentes
Figura 3.2.1: Controlar escalonamento de destinos
810
DICIONÁRIO DE DADOS
DO
SISTEMA DE CONTROLE DE ELEVADORES
andar-atual = valores: 1-40
OBS. : número do andar onde um elevador está
andar-da-destino = valores: 1-40
OBS. : números do5 andares onde um elevador
deve parar
andar-desejado-alcançado
OBS.: sinal
andar-do-elevador = valores: 1-40
chamadas
OBS. : ***Entrada Gerada***
chamadas-pendantes valores: [ 1 off]

Página 538 de 584
controle-de-descida-da-elevador
OBS.: sinal para o hardware
controle-da-parada-da -elevador
OBS. : sinal para o hardware
controle-da-subida-da-elevador
OBS.: sinal para o hardware
descendo
OBS.: ***Entrada Gerada***
destino-desce
OBS.: sinal de que a direção solicitada e descer
destino-direção = [ destino-desce]
destino-pendente = valores: [
OBS.: indicação de que o elevador tem mais destinos além do andar atual
destino - sobe
811
destinos-pendantes = (chamadas-pendentes 1 destino- pendente 1 chamadas-pendentes +
destino-pendente]
OBS. : sinal de que existe um escalonamento
de destinos
di ração-da sce
direção-sobe
elevador-não-disponivel
OBS. : sinal de que um elevador não está
disponível para atender a uma chamada
avador- selecionado
OBS.: sinal de que um elevador foi escalado para uma chamada
escalonamento-da-destino = @número-do-elevadcr+ { andar-de- destino }+origem-da-solicitação
+dest inação-pendente
escalonam ntoa-de-d.stino = {escalonamento-de-destino}
estacionado
OBS.: sinal

Página 539 de 584
estado-da-elevador = (estacionado subindo 1 descendo 1 parado
1 fora-de-serviço]
fora-de-serviço
OBS.: sinal de que o elevador falhou em reagir ao comando de movimento
indicação-da-chamada = valores: 1-40
OBS. : indicação de números dos andares em
que um elevador está escalado para
parar
indicação-da-chegada valores: 1-40
OBS. : indicação do andar ao qual o elevador
chegou
dicação-da-destino = valores: 1-40
OBS. : indicação dos números dos andares
onde o elevador deve parar
812
no-andar
OBS. : sinal de que o elevador atingiu um
andar
núi = valores: 1-40
númQro-da-.1.vador = valores: 1-4
ord = @andar-do-elevador + [
direção-desce 1 direção-sobe + direção
-desce] + número-de-elevador
ordem-de-moviz
OBS.: sinal
ord.m-d. -movimento -recebida
OBS.: sinal
ordens-d = {ordem-de-movimento}
parado
reescalonar-elevador

Página 540 de 584
OBS. : sinal para iniciar o reescalonarnento
de chamadas para um elevador com
defeito
sjnal_de_controle_de_elevadorcontroledesUbidade- elevador+contro elevador+controle-
deparadade elevador
situações-de-elevador = {situação-de-elevador}
sobrecarga
OBS.: sinal do hardware
solicitação-de-destino = @núrnero-do-elevador+ [ andar
813
OBS.: sinal de que um passageiro introduzi solicitação
aolicitaç&o-d-d
OBS.: sinal de que a solicitação está pron ta para escalonamento
solicitaçio-origem = [ 1 andar-de-destino
chamada + andar-de-destino]
solicitaçao-r = ordem-de-movimento-recebida +
solicitação-de-destino-recebj
so].icitaçô8 ordens-de-movimento + solicitações-de
destino
soliCitações-de-destino { solicitaçào-de-destino}
situação-de-elevador = @número-de-elevador+estado-de
elevador+andar-atual
subindo
valores
814
L
Espeqficações de Processos
1.1.2 ARNAZEN7 ORDEM DE MOVIMENTO
Pré-condição
entrada-da-ordem-da-movimento ocorra
Pós-condição
entrada-de-ordem-de-movimento seja armazenada

Página 541 de 584
ordem-da-movimento-introduzida seja produzida
1.1.3 LIMPAR CHAMADA COMPLETADA
Pré-condição
Existe um n em situações-da- elevador que coincide com número-da-elevador- designado em
ordem-da--movimento
e
Existe um correspondente andar-atual em situações-de-elevador que coincide com número- de-
andar em ordens-da-movimento
Pós-condição
A entrada correspondente em ordem-de-movimento é
nula
1.1.4 EXIBIR ORDEM DE MOVIMENTO
Pré-condição
Nenhuma
Pós-condição
Que as ordens-de-movimento estejam exibidas
1.2.3 LIMPAR DESTINOS ATINGIDOS
Pré-condição
Existe um numero-de-elevador em situações-de- elevador que coincide com numero-de-elevador
em solicitações-de-destino
e
Existe um correspondente andar-atual em situações-de-elevador que coincide com numero- da-
andar em solicitações-de-destino
Pós-condição
A entrada correspondente em solicitações-de- destino é nula
1.2.4 EXIBIR SOLICITAÇÃO DE DESTINO
Pré-condição
Nenhuma
Pós-condição
Que as solicitações-da-destino estejam exibidas
815
2.1.2 DETERMINAR DESTINO FINAL
Pré-condição
Existe um numero-de-elevador em situações-de-
elevador que coincide com numero-de-elevador em

Página 542 de 584
escalonamentos-de-destino
e
Existe um correspondente andar-atual em
situações-da-elevador que coincide com andar-de-
destino em escalonamantos-de-deatino
e
destino-pendente correspondente = 0ff em
escalonamentos -da-destino
Pós-condição
destino-final-atingido seja produzido
2.1.3 DETERMINAR DIREÇÃO SOLICITADA
O termo local igual é um numero-de-elevador coincidente em escalonamantos -de-destino e
numero-de-elevador em situação-da-elevador
Pré-condição 1
igual existe e
Existe em escalonamentos-de-destino um andar-de- destino > andar-corrente em situação-de-
elevador
Pós-condição 1
destino-sobe seja produzido
Pré-condição 2 igual existe e
Existe em escalonamentos -de-destino um andar-de- destino < andar-corrente em situação-de-
elevador
Pós-condição 2
destino-desce seja produzido
2.2.2 MONITORAR CHEGADA A ANDAR Pré-condição 1
andar ocorra
Pós-condicão 1
indicação-de-chegada esteja limpa em relação a andar anterior
e
indicação-de-chegada seja produzida para andar corre spondente
e
no-andar seja produzido e
andar-atual seja atualizado em situações-de- elevador
816

Página 543 de 584
2.2.3 MONITORAR MOVIMENTO DE ELEVADOR
andar-atual é lido de situações-de-elevador
Pré-condição
passam-se 10 segundos sem que andar-atual se
modifique
Pós-condição
intervalo-da-movimento ocorre
2.2.4 ARMAZENAR SITUAÇÃO DE ELEVADOR
Pré-condição
que seja recebido um sinal de entrada
Pós-condição
estado-de-elevador seja atualizado em situação- da-elevador
2.2.5 DETERMINAR ANDAR DESEJADO
Pré-condição
Existe um numero-de-elevador em situações-da- elevador que coincide com número-da-elevador
em situações -da-da stino
e
Existe um correspondente andar-atual em situações-da-elevador que coincide com andar-da-
destino em escalonamentos-de-dastino
Pós-condição
andar-desejado-atingido seja produzido
3.1.1 ESCALONAR CHAMADAS
BEGIN
com ordem-de-movimento, situação-da-elevador e sobrecarga
DO WHILE elevador-selecionado não tenha sido sinalizado
Encontrar elevador mais próximo
IF elevador está se movendo na direção correta ou elevador está estacionado
IF elevador não está sobrecarregado introduza
ordem-da-movimento por número -de-elevador em
escalonamento-de-destino
ajuste solicitação-origem em chamada ou em
chamada + destino
ENDIF
IF destinação-pendente = off

Página 544 de 584
faça destinação-pendente = on
END 1 F
sinalize elevador-selecionado
ELSE
Encontre elevador mais próximo
817
END DO
IF nenhum elevador encontrado
Sinalize elevador não disponivel
ENDIF
END
3.1.3 LIMPAR DESTINOS CHAMADOS
Pré-condição
Existe um número-de-elevador em situações-da- elevador que coincide com número-da-elevador
em escalonamento. -de-destino
e
o correspondente estado-da-elevador = fora-de- serviço em situações-da-elevador
e
a correspondente solicitação-origem = chamada em escalonamentos-cie-dastino
Pós-condição
As entradas correspondentes de andar-da-destino
são nulas
3.2.2 ESCALONAR SOLICITAÇÃO DE DESTINO
Pré-condição
Nenhuma
Pós-condição
escalonamentos-de-dastino seja atualizado por
solicitações-de-destino coincidindo com número-
da-elevador
Faça solicitação-origem = destino ou chanada +
destino
IF destino-pendente = oU
Faça destino-pendente = off
ENDIF

Página 545 de 584
3.2.3 ATUALIZAR ESCALONAMENTO DE DESTINO Pré-condição 1
Existe um numero-da-elevador em situações-da- elevador que coincide com número-de-elevador
em escalonamento. -de-destino
e
Existe um correspondente andar-atual em situações-de-elevador que coincide com andar-de-
destino em escalonamento-de-destino
Pós-condição 1
a entrada correspondente de andar-de-destino é
nula
Pré-condição 2
mesma condição da pré-condição 1
818
e
nenhun outra correspondente entrada de andar- da-daatino esteja presente
Pós-condiçâo 2
a entrada correspondente de andar-da-destino é
nula
e
o correspondente daatino-pondonta seja ajustada
em off
819
ÍNDICE
A
Abordagem de modelagem clássica, 392-
97
fracasso da, 392-97
modelo físico atual, 392
modelo físico novo, 392-93
modelo lógico atual, 392
modelo lógico novo, 392
pressuposições, 395
Abordagem top-down
no modelo comportamental, 440-42
fenômeno dos seis analistas, 440-

Página 546 de 584
41
paralisação da análise, 440
subdivisão física arbitrária, 441
Ações, estados, 326
ADABAS sistema de gerenciamento de
bancos de dados, 247, 290
Ambiente, sistemas de tempo real, 31
Análise de benefícios, 633-36
benefícios estratégicos do novo sis tema, 636-37
benefícios táticos, 634-36
Análise de riscos, 641-43
Análise estruturada, 151-64, 581
advento das ferramentas automati zadas de análise, 157-59
backlog (demanda) de aplicações,
132-39
cálculos de custo/benefício, 623-44
caminhamentos, 543, 645-53
caminhamentos de análise, 646-53
ciclo devida da prototipação, 98,120-
24
ciclo de vida do projeto, 97-129
ciclo de vida do projeto estruturado,
109- 16
demanda (backlog) de aplicações,
132-39
desenho de formulários, 486-88
desenvolvimento de sistemas, 49-79, 13 1-50
diagramas de contexto, 4 16-17, 421- 28
diagramas de entidades-relaciona mentos(E-R),88-89, 156,246,289-
318, 400
diagramas de fluxo de dados (DFD), 84-87, 177-233, 246, 400
diagramas de transições de estado
(DTE), 28, 90, 91, 156, 215, 247, 3 19-36, 400
dicionário de dados (DD), 86, 235- 54, 400

Página 547 de 584
diretrizes para estimativas, 605-22
entrevistas, 655-68
especificações de processos, 86-87, 246, 253-87, 400
estudo de caso: a Yourdon Press,
67 1-785
ferramentas automatizadas, 157-59,
579-603
ferramentas de modelagem, 82-83,
167-74
fluxos, 181-87
futuro da, 563-76
casamento da IA e da análise es truturada, 571-72
conhecimento ampliado da aná lise de sistemas, 566-68
hardware de computadores, 572-
74
impacto dos desastres de manu tenção, 569-70
821
proliferação das ferramentas au tomatizadas, 568-69
impacto na estrutura organizaciona!,
530-31
interface humana, 473-91
lista de eventos, 4 17-20, 428-32, 679- 81, 794
manutenção das especificações, 553-
76
modelagem, 28, 82-95, 156
modelo ambiental, 399, 400, 4 14-32
modelo comportamental, 399, 400,
139-64
modelo de implementação do usuário, 29, 73, 361,395, 465-503
modelo essencial, 391,397-407,465- 66
modificações antigas na, 563-66 modificações na análise estruturada
clássica, 155-56
movimento em direção a, 153-55
projeto de sistemas, 507-25

Página 548 de 584
programação, 5 27-39
prototipação, uso da, 159-60
sistemas automatizados, 20-40
testes, 101-104, 530-31, 539-43
usuários, 50-60
Veja também tópicos específicos Analistas de sistemas
fornecedores de estações de trabalho,
584-85 papéis dos, 68-69
programação/testes e, 528-31 Apresentador, como personagem nos
caminhamentos, 650
Armazenamento de dados a longo prazo,
493
Auditores, 67
objetivo dos, 67
problemas do trabalho com, 67 Automatização
como problema da gerência do pro jeto, 384-86
de sistemas de processamento de informações, 20
B
Backlog, Veja Backlog de aplicações
Backlog de aplicações, 132-39
backlog desconhecido, 133
backlog invisível, 132
backlog visível, 132
redução do, 133-38
Backlog desconhecido, 133
Backlog invisível, 132
Backlog visível, 132
Bancadas, projeto, 581
Bolhas de geração espontânea, 204
Buracos negros, diagramas de fluxos de
dados (DFD), 204
c
Cálculos, 493
Cálculos de custo/benefício, 623-44

Página 549 de 584
análise de benefícios, 633-37
benefícios estratégicos do novo
sistema, 636-37
benefícios táticos, 634-36
análise de custos, 625-33
custo das falhas, 632-33
custo do dinheiro,629
custos de construção de sistemas,
625-27
custos de instalação de sistemas,
627-29
custos operacionais, 629-3 1
distinção entre custo de capital e
custo de despesas, 633
análise dos riscos, 641-43
como expressar custos/benefícios,
637-4 1
fluxo de caixa, 638-39
retorno do investimento, 639
taxa interna de retorno, 641
valor atual líqüido, 639-40
Cálculos de custos, sistemas, 625-27
Caminhamentos (Walkthroughs), 643,
645-53
definição, 645-46
motivos para a realização, 646-48
personagens dos, 649-5 1
procedimentos, 651-52
quando fazer, 648-49
tipos de, 646
Caminhamentos da análise, 646-53
822
motivos de utilização, 646-48
personagens dos, 649-5 1

Página 550 de 584
procedimentos, 651-52
quando utilizar, 648-49
Caminho da auditoria, 497
Cartões perfurados, 474, 476-77
CASE (Computer-Aided Software Engi neering), 158
Ciclo de vida da prototipação, 98, 120-24
candidatos para, 12 1-24
definição, 120
software usado, 121
Ciclo de vida do projeto, 97-129
ciclo de vida da prototipação, 98,
120-24
ciclo de vida do projeto clássico, 100-
101
implementação bottom-up, 101-
104
progressão seqüencial, 104-105
109-116
ciclo de vida do projeto semi-estrutu rado, 98, 104-108
conceito de, 98-100
implementação top-down, 98, 116-
20
objetivos do, 99-100
Ciclo de vida do projeto clássico, 100-
101
implementação bottom-up, 101-104
ciclo de vida em cascata, 101-104
eliminação de erros, 101
testes, 101-104
progressão seqüencial, 104
Ciclo de vida do projeto estruturado,
109- 116
análise de sistemas, 112

Página 551 de 584
controle de qualidade, 114
conversão de bancos de dados, 115
geração de testes de aceitação, 113
implementação, 113
instalação, 115
levantamento, 109-111
projeto, 112
resumo, 115-116
Ciclo de vida do projeto semi-estrutu rado, 98, 105-108
comparado ao ciclo de vida do pro jeto clássico, 105
Ciclo de vida em casacata, 101-104
Código reutilizável, suporte de IA, 598-
99
Códigos
código reutilizável, suporte da IA,
598-99
códigos alfabéticos, 490
códigos externos, 489
Códigos alfabéticos, 490
Códigos de classificação, 490
Códigos externos, 489
Coleta de dados, 668
Coleta de dados
formas de, 668
entrevistas, 656-68
Complexidade excessiva, verificação
antecipada, 597
Comportamento tempo-dependente, 3 19-20
sistemas de tempo-real, 31
Computador Apoilo, 583
Computador Sun, 583
Computadores pessoais (PC), 580, 81
Computadores VAX, 583-94
Computadores Wang, 593

Página 552 de 584
Computer-Aided Software Engineering
(CASE), 158
Computer OutputMicroform (COM), 478
Condições, estados, 326
Confiabilidade
como problema de alocação, 5 13-14
no desenvolvimento de projetos de
sistemas, 139-42
erros de software, 139-42
restrições, 496-97
Controles batch, 495
Controle de documentos, 595
Controle de qualidade, ciclo de vida de
projeto estruturado e, 114
Conversão, 545-46
conversão de bancos de dados, 115
custos de, 627
Conversão de bancos de dados
ciclo de vida do projeto estruturado, 115
custos da, 627
823
Correção, como problema da pro gramação, 537
Cronogramas, estimativas de, 605
Custo, um problema de alocação, 512
Custos com pessoal, 630
Custos das falhas, 632-33
Custos das instalações físicas, 631
Custos de capital, comparados com
custos de despesas, 633
Custos de despesas, comparados com
custos de capital, 633
Custos operacionais, sistemas, 632-33
D
Decisão de implementação, 29

Página 553 de 584
Definições, dicionário de dados, 239
Declaração de objetivos
modelo ambiental, 414-16
Yourdon Press, 678
Demanda desconhecida, 133
Departamento SIG, 63
Depósito de implementação, 188-90
Depósitos
alocação de, 511
atribuição de nomes aos, 196-99
definição de, 188-189
depósito de implementação, 189-91
depósitos de escrita-apenas, 204
depósitos de leitura-apenas, 204
depósitos essenciais, 447
fluxo para, 193-94
interpretação de fluxo proveniente
de, 192
píopósito dos, 189
Depósitos de controle, 86, 214
Depósitos de dados
alocação de, 511
Veja também Depósitos
Depósitos de escrita-apenas, 204
Depósitos de leitura-apenas, 204
Depósitos essenciais, 447
Depósitos externos
comunicação através de, 423
modelo de entidades-relacionamen tos, 419
DER, Veja Diagramas de entidades-rela cionamentos (E-R)
Desenvolvimento, Veja Desenvolvi mento de sistemas
Desenvolvimento de sistemas participantes, 49-79
analista de sistemas, 68-69
auditores, 67

Página 554 de 584
gerência, 60-67
grupo de controle de qualidade,
67
pessoal de operações, 72-73
programadores, 69-72
projetistas de sistemas, 69
setor de padrões, 67
usuários, 50-60 principais problemas, 131-50
confiabilidade, 139-42
eficiência, 144
manutenibilidade, 142-44
portabilidade, 144
produtividade, 132-39
segurança, 144 relacionamento entre a gerência e,
62-63
DFD, Veja Diagramas de fluxo de dados Diagrama de bolhas, Veja Diagramas de
fluxo de dados
Diagrama de fluxo de dados de alto nível, 440
Diagrama de fluxo de dados inicial, desenvolvimento do, 447-48
Diagrama SADT, 366
Diagramas de análise de problemas
(DAP), 357, 359, 360
componentes dos, 359
Diagramas de Bachman, 366, 367 Diagramas de contexto
modelo ambiental, 416
construção do, 421-28
nome de processo típico para,421
terminadores duplicados em, 424 Diagramas de entidades-relacionamen tos (E-R), 88-89, 157, 246,
289-318,
400
componentes do, 88, 292-300 indicadores de tipos de objetos
associativos, 298-300
relacionamentos, 294-97
tipos de objetos, 292-93

Página 555 de 584
824
definição de, 88
dicionário de dados, notação para,
310-11
diretrizes de construção, 300-301
acréscimode tipos de objetos, 300-
10
supressão de tipos de objetos, 306-
10
equilíbrio em relação ao DFD e às especificações de processos, 344-
45
variações, 365 -68
Yourdon Press, 757
Diagramas de estrutura de dados de DeMarco, 366-67
Diagramas de Ferstl, 357-58
Diagramas defluxo de dados (DFD), 84- 87, 177-233, 247, 400
como evitar DFD excessivamente complexos, 200
como refazer, 201-203
comparados com os diagramas de entidades-relacionamentos (E-R),
289
componentes dos, 84-86, 179-96
depósitos, 85, 188-94
fluxos, 85, 181-88
processos, 85, 180-81
terminadores, 85, 194-96
diagramas de fluxo de dados subdi vididos em níveis, 205-2 14
dicionário de dados (DD), 86
diretrizes de consistência, 204-205
especificação de processos, 86, 87
exemplo de, 85
extensões, para sistemas de tempo real, 214-15
modelo comportamental final, Your don Press, 675-732
modelo comportamental preliminar, Yourdon Press, 679-72 1
problema dos elevadores, 795-810

Página 556 de 584
relacionamentos entre diagramas de transições de estado (DTE) e, 330-
331
subdivisão em níveis, 454-59
subdivisào ascendente, 454-55, 461
subdivisão descendente, 455-57
utilização em lugar dos diagramas
PERT, 38 1-83
variações, 365
Diagramas de fluxo de trabalho, Veja
Diagramas de fluxo de dados
Diagramas de Gane-Sarson, 365
Diagramas de Hamilton-Zeldin, 357,359
Diagramas de transições de estado (DTE), 28, 89-90, 91, 156, 214-15, 246, 319-
36, 400
como completá-los, 461
comparados aos diagramas de enti dades-relacionamentos (E-R), 289
construção dos, 3 29-30
diagramas subdivididos, 326-28
notação, 320-26
condições e ações, 326
estados do sistema, 320-22
mudanças de estado, 322-24
relacionamento com outros compo nentes do modelo, 330-31
relacionamento entre diagramas de
fluxo de dados e, 331
Diagramas estruturais, 90-91,363-65,516
módulos, 72
Diagramas HIPO, 362-63
Diagramas IPO (entrada-processamento saída), 363
Diagramas PERT, 378-80
lista de atividades, 383
atividades de alto nível, 383
Dicionário de dados (DD), 86, 235-52, 400
aceitação do usuário, 245-47

Página 557 de 584
como completar o, 460
definição do, 236
entradas (itens), 164
equilíbrio do, 340-42, 346-47
em relação às especificações de
processos, 340-42
em relação ao DD, 340-4 1
em relação ao DTE, 346-47
implementação do, 247-48
importância do, 235-36
notação, 238-45
definições, 239-40
elementos de dados elementares,
825
240-41
elementos de dados opcionais,
242-43
esquemas de notação, 239
iteração, 243-44
necessidade da, 236-38
seleção, 244
sinônimos, 244-46
notação do diagrama E-R, 3 10-11
problema do elevador, 81 1-13
Yourdon Press, 732-57
Diagramas de estrutura de dadosJackson,
366, 369
Diagramas de fluxo de dados subdividi dos em níveis, 205-2 14
consistência, 210
exibição de depósitos em vários níveis, 210
exibição dos níveis aos usuários, 210
número de níveis, 209
subdivisão, 209

Página 558 de 584
uso de, 213-214
Diagramas de Nassi-Shneiderman, 277- 78, 356, 358
t pseudocódigo, 278
Diagramas subdivididos, 326-28
Diálogo/interface homem/máquina, Veja Interface humana
Diretrizes de consistência, diagramas de fluxo de dados (DFD), 204-205
Diretrizes de estimativas, 605-22 fator de comunicação, 615-16 fórmulas, 616-18
para estimar o tempo, 617-18
para estimar o tempo de trabalho,
617
itens a serem estimados, 605-06
modelos de estimativas computado rizadas, 619
perigos, 606-13
de estimar seu próprio trabalho,
609- 10
diferença entre estimar e negociar,
607-608
dificuldade em medir a unidade de trabalho, 612-13
estimativas com base em pressu posições de horas extras não
pagas, 613
estimativas detalhadas prematu ras, 611-12
falta de um banco de dados de estimativas, 610-11
grande variação nas habilidades técnicas, 608-609
trabalho novo versus trabalho aproveitado, 616
unidades de estimativas, tamanho das,
614-15
unidades de trabalho, independência das, 615
Discos flexíveis, 474-75
E
Eficiência
como problema da alocaçao, i !-iz comoproblemada programação, 536-
37
no desenvolvimento de projetos de sistemas, 144
EGA-Paint, 583, 588

Página 559 de 584
Elementos de dados elementares, di cionário de dados (DD), 240-41
Elementos de dados opcionais, di cionário de dados (DD), 242-43
Eliminação de erros, 579
ciclo de vida do projeto clássico, 101 Entrada
dispositivos de entrada, 474-75
cartões perfurados, 474
discos flexíveis, 474-75
entrada de voz, 476
fita magnética, 474
leitoras óticas/leitoras de código de barras, 475
telefone, 475-76
terminais e computadores pes soais (PC), 475
entradas redundantes, 494
inserção dc entradas no sistema, 492-
93
tempo de resposta à, 496
Entrada de voz, 476
Entradas (itens), dicionário de dados
(DD), 164
826
Entrevistas, 655-664
diretrizes para a condução, 658-664 autorização para falar com os usuá rios, 659-660
estilos de entrevistas, 663-64
informações de interesse para o usuário, 662-63
planejamento geral, 658-59
problemas a dar atenção, 666-67
resistência, 664-66
uso de ferramentas automatiza das, 662
uso eficiente do tempo, 660-62
formas alternativas de coleta de dados, 668
motivo para realizar, 655
problemas com, 657-58
tipos de, 656 Equilíbrio
das especificações de processos em relação ao DFD e ao DD, 342-43

Página 560 de 584
de modelos, 337-5 1
do DD em relação ao DFD e às especi ficações de processos, 344
do DER em relação ao DFD e às especificações de processos, 344-
45
do DFD em relação ao DD, 340-4 1
do DFD em relação ao DTE, 346-47
do DFD em relação às especificações de processos, 34 1-42
Equipe de desenvolvimento, o custo durante a instalação, 628-29
Erros, software, 139-42
Escalonamento de pessoal, estimativas de, 605
Escrivão, como personagem de cami nhamentos, 650
Especificações de processos, 86-87,246,
253-87, 400
como completar, 460-61
condições pré/pós, 266-71
diagramas de Nassi-Shneiderman,
277-78
equilíbrio em relação ao DFD e ao
DD, 342-43
fluxogramas, 275-77
grafos/diagramas. 274
limitação da complexidade das, 264-
65
linguagem estruturada, 258-66
linguagem narrativa, 274-75
manutenção das, 544
requisitos das, 2 53-54
tabelas de decisão, 247-49
Yourdon Press, 758-785
Especificações funcionais gráficas, 155
Especificações funcionais minirnamente
redundantes, 155
Especificações funcionais subdivididas, 155

Página 561 de 584
Estações de trabalho (estações inteli gentes), custo das, 599-601
Estado final de sistema, 323, 25
Estado inicial de sistema, 323, 25
Estados do sistema, 321-22
mudanças de estado, 322-26
Estimativa de orçamentos, 605
Estimativas detalhadas prematuras, 611-
12
Estudo de caso, a Yourdon Press, 671-
785
antecedentes, 672-78
diagrama de entidades-relacionamen tos (E-R), 757
dicionário de dados (DD), 732-57
escala de operações, 678
especificações de processos, 758-85
estrutura organizacional da Yourdon, Inc., 675-76
grupos principais, 676-77
modelo ambiental, 678-8 1
declaração de objetivos, 678
diagrama de contexto, 679
lista de eventos, 679-81
modelo comportamental final, 722-
31
diagramas de fluxo de dados
(DFD), 723-3 1
modelo comportamental preliminar,
682-785
diagrama de fluxo de dados
(DFD), 683-721
Execuções paralelas, custo das, 628-29
827
F
Ferramentas automatizadas, 156-59,579- 603, 662
características das, 585-91

Página 562 de 584
verificação cruzada dos mode los, 590-91
recursos de verificação de erros,
588-90 suporte gráfico, 586-88
futuro das, 591-99
código reutilizável, suporte da IA,
598-99
controle de documentos, 595
estatística da produtividade e
métricas de software, 596
geração de código, 598
gerenciamerito de projetos, 595-
96
prova de correção assistida por computador, 597
quadros da equipe de projeto, 599 redes para uso em projetos, 593-
94
suporte à metodologia de enge nharia de software
personalizado, 594-95
teste e simulação assistidos por computador, 597
verificação antecipada de com plexidade excessiva, 597
tipos de, 579-81
Ferramentas de modelagem, 82-83, 166-
74
características das, 166-74
diagrama de fluxo de dados (DFD),
177-233
diagramas de entidades-rela cionamentos (E-R), 289-3 18
(DTE), 319-36
diagramas HIPO, 362-65
equilíbrio das, 337-5 2
especificações de processos, 253-87
fluxogramas, 354-62
modelos gráficos, 169

Página 563 de 584
828
modelos minimamente redundan tes, 171-72
modelos transparentes, 172-73
para gerência de projetos, 375-87
subdivisão top-down de modelos,
179-81
Ferramentas de modelagem de tempo-
real, 595
Fita magnética, 474,477
Fluxo de caixa, 638-39
Fluxogramas de sistemas, 359-61
Fluxos
atribuição de nomes, 182
definição de, 181
direção de, 183
escolha de nomes para, 196-99
fluxos convergentes, 184-85
fluxos de diálogo, 184
fluxos divergentes, 185-86
Fluxos de controle, 86, 214-15
Fluxos de dados, diagramas de con texto, 424, 426
Fluxos de diálogo, 427-29
Fluxos divergentes, 185-86
Fluxos sem rótulo, 192, 204
Fluxogramas, 275-77, 354-59
críticas aos, 275
fluxograma clássico, 354-56
fluxograma não-estruturado, 357
notação, 354
variações, 356-59
Formato, de sistema, 466-67
Formulários especiais, 487-88
custo dos, 488
formulários multipartes, 488

Página 564 de 584
tipos de, 488
Formulários multipartes, 488
Formulários normais, 487
Fórmulas
estimativas, 616-18
para estimar o tempo, 617-18
para estimar o tempo de trabalho, 617
Fornecedores
custos de instalação, 627
demonstrações pelos, 668
L
Fronteiras da automatização, 392 modelo de implementação do
usuário, 468-73
opções extremas, 468-69
seleção das, 469-73
G-H
Geração de código, 598
Geração do teste de aceitação, ciclo de vida do projeto estruturado, 113
Gerência
interação entre os analistas de sis temas e, (50-62
níveis de, 60-61
pontos importantes relativos à, 60-62
relacionamento entre projetos desen volvimento de sistemas e, 63-64
Gerência de projeto, 595-96 ferramentas de modelagem, 375-87
comparadas com outras ferramen tas de modelagem de sistemas,
382-84
diagramas de GANTF, 380-81
diagramas PERU, 378-80
necessidade de modelos pela gerência, 376-77
problema da automatização, 384-86 Grafos/diagramas, 274
Grupo de administração de banco de dados (DBA), 290-91
Grupo de administração de dados (DA),
290
Guias de referência, 547

Página 565 de 584
Hardware
custo do, 630
futuro do, 572-74
instalação, 576 Hierarquia sincronizada de módulos,
365
Implementação bottom-up ciclo de vida do projeto clássico, 101-
104
ciclo de vida em cascata, 101-104 eliminação de erros, 101
testes, 101-104
Implementação, ciclo de vida de projeto estruturado, 113
Implementação top-down
abordagem radical versus aborda gem conservadora, 116-120
ciclo de vida do projeto sem i-estrutu rado, 105-106
Implementação top-down conservado ra, 116-120
Implementação top-down radical, 116- 120
Inspeções, 543
Veja também Caminhamentos (Wal kthroughs)
Instalação
115
custos da, 627-29
de sistema, 546-47
software, 547
Inteligência artificial
apoio de código reutilizável, 598-99 casamento da análise estruturada e,
571-72
definição de , 35-36,38
e o custo do sistema, 636-37 Interface amistosa ao usuário
diretrizes, 480-85
Veja também Interface humana Interface humana, 28, 473-91
códigos de entrada/saída, 489-91
códigos alfabéticos, 490-91
códigos de classificação, 489
códigos externos, 489

Página 566 de 584
requisitos para, 489-90
diretrizes para interfaces amistosas para o usuário, 480-85
dispositivos de entrada, 474-75
cartões perfurados, 474
discos flexíveis, 474-75
entrada de voz, 476
fita magnética, 474
leitoras óticas/leitoras de código de barras, 475
telefone, 475-76
terminais e computadores pes soais (PC), 475
829
dispositivos de saída 135-36, 535
cartões perfurados, 476-77 Linguagem de programação MARK V,
Computer Output Microform 135-36, 535
(COM), 478 Linguagem de programação NOMAD,
fita/disco magnético, 477 467
plotter, 477 Linguagem de programação Pascal, 135-
saida de voz, 477 36, 159, 535
saída impressa, 476 Linguagem de programação PC-FOCUS,
terminais, 477 135-36
formatos de entrada/saída, 478-85 Linguagem de programação PROLOG,
problemas relacionados, 473-74 39
projeto de formulários, 486-88 Linguagem de programação RAMIS, 535
conteúdo de formulários, 486 Linguagem estruturada, 258-66, 272
formulários comuns, 487 definição, 258-59
formulários especiais, 488 objetos, 259
International Business Machines (IBM), sentenças, 260
583 sentenças compostas, 262
Intervalo de tempo entre falhas (MTBF), verbos, 259
497 Linguagem narrativa, 274-75
Iteração, dicionário de dados, 243 abordagem de análise estruturada
subdividida, 275
Linguagens de programação de alto ni
L vel, 579

Página 567 de 584
Leitoras de códigos de barras, 475 Linguagens de programaçãode primeira
Leitoras óticas, 475 geração, 534
Levantamento, ciclo de vida do projeto Linguagens de programação de quarta
estruturado, 109-11 geração, 535-36
Linguagem de programação ADA, 135- Linguagensde programaçãode segunda
36, 535 geração, 534
Linguagem de programação BASIC, 135- Linguagens de programação de terceira
36, 534, 535 geração, 535
Linguagem de programação C, 135-36, Lista de eventos
535 modelo ambiental, 417,4 19
Linguagem de programação COBOL, 37, construção do, 428-30
135-36, 159, 273, 531, 534, 535, 551, problema dos elevadores, 794
579, 598 Yourdon Press, 682-84
Linguagem de prc dBASE III, Lotus 1-2-3, 33
135-36, 535, 218 , 467
Linguagem de programação FOCUS, 135-
36, 248,467,535 N
Linguagem de programação FORTRAN, MacDraw, 583-87
135-36, 273, 531, 534, 535, 598 MacPaint, 583-87
Linguagem de programação IDEAL, 467, Mantenedor de padrões, como persona
535 gem de caminhamentos, 651
Linguagem de programação LISP, 39 Manuais do usuário, 547-48
Linguagem de programação MAN’ITS, Manutenção
535 custos da, 630-31
Linguagem de programação MAPPER, de especificações, 553-61
830
importância das, 5 54-56
pré-requisitos necessários, 556
regras, 556-59
desastres, impacto dos, 569-70
programador de manutenção, 71
revisor de manutenção, como papel
do caminhamento, 650
Manutenibilidade

Página 568 de 584
como problemade programação, 537-
38
sistemas, 14 2-44
Mesas de projeto, 581
Microsoft File, 248
Minicomputadorde nível de projeto, 593-
94
Modelagem, 29, 82-95, 156
comportamento tempo-dependente, dados armazenados, 88-89
estrutura de programa, 90-91
ferramentas, uso de, 82-83
funções do sistema, 84-87
relacionamento entre modelos, 92
tipos de modelos, 82
Modelagem de dados, integração da
modelagem de processos e, 565
Modelagem de processos, integração da
modelagem de dados e, 565
Modelo ambiental, 399, 4 14-32
aspecto crítico do, 410
componentes do, 4 14-19
declaração de objetivos, 414-16
diagrama de contexto, 416-17
lista de eventos, 4 17-19
diagrama de contexto, 42 1-28
lista de eventos, 428-32
definição do, 409-10
dicionário de dados inicial, 419
fatores do escopo de projeto, 4 10-14
modelo de entidades-relacionamen tos de depósitos externos, 419
Modelo comportamental, 399, 439-50
construção do modelo preliminar,

Página 569 de 584
439-40
abordagem clássica, 440-42
etapas do desenvolvimento, 447-
identificação das respostas aos eventos, 441-46
interligação das respostas aos eventos 446-47
desenvolvimento top-down do, 440- 42
término de, 453-64
diagramas de transições de esta do, 461
dicionário de dados (DD), 460
especificações de processos, 460-
61
modelo de dados, 461
subdivisão do DFD em níveis, 454- 59
Modelo de dados, como completar, 454 Modelo de implementação de programa,
5 15-20
Modelo de implementação do usuário,
29, 73, 361, 395, 465-503
especificação de restrições opera cionais, 495-97
fronteiras da automatização, 468-73 escolha das, 469-71
opções extremas, 469
identificação de atividades adicio nais de suporte manual, 491-95
interface humana, 473-91
código de entrada/saída, 489-91
desenho de formulários, 486-88
dispositivos de entrada/saida, 474-
78
formatos de entrada/saída, 478- 85
problemas relacionados, 473-74 problemas de continuidade, 507-576
futuro da análise estruturada, 563-
76
manutenção das especificações,
553-61
programação/testes, 527-52
projeto de sistemas (fase), 507- 625

Página 570 de 584
Modelo de implementação, logicalização do, 400-403
Modelo de processador, 508-14 problemas de alocação, 5 11-14
49
89
831
Modelo de tarefa, 5 14-15
Modelo essencial, 391, 397-407, 465-66
componentes do, 400
definição do, 397
detalhes de implementação, 397-98
dificuldades da construção, 397-98
Modelo de funções, Veja Diagramas de fluxo de dados
Modelo de processos, Veja Diagramas de fluxo de dados
Modelo físico atual, desenfatização do,
564-65
Modelos de estimativa computadoriza da, 619
Modelos, equilíbrio de, 337-5 1
Modelos gráficos, 169
Modelos minimamente redundantes,
171-72
Modelos subdivisiveis pela modalidade top-down, 170-71
Modelos transparentes, 172-73
Módulos funcionalmente coesos, 520
Módulos pequenos, programas, 538
Mudanças de estado, 28, 89-90
N
Negociação, diferença entre estimativas e, 607-608
Nomes de processos, 4 21-22 Notação
(DTE)
condições e ações, 326
estados do sistema, 32 1-22
mudanças de estado, 322-24 dicionário de dados (DD)

Página 571 de 584
definições, 239-40
elementos de dados elementares,
240-4 1
elementos de dados opcionais,
24 2-43 •
esquemas de notação, 238-39
iteração, 243-44
necessidade de, 236-38
seleção, 244
sinônimos, 244-4 5 fluxogramas, 354-56
o-P
Objetos, linguagem estruturada, 259-60 Pacote de software de projeto (Meta
Systems Inc.), 682
Pacotes de controle de código fonte, 581
PC-Draw, 583, 588
Pesquisa externa, 668
Pessoal de operações, papel do, 72-73
PFS-File, 248
Plotadora, 477
Poços sem fundo, diagramas de fluxo de dados (DFD), 204
Portabil idade
como problema da programação, 537
no desenvolvimento de projeto de sistemas, 144
Prazos, estimativas de, 605 Pré/pós-condições, 266-71
Preparação da localização do computa dor, 546
Pré-requisitos, manutenção das especi ficações, 556
Presidente, como papel no cami nhamento, 650
Primeira versão do diagrama de fluxo de dados, 439
Problema dos elevadores, 787-8 18 descrição narrativa, 788-91 diagramas de fluxo de dados
(DFD),
795-810
especificação de processos, 815-18

Página 572 de 584
lista de eventos, 794
modelo essencial, 792-93 Processo de análise
modelo ambiental, 4 09-37
modelo comportamental
término do, 453-64
modelo de implementação do usuá rio, 465-503
modelo essencial, 391-407
Processos
atribuição de nomes a bolhas de processos, 181
definição de, 180
832
escolha de nomes, 196-99
exemplo de, 180
numeração de, 199-200
Processos de controle, 86, 214-15
Processos sem rótulo, 204
Produtividade
como problemade programação, 596
estatísticas, 596
sistemas, 132-39
Produtos CASE, 594-95
Programa de planilha Framework, 33
Programa de planilha Multiplan, 33
Programa Lightyear, 34, 35
Programação, 527-39
fast-tracking e implementação top down, 531-33
futuro da, 538-39
impacto na estrutura organizacional,
530-31
linguagens de programação, 533-39
gerações das, 534-36
papel doanalista de sistemas na, 528-

Página 573 de 584
30
problemas importantes, 536-38
Programação estruturada, 538
Programadores, 69-72
contato com analistas de sistemas,
70-7 1
programador de manutenção, 71
Progressão seqüencial, ciclo de vida do
projeto clássico, 104-105
Projetistas de sistemas, 69
Projeto de formulários, 486-88
conteúdo de formulários, 486-87
formulários comuns, 487-88
formulários especiais, 488
custo dos, 488
formulários multipartes, 488
tipos de, 488
Projeto de sistemas (fase), 507-25
diretrizes para, 520-22
acoplamento, 520-21
amplitude do controle, 521
coesão, 520
escopo de efeito! escopo de con trole, 521-22
tamanho dos módulos, 521
estágios do, 508-20
metas/objetivos, 520-22
modelo de implementação de programas, 515-20
modelo de processador, 508-14
modelo de tarefa, 5 14-15
programação/testes, 527-52 Projeto (fase)
112- 13
Veja também Projeto de sistemas (fase)
Prototipaçáo,59

Página 574 de 584
uso na análise estruturada, 159-60 Prova de correção, 543
prova de correção assistida por computador, 597
Prova de correção assistida por compu tador, 597
Q-R
Quadros negros para a equipe de pro jeto, 599
Questionários, 668
Rbase-5000, 135-36, 248, 467, 535
Recursos humanos, estimativas de, 605
Recursos de verificação de erros, ferra mentas automatizadas, 588-90
Redundância, 494
redundância interna, 494
Redundância interna, 494
Reestruturação de programas, 135-36
Relacionamentos, diagramas de enti dades-relacionamentos (E-R), 88-89
Resistência, a entrevistas, 664-66
Reseostas aos eventos, conexão de, 446- 47
Restrições ambientais, 496-97
Restrições operativas, como problema de alocação, 5 13-14
Restrições políticas, 496
como problema de alocação, 514 Retorno de investimentos, 639
s
Saída
833
dispositivos de saída
cartões perfurados, 476-77
Computer Output Microform
(COM), 478
fita e disco magnéticos, 477
plotadora, 477
saida de voz, 477
saída impressa, 476
terminais, 477
emissão de saídas do sistema, 493
saídas redundantes, 494

Página 575 de 584
Saida de voz, 477
Saída impressa, 476
Segurança
como problema de alocaçào, 512
em projetos de desenvolvimento de
sistemas, 144
restrições, 497
Seleção, dicionário de dados (DD), 244
Sentenças
linguagem estruturada, 260-61
sentenças compostas, 262-64
Sentenças compostas, 262,64
Setor de controle de qualidade
objetivo do, 67
problemas de trabalho com, 67-68
Setor de padrões
objetivo do, 67
problemas de trabalho no, 67-68
Setor de processamento de dados, 62-63
Simplicidade de estilo, programas, 538-
39
Simulação assistida por computador, 597
Simuladores, 579-80
Sinônimos, dicionário de dados, 244-45
Sistema de gerenciamento de bancos de
dados IDMS, 247, 290
dados IMS, 247, 290
dados TOTAL, 247, 290
Sistemas
custos de construcão, 625-27
custos de instalação, 627-29
custos operacionais, 629-3 1

Página 576 de 584
definição, 11-14
introdução de entradas no sistema,
492-93
obtenção de saídas do sistema, 493
semelhanças entre, 12
sistemas automatizados, 20-39
sistemas feitos pelo homem, 18-20
sistemas naturais, 14-18
tipos de, 14-15
Sistemas automatizados, 20-39
aplicações, 21
componentes comuns dos, 20
sistemas baseados no conhecimento,
38-39
sistemas de apoio à decisão, 32-37
sistemas de tempo real, 29-32
sistemas on-line, 27-29
Sistemas baseados no conhecimento,
38-39
definição de, 38
Sistemas batch (em lotes), 27-28
Sistemas CAD/CAM, 600
Sistemas de apoio à decisão, 32-37
definição, 32
exemplos de, 32-33
Sistemas de planejamento estratégico,
35-36
modelos típicos dos, 36, 37
Sistemas de processamento de infor mações, automatização dos, 20
Sistemas de tempo-real, 29-32, 3 19-20
ambiente, 31
análise estruturada e, 155-57
características dos, 3 1-32

Página 577 de 584
comportamento tempo-dependente, 31
exemplos de, 319
extensões aos diagramas de fluxo de
dados (DFD), 214-15
tipos de, 29-30
Sistemas especialistas, Veja Sistemas
baseados no conhecimento
Sistemas feitos pelo homem, 18-20
computadorização dos, 18-19
exemplos de, 18
Sistemas naturais, 14-18
sistemas vivos, 14-17
interação dos sistemas feitos pelo
homem nos, 16-18
834
sistemas físicos, 14
Sistemas on-line, 27-29
características dos, 27-28
comparados a sistemas batch, 27-28
definição de, 27
mudanças de estado, 28
uso de, 29
Sistemas operativos, relacionamento
entre, 35-36
Software
custo do, 630
erros de software, 139-42
instalação, 546
manutenção, 142
métricas, 596
Subdivisão de eventos, 157, 564
abordagem do modelo compor tamental, 442-46
Subdivisão em níveis

Página 578 de 584
diagramas de fluxo de dados (DFD),
454-59
subdivisão ascendente, 454-59
subdivisão descendente, 454-59
Subdivisão em níveis ascendentes, dia gramas de fluxo de dados (DFD), 454, 460
Subdivisão em níveis descendentes, diagramas de fluxo de dados (DFD),
454-59
Suporte à metodologia de engenharia de
software personalizado, 594-95
Suporte de gráficos, ferramentas auto matizadas, 586-88
Tabelas de decisão, 27 1-73
Taxa interna de retorno, 641
Telefone, 475-76
Teoria geral dos sistemas, 13, 40-43
Tetminadores, 194-96, 422-28
atribuição de nomes a, 196-99
comunicação entre o sistema e, 422
definição de, 194
fontes/manipuladores, 425
processo de comunicação, 422
representação gráfica de, 194
terminadores duplicados no diagra
Terminais de tempo compartilhado, 580
Testes, 539-43
ciclo de vida do projeto clássico, 101-
conceitos relacionados, 543-44
ferramentas de testes, 579-80
impacto na estrutura organizacional,
530-31
papel do analista de sistemas nos,
528-30
plano de testes, 540-4 1
descrições, 543
locação/cronograma, 543

Página 579 de 584
objetivo, 543
procedimentos, 543
testes e simulação assistidos por
computador, 597
tipos de, 540-43
testes de desempenho, 541
testes de recuperação, 540-4 1
testes funcionais, 540
Testes de desempenho,541
Testes de recuperação, 540-4 1
Testes e simulações assistidos por com putador, 597
Testes funcionais, 540
Tipos de objetos, diagramas de enti dades-relacionamentos (E-R), 88
Treinamento, 547
custo do, 625
U-v
Usuários, 50-60
características dos, 58
dassificados por nível de experiência,
59-60
novatos, 60
usuários amadores, 59
ma de contexto, 425 Terminadores duplicados, no diagrama
de contexto, 425
Terminais, 475
definição, 27
e computadores pessoais (PC), 475
terminais de tempo compartilhado,
580
102
835
usuários experimentados, 60 classificados por tipo de tarefa, 52-59
usuários de nível executivo, 56
usuários operativos, 53

Página 580 de 584
usuários supervisores, 54-56
heterogeneidade dos, 52
identificação dos, 51
preparação da localizacão, 546 Usuários de nível executivo, 56
Usuários operativos, 53
Usuários supervisores, 54-56
Valor atual líquido, 639-40
Verbos, linguagem estruturada, 259
Verificações de seqüência, 495
Visitas a outras instalações, 668
Volumes de dados, especificação de,
495-96
836
Série Yourdon Press Os clássicos indispensáveis
para analistas e programadores
GUIA DE IMPLEMENTAÇÃO PARA PROGRAMAÇÃO EM TEMPO REAL Ripps, DL,
Destinado a quem já tem experiência com programação em geral e deseja ampliar seus
conhecimentos sobre os últimos i avanços na programação em tempo real. cód.807-316pp.
PROJETO BASEADO EM OBJETOS
Yourdon, E.
Livro voltado para engenheiros de soft ware, especialmente os responsáveis pelo desenvolvimento
da arquitetura global para um sistema. Ajuda na elaboração de projetos de desenvolvimento de
sistemas reais.
cód.760 *
PROJETO ESTRUTURADO DE SISTEMAS
Yourdon, E./Constan tine, L.
Sintetiza as bases do método Yourdon de análise e projeto de sistemas. Fruto da experiência de
anos, este texto famoso derruba todos os padrões preestabeleci dos de identificação, especificação,
proje to e implementação de sistemas.
cód.714 568pp.
ANÁLISE BASEADA EM OBJETOS Coad, P./Yourdon, E.
O livro ajuda o analista a melhor se co PROJ
1 ESTRUTU
DE SIET [
ADMINISTRANDO O CICLO DE

Página 581 de 584
VIDA DO SISTEMA
Yourdon. E.
ADMINISTRANDO TÉCNICAS
ESTRUTURADAS
Estratégias Para o Desenvolvimento de
Software nos Anos 90
Yourdon, E.
municar para extrair as informações ne cessárias do especialista e então retornar todos os dados
analisados para o cliente. A análise baseada em objetos melhora a interação entre analista e
especialista.
cód.700 236 pp.
ANÁLISE ESTRUTURADA MODERNA
Tradução da terceira edição americana Yourdon, E.
Yourdon descreve neste clássico esta no va tecnologia que modificou a perspec tiva e o enfoque da
análise de sistemas. Atualiza a abordagem para a modela gem de um sistema físico atual e apre
senta os diagramas de transição de esta dos. Inclui cerca de 1.000 exercícios e estudo de casos.
cód.615 824 pp.
ANÁLISE ESTRUTURADA E
ESPECIFICAÇÃO DE SISTEMAS DeMarco, T.
Este é um livro de ferramentas e métodos para o analista. Seu objetivo é trazer or dem e rigor ao
processo de especificação para guiar o analista no desenvolvimento de uma Espec Estruturada.
Possui mais de 200 exemplos.
cód.544 348pp.
DO
REVISÕES
ESTRUTURADAS
Yourdon, E.
CRIAÇÃO DE SOFTWARE
Técnicas Eficientes
King, D.
Outros títulos da Série:
Editora Campus • A Qualidade da Informática
Outras maneiras fáceis de receber informações sobre nossos ‘ançamentos e ficar atualizado.
• ligue grátis: 0800-265340 (2 a 6 feira, das 8:00 h às 19:00 h)
• preencha o cupom e envie pelos correios (o selo será pago pela editora)

Página 582 de 584
• ou mande um e-mail para: info@campus.com.hr
CAMPUS
-
Nome: -- - ______________
Escolaridade: j Masc 1 Fem Nasc: _/_/_
Endereço residencial: _____________________________________________________________
Bairro__________________ Cidade___________________ Estado:_________________
CEP:________________ lei.:___________ Fax:_______________________
Empresa: ________________________________
CPF/CGC:
Costuma comprar livros através de: J Livrarias -_J Feiras e eventos J Mala direta
.J Internet
Sua área de interesse é:
1 NEGÓCIOS JINTERESSE 1JINFORMÁTICA 1 LIVROS-TEXTO
-- UALIDADE GERAL Nível: Administração
DE VIDA Irjiciante Informática
.J Intermediário Economia
1 Avançado 1 Comunicação
1 História
ij Ciência Política
‘o (D
si Si’
. c
Si cJ
-
>c/,
- 01
o
-1
>
OD
G O’
>
o,

Página 583 de 584
L
Cadastre-se e receba informações
sobre nossos lançamentos,
novidades e ptomoções
Para obter informações sobre lançamentos e novidades da
Editora Campus, dentro dos assuntos do seu interesse,
basta cadastrar-se no nosso site. I rápido e fácil.
Além do catálogo completo on-line, nosso sitc possui
avançado sistema de buscas para consultas, por autol título
ou assunto. Você vai ter acesso às mais importantes
publicações sobre Administração, Negócios, Informática,
Economia, Divulgação Científica, Qualidade de Vida,
Ciências Humanas e Interesse Geral.
Nosso site conta com módulo de segurança de última
geração para suas compras.
Tudo ao seu alcance, 24 horas por dia. Clique
www.campus.com.br e fique sempre bem informado.
www.campus.com.br
É rápido e fácil. Cadastre-se agora.
Este livro foi impresso nas oficinas gráficas da
Editora Vozes Ltda.,
Rua Frei Luís, 100 - Petrópolis, RJ,
com filmes e papel fornecidos pelo editor.

Página 584 de 584

Análise Estruturada Moderna

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Análise Estruturada Moderna

Diunggah oleh

Hak Cipta:

Format Tersedia

Consultor Editorial

Fernando Barceilos Ximenes

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

Oprincipio e a finalização de todos os empreendimentos humanos são desorganizados, a construção

1.1 POR QUE A ANÁLISE DE SISTEMAS É INTERESSANTE?

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46

http://dl.docslide.com.br/download/39f1e5662c0308704c7b67…%2FkREuvbnSOw3Lph94vUkXyVarMpvbvchne2%2F0A%3D%3D 05/02/18 23R46