Anda di halaman 1dari 584

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

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


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

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


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.

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


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

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


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

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


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

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


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

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


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.

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


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

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


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

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


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

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


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.
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 é ,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”,

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


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

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


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
Neste capítulo, aprenderemos:
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

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


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, detalhada- mente, 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.

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


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 ti- pos diferentes de sistemas; na
verdade, quase tudo aquilo com que te mos contato em nossa vida ou é um sistema ou um
componente de um sistema (ou ambas as coisas).
Significa que devemos estudar todos os tipos de sistemas, ou pre tender nos tornarmos peritos em
sistemas sociais, sistemas 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

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


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

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


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 trans- portadoras 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.

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


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

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


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

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


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

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


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.

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


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

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


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

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


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

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


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-

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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,

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


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

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


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.

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


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.

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


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
PERGUNTAS E EXERCÍCIOS
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.

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


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

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


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

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


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
Neste capítulo, aprenderemos:
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

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


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

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


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

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


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

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


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

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


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

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


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

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


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:

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


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

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


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.

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


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), é

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


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

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


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.

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


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 .

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


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.

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


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á.

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


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.
PERGUNTAS E EXERCÍCIOS
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
particular- mente 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

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


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?
9. Qual o conhecimento que o usuário deve ter sobre computadores e sobre software para poder
gerenciar uma equipe de projeto de desenvolvimento de sistema? Qual o conhecimento que ele
deve ter a respeito da análise de sistemas para poder ser um eficiente gerente?
74
10. Qual o conhecimento que o usuário deve ter sobre computadores e sobre software para poder
desenvolver por ele mesmo todo o projeto de desenvolvimento de um sistema? Qual o
conhecimento que ele deve ter sobre 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

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


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

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


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

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


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

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


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
Neste capítulo, aprenderemos:
1. Para que um analista de sistemas usa ferramentas de modelagem.
2. A natureza e os componentes de um diagrama de banco de dados.
3. Os componentes de um 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

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


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

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


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.

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


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

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


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

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


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

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


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.

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


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.
PERGUNTAS E EXERCÍCIOS
1. A introdução ao capítulo 4 lista mapas, globos, fluxogramas, dese nhos arquitetônicos e pautas
musicais como exemplos de modelos.

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


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?

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


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.

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


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
Neste capítulo, aprenderemos:
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.

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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,

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


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

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


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

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


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

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


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á radical- mente 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

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


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

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


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

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


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:

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


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

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


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:
YOURDON Press, 1981.
6. Edward Yourdon, Managing the Systems L Cycle, 2 ed. En glewood Cliffs, N.J.: Prentice-Hall,
1988.
7. James Grier Miller, Living Systems. Nova lorque: McGraw-Hill,
1978.
8. Michael Jackson, Princ ofPmgram Design. Nova lorque: Aca demic Press, 1975.
9. Winston W. Royce, “Managing the Development of Large Software Systems», Proceedings,
IEEE Wescon, agosto de 1970, pgs. 1-9.
10. Barry Boehm, Software 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
PERGUNTAS E EXERCÍCIOS
1. Apresente dois sinônimos para metodologia.
2. Qual é a diferença entre uma ferramenta, como usada no conte
deste livro, e uma metodologia?

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


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?

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


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?

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


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

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


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
Neste capítulo, aprenderemos:
1. Porque a produtividade é um problema importante.
2. As soluções comuns do problema da produtividade.

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


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:

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


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.

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


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.

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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:
YOURDON Press, 1986.
7. Bennett P. Lientz e E. Burton Swanson, Software Maintenance Management. Reading, Mass:
Addison-Wesley, 1980.
8. T. Capers Jones, Programming Produclivity. Nova lorque:

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


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.
PERGUNTAS E EXERCÍCIOS
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.

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


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?

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


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

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


Página 111 de 584
determinação da eficiência de um sistema de informação?
35. Qual é o papel desempenhado hoje pelo analista de sistemas na
determinação da portabilidade de um sistema de informação?
36. Qual é o papel desempenhado hoje pelo analista de sistemas na
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].

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


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

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


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
Neste capítulo, aprenderemos:
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

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


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

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


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

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


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
discutido no capítulo 17.
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

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


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

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


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

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


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

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


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:

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


Página 121 de 584
YOURDON Press, 1980.
9. Meilir Page-Jones, The Practical Guide to Structured Systems De sign, 2’ ed. Englewood Cliffs,
N.J.: Prentice-Hall, 1988.
10. Edward Yourdon e Larry Constantine, Siructured Design, 2’ cd. Englewood Cliffs, N.J.:
Prentice-hall, 1989.
PERGUNTAS E EXERCÍCIOS
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?

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


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 vitoria- na 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

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


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

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


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
Neste capítulo, aprenderemos:
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

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


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.

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


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

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


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

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


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
PERGUNTAS E EXERCÍCIOS
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?

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


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.

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


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:

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


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

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


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

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


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

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


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 estreita- mente 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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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 é
discutido no capítulo 18.
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

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


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

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


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
DIAGRAMA DE CONTEXTO
o
FIGURA 3
Figura 9.22 (a): Um fragmento de DFD equilibrado
211
DIAGRAMA DE CONTEXTO
o
FIGURA 3
Figura 9.22 (b): Um fragmento de DFD desequilibrado
212
7. Como realmente se faz a subdivísão dos DFD em níveis? A dis cussão até agora orientou mal de
um modo um tanto sutil:

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


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 é intuitiva- mente 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

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


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

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


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:
YOURDON Press, 1975.
3. Glen Myers, Reliable Software through Composite Design. Nova lorque: Petroceili/Charter,
1975.
4. Tom DeMarco, Structured Analysis and Systems Spec Englewood Cliffs, N.J.: Prentice-Hall,
1979.
5. Chris Gane e Trish Sarson, Struclured Systems Analys&s: Tools and 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.
PERGUNTAS E EXERCÍCIOS
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?

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


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
10. O que está errado com o processo abaixo?
REGISTRO
DE CLIENTE
11. O que está errado com o processo abaixo?
12. Por que um analista de sistemas desenharia um DFD com un
processo composto do nome de uma pessoa ou de um grupo d
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?
20. O que está errado no DFD abaixo?
1
21. O que está errado nos DFD abaixo?
b
219

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


Página 154 de 584
22. O que está errado no DFD abaixo?
a
c
b
23. O que está errado no DFD abaixo?
c
b
24. Descreva um fluxo de 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
38. O que está errado nos DFD abaixo?
(a)

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


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?
47. O que está errado no DFD abaixo?
CLIENTES
dados-de-inventário
trajetória-do-míssil
224

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


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?
51. O que está errado nos DFD abaixo?
(a)
(b) ________
CLIENTE 1
SISTEMA
DE PEDIDOS
(c)
impostos
(d)
225
52. O analista de sistemas pode alterar o 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

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


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?

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


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

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


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

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


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

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


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

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


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

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


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
Neste capítulo, aprenderemos:
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

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


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.”

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


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

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


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 mar- ciano 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

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


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

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


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)

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


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:

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


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,

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


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
::::
.:.. .
:...•:

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


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?

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


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

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


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.
PERGUNTAS E EXERCÍCIOS
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?

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


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

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


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

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


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
Neste capítulo, aprenderemos:
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

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


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.

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


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

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


Página 180 de 584
ficará restrito a utilizá-lo pelo analista de sistemas. Na verdade, a extraordinária atenção dada ao
algo- ritmo 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

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


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

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


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:

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


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

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


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

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


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

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


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

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


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

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


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:

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


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

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


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

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


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

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


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

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


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.

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


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

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


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)
mostrada na figura 11.9.
275
Entretanto, se o fluxograma for utilizado apenas para descrever ló gica detalhada e se o analista de
sistemas se restringir a incluir no fluxograma 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

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


Página 196 de 584
INassi e Shneider man, 19731 e [ 19741. Um diagrama de Nassi- Shneiderman típico toma a forma
mostrada na figura 11.11.
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,

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


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.:
Prentice-Hall, 1988.
4. James Martin e Carma McClure, Diagramming Technique.s for Soft ware Engineeríng.
Englewood Cliffs, N.J.: Prentice-Hall, 1985.
5. Victor Weinberg, Slructured Analysis. Englewood Cliffs, N.J.: Pren tice-Hall, 1978.
6. Edward Yourdon, Classics in Software Engineering. Nova lorque:
YOURDON Press, 1979.
7. Corrado 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.).

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


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.
PERGUNTAS E EXERCÍCIOS
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?

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


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

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


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?

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


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
53. O que está errado na tabela de decisões abaixo?
Altura superior a 1,80m
T
T
E

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


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

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


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

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


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.

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


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

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


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
Neste capítulo, aprenderemos:
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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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 (a): Um diagrama de E-R inicial
Figura 12.11 (b): Um objeto transformado em objeto associativo
EMPREGADO FILHO
305
Figura 12.12(b): Diagrama de E-R revisto
Esse processo de 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).

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


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
Figura 12.14 (a): Um diagrama de E-R inicial
À 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

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


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.

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


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

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


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.
PERGUNTAS E EXERCÍCIOS
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?

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


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?

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


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 consulto- ria 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?

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


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

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


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.

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


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

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


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

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


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

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


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•

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


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”

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


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

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


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.

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


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.
PERGUNTAS E EXERCÍCIOS
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

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


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
26. O que está errado com o DTE abaixo?
333
27. O que está errado com o DTE abaixo?
28. O que está errado com o DTE abaixo?
29. O que está errado com o DTE abaixo?
334
30. O que está errado com o DTE abaixo?
31. O que está errado com o DTE abaixo? Se você achar que nada está errado com ele, descreva o
que poderia acontecer com o sistema
modelado por este DTE.
condição-1
32. O que está errado com o DTE abaixo?

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


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.

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


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”.

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


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.

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


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

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


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 *

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


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}

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


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

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


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

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


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,
N.J.: Prentice-Hall, 1984.
2. Barry Boehm, Software Engineering Economics. Englewood Cliffs, N.J.: Prentice-Hall, 1981.
PERGUNTAS E EXERCÍCIOS
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

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


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
dicionário de dados?
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,

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


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
Neste capítulo, aprenderemos:
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.

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


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

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


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

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


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.:

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


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;

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


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

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


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,

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


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

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


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

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


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:
YOURDON Press, 1979.
370
11. C.W. Bachman, “Data Structure Diagrams”, Data Base, The Quar terly Newsletler of lhe
Special lnlerest Group on Business Data Pro 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.

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


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:
YOURDON Press, 1977.
16. Jean-Dominique Warnier, Logícal Construction of Programas, 3 ed., traduzida por B. Flanagan,
Nova Jorque: Van Nostrand
Reinhold, 1976.
PERGUNTAS E EXERCÍCIOS
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 fluxo- gramas?
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?

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


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?

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


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
Neste capítulo, aprenderemos:
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

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


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.

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


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,

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


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

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


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.

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


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

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


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

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


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 é

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


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.:
Prentice-Hall, 1985.
3. Marvin Gore e John Stubbe, Elemenis of Systems Analysis, 3* cd. Dubuque, Iowa: William C.
Brown, 1983.
PERGUNTAS E EXERCÍCIOS
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?

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


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

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


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
Neste capítulo, aprenderemos:
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

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


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

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


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 superficial- mente 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

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


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

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


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

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


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

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


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

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


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
lorque: YOURDON Press, 1978.
2. Chr” Gane e Trish Sarson, Slructured Systems Analyszs: Tools and
Techniques. Englewood Cliffs, N.J.: Prentice-Hall, 1978.
3. Edward Yourdon, Managing lhe Systems L Cycle, Nova lorque:
YOURDON Press, 1982.
4. Victor Weinberg, Stnsctured Analysis, Nova lorque: YOURDON
Press, 1978.

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


Página 274 de 584
5. Steve McMenamin e John Palmcr, Essential Systems Analysis, Nova
lorque: YOURDON Press, 1984.
PERGUNTAS E EXERCÍCIOS
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

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


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?
42. Quando se “logicaliza” o modelo físico atual, o que se deve fazer

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


Página 276 de 584
com os processos cujo único propósito seja transportar dados de
um lugar para outro?
43. Quando se “logicaliza” o modelo físico atual, o que se deve fazer
com as bolhas cujo único propósito seja o de verificar dados que
são criados dentro do sistema?
44. Quando se “logicaliza” o modelo físico atual, o que se deve fazer
com os depósitos essenciais que tenham sido empacotados no
mesmo meio?
45. Quando se “logicaliza” o modelo físico atual, o que se deve fazer
com os elementos de dados que existem nos depósitos mas que
não são utilizados em lugar algum do sistema?
46. Quando se “logicaliza” o modelo físico atual, o que se deve fazer
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

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


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
Neste capítulo, aprenderemos:
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

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


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

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


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.

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


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

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


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

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


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.

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


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

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


Página 284 de 584
depósitos que, dc outra maneira, não se tornariam evidentes até que o modelo comporta- mental
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 termina- dores 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 termina- dores, 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

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


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

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


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 ter- minador 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

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


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

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


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 ter- minadores. No entanto, devemos ter
cuidado em distinguir entre os eventos discretos que tenham sido acidentalmente “empacotados”
juntos como se fossem um único evento; isso acontece quase sempre com os eventos orientados
por fluxo. Devemos examinar o evento candidato e nos perguntarmos se todas as 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”.

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


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

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


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 mode