Documente Academic
Documente Profesional
Documente Cultură
1
INTRODUÇÃO
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
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,
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
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
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
IL
19
A CONSTRUÇÃO
DO MODELO
COMPORTAMENTAL
PRELIMINAR
As coisas são sempre melhores no início.
Blaise Pascal, Leilres Provinciales, 1656-165Z nr. 4
Neste capítulo, aprenderemos:
1. Porque a abordagem top-down á difícil para o mo delo comportamental.
2. Como desenvolver um modelo comportamental pre liminar usando a subdivisão de cvcntos.
3. Como desenvolver o modelo dc dados DER inicial.
No capítulo anterior vimos como desenvolver o modelo ambiental para um sistema. Se, neste
momento, você estivesse trabalhando em um projeto real, você teria prontificado o diagrama de
contexto, a lista de eventos e uma declaração de objetivos. Além disso, você teria iniciado a
preparação do dicionário de dados, com pelo menos a definição dos elementos de dados que
representam as intcrfaces entre os terminadores externos e o sistema. Nossa tarefa agora á começar
a construir o modelo comportamental, isto é, o modelo do que deva ser o comportamento interno
do sistema para que possa interagir corretamente com o ambien te. Isso envolve o desenvolvimento
de um diagrama de fluxo de dados preliminar e um diagrama de entidades-relacionamentos, bem
como a elaboração dos itens iniciais dc) dicionário de dados.
25
O FUTURO DA ANÁLISE
E STRUTURADA
Todas as tentativas de previsão do futuro em qualquer nível de detalhe parecem ridículas em
poucos anos. Este livro tem um alvo mais realista, e também mais ambicioso. Ele não tenta
descrever o futuro, mas apenas definir as flvnteiras dentro das quais o futuro poderá estar. Se
encarar mos os tempos que se estendem adiante de nós como uma região ignota e inexplorada,
quero descobrir suas fronteiras e ter alguma idéia de sua extensão. Os detalhes geográficos de seu
interior permanecerão desco nhecidos - até que lá estejamos.
Arthur C. Clarke, Profiles of lhe Future
Através deste livro vimos a evolução de idéias e técnicas na área
da análise de sistemas. Elas enquadram-se em três largos períodos de
tempo:
1. Análise de sistemas convencional, até meados da década de 70; caracterizada (se o fosse) por
especificações narrativas seme lhantes a novelas vitorianas, dificeis dc ler e compreender, e
virtualmente impossíveis de manter.
2. Análise estruturada clássica, de meados dos anos 70 a meados dos anos 80, como descrito em [
19781, [ e Sarson, 1977] e outros. Ela caracterizava-se por versões iniciais de modelos gráficos e
F.2 ANTECEDENTES
Para se entender os trabalhos da YOURDON Press, é necessá gastar algum tempo explicando o
Contexto maior da corporação den da qual ela existia: YOURDON inc. Sem a YOURDON inc.
não haveri YOURDON Press; embora sem a YOURDON Press, é Claro qu YOURDON inc. não
teria alcançado o mesmo sucesso.
A YOURDON inc. foi formada como uma extensão de ativida independentes de consultoria e
palestras que exerci por alguns anos fins da década de 60 ao início da de 70. A empresa foi formada
em ai de 1973 porque meu contador me informou de que uma corporaç oferecia certas vantagens
fiscais que não me seriam oferecidas coi consultor autônomo. Não obstante essa orientação prática
sobre imp tos, a nova corporação não efetuou de fato qualquer operação antes dia da mentira
(primeiro de abril) de 974.
Como acontece com a maioria das empresas (e com muitos p jetos de processamento!), uma das
primeiras atividades foi criar o noi da empresa. Minha mulher e eu, que éramos os únicos
acionistas, di tores, funcionários e empregados, gostamos do nome “Artichokes A Other Fur-
Bearing Animals, Inc.”, mas percebemos que não caberia nossa fachada. Por fim, escolhemos o
nome “Superprogrammers, Lii ted”, e demos entrada nos papéis no estado de Nova lorque para reí
trar o nome. Depois de duas semanas, quando já íamos publicar alg anúncios de nossa primeira
série de seminários sobre programação truturada, o órgão competente nos avisou que o nome de
nossa empn não tinha sido aprovado: ele era muito parecido com o nome de ou companhia. Ao
investigarmos, descobrimos que a outra companhia denominada “Supermarkets Products, Inc. Sem
nos desesperarm rapidamente escolhemos um nome que tínhamos uma razoável cert de que não
seria cópia de alguma outra: meu próprio nome. Eni nasceu a YOURDON inc.
As atividades iniciais da empresa foram seminários profission sobre técnicas avançadas de
documentos-de-remessa = *lista de separação e etiqueta postais enviadas aos depósito para que
240-41
elementos de dados opcionais,
242-43
esquemas de notação, 239
iteração, 243-44
necessidade da, 236-38
seleção, 244
sinônimos, 244-46
notação do diagrama E-R, 3 10-11
problema do elevador, 81 1-13
Yourdon Press, 732-57
Diagramas de estrutura de dadosJackson,
366, 369
Diagramas de fluxo de dados subdividi dos em níveis, 205-2 14
consistência, 210
exibição de depósitos em vários níveis, 210
exibição dos níveis aos usuários, 210
número de níveis, 209
subdivisão, 209