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 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, 1944Y74a 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 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 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. 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 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 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 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 - 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. 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 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 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.: PrenticeHall, 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 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.: PrenticeHall, 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.: PrenticeHall, 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”, 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 temporeal, 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 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 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 modificouse 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. 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
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 - 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 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ériaenergia 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 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ériaenergia 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. • 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 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 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 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. 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 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 Codificador
, Rainha e o governo em Haia;
, 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 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 tocadisco; 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 online; 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 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-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 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 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 15 20 5 10 10 12 5 315 148 120 18 15 20
6 10 10 13 5 365 118 120 18 15 20 5 10 15 13 5 339 123 125 19 18 20 7 10 10 14 5 351 513 465 70 63 80
23 40 45 52 20 1371 LUCRO/PERDA 220 280 176 184 859 Figura 2.6: Uma planilha 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 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 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 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 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, 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 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. 3. James Grier MilIer, Living Systems. Nova lorque: McGraw-Hill, 1978.
4. George Steiner, Strategic Planning. Nova lorque: Free Press, 1979. 5. Peter Dru cker, Management: Tasks, Respons ibilities, Pra ctices. Nova lorque: Harper & Row, 1974. 6. Russell L. Ackoff, A Concept of Co Planning. Nova lorque: Wiley, 1970. 7. Stafford Beer, Brain oftbe Firm. Nova lorque: Wiley, 1972. 43 8. Stafford Beer, Tbe Heart ofEntetprise. Nova lorque: Wiley, 1978. 9. Stephen Hall, “Biochips”, Higb Technology, dezembro de 1983. 10. H. Garrett DeYoung, “Biosensors”, High Technology, novembro de 1983. 11. Nicholas Shrady, “Molecular Computing”, Forbes, 29 de julho de 1985. 12. David Olmos, “DOD Finances Case Western Biochip Research Center”, Computerworld, 3 de setembro de 1984. 13. Elaine Rich, “The Gradual Expansion of Artificial Intelligence”, IEEE Computer, maio de 1984. 14. Edward Feigenbaum e Pamela McCorduck, The Ft/ih Generation. Reading, Mass.: Addison-Wesley, 1983. 15. R.J.K. Jacob eJ.N. Froscher, “Software Engineering for .Rule-Based Software Systems”, Proceedings of the 1986 Fali Joint Computer Conference. Washington, D.C.: IEEE Computer Society Press, 1986. 16. Robert E. Kelier, Expert Systems Technolog Development and Application. Englewood Cliffs, N.J.: Prentice-Hall, 1987. 17. Robert Alioway e Judit.h Quillard, “User Managers’ Systems Nce CISR Working Paper 86. Cambridge, Mass.: MIT Sloan School Cen ter for Information Systems Research, abril de 1982. 18. Ludwig von Bertalanffy, General Systems Theo?y. Nova lorque: George Brazilier, 1969. 19. Gerald Wdnberg, An Introduclion lo General Systems 71.nnking. Nova lorque: Wiley, 1976. 20. John Gali, Systemantics. Nova lorque: Quadrangle/The New York Times Book Company, 1977. 21. D.Barstow, “Artificial Inteiligence and Software Engineering”, Proceedings of the 9th Internationai Software Engineering Conference, abril de 1987.
22. M.D. Lubars e M.T. Harandi, “Knowledge-Based Software Design Using Design Schemas”, 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. 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 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 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 • 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 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 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 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 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 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 pessoalpotencial 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 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: 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 subutilizados 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 vicepresidente 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 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. • 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), é 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 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. 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 . • 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.
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á. 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 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 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 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 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 originalmente 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 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 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 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 entidadesrelacionamentos 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. 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 $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 retratado por uma outra ferramenta de modelagem: o diagrama de entidades-rela cionamentos. Um diagrama entidadesrelacionamentos 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 entidadesrelacionamentos. 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 TEMPODEPENDENTE: O DIAGRAMA DE TRANSIÇÕES DE ESTADO Um terceiro aspecto de muitos sistemas complexos é o compor tamento tempodependente, 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 temporeal), 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 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. 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 tempodependente 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. 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? 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. 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. 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 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 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 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 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 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 topdown 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 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 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 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 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 homemmá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, 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 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 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 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 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 temporeal 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 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 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: 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 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.: PrenticeHall, 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? 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? 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? 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
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.
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: • 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. 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-selhes 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. 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 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 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 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 :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 á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 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 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: 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. 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? 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
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 superprogramador 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]. 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 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) revelase 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 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 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 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 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 temporeal; 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 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 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 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: 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? 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 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.: PrenticeHall, 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 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 topdown. 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 derelacionamentos, 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 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. 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 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 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? 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. 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: 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 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
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 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-DEENTREGADORES; 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-DEPEDIDOS 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ÓDIGOPOSTAL 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 ‘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 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 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 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 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 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 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 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 • 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 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 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 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 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 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 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 apresentarlhe 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: 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 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 temporeal 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 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 13. 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? 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 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) 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 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 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? 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 60Minute 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 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 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 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 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 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 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 entidadesrelacionamentos. 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.” 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 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
E1
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 • 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 autoexplicativos, isto é, termos 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) significa, literalmente, que o endereço do cliente poderia constituirse 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: 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, 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 :::: .:.. . :...•: 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?
• 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 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? 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 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 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 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 NassiShneiderman, 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. 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 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 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 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: 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 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 é 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 DOWHILE 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 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 DOWHLLE. 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-THENELSE 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 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
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 CATEGORIADE-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: «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 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 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 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 (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. 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 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 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 NassiShneiderman: “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, 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.). 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? 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 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? 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 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 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 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. 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 ENTIDADESRELACIONAMENTOS 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 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 entidadesrelacionamentos 5 1. Tipos de objetos 2. Relacionamentos 3. Indicadores associativos de tipos de objetos 4. Indicadores de supertipos/subtipos 12.1.1 Tipos de Objetos
Um tipo de objeto é representado por um retângulo em um diagra ma de entidadesrelacionamentos; 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 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 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 (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 ClienteItem 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 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 • Valor da hora extra • Hora de início 12.2 DIRETRIZES PARA A CONSTRUÇÃO DE DIAGRAMAS DE ENTIDADESRELACIONAMENTOS A notação mostrada na seçãÕ anterior é suficiente para cons trujr diagramas de entidadesrelacionamentos 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 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-degravidezes 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 ClIENTECARTÃO- DE-CRÉDITO como dois tipos de 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 sexodo-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 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). 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 umpara-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 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-paramuitos 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. 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 tempodependente 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 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.: AddisonWesley, 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 entidadesrelacionamentos? 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? :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? 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? 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 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. 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 tempodependente do sistema. Até bem pouco tempo, os modelos do comportamento tempodependente 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 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 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 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• 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” IAGUARDANDO
Limpar tela
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” 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 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. 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 (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? 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. 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”. 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. 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-seia 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 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 * 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} 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 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 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.: PrenticeHall, 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 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ãoprimitiva (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, 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. • 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 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 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 HamiltonZeldin, 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
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.: 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 NQUANTOc3P4 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; 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 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
transação
da transação transaçãc
ENDIF COLETAR CAMPOS
cartão da
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, 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 GaneSarson. 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 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 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. GC2O1851-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. 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? 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 NewtonRaphson. 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? 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 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. 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, 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
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. 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 • 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
cedo
cedo
tardio tardio
1
Início O
2
Falar com represen- 5
mais
1/4/88 1/4/88 1/4/88 1/4/88 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
Visitar instalações do 4
1/11/88
Apresentar estudo de O
2/1/88 2/1/88 2/1/88 2/1/88
iniciais 4
1/15/88
usuário 5
viabilidade
1/26/88
2/1/88
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
20
2/1/88 2/29/88
2/1/88 2/29/88
financeiras 8
Conduzir atividades de
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 é 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? 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 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 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 tamanho fixo
DE PEDIDOS
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 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 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 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 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 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 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. 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 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
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 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 é 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 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. 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 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 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. • 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 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 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 terminadorpara-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 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 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 do sistema (isto é, visto de dentro), poderemos identificar erroneamente os fluxos de chegada que não são eventos por eles mesmos, mas que são necessários para processar algum outro evento. Desse modo, sempre desejamos descrever os eventos do ponto dc vista do ambiente (isto á, de fora do sistema). Na maioria dos casos, o meio mais fácil para identificar os eventos relevantes para um sistema é visualizar o sistema em ação: examinamos cada terminador e nos perguntamos qual o efeito que as ações do termi nador podem ter no sistema. Isso á habitualmente feito em combinação com os usuários do sistema, que podem desempenhar o papel dos terminadores. No entanto, devemos ter cuidado em distinguir entre os eventos discretos que tenham sido acidentalmente “empacotados” juntos como se fossem um único evento; isso acontece quase sempre com os eventos orientados por fluxo. Devemos examinar o evento candidato e nos perguntarmos se todas as instâncias do evento envolvem os mesmos dados; se os dados estiverem presentes em algumas instâncias e ausentes em outras, podemos ter de fato dois eventos distintos. Por exemplo, se 428 consulta sobre resposta sobre situa SISTEMA DE solicitação de CONTROLE verificaçáo de crédito DE PEDIDOS resposta à verificação de crédito PARTAM ENTO DE
INTABILIDADE CLIENTE consulta sobre situação de pedido Figura 18.15 (c):, Um meio alternativo de mostrar fluxos de diálogo itaçáo de ficação de cr situação de pedido resposta à verificação de crédito Figura 18.15 (b): Fluxos de diálogo para mostrar mensagens essenciais 429 examinarmos cuidadosamente o evento “cliente entrega pedido”, vere mos que algumas instâncias do evento incluem o elemento de dad’s ‘vendedor-ID” e outros nãO; e veremos que a resposta do sistema será diferente quando um vendedor estiver envolvido do que quando não houver vendedor. Desse modo, seria mais apropriado termos dois even tos separados: “cliente entrega pedido”, e “vendedor entrega pedido de cliente”. 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 relacionamento de pedidos: um outro evento seria uma ação que anulasse uma instância do relacionamento. Isso nos conduziria a identificar “Cliente pede livro” e “Cliente cancela pedido de livro” como eventos da lista de eventos. Não é preciso muita investigação para perceber que “cliente” é um terminador para o sistema (enquanto “livro” não é); em seguida poderemos começar a desenhar o diagrama de contexto. Quando ambos os componentes do modelo ambiental estiverem terminados, estaremos aptos a confirmar o seguinte: • Cada fluxo de entrada no diagrama de contexto seria necessá rio ao sistema para reconhecer que um evento ocorreu, ou seria necessário ao sistema para a produção de uma resposta a um evento, ou ambos. • Cada fluxo de saída deve ser uma resposta a um evento. • Cada evento não temporal da lista de eventos deve ter entradas a partir das quais o sistema pode detectar que o evento ocorreu. • Cada evento deve ou produzir urna saída imediata como res posta, ou armazenar dados para serem emitidos como saída posteriormente (como resposta ou parte de uma resposta para i31 DE EVENTOS Figura 18.16: Criação do dia de contexto a partir de um DER algum outro evento), ou ele deve fazer com que o sistema a mude de estado (como indicado no diagrama de transações de estado). 18.3 RESUMO
A construção do modelo ambicntal é a prime!ra e mais importante parte da construção de um modelo completo dos requisitos do usuário para um novo sistema. A essa altura, isso poderia parecer uma tarefa fácil; afinal de contas, o diagrama de contexto consiste em uma única bolha, e a lista de eventos se parece com uma simples lista de transa ções. Mas, em um grande projeto, pode estar envolvido um grande vo lume de trabalho: a única bolha no diagrama de contexto pode intera gir com dezenas de terminadores externos e podem ter mais de uma 432 pedidos, 1. Evento 1... 2. Evento 2... 3. Evento 3... 4. 5. fatura, fatur CONTABILI - DADE liiL centena de fluxos de dados chegando e partindo. E a lista de eventos é também um importante esforço em grandes sistemas; pode existir facil mente mais de uma centena de eventos com que o sistema terá de lidar, e todos deverão ser identificados. Além disso, pode ser difícil conseguir uma declaração simples consensual do motivo da existência do sistema. Uma vez construído o modelo ambicntal, ele deve ser minucio samente revisto por todos os representantes dos usuários principais, bem como pela equipe do projeto. Depois disso, você estará pronto para iniciar a construção do modelo comportamental, o modelo do interior do sistema. Isso será discutido nos capítulos 19 e 20. PERGUNTAS E EXERCÍCIOS 1. Quais são as três coisas definidas pelo modelo essencial? 2. Que espécie dc eventos devem ser modelados em um modelo essencial? 3. Como a fronteira entre o sistema e o ambiente é determinada pelo analista de sistemas? ‘1. Qual é a provável conseqüência de o analista de sistemas escolher um escopo demasiado pequeno para o projeto? . Qual é a provável conseqüência de o analista de sistemas escolher um escopo demasiadamente grande para o projeto? 6. Que fatores devem ser levados em conta na definição dc um escopo para o projeto? 7. Como o desejo do usuário de conseguir uma certa participação no mercado afeta o
âmbito de um sistema? 8. Como a legislação decretada pelos diversos níveis governamentais afeta o escopo de um sistema? 9. Como o desejo do usuário para minimizar (Ou reduzir) despesas operacionais afeta o âmbito dc um sistema? 10. Como o desejo do usuário em obter alguma vantagem estratégica contra os competidores afeta o escopo dc um projeto? 11. Projeto de Pesquisa: examine um projeto da sua própria organi zação. Que fatores você considera que mais influíram na escolha do escopo do sistema? Você acha que o usuário, o analista de sistemas e a equipe do projeto estavam cientes dele e estavam de acordo? 12. Na sua opinião, de um modo geral, quais serão os principais fatores dos sistemas desenvolvidos nos anos 90? Por exemplo, a redução das despesas operacionais será mais importante do que as mudanças causadas pela legislação governamental? 13. Quais são os três principais componentes do modelo ambiental? 433 14.
Qual deve ser aproximadamente a extensão da declaração de
objetivos? 15.
Quais são as cinco características dc um sistema mostradas pelo
diagrama de contexto? 16.
Quais são os componentes dc um diagrama dc contexto?
17.
O que é uma lista de eventos?
18.
Quais são os três tipos dc eventos que devem ser modelados em
um diagrama de contexto? 19.
Qual é o relacionamento entre fluxos e eventos no diagrama de
contexto? 20.
O que é um evento temporal?
21.
Que componentes adicionais podem ser encontrados em um
modelo ambiental além do diagrama de contexto, a lista de eventos e a declaração de objetivos? 22.
Por que costuma ser necessário fazer muitas revisões e refina
mentos do modelo ambicntal? 23.
Por que é importante garantir que o modelo ambiental esteja
correto? 24.
Que tipo de nome deve ser colocado na bolha de um diagrama de
contexto? 25.
O que é um modelo de empresa?
26.
Como os terminadores comunicam-se com o sistema
27.
Os terminadores comunicam-se entre si cm um modelo de sistema?
Por quê? 28.
Sob que condições seria um terminador desenhado mais do que
uma vez em um diagrama de contexto? Como seria mostrado? 29.
Se um terminador for uma pessoa, como deve ele ou ela ser mos
trado no diagrama de contexto? 30.
Como pode o analista de sistemas ter certeza de que ele ou ela
identificou todos os terminadores no diagrama dc contexto? 31.
O que é um manipulador? Qual é a diferença entre urna fonte e um
manipulador? 32.
Por que devem ser mostradas fontes e não manipuladores em um
diagrama de contexto? 33.
O que deve fazer o analista de sistemas se o usuário insistir em
mostrar os manipuladores no diagrama de contexto? 34.
Sob que condições os fluxos são mostrados em um DFD?
35.
Por que as mensagens (prompts) e handshakings em geral não são
mostrados em um diagrama de contexto? 36.
O que significa a expressão fluxo limpo de dados?
37.
Sob que condições um terminador não inicia a entrada em um.
sistema? 38.
Sob que condições o sistema não inicia a saída para um
terminador? 434 39. O que deve ser desenvolvido primciro, o diagrama de contexto ou a lista de eventos? Por quê? 40. Quais são as quatro coisas que devem ser verificadas para garantir que o modelo ambiental esteja correto? 41. O que está errado no diagrama dc contexto abaixo? 42. O que está errado no diagrama de contexto abaixo? 43. O que está errado no diagrama de contexto abaixo? p
/ 44.
O que está errado no diagrama de contexto abaixo?
a LISTA DE EVENTOS 1. Cliente precisa de um “a» 2. Fornecedor precisa de fatura. 3. Fornecedor faz uma remessa. 4. Cliente entrega pedido. NOTAS Alguns usuários podem não ser importantes em termos de hierar quia organizacional; eles podem ser considerados como funcioná rios subalternos, secretários ou administradores. Contudo, as funções que eles desempenham podem ser vitais, e pode ser fun damental modelar exatamente as entradas que eles recebem do mundo exterior e as saídas que eles enviam ao mundo exterior, O motivo pelo qual o analista de sistemas muitas vezes esquece de falar para essas pessoas é muito simples: um usuário de nível mais elevado (isto é, o chefe) informará ao analista de sistemas com quem deve falar. “Não aborreça nenhum dos meus funcionários”, dirá o chefe ao analista, “eles estão muito ocupados e é por isso que precisamos de um novo sistema. Eu direi tudo que você necessita saber sobre o sistema”. Como já estudamos no capítulo 3, pode não haver um meio diplomático para evitar isso; mas é essencial verificar cuidadosamente o modelo ambiental para ga rantir que nada esteja faltando. 2 Esse é um improvável cenário para o projeto de desenvolvimento de um sistema, mas está começando a ocorrer gradualmente mais, à proporção que as pessoas estão utilizando diagramas de fluxo de dados e outras ferramentas de modelagem descritas neste livro para a construção de modelos de empresas. Isso pode ser feito sem qualquer intenção de se computadorizar toda a empresa, mas sim plesmente para abranger o que já existe principalmente para. abranger os dados de que a organização necessita para executar seu objetivo, O tema dc modelos dc empresas é discutido em Information Engineering for lhe Practilioner, de William Inmon 436 b (Engle wood Cliffs, N.J.: Prentice-hall, 1987) e Slrategic Data Base Modeling, de James Martin (Englcwood Cliffs, N.J.: Prentice-Hall, 1985). 3 Não é obrigatório o uso dc um fluxo dc diálogo, mas ele faz com que o diagrama de contexto fique mais legível pela agregação das entradas e saídas associadas de forma a que fiquem imediatamente visíveis ao leitor. Além disso, a utilização de uma seta para mostrar que o diálogo, em oposição a duas setas separadas, cria um de diagrama de contexto menos congestionado. Isso é importante em grandes sistemas, onde pode existir uma centena ou mais de diferentes interações com terminadores externos. 437
IL 19 A CONSTRUÇÃO DO MODELO COMPORTAMENTAL PRELIMINAR As coisas são sempre melhores no início. Blaise Pascal, Leilres Provinciales, 1656-165Z nr. 4 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. Essa abordagem envolve fundamentalmente o desenho da primei ra versão de um diagrama de fluxo dc dados, com um processo (bolha) 439 para a resposta do sistema a cada evento q tcnha sido identificado na lista de eventos. Em seguida, desenhamos depósitos cm nossa primeira versão de DFD para modelar s dados que devem ser memorizados entre eventos assíncronos. Finalizando, interligamos os fluxos adequa dos de entrada e de saída às bolhas e verificamos nosso conjunto de DFD em relação ao diagrama dc contexto para manter a consistência. Feito isso, damos partida cm um processo de limpeza, descrito no capítulo 20, para produzirmos um modelo bem organizado de processos e de dados para apresentação ao usuário final. A esta abordagm foi dado o nome de subdivisão dc evcntos cm lMcMenamin e Palmer, 198/d. Começaremos comparando esta abordagem com a clássica aborda gem top-down. 19.1 A ABORDAGEM CLÁSSICA
A abordagem sugerida neste capítulo é substancialmente diferente da abordagem topdown descrita em livros clássicos como DeMarco [ 19791, Gane [ e Sarson, 19791 e outros. A abordagem clássica presume que você já desenhou o diagrama de contexto; mas também presume que você prosseguirá direlarncnie da bolha única do diagrama de contexto para um 1)11) de alto nível (conhecido como figura 0), em que cada uma das bolhas representa um importante sub sistema. Cada bolha da figura O é, depois, dividida em figuras de nível mais baixo, e cada bolha dessas figuras dc nível mais baixo são tam bém divididas, e assim por diante, até que se alcance o nível de bolhas “atômicas”, que já não exigem mais decomposições. Isso é ilustrado na figura 19.1. Embora essa abordagem top-down seja diferente da que é apresen tada neste livro, eu nada tenho contra ela, ... clesc1e que funcione. Entre tanto, lembre-se de que muitos analistas de sistemas encontram os se guintes problemas quando utilizam a abordagem top-down: • Paralisia da análise. Em muitos sistemas grandes e complexos, simplesmente não existe algo que possa orientar o analista de sistemas no desenho da figura O adequada a partir do diagrama de contexto. Dessa forma, o analista senta-se à sua mesa, con templando o diagrama dc contexto, esperando pela inspiração divina, ou por alguém que lhe diga que o projeto ultrapassou o tempo para análise e que já é hora de se iniciar a codificação. • O fenômeno dos seis anolislas. Em um sistema grande e com plexo muitas vezes há mais dc um analista de sistemas contem plando o diagrama de contexto. Para dividir o trabalho sem que 440 Figura O rigura 19.1: li aesenvoivzmenro rop-down do modelo comportamental um interfira no serviço dos outros, eles criam arbitrariamente uma figura O com uma bolha para cada analista de sistemas. Desse modo, se houver seis deles, a figura O se constituirá de seis bolhas. Desnecessário dizer que isso pode não ser a melhor subdivisão do sistema, O que acontecerá, por exemplo, se o mesmo sistema for especificado por três analistas de sistemas? E por nove? E por um só? A subdivisão fl arbitrária. Em muitos casos o novo sistema fundamenta-se em outro sistema já existente ou é a computa dorização de uma organização. A subdivisão em alto nível do sistema atual (ex.: as unidades atuais da organização ou os sis temas de processamento existentes) é muitas vezes utilizada como base lógica para se subdividir o novo sistema. Portanto, se o sistema atual é representado pelo Departamento de Compras e pelo Departamento de Controle de Qualidade, o novo sistema freqüentemente tem um Subsistema de Compras e um Subsis tema de Controle de Qualidade mesmo que essa não seja (e muitas vezes não é) a melhor forma de subdividir (do ponto de vista funcional) o sistema. 441 A abordagem descrita neste capítulo não é puramente top-down e também não é puramente bottom-up. Ela é, dc certa forma, uma aborda gem “do meio”; depois que o DFI) inicial está pronto, pode ser preciso criar alguns níveis para cima e alguns outros
níveis para baixo. 19.2 A IDENTIFICÀÇÃO DE RESPOSTAS A EVENTOS A abordagem dc subdivisào dc evcntos envolve as quatro etapas abaixo: 1. Desenha-se uma bolha, ou processo, para cada evento da lista de eventos. 2. A bolha recebe um nome de acordo com a resposta que o siste ma deve dar ao evento associado. 3. Desenham-se entradas e saídas apropriadas de modo a que a bolha seja capaz de emitir a resposta necessária e desenham-se depósitos, como for mais adequado, para comunicação entre as bolhas. 4. O resultante DFD inicial é verificado em relação ao diagrama de contexto e à lista de eventos para que se confirme se está completo e consistente. A primeira etapa é direta, quase mecânica por natureza. Se houver 25 eventos na lista, você terá de desenhar 25 bolhas. Para facilitar consul tas, numere cada bolha de modo a coincidir com o evento a ela associa do. Assim, o evento 13 corresponderá á bolha 13 (posteriormente, como veremos no capítulo 20, rcnumerarcmos as bolhas adequadamente). A segunda etapa também é direta e mecânica: cada bolha recebe um nome apropriado, de acordo com sua necessária resposta. Isso igni fica que você deve examinar o evento e perguntar a você mesmo Que resposta o sistema deve dar a este evento?”. Lembre-se, contudo, que você deve escolher nomes tão específicos quanto possível. Assim, se um evento for CLIENTE EFETUA PAGAMEN1O, um nome adequado para uma bolha seria ATUALIZAR CONTAS A RECEBER (se for esta a única resposta exigida do sistema), em vez dc PROCESSAR PAGAMENTO DE CLIENTE (que nada nos informa sobre a natureza da resposta). A terceira etapa definitivamente não á mecânica, mas é normal mente bastante direta. Para cada bolha desenhada, é preciso identificar as entradas que a bolha necessita para executar sua tarefa; é preciso identificar as saídas (se houver alguma) que a bolha produz, sendo ainda 442 necessário identificar os depósitos a que a bolha deve ter acesso. Isso normalmente é feito mediante entrevistas com os usuários apropriados e focalizando cada evento e sua bolha associada. “De que necessita esta bolha para fazer seu serviço?” - você perguntará ao usuário - e “Que saídas ela gera?” Em muitos casos, o evento é dirigido pelos fluxos; isso quer dizer que o sistema se torna interessado na ocorrência do evento por causa da chegada de alguns dados de um tcrminador externo. Isso obviamente significa que o fluxo de dados apropriado deve ser associado ao proces so necessário para responder àquele evento. Porém, como mostram as figuras 19.2(a) e (b), podem ser necessárias entradas adicionais (de ou tros
terminadores e possivelmente de depósitos de dados) para que o processo possa produzir a necessária saída. Do mesmo modo, é preciso desenhar as saídas apropriadas produ zidas pelo processo como parte da resposta. Em muitos casos, isso en volverá saídas que são encaminhadas de volta aos terminadores fora do sistema; entretanto, isso pode envolver saídas enviadas aos depósitos, para serem utilizadas como entradas por outros processos. Isso está ilus trado nas figuras 19.3(a) e (b). Por fim, a quarta etapa é uma atividade de verificação de consistên cia semelhante às etapas de equilíbrio descritas no capítulo 14. Você deve se certificar de que cada entrada no diagrama de contexto esteja associada a uma entrada em um dos processos do DFD preliminar e de que cada saída produzida por um processo no DFD preliminar seja 1
___
Figura 19.2 (a): Fluxo de dados sinalizando a ocorrência de um evento 443 Figura 19.3 (a): Uma saída enviada de um processo para um terminador enviada para um depósito ou seja uma saída externa mostrada no diagra ma de contexto. Existem dois casos especiais: (1) eventos unitários que provocam múltiplas saídas e (2) eventos múltiplos que causam a mesma resposta. No primeiro caso, um evento unitário pode provocar múltiplas respostas, sendo cada uma delas modelada com sua própria bolha no DFD preliminar. Isso é ilustrado na figura 19.4. Isso só é adequado se todas as 444 Y Figura 19.2 (b): Entradas adkionajs necessárias para a produção da resposta Figura 19.3(b): Uma saída sendo enviada de um processo para um depósito edido de cliente Figura 19.4: Múltiplas respostas proven ientes do mesmo evento respostas usarem o mesmo fluxo de dados que chega, e somente se todas elas forem independentes entre si. Nenhuma saída de uma parte da resposta geral deve ser necessária como entrada para outra parte da resposta geral De forma inversa, haverá ocasionais situações em que um pro cesso esteja associado a mais de um evento; isso é mostrado na figura 19.5. Isso só é válido e adequado se a resposta emitida pela bolha for 445 pedido/ dinheiro idêntica para os diversos evcntos e somente se os dados de entrada e os de saída forem idênticos para as diversas resposlas aos eventos.
19.3 A INTERLIGAÇÃO DAS RESPOSTAS AOS E VENTOS Observe que, nos exemplos anteriores, nenhum dos processos do diagrama de fluxo de dados preliminar era interligado a outro: bolbas não falam diretamente com outras bolhas. Ao invés disso, as bolhas se intercomunicam através dos depósitos de dados. Por que é assim? Simplesmente porque as bolhas do DFD preli minar representam respostas a um evento, e os eventos que ocorrem no ambiente externo são, no caso geral, assmncronos. Isto é, não temos meios de garantir que dois eventos ocorrerão no mesmo instante, ou defasados um do outro por dois segundos, ou por qualquer intervalo de tempo. Os eventos acontecem no ambiente externo quando o ambiente decide fazê-los acontecer. E desde que: • a resposta a um evento possa exigir dados produzidos por al gum outro evento, e • não tenhamos meios dc saber quando os eventos ocorrerão, e • tenhamos de presumir, em um modelo essencial, que cada pro cesso executará sua tarefa de modo infinitamente rápido, e pedido! cartão de crédito Figura 19.5: Eventos múltiplos com a mesma resposta 446 daí depreende-se que o único modo dc sincronizarmos múltiplos even tos interdependentes é através dc um depósito. Atente para o fato de que esse é um depósito essencial: necessário, não por causa dos retardos de tempo relacionados à tecnologia impcrfcita, mas devido ás considera ções temporais do ambiente. Desse modo, você não deve ver um diagrama de fluxo de dados preliminar como o mostrado na figura 19.6(a); como os evcntos associa dos são assíncronos, a figura 19.6(a) só poderia funcionar se um depósi to de dados com retardo estivesse oculto cm um dos processos ou no próprio fluxo de dados. Assim sendo, a figura 19.6(b) é a maneira correta de mostrar as comunicações entre processos. 19.4 O DESENVOLVIMENTO DO MODELO DE DADOS INICIAL Como vimos, o procedimento dc esboçar o DFD inicial engloba o desenho de depósitos de dados entre processos assmncronos. Na maioria dos casos, a natureza desses depósitos será óbvia e os nomes pode rão ser escolhidos a partir do seu conhecimento do objetivo do projeto. Todavia, enquanto isso, você ou um dc seus colegas deve ter co meçado a trabalhar na versão inicial do diagrama de entidades-re lacionamentos como atividade independente, em paralelo com o desen volvimento do DFD inicial, o que deve ser feito com o emprego das técnicas descritas no capítulo 12. Como o DER e o DFD são desenvolvidos cm paralelo, eles podem ser usados para verificações cruzadas entre eles. Dessa forma, os depósitos que tenham sido definidos
cxpcrimcnta!mcntc no DFD preliminar podem ser utilizados para sugerirem objetos no DER pre liminar e os objetos que tenham sido cxpcrimcntalmcnte identificados no DER preliminar podem ser usados para auxiliar a escolha dos depósitos adequados no DFD preliminar. Nenhum dos modelos deve ser considerado como sendo o modelo dominante, que controla os demais; todos estão no mesmo pé dc igualdade e podem dar inestimável auxílio ao outro. Você também descobrirá que a lista de eventos é tão útil na elabo ração do DER inicial como na do DFD inicia!. Os substantivos na lista de eventos muitas vezes se mostrarão como objetos no DER; por exemplo, se um evento for “Cliente introduz pedido”, identificamos imediatamen te cliente e pedido como objetos experimentais. Podemos usar, do mesmo modo, a lista de eventos como meio de verificação cruzada do • cada fluxo de dados atue como um duto que possa transportar elementos de dados em velocidade infinita, pedido de cliente consulta sobre pedido de cliente de cliente situaçáo de pedido Figura 19.6 (a): Modelo incorreto de comunicação com retardo entre processos pedido de cliente SSAR PEDIDO DE 3 PEDIDOS situação de pedido Figura 19.6 (b): Modelo correto de comunicação com retardo entre processos consulta sobre pedido de cliente 448 DER inicial: todos os tipos de objetos do DER devem corresponder a substantivos na lista de eventos. 19.5 RESUMO A conclusão mais importante deste capitulo e que você não produ zirá um modelo comportamental que esteja pronto para ser mostrado ao usuário. Ele não está terminado, não está atraente e não é suficientemen te simples ou bem organizado para ser inteiramente compreendido. Pode-se ver um exemplo disto examinando-se o estudo de caso do apêndice F. Então, o que ele é? Qual é o momento de executar as etapas descri tas na seção 19.3? Muito simples, ele á um começo, uma estrutura sobre a qual você pode assentar o desenvolvimento da versão final, completa, do modelo essencial.
Neste momento você não deve estar preocupado com a preparação do modelo comportamental, ou com sua complexidade ou compreensi bilidade. Você deve resistir resolutamente á tentação de reorganizar, empacotar, decompor ou “recompor” qualquer bolha do DFD prelimi nar. Tudo com que você deve se preocupar neste momento é com a correção subjacente do modelo: ele tem um processo para cada evento? Eie apresenta as necessárias entradas e saídas para cada evento? E ele mostra as necessárias conexões entre os eventos? Depois de haver estabelecido Ludo isso,você pode começar a traba lhar na reorganização do modelo. Isso será discutido mais detalhadamente no capítulo 20. REFERÊNCIAS 1. Tom DeMarco, Sl Analysis and Systems Specification. Englewood Cliffs, N.J.: Prentice-! lalI, 1979. 2. Chris Gane e Trish Sarson, Struclured Systems Analysis: lbols and Tecbniques. Englewood Cliffs, N.J.: Prentice-! laIl, 1979. 3. Steve McMenamin e John Palmer, Essential Systems AnalysLís. Nova lorque: YOURDON Press, 1984. PERGUNTAS E EXERCÍCIOS 1. O que é o modelo comportamental de um sistema? Para que serve? 2. Quais são os três principais componentes do modelo comporta- mental pre1imina 449 3.
Qual é a abordagem clássica de construção do modelo comporta-
mental? Por que ela é caracterizada como uma abordagem top down? 4.
Quais são os três principais problemas normalmente encontrados
pelos analistas de sistemas ao tentarem seguir a abordagem top down clássica para preparar o modelo comportamental de um sistema de informações? 5.
Por que você acha que alguns analistas de sistemas são tomados de
paralisia, ou do ‘bloqueio de escritor”, ao tentarem desenvolver o DFD da figura O a partir do diagrama dc contexto? 6.
Por que o modelo comportamental de alguns projetos apresenta
uma subdivisão fisica arbitrária? 7.
O que significa a expressão subdivisão de eventos?
8.
Quais são as quatro etapas da subdivisão dc eventos?
9.
Se o analista de sistemas tiver descoberto 13 eventos no modelo
ambiental, quantos processos (bolhas) deve haver na primeira versão do modelo comportamental? 10.
Que tipo de esquema de numeração é utilizado para se numerar as
bolhas na primeira versão do DFD do modelo comportamental? 11.
Que base lógica é utilizada para se dar um nome a cada bolha na
primeira versão do DFD do modelo comportamentaP 12.
Como o analista de sistemas deve determinar as entradas, saídas e
depósitos necessários a cada bolha na primeira versão do DFD? 13.
Se um evento for dirigido por fluxos, quantos fluxos de dados de
entrada deve receber a bolha que processa esse evento? 14.
Quais são as diretrizes dc verificação dc consistência que o analista
de sistemas deve seguir ao desenhar a primeira versão do DFD do modelo comportamental? 15.
Como deve ser desenhada a primeira versão do DFD para o caso
de um evento que produz múltiplas respostas? 16.
Sob que condições pode urna bolha única na primeira versão do
DFD estar associada a mais dc um evento? 17.
Na primeira versão do DFI), como as bolhas comunicam-se entre
si? Isto é, como a saída produzida por uma bolha torna-se a entrada de outra bolha? 18.
Como a primeira versão do l)Fl) mostra a sincronização de eventos
múltiplos, assmncronos e interdependentes? 19.
O que deve ser desenvolvido primeiro: a primeira versão do DFD
ou a primeira versão do modelo de dados (I)ElO? Por que? 20.
O que o analista dc sistemas dcvc fazer com a primeira versão do
DFD e do DER depois de havê-las completado? 21.
Quando a primeira versão do I)FD está pronta, deve ser revista
com o usuário? Por quê? 450 22. O que está errado na primeira versão dc DFD abaixo? 23. O que está errado na primeira versão de DFD abaixo? crédito o)
PROCESSAR o TO o w o LISTA DE EVENTOS (do modelo ambiental) 1. Cliente pede item. 2. Cliente devolve um item. 2. Cliente efetua pagamento. 451 20 COMO COMPLETAR O MODELO COMPORTAMENTAL Dêem-nos as ferramentas e completaremos nossa tarefa. Winston Churchill, transmissão radiofônica, 194 Neste capítulo, aprenderemos: 1. Como subdividir um DFD inicial em níveis deforma ascendente. 2. Como ocultar depósitos dc dados locais. 3. Quando e como subdividir dc forma descendente as bolhas de um DFD inicial. 4. Como completar o dicionário de dados inicial. 5. Como completar as especificações dc processos. 6. Como completar o modelo de dados. 7. Como completar o diagrama de transições de estado. No capítulo anterior, apresentei um estratégia para desenvolver uma versão inicial do modelo comportamental. Entretanto, é evidente que aquele modelo não pode ser apresentado ao usuário para verifica ção. Por que não? Em primeiro lugar porque ele é complicado demais. Como vimos no capítulo 19, o DFD preliminar terá um processo para ca da evento que identificamos no modelo ambiernal; assim, ele pode ter 40 cu 50 bolhas, e possivelmente mais. Dc maneira semelhante, a versão inicial do DER é provavelmente muito tosca para ser revista com os usuá rios; como discutimos no capítulo 12, é necessário algum refinamento para eliminar os objetos desnecessários e/ou acrescentar novos objetos. 453
Existe um segundo problema com o modelo: ele é composto po muitos gráficos, com pouco ou nenhum suporte textual. Embora o dia grama de fluxo de dados e o de entidades-relacionamentos sejam exce lentes veículos de apresentação dc uma vista geral do sistema a usuário eles necessitam do apoio de um dicionário de dados e de um conjunt completo de especificações dc processos. 20.1 COMO COMPLETAR O MODELO DE PROCESSOS 20.1.1 A Subdivisão do DE!) em Níveis O primeiro passo é reorganizar o DFD que desenvolvemos no capítulo 19. Como vimos, ele compõe-se de um único nível, com dema siadas bolhas. Então, precisamos subdividir o I)FD em níveis ascenden tes. Isso quer dizer que desejamos agrupar processos relacionados em agregados significativos, cada um representando uma bolha de um dia grama de nível mais elevado. Isso é ilustrado na figura 20.1. Existem três diretrizes que você deve ter em mente ao fazer isso: 1. Cada agrupamento de processos deve envolver respostas estrei tamente relacionadas (lembre-se que cada bolha no DFD preliminar tem um nome relativo á resposta a um evento da lista de eventos). Isso habitualmente significa que OS processos lidam com dados estreitamente relacionados. 2. Procure oportunidades para ocultar, ou “sepultar”, dados arma zenados que apareçam no nível inferior. Assim, se você en contrar um grupo de processos no DFD preliminar relativo ao mesmo depósito, sem que oulros processos no DFD preliminar se refiram a esse depósilo, então você deve criar uma bolha em nível mais alto que oculte aquele depósito. Isso é ilustrado na figura 20.2. 3. Lembre-se de que a pessoa que examinar seus diagramas de fluxo de dados, seja ela um usuário ou um analista de sistemas, não quer ver tudo de uma só vez. lm face disso, você deve criar agregados ou grupos provenientes do DFD preliminar com postos por cerca de 7 mais ou menos 2 fragmentos de informa ção, onde um pr»c (e os fluxos que lhe sejam relacionados) ou um depósito possa ser considerado um fragmento Isso, naturalmente, significa qu )odemos precisar de algum esfor ço de subdivisão em níveis ascendentes. Por exemplo, se começamos 454 1
RESULTADO DA SUBDIVISÁO
EM NÍVEIS ASCENDENTES DFD PRELIMINAR Figura 20.1: Subdivisão de um DFD em níveis ascendentes com um DFD preliminar que tinha (para fins de argumentação) 98 processos e organizamos o diagrama em grupos de 7 bolhas (ignorando, para favorecer a simplicidade, todos os depósitos), poderíamos criar um diagrama de nível mais alto com 14 bolhas, cada uma delas representan do uma “abstração” de sete bolhas do n inferior. Mas 14 bolhas é um número elevado para se manipular e muito grande para ser mostrado ao usuário de uma só vez; desse modo, nós possivelmente criaríamos um diagrama de
nível ainda mais elevado, como na figura 20.3, com apenas duas bolhas. Observe que este exemplo envolve números inteiramente artifi ciais. Você não deve orientar sua atividade de subdivisão em níveis de forma a garantir que cada diagrama tenha exatamente sete bolhas! Na verdade, as duas primeiras diretrizes acima citadas, agrupar bolhas se gundo os dados comuns e buscar oportunidades de ocultar depósitos 455 RESULTADO DA SUBDIVIS EM NÍVEIS ASCENDENTES DFD PRELIMINAR Figura 20.2: A ocultação de um deposito local no nivel superior locais, devem ser sua principal base lógica para a subdivisão em nívei ascendentes, e não uma lei aritmética. Observe ainda que você também pode precisar fazer subdivisõe em níveis descendentes. Isto é, os processos idcntifkados no DFD preli minar podem não ser processos primitivos e exigirem subdivisões par baixo, em DFD de níveis inferiores. Isso significa apenas que os proces sos iniciais, cada um dos quais é responsável pela produção da respost a um evento, podem ser demasiadamente complexos para serem descri tos em uma especificação de processos de uma página. Isso muitas ve zes torna-se evidente quando se examina cuidadosamente o processo ou quando se solicita ao usuário uma explicação do que a bolha dev fazer. Se o usuário hesitar por um instante, inspirar profundamente 456 Figura 20.3: Mú1t subdivisões ascendentes de um DFD disser “Bem, é uma longa história, mas é mais ou menos o seguinte é uma boa indicação de que aquela bolha preliminar terá de ser subdividida! Em outros casos, a necessidade dc subdividir cm níveis no sentido descendente pode não se tornar evidente até que você realmente tente redigir a espccifkação de processos; se você notar que já escreveu três FIGURA o (duas bolhas> lesultado da primeira su bdivisáo m níveis ascendentes (14 bolhas) o o o o o DFD preliminar (98 bolhas) o
o 457 páginas sobre uma bolha preliminar e ainda há mais, muito mais a se escrito, é outra indicação da necessidade da subdivisão. Eis algumas diretrizes para a subdivisão em níveis descendentes: Em alguns casos, a abordagem de decomposição funciona pura é adequada. Isto é, se você encontrar uma bolha de proces. so que execute uma função complexa, tente identificar sub. funções, cada uma das quais podendo ser uma bolha de níve, mais baixo. Suponha, por exemplo, que tenhamos um processc chamado “Ajustar trajetória do míssil”; ele poderia ser a bolha responsável pela manutenção dc um evento temporal em uni sistema de direção dc mísseis cm tempo-real. A função geral de ajustar a trajetória do míssil poderia ser decomposta em vária5 subfunções: Calcular a variação da coordenada x. - Calcular a variação da coordenada y. - Calcular a variação da coordenada z. - Calcular o novo fator de “arrasto” atmosférico. - Calcular a nova velocidade do vento. - Calcular força de impulsão da coordenada x. - Calcular força de impulsão da coordenada y. - Etc. • Em outros casos, os fluxos de dados que chegam e que saem da bolha darão a melhor indicação para a subdivisão em níveis descendentes. Por exemplo, suponha que tenhamos uma bolha como a da figura 20.4. É provável que um DFD de nível inferior possa ser criado com a forma geral mostrada na figura 20.5. Evidentemente, pode ser necessário mais de uma bolha para combinar ou agregar os elementos de dados, mas a idéia é a mesma: deti os dados seivirein de guias. Enquanto você estiver envolvido com a atividade de subdivídir os níveis de maneira ascendente ou descendente lembre-se da impor tância do equilíbrio. Isto é (como vimos no capítulo 14), é preciso veri ficar se as entradas e saídas de urna bolha de um determinado nível 458 x p correspondem às entradas e saídas dc um diagrama do nível ime diatamente inferior. Para ver um exemplo da atividade de subdivisão ascendente, leia o estudo de caso do Sistema dc Informações da YOURDON Press no apêndice F. Naquele caso começamos com um DFD preliminar contendo 40 bolhas; tornou-se necessário um nível de ;ubdivisão ascendente, conduzindo-nos a um DFD da figura O com nove olhas.
Figura 20.4: Decomposição de uma bolha complexa em níveis descendentes entrada intermediária (X’) Figura 20.5: O DFD de nível inferior 459 20.1.2 Como Completar o Dicionário de Dados Quando você começou a desenvolver o DFD preliminar no capí tulo 19, deve também ter iniciado o desenvolvimento do dicionário d dados; na verdade é bastante comum começar-se o dicionário de dado quando o diagrama de contexto está sendo desenvolvido. Entretanto, dc ainda está longe de estar completo. Normalmente, ainda será necessáric fazer a descrição do st dc cada itcm de dado; por uma questãc de clareza,podc também ser necessário dividir os itens de dados comple xos em subitens. Quando o dicionário de dados estiver ficando pronto, é precisc verificar se ele está consistente e completo. Inspecione-o para ver se está internamente consistente (cx.: se uma parte do dicionário não contra- diz alguma outra parte). Certifique-se também que o dicionário está equilibrado em relação ao diagrama de fluxo de dados em níveis, ao dia grama de entidades-relacionamentos e às especificações de processos. 20.1.3 Como Completar as Espec de Processos Quando desenvolvemos o diagrama de fluxo de dados preliminar, utilizando a abordagem da subdivisão dc eventos mostrada no capítulo 19, há grandes possibilidades dc que não tenhamos feito qualquer espe cificação de processo. Poderá haver algum caso de uma determinada especificação ter sido esboçada face a um interesse particular de sua parte ou de parte do usuário, mas sua principal preocupação será apenas com a preparação do próprio DEr). Na verdade, muitas vezes é uma má idéia gastar tempo com a escrita de especificações de processos antes que o DFD esteja pronto, porque o desenvolvimento inicial do I)Fl) está sujeito a muitas modifica ções, correções e revisões. As bolhas podem aparecer, desaparecer, ser movidas e rebatizadas. Quando o DFD preliminar começa a se assentar e passa pelo teste da subdivisão cm níveis ascendentes (isto é, essa ativi dade não descobre maiores falhas no modelo), você pode começar a redigir as especificações de processos. Esse trabalho é muitas vezes prolongado e consumidor de tempo, porque cada bolha do nível mais baixo do I)FD exige uma especificação de processo. Desse modo, pode ser possível a um grupo de dois ou três analistas de sistemas desenhar algumas dezenas de DFD; mas será neces sário um grupo maior de analistas para completar todas as especificações. de processos em tempo satisfatório. Quando as especificações de processos estiverem prontas, devem ser equilibradas e passar por uma verificação cruzada em relação ao 460 [ de dados e ao DER, observando-se as diretrizes apresentadas Lo capítulo 14. O.2 COMO COMPLETAR O MODELO DE DADOS Como dissemos no capítulo 12, o DER é desenvolvido em uma nodalidade um tanto
semelhante à que foi apresentada sobre o DFD: sboçamos um DER e depois o refinamos e melhoramos. Grande parte lo melhoramento é feita designando-se ou atribuindo-se elementos de lados aos adequados tipos de objetos; isso costuma ser uma boa aju la na identificação de novos tipos de objetos ou de tipos de objetos lesnecessários. Lembre-se, contudo, que o DER muitas vezes é desenvolvido mais )u menos ao mesmo tempo que o DFD. É muito comum encontrar tlguém (ou um pequeno grupo) da equipe de projeto trabalhando no )ER, enquanto outra pessoa (ou um outro pequeno grupo) trata do )FD. Ou então o DFD pode ser desenvolvido pela equipe de projeto, nquanto o DER é desenvolvido por um grupo de administração centra izada de dados dentro da organização de PED. Em qualquer que seja ) caso, se o DER e o DFD forem desenvolvidos aproximadamente ao mesmo tempo, o conhecimento adquirido com o DFD (existência de Jepósitos, fluxos de dados etc.) pode muitas vezes ser usado para refinar fazer verificações cruzadas do DER O.3 COMO COMPLETAR O DIAGRAMA DE TRANSIÇÕES DE ESTADO Se o seu sistema possuir características de tempo-real, você desen olverá um diagrama de transições de estado em acréscimo ao DFD e ao J.iagrama de entidades-relacionamentos. O conhecimento detalhado do :omportamento do sistema poderá ajudá-lo a refinar esse modelo. Como Jissemos no capítulo 13, você deve examinar o diagrama inicial de tran ições de estado em busca dos seguintes tipos comuns de erros: • Todos os estados foram definidos? • Todos os estados podem ser atingidos? • Pode-se sair de todos os estados? • O sistema responde adequadamente, em cada estado, a todas as condições possíveis? 461 20.4 RESUMO Atingimos, aqui, o final do modelo essencial. Se você acompanho todas as etapas dos capítulos 18, 19 e este capítulo, deve estar de poss de um modelo completo, detalhado, formal e rigoroso de tudo o que sistema deve fazer para satisfazer os requisitos do usuário. Ele contén todos os itens abaixo: • Diagrama de contexto • Lista de eventos • Declaração de objetivos • Um conjunto completo de diagramas de fluxo de dados ezr níveis • Diagrama de entidades-relacionamentos terminado e completo • Um conjunto completo de diagramas de transições de estado • Dicionário de dados completo (para a fase de análise dc projeto)
• Um completo conjunto de especificações de processos, con uma especificação para cada processo do nível mais baixo. Presumindo que você tenha revisado os componentes da especi. ficação para certificar-se de que estão completos e consistentes e que c usuário revisou e aprovou o documento, você terminou. Você pode passar um belo laço vermelho em volta do pacote e entregá-lo à equipe de projeto/programação cuja tarefa será construir o sistema. Em seguida, pode recolher-se ao aconchegante conforto de seu escritório até que suna o próximo projeto. Mas, espere! Ainda há uma última etapa. Tudo o que desenvol vemos no modelo essencial pressupunha a existência de perfeita tecno logia, mas também que o usuário não teria restrições de implementaçãc a impor ao sistema. Perfeita tecnologia é uma fantasia de nossa ima ginação, mas podemos deixar que a equipe de implementação decida como alcançar um compromisso razoável coma tecnologia existente. A idéia de que o usuário vai ignorar todas as restrições de imple. mentação também é uma fantasia, com a qual teremos de lidar ante5 de passarmos a versão final da especificação para a equipe de imple mentação. Essa atividade final, que deve ser feita com a colaboração do 462 usuários, dos analistas e de al,guns membros da equipe de implemen tação, é o desenvolvimento do modelo de implementação do usuário. Esse assunto será discutido no próximo capítulo. PERGUNTAS E EXERCÍCIOS 1. Por que a primeira versão do modelo comportamental não pode ser apresentada ao usuário? 2. A primeira versão do modelo comportamcntal é completa? Se não é, que elementos lhe faltam? 3. O que significa subdivisão em níveis ascendentes no contexto des te capítulo? 4. Qual é a base lógica que o analista de sistemas deve usar para agrupar bolhas cm um DFI)? 5. Quais são as três diretrizes que o analista dc sistemas deve lembrar ao fazer uma subdivisão em níveis ascendentes? 6. O que significa o conceito de ocultação de dados armazenados no contexto deste capítulo? 7. Quantos níveis de DFD dc nível mais elevado devem ser criados a partir de um único DFD de primeira versão? Existe alguma fórmula matemática que possa ser utilizada para dar uma aproximação do número necessário de níveis? 8. Sob que condições a subdivisão de um DFD em níveis descenden tes torna-se necessária? 9. É possível que o analista de sistemas precise executar a subdivisão de um DFD em níveis ascendentes e descendentes? Por quê? 10. Por que o dicionário de dados normalmente deve estar pronto du rante o estágio de
desenvolvimento do modelo comportamental? 11. Que tipo de verificação de erros deve ser feita no dicionário de dados durante esse período do projeto? 12. Por que muitas vezes não é uma boa medida que o analista de sistemas despenda tempo redigindo especificações de processos antes que o DFD preliminar esteja completo? Sob que condições faria sentido escrever pelo menos algumas especificações? 13. Quais são os oito principais componentes do modelo terminado dos requisitos do usuário? NOTAS 1 Esse número aparentemente arbilrário (sete mais ou menos dois) é uma diretriz para controlar a complexidade em diversas situações de resolução de problemas. Ela se fundamenta na obra de George 463 Milier, que foi o primeiro a perceber a dificuldade das pessoas err lidar com múltiplos fragmentos de informação, em um clássico ar tigo intitulado “The Magical Number Seven, Plus or Minus l’wo Some Limits on Our Capacity for Processing Information”, publica do em Psycholo Revíew, Volume 63 (1956), pgs. 81-97. 2 O ideal é que os modelos I)ER e 1)1:1) sejam desenvolvidos pelc mesmo grupo, trabalhando cm conjunto. Isso evita problemas d comunicação, e tende a garantir que seja dada a mesma ênfase a ambos os modelos. Infelizmente, isso raramente acontece no mun do real. 464 21 O MODELO DE IMPLEMENTAÇÃO DO USUARIO Deve ser observada uma simplicidade espartana. Nada poderá ser feito apenas porque contribui para a beleza, conveniência, conforto ou prestígio. Office of lhe ChiefSi.gnal Offícer, U. S. Ar?ny, 29 de Maio de 1945 Neste capítulo, aprenderemos: 1. Como escolher as fronteiras da automatização para um sistema. 2. Como selecionar os dispositivos de entrada e os dis positivos de saída para o usuário. 3. Como desenvolver os formatos dc entrada e os for matos de saída. 4. Como projetar formulários para o sistema. 5. Como desenvolver esquemas de codificação para entradas de sistemas. 6. Como identificar atividades manuais de suporte.
7. Como descrever as restrições operacionais do sistema. Ao finalizarmos o último capítulo terminamos o desenvolvimento do modelo essencial de um sistema dc informações. Esse modelo con tém uma descrição completa do que o sistema deve fazer para satisfazer o usuário. Especificamente o modelo essencial descreve: 465 1 • A ação essencial ou lógica das funções que devem s executadas. • O conteúdo essencial dos dados armazenados pelo sistema que se movimentam através dele. • O comportamento essencial tempo-dependente que o sistern deve exibir para lidar com os sinais e as interrupções do arr biente externo. No melhor de todos os mundos (do ponto dc vista do analista d sistemas e da equipe de implementação), isso representa informaçõc suficientes para os projetistas e programadores: nós simplesmente lhc daremos o modelo essencial e os deixaremos escolher o melhor harc ware, o melhor sistema opcracional, o melhor sistema de gcrcnciament de banco de dados e a melhor linguagem de programação, dentro da restrições gerais de tempo, dinheiro e recursos humanos para o projetc Entretanto, isso não é tão simples: em virtualmente todos os projeto de desenvolvimento dc sistemas, o usuário insistirá em que se incluar informações adicionais. Essas informações adicionais envolvem problemas de imp1emei lação - mas problemas de implementação que sejam suficientementi importantes e que tenham impacto suficiente na capacidade do usuári em utilizar o sistema para que precisem ser especificados agora. O pro biema mais evidente de implementação de interesse do usuário é a fron teira da automatização, isto é, que partes do modelo essencial serã implementadas em computador, e que partes serão executadas manual mente na organização do usuário? O analista de sistemas pode ter um opinião sobre isso, e o grupo projetista/programador pode também que rer exprimir sua opinião, mas este, naturalmente, é um problema sobre qual o usuário tem a última palavra. De modo análogo, ofonnaio das entradas do sistema (também co nhecido como interface humana) é de grande interesse para o usuário- muitas vezes, ele parece ser dc interesse maior do que as funções dc sistema! Desde que os sistemas dc processamento começaram a gerai relatórios impressos, os usuários têm manifestado fortes opiniões sobre organização e o layout das informações do relatório. Onde devem ficai os números das páginas? Onde devem ser colocados os títulos das pá ginas? Como deve ser arrumada cada linha de informação para máxima legibilidade? Deve haver um resumo ou um subtotal ao final de cada página ou somente ao final do relatório? E assim por diante. Com o advento dos sistemas on-line nos anos 70, esse problema expandiu-se incluindo o interesse do usuário na formatação das telas dc entrada do terminal de vídeo. Onde devem ser apresentadas na tela as
466 mensagens de entrada? Que espécies de mensagens de erros devem ser exibidas? Como o usuário deverá mover-se de uma tela para outra? Mais recentemente diversas outras opções e possibilidades vieram aumentar a importância desses problemas de implementação do usuário: Os usuários finais muitas vezes têm a oportunidade de usar computadores pessoais (PC) como parte de uma rede distribuí da de computadores (p.ex., são-lhes dados PCs interligados ao computador de grande porte da organização). Isso levanta uma série de questões: que partes do mode essencial serão desig nadas para o PC (sob controle do usuário) e quais ao main frame? Que partes dos dados serão designadas para o PC e que partes ao mainframe? Qual será o formato da entrada que o usuário fornecerá ao PC? Quais as atividades adicionais de apoio que devem ser oferecidas para assegurar que o usuário não danifique inadvertidamente os dados do PC ou do mainframe? Os usuários finais atualmente estão tendo cada vez mais opor tunidades para escrever seus próprios programas em linguagens de quarta geração como FOCUS, NOMAD e IDEAL em computa dores de grande porte, ou dBASE-III e Rbase-5000 nos PCs. À proporção que se envolvem com tais problemas de implemen tação, eles precisam especificar os formatos das entradas e saídas do sistema. E mais, eles podem querer decidir que partes do sistema serão implementadas usando linguagens de quarta geração e que partes serão implementadas com linguagens con vencionais de terceira geração Em muitas situações hoje em dia, o usuário e o analista de sis temas podem decidir prototipar partes do sistema, usando ou uma linguagem de quarta geração de alto nível ou um pacote gerador de aplicações. A prototipação pode ser feita porque o usuário está inseguro da ação detalhada que eventualmente terá de ser escrita nas especificações de processos do modelo essen cial; porém, a atividade de prototipação está, na maioria das vezes, interessada na exploração e experimentação com forma tos de entrada, diálogos on-line e formatos de saída para telas e relatórios. • Para muitas aplicações da empresa, uma opção disponível ao usuário é a escolha e aquisição de um pacote de software, isto é, um produto de software que pode ser utilizado sob licença ou adquirido de um fornecedor. Nesse caso, os mesmos problemas de implementação são importantes para o usuário: que partes 467 das funções essenciais serão implementadas pelo pacote adqui rido e que partes terão dc ser executadas pelo usuário (ou im plementadas pelo setor dc SIG do usuário como um sistema se parado)? Que partes dos dados essenciais serão mantidos pek pacote e que partes terão dc ser mantidas pelo usuário? serão a forma e a seqüência das entradas exigidas pelo sistem adquirido e serão elas aceitáveis E’ problemas devem ser tratados como parte do modelo de Im plementa do usuário. Eles podem ser originados pelo aumento, pek inclusão de observações e pela revisão do modelo essencial, como ve remos nas seções subseqüentes deste capftulo. Recomendo, entretanto que você mantenha sempre intacta uma cópia do modelo essencial origi na!; isto permitirá que você experimente modelos alternativos de imple mentação do usuário
no futuro. Em termos gerais, o modelo dc implementação do usuário abrang os quatro aspectos seguintes: . A alocação do modelo essencial a pessoas versus máquinas. 2. Detalhes da interação homem/máquina. 3. Suplementares atividades manuais que podem vir a se necessárias. 4. Restrições operacionais que o usuário deseja impor ao sistema. Todos esses aspectos serão discutidos cm maiores detalhes seguir. 21.1 A DETERMINAÇÃO DOS LIMITES DA AUTOMATIZAÇÃO Lembre-se de que o modelo de sistema em que estamos traba lhando neste momento identifica todas as atividades (funções) essenciai e todos os dados essenciais. A pergunta a esta altura : que funções que dados serão manipulados manualmente, e quais serão automatiza dos? Embora possa ter havido uma experimental escolha preliminai dos limites da automatização durante o estudo de viabilidade não de. vemos considerá-los como fixados. Na realidade, o limite da auta matização é quase irrelevante no modelo essencial, pois embora c usuário obviamente deseje que desenvolvamos um sistema auto matizado, ele também necessita de uma bem elaborada declaração dc 468 requisitos das funções e dos dados que ficarão fora das frontLiras da automatização. Existem três casos extremos que mencionaremos sucintamente: O usuário pode não se importar com onde esteja a fronteira da automatização. É improvável que isso aconteça, mas é uma possibilidade teórica. Na prática, o usuário solicita à equipe de implementação, “Diga-me que partes do sistema devem ser manuais ou automatizadas”. Além do fato de que o usuário normalmente tem grande sensibilidade sobre esse problema, es pera-se que o analista de sistemas produza (como produto se cundário do seu trabalho) uma análise revisada de custo/be nefício de todo o projeto. Isso costuma exigir pelo menos al guma decisão preliminar de que partes do modelo essencial serão automatizadas e quais serão manuais. O usuário pode optar por um sistema inteiramente automati zado. Essa é uma situação muito comum, principalmente se o sistema estiver sendo desenvolvido para substituir um outro sis tema já existente e suas fronteiras não serão alteradas. Desse modo, as atividades manuais executadas pelo usuário podem já estar fora dos limites do sistema representadas no diagrama de contexto como terminadores com os quais o sistema se comunica. • O usuário pode optar por um sistema inteiramente manual. F.ssa é uma opção bastante incomum, especialmente nesta era da automatização, pois o analista dc sistemas habitualmente tem interesse em computadorizar o quanto for possível. Entretanto, isso pode ocorrer em ocasiões cm que a intenção expressa do usuário não seja computadorizar coisa alguma, mas simples mente reorganizar a maneira com as atividades estejam presen
temente sendo executadas em uma organização. Normalmente, esses casos extremos não ocorrem; com base nas interações entre o usuário, o analista de sistemas e a equipe de imple mentação, algum acordo será ajustado. Isto é, al,guinas das atividades do modelo essencial serão automatizadas, e outras serão identificadas como funções manuais; de forma análoga, alguns dos dados essenciais serão identificados como candidatos certos para computadorização (sendo, presumivelmente, colocados sob o controle de uma organização de SIG) e alguns serão deixados sob o controle direto do usuário. A menos que o usuário faça uma escolha imediatista e arbitrária por ordem, será aconse lhável que as trê.s partes (o usuário, o analista dc sistemas e a equipe de 469 implementação) examinem diversas opções. Como as figuras 21.1(a), (b e (c) demonstram, pode haver diversas alternativas razoáveis para detei minar o limite da automatização. Cada alternativa terá custos diferente (em cuja estimativa a equipe de implementação deve auxiliar, uma ve PARTE MANUAL Figura 21.1 (a): Uma opção para afronteira da automatização Figura 21.1 (b): Outra opção para os limites da automatização 470 PARTE AUTOMATIZADA Figura 21.1 (c): Uma terceira opção para os limites da automatização que eles têm o conhecimento das possibilidades da tecnologia de imple mentação) e ramificações organizacionais diferentes na área do usuário. A tarefa de determinar os limites da automatização não é da alça da do analista de sistemas e nem da equipe de implementação; ela é, em última análise, da responsabilidade do usuário, e este livro não apresentará qualquer diretriz para determinar qual seria a melhor escolha. Mas, observe como o modelo essencial serve como uma útil ferramenta para o usuário e para a equipe de implementação exami narem as diversas opções. Uma vez que a fronteira da automatização tenha sido escolhida, o analista de sistemas pode pensar que ele tem o privilégio de eliminar os processos manuais e dados manuais (isto é, as bolhas e depósitos que não serão automatizados) sem maiores con siderações. Porém, geralmente não é assim. No caso mais simples, as ati vidades e dados manuais podem ter de voltar para os terminadores que envolvem o sistema, como ilustrado nas figuras 21.2(a) e (b). Mas, em geral, o analista de sistemas deve reconhecer que mesmo as atividades manuais fazem parte do novo sistema. Portanto, o analista pode ter de escrever procedimen para que os membros da comunida de usuária saibam como executar as funções requeridas. E o analista pode ter de fornecer alguma orientação na organização de depósitos que não
serão automatizados Observe que esse aspecto do modelo de implementação do usuário precisa apenas que sejam feitas observações no DFD e no PRD para indicar quais atividades e dados são manuais e quais são automatizados. 471 PARTE UTOMATIZADA Figura 21.2 (a): Um modelo essencial com os limites da automatização Figura 21.2(b): As atividades manuais foram colocadas dentro dos terininadores 472 Observe que quando se determinam as fronteiras da automatiza ção pode ser importante considerar alguns problemas ambientais; volu me do som, radiação, iluminação, aspectos ergonômicos do terminal de vídeo, espaço de trabalho e assim por diante. Quase sempre o novo sistema desorganiza o ambiente normal dc trabalho do usuário (p.ex., ele fará com que um terminal dc vídeo seja colocado na mesa do usuá rio, onde nunca tinha existido um antes) Ou pode introduzir atividades de processamento de informações em um ambiente onde nunca tinham sido executadas essas atividades antes (ex., um piso dc fábrica em um ambiente de manufatura). Assim, é importante garantir que esses fatores humanos tenham sido cuidadosamente estudados antes da determina ção final das fronteiras da automatização. O usuário muitas vezes tem importantes opiniões a expressar sobre esses aspectos, porém se ele não tiver experiência anterior em sistemas dc informações, pode não ser capaz de adiantar quais serão os problemas. Você pode se aconselhar com Outros profissionais dc sistemas que desenvolveram e instalaram sistemas semelhantes em iguais condições ambientais. Para finalizar, observe que uma vez que tenha sido decidida a fronteira da automatização, pode ser necessário aumentar o modelo es sencial para mostrar como dar partida no sistema e como terminá-lo; o modelo essencial mostra somente o comportamento “steady-state” do sistema, e pressupõe que o sistema esteve sempre funcionando e assim continuará para sempre. Desse modo, podemos precisar incluir processos (bolhas no DFD), fluxos de dados e depósitos adicionais para mostrar as atividades inicializadoras e tcrminadoras do sistema; isso pode incluir relatórios para a direção (ou para os usuários ou para o de partamento de operações) sobre as características operacionais do sistema. 21.2 A DETERMINAÇÃO DA INTERFACE HUMANA A atividade mais consumidora dc tcmpo e na qual o usuário estará mais interessado, é provavelmente a especificação da interface humana. Isso envolve quatro problemas relacionados: 1. A escolha de dispositivos dc entrada e saída (p.ex., terminais de vídeo, dispositivos de k’itura ótica, cartões perfurados etc. para entrada e relatórios impressos, imagens na tela do monitor, ou luzes piscantes como saída). 2. O formato de todas as entradas que fluem dos terminadores para o sistema. 473
3. O formato de todas as saídas que fluem de volta do sistema para os terminadores. 4. A seqüência e o “timing” de entradas e saídas em um sistema on-line. 21.2.1 Dispositivos de Entrada e Saída A escolha dos dispositivos de entrada e saída pode ser imposta pelos terminadores externos ao sistema; por exemplo, se o sistema pro duzir relatórios de saída a serem enviados ao governo, pode não haver outra escolha senão produzir relatórios impressos. Os dispositivos que costumam ser usados para entrada de dados incluem: Cartões perfurados. Os cartões perfurados foram a forma mais comum de entrada de dados, porém são raramente utilizados atualmente, exceto em alguns sistemas batch de processamento muito grandes. Uma vantagem dos cartões perfurados é que eles podem ser usados como documentos fonte pelo usuário externo (p.ex., considere os cheques produzidos por alguns sistemas do governo; eles são documentos negociáveis, mas também são usados como entrada direta para um sistema de processamento). As maiores desvantagens dos cartões perfurados são o tamanho volumoso, capacidade limitada de armazenamento de dados, o fato de só poderem ser utilizados uma vez e a suscetibilidade a erros do operador. • Fita magnética. A fita magnética pode ser uma forma apro priada de entradas provindas de outros sistemas; ela também pode ser um meio adequado de entrada se o usuário dispuser de um dispositivo de entrada de dados teclado-fita. A principal vantagem desse recurso é, naturalmente, que o volume de da dos de entrada que pode ser armazenado em uma fita é muito maior que em um cartão; a desvantagem é que os dados não podem ser manipulados com facilidade, uma vez que eles estão gravados na fita. O cartão perfurado, por outro lado, é mais pri mitivo, mas oferece ao usuário a possibilidade de rearrumar os cartões ou anular alguns deles (jogando-os fora) antes de sub metê-los ao sistema. • Discos flexíveis. Com o aparecimento dos computadores pes soais no início dos anos 80, os discos flexíveis tornaram-se uma forma popular de meio de entrada. Os dados normalmente são 474 gravados nos discos flexíveis pela interação off-line com um computador pessoal (por off-line queremos dizer que a ati vidade não tem conexão com o sistema de informações em de senvolvimento). Um disco flexível comum pode armazenar entre 360.000 e 1.2 milhões de caracteres; isso não é tanto quanto uma fita magnética, mas é satisfatório para muitas apli cações de tamanho médio. Terminais e computadores pessoais. Os terminais de vídeo, tor naram-se um dos mais comuns meios de entrada durante os últimos dez anos à medida que o preço caiu de $3000 (ou mais) para $300 (ou menos). É importante distinguir entre os terminais comuns (não inteligentes) que não oferecem nada além de um teclado e uma tela, os terminais inteligentes que oferecem diver sos recursos de edição local e capacidade de armazenamento local e os computadores pessoais, que têm capacidade de ar
mazenamento muito maior e todos os poderes computacionais de um computador de emprego geral. Terminais inteligentes e PCs possibilitam que o usuário faça alterações e corrija erros triviais imediatamente, em vez de esperar pela demora do envio das entradas através de linhas de telecomunicações ao computa dor principal; a capacidade de armazenamento local torna possível ao usuário introduzir um grande volume de entradas, ainda que o sistema principal de processamento não esteja operacional durante todo o tempo. Leitoras óticas e leitoras de códigos de barra. Leitoras óticas e leitoras de códigos de barra podem ler informações impressas ou codificadas em vários tipos de documentos; isso é especial mente vantajoso para aplicações como a cobrança em uma loja, onde o usuário precisa introduzir o código e outros dados rele vantes sobre um produto. Como esses dispositivos podem ler diretamente os dados, elimina-se a necessidade de o usuário digitar manualmente os dados em um terminal. Algumas leitoras óticas podem ler documentos datilografados da forma normal e algumas podem ler documentos manuscritos. A maior desvan tagem desse tipo de meio de entrada é o seu custo; outra des vantagem é sua tendência a erros. • Telefone. Para algumas aplicações, o telefone Touch-Tone pode ser um meio de entrada apropriada 6• Isso é particularmente van tajoso para os sistemas que devem lidar com o público em geral: poucas pessoas têm um terminal ou um PC em suas casas, mas aproximadamente 98% da população dos Estados Unidos têm 475 / pelo menos um telefone cm suas casas. Uma vez que o telefone somente fornece entradas numéricas, as aplicações são um tantc limitadas; ele é prático para situações onde o usuário necessita fornecer informações como um número de conta, mas não prático para situações que requerem entrada de texto. Entrada de voz. Para finalizar, alguns sistemas podem usar a voz humana como meio de entrada. A tecnologia de entrada de voz no final dos anos 80 é capaz de reconhecer um vocabulário com algumas centenas de palavras para um usuário individual; esse recurso precisa ser reensinado para cada novo usuário. As vantagens desse meio dc entrada são óbvias; as desvantagens, no momento atual, são (1) o custo do dispositivo, (2) seu voca bulário limitado, (3) o longo tempo dc resposta e (4) problemas reais se a voz do usuário se alterar significativamente por causa de um resfriado ou por outros motivos. Assim como o usuário tem a opção de escolher entre diversos meios diferentes de entrada para seu sistema, existem vários meios possíveis de saída. Os meios mais comuns usados para saída são os seguintes: Saída impressa. A forma mais comum de saída em sistemas de processamento, hoje, é, de longe, a saída impressa. Ela pode ser produzida em vários dispositivos: impressoras de matriz de ponto (muitas vezes ligadas ao terminal utilizado para entrada), impressoras de linha de alta velocidade, impressoras laser de alta velocidade, impressoras pessoais a laser, impressoras pes soais de margarida e outras. A principal vantagem da saída im pressa é que ela é um documento permanente, que pode ser usado em diversas aplicações
externas ao sistema. As desvan tagens dos relatórios impressos são o seu volume, a probabili dade de que serão impressas mais informações (ou mais có pias de informações) do que é realmente necessário, e a rela tivamente baixa velocidade com que as informações são produzidas. • cartões perfurados. Assim como os cartões perfurados podem servir como meio de entrada, também podem servir como meio de saída. Como já foi mencionado, OS cartões perfurados podem ser usados como documentos legais; como Marjorie Leeson afirma ILeeson, 19811, os cartões perfurados podem servir como um “documento de turnaround” (isto é, um documento que é 476 enviado para fora do sistema a um terminador externo e depois torna-se entrada para o sistema a partir do mesmo terminador). Mas, de um modo geral, os cartões perfi.irados são volumosos e não podem abrigar muita informação; e, por isso, não são usa dos na maioria dos sistemas de informações atuais. Terminal. Os sistemas on-line que usam terminais como meio de entrada costumam utilizá-los também como meio de saida. A vantagem do terminal é que ele pode exibir uma quantidade substancial de informações em alta velocidade; com terminais modernos, podemos exibir combinações práticas de texto e gráficos. A principal desvantagem do terminal é que ele não representa uma saida impressa; a saída é transiente e é perdida ao ser exibida a tela seguinte. • Saída de zxz Para algumas aplicações, a voz é um meio ade quado de saída. Isso é verdadeiro em aplicações onde o telefone é usado como um meio de entrada (veja acima); o mesmo tele fone pode ser usado para conduzir a saída de voz para o usuá rio. Alguns terminais também são equipados com dispositivos de saída de voz, ainda que isso seja um tanto raro. A principal vantagem da saída de voz é que ela pode ser usada para con duzir breves mensagens de saída em um ambiente (ex.: um dis positivo de manufatura) onde o usuário possa não ter oportuni dade de ler saídas impressas. • Plotador. Um plotador é normalmente usado para produzir dia gramas e desenhos grandes e intricados (p.ex., desenhos arqui tetônicos e impressos em azul). Desenhos que se acomodam em uma página de papel de tamanho normal, podem ser habitual mente produzidos, hoje, por impressoras laser ou impressoras de matriz de ponto, mas os plotadores, muitas vezes, produzem saídas medindo dois ou três pés de largura por vários pés de comprimento. A desvantagem desse meio de saída é o seu custo, seu volume físico e o tempo necessário para produzir a saída. • Fita ou disco magnéticos. É evidente que se a fita magnética e o disco magnético podem ser usados para entrada, também po dem ser usados para saída. Isso normalmente só é prático nos casos em que a saída será enviada para outros sistemas de processamento (isto é, onde o terminador do sistema não é uma pessoa, mas um computador). 477 • COM. COM é um acrônimo para o Compuler Output Microform. A saída COM é normalmente reservada para saída para arquivos (p.ex., grande volume de material de referência que seria muito caro e excessivamente volumoso para ser produzido como re latórios impressos normais). Exemplos de COM são rolos de mi crofilmes (usados, por
exemplo, por bancos para conservar có pias de cheques cancelados) ou microfichas. 21.2.2 Formatos de Eniradas/Saídas Depois que os dispositivos dc entrada/saída foram cscoinidos, a etapa seguinte é determinar os forma/os das entradas e saídas do siste ma. Em alguns casos, os formatos dessas entradas e saídas podem não ser assunto de negociação, mas simplesmente o caso dc o usuário infor mar ao analista de sistemas “como devem ser as coisas”. Isso é especial mente verdadeiro quando o novo sistema deve comunicar-se com outros sistemas de processamento ou com pessoas (Ou grupos de pessoas) ex ternas à organização que elabora o novo sistema. Organizações externas ou outros sistemas de processamento podem fornecer dados para o novo sistema em um formato fisico prescrito que não pode ser alterado. E eles podem exigir saídas do sistema cm um formato igualmente pres crito rigidamente. Se o diálogo homem-máquina não tiver sido inteiramente ajustado, o que existe para ser negociado? Não a representação interna dos dados no sistema de processamento; o usuário não se interessa e nem sequer deve ter consciência dessa informação. E não aspectos como valores e intervalos válidos dos elementos de dados dc entrada, porque eles de vem ter sido especificados como parte do modelo essencial. No entanto, esse é um lugar para negociar razoáveis restrições de implementação de vários aspectos dos elementos de dados. Seguem-se alguns exemplos: • O modelo essencial pode haver identificado o elemento de dados ÚLTIMO-NOME-DOCLIENTE. Sendo um assunto de in teresse essencial, pode não haver limite para o comprimento (número de caracteres) desse elemento de dados. Afinal, o que está errado com um último nome que por acaso tenha 357 ca racteres de comprimento? Embora isso não aconteça com freqüência, alguns membros da aristocracia européia podem querer demonstrar suas linhagens pela inclusão dos nomes de todos os seus ancestrais no último nome. Isso é interessante e pode ser de alguma significância histórica, porém o usuário e o analista de sistemas podem, contudo, concordar em restringir ÚLTIMO-NOME-DOCLIENTE para 25 caracteres. Observe, a 478 propósito, que isso vai exigir uma alteração na(s) apropriada(s) especificação(ões) de processo que lida(m) com a entrada do IíL11MO-NOME para garantir que seja válida, de acordo com essa restrição dc implementação. Em um sistema de controle dc pedidos, um PEDIDO-DE- CLIENTE pode ser definido da seguinte maneira: PEDIDO-DE- CLIENTE - NOME + ENDEREÇO + (ITEMPEDIDO). No mo delo essencial pode não haver motivo para limitar o número de itens diferentes que um cliente pode comprar em um pedido. Da perspectiva de implementação do usuário, entretanto, pode haver diversas razões: (1) como atividade de suporte manual (discutida mais detalhadamente na seção 21.3, o usuário pode desejar que o funcionário do setor dc vendas preencha o pedido em um formulário prá-impresso que só tenha espaço para, diga mos, oito itens; (2) o usuário pode estar preocupado em que o funcionário do setor dc vendas poderá cometer um engano se tentar lidar com mais do que um número limitado de itens em cada pedido; (3) o usuário pode ficar preocupado em que o dispêndio excessivo de tempo no atendimento a um só cliente com seus 597
diferentes itens, possa aborrecer outros clientes que esperam para ser atendidos. E, assim por diante. Por esta razão, pode haver alguns bons motivos para impor-se uma restrição de implementação definida pelo usuário sobre os ele mentos de dados. Observe que os problemas da implementação do usuário, desse tipo, envolvem observações suplernentares no dicionário de dados e ló gica adicional (se isso for apropriado) nas especificações de processo que tratam da validação dos elementos dc dados de entrada. Mas existe um outro aspecto do diálogo homem-máquina que exige algo mais do que observações no dicionário de dados: a seqüência de entradas e saídas, principalmente em um sistema on-line, pode ser conveniente- mente modelada com a utilização do diagrama dc transições de estado. A figura 21.3 mostra um exemplo típico de um diagrama de transições de estado usado para modelar a seqüência das telas dc vídeo que o usuário final utiliza para se comunicar com o sistema. Isso é útil especialmente para lidar com perguntas como: “Posso retornar à tela do menu principal a partir da tela 12?” e “Quais são os meios para atingir a tela de entrada dc pedidos”? Outros importantes problemas de entrada/saída incluem a organização física de elementos de dados de entrada em uma tela de vídco, a natureza das mensagens de erro quando se comete um erro de entrada; e a organização física de elementos de dados de saída nas telas e em relatórios. Com o imenso 479 Cancela pedido Introduzir
Cancelar det
detalhes
de pedidos
de pedidos
__________
Figura 2 1.3: Um diagrama de transições de estado para a modelagem de telas de vídeo conjunto atual das linguagens de quarta geração, ferramentas de prototi pação e PCs, eu recomendo que você dê ao usuário a oportunidade de divertir-se com diversas variações de telas de entrada, imagens de saída e coisas desse tipo Uma vez obtido o consentimento do usuário, você deve vincular uma cópia das imagens de tela, formatos de relatório e adequados diagramas de transições de estado ao modelo essencial, com apropriadas referências cruzadas aos elementos de dados essenciais do dicionário de dados. É claro que em muitos casos o usuário não terá grandes sugestões para fazer porque não tem experiência anterior em trabalhar com um sistema de processamento; isso é um tanto análogo a alguém que tenha morado em um apartamento durante toda a sua vida e agora deseja es pecificar os detalhes da sua primeira casa sob encomenda em estilo de rancho. No caso dos sistemas de informações computadorizadas, as se guintes diretrizes o ajudarão a desenvolver uma interface humana amis tosa ao usuário na maioria dos casos. 1. Seu sistema \deve requisitar entradas e produzir saídas em uma forma c?fr Isso é particularmente verdadeiro nos sistemas on-line em que o usuário pode introduzir uma entre diversas transações diferentes e/ou receber uma de diversas imagens diferentes.
Suponha, para exemplificar, que o seu sis tema solicite a data ao usuário sempre que uma transação for introduzida; seria desastroso se um tipo de transação exigir a - data na forma 12/23/87, enquanto outra transação exige a data na forma 87/12/23. E também seria desastroso se uma parte do 480 sistema exigisse que o usuário especificasse o estado como um código de dois caracteres (p.ex., RJ para Rio de Janeiro), en quanto outra parte do sistema exigisse que o nome do estado fosse escrito por extenso. De forma análoga, se uma parte do sistema exigir que o usuário forneça um código de área quando introduzir um número dc telefone, todas as partes do sistema devem exigir um código de área quando for intro duzido um número de telefone. 2. Peça Informações em uma seqüência lógica. Em muitos casos, isso depende da natureza da aplicação e exigirá minuciosos entendimentos com o usuário. Por exemplo, suponha que você esteja desenvolvendo um sistema de controle de pedidos, e deseje que o usuário especifique o nome do cliente. Se a in formação for introduzida em cartões perfurados ou (com maior probabilidade) a partir de um terminal de vídeo, você terá de especificar a seqüência na qual deseja que sejam introduzidos os componentes de “nome de cliente”. Uma seqüência lógica seria solicitar ao usuário que introduzisse a informação na se guinte seqüência: título (Sr./Sra. etc.) primeiro nome inicial do nome intermediário último nome Porém o usuário pode achar isso muito desajeitado; suponha que o usuário tenha obtido o nome do cliente de alguma fonte externa como um catálogo de telefones. Nesse caso, seria muito mais prático que o usuário introduzisse último nome primeiro nome inicial do, nome intermediário título A única coisa sobre a qual podemos ter certeza á que a seguinte seqüência seria definilivamenle desaprovada pelo usuário: inicial do nome intermediário 481 482 primeiro nome título último nome 3. Evidencie ao usuário o tipo de erro que cometeu e onde está. Em muitos sistemas, o usuário fornece uma quantidade substancial de informações ao sistema para cada evento
ou transação. Em um sistema dc controle de pedidos, por exem plo, o usuário pode especificar o nome do cliente, endereço e número do telefone, bem como informações sobre os itens que estão sendo pedidos, desconto aplicável, instruções de em barque e imposto sobre vendas. Todas essas informações po dem ser introduzidas em urna única tela de informações antes de serem enviadas ao sistema; e, certamente, o sistema poderá determinar em seguida que parte da entrada está errada ou toda ela. O importante é ter certeza de que o usuário com preenda a espécie dc erro que foi cometido e onde o erro está localizado; não é aceitável que o sistema simplesmente emita um sinal sonoro e exiba a mensagem MÁ ENTRADA. Cada erro (presumindo-se que haja mais de um) deve ser identificado, ou com uma mensagem descritiva ou (no caso de um sistema on une) ressaltando ou codificando em cores os dados errados. Dependendo da natureza do sistema e do nível de sofisticação do usuário, pode ser também importante exibir uma men sagem explicativa; isso será discutido em maiores detalhes no item 5. 4. Faça a distinção entre edições de campos e edições de telas. Em muitos casos, o seu sistema será capaz de determinar se o elemento de dados fornecido pelo usuário está correto ou in correto, sem referência a quaisquer outros elementos de dados. Por exemplo, se o usuário introduzir um código de dois ca racteres para um estado, o sistema deverá ser capaz de de terminar, imediatamente, se os dois caracteres representam um dos cinqüenta estados, ou uma das províncias canadenses, e assim por diante. Mas, se o usuário tiver que introduzir um código post elemento de dados individual, existirá somente um volume limitado de edições de campo que o siste ma poderia realizar sem entradas adicionais; necessitaríamos do código postal e do código dc estado para determinar se o código postal deveria ser um código de cinco (ou de 9 dígitos) ou um código postal canadense de 6 caracteres. O sistema poderia comparar, também, o código de estado e o código de zona para ver se o código postal está dentro do intervalo certo (p.ex., se o código de estado for NY, o código postal come çaria com o dígito 1). O relacionamento entre os elementos de dados podem ser evidentes para o analista de sistemas; en tretanto, isso pode exigir conhecimento íntimo e detalhado da aplicação que pode ser obtida somente do usuário. 5. Torne a edição e a verificação de erros dependentes do usuá rio. Como já dissemos, é normalmente uma boa idéia que o sis tema exiba uma mensagem explicativa quando for detectado um erro. Mas isso só é verdade se o usuário não for capaz de determinar por etc mesmo o que fez de errado. Se o usuário tiver digitado um código postal dc três dígitos, por exemplo, não deve ser necessário que o sistema exiba uma mensagem muito elaborada sobre o comprimento dos códigos postais; en tretanto, isso seria apropriado se o usuário digitasse um código postal de cinco dígitos e o sistema estivesse esperando por um dos novos códigos postais dc nove dígitos. Observe também que (a) alguns usuários são mais capacitados do que outros e podem ficar aborrecidos ainda mais rapidamente se eles ti verem de ler mensagens de erros longas e volumosas e (b) de pois do uso repetido, até mesmo o usuário novato tornar-se-á perito em algumas partes do sistema. Portanto é muitas vezes importante fazer com que as mensagens de erros sejam flexíveis e talvez mesmo alteráveis pelo usuário; o compro misso mais fácil é urna combinação de mensagens de erro curtas (que podem consistir em nada mais do que o realce das entradas erradas e um sinal sonoro para atrair a atenção do usuário) e mensagens de erro longas (com texto explicativo e uma referência à parte adequada do manual de treinamento do
usuário). O item 7 apresenta mais detalhes sobre este assunto. 6. Ofereça ao usuário um modo de (a) cancelar parte de uma transação e (b) cancelar toda uma transação. É ingênuo pressupor que o usuário sempre terminará a introdução de uma transação inteira sem ter interrompido. Com um sistema de processamento batch, isso não representa um problema; o sistema normalmente não examinará qualquer coisa prove niente do usuário até que diversas transações individuais tenham sido compostas Mas em sistemas on-line isso é um problema importante: o usuário pode ter introduzido um no me e endereço de cliente antes de descobrir que estava tra balhando com o cliente errado; ele desejará ser capaz de 483 484 anular o que foi digitado e começar dc novo. Ou o usuário pode haver terminado a introdução da maior parte das infor mações do cliente e, então, perceber que escreveu mal o pri meiro nome do cliente; ele vai querer poder retornar àquele elemento de dados e corrigi-lo sem perder todas as outras in formações já digitadas. 7. Providencie um mecanismo prático de ‘ Nos sistemas on-line, é cada vez mais importante oferecer ao usuário um mecanismo prático para a obtenção de informações sobre como usar o sistema. Em alguns casos, a facilidade do “socorro” simplesmente fornecerá urna explicação se o usuá rio cometer um erro; cm outros casos, o “socorro” poderia ser usado para explicar os detalhes dc vários comandos ou transa ções disponíveis ao usuário. Existem muitos meios de imple mentar essa facilidade, e você e o usuário devem examinar diversos exemplos típicos (a maioria dos pacotes de software disponível no IBM PC e no Apple Macintosh tem facilidades de “socorro”; são bons para iniciar) antes de tomar uma decisão. 8. Faça a distinção entre os sistemas clirigidos por menus e sistemas dirigidos por comandos; se for adequado dê a opção ao usuário. Um sistema dirigido por menu é o que apresenta ao usuário uma lista de escolhas alternativas (ou funções, ou transações etc.); ao escolher urna, pode ser apresentado um Outro submenu, que poderá conduzir a submenus de níveis ainda mais baixos antes que o sistema finalmente execute algu ma ação. Um sistema dirigido por comandos, por outro lado, espera que o usuário apresente um detalhado (e, às vezes, muito longo) comando indicando o que ele quer que o sistema faça. Os sistemas dirigidos por mcnus são considerados mais amistosos, uma vez que eles exibem todas as opções dispo níveis ao usuário; por esta razão, a abordagem de menus é muitas vezes considerada preferível para novos usuários ou quando o sistema tiver dc interagir com uma grande variedade de usuários com diferentes experiências e níveis de habilidade. Mas o sistema dirigido por menu é considerado tedioso pelo usuário experiente, pois ele freqüentemente exige duas ou três interações separadas com o sistema (cada uma com algum tempo de antes que ele finalmente saiba o que o usuário des experimentado geralmente prefere um sistema dirigido por comandos para que ele possa executar o que deseja tão rapidamente quanto possível. a 9. Se o seu sistema estiver empenhado em um processamento muito prolongado, exiba uma mensagem para que o usu4rio não pense que o sistema caiu. Se o seu sistema tiver
de exe cutar cálculos extensos ou se ele provavelmente apresentará demoras periódicas por causa de entradas volumosas, é importante exibir uma adequada mensagem para o usuário; caso contrário é possível que ele imagine que o seu terminal “congelou” ou “ficou preso”, ou que o sistema “caiu”, ou que ocorreu uma falta dc energia. O sistema deve, no mínimo, emitir uma mensagem (p.ex., SISTEMA OPERANDO - POR FAVOR, ESPERE) em intervalos regulares. Melhor ainda seria uma série de mensagens informando ao usuário quanto do trabalho já foi executado e aproximadamente quanto tempo falta para completá-lo. 10. Forneça defaults para entradas padronizadas. Em muitos ca sos, o sistema pode fazer uma boa suposição sobre o provável valor de uma entrada fornecida pelo usuário; tornando-o um default, você pode economizar para o usuário um considerável tempo e a atividade dc digitação. Essa abordagem é válida pa ra todos os tipos de sistemas, mas é especialmente aparente em sistemas on-line, cm que o usuário pode não ser um digi tador profissional. Um exemplo de valor default é a data: em muitas aplicações a data mais provável que o usuário intro duzirá é a data atual. Ou, suponha que você esteja construindo um sistema de controle dc pedidos, e o usuário diz que 95% dos clientes vivem nas redondezas; em seguida, quando você pedir que o usuário informe o número do telefone do cliente, o sistema deve presumir que o código de área default é o seu código de área local. 11. Beneficie-se das cores e do som, mas não exagere. Os moder nos terminais on-line têm diversos efeitos de cores e som; eles podem ser bastante úteis para a enfatização de tipos diferentes de entrada ou para atrair a atenção do usuário para aspectos importantes da interface humana. Dessa forma, você node usar a cor verde para tudo o que for exibido pelo sisten. ul para todos os dados de entrada fornecidos pelo usuário, e vermelho para todas as mensagens de erro. Entretanto, não se deixe ar rebatar: a maioria dos usuários poderá não gostar se as telas ficarem parecendo árvores de Natal. Isso também vale para efeitos sonoros; uma ocasional campainha ou hipe é útil, mas o usuário não deseja que o terminal produza todos os efeitos sonoros do filme Guerra nas Estrelas. 485 21.2.3 O Desenho de Formulários O desenho dos formatos de entradas e saídas dos sistemas tem tra dicionalmente sido chamado de desenho de formulários, porque maioria dos sistemas nos anos 60 e 70 exigia que o usuário codificasse a entradas em formulários de papel que eram depois transcritas para car tões perfurados antes de serem introduzidas em um sistema de processa mento batch. Porém, mesmo nos sistemas on-line de hoje, podem existii alguns desenhos de formulários a serem feitos; considere, por exemplo a situação comum em que a entrada do sistema origina-se com um clien te externo. O cliente pode fornecer a entrada exigida preenchendo un formulário de papel e enviando-o aos usuários que interagem com c sistema; um exemplo de um formulário do mundo real é mostrado n figura 21.4. Desse modo, alguma atenção deve ser dada ao desenho dc formulário. Em alguns casos, o analista de sistemas poderá recorrer a um dc partamento doméstico de gráficos ou a um fabricante externo de formu lários para auxiliar no desenho do formulário; alternativamente o usuáric poderá já possuir formulários relacionados ao sistema existente que de sejará continuar usando no novo sistema. Mas, existem também
muita situações em que o analista de sistemas e o usuário devem desenhar urr novo formulário para um novo sistema. Embora existam muitos estilos diferentes para um formulário, todos devem conter as seguintes infor mações básicas: • Título, para distinguir um formulário de quaisquer outros formu lários. O título é habitualmente impresso cm letras grandes en negrito na parte superior do formulário para que o usuário saiba que aquele é um “formulário de pedido” ou “um formulário dc relatório de problemas”. • Instruções, para informar ao usuário como preencher as infor mações necessárias do formulário. As instruções gerais são ha bitualmente colocadas no início do formulário perto da parte superior; instruções específicas são normalmente apresentadas em seguida ou abaixo de cada item de dados que precise ser preenchido. • C a parte pi. pai do formulário na qual os dados são introduzidos. Este podc ser organizado cm estilo aberto, em es: tilo em quadros ou uma cov’ nação de ambos. O estilo em qua dros é normalmente utilizado para informações binárias (ex., 486 TOTAL $6., R# doo, ool 9O6.OnIeo ,,,oohine o,m$a6ibiIity pie b soro ia sineck prodoal reqoiremenb. Figura 21.4: Um exemplo deformulá rio “confirme neste quadro se quiser o seu nome acrescido à nossa lista postal para futuras informações sobre produtos”) ou de formalo fixo (ex., um número dc telefone ou código postal). O estilo aberto costuma ser empregado para informações de com primento variável como nomes ou endereços. Decidir exatamente como o formulário deve ser diagramado é uma arte por si mesma e é mais bem feita por pessoas experientes em projetos de formulários. Um dos erros mais comuns dos projetistas novatos de for mulários, por exemplo, é não deixarem espaço adequado para o usuário completar as informações exigidas. Isso vale especialmente em formu lários que exigem informações manuscritas . 1 ITEMS ORDERED G. A II _JI ORDERS 800/228-8910 Good anywhere In LIS. 408/625-0465 MAILORDEAS
P0 600 911 • 00116 01077 • Mo,eecey. 04 93942 DATE OF ORDER Sl l
OESCP9P1IOÇ
2T0 UNFI POlO
50,0
157001
00FIC(
SHIPPING/HANDLINC, CHARGE.S BILL TO: (Plnao Pr:nt) 6626. OTTEN1 $36940 900 1
5
6% SOLOS 003
-
--
O-* SI6PP $3 5 -- HUMO 574055 .9 StoP iaildI0.9 086290. ,00100i6l,d by 006 00 ilQo 9, de9 choro, la, 0. onde, chspp UPO G,oond o, 11$ nnojL . add Oh, lhippiro] chaga $94 ao poro,8o,es 1 d4echy 011,000, 9002 loa 0208 0010 oldenod ood add $100 lo 1h, 10101 P,6ec6 secola. .ll.bke; ,,ii Iec sI 00656. 9. C620eOl 9 Boto, II yea reqoone deh cabide lhe 0051)00153 000- ei Sbote.,. pi,ase add Ofle 01 lhese Sp,coal charges lo yoor 0,01,, c 01 oron$ lhe 0501, ai 1611 Haoaa.4 ca8 lo, cha,o,s C ach 8%. $15 nononornon. Foreloeo 0000,0. ach 21%. $35 ,nnon$3nn AI 99000,1110 Olilai Se ir U L doli 006: 001egn 0,11,1, sobj,cl lo FIC r,01005005 001 0 dela$ 1 SHIP TO: ( diff Itian Bili To) 105500620 O 006600 ao O app,aron o, ,no,ag 19.5 NOME COMPaPO 0 000o004l 0100155 570 00 lo, 540057 ara s
1 zip 56059€ P006 000€ P00000 METHOD OF PAYMENT 06 MOIOS l €N ,, 625510
O voa
Li COOOO , P0 NUM610 LJ P 0062,00,6 0,6,1009.6 $01 ar. . 00 cr,dir 6.0,0.6 HHIIHHHII OCCOUNI 50 (100 CIElOME CA OITO SIGNOTURE 487 Dependendo da aplicação, o analista dc sistemas pode desenhai formulários de corte ou formulários especiais. Os formulários de cortc costumam ser impressos em folhas simples de papel e são apropriado para a grande maioria de situações; com a disseminada disponibilidadc dos sistemas de editoração de mesa e programas de desenho de formu lários, o usuário e o analista de sistemas podem facilmente projetar seus próprios formulários. Os formulários especiais são mais complexos e podem ser projeta dos com a assistência dc um experiente projetista de formulários (nor malmente associado a um fabricanie de formulários), O exemplo mais comum de formulário especial é um formulário multipartes, que pode tei folhas de papel carbono entre as cópias de papel especial sem carbono, Os tipos mais conhecidos de formulários especiais S • Formulários encadernados como livros (ex., blocos de pedidos de vendas). • Formulários com partes destacáveis, com um original e múltiplas cópias que podem ser separadas (ex., formulários de cobrança de cartão de crédito). • Formulários contínuos, preenchidos manualmente ou gerados por computador. • Postáveis: formulários pré-impressos já inseridos em um enve lope, fixados juntos como um formulário contínuo. O computa dor pode então imprimir informações padronizadas tais como c nome e endereço do cliente e (através do correto posicio. namento do papel carbono) a impressão será feita no envelope e na carta que estiver em seu interior. Os formulários especiais são, como era de se esperar, bem mais caros do que os formulários de folha única. Assim sendo, deve-se ter cuidado em que eles não
representem uma importante fonte de custos do sistema. Os formulários especiais devem ser produzidos em quantida de razoável para manter baixo o custo unitário: o custo de impressão de 10.000 cópias de um formulário especial é muitas vezes apenas de 10 a 20% maior que o custo de impressão de 5.000 cópias. Deve-se utilizar formulários de tamanho padronizado para que a impressora não tenha de executar dispendiosas atividades dc corte e ajuste; a maioria dos for mulários de tamanho padronizado é de 8,5 polegadas por 11 polcgada ou de 5,5 polegadas por 8,5 polegadas. 488 1.2.4 Códigos de Enirada e Saída Como parte da tarefa de especificação de formatos de entrada e uda, o analista de sistemas muitas vezes deve especificar códigos, isto abreviações para informações que seriam de difícil manipulação e )nsumidoras de tempo para serem descritas detalhadamente. Exemplos códigos são Social Security Numbers (Números de Segurança Social), )digos postais, números de livros publicados (ISBN) e Employer Ide nti cation Numbers (Números de Identificação de Empregadores (EIN)) .ie o IRS atribui ás empresas que arquivam declarações de impostos. Os exemplos acima representam códigos externos para a maioria nós; isto é, qualquer que seja o tipo dc sistema, temos que usar os ;quemas de codificação desenvolvidos pelo IRS, pelos Correios dos U.A., e pela Social Security Administration. Mas há freqüentes situações ‘n que precisamos projetar novos códigos associados ao próprio siste a (ex., números de contas de clientes, números de fabricantes, núme )5 de formulários, códigos de produtos, códigos de cores e números de os de linhas aéreas). Assim Como o desenho de formulários é uma le, as técnicas de codificação também são uma área especializada de rícia; como Gore e Stubbe mostram em IGore e Stubbe, 19831, um étodo de codificação deve ser: • Expansível - O código deve dispor de espaço para entradas adicionais que possam ser necessárias. • Preciso - O código deve identificar o itcm específico. • Conciso - O código deve ser curto e ainda assim descrever adequada mente o item. • Prático - O código deve ser fácil de ser codificado e descodificado. • Significativo - O código deve ser útil às pessoas que lidam com ele. Se possível, deve indicar algumas das características do item. • Funcional - O código deve ser compatível com os métodos presentes e antecipados do processamento de dados - manual ou à máquina.” Em alguns casos pode não ser necessário, desejável ou prático que código tenha algum relacionamento evidente com o item que ele des eve. Um bom exemplo é um número dc cliente, um número de conta i um número de empregado em muitos sistemas: o código é simples- ente um número, escolhido seqüencialmente. Entretanto, também é mum que a
técnica de codificação reserve blocos de números (ou tras) para itens que se enquadram em uma categoria comum; por 489 exemplo, um sistema de controle de pedidos poderia usar um númen de quatro dígitos como um número de produzo, com os números de 1 500 reservados para itens comuns, e os números dc 501 a 999 reservado para itens especiais. Ainda mais comum é o código de cIass que utiliza grupo de dígitos (ou letras) no código para identificar classificações maiores intermediárias e menores no item que está sendo descrito. Por exemplo para ligar para meu escritório em Londres, eu disco os seguintes dígitos 011-44-1-637-2182 Os três primeiros dígitos identificam o número do telefone com um número internacional (em comparação a um número chamado den tro da América do Norte). Os dois dígitos seguintes são o código ± cidade, sendo 44 o código do Reino Unido. O dígito seguinte é o códig de área de Londres, análogo ao código dc área de três dígitos uiilizad nos Estados Unidos. Os três dígitos seguirnes representam um centrc telefônico e muitas vezes dará ao usuário esperto uma boa idéia do bair ro londrino onde está localizado esse telefone. E, para finalizar, os úl timos quatro dígitos identificam um telefone específico. Os códigos alfabéticos também são muito usados em sistemas d informações. A maioria dos códigos alfabéticos é uma tentativa de auxí lio mnemônico ou da memória, que o usuário será capaz de lembrai com facilidade 10 Se a tentativa terá ou não sucesso dependerá d extensão do código (isto é, dois caracteres contra dez caracteres), a di. versificação e a disparidade dos próprios elementos dc dados, e a fami liarização do usuário com os elementos dc dados. Por exemplo, conside re os códigos de duas letras usadas para identificar diferentes linhas aé reas; a maioria dos cidadãos americanos percebe imediatamente que AA representa American Airlines e que UA representa United Airlines. Toda via, quantos sabem que HW representa Havasu Airlines, ou que AQ re presenta Aloha Airlines? Com códigos de três letras, temos uma chanc melhor na escolha de códigos mnemônicos, como é demonstrado pelo5 códigos utilizados para identificar aeroportos. Quase todos sabem que JFK representa o aeroporto John F. Kenriedy em Nova lorque e que SFC representa o aeroporto dc São Francisco. Mas, mesmo assim há dificul dades, a menos que o usuário tenha memorizado muitos códigos que não são mnemônicos (ex., ORD para O’Hare e YYZ para o aeroporto de Toronto!). Para finalizar, alguns códigos são dc au1o-venficaçãa isto é, con têm informações adicionais (redundantes) que podem ser usadas para certificar que o código foi introduzido corretamente. Cm conhecido exemplo de código de auto-verificação é o que contém um dígito veri ficador, que costuma ser acrescentado ao final do código numérico. 490 ) dígito verificador pode ser calculado de diversas maneiras, uma das luais é mostrada abaixo: digito-verif - o
FOR cada digito no código numérico soma - digito in. pelo número de sua 0 Si Ç digito-verificador - digito-verificador + sorna DO WHILE existir mais do que um digito em digito verif digito-verificador
soma de todos os digitos em
digito-verif ENDDO Por exemplo, se tivéssemos o código numérico 9876, o dígito veri icador seria calculado como (91) + (82) + (73) + (64), que resulta em O. A soma dos dígitos 7 e O dará o resultado final 7 como dígito verifica lor. O objetivo disso não é obrigar que o usuário faça todo esse cálculo, nas sim utilizar um código que contém um dígito verificador embutido ex.: 9876-7). Em seguida, quando o usuário introduzir o código no sis ema, o computador poderá recalcular automaticamente o dígito verifica lor esperado (utilizando o algoritmo acima descrito) e compará-lo ao lígito verificador real. Se houver algum erro, isso normalmente significa- á que um dos dígitos foi introduzido erroneamente pelo usuário. fl.3 A. IDENTIFICAÇÃO DE ATIVIDADES COMPLEMENTARES DE SUPORTE MANUAL No modelo essencial, presumimos a existência de uma tecnologia )erfeita - que significa, entre outras coisas, que consideramos que nos- a tecnologia de implementação nunca falha nem comete erros. Os isuários podem não estar dispostos a aceitar isso, e quem os pode cul )ar? Além disso, o usuário pode decidir que certas partes do sistema Lutomatizado poderão ficar sob seu próprio controle operativo (ex.: um ou um minicomputador em sua área de trabalho) e ele pode ficar Lpreensivo com possíveis erros de operação que o seu próprio pessoal )ode cometer. Lembre-se, ainda, que ele pode estar trabalhando com lados financeiros, caso em que podem existir exigências legais (ou exi ências impostas pelos auditores) para assegurar a integridade das en radas, saídas e dos arquivos do sistema. Na maioria dos casos essas tividades complementares de suporte serão representadas por novos 491 processos no DFD do modelo comportamental. Um exemplo é apres tado na figura 21.5. De um modo geral, temos que nos preocupar com a possibilida da tecnologia defeituosa em quatro importantes áreas, como mostra figura 21.6. A Introdução da entrada no sislema. Se os dados de entra forem introduzidos pelos terminais de vídeo interligados a Figura 21.5: Uma atividade de verificação de erros de suporte manual terminal de entrada
Relatório de saidã Figura 21.6: Possíveis áreas de tecnologia defeituosa 492 computadores principais por linhas dc telecomunicação, é possível que alguma transação ou todas elas sejam pcrdidas ou embaralhadas. O mesmo pode acontecer com quase todas as outras formas dc enirada; por exemplo, um ou dois cartões de entrada podem ser perdidos pelo operador do computador ou um dos discos flexíveis de um conjunto pode não ser lido para o sistema. • A execução dos cálculos. Uma vez introduzida a entrada no sis tema, existe a remota possibilidade dc que o próprio computa dor apresente um defeito e a possibilidade muito maior (!) de que um erro nos programas de processamento produza um re sultado incorreto. Os erros dc hardware do computador podem ocorrer em uma UCP individual ou na interface entre as divcrsas UCPs na configuração do sistema. • Armazenamento de dados por lon períodos. A maioria dos sistemas retém dados por longos períodos dc tempo em discos magnéticos, fitas magnéticas, discos flexíveis e congêncres. É possível que alguns desses dados (ou todos) sejam dcstruídos por causa dc erros do hardware do computador e/ou erros do software. Os erros de hardware podem consistir cm problemas no próprio dispositivo dc armazcnamcnto ou problemas na co nexão entre a UCP e o dispositivo de armazenamcnto. Os erros de software podem ocorrer nos programas dc aplicação desen volvidos pela equipe do projeto ou no software de gerencia mento de banco dc dados do fornecedor. A obtenção de saídas do sistema. Os potenciais problemas neste aspecto são análogos aos prot)lemas da introdução dc entradas no sistema. Em alguns casos, a saída deve ser transmitida por linhas de telecomunicação, muitas vezes para o mesmo terminal de vídeo utilizado para entrada. Em outros casos, a saída é pro duzida em fitas magnéticas ou em relatórios impressos. Em to dos os casos, é possível que as informações de saída sejam per didas ou modificadas incorretamente cm conseqüência de erros de hardware ou de software. O que deve ser feito em relação a essas possíveis áreas de tecno logia defeituosa Evidentemente, isso vai depender muito (1) do nível estimado de conflabilidade do hardware e do software que estiverem sendo utilizados, (2) da natureza da aplicação do usuário e (3) dos custos ou penalidades associadas a entradas ou saídas defeituosas. É claro que isso exige um detalhado entendimento entre o usuário, os analistas de ‘í93 sistemas e a equipe de implementação; eles podem resolver acrescen tar alguns dos seguintes itens ao modelo essencial para lidar com a tec nologia defeituosa: Entradas e/ou saídas redundantes. No caso mais extremo, po dem ser fornecidas cópias duplicadas dc entradas proveniente de duas diferentes origens (ex.: de dois diferentes usuários en diferentes terminais de vídco). E o sistema pode produzir saída: duplicadas (ex.: duas cópias diferentes de um relatório de saíd impresso em diferentes impressoras). Essa é uma hipótese inco mum, mas pode precisar ser considerada no caso de aplicaçõe: extremamente sensíveis.
Tecnologia de processador redundante. Os dados mantidos pclc sistema podem ser armazenados, em duplicata, cm dois diferen tes discos ou em duas diferentes fitas magnéticas. E os cálculo executados pelo sistema podem ser efetuados, cm duplicata em duas diferentes UCP. Em realidade, pode ser exigida re dundância ainda maior: embora uma segunda UCP ou uma se gunda unidade dc disco permita que o sistema continue, se primeira unidade falhar completamente, isso não reprcsent proteção contra erros sutis. E se a UCPI e a UCP2 executaremc mesmo cálculo (cx.: o cálculo dc juros em contas dc poupanç ou o cálculo da trajetória de um míssil para um vôo à Lua) ( produzirem respostas diferentes? Qual UCP estará correta? Nc caso mais extremo, podemos insistir até em processadores tripli cados e armazenamento dc dados triplicados, com a maioria de cidindo qual dos dois computadores tem a resposta certa. Mas, c se os três computadores divergirem? Redundancia interna. Uma forma comum de lidar com tecnolo gia defeituosa é a redundância parcial. Por exemplo, um fun cionário de banco que introduz dados sobre um depósito err um sistema bancário on-line pode ser solicitado a fornecer c número da conta e o nome do depositante. Embora o númerc da conta normalmente seja suficiente para identificar o registrc do cliente no sistema, sempre existe a possibilidade de o fun cionário do banco introduzi-lo incorretamente, ou que c número da conta possa ser alterado por causa de um erro de telecomunicação, ou um erro no terminal dc vídeo, ou um erro na UCP. Como alternativa, o sistema pode exigir que o fuft cionário do banco introduza somente o número da conta, verifi cando se está correto pela exibição do nome do cliente após o registro ter sido recuperado. 494 • Controles batch. Essa é uma técnica introduzida primeramente nos sistemas de processamento batch de segunda geração, mas que ainda é importante cm muitos sistemas atuais. Ela exige que o usuário mantenha um contador das transações que introduz no sistema, bem como um acumulador de quaisquer itens de dados importantes dessas transações; em sistemas financeiros, a coisa mais óbvia a ser totalizada seria o valor em dinheiro de cada transação. Entrementes, o sistema mantém sua própria to talização à proporção que recebe as transações; periodicamente, o sistema e o usuário comparam seus totais para assegurarem que nada foi perdido ou alterado. A mesma técnica pode ser usada com as saídas: o sistema pode manter sua própria totali zação do número dc transações que ele produziu, e isso pode ser comparado com uma totalização manual feita pelo usuário. • Verifica ções de seqüência. A técnica dc verificação de seqüência está relacionada ao conceito dc controles batch. O usuário pode designar um número seqüencial ou um número de transação para cada entrada, e o sistema pode verificar, à medida que pro cessa essas entradas, se elas estão cm seqüência e se nenhuma transação foi perdida. De modo semelhante, o sistema pode atri buir um número seqüencial para cada saída produzida, e o usuário pode confirmar manualmente que nenhuma das saídas tenha sido perdida. 21.4 A ESPECIFICAÇÃO DE RESTRIÇÕES OPERACIONAIS
No final de tudo, a equipe de implementação terá de deckiir que combinação de hardware, sistema operacional, recursos de telecomuni cação, linguagens de programação e estratégia de projeto implementarão melhor os requisitos. Mas, será difícil fazer isso sem o estabelecimento de algumas restrições de operação, que o modelo essencial evita de liberadamente. Os principais problemas são, normalmente: • Volumes de dados. O usuário precisa especificar os volumes de transações de entrada e o tamanho necessário dos depósitos de dados. Isso é especialmente importante se houver grandes va riações no volume de transações (ex.: durante as horas mais tumultuadas do dia ou épocas mais tumultuadas do ano). Assim, o usuário poderá dizer: “Normalmente processamos 2.000 pedi dos por dia, porém, o volume salta para 4.000 pedidos ao dia durante o mês de dezembro”. Além disso, o usuário precisa 495 estimar o aumento dos índices de transações e os requisitos d memória em relação à vida útil estimada do sistema. Dess modo, o usuário pode dizer, “O depósito INVENTÁRIO precis; ser capaz de manipular o movimento dc 4.000 peças diferente agora, e esperamos lidar com cerca de 6.000 peças dentro do próximos cinco anos”. De um modo geral, pode-se esperar qu o volume de dados armazenados por um sistema de informa ções cresça de aproximadamente 10% ao ano ‘ Tempo de resposta para várias entradas. Pode ser estahclecid em termos absolutos, mas é estabelecido de modo mais realist como uma probabilidade: “90% dc todas as transações deven ter tempo de resposta inferior a 2 segundos”. Em alguns casos pode ser especificado em termos dc limites: “0 relatório XY2 deve ser produzido antes das 8:00 horas (AM) dc todas a manhãs”, ou todas as transações dc depósitos devem ser proces sadas à meia-noite para que os clientes possam saber seu saldc atual a partir de seus respectivos sistemas bancários. • Restrições políticas em opções de implementação. o usuário po. de, por motivos racionais ou irracionais, especificar a marca dc hardware a ser usado (ou a marca de hardware a ser evitada), a linguagem de programação a ser utilizada (“a programação de verá ser feita em Ada”), o fornecedor do equipamento de tele comunicação que será utilizado, e assim por diante. Isso deve ser evitado sempre que possível, mas você deve esperar pelo menos algumas pressões dessa espécie. Observe que é mais provável que as restrições dc implementação sejam impostas pelo departamento dc operações da organização; isto é, você provavelmente ouvirá coisas como, “Bem, esse novo sistema parece muito bom, mas naturalmente deverá ser processado no computador da empresa. Portanto, certifique-se que ele não ocupe mais do que 8 mcgahytcs; alocaremos um p de discos para você”. • Restrições ambientais. Temperatu ra, umidade, interferência elétrica (RFI), consumo dc força, limitações de peso, tamanho ou emissões elétricas, vibração, poluição, ruído, radiação e outras restrições amhicntais podem ser impostas pelo usuário à equipe de implementação. Algumas vezes o usuário não aborda rá explicitamente a questão; ele apenas partirá do princípio. que o novo sistema funcionará satisfatoriamente no seu am biente normal (ex.: em refinarias de pctróleo, em fábricas, ou em um ambiente aberto de escritório). Desse modo, pode ser
496 necessário documentar os recursos relevantes do ambiente do usuário para facilitar o trabalho da equipe de implementação. Você pode preferir simplesmente indicar no modelo de imple mentação do usuário que o sistema deve operar no ambiente do usuário, e deixar que a equipe de implemenaçào descubra por si mesma o que isso significa. Resinções de se e conJ?abilidade. O usuário pode es peciflcar o tempo médio entre falhas (MT e o tempo médio entre paradas para manutenção (MTTR), do sistema. A confia bilidade exigida do sistema também pode ser expressa em ter mos de disponibilidade; por exemplo, o usuário pode dizer, “Não podemos admitir nada abaixo de 99.5% de disponibilidade do sistema.” Restrições de se O usuário pode especificar uma va riedade de restrições com a intenção de minimizar o uso não autorizado do sistema. Isso pode incluir números de contas e senhas (os usuários terão de identificar-se). Também pode in cluir mecanismos para impedir acesso não autorizado a dados confidenciais; alguns usuários podem ter permissão para ler registros em diversos depósitos, enquanto outros usuários po dem ter permissão para modificar (ou eliminar) dados existen tes, e ainda outros podem ter permissão para acrescentar no vos registros. E o usuário pode exigir mecanismos para impedir que usuários não autorizados executem cerl2s funções do sis tema (ex.: nem todos devem ser capazes de executar o sistema de pagamento). Várias medidas dc segurança podem ser im postas sobre os dados que entram e saem do sistema; isso pode incluir, por exemplo, a codificação de dados transmitidos por li nhas de telecomunicação 12 E, para fins de segurança, o sistema pode ser obrigado a produzir uma Usta de audiloria: uma lis tagem completa de todas as transações introduzidas no sistema, todas as saídas produzidas e talvez mesmo um registro de todas as alterações feitas nos arquivos do sistema. 21.5 RESUMO O modelo de implementação do usuário é muitas vezes descrito como a “zona sombria” entre a análise estruturada e o projeto estrutura do. Ele não pode ser feito apenas pelo analista de sistemas, e é arriscado para o analista e para o usuário desenvolverem o modelo de implemen tação do usuário sem a participação dos projetistas e programadores que 497 construirão o sistema. Embora as funções, os dados e o comportamentc tempodependente sejam, cm última análise, as características mais im portantes de um sistema de informação, a intcrface humana é muitas ve zes a área que provoca as reações mais emocionais do usuário. Formatos complicados de entrada, mensagens dc erro confusas e tempo pro longado de resposta podem tornar mesmo as funções mais elegantes do sistema inaceitáveis para o usuário. Também deve ser lembrado que as restrições de implementação impostas pelo usuário (habitualmente de forma inocente) podem destruir até o mais bem gerenciado projeto: simplesmente pode não ser possível implementar o sistema dentro das restrições do usuário. Quando o modelo de implementação do usuário iiver sido cons truído e revisto pelos
usuários, pelos analistas dc sistemas e pelo grupo projetista/programador, a tarefa dc análise dc sistemas estará terminada. Nesse ponto, costuma ser necessário apresentar à direção os resultados de toda a fase de análise de sistemas do projeto para que se obtenha aprovação para prosseguir com o projeto e a implementação do sistema. A apresentação deve incluir as seguintes informações: 1. A situação atual do sistema existente (presumindo-se que exista). 2. Problemas (fragilidades, funções ausentes etc.) que foram identi ficados no sistema atual durante o levantamento inicial ou es tudo de viabilidade. 3. Soluções alternativas que foram identificadas. 4. Uma visão geral do modelo essencial e do modelo de imple mentação do usuário, com tantos detalhes quantos a gerência deseje ver. Normalmente, apresenta-se o modelo de DFD de alto nível e os componentes detalhados do modelo são tornados dis poníveis à direção para subsequcn Les consultas. 5. Custos e benefícios projetados do novo sistema 6. Estimativas de custos, cronogramas e recursos (horas de traba lho) para as fases restantes do projeto. 7. Recomendações da equipe do projeto ou do analista de sistemas. Admitindo-se que a aprovação da direção esteja próxima, o projeto está apenas começando: existe ainda um grande volume de trabalho de 498 projeto, programação e testes a ser feito antes que o usuário finalmente receba o sistema desejado. Essas áreas serão estudadas nos próximos capítulos. REFERÊNCIAS 1. Marjorie Leeson, Systems Analysis and Design Chicago: Science Research Associates, 1981. 2. Tom Gibb e Gerald Weinberg, Humanized Input. Cambridge, Mass.: Winthrop Publishers, 1977. 3. James Martin, Design of Man-machine Dialogues. Englewood Cliffs, N.J.: PrenticeHall, 1973. 4. Marvin Gore e John Stubbe, Elements of Systems Analysis, 3a ed. Dubuque, Iowa: William C. Brown Co., 1983. 5. Data Processing Techniques: Coding Methods, Form GF2O-8093. White Plains, N.Y.: IBM Technical Publications Department. PERGUNTAS E EXERCÍCIOS 1. Quais são as três principais coisas que o modelo essencial de um sistema descreve? 2. Por que o modelo essencial habitualmente não representa infor mação suficiente para os projetistas de sistemas e programadores
para que seja iniciada a implementação do sistema? 3. Que informações adicionais precisam ser acrescentadas ao modelo essencial? 4. O que é um modelo de implementação do usuário? Quais são seus principais componentes? 5. Quais ão os dois principais problemas de implementação que sensibilizam fortemente os usuários em relação a um projeto de in formação de sistemas? 6. Dê uma definição de fronteiras de automatização de um sistema. Que outros termos ou sinônimos podem ser usados em lugar de fronteira de automatização? 7. Por que os usuários muitas vezes têm importantes opiniões sobre o formato de entradas e saídas de um sistema de informação? 8. Dê quatro exemplos de problemas de formatação (envolvendo en tradas, saídas ou as duas coisas) que um usuário pode querer es pecilicar como parte do seu modelo de implementação. 9. Dê três exemplos de problemas de formatação associados a siste mas on-line, que um usuário pode querer especificar como parte do seu modelo de implementação. 499 10. Como o advento dos computadores pessoais afetou o trabalho que o analista de sistemas deve fazer para desenvolver o modelo de implementação do usuário? 11 Dê três exemplos de perguntas que precisarão ser respondidas no modelo de implementação do usuário se os PCs controlados por usuários fizerem parte da implementação do sistema. 12. Como o advento das linguagens de programação de quarta gera ção em muitas organizações afeta o trabalho que o analista de sistemas deve fazer para desenvolver o modelo de implementação do usuário? 13. Como o conceito de pmlolipação afeta o desenvolvimento do mo delo de implementação do usuário em um típico projeto de desen volvimento de sistemas? 14. Como a possível compra dc um pacote de software de um forne cedor afeta o desenvolvimento do modelo de implementação do usuário em um típico projeto dc desenvolvimento de sistemas? 15. Que erro muitas organizações cometem no desenvolvimento de um modelo essencial em situações em que esperam utilizar um pacote de software de um fornecedor? 16. Quais são os três casos extremos que podem ocorrer quando as fronteiras da automatização são determinadas para um sistema de informações?
17. Sob que condições o usuário provavelmente não terá opinião sobre onde deverá ficar a fronteira da automatização no projeto de de senvolvimento de um sistema? Qual é a probabilidade da ocorrên cia disso em uma organização típica? 18. Sob que condições o usuário tende a optar por um sistema total mente automati;.ado quando a fronteira da automatização está sendo determinada, com todas as funções executadas por compu tadores e todos os dados armazenados de forma computadorizada? 19. Sob que condições o usuário tende a optar por um sistema total mente manual quando a fronteira da automatização está sendo de terminada? Você acha isso provável? 20. Quantas fronteiras alternativas de automalização você acha que a equipe de projeto deve examinar com OS usuários antes da defini ção final? Apresente uma justificativa para a sua resposta. 21. Do ponto de vista do analista dc sistemas, qual é a coisa mais sim ples que pode ocorrer aos processos e dados que foram deixados fora da fronteira de automatização quando esta foi estabelecida? 22. Qual é a coisa mais provável que o analista deverá fazer com os processos manuais e com os dados manuais depois da definição d fronteira da automatização? 23. Quais são os três principais problemas que precisam ser tratados ao 500 se definir a fronteira de automatização no modelo de implementa ção do usuário? 4.
Onde o analista de sistemas deve documentar os detalhes da maio
ria dos problemas relativos à fronteira da automatização que foram discutidos com o usuário? 5.
Apresente dois exemplos de restrições de implementação de um
elemento de dados que possa ser definido como parte da fronteira de automatização. 6.
Como o diagrama de transições de estado pode ser efetivamente
utilizado durante o desenvolvimento do modelo de implementação do usuário? 7.
Que tipo de atividades dc suporte manual pode precisar ser espe
cificado durante o desenvolvimento do modelo de implementação do usuário? 8.
Quais são os cinco principais tipos dc restrições operacionais de
um sistema que costumam precisar ser especificados no modelo de
implementação do usuárío? 9.
Por que é importante especificar no modelo dc implementação do
usuário o volume de dados que o sistema deve manipular? 0.
Apresente três exemplos de restrições políticas que podem ser
impostas a um sistema como parte do modelo de implementação do usuário. 1.
O sistema de caixa automático de seu banco é dirigido por menus
ou por comandos? Quais são as vantagens e as desvantagens da técnica adotada pelo Sistema? SOTAS 1
Isso ilustra a necessidade dc uma boa comunicação entre os usuá
rios e a equipe de implementação, bem como com os analistas de sistemas. Embora os usuários possam estar muito interessados no emprego de linguagens dc quarta geração, a equipe dc implemen tação pode precisar investigar o desempenho da linguagem. Os sistemas com grandes volumes dc entrada e saída podem descobrir que as linguagens de quarta geração são demasiadamente inefi cientes. Isso será analisado mais detalhadamente no capítulo 23. 2
Uma suposição muito importante está sendo feita aqui; o modelo
essencial deve ser desenvolvido primeiro, antes que o pacote do fornecedor seja avaliado. Muitas organizações fazem justamente o inverso: elas primeiro avaliam o pacote e, depois, tentam obter um modelo dos requisitos essenciais dos recursos do pacote. 3
Os procedimentos do usuário para os processos manuais podem
basear-se na especificação daqueles processos. De fato, no caso 501 mais simples, a especificação do processo é o procedimento d usuário; entretanto, como as especificações do processo forar cuidadosamente redigidas para evitar qualquer tendência de impk mentação desnecessária, elas podem precisar. ser expandidas o rcescritas para prover orientação aos usuários. 4
Pense por um momento sobre os tipos dc problemas que poder
ser criados pela simples colocação dc um terminal na mesa d
usuário. Primeiro, pode não haver espaço para ele: o usuário pod precisar de todo o espaço dc trabalho disponível para outras coisa que faça. Segundo, pode não haver suficientes tomadas elétrica para ligar o terminal de vídeo, a impressora, o modem e a parafei nália restante. Terceiro, a mesa pode ter altura correta para leitura escrita, mas, talvez, não para digitação. Quarto, a iluminação d escritório pode causar tanta claridade que torne difícil ler as infor mações na tela do terminal. Quinto, o ruído causado pela digitaçã do usuário no terminal pode desagradar os outros usuários d mesma área. 5
Observe que estamos discutindo entradas fornecidas pelo usuário
Muitos sistemas (especialmente sistemas dc tempo-real) devem ne gociar com dispositivos que forneçam entradas sem interferênci; humana (p.ex., rãdar, gravadores de dados e sinais dc satélite). 6
Observe que estamos fazendo distinção aqui entre o uso do apare
lho telefônico (o aparelho propriamente dito) e a linha de tele comunicações. Muitos terminais são interligados, através dc urr modem, a uma linha telefônica; mas aqui estamos falando sobre c aparelho telefônico como meio dc entrada. 7
Na realidade, você também pode precisar usar ferramentas de IA
de quinta geração, para fazer experiências com entradas cm lingua gem material, entrada de voz, saída de gráficos e assim por diante. 8
Porém, mesmo em um sistema batch, o usuário pode achar que
introduziu alguns dados no sistema por engano. É quase sempre necessário suprir o usuário com a facilidade de desfazer ou reverter o que quer que tenha introduzido. Mas isso deveria ter sido desco berto durante suas entrevistas com o usuário, e já deveria ser evi dente no DFD e nas especificações de processos para o sistema. 9
Deixe, pelo menos, meia polegada de espaço vertical para cada
linha de informação manuscrita em um formulário. Deixe pelo menos 1/3 de polegada e alguns múltiplos de 1/6 de polegada para cada linha de informação datilografada em um formulário. Certifi que-se de que o datil6grafo não tenha de realinhar a máquina de
escrever para cada linha de informação. 10
Alguns outros esquemas de codificação alfabética parecem ser exa
tamente opostos aos mnemônicos; são os códigos derivados de um ou mais dos atributos do elemento dc dado. Um exemplo disso é o 502 código encontrado no rótulo postal dc muitas revistas; o código do assinante costuma ser composto por uma parte do último nome do assinante, seu endereço, código postal, data da expiração da as sinatura e outros detalhes, não sendo, portanto, muito mnemônico: não há como alguém possa memorizar um código que muitas ve zes atinge 20 ou 30 caracteres dc comprimento. Entretanto, depois que o código é introduzido no sistema, o registro do assinante po de ser recuperado com muita rapidez, o que pode ser muito im portante em um banco de dados de assinantes com alguns milhões de registros. Mais informações sobre esses códigos derivados po dem ser encontrados no IBM Form GF2O8093, Data Processing Techníques. Coding Metbods. 11 Essa estimativa é baseada em um levantamento feito em aproxima damente 500 instalações de computadores nos EUA, documentada por Lientz e Swanson em Software Maintenance Management (Reading, Mass.: Addison-Wesley, 1980). 12 A segurança do computador é um importante aspeclo por si mesma e não é discutida em detalhes neste livro. Para maiores in formações, consulte livros sobre segurança dc computadores e crimes em computadores; além disso, estabeleça entendimentos com o Computer Security Institute (Instituto de Segurança de Computadores). 13 Os cálculos de custo/beneficio serão discutidos no apêndice C. 503 1 22 A FASE DE PROJETO For dose desígns and crooked counseis fli, Sagacious, bold, and turbuieni of wil, Restiess, unfix’d in principies and place, in power unpleas’d, impatien: of dtsgrace A fiery soul, which working oul zi way, Fretted lhe pygmy-body lo decay.... John Dryden, Absalorn and Achitophel, 1680 Neste capítulo, aprenderemos: 1. Os três níveis do projeto de sistemas.
2. Os três principais critérios de avaliação do projeto de um sistema. 3. Como desenhar um diagrama estrutural. 4. Como utilizar o acoplamento e a coesão para avaliar um projeto. Quando o modelo de implementação do usuário está pronto, a tarefa do analista de sistemas está oficialmente terminada. Tudo que estiver além desse ponto passa a ser uma questão de implementação. A parte visível desse trabalho são a programação e os testes, que discutire mos no capítulo 23. A programação, todavia, deve ser precedida por uma atividade de nível mais elevado: o pmj elo. Como analista de sistemas, você pode não perceber que está in teressado nos detalhes de projeto de sistemas ou de projeto de progra mas; entretanto, como vimos no capítulo anterior, as tarefas do analista 507 de sistemas e do projetista não podem estar sempre separadas. Principal mente na área do modelo de implementação do usuário, o analista dev certificar-se de que conhece os requisitos do usuário, enquanto o proje. tista deve garantir que esses requisitos sejam corretamente implementa. dos com a atual tecnologia existente. Dessa maneira, é importante que você tenha algum conhecimento do processo que o projetista executar quando sua tarefa estiver terminada. Existe mais um motivo para que você se interesse pelo projeto dc sistemas: pode acontecer de você ter de fazer o serviço! Principalmente nos sistemas de pequeno e médio porte, é normal a mesma pessoa do cumentar os requisitos do usuário e desenvolver o projeto. Assim, você pode ter de decidir a melhor maneira de mapear o modelo dos requisitos do usuário em uma configuração de várias UCP; você pode ter de decidir que o modelo de dados lógicos (documentado com os DER) pode ser implementado melhor com um sistema de gerenciamenlo de banco de dados e ter de decidir como as funções do sistema devem ser alocadas a diferentes tarefas em cada processador. Não é propósito deste livro discutir as atividades do projeto de sistemas com muitos detalhes; isso é mais bem feito em livros dedicados ao assunto, como [ 19881, EYourdon e Constantine, 19891, [ e Meilor, 1985], [ 1975], [ 1977] e outros. Contudo, examinaremos rapidamente os principais estágios de projeto e alguns dos mais importantes objetivos que o projetista de sistemas deve tentar alcançar. Como o projeto de sistemas e o projeto de programas são as suntos separados, você deve consultar as referências ao final deste capítulo no caso de precisar de maiores informações. 22.1 OS ESTÁGIOS DO PROJETO A atividade de projeto inclui o desenvolvimento de diversos mode los, quase do mesmo modo como o analista de sistemas desenvolve modelos durante a fase de análise de sistemas. Os modelos de projeto e seu relacionamento com os modelos da análise de sistemas discutidos neste livro são mostrados na figura 22.1. Os modelos mais importantes para o projetista são o modelo de implementação de sL e o modelo de implementação de pmg rama. O modelo de implementação de sistema subdivide-se em um modelo de processador e um modelo de tarefa.
22.1.1 O Modelo de Processador A primeira tarefa que o projetista enfrenta é decidir como o modelo essencial (ou, para ser mais exato, a parte automaiizada do modelo de 508 Figura 22.1: Modelos de análise e modelos de projeto 509 ODELO ESSENCIAL Incorpora diversos dei essenciais de dados ‘ DE NÍVEL DE PROCESSADOR NÍVEL DE TAREFA MODELO DE NÍVEL DE PROGRAMA implementação do usuário) será alocado às principais peças de hardware e à tecnologia de software de sistemas. Em nível de modelo de processa dor, o projetista de sistemas tenta decidir principalmente como o mode lo essencial deverá ser alocado aos diferentes processadores (UCP) e como esses processadores se intercomunicarão. Costumam existir várias opções: • Todo o modelo essencial pode ser alocado a um só processador. Isso costuma ser chamado de solução mainframe. • Cada bolha no DFD figura O do modelo essencial pode ser aio- cada a uma diferente UCP (tipicamente um mmi ou microcom putador)’. Isso costuma ser chamado de solução distribuída. • Pode ser escolhida uma combinação de mainframes, minis e micros para minimizar custos, maximizar a confiabilidade ou alcançar algum outro objetivo. Assim como os pmcessos podem ser designados para componen tes de hardware adequados, os depósitos de dados podem também ser alocados. Desse modo, o projetista deve decidir se um depósito será im plementado como um banco de dados no processador 1 ou no pro cessador 2. Como a maioria dos depósitos é compartilhada por muitos processos, o projetista talvez tenha de decidir também se será necessário designar cópias duplicadas de depósitos para processadores diferentes. A atividade de alocar processos e depósitos para os processadores é mostrada na figura 22.2. Observe que qualquer coisa além de uma implementação de pro cessador-único envolverá algum mecanismo de comunicação entre pro cessadores; o que tradicionalmente é mostrado como fluxos de dados deve agora ser especificado em termos físicos. Algumas das opções dis poníveis ao projetista de sistemas em termos de comunicação processa dor-processador São: • Conexão direta entre os processadores. Isso pode ser implemen tado pela interligação dos processadores por um cabo, ou por um canal ou por uma rede local. Esse tipo de comunicação costuma possibilitar a transmissão de dados de um processador para outro a
velocidades que variam de 50.000 bits por segundo (às vezes abreviado como 50 KB) a vários milhões de bits por segundo. • Um elo de telecomunicações entre os processadores. Isso é al go bastante comum quando os processadores são fisicamente 510 Figura 22.2: Alocação de processos e depósitos a processadores separados por mais do que poucas dezenas de metros. Depen dendo da natureza do elo de telecomunicações, os dados serão normalmente transmitidos entre os processadores a velocidades entre 300 bits por segundo e 50.000 bits por segundo. Um elo indireto entre os processadores. Os dados podem ser es critos em fitas magnéticas, discos flexíveis, cartões perfurados ou em algum outro meio em um processador e em seguida levados a outro processador para serem usados como entrada. O último (por vezes chamado de ‘interface disfarçada») é um caso um tanto extremo, mas ilustra um aspecto importante: a comunicação pro cessador-processador é normalmente muito mais lenta que a comunica ção entre processos (bolhas) no mesmo processador. Por causa disso, o projetista de sistemas habitualmente tenta agrupar processos e depósitos que tenham alto grau de comunicação no mesmo processador. Vários fatores devem ser levados em conta pelo projetista de sistemas ao fazer essas alocações. Normalmente, os principais problemas são: 511 • Custo. Dependendo da natureza do sistema, a implernentaçãc de processador-único pode ou não ser a mais barata. Para algu mas aplicações, um grupo de microcomputadores de baixe preço pode ser a solução mais econômica; para outras, a imple mentação no computador de grande porte da empresa pode ser a mais prática e econômica 2 • Eficiência. O projetista de sistemas normalmente se preocupa com o tempo de resposta para sistemas on-line e com o tempo de retorno para os sistemas de processamento em lotes. Assim, o projetista deve escolher processadores e dispositivos de armaze namento de dados que sejam suficientemente rápidos e podero sos para satisfazer os requisitos de desempenho especificados no modelo de implementação do usuário. Em alguns casos, o projetista pode escolher uma implementação de múltiplos processadores de modo a que diferentes partes do sistema pos sam ser executadas em paralelo, acelerando, dessa forma, o tempo geral de resposta do sistema. Ao mesmo tempo, o proje tista deve se preocupar com a ineficiência da comunicação processador-processador, como já foi discutido. Para exemplificar, suponhamos que o projetista veja que o sistema contém uma função de edição e uma função de pro cesso, como mostrado na figura 22.3. Colocando cada função em um processador separado, o projetista sabe que o sistema poderá editar uma transação enquanto simultaneamente executa o processamento de outra transação, presumivelmente me lhorando a eficiência geral do sistema. Por outro lado, as transações editadas terão de ser remetidas de uma UCP para a outra; isso pode ser muito eficiente se puder ser feito através de uma conexão direta de hardware, ou muito ineficiente, se a comunicação se processar por meio de vagarosas linhas de telecomunicação.
• Segurança. O usuário final pode ter requisitos de segurança que determinem a instalação de alguns (ou de todos) processadores e/ou dados importantes em localizações protegidas. Os requisi tos de segurança também podem determinar a natureza da (ou a ausência) comunicação processador-processador; por exemplo, o projetista pode ser obstado de transmitir dados de um proces sador para outro por linhas telefônicas comuns no caso de as- informações serem confidenciais. 512 Figura 2 2.3: Comunicação processador-processador • Confiabilic4ade. O usuário final normalmente especifica requisi tos de confiabilidade para um novo sistema; esses requisitos podem ser expressos em termos de intervalo de tempo entre falhas (mean time between failure - MTBF) ou intervalo de tempo entre reparos (mean time to repair - MTI’R) ou de dis ponibilidade do sistema . Em qualquer ciso, isso pode ter in fluência decisiva no tipo de configuração do processador escolhido pelo projetista: ele pode decidir separar os processos do sistema em diversos processadores diferentes de modo a que alguma parte do sistema se mantenha disponível ainda que outras partes estejam inoperantes face a uma falha de hardware. Como alternativa, o projetista pode decidir implementar cópias redundantes de processos e/ou dados em múltiplos processa dores, talvez até com processadores de reserva que possam entrar em ação no caso de alguma falha. Isso é mostrado na figura 22.4; mesmo que a UCP falhe (o que é mais provável, por ser um complexo computador de grande porte), as UCP indivi duais de edição podem continuar operacionais - coletando, editando e armazenando transações para posterior processa mento. De forma análoga, se alguma das UCP apresentar proble mas, as outras possivelmente continuarão funcionando. • Restriçõe políticas e operacionais. A configuração de hardware também pode ser influenciada pelas restrições políticas dire tamente impostas pelo usuário final, pelas pessoas de outros níveis de chefia da organização ou pelo departamento de ope rações responsável pela manutenção e operação de .todos os sistemas de processamento. Isso pode levar a uma específica 513 transação resposta DC Cn .0 o, CD (1) CD o DC o DC Cfl
Figura 22.4: Múltiplos processadores visando a confia bilídade escolha de configuração de hardware, ou pode obstar a escolha de certos fornecedores. De forma análoga, as restrições ambien tais (temperatura, umidade, exposição a radiação, poeira/sujeira, vibrações) podem ser impostas ao projetista, tendo forte in fluência na configuração do processador que ele ou ela escolherá. 22.1.2 O Modelo de Tarefa Depois de alocar processos e depósitos a processadores, o projetis ta deve, usando um método de processador por processador, designar processos e depósitos de dados a tarefas individuais em cada processa dor. A noção de tarefa é comum a virtualmente todas as marcas de hard ware, embora a terminologia possa divergir de fornecedor para fornece dor: alguns utilizam a expressão partição, enquanto outros preferem usar as expressões job step, overlay ou ponto de controle. Sem considerar os nomes, a figura 22.5 mostra como um processador típico divide sua área de armazenamento disponível em áreas separadas, cada uma gerencia da por um sistema operacional central, O projetista de sistemas nor malmente tem de aceitar o sistema operacional do fornecedor (embora possa escolher entre vários sistemas operacionais diferentes para um determinado computador), mas o projetista tem a liberdade de decidir quais partes do modelo essencial designado para aquele processador devem ser alocadas a tarefas individuais dentro do processador. Observe que os processos em um mesmo processador podem precisar se comunicar através de alguma forma de protocolo de 514 resposta comunicação intertarefas. O mecanismo que se ocupa disso varia de for necedor para fornecedor, mas é quase universalmente verdadeiro que a comunicação ocorre através do sistema operacional do fornecedor, como ilustrado pela figura 22.6. Assim como a transmissão de dados de um processador para outro processador é relativamente lenta e ineficiente, a comunicação de dados (ou sinais de controle) de uma tarefa para outra tarefa no mesmo processador também é ineficiente. A comunicação entre processos na mesma tarefa costuma ser muito mais eficiente. Assim sendo, o projetista de sistemas normalmente tentará conservar na mesma tarefa os processos que tenham grande volume de comunicações. Em um processador individual nem sempre é evidente se as ativi dades ocorrem sincronizadamente ou não; isto é, nem sempre é evidente se apenas uma coisa pode acontecer em um determinado instante ou se múltiplas coisas. No caso típico, cada processador individual tem apenas uma UCP, que só pode executar instruções para um processo de cada vez. Entretanto, se um processo estiver esperando por alguma entrada ou saída de um dispositivo de armazenamento (disco, fita, terminal de vídeo etc.), o sistema operacional do processador pode passar o con trole para outra tarefa. Desse modo, o projetista de sistemas muitas ve zes pode simular que cada tarefa seja uma atividade independente e assíncrona. 22.1.3 O Modelo de Implementação de Pro,g rama Por fim, atingimos o nível dc tarefa individual; nesse ponto, o pro jetista de sistemas já
preparou dois níveis de alocação dc processos e SISTEMA OPERACIONAL IAKtI-A 1 1 AKbI-A 2 1 ANLI-A Figura 22.5; A organização de tarefas em um processador 515 III,! liii I armazenamento de dados. Em uma tarefa individual, o computado funciona na modalidade assíncrona; só pode ocorrer uma atividade & cada vez. O modelo mais utilizado para organizar a atividade com um só unidade sincronizada é o diagrama estrutural, que mostra a orga nização hierárquica dos módulos de uma tarefa. Os principais com ponentes de um diagrama estrutural são apresentados na figura 22.7. A leitura dessa pequena estrutura deve ser feita da seguint maneira: notação de módulo notação de chamada (ca11) de um módulo SISTEMA OPERACIONAL Figura 22.6: Comunicação entre tarefas com um processador 4-módulo decha notação de parâmetros de entrada sendo passados para o módulo chamado de chamada - o módulo ch Figura 2 2.7: Componentes de um diagrama estrutural 516 • O módulo A é o módulo executivo mais elevado do sistema composto pelos módulos A e B. O motivo pelo qual A é identi ficado como o módulo superior (superordenado) não é porque esteja topologicamente situado acima do módulo B, e sim porque não é chamado por qualquer módulo, O módulo B, por outro lado, é dito ser subordinado ao módulo A (presume-se que o módulo A seja chamado pelo sistema operacional do computador). • O módulo A contém uma ou mais instruções executáveis, in cluindo uma chamada ao módulo B. Essa chamada pode ser im plementada por um comando CALL em linguagens como FOR TRAN; ou um comando PERFORM ou CALL USING em COBOL; ou simplesmente pela chamada do nome de B em outras lingua gens. O diagrama estrutural
evita deliberadamente indicar quan tas vezes o módulo A realmente chama o módulo B; isso vai de pender da lógica interna de programa no módulo A. Desse modo, pode haver no módulo A um comando como este: ‘ guerra-nuclear-correçar CALL Módulo-E em cujo caso o módulo B jamais será chamado. Mas também poderia existir um comando de programa no módulo A do se guinte tipo: DO WBILE existirem pedidos no arquivo PEDIDOS CALL Módulo-B DO em cujo caso o módulo B poderia ser chamado milhares de vezes. • Quando o módulo B é chamado, a execução do módulo A é sus pensa. O módulo B começa a ser executado a partir de sua primeira instrução executável e quando termina, sai ou retorna para o módulo A, que reenceta sua execução a partir do ponto em que havia parado. • O módulo A pode ou não passar parâmetros de entrada para o módulo B como parte de sua chamada e o módulo B pode retornar ou não parâmetros de saída ao restituir o controle para 517 o módulo A. No exemplo mostrado na figura 22.7, o módulo passa os parâmetros X e Y para o módulo B, e este retorna o parâmetros P e Q. As definições detalhadas de X, Y, P e ( seriam normalmente encontradas no dicionário de dados. mecânica real de transmissão de parâmetros variam de uma lir guagem de programação para outra. A figura 22.8 mostra um exemplo de um completo diagrama estru tural. Observe que ele contém quatro níveis de módulos; isso normal mente representaria um programa de cerca de 500 a 1000 instmçõe presumindo-se que cada módulo represente de 50 a 100 instruções di programa ¶ Existe uma óbvia pergunta neste ponto: como o projetista de siste mas transforma um modelo de processos em rede de um diagrama d4 fluxo de dados no modelo sincronizado representado por um diagram estrutural? Alguns livros sobre projeto de sistemas, incluindo lPage-Jone 1988] e [ e Constantine, 1989], discutem detalhadamente ess questão. Como a figura 22.9 mostra, existe uma estratégia para transfor mar o modelo de rede de fluxo de dados em um modelo de diagram estrutural sincronizado; na realidade, a estratégia é em geral conhecid como projeto centralizado na transformação. O projeto centralizado ru transformação é apenas uma das diversas estratégias para converte um modelo de rede de fluxo de dados em um modelo hierárquico sin Figura 22.8: Um exemplo de diagrama estrutural 518
Diagrama estrutural derivado. Figura 22.9: Estratégia de projeto centralizado na transformação :ronizado; [ 1988], LYourdon e Constantine, 1989] e [ e v1ellor, 1985] discutem várias dessas estratégias. Observe que cada bolha le processo no diagrama de fluxo de dados mostrado na figura 22.9 :orna-se um módulo no diagrama estrutural derivado; essa situação é ealista se os processos forem relativamente pequenos e simples (ex.: se i especificação do processo for menor que uma página de linguagem struturada). Além do módulo que implementa os processos do fluxos le dados, é evidente que o diagrama estrutural também contém módulos jara coordenar e gerenciar a atividade geral, bem como módulos ledicados a trazer entradas para o sistema e levar saídas para fora do ;istema. 519 )iagrama abstrato de fluxo de dados Outras estratégias de projeto utilizam o diagrama de entidade relacionamentos ou outras formas de diagramas de estrutura de dado como ponto de partida da derivação do adequado diagrama estrutura veja [ 19751 e [ 19771 para mais informações sobre essa estratégias de projeto. 22.2 METAS E OBJETIVOS DO PROJETO Além de ter de alcançar os objetivos de projeto especificados o modelo de implementação do usuário, o projetista também se preocup com a qualidade geral do projeto. A capacidade dos programadores er implementar um sistema de alta qualidade e livre de erros depende sc bremaneira da natureza do projeto criado pelo projetista. Analogameni a capacidade dos programadores de manutenção em fazer alterações ni sistema depois que ele entrar em operação depende da qualidade di projeto. A área do projeto estruturado contém diversas diretrizes detalhada que ajudam o projetista a determinar que módulos e que interligaçôe entre eles implementarão de forma melhor os requisitos especificado pelo analista de sistemas; todos os livros relacionados no final deste ca pítulo baseiam-se nessas diretrizes. As duas diretrizes mais importante são o acoplamento e a coesão. Essas e algumas outras diretrizes comun serão discutidas agora. • Coesão. O grau em que os componentes de um módulo (tipica mente as instruções individuais de processamento que com põem o módulo) são necessários e suficientes para executa uma função única e bem definida. Isso na prática significa que 1 projetista de sistemas deve assegurar que ele ou ela não subdi vidiu processos essenciais em módulos fragmentados; e o proje tista deve assegurar também que ele ou ela não agrupou proces sos não relacionados (representados por bolhas no DFD) en módulos sem significado. Os melhores módulos são os fisncic nalmente coesos (isto é, módulos nos quais cada instrução d programa é necessária para a execução de uma tarefa únic e bem definida) e os piores são os coesos por coincic (módulos cujas instruções de programas não têm qualquer rela cionamento significativo entre si) . • Acoplamento. É o grau em que os módulos se interligam ou s relacionam entre si. Quanto mais forte for o acoplamento entn os módulos de um sistema, mais difícil será sua
implementaçã e manutenção, porque a modificação de um módulo necessitar 520 um cuidadoso estudo, assim como as possíveis alterações e mo dificações de um ou mais dos outros módulos. Isso na prática significa que cada módulo deve ter interfaces simples e claras com outros módulos e que o menor número possível de ele mentos de dados deve ser compartilhado pelos módulos. Também significa que um módulo não deve modificar a lógica interna ou os dados de outro módulo, o que é conhecido por conexão patológica (o temido comando ALTER do COBOL é um ótimo exemplo). Tamanho do módulo. Se possível, cada módulo deve ser sufi cientemente pequeno de modo a que a listagem de seu pro grama caiba em uma página (ou, como alternativa, que possa ser exibido erp uma tela do terminal). Naturalmente, às veses não é possível determinar qual será a extensão do módulo até que tenham sido escritas as instruções do programa real; mas as atividades iniciais de projeto muitas vezes dão ao projetista uma boa pista do tamanho e complexidade que o módulo terá. Se for o caso, o módulo grande e complexo poderá ser dividido em um ou mais níveis de submódulos (em raras ocasiões, os proje tistas criam módulos extremamente triviais, por exemplo, módu los com postos de duas ou três linhas de código. Nesse caso, vários módulos podem ser reunidos em um supermódulo maior). • Amplitude do contmle. É o número de subordinados imediatos que podem ser chamados por um módulo gerenciador. Um módulo não deve chamar mais do que aproximadamente meia dúzia de módulos de nível inferior. A razão para isso é evitar a complexidade: se um módulo tiver, digamos, 25 módulos de nível inferior, ele provavelmente conterá lógica de programas demasiadamente complexa (na forma de declarações IF ani nhadas, iterações DO-WHILE aninhadas etc.) que ninguém será capaz de compreender. A solução para uma situação dessas é introduzir um nível intermediário de módulos gerenciadores, como um gerente em uma organização humana faz quando percebe que está supervisionando diretamente 25 subordinados imediatos 6 • Escopo do efeito/escopo do controle. Esta diretriz sugere que qualquer módulo afetado pelo resultado de uma decisão seja subordinado (embora não necessariamente subordinado ime diato) ao módulo que toma a decisão. Isso é algo análogo a uma diretriz gerencial que diz que qualquer funcionário afetado pela 521 conseqüência de uma decisão de um gerente (isto é, dentro d escopo do efeito da decisão) deve estar dentro do escopo d controle daquele gerente (isto é, trabalhando em algum pont na hierarquia de pessoas que se subordinam àquele gerente). violação dessa diretriz em um ambiente de projeto estruturad habitualmente conduz à passagem desnecessária de sinais chaves (o que aumenta o acoplamento entre os módulos), a de cisões redundantes ou (o que é pior) conexões patológicas entr os módulos. 22.3 RESUMO Ainda há muito o que aprender sobre projeto, mas com esta intro dução você deve compreender o processo desenvolvido pelo projetist de sistemas. Como vimos, a primeira etapa é mapear o modelo essencia dos requisitos do usuário em uma configuração de processadores. En seguida, em cada processador, o projetista deve decidir como aloca
processos e dados a diferentes tarefas. Por fim, deve organizar os proces sos de cada tarefa em uma hierarquia de módulos, utilizando o diagram estrutural como ferramenta de modelagem. Observe, ainda, que provavelvente precisarão ser acrescentado, processos e repositórios de dados adicionais ao modelo de implementa ção para acomodar os recursos específicos da tecnologia de implementa ção. Por exemplo, podem ser necessários processos adicionais para au vidades de verificação de erros, edição e validação que não foram mos tradas no modelo essencial; mais outros processos podem se fazer ne cessários para o transporte de fluxos de dados entre UCPs. Depois diss pronto, a programação pode se iniciar. A programação e os testes SCrã discutidos no capítulo 23. REFERÊNCIAS 1.
Meilir Page-Jones, Tbe Practical Guide to Structured System
Deslgn, 2a ed. Englewood Cliffs, N.J.: Prentice-Hall. 1988. 2.
Edward Yourdon e Larry L. Constantine, Structured Design: Funda
mentais of a D of Computer Program and Systems Desig Englewood Cliffs, N.J.: P 1989. 3.
Paul Ward e Steve Mellor, Structured Development for Rea1-Tin
Systems, Volume 3. Nova Jorque: YOURDON Press, 1986. 4.
Michael Jackson, Principies ofProgram Design. Nova lorque: Aca
demic Press, 1975. 522 5. Ken Orr, Struclured Systems Development. Nova lorque: YOURDON Press, 1977. PERGUNTAS E EXERCÍCIOS 1. Qual é a atividade que se segue ao desenvolvimento do modelo de implementação do usuário em um projeto típico de desenvolvi mento de sistemas? 2. Quais são os três principais estágios da fase de projeto no desen volvimento de um sistema? Que modelos ão preparados durante essas três etapas? 3. Por que os modelos são importantes durante a fase de projeto? 1. Qual é o principal propósito do modelo de processador durante a atividade de projeto? 5. Dê três exemplos de como os processos em um modelo essen cial podem ser mapeados para as UCP em um modelo de implementação. 6. Que decisões devem ser tomadas durante a atividade de modela gem de processadores em relação aos depósitos de dados que
foram identificados no modelo essencial? 7. Apresente três métodos conhecidos para a comunicação entre processadores. 8. Quais fatores o projetista deve levar em consideração ao escolher um desses três métodos? Qual desses fatores você considera ser o mais importante? 9. Se você estiver trabalhando em um projeto de desenvolvimento de sistemas em que a confiabilidade tem alta prioridade, como isso afetaria sua decisão sobre a alocação dos processos essenciais e dos depósitos essenciais a diferentes processadores? 10. Dê um exemplo de como as restrições políticas podem influir na alocação de tarefas e depósitos essenciais a diferentes processadores. 11. O que é um modelo de tarefa no contexto deste capítulo? Quais são seus componentes? 12. Apresente três sinônimos conhecidos para tarefa. 13. Sob que circunstâncias tarefas diferentes podem funcionar simultaneamente? 14. Projeto de Pesquisa: escolha um computador comum e um sistema operacional. Explique como diferentes tarefas funcionando sob o controle de um sistema operacional podem comunicar-se umas com as outras. Qual é a sobrecarga típica (em termos de tempo de UCP, utilização de memória e de outros recursos significativos de hardware) causada por essa comunicação intertarefas? 523 15.
Dê uma definição de modelo de implementação de programa
Quais são seus componentes? 16.
Como o projetista deve transformar um modelo essencial de DFI
assíncrono e orientado para redes em um modelo sincronizado hierárquico? 17.
Sob que condições cada bolha no modelo essencial torna-se ur
módulo no modelo de implementação de programa? 18.
Apresente duas estratégias de projeto conhecidas. Faça uma resu
mida descrição de cada uma. 19.
Qual é o principal objetivo que o projetista tenta alcançar quar
do ele ou ela converte o modelo essencial em um modelo d implementação? 20.
Que outros objetivos o projetista habitualmente tenta atingir quar
do ele ou ela cria um modelo de implementação?
NOTAS 1
Perceba que isso é algo irreal, em face da tecnologia computa
cional do final dos anos 80, para qualquer sistema não-trivial. S um sistema tiver 500 bolhas primitivas no DFD do modeli essencial, seria realista considerar a implementação do sistema er 500 UCP separadas? Isso mudará em meados da década de 90. 2
Lembre-se de que existe um orçamento para todo o projeto, qu
deve ter sido estabelecido como parte do processo de análise (vej o capítulo 5). Assim sendo, o projetista deve escolher o sistem mais eficiente que se enquadre nesse orçamento. Entretanto, nã se esqueça do fato de que os orçamentos podem se modificar: o orçamentos feitos na fase de análise eram apenas estimativas podem estar sujeitos a revisão se o projetista demonstrar que é ne cessário gastar mais dinheiro para uma implementação aceitável. 3
Costuma-se definir disponibilidade de um sistema como a percen
tagem de tempo em que o sistema está disponível para o uso. El: pode ser calculada com base no MTBF e no M1TR da seguint maneira: disponibilidade = MTBF/ (MTBF+MTTR) 4 Naturalmente, um módulo chamado EXTRAIR CARACTER nãi soa como se exigisse de 50 a 100 instruções; ele poderia precisa de apenas dois ou três comandos em uma linguagem de prc gramação de alto nível típica. Entretanto, em uma linguagem d baixo nível, orientada para a máquina, seriam exigidas muitas ins truções a mais. 524 5 Exemplos de módulos funcionalmente coesos são CALCULAR RAIZ-QUADRADA, CALCULAR-SALÁRIO-LÍQUIDO e VALIDAR- ENDEREÇO-DE-CLIENTE. Um exemplo de módulo coeso por coin cidência é FUNÇÕES-MISTAS. 6 Existe uma exceção para isso, conhecida como centro de transa ções. Se o módulo gerenciador faz apenas uma decisão simples para chamar um dos subordinados imediatos, então a lógica do programa desse gerenciador será provavelmente bastante simples. Nesse caso, não precisamos nos preocupar com a amplitude de controle do gerenciador. 525 23 PRO GRAMAÇÃO E TESTES
É impossível dissociar a linguagem da ciência ou a ciência da lingua gem, porque toda ciência natural sempre enwke três coisas. a sequência dos fenô menos nos quais a ciência se fundamenta, os conceitos abstratos que trazem esses fenômenos á mente; e as palavras em que os conceitos são e Para espressar um conceito uma palavra é necessária; para descrever um fenômeno é necessário um conceito. Os três refletem todos a mesma e única realidade. Antoine Laurent Lavoisier Traité Elementaire de Chimie, 1789 O que temos de fazer é estar sempre testando novas opiniões e procuran do novas impressões com curiosidade. Walter Pater, The Renaissance, 1873 Neste capítulo, aprenderemos: 1. O papel do analista de sistemas na programação e nos testes. 2. Porque o fast-tracking é vantajoso durante a progra mação e os testes. 3. O que o analista de sistemas deve procurar quando examinar um programa. 4. As principais formas de testes que devem ser executados. A programação e os testes normalmente começam, como era de se esperar, quando termina a atividade de projeto. A programação, ou fase 527 de implementação de um projeto típico envolve a escrita de instruçõe em COBOL, Pascal ou em alguma outra linguagem de programação par implementar o que o analista de sistemas especificou e o que o projeti ta organizou em módulos. Os testes, como o próprio nome diz, envol vem a experimentação do sistema para ver se ele produz as saídas corre tas e apresenta o comportamento correto para um grande número.d’ entradas. Por que isso deve interessar ao analista de sistemas’ Não é verdadi que você já deveria não estar mais envolvido neste ponto’ Não, não ne cessariamente. Por vários motivos, o trabalho que os programadores e o testadores fazem podem influir em seu trabalho, e a maneira como voo organiza seu trabalho pode influir na maneira como eles realizam deles. Esse interrelacionamento entre a análise de sistemas e a programa ção/testes é o assunto deste capítulo. 23.1 O PAPEL DO ANALISTA NA PROGRAMAÇÃO E NOS TESTES No caso mais extremo, o analista de sistemas termina seu trabalh de especificar o sistema e, em seguida, dcspcnde algum tempo com equipe de projeto quando o modelo de implementação está desenvolvi do e quando ocorrem os primeiros estágios de projeto. Mas, quando programação se inicia, o analista de sistemas pode ter se transferido par outro projeto. Porém, existem alguns motivos para que você, como ana lista de sistemas, possa precisar permanecer envolvido no projeto quan do começar a atividade de programação: Um motivo simples. Você é o líder do projeto, e é o responsáve pelos programadores. É
óbvio que você não os pode abando nar. Você estará envolvido no projeto até os testes finais, aceita ção e entrega ao usuário final. Portanto, é importante que voc saiba se os programadores escreveram programas de alta quali dade, e é igualmente importante saber se eles testaram os pro gramas adequadamente. • Outro motivo simples. Você é um analista de sistemas júnior, e c seu cargo é programador/analista ou analista/programador. As sim, além de desenvolver as especificações do sistema, você também está envolvido na escrita dos programas. • Um motivo mais inleressanle. Você faz parte do grupo qu prepara casos de testes que serão usados para testar os pro. gramas escritos pelos programadores. Em muitos projetos, voc 528 pode ser acompanhado nessa atividade por um ou mais usuários, de acordo com a teoria segundo qual os usuários são as pessoas mais capacitadas a imaginar os mais incomuns e ex cepcionais casos para teste. O desenvolvimento de dados de teste pode começar assim que a especificação tiver terminado (na verdade, até antes de estar totalmente terminada); como Tom DeMarco diz, “A especificação é o teste do sistema”. Como nesse momento você só conhece o conteúdo lógico das entra das e saídas, você provavelmente terá de esperar até que o modelo de implementação do usuário esteja pronto antes de poder estabelecer o formato físico das entradas e saídas. Você também precisará do modelo de implementação do usuário para saber quais restrições operacionais (tempo de resposta, volu mes etc.) precisarão ser testadas. Mas essa atividade pode facil mente mantê-lo ocupado até o final do projeto; afinal, se os pro gramas fracassarem nos testes, você terá de trabalhar com os programadores pata ver se o caso de teste está errado ou se os programas estão errados. • Um motwo não tão Óbvio. Você pode estar envolvido no desen volvimento dos manuais, treinando os usuários, planejando a instalação do novo sistema e a conversão dos dados do sistema antigo. Na maioria dos casos isso pode ocorrer em paralelo com a programação e testes do novo sistema. Sendo você o analista envolvido com o novo projeto desde o início, você muitas vezes será visto como o candidato ideal para desempenhar essa tarefa. • Um motivo de.sencorajador. Os programadores podem não en tender sua especificação. Ou ela pode estar incompleta, incon sistente ou contraditória. Tsk! Tsk! Mas essas coisas acontecem, e você pode perceber que os programadores precisam procurá-lo periodicamente para revisar e esclarecer a especificação na medida em que eles a convertem para uma linguagem de pro gramação. Outra variação deste tema: os programadores podem pedir-lhe que mod a especificação porque estão tendo dificuldades para implementá-la. Nesse caso, naturalmente, você terá de ser o mediador (e também o intérprete) entre os progra madores e os outros analistas de sistemas. • Outro motivo desencorajador. Os usuários podem começar a mudar de opinião a respeito dos requisitos quando os pro gramadores já estiverem implementando os requisitos que dis seram desejar. Além do fato de alguns usuários serem irritadiços e fazerem isso só pelo prazer de o fazerem, existem boas razões 529
para esse fenômeno; os usuários vivem em um mundo dir e muitas vezes precisam cumprir alterações de normas que lhe são impostas pela legislação governamental, por exigência dc clientes ou pelas condições gerais do mercado. Assim, pod ocorrer de você ter de modificar a especificação justo quando o programadores a estejam implementando, algo que não faz nir guém feliz, mas pode ter de ser feito. Isso será discutido n seção 23.4. 23.2 O IMPACTO DA ANÁIISE, DA PROGRAMAÇÃO 1 DOS TESTES NA ESTRUTURA ORGANI7ACIONA] Através deste livro, ficou evidente que a análise estruturada envo ve uma firme progressão desde os aspectos de modelagem de alto nív (ex.: diagramas de fluxo de dados de nível superior) aos aspectos d modelagem dos níveis mais baixos, como o desenvolvimento de especi ficações de processos e de um dicionário de dados completo e detalh2 do. De forma semelhante, o processo de projeto envolve o desenvolvi mento de modelos de projeto desde diagramas estruturais de alto nível elementos de baixo nível, como pseudocódigo e fluxogramas. A progn mação deve seguir esse mesmo padrão: os programas têm de ser escrito para módulos de execução de alto nível e serão eventualmente deser volvidos para os módulos do nível mais baixo, que executam cálculo detalhados, validação de elementos de dados etc. Uma coisa sobre a qual ainda não discutimos é o relacionament entre os níveis do síslema e os níveis da oi que constrói sistema. Porém é provável que você tenha ficado com a impressão, apá ler quase todo este livro, que as pessoas que ostentam o título de anali tas de sistemas são responsáveis por todo o trabalho de análise de sistc mas, as que têm o título de projelistas de sistemas são responsáveis pel trabalho de projeto e as que têm o título de programadores são as re ponsávcis pelo trabalho de escrever os programas. Não obstante, existe um problema com essa abordagem - de fatc dois problemas relacionados. Primeiro, as pessoas que têm o título d analistas de sistemas são normalmente senhores com vários anos d experiência. Embora esses senhores geralmente apreciem a tarefa d desenhar diagramas de fluxo de dados e de entidades-relacionamento é improvável que se interessem pela perspectiva de escrever centena de especificações de processos e de definir milhares de elementos d dados. E, depois, há o outro lado desse problema: se o pessoal mais gr duado executa de fato todo esse detalhado trabalho, o que sobra para o programadores? A tarefa deles torna-se quase mecânica por natureza 530 convertendo cuidadosamente especificações de processos em COBOL ou FORTRAN. Qualquer que fosse a criatividade que eles pensavam possuir em suas tarefas parece ter desaparecido 1 Uma solução para esse aparente dilema é permitir que o pessoal mais graduado execute todas as atividades de alto nível do projeto e deixar os elementos de nível júnior fazerem todo o serviço detalhado de baixo nível. Isso significaria, por exemplo, que o pessoal sênior (que possui o título de analista de sistemas sênior ou algo igualmente respei tável) não somente executaria as atividades de alto nível da análise de sistemas (desenhando
diagramas de fluxo de dados e congêneres) mas também as atividades de alto nível de projeto de sistemas e se encarre garia até (arquejem! estremeçam!) da escrita de código de alto nível. Enquanto isso, o pessoal de nível júnior estaria envolvido no projeto desde o princípio (ou tão logo os mais graduados tivessem terminado os aspectos de alto nível da análise) e estaria também envolvido na tarefa de escrever especificações de processos e de módulos, de redigir os itens do dicionário de dados e de escrever os programas dos módulos de baixo nível. A vantagem desse esquema para os programadores é que eles têm de fazer o trabalho criativo dc escrever as especificações de processos e assim têm o prazer de transformar em código suas próprias especifica ções de processos. Esse esquema os envolve no processo de análise de sistemas desde os estágios iniciais de suas carreiras do que seria possível de outra forma. Apresenta ainda a vantagem de conservar os elementos de nível sênior em contato com a tecnologia por forçá-los a continuar executando tarefas de projeto e de programação. Nem todos os analistas de sistemas sênior concordam em que isso seja uma boa idéia, embora admitam que a eles não agrade a maçada de escrever todas as especificações detalhadas de processos como parte de seu trabalho. Em qualquer caso, existe uma crescente concordância em que a tarefa de programação, quando precedida por uma cuidadosa e detalhada análise de sistemas do tipo descrito neste livro, torna-se uma tarefa servil e burocrática que pode desaparecer completamente quando desenvolvermos geradores de código que possam compilar as especifi cações de processos diretamente. Dessa forma, podemos esperar que as empresas modificarão gradualmente o modo de trabalhar nos próximos 5 a 10 anos para se adaptarem ás idéias acima discutidas. 23.3
FAST-TRACKING E IMPLEMENTAÇÃO
TOP-DOWN 4’ Outra impressão que você pode ter tido da leitura deste livro: que as atividades de análise dc sistemas devem ser executadas e completadas 531 antes que as atividades de projeto e programação sejam iniciadas. Einbc ra muitos projetos sejam desenvolvidos dessa maneira, isso não é estri tamente necessário. As atividades de análise de sistemas, de projeto e d programação podem avançar em paralelo umas em relação às outras. O conceito de desenvolvimento paralelo da especificação, do pro jeto e da codificação de um sistema é por vezes chamada de fast-trackin e é referenciada em alguns livros (veja, por exemplo, lYourdon, 1988] como implementação top-down. Ela não é única na área do processa mento. A idéia foi discutida de maneira sucinta no capítulo 5, mas voo pode rever o conceito de implementação top-down como parte do ci cio de vida do desenvolvimento de sistemas que discutimos naquel capítulo. A indústria da construção e muitas disciplinas de engenharia se guem essa abordagem em muitos projetos. Como muitos gerentes d projetos de construção dizem, ‘Não é necessário saber o número d maçanetas de um edifício antes que os alicerces estejam prontos”. N caso do desenvolvimento de um sistema de informações, isso signific que os produtos de
alto nível da análise de sistemas, os documento estruturais de diagramas de fluxo de dados, diagramas de entidades relacionamentos e diagramas de transições de estado, podem ser usado como fundamentos para o projeto de alto nível. E esse projeto de ait nível pode ser empregado como fundamento para se escrever código d alto nível antes que os detalhes da análise de sislemas tenham sid completados. Esta abordagem apresenta muita flexibilidae. Pode-se completa 80% do trabalho de análise de sistemas antes de iniciar-se o projeto e programação, ou pode-se completar apenas 10%. Um plano que exij: um trabalho de análise dc sistemas quase completo antes do projeto di sistemas costuma ser chamado de abordagem conservadora; um plan que necessite de quase total paralelismo da análise de sistemas, do pro jeto de sistemas e da programação é conhecido como uma abordagen radical. Todo gerente dc projeto pode decidir quão radical ou conserva dor deverá ser seu projeto, e pode mudar de opinião dinamicamenti durante o projeto. Por que o gerente do projeto escolheria a abordagem radical? Po que alguém iria quçrer começar o trabalho de projeto de sistemas e di programação antes de terminar a análise de sistemas? Existem muito motivos, dos quais os que se seguem são os mais importantes: Como as atividades de análise de sistemas, de projeto e dc pro gramação são executadas de forma concorrente, existe habi tualmente uma oportunidade de encurtar substancialmente tempo decorrido de um projeto. Em alguns ambientes isso pod ser imensamente importante; por exemplo, quando um sistem; 532 tem, de maneira absoluta e positiva, de ser terminado até uma certa data. • O trabalho de desenvolvimento concorrente pode ser utilizado como uma forma de prototipação: ele possibilita que a equipe do projeto mostre uma versão esqueleto do sistema ao usuário antes que todo o trabalho detalhado de análise de sistemas esteja terminado. Isso pode ajudar a evitar maiores mal-entendi dos entre o usuário e o analista de sistemas que de outra forma poderiam ocorrer mesmo com a especificação estruturada mais cuidadosamente desenvolvida. • Começar o trabalho de programação em um momento anteci pado do projeto muitas vezes suaviza diversas necessidades de recursos, como tempo de máquina, que, de outra forma, poderia transformar-se em um gargalo. Por exemplo, a abordagem con servadora muitas vezes exigiu enormes volumes de tempo du rante os estágios finais de testes, e isso pode ser um grande problema. Se o gerente de projeto vai decidir-se pela abordagem conservado ra ou pela radical está fora do escopo deste livro; alguns ambientes de projeto podem favorecer a abordagem conservadora e outros se mostra rão mais indicados para uma abordagem altamente radical. O principal a ser lembrado é que a abordagem de análise estruturada descrita neste livro não desaconselha qualquer abordagem e nem insiste em qualquer delas. 23.4 PROGRAMAÇÃO E LINGUAGENS DE PROGRAMAÇÃO Se você ainda estiver envolvido no projeto durante o estágio de
implementação, você deve ter pelo menos um conhecimento geral dos aspectos e técnicas de programação. Nesta seção, discutiremos: • Linguagens de programação dc quarta geração • Aspectos importantes de programação • O que procurar quando você examinar a codificação do programador 533 23.4.1 As Quatro Gerações das Linguagens de Programação Os programas vêm sendo escritos desde que os computadores d emprego geral foram desenvolvidos a cerca dc 40 anos atrás. Os progra mas são escritos em linguagens de programação, das quais BASIC COBOL e FORTRAN são exemplos conhecidos. É prático agrupar toda as diferentes linguagens de programação (existem algumas centenas & linguagens diferentes em uso pelo mundo) em quatro gerações distintas • Linguagens de primeira geração. As linguagens de programa ção de primeira geração foram as linguagens de máquina usada nos anos 50; os programadores que desejassem que o computa dor fizesse alguma coisa codificavam as instruções em uns e ze ros binários. Hoje ainda há ocasiões em que um computador de feituoso emite páginas de dígitos confusos; e ainda há alguns jo vens mal orientados que pensam que linguagem de máquina é melhor meio de jogar com computadores pessoais. Mas o restr do mundo parou de pensar em linguagem de máquina há cerca de 25 anos. • Linguagens de segunda geração As linguagens de segunda ge ração são as sucessoras da linguagem de máquina; elas são ge ralmente conhecidas como linguagens de montagem ou assem bler. As linguagens de segunda geração são de baixo nível nc sentido de que a programadora tem de escrever uma instruçãc para cada instrução de máquina. Assim, embora ela conceitual mente possa pensar em termos da instrução X = Y + Z, teria dc converter as seguintes declarações cm linguagem de montagem CLEAR ACUMULADOR LOAD Y INTO ACUMULADOR ADD Z TO CONTEUDO DE ACUMULADOR STORE ACUMULADOR IN X Mesmo este pequeno exemplo mostra a principal desvantageni da linguagem de montagem. Em vez de ser capaz de raciocinai em termos do problema que ela quer resolver, a programadora tem de pensar em termos de máquina. A partir de cerca de 1960, linguagens mais poderosas começaram a aparecer; os pro. gramadores mais equilibrados abandonaram a linguagem d montagem desde então. Infelizmente, ainda há algumas si tuações em que tais linguagens são necessárias. A maioria delas envolve computadores muito pequenos e de baixa energia (que 534 podem ser fabricados a baixo custo e que são suficientemente pequenos para caberem, digar’ios, em um relógio digital) que não têm capacidade para tolerar a sobrecarga associada ás linguagens de alto nível.
Linguagens de terceira geração As linguagens de terceira gera ção são a norma hoje cm dia; elas incluem BASIC, COBOL, FORTRAN, Pascal, C, Ada e muitas outras. Elas são de alto nível no sentido de que um único comando (como “MOVE A TO B” em COBOL) habitualmente representa de cinco a dez instruções em linguagem de montagem (e, às vezes, em torno de cem instruções); elas são de alto nível no sentido, ainda mais impor tante, de que permitem que a programadora expresse pensa mentos de uma forma mais compatível com a área do problema em que ela está trabalhando. Entretanto, elas são de baixo nível sob alguns aspectos importantes. Elas exigem que o programa dor esteja estreitamente envolvido no tedioso trabalho de forma tar a diagramação (layout) dos relatórios e editar e validar as entradas do programa. O programador muitas vezes dirá para si mesmo: «este relatório deveria ter o cabeçalho padrão no alto de cada página, com o número da página à direita e a data à esquerda, como todos os nossos outros relatórios”, mas ele pode ter de escrever 20 ou 30 comandos COBOL para obter isso As linguagens de terceira geração também se caracterizam como linguagens procedurais. Elas exigem que o programador medite cuidadosamente sobre a seqüência de cálculos, ou sobre o pro cedimento, necessário para executar alguma ação. Em uma apli cação científica, por exemplo, o programador pode saber que deseja somar o array A ao array B; entretanto, ele pode ser forçado a escrever as etapas procedurais detalhadas para somar cada um dos elementos dos dois arrays, em lugar de dizer sim plesmente “Some estes dois arrays” sem se preocupar com as etapas procedurais. • Lín de quarta geração As linguagens de quarta gera ção, ou L4G, constituem a atração atual e são consideradas por alguns consultores de computação como o mais importante avanço na área de software dos últimos 20 anos. Algumas delas já existem por cerca de uma década, porém só tornaram-se conhecidas há poucos anos. Exemplos de L4G 5 FOCUS, IDEAL, MARK IV, MANTIS, MAPPER, dBASE-III Plus e Rbase 5000. A maioria dessas linguagens têm as características da pro gramação estruturada de que carecem as antigas linguagens de 535 terceira geração, mas elas dispõem ainda de outros recursos. En particular, a maioria dos tediosos detalhes de programação asso ciados à obtenção de dados para o computador (via terminal) oculta do programador; com um simples comando, o programa dor pode especificar que o computador deve aceitar um deter minado tipo de dado a partir do teclado, validá-lo e armazená-k em um elemento de dado indicado. A mesma tarefa poderi exigir 10 ou 20 comandos de uma linguagem de prograrnaçãc de terceira geração ou de 100 a 200 instruções de uma lin guagem de segunda geração. De modo semelhante, muitos dos aborrecidos detalhes de pro gramação associados à produção de relatórios de saída (ex. listas de inventários, cheques de pagamento, faturas ou um re sumo diário dos pedidos) são manipulados automaticament pelas linguagens de quarta geração. Se o posicionamento exat da informação no dispositivo de saída do computador for relati vamente sem importância (o que freqüentemente é o caso), programador nem sequer precisa especificá-lo; caso contrárü (como no caso de cheques de pagamento produzidos em com putador, onde os valores devem ser impressos em local exato) os detalhes são facilmente especificados em poucas instruçõe de L4G. 23.4.2 Aspectos Importantes da Programação
Qualquer que seja a linguagem de programação usada, existen alguns problemas que se deparam a todos os programadores. Comc analista de sistemas você deve conhecê-los. Os problemas mais comun são os seguintes: Produtividade O mais importante problema de programaçãc hoje provavelmente é o da produtividade: a obtenção de mai software escrito com mais rapidez do que nunca. O principa motivo disso é o enorme backlog de sistemas e aplicações ainda não escritos nas grandes organizações: a grande organizaçãc típica tem um backlog de quatro a sete anos dc novos serviços serem feitos 2 Dessa maneira, as linguagens e técnicas de pro gramação que favorecem a produtividade estão sendo adotada e, exceto em raros casos, a produtividade está sendo conside. rada como mais importante hoje do que a eficiência. 536 • Eficiência: Em algumas aplicações, a eficiência ainda é impor tante. Isso vale para muitos sistemas de tempo-real e pode valer para outros tipos de sistemas que processam grandes volumes de dados (ex.: a maioria dos sistemas executados na Social Secu rity Agency, bem como outros igualmente muito grandes em bancos, em operações de reserva de passagens aéreas, empre sas corretoras de valores e empresas de seguros). Para essas aplicações, costuma ser importante minimizar o tempo de UCP exigido pelo programa; pode também ser importante minimizar a utilização da memória e a utilização de outros recursos como os discos. Observe que a meta da eficiência está habitualmente em conflito com as outras metas discutidas nesta seção: quando se despende mais tempo desenvolvendo um programa eficien te, ele provavelmente será menos manutenível e menos portátil, tendo provavelmente sutis erros residuais e possivelmente de gradará a produtividade de quem escreveu o programa. • Correçãa Pode-se argumentar que este seja o aspecto mais im portante. Afinal, se um programa não funcionar corretamente, não importa quão eficiente ele é. As linguagens de programação como Ada e Pascal são consideradas preferíveis quando a cor reção é um fator essencial (como seria, por exemplo, para al guém trabalhando no sistema Star Wars ou construindo um sis tema de controle para um reator nuclear) porque elas são “forte mente tipadas”: o programador é solicitado a declarar a natureza de suas variáveis (se são inteiras, caracteres, de ponto flutuante etc.) e a linguagem verifica cuidadosamente para impedir referências ilegais a dados, e coisas semelhantes. • Portabilidacle Em alguns ambientes a portabilidade é impor tante; o usuário pode querer processar o mesmo sistema em diversos tipos de computadores. Algumas linguagens de pro gramação são mais portáteis do que outras; ironicamente, isso é mais válido para linguagens de terceira geração (C, Pascal, FORTRAN, COBOL etc.) do que para as de quarta. Entretanto, nãq existe uma linguagem inteiramente portátil; sempre existe uma forma para o programador beneficiar-se dos recursos espe ciais de um determinado computador ou de um determinado sistema operacional. Desse modo, além da linguagem de pro gramação, também devemos nos preocupar com o estilo da programação quando a portabilidade for um fator importante. • Manutenibilidade Por fim, devemos lembrar-nos que os sis temas vivem por um longo tempo e o software precisa ser 537
mantido. A manutenção será discutida em maiores detalhes nc capítulo 24. 23.4.3 Aspectos a Serem Examinados Como analista de sistemas, você pode ter ocasião de examinar ( serviço feito pelos programadores do projeto; na verdade, você pode sei o supervisor deles. Como acima indicado, você develembrar-se de que produtividade, eficiência, correção, portabilidade e a manutenibilidad são provavelmente aspectos importantes. Mas, como essas metas poden ser alcançadas? Você deve consultar outros livros, como lYourdon, 1976 e [ e Plaugher, 19751, que apresentam detalhes sobre a técnicas de programação; contudo, eis alguns importantes aspectos ± programação: Programação estruturada: Presumindo-se que os programas es tejam escritos em uma linguagem de terceira ou quarta geração deve ser seguida uma abordagem de programação estruturada Ela organiza toda a lógica do programa (decisões e laços) en combinações aninhadas de construções de IF-THEN-ELSE e DO WHILE. Quase todos os livros modernos de programação ensi nam uma abordagem de programação estruturada; veja, p0 exemplo, EWelis, 19861, IBenton e Weekes, 19851, lYourdon Gane e Sarson, 19761 e lYourdon e Lister, 19771. Módulos pequenos: É essencial que os programas sejam organi zados em pequenos módulos para que a lógica da programaçãc possa acomodar-se em uma página da listagem de um pro grama. É importante lembrar que a complexidade de um pro grama não cresce linearmente com o tamanho do programa: urr programa com 100 instruções será quase sempre mais de dua vezes mais complexo que um dc 50 instruções. Como vimos nc capítulo 22, isso está principalmente sob o centrole do proje tista; mas o projetista pode não estar apto a dizer quão grand será um módulo, principalmente se não conhecer bem a lingua gem de programação que será empregada no projeto. Assin sendo, o programador pode ter de exercer a tarefa de projeto dividindo o módulo em submódulos de nível inferior de forma que cada um represente não mais de 50 instruções. Simplicidade de eslílo: Muitos livros de programação, com FYourdon,19761 e FKernighan e Plaugher, 19751, oferecem de talhadas diretrizes para a escrita de programas simples - 538 programas que o programador médio pode compreender e que podem ser confiados ao programador de manutenção; entre es sas diretrizes está a sugestão de que o programador deve evitar instruções com expressões booleanas compostas. Por exemplo, IF A AND B OR NOT C AND D THEN ADD 3 TO X. É interessante observar que alguns modelos matemáticos da complexidade de programas foram desenvolvidos nos últimos dez anos - um dos mais conhecidos é o modelo de complexi dade ciclomática de McCabe (veja FMcCabe, 1976]), que oferece uma medida quantitativa da complexidade intrínseca de um programa . Algumas empresas atualmente determinam que todos os novos programas sejam executados através de um ve rificador automatizado de complexidade para assegurarem-se de que eles não sejam demasiadamente complexos. 23.5 TESTES O processo de testes provavelmente ocupará cerca de metade do cronograma de
desenvolvimento de seu sistema, dependendo do cuida do com que tenham sido executadas as atividades iniciais de análise, projeto e programação. Mesmo no caso de ter sido executada uma tarefa rerfeita de análise de sistemas, projeto e programação, é preciso algum esforço para verificar se não há erros. Se, por outro lado, tiver sido feito um mau serviço (o que quase sempre acontece!), então os testes tornam 5e iterativos: a primeira rodada de testes denuncia a presença de erros e as rodadas subseqüentes verificam se os programas corrigidos já estão Funcionando corretamente. O que você precisa saber sobre testes como analista de sistemas? [ naturalmente dependerá de quanto você estiver envolvido no pro :esso. Em muitos casos, o analista de sistemas trabalha em estreita asso :iação com o usuário para desenvolver um conjunto completo e abran ‘ente de casos de testes fundamentados no modelo essencial e no nodelo de implementação do usuário do sistema. Esse processo de tesenvolvimento de casos de testes de aceitação pode ser executado em Daralelo com as atividades de implementação de projeto e programação, te modo que, quando os programadores tiverem terminado seus pro ramas e executado seus próprios testes locais, a equipe usuário/analista stará pronta para seus próprios casos de testes. Além desse conceito básico (que a descrição dos requisitos do isuário forma a base dos casos de testes finais), você deve conhecer 539 os vários tipos de testes, bem como alguns conceitos estreitament relacionados com eles. É o que discutiremos a seguir. 23.5.1 Tipos de Testes A esta altura, pode não lhe haver ocorrido que existe mais de un tipo de teste: que mais pode haver além de imaginar casos de testes depois verificar se o sistema funciona corretamente? A primeira coisa a compreender é que existem diferentes estraté glas de testes: as duas mais conhecidas são os testes bottom-up e os top down. A abordagem bottom-up começa por testar os módulos pequeno de forma individual; essa modalidade é muitas vezes chamada de tes te de unidade, teste de módulo ou teste de programa. Em seguida, o módulos individuais são reunidos em unidades cada vez maiores par; serem testadas em conjunto; isso costuma ser chamado de teste de sub sistemas. Por fim, todos os componentes do sistema são combinado para serem testados, o que é conhecido como teste do sistema, e muitas vezes seguido pelos testes de aceitação, quando o usuário pod submeter seus próprios casos de teste para verificar se o sistema est funcionando corretamente. A abordagem de testes top-down principia com um arcabouço d( sistema; isto é, a estratégia de testes presume que os módulos de execu ção de alto nível do sistema foram desenvolvidos, mas que os módulo de baixo nível existem apenas como simulaçõcs ou “stubs” Como; maioria das funções detalhadas do sistema não foram implementadas, o testes iniciais são muito limitados, O propósito é apenas começar a testa as interfaces entre os principais subsistemas. Os testes subseqüentes tor nam-se em seguida cada vez mais abrangentes, testando aspectos cad; vez mais detalhados do sistema. A abordagem
top-down de testes geralmente considerada melhor para a maioria dos sistemas atualment (para mais detalhes, veja [ 19861). Além desses conceitos básicos, você deve conhecer os seguinte tipos de testes: • Testes funcionais: Esta é a mais conhecida forma de testes. ( objetivo é verificar se o sistema executa corretamente suas fun ções normais. Portanto, os casos de testes serão desenvolvidos introduzidos no sistema; as saídas (e os resultados da atuali zação de arquivos) serão examinadas para testar sua correção. • Testes de recupera ção O objetivo deste tipo de teste é verifica se o sistema pode recuperar-se adequadamente de vários tipo de falhas. Isso é especialmente importante em grandes sistema 540 on-line e em vários tipos de sistemas de tempo-real que con trolem dispositivos físicos e/ou processos de fabricação. Os tes tes de recuperação podem exigir que a equipe de projeto simule (ou provoque) falhas de hardware, faltas de energia, falhas do sistema operacional do fornecedor e assim por diante. Testes de desempenhct O objetivo deste tipo de teste é verificar se o sistema pode manipular o volume de dados e transações recebidas especificadas no modelo de implementação do usuário, bem como verificar se ele apresenta o tempo de res posta necessário. Isso pode exigir que a equipe de projeto si mule uma extensa rede de terminais on-line, de modo a levar o sistema a pensar que está funcionando sob uma grande carga. Existe ainda um último conceito que você deve conhecer: a noção de testes completos. No projeto ideal, geraríamos casos de testes que cobririam todas as entradas possíveis e toda possível combinação de si tuações com que o sistema poderá se defrontar; então testaríamos exaus tivamente o sistema para assegurar que seu comportamento seria per feito. Há um único problema quanto a iSSO: não funciona! A quantida de de casos de teste para um típico sistema grande e complexo é tão absurdamente grande, muitas vezes da ordem de 10 casos distintos ou mais que, ainda que pudéssemos efetuar um teste a cada milissegundo, levaríamos mais tempo que a idade do universo para executar todos os testes! Em conseqüência, ninguém efetua realmente testes exaustivos em algo além de um sistema trivial; na melhor das hipóteses os desenvolvedores do sistema podem esperar criar casos de teste que verificarão (ou cobrirão) uma grande percentagem dos diferentes cami nhos de decisão que o sistema pode seguir . Isso faz com que seja ainda mais importante garantir que o modelo dos requisitos do usuário e os diversos modelos de implementação sejam tão corretos quanto possível. Suponha, por exemplo, que alguém quisesse preparar casos de teste para a parte de um sistema que calcula o salário líquido de um empregado, como mostrado na figura 23.1. Imagine que salário bruto esteja definido no dicionário de dados como um inteiro (isto é, um sa lário expresso por um valor inteiro na moeda corrente) variando entre O e 10.000. Então, poderia parecer que um teste completo consistiria em especificar qual seria o salário líquido correto para cada uma das 10.000 possibilidades do valor de salário bruto.
Poder-se-ia supor que, se a equipe de implementação executasse os 10.000 casos de teste e veri ficasse que fora produzido, de fato, o salário líquido correto, pôdería mos confiar em que o processo estaria funcionando corretamente. Espere! E os valores potencialmente incorretos do salário bruto? E se o usuário introduzir um salário bruto negativo? E se ele introduzir 541 um salário bruto de 100.000? Como existe um número potencialmence infinito de valores possíveis para salário bruto 6, e como não temos co nhecimento do comportamento interno do programa que implementa CALCUlAR SAlÁRIO LÍQIJIDO, nós nos defrontamos com um aparen temente infinito número de casos de teste. Se os casos de teste forem de senvolvidos no final da fase de análise do projeto, com utilização do di cionário de dados e da especificação de processos, não há meio de sa bermos como o programa funcionará quando o programador escrever o código e, desse modo, somos forçados a executar um teste tipo caixa preta. Quando conhecemos a lógica e a estrutura interna do programa (isto é, depois de o programador ter escrito o programa), podemos Fun damentar os casos de testes na lógica do programa e executar o que muitas vezes é chamado de testes de ‘caixa de vidro” ou de ‘caixa branca”. Geralmente podemos demonstrar que se, por exemplo, o pro grama identificar corretamente um valor de salário bruto inferior a zero, ele identificará corretamente todos os valores negativos de salário bruto. Em geral, devemos ser capazes de demonstrar que o programa apresentará comportamento consistente para diversos inte? valos de salário bruto, e, assim, reduzirmos o número necessário de testes a um número gerenciável. Embora isso não se constitua em testes completos, podemos presumivelmente alcançar um nível de confiança mais elevado de que desenvolvemos casos de testes para todos os caminhos significativos que o programa pode tomar. Mas, espere! CALCULAR SALÁRIO LÍQUIDO é apenas um pro cesso, uma bolha entre centenas, e talvez milhares, de um grande siste ma. Se forem necessários, digamos, 1000 casos de testes para verificar se CALCULAR SALÁRIO LÍQUIDO está funcionando corretamente (em termos de correção funcional), então poderiam ser necessários 1000 testes para cada um dos, digamos, 1000 outros processos do sistema. A quantidade total de casos de testes distintos poderia, então, alcançar 1000 * 1000 = 1.000.000. E isso em uma estimativa moderada (sem considerar a dimensão de complexidade adicionada pelos testes de desempenho, testes de recuperação etc.)! Desse modo, temos de admitir que testes completos são uma impossibilidade. Mas podemos, como explicamos acima, escolher salário bruto salário líquido Figura 23.1: Uma pequena parte de um sistema 542 judiciosamente casos de testes, de forma a verificarmos tantos caminhos lógicos do sistema quantos sejam possíveis. Mesmo assim, precisamos estar preparados para um
grande, senão enorme, volume de testes. Para que esses testes sejam executados de maneira eficaz, a equipe de desen volvimento de sistemas necessita de três coisas: planos de testes, descrições de testes e procedimentos de testes. Um plano de teste é exatamente o que o nome diz, um documento organizado que descreve alguma atividade de teste. Um plano de teste típico contém as seguintes informações: • Objetivo do teste: qual é o objetivo do teste e que parte do sistema será testada. • Localização e cronograma do teste: onde e quando o teste será realizado. • Descrições de testes: uma descrição das entradas que serão intro duzidas no sistema e as saídas e resultados antecipados. As des crições das entradas de teste habitualmente são fornecidas no formato do dicionário de dados discutido no capítulo 10. • Procedimentos de testes: uma descrição de como os dados de testes devem ser preparados e submetidos ao sistema, como os resultados de saída devem ser colhidos, como os resultados dos testes devem ser analisados e de quaisquer outros procedimen tos operacionais que devam ser observados. 23.5.2 Conceitos Relacionados Embora muitas empresas executem os testes na modalidade acima descrita, existem alguns conceitos relacionados que podem ser utilizados para melhorar o processo padrão de testes. Entre eles estão os seguintes: • Caminhamentos (Walkthroughs) • Inspeções • Provas de correção Os caminhamentos, discutidos no apêndice D, são uma forma de revisão de produtos técnicos; são amplamente utilizados na indústria de processamento de dados para revisar diagramas de fluxo de dados (e outros produtos da análise de sistemas), diagramas estruturais (e outros 543 produtos de projeto) e também programas. Embora diferentes dos testes seus objetivos são os mesmos: descobrir possíveis erros no sistema. As inspeções são semelhantes aos caminhamentos, mas com um agenda um pouco mais formal de itens que devem ser examinados n programa (ou na especificação, ou no projeto, dependendo do tipo dc inspeção) para que ele possa ser aprovado. Para fazer uma analogia considere o que ocorre a cada ano em que seu carro é inspecionado: c mecânico tem uma lista específica de verificação de características - freios, faróis, descarga etc. que devem ser examinadas para que elc aponha o adesivo adequado no carro. Por fim, existe um número limitado de casos em que provas d correção formais serão desenvolvidas para um programa; o processc aqui é um tanto análogo ao processo de obtenção de provas geométrica que um dia estudamos no colégio. Infelizmente, é extremamente difici desenvolver uma rigorosa prova de correção de programas, além dc tempo que ie gasta, e raramente isso tem sido feito para coisas maiores que umas poucas centenas de instruções de programa. Entretanto, pelc menos um projeto do governo
americano desenvolveu uma prova dc correção assistida por computador para um sistema que envolvia apro ximadamente 10.000 instruções; embora custasse cerca de $500.000 e exigisse 6 meses de trabalho, justificava-se para certos sistemas de altc risco ou de alta segurança. Para uma discussão sobre provas de correção, veja o capítulo 6 de LDunn, 19841 ou os levantamentos em EElspas et a1í 19721 e [ e Basili, 1982]. 23.6 A MANUTENÇÃO DA ESPECIFICAÇÃO DURANTE A PROGRAMAÇÃO: UM PRELÚDIO PARA O CAPÍTULO 24 Como já dissemos, a especificação estruturada pode ser modificada durante o processo de programação. Isso pode ocorrer como resultado da estratégia de fast-tracking anteriormente descrita, ou porque a es pecificação original estava errada ou simplesmente porque os usuários mudaram de opinião sobre seus requisitos, De qualquer forma, isso é uma realidade que ressalta um aspecto importante: a especificação do sistema não pode ser considerada imutável após a fase de análise de sistemas ter sido declarada como terminada. Ela deve ser considerada um documento vivo que necessitará de continua manutenção antes mesmo que afase de manutenção do próprio sistema tenha sido inicia da. O capítulo 24 estuda esse aspecto com mais detalhes. 544 23.7 E DEPOIS DOS TESTES? Você talvez pense que seu trabalho esteja totalmente terminado quando os testes do sistema tiverem sido feitos. Infelizmente, há mais a fazer, embora você possa não estar envolvido em seu papel de analista de sistemas. Entretanto, alguém (e muitas vezes um grande grupo de pessoas) deve executar as atividades finais de um projeto de desenvol vimento de sistemas. • Conversão • Instalação • Treinamento Conve?são é a tarefa de passar os atuais arquivos, formulários e bancos de dados do usuário para o formato requerido pelo novo siste ma. Em alguns raros casos, isso pode não ser uma tarefa de relevância, porque pode não haver dados. Contudo, se o usuário estiver trocando um sistema antigo por um sistema novo, essa tarefa poderá ser delicada e difícil. Um plano de conversão deve ser elaborado, de preferência, as sim que o modelo de implementação do usuário esteja pronto, para tratar dos seguintes problemas: • Se o usuário já possuir dados relativos a um sistema existente, ele provavelmente vai querer usá-los até o último momento possível antes de passar para o novo sistema. Portanto, é difícil considerar os dados existentes como estáticos. • Pode haver um volume tão grande de dados existentes que seja impraticável convertêlos todos de uma só vez. Os arquivos e registros podem precisar ser convertidos de forma paulatina, quando isso se fizer necessário. Isso, é claro, exigirá coorde nação e controle cuidadosos.
• A conversão deve ser executada dc modo automático; isso só pode ser feito se os arquivos e dados atuais existirem sob al guma forma automatizada. Se assim for, será relativamente simples escrever-se um programa (ou utilizar-se um pacote de .algum fornecedor) para converter os arquivos atuais para o for mato requerido pelo novo sistema. Entretanto, às vezes é um tanto difícil converter os dados de maneira automatizada, princi palmente quando os arquivos existentes estão localizados em vários computadores diferentes, em diferentes formatos, e assim 545 por diante. Na verdade, o desenvolvimento de um software d conversão pode tornar-se, por ele mesmo, um importante pro. jeto de desenvolvimento de sistemas! Os dados existentes podem conter erros; na verdade, se esse dados foram criados e mantidos manualmente, você pode estai virtualmente certo que haverá erros. Assim, parte do processo de conversão é destinada à detecção e correção de erros, o que pode tornar o processo ainda mais difícil e consumir mai5 tempo. Alguns arquivos e registros existentes podem revelar-se ilegíveis ou incompreensíveis; em outros casos, pode ser evi dente que os dados existentes estejam errados, mas pode não ser tão evidente quais sejam os valores corretos. Além da conversão dos arquivos existentes, pode ser necessário converter programas e procedimentos. Em alguns casos, os pro gramas e procedimentos existentes podem ser utilizados na forma atual; em outros, terão de ser inteiramente substituídos. A instalação do novo sistema pode ser uma atividade instantânea, porém muitas vezes é uma tarefa importante. Habitualmente, duas coisas precisam ser feitas: • O preparo da localização do computador deve preceder a insta lação do novo sistema, de hábito por vários meses. Isso envolve a construção ou o aluguel das acomodações do computador com força, espaço, iluminação e controle do ambiente (tempera tura, umidade, poeira, eletricidade estática etc.). Isso muitas vezes é feito mediante acordo com o fornecedor do hardware ou com o setor de operações do computador da empresa. • O preparo da localização do usuário também pode ser neces sário, principalmente no caso de sistemas on-line que têm termi nais e impressoras no setor de trabalho do usuário. Nos casos mais simples, os terminais podem ser distribuídos para a área de trabalho do usuário imediatamente antes da instalação do sis tema; em alguns casos, todavia, pode ser necessária a cons trução de todo um novo ambiente de trabalho (considere, por exemplo, um terminal de reserva de passagens em um aeroporto). • A instalação do hardware, presumindo-se que o novo sistema exija seu próprio hardware de processamento, costuma ser le vada a efeito pelo fornecedor do hardware; por vezes estão 546 envolvidos múltiplos fornecedores, principalmente no caso de sistemas on-line e de tempo real. No caso de um sistema simples desenvolvido para um computador pessoal, a instalação pode consistir apenas em retirar-se o computador da caixa e ligá-lo à tomada.
A instalação do software, que envolve o carregamento de todos os programas que foram escritos para o novo sistema no(s) computador(es) apropriado(s) e sua preparação para funcionamento. Lembre-se que os aspectos acima descritos presumem que exista apenas uma instalação em um único lugar. Mas nem sempre é assim; no caso de um sistema distribuído, de grande porte, pode haver uma única e centralizada localização do computador e dezenas ou mesmo centenas de localizações de usuários. Desse modo, pode ser necessário instalar o sistema por estágios, com equipes de instalação especialmente treinadas visitando cada localização de usuário de acordo com uma es cala previamente preparada. Nesse caso, a instalação e a passagem para o novo sistema não pode ocorrer de uma só vez, mas, ao invés disso, deve ser dividida em fases com períodos de dias, semanas e mesmo meses. O treinamento é a tarefa final da equipe de desenvolvimento de sistemas: treinamento dos usuários (obviamente!) e do pessoal de opera ções, dos programadores de manutenção e dos diversos níveis de dire ção. Um plano de treinamento deve ser desenvolvido no início do proje to, porque existe um bom volume de trabalho a ser feito, e esse plano precisa estar pronto ao mesmo tempo (ou antes) que o sistema esteja apto para entrar em operação. O plano de treinamento deve tratar dos seguintes aspectos: • Como o treinamento deve ser realizado? A maioria dos projetos de desenvolvimento de sistemas apóia-se em manuais do usuário e guias de referência para oferecer documentação escrita para os usuários. Entretanto, aulas e seminários ao vivo podem ser adequados, bem como palestras de orientação para gerentés e outros que necessitem conhecer o sistema mesmo que não venham a interagir com ele todos os dias. E, com a tecnologia atual, há uma gama de opções de meios de treina mento: treinamento por videoteipe e videodisco, treinamento com uso do computador e até versões simuladas do sistema real para que os usuários possam treinar a introdução de transações e aprender como interagir com o sistema. 547 No caso mais extremo, o treinamento pode consistir em fac lidades de auxílio extremamente sofisticadas embutidas n próprio sistema. Isso vem tornando-se crescentemente pop lar com a proliferação dos computadores pessoais, mas não muito prático para grandes sistemas que interagem cor uma comunidade grande e diversificada; por outro lado, pc de ser usado para aumentar e reforçar outras formas d treinamento. Quem ministrará o treinamento? Em alguns casos elementos d equipe de desenvolvimento do sistema participam do process de treinamento, principalmente porque supostamente são o que mais conhecem o funcionamento do sistema. Entretantc lembre-se de que o melhor programador (ou analista de sis temas) nem sempre é o melhor treinador. Na verdade, os desen volvedores muitas vezes comportam-se de um modo muito de fensivo quando os usuários começam a perguntar o que ele consideram ofensivo. Além disso, os desenvolvedores estã (quase por definição) terrivelmente ocupados com projeto, codi ficação e testes do sistema até o último minuto; o analista d sistemas pode ter mais tempo disponível depois que o modek essencial e o modelo de implementação do usuário estiveren prontos. Quem será treinado e em que escala de tempo? Obviamente, O:
usuários precisam ser treinados para que possam começar a uti lizar o sistema; por outro lado, não é muito eficiente treiná-lo seis meses antes que possam ter acesso a ele.. Desse modo, treinamento deve ser feito em um período bastante reduzido mas isso, por sua vez, muitas vezes vai interferir com o trabalk diário normal que os usuários têm que cumprir. Portanto, é ne cessário negociar com os usuários um cuidadoso calendário d atividades de treinamento. 23.8 RESUMO Este capítulo discorreu sobre uma ampla gama de tópicos: progra mação, testes, conversão, instalação e treinamento. O espaço não ofere ce ocasião para uma detalhada cobertura desses tópicos, porém a sucinta cobertura apresentada neste capítulo deve dar ao analista de sistema uma visão geral das atividades finais do projeto de desenvolvimento dc sistemas. Detalhes complementares podem ser encontrados em muitas referências no final deste livro. 548 REFERÊNCIAS 1. Edward Yourdon, Managing tbe Systems Life Cycle, 2’ ed. Engle wood Cliffs, N.J.: Prentice-Hall, 1988. 2. Edward Yourdon, Nations at Risk Nova lorque: YOURDON Press, 1986. 3. Edward Yourdon, Techniques ofPro Sfructure and Design, 2’ ed. Englewood Cliffs, N.J.: Prentice-Hall, 1976. 4. Brian KernigJ e P.J. Plauger, The Elements ofProgramming Slyle. Reading, Mass.: Addison-Wesley, 1975. 5. Timothy Wells, Structured Systems Development in COBOL Nova lorque: YOURDON Press, 1986. 6. Timothy Welis, Structured Systems Development in BASIC. Nova lorque: YOURDON Press, 1985. 7. Timothy Wells, Structured Systems Development in Pascal. Nova lorque: YOURDON Press, 1986. 8. Stan Benton e Leonard Weekes, Program It Right: Structured Ptv gramming in BASIC Nova lorque: YOURDON Press, 1985. 9. Edward Yourdon, Chris Gane e Trish Sarson, Leaniing to Program in Structured COBOL, Part 1. Nova lorque: YOURDON PRESS, 1976. 10. Edward Yourdon e Timothy Lister, Learning to Program in Struc tured COBO4 Part II. Nova lorque: YOURDON Press, 1977. 11. Tom DeMarco, Controlling Software Projects. Nova lorque: YOURDON Press, 1982.
12. Glenford Myers, 7 Art of Software Testing. Nova lorque: Wiley, 1979. 13. Tom McCabe, “A Complexity Measure”, IEEE Transactions on Soft ware Engineering, Volume SE-2, Número 12 (dezembro de 1976), pgs. 308-320. 14. Edward Yourdon, Managing the Structured Techníques, 3.” ed. Nova lorque: YOURDON Press, 1986. 15. Robert Dunn, Software Defect Removal. Nova lorque: McGraw- Hill, 1984. 16. B. Elspas e outros, ‘An Assessment of Techniques for Proving Pro gram Correctness”, ACM Computing Surveys, Vol. 4 (junho de 1972), pgs. 97-147. 17. D. Dunlop e V. Basili, «A Comparative Analysis of Functional Cor rectness”, ACM Computing Su?veys, Vol. 14 (junho de 1982), pgs. 229-244. 549 PERGUNTAS E EXERCÍCIOS 1.
Que atividades de um projeto de desenvolvimento de sistem
começam quando termina a fase de projeto? 2.
Quais são os seis motivos pelos quais o analista de sistemas poc
precisar permanecer envolvido com um projeto durante as ativid des de programação e testes? 3.
Se o analista de sistemas for também o líder do projeto, você acn
dita que seja importante que ele conheça as técnicas de program ção e de testes? Por que? 4.
Em sua empresa espera-se que os analistas de sistemas tambér
participem das atividades de projeto e de programação? Você cor sidera isso uma boa idéia? Por que? 5.
Por que o analista de sistemas tende a participar do desenvolv
mento de dados dc teste para um sistema? Quem mais deverá sc envolvido? 6.
O que deve fazer o analista de sistemas se os programadores solici
tarem que ele modifique a especificação do sistema durante a fas de programação do projeto? 7.
O que deve fazer o analista de sistemas se os usuários solicitarem
modificação dos requisitos do sistema depois que os programado res tiverem começado a implementação do sistema? Quão prováve é uma situação dessas? 8.
Por que é possível que um usuário queira modificar os requisito
do sistema depois de terminada a fase de análise do projeto? 9.
Que dificuldades podemos esperar se um analista de sistemas sé
nior tiver de executar todo o serviço de análise de um projeto? 10.
Que tipo de reação negativa podemos esperar dos programadore
de uma empresa quando os analistas de sistemas executam toda as atividades detalhadas dc especificação discutidas através destr livro? 11.
Que tipo de estrutura organizacional pode ser estabelecida para
acomodar a combinação de pessoal sênior/júnior e atividades téc nicas de alto e baixo nível de um projeto? 12.
Se as atividades de análise e de projeto de sistemas tiverem sido
executadas completa e detalhadamcnte podem os aspectos da pro gramação ser automatizados? Por quê? Você acredita que essa situa ção possa se modificar nos próximos 5 ou 10 anos? 13.
É necessário executar as atividades de análise de sistemas até o
final para que a . possa começar? Por quê? 14.
O que significa fast trackir
15.
Em que Outras atividades, aléri o desenvolvimento de sistemas, é
utilizada a técnica do fast tracking? 550 16. O que é uma abordagem conservadora de implementação de um sistema? O que é uma abordagem radical? 17. Quais são os três principais motivos pelos quais o gerente de pro jeto poderia adotar uma abordagem radical na implementação de um sistema? 18. Por que a especificação de um sistema não pode ser considerada imutável no final da fase de análise do projeto? NOTAS 1 Na verdade, as coisas poderiam ser piores e poderiam ser melho res. A pior situação (do ponto de vista do programador) é que poderemos não precisar de programadores! Se a
especificação de processos for escrita em uma linguagem suficientemente formal, poderá ser compilada sem qualquer intervenção humana! Isso já está acontecendo em casos isolados (ex.: especificações de pro cessos escritas na linguagem ADA e compiladas diretamente). Por outro lado, existe a possibilidade de que o programador continue a ter um grande trabalho criativo para fazer se o analista de sistemas redigir a especificação de processos utilizando a abordagem pré- condição/pós-condição discutida no capítulo 11. Nesse caso, o analista terá especificado as entradas e saídas para cada módulo, mas terá deixado para o projetista e, em última análise, para o pro gramador, a tarefa de escolher o melhor algoritmo. 2 Isso não significa quatro a sete anos de trabalho para uma única pessoa, mas, sim, quatro a sete anos de trabalho para toda a orga nização de sistemas de informações gerenciais. Para mais detalhes, leia [ 1986]. 3 Para linguagens de terceira geração como COBOL, a complexidade ciclomática é aproximadamente igual ao número de comandos IF no programa. Para maiores informações, veja [ 19821. 4 Um exemplo de “stub” é um módulo que não executa qualquer processo e se retira tão logo seja chamado; outro exemplo é um módulo que retorna os mesmos parâmetros de saída, quaisquer que tenham sido os parâmetros de entrada que lhe tenham sido passados ao ser chamado. Dessa maneira, os testes top-down ini ciais de um sistema de pagamento podem conter módulos stub que paguem a todos $100 por semana, independentemente de catego ria profissional; o módulo stub para cálculo de impostos pode de duzir $10 de impostos do contracheque de cada um. O objetivo do teste top-down inicial é apenas verificar se o sistema pode fun cionar e se é de fato capaz de gerar uma série de contracheques de $100. 551 5 LDunn, 19841 e LMyers, 19791 apresentam detalhadas discussões sobre abrangência de testes. 6 Na realidade, o número de casos de testes não é infinito, em virtu de da limitada precisão dos números armazenados na memória do computador. Se um número for armazenado como um inteiro, um computador comum permitirá o armazenamento de números até 2 ou talvez 2 Se o número for de ponto flutuante, poderemos representar números até 10100 ou maiores, mas normalmente só disporemos dé oito ou nove dígitos significativos de precisão. Desse modo, isso não representa infinidade, mas, de qualquer maneira, é um número muito, muito grande. 552 24 A MANUTENÇÃO DA ESPECIFICAÇÃO Até agora, o principal profissional de processamento de dados era al guém que podia aprender o suficiente sobre as necessidades das organi zações para e. na linguagem do computador. No futuro, quando nossa sociedade se tomar irrewgavelmente
computadorizada, o principal profissional (será) alguém que possa aprender o suficiente sobre sistemas computadorizados para espressá-los na linguagem hu mana. Sem essa pessoa, teremos perdido o controle da sociedade. Essa pessoa é um engenheiro às avessas. Os mantenedores de software são o inverso dos engenheiros da sociedade. Nicholas Zvegintzov, editor, Software Maintenance News Neste capítulo, aprenderemos: 1. Porque é importante manter-se a especificação atualizada. 2. Que tipos dc modificações precisam ser feitas em uma especificação. Para muitos analistas dc sistemas o projeto está terminado quando as especificações estruturadas estão prontas e aceitas pelo usuário. Nesse momento, a especificação é entregue à equipe de implementação com posta por projetistas e programadores que construirão um sistema a partir da especificação. Naturalmente, alguns analistas dc sistemas permanecem com o sis tema durante as fases de projeto e de implementação. Às vezes o analista 553 1 de sistemas atua como gerente de projeto, orientando e dirigindo o esforços da equipe de implementação. Por vezes o analista de sistema permanece com o projeto para continuar fazendo análise, isto.é, par continuar atuando como intermediário entre o usuário e a equipe d implementação. E o analista de sistemas pode ainda estar incumbido d desenvolvimento dos manuais do usuário, dos dados do teste de aceita ção, do planejamento das instalações e de diversas outras atividade, complementares que podem ocorrer de forma concorrente com o pro cesso de implementação. Entretanto, quase todos os analistas de sistemas deixam o projet após o desenvolvimento ter sido terminado e o novo sistema ter entrad em operação. Alguns programadores permanecem para executar ativida des de manutenção, mas, quando termina a fase dc desenvolvimento, festa acaba, e a maioria dos analistas dc sistemas, projetistas e programa dores é deslocada para novos projetos (e muitas vezes novas empresas onde possam obter salário superior ao que seu atual empregador pod pagar!). Porém o trabalho feito pelo analista de sistemas (todo o trabalh( discutido neste livro) continua a ser importante. Assim como os pmgra mas devem ser mantidos durante os 5, 10 ou 20 anos da vida operaciona do sistema, também a especificação precisa ser mantida. Ou, dito d outra forma, vários aspectos da implementação do sistema serão modi ficados durante o tempo dc vida do sistema, e para cada uma dessa modificações deve ser feita uma alteração adequada e correspondente n especificação. Embora o analista de sistemas original possa não permanecer con o projeto durante seu tempo de vida operacional, é importante qu deixe um legado que possa ser modificado. Este capítulo discute manutenção da especificação do sistema. 24.1 PORQUE É IMPORTANTE
A essa altura, você pode estar um tanto confuso; afinal de contas você deve estar pensando, é perfeitamente óbvio que a especificação d sistema deva ser atualizada. Por que alguém faria de modo diferente Infelizmente, a história da área do desenvolvimento de sistemas indica outra coisa: a imensa maioria, provavelmente mais de 80%, dos sistema presentemente em operação não tem uma declaração exata e atualizada dos requisitos do usuário que o sistema executa. Isto não é um fenômeno que ocorra apenas na área do processi mento de dados. Quantas construções centenárias possuem documento atualizados que descrevam a fiação, os encanamentos, o aquecimento 554 outros detalhes arquiteturais? A verdade nua e crua é que muitas vezes é bem mais fácil fazer uma correção, um aperfeiçoamento ou uma modificação “de qualquer maneira” cm um sistema do que começar pela alteração do documento de requisitos, e depois ir propagando a modifi cação pelo documento de projeto e pela própria implementação. Isso é particularmente verdadeiro quando as modificações precisam ser feitas para corrigir um problema imediato, premente e urgente . “Faremos as modificações do documento mais tarde” dirá o encarregado da manuten ção, “mas primeiro temos que corrigir o problema”. A documentação é a última coisa que alguém deseja fazer, e muitas vezes acaba por não sex feita. Os sistemas de informações têm uma importante característica rela tiva á manutenção: eles duram mais que os desenvolvedores ou os usuá rios que estiverem envolvidos no desenvolvimento original do sistema. Isso também vale para construções; nem o arquiteto e nem o usuário final de uma residência vitoriana de 1880 está disponível para consultas hoje. E isso vale também para muitos sistemas dc informações; depois de 10 ou 20 anos, o sistema está sendo usado pela terceira geração de usuários (alguns dos quais podem não ter idéia dos objetivos originais do desenvolvimento do sistema) e está sendo mantido pela terceira ge ração de programadores dc manutenção (alguns dos quais podem não ter idéia do motivo que levou os desenvolvedores originais a adotarem uma determinada estratégia de projeto) Eis por que Nicholas Zve gintzov descreve os programadores de manutenção como o “inverso dos engenheiros da sociedade”. Existe outro ponto importante a respeito de sistemas de informa ções: eles tendem a ser complexos desde o início, e a complexidade cresce durante os anos de manutenção. Quando um sistema é simples (digamos, 250 instruções em Pascal) sua manutenção é fácil mesmo não havendo documentação. Mas um sistema típico tem pelo menos 100.000 instruções de programas; muitos, dos maiores sistemas em manutenção hoje têm bem mais de 500.000 instruções; e alguns têm mais de um mi lhão de instruções. Ninguém pode compreender um sistema assim tão complexo, principalmente se (1) essa pessoa não estava envolvida no desenvolvimento do sistema original e (2) os requisitos e o projeto do sistema original não estiverem documentados. E, no entanto, isso é exa tamente o que mais pedimos que os programadores de manutenção façam . • Existem dezenas, e talvez centenas, de exemplos de organizações com graves problemas de manutenção do gênero acima descrito. Virtual mente todas as maiores empresas que se computadorizaram há 20 anos atrás agora estão se defrontando com problemas com, os
sistemas de 20 anos cujas implementações são um mistério e, pior ainda, cujos re quisitos dos usuários também são um mistério. 555 A única solução para essa crise no futuro é conservar a documen tação correta e atualizada por tanto tempo quanto o sistema durar. Ma como fazê-lo? 24.2 PRÉ-REQUISITOS NECESSÁRIOS Não se pode conservar atualizado um sistema e a documentação ele associada se essa documentação não estiver correta. Assim, eis ponto de partida: precisamos ,garanhir que, quando um sistema entra em operação, todos os documentos a ele relativos estejam completos consistentes, corretos e atualizados. Através deste livro, discutimos as características de um modelo cor reto dos requisitos do usuário e as diretrizes para assegurar que o mo delo de sistema seja completo e internamente consistente. Para que manutenção continuada tenha sucesso, essas diretrizes devem ser impos. tas e uma pessoa ou grupo independente deve verificar se a documenta. ção está correta antes que o sistema seja posto em operação. Além de nos certificarmos de que os documentos estão corretos, devemos nos assegurar de que existe um mecanismo para executa, modificações continuadas nesses documentos. Não convém que a espe cificação estruturada tenha sido inscrita para sempre com uma pena de aço inoxidável em placas de pedra como uma permanente recordação para as futuras gerações; a especificação deve ser vista como um docu mento vivo, sujeito a alterações constantes, apesar de controladas. 24.3 COMO FAZER A primeira e mais básica regra da manutenção de sistemas é esta: qualquer modificação proposta do sistema operativo atual deve, em todos os casos, iniciar-se por um exame dos impactos na especificação de requisitos do sistema. Isso deve ser feito em todos os casos apresenta dos a seguir, juntamente com qualquer outra proposta de modificação do sistema: • O usuário decide que gostaria de acrescentar uma nova função ao sistema atual. • O usuário não está satisfeito com a maneira como uma função atual é executada e deseja modificá-la. • O usuário quer um novo relatório de saída além dos que já existem. 556 • O usuário quer modificar o formato ou a organizaç de um re latório de saída já existente. • Os programadores de manutenção desejam refazer um módulo para torná-lo mais eficiente. • O departamento de operações anunciou que planeja elevar o nível dos sistemas computacionais da empresa e que serão ne cessárias determinadas modificações.
• O usuário reclama que o sistema produz saídas incorretas para determinada combinação dc entradas. • O setor de desenvolvimento dc sistemas decidiu adotar Ada como nova linguagem padrão de programação. Estão sendo preparados os planos para converter todo o software existente para aquela linguagem. • Foi determinado que o sistema passasse a remeter relatórios de saída para uma nova agência do governo, que ainda não existia quando o sistema foi originalmente desenvolvido. Qualquer modificação desse tipo deve ser ilustrada, documentada e verificada com o usuário, fazendo-se as adequadas modificações no modelo do sistema. Isso costuma ser feito pelo preenchimento de um formulário conhecido como solicitação de alteração de sistema. A modi ficação de manutenção pode envolver algum dos itens abaixo ou todos eles: • Pode ser necessário acrescentar novos terminadores ao dia grama de contexto, ou eliminar terminadores. Pode ser ne cessário acrescentar, eliminar ou modificar fluxos de dados entre o sistema e os terminadores. Funções anteriormente executadas por terminadores podem precisar agora ser executadas no inte rior do sistema; de modo inverso, funções executadas pelo sis tema podem agora ser consideradas fora do sistema e dentro do domínio de um terminador. • Pode ser necessário acrescentar novos eventos à lista de even tos, ou pode ser necessário eliminar eventos existentes. • Se a modificação for substancial, pode ser necessário alterar a declaração de objetivos no modelo ambiental. 557 • Pode ser necessário modificar os modelos de fluxo de dados, d entidadesrelacionamentos e/ou de transições de estado. • Pode ser necessário refinar ou modificar as especificações d processos e o dicionário de dados. • Pode ser necessário modificar diversos aspectos do modelo d implementação do usuário, envolvendo a interface homem máquina, as restrições de implementação relativas a tempo d resposta etc. Qualquer modificação desse gênero não será livre. É possível qu algumas modificações sejam mínimas e só requeiram alguns minutos d trabalho para serem incorporadas apenas alguns minutos para seren feitas as necessárias alterações à especificação e aos programas existen tes. Entretanto, a pessoa ou grupo responsável pela alteração tem a obri gação de escrever a declaração de trnpacto: uma declaração precisa detalhada das mudanças que terão de ser feitas na especificação do sis tema para implementar a modificação proposta. Juntamente com isso deve haver uma declaração do impacto econômico: uma declaração dc custo da implementação da alteração e o benefício estimado que deriva. rá daquela alteração. Isso é especialmente importante se a atividade dc manutenção mudará o escopo do sistema.
Naturalmente, há algumas modificações que não causam impacto na especificação do sistema: a correção de um erro de um programa, a modificação do código para melhorar a legibilidade ou a eficiência do sistema ou uma mudança do hardware existente ou do software de siste ma (o compilador, o sistema operacional, o sistema de gerenciamento de banco de dados etc.). Contudo, mesmo nesses casos, deve ser emitida uma declaração do impacto econômico para que o usuário e o setor de desenvolvimento de sistemas sejam informados dos custos e benefícios relacionados àquela alteração. Qualquer modificação feita em um sistema normalmente resulta em uma modificação no software e/ou no hardware do sistema; pode tam bem causar a alteração dos manuais, dos procedimentos de operação e de vários outros componentes do sistema. Porém o documento mais importante a ser mantido atualizado é a declaração de requisilos do usuário! Sem isso, as futuras modificações serão cada vez mais difíceis de serem feitas; e a mudança para um novo sistema será infinitamente mais dispendiosa, mais consumidora de tempo e mais penosa do que normalmente seria.
-
Não há dúvida de que esta insistência por um especificação de sistema atualizada seria vista com desconfiança por um veterano analista de sistemas com 20 anos de experiência. Afinal, o processo de análise de 558 sistemas tem sido tão difícil por tantos anos bem como a tarefa de desen volver especificações corretas, que a idéia de mantê-la permanentemente atualizada parece quase ridícula. A resposta, a longo prazo, será a automatização. Agora já estão disponíveis estações de trabalho automatizadas de análise de sistemas do tipo descrito no ap&idice A a preços módicos. Elas representam um substancial avanço sobre a tecnologia usada pela maioria dos analistas de sistemas de hoje em dia, assim como os sistemas de processamento de palavras representam um enorme aperfeiçoamento sobre as máquinas de escrever elétricas dos anos 60. Estão em andamento planos mais ambiciosos para desenvolver ambientes de engenharia de software inte grados e abrangentes que servirão como rcpositórios centrais para todos os documentos relativos ao desenvolvimento de um sistema. Entretanto, essa avançada tecnologia provavelmente não estará totalmente desenvol vida até meados dos anos 90. Contudo, ainda há muito a ser feito mesmo com a tecnologia hoje disponível. Simplesmente não há desculpa para fazer-se uma modifica ção em um sistema sem que se efetue a correspondente alteração na especificação do sistema. Para fazer com que isso funcione, entretanto, é necessária uma gerência forte e disciplinada na organização de gerencia mento de sistemas de informações. 24.4 RESUMO Existe um crescente volume de obras sobre o tema da manutenção de software, e pelo menos uma sociedade profissional (a Software Main tenance Association) dedicada aos problemas da manutenção. Entretan to, a maior parte da ênfase atual é voltada para a gerência e para a renovação de programas já existentes; existe também alguma ênfase no
uso de boas técnicas de projeto para a criação de programas manutení veis. Mas a indústria do desenvolvimento dc sistemas somente agora está começando a compreender que sem espec manuteníveis nunca teremos software manutenível. REFERÊNCIAS 1. . Bennett Lienta e B. Swanson, Software Maintenance Management. Reading, Mass.: Addison-Wesley, 1980. 2. James Martin e Carma McClure, Software Maintenace: Tbe Problem and lis Solution. Englewood Cliffs, N.J.: Prentice-Hall, 1983. 3. Girish Parikh, editor, Techniques ofProgram and Systems Mainte nance. Lincoln, Neb.: Ethnotech, Inc., 1980. 559 4.
Carma McClure, Managing Software Development and Maintena,
ce. Nova lorque: Van Nostrand Reinhold, 1981. 5.
Robert Glass e R.A. Noiseux, Software Maíntenance Guidebocn
Englewood Cliffs, N.J.: Prentice-Hall, 1981. 6.
Ned Chapiri, ‘Software Mairitenance with fourth-generation Lar
guages”, ACM Software Engineering Notes, Volume 9, Número janeiro de 1984, pgs. 41-42. 7.
R.N. Britcher e Jj. Craig, ‘Using Modern Design Practices to Uç
grade Aging Software Systems”, IEEE Software, Volume 3, Númer 3, maio de 1986, pgs. 16-24. 8.
Salah Bendifallah e Walt Scacchi, ‘Understanding Maintenanc
Work”, JEEE Transaction.s on Software Engineering, Volume SE 13, Número 3, março de 1987. PERGUNTAS E EXERCÍCIOS 1.
Por que é necessário que a especificação de um sistema sej:
mantida mesmo depois que o sistema tenha sido totalmenti desenvolvido? 2.
Por que os programadores de manutenção são tentados a modifica
um sistema operativo sem atualizar os correspondentes documen tos da especificação? 3.
Projeto de Pesquisa: Encontre a idade média dos sistemas presen
temente em operação em sua empresa. Algo de maior interesse descubra por quanto tempo eles devem continuar funcionandc
antes de serem substituídos por novos sistemas. 4.
Projeto de Pesquisa: Descubra quantos dos sistemas presentement
em operação têm especificações atualizadas. Os usuários e geren tes de sua empresa têm conhecimento dessas estatísticas? 5.
Que dificuldades são causadas pelo fato de um sistema ser utiliza
do por usuários e mantido por programadores que não participa ram do desenvolvimento original do sistema? 6.
Dê seis exemplos do tipo de modificações que um usuário poderia
querer fazer a um sistema operativo. 7.
Por que é possível que novos terminadores tenham que ser acres
centados ao diagrama de contexto durante a manutenção de urr sistema? 8.
Por que é possível que novos eventos tenham que ser acrescenta
dos à lista de eventos durante a manutenção de um sistema? 9.
Sob que condições a declaração de objetivos de um sistema pod
ter de ser modificada durante a manutenção? 10.
O que é a declaração de impactos? Por que ela é importante?
560 11. Por que costuma ser difícil conservarem-se atualizados os docu mentos da análise de sistemas (o modelo essencial do sistema) na maioria das empresas? 12. Que tipos de desenvolvimentos tecnológicos serão provavelmente necessários para assegurar que os documentos da análise de siste mas serão mantidos atualizados? NOTAS 1 Um levantamento em lLientz e Swanson, 19801 mostrou que aproxi madamente 9 de todo o trabalho de manutenção consiste em “apuros emergenciais de programas”. 2 Um estudo efetuado nos anos 70 pela fabricante britânica de com putadores ICL indicou que o sistema típico era mantido por sete aerações de programadores de manutenção antes de ser finalmente alijado. Isso dá a entender que boa parte do que denominamos de programação de manutenção poderia ser descrita mais exatamente como arqueologia. 3 Um dos exemplos mais extremos de um sistema grande e comple xo com requisitos de manutenção continuada é o projeto da Esta ção Espacial presentemente em desenvolvimento pela NASA. Seu objetivo: colonizar e industrializar as proximidades do sistema solar. Seu prazo previsto de desenvolvimento: 30 anos. Ele necessi tará de
permanenle manutenção. 561 25 O FUTURO DA ANÁLISE E STRUTURADA Todas as tentativas de previsão do futuro em qualquer nível de detalhe parecem ridículas em poucos anos. Este livro tem um alvo mais realista, e também mais ambicioso. Ele não tenta descrever o futuro, mas apenas definir as flvnteiras dentro das quais o futuro poderá estar. Se encarar mos os tempos que se estendem adiante de nós como uma região ignota e inexplorada, quero descobrir suas fronteiras e ter alguma idéia de sua extensão. Os detalhes geográficos de seu interior permanecerão desco nhecidos - até que lá estejamos. Arthur C. Clarke, Profiles of lhe Future Através deste livro vimos a evolução de idéias e técnicas na área da análise de sistemas. Elas enquadram-se em três largos períodos de tempo: 1. Análise de sistemas convencional, até meados da década de 70; caracterizada (se o fosse) por especificações narrativas seme lhantes a novelas vitorianas, dificeis dc ler e compreender, e virtualmente impossíveis de manter. 2. Análise estruturada clássica, de meados dos anos 70 a meados dos anos 80, como descrito em [ 19781, [ e Sarson, 1977] e outros. Ela caracterizava-se por versões iniciais de modelos gráficos e pela ênfase na modelagem de imple mentações atuais de um sistema antes da modelagem do novo sistema. 3. Análise estruturada moderna, mostrada neste livro e em outras obras recentes, como IWard e Meilor, 1985] e [ e Palmer, 19841. 563 Este capítulo resume algumas das maiores mudanças ocorra desde a apresentação da análise estruturada clássica no final dos anos e utiliza o tema como ponto de partida para uma discussão sobre prováveis modificações nos próximos 5 a 10 anos. 25.1 O QUE MUDOU Alguns aspectos da análise estruturada modificaram-se gradu: mente durante os últimos dez anos. As principais áreas de mudanç incluem: Mudanças da terminologia. Agora utilizamos a expressão m delo ambiental como meio de descrevermos o que se costuma’ chamar de diagrama de contexto. Isso deve-se ao fato de a an use estruturada clássica não incluir a lista de eventos como par do modelo formal
do sistema. Além disso, agora utilizamos termo essencial ao invés de lógico, para descrever o modelo qi. se concentra naquilo que o sistema deve fazer, e a palavra í plementação em lugar de fisico para descrever o modelo volta para como o sistema deve ser desenvolvido. Essas são, evident mente, modificações menores, mas elas auxiliaram a reduzir confusão ao se tratar com usuários que pensam que o oposto um sistema lógico seja um sistema ilógico. • Subdivisão de evento.s. Um dos mais significativos avanços análise estruturada, que discutimos nos capítulos 20 e 21, é utilização de uma lista de eventos para orientar o desenvol mento inicial do modelo comportamental. Ela substitui a abc dagem da estrita subdivisão top-down do diagrama de contex ao diagrama de fluxo de dados de nível superior (figura 0) e figura O aos níveis inferiores, e assim por diante. Embora abordagem top-down não seja errada sob qualquer sentido palavra, tem sido de utilização dilicil para muitos analistas sistemas; a abordagem de subdivisão de eventos, que é un abordagem middle-out, provou ter tido mais sucesso em muit projetos de análise. • Diminuição da ênfase no modelo fisico atual. Como o capíti lo 17 ressaltou, existem vários motivos para que o analista sistemas sea tentado a modelar a implementação atual de u sistema. Porém, freqüentemente percebemos ser essa un 564 tentação perigosa e que o analista de sistemas despende mais tempo nessa atividade do que ela merece. Embora não preten damos declarar fora da lei o modelo fisico atual, nós desencora jamos e desenfatizamos sua utilização. A análise estruturada moderna enfatiza o desenvolvimento, logo que possível, do modelo essencial do novo sistema do usuário. Ferramentas de modelagem de tempo-real. A análise estruturada clássica era inicialmente voltada para o desenvolvimento de sis temas comerciais diretos; ela não tratava de problemas de inter rupções, sinais e tempo. Entretanto, muitos dos complexos sis temas de hoje incluem diversos aspectos de tempo-real, e as ferramentas de modelagem da análise estruturada foram estendi das de acordo. Os fluxos de controle e processos de controle foram utilizados para aumentar os diagramas de fluxos de dados; e os diagramas de transições de estado foram apresenta dos como uma nova ferramenta de modelagem para representar os requisitos de tempo-dependência de um sistema. • Estreita Integração entre a modelagem de processos e a modela gem de dados. A análise estruturada clássica utilizava diagramas de estruturas de dados para modelar o relacionamento entre os depósitos de um diagrama de fluxo de dados. Entretanto, os relacionamentos eram muitas vezes obscurecidos pela notação, que tendia a provocar intensas discussões e debates sobre o projeto e a implementação do banco de dados fisico. O dia grama de entidades-relacionamentos apresentado neste livro oferece um modelo mais lógico ou conceitual dos dados exi gidos pelo sistema, e possibilita que os relacionamentos entre as entidades de. dados sejam descritas rigorosa e detalhadamente. Além disso, as normas de balanceamento discutidas no capítulo 14 asseguram que o modelo de dados (documentado com os DER) seja totalmente consistente e compatível com o modelo de processos (documentado com os DFD e especificações de processos). Não é importante que você esteja familiarizado com essas modifi cações, porque você pode estar trabalhando em uma empresa que ainda não incorporou as alterações a seus
padrões; em 1987, quando este livro estava sendo escrito, muitas grandes empresas que visitei nos Estados Unidos ainda estavam utilizando métodos de desenvolvimento de siste mas de pelo menos 10 anos atrás. 565 25.2
FUTUROS DESENVOLVIMENTOS DA ANÁLISE
ESTRUTURADA Ninguém pode ter a pretensão de conhecer o futuro; o máxim que se pode esperar é, como diz Arthur C. Clarke na introdução dest capítulo, encontrar alguns sinais do futuro. Avanços recentes sugerer várias tendências que provavelmente se estenderão à próxima décad As tendências SãO: 25.2.1 Maior Disseminação do Interesse pela Análise de Sistemas Os computadores, como sabemos, estão tornando-se uma part ubiqua da vida de todos. Em conseqüência disso, uma parte gradua mente maior da sociedade está aprendendo a utilizá-los e a falar sobr eles; um aspecto ainda mais importante (no contexto deste livro) é qu muitas pessoas estão gradualmente tornando-se familiarizadas com análise estruturada e com outros aspectos da engenharia de software. E estou particularmente interessado no futuro impacto da análise estrutun da em três grupos: a alta direção de nossas organizações empresariais governamentais, crianças e profissionais do processamento de dados no países do Terceiro Mundo. Na maioria das grandes organizações, os componentes dos nívei superiores de direção são, normalmente, pessoas entre 40 e 60 anos d idade, o que significa que foram educadas e passaram pelos anos d formação de suas carreiras há 20, 30 ou 40 anos atrás. Os computadore como é sabido, já existiam há 20 anos (e mesmo 30 anos atrás), mas nã estavam amplamente disponíveis nem faziam parte da tecnologia ou d cultura com que essas pessoas cresceram. Mas isso está começando mudar; estamos começando a ver pessoas de níveis elevados de chefi que ou (1) iniciaram suas carreiras nos setores de processamento d dados ou de MIS (Management Information Systems - Sistemas de Ir formações Gerenciais - SIG) 1, ou (2) começaram em alguma outra part da organização (contabilidade, vendas, fabricação etc.) cuja operaçã diária foi substancialmente afetada pela tecnologia computacional. Iss quer dizer que você pode esperar, como analista de sistemas, que a alt direção se torne progressivamente cônscia da estratégica importânci dos sistemas de processamento de informações em sua empresa e pr gressivamente interessada em examinar modelos de alto nível dos princ pais sistemas novos. Se você tentasse mostrar um fluxo de dados a executivo principal de sua empresa hoje, é provável que ele não o er tendesse e nem quisesse compreender porque devería entender. Der tio dos próximos 5 anos, creio que a alta direção entenderá que é tã 566 importante ser capaz de ler (e criticar) um modelo de sistema quanto o é ler e criticar um balanço ou um demonstrativo de lucros e perdas. As crianças também tornar-se-ão mais familiarizadas com a análise estruturada nos próximos anos. A programação estruturada e o projeto estruturado já estão sendo
ensinados no segundo grau escolar em algu mas partes dos Estados Unidos. A análise estruturada, que antes era matéria dos seminários do nível de graduação, agora é ensinada no terceiro e quarto anos dos curriculos universitários da ciência da compu tação e das escolas comerciais, e logo fará parte de uma matéria padrão do primeiro ano universitário. Divisões longas eram assunto do curso superior e agora são ensinadas às crianças; a análise estruturada será igualmente um tópico que as crianças aprenderão durante seu processo educacional normal. Foi feita uma estimativa de que uma criança nascida em 1980 estará formada na escola secundária no final do século, tendo escrito 10.000 linhas de código; isso equivale aproximadamente a dois anos de expe riência de programação em tempo integral de um programador adulto de hoje. Durante essa experiência em programação, prevê-se que a geração atual de jovens adquirirá crescente experiência com o projeto e a análise de sistemas. Nem todos os componentes dessa geração seguirão a profis são de programador ou de analista de sistemas; na verdade, apenas uma pequena fração se decidirá por essas carreiras. Mas as demais crianças dos dias atuais, quer prefiram ser contadores ou engenheiros, comercian tes, professores ou políticos, formarão uma comunidade de usuários finais inteligentes de sistemas de informações; os usuários saberão muito mais sobre o que podem esperar de um analista de sistemas e sobre o que lhe pode ser solicitado. Grande parte de nosso trabalho atual, de vida, aparentemente, à dificuldade de tratar com usuários ignorantes, poderá ser desnecessária no futuro. Existe um outro aspecto do crescente interesse pela análise estrutu rada que merece ser mencionado: o impacto nas indústrias de software do Terceiro Mundo. Na década passada, a competição internacional em diversas indústrias manufatureiras intensificou-se e as indústrias america nas muitas vezes perderam terreno (ou foram alijadas) na competição com as indústrias japonesa, coreana, chinesa ou brasileira, que oferecem produtos de alta qualidade a preços competitivos. O mesmo fenômeno está começando a acontecer na indústria de desenvolvimento de siste mas. As técnicas de engenharia de software, incluindo as técnicas de análise estruturada discutidas neSte livro, podem auxiliar as organizações competitivas a desenvolverem sistemas com produtividade dez vezes superior à de muitas organizações americanas e com nível de qualidade (expresso em tempo médio entre falhas ou número de erros) cem vezes maior que os das organizações americanas comparáveis 2 E, tendo em vista que, em grau crescente, todos os nossos produtos e todos os nossos serviços dependem de sistemas de informações fundamentados ei computadores, isso tem profundas implicações para toda a indústri americana. 25.2.2 A Pro4feração das Ferramentas Automatizadas No decorrer deste livro mencionamos a possibilidade da utilizaçã de ferramentas baseadas em estações de trabalho para automatizar clivei sos aspectos da análise estruturada, particularmente as atividades d intenso labor como a criação de modelos gráficos de sistemas e a verifi cação da completude e correção deles. O apêndice A descreve as características de muitas dessas ferra mentas do analista que estavam disponíveis no mercado por volta di 1987, bem como os recursos que provavelmente serão acrescentados ao produtos comerciais nos próximos anos, O que interessa é que esse produtos existem agora, e tornar-se-ão crescentemente poderosos n:
próxima década. Porém, poucos analistas utilizam essas ferramentas hoje. Em 198 estimava-se que menos de 2% dos analistas de sistemas na América dc Norte e na Europa tinham acesso pessoal a uma ferramenta automatiza da adequada. Isso significa que a típica empresa de desenvolvimento d sistemas tem uma ou duas estações de trabalho para desenhar diagrama de fluxo de dados, diagramas de entidades-relacionamentos etc. Essa estações de trabalho podem ser compartilhadas por toda uma organi zação de cem ou mais pessoas, mas são muitas vezes mais utilizadas poi uma equipe isolada de projeto que teve a sorte, a tenacidade ou a c rividência de investir nessa tecnologia. Estima-se que por volta de 1990 aproximadamente 10% dos analis tas de sistemas na América do Norte e na Europa (e em outras regiõe civilizadas do mundo) terão suas próprias estações pessoais de trabalho E em meados dos anos 90 é razoável esperar que pelo menos 50% do analistas terão suas próprias estações de trabalho. Quando tivermos obti do essa massa crítica será razoável argumentar que nossa abordagem análise de sistemas modificou-se fundamentalmente, porque a maiorii dos analistas praticantes estará utilizando novas e poderosas ferramentas, Para fazer uma analogia: é interessante falar a respeito dos melhoramen. tos que podem ser obtidos na área da carpintaria utilizando-se uma serra elétrica ao invés de sua congênere manual, mas o assunto é discutível sc apenas 1% das carpintarias dispuser de eletricidade. E o poder da ferra. menta afeta realmente o modo como lidamos com o mundo à nossa volta; Craig Brod falou sobre isso com muita eloqüência em um clássicc livro intitulado Technostress (EBrod, 19841): 568 As ferramentas sempre causaram grandes mudanças nas sociedades humanas. Elas nos criam da mesma forma como nós as criamos. A lança, por exemplo, fez muito mais do que estender o alcance do ca çador; ela mudou sua maneira de andar e a utilização de seus braços. Ela estimulou a melhor coordenação olhos-mãos; ela con duziu às organizações sociais pelo rastreamento, abate e reco lhimento de grandes presas. Ela ampliou a distância entre o caçador inábil e o caçador hábil e tornou o acúmulo de informações mais importante quando as caçadas tomaram-se mais complexas. Houve outros efeitos menos evidentes: alterações na dieta dos grupos caçadores levaram ao compartilhamento da comida e à formação de novas relações sociais. O valor da habilidade artesanal nasceu. As pessoas começaram a planejar antecipadamente, armazenando ar mas para reutilização. Todas essas novas necessidades relativas às ferramentas, por sua vez, estimularam maior desenvolvimento do cérebro. A complexidade do cérebro levou a novos utensílios, e novos utensílios tornaram os cérebros ainda mais complexos van tajosos para a sobrevivência da espécie. A esta altura, parece evidente que a tecnologia de ferramentas automatizadas continuará a progredir durante os próximos 10 anos. O estojo de ferramentas do analista dos meados da década de 90 quase certamente terá sofisticados recursos de verificação de erros e a capaci dade de gerar código e até sugerir (usando técnicas de inteligência artificial) possibilidades de reutilização de códigos de bibliotecas de software. 25.2.3 O Impacto dos Desastres da Manutenção
No capítulo anterior discutimos o uso do modelo de análise estruturada para facilitar a manutenção e a modificação contínuas de sistemas. Porém, esse é um problema que muitas vezes parece abstrato, filosófico e politicamente sem imporiancia durante a fase de desenvolvimento de um projeto, quando a ênfase principal parece ser conseguir entregar o sistema ao usuário. De preferência, um sistema que funcione; se possível o sistema que o usuário desejava. Mas, no caso disso falhar, qualquer sistema que pareça funcionar e satisfaça ao menos alguns dos requisitos do usuário. A realidade política é simplesmente a seguinte: a importância da análise estruturada e dos rigorosos e formais modelos de sistemas não foi totalmente compreendida por muitos dirigentes de nossas organiza çôes. Mesmo nas fileiras do gerenciamento de PED, a análise estruturada não merece o mesmo entranhado sentimento de urgência que a necessi dade política de entregar-se em tempo ao usuário um sistema que fun cione (ou que conste estar funcionando). 569 Como já sugeri anteriormente, essa situação pode modificar-s quando a população usuária conhecer melhor a tecnologia do processa mento e quando a competitividade dos países do Terceiro Mundo tomai se mais intensa. Existe, porém, um Outro fenômeno que evidenciará necessidade de modelos de sistemas atualizados que sejam mantidos d forma tão diligente quanto os programas-fonte: desastres de manurenØ que farão os sistemas atuais entrarem em colapso. No caso mais extremo, isso pode fazer com que um sistema exi tente - um grande, complexo e não documentado sistema - termin anormalmente, ou pare, sem que alguém seja capaz de imaginar com repará-lo. Mas isso é difícil de ocorrer; é mais provável que a causa d falha seja identificada e simplesmente expurgada. A advertência ser ‘Não se pode mais introduzir uma transação tipo X25 no sistema porqu causa problemas”. Não, a causa provável de um grande desastre de manutenção é total impossibilidade de fazer-se uma necessária e uigente mod de um sistema. Essas modificações muitas vezes são determinadas pc nova legislação ou pela política governamental; mas também podem se necessárias por causa de mudanças no ambiente da empresa ou n: situação da competição. Muitas empresas já estão enfrentando esse problema; muitos do sistemas projetados no final dos anos 60 ou no início dos 70 estão à beir: do colapso, e isso um dia acontecerá. Parte do problema estará relacio nado à Implementação do sistema, isto é, o código já foi emendado remendado tantas vezes que não é mais possível determinar com exati dão como o sistema funciona. Mas o maioL problema, em minha opinião, é que ninguém sabe oi lembra o que esses iistemas realmente devem fazer. A terceira geraçã de programadores de manutenção está agora interagindo com usuário de terceira geração para discutir possíveis modificações em um sistem: cujos requisitos originais são um mistério para todos. Nesse ambiente, inevitável que os programadores de manutenção um dia cruzem os bra ços e se recusem a fazer mais alterações.
Ao defrontar-se com um problema desse gênero, a alta direção ter: provavelmente uma reação automática: comissões serão formadas, nor mas serão impostas e novos procedimentos serão exigidos. Assim com temos visto líderes do governo reagirem a problemas de resíduos tóxi cos, derramamentos de petróleo, corrupção e vários outros problemas somente depois da ocorrência de um grande desastre, acredito qu muitos dirigentes da cúpula empresarial e governamental reagirão a problema de modelos não existentes de sistemas somente após have ocorrido um sério problema de manutenção. 570 25.2.4 O Casamento entre a Análise Estruturada e a Inteligência A rt No momento em que este livro está sendo escrito, uma imensa atenção está sendo devotada pelas empresas, pelo governo e pela indús tria do processamento de dados à inteligência artificial (IA): sistemas especialistas, sistemas em linguagem natural, robótica e muitos assuntos conexos. Embora a IA tenha um dia sido considerada um assunto aca dêmico de pouca aplicação prática, e apesar de ter sido implementada em hardware exótico com linguagens de programação incomuns como LISP e PROLOG, ela agora está tornando-se um tema de crescente impor tância - principalmente a área de sistemas especialistas, os sistemas que podem imitar o comportamento de pessoas peritas em certos campos estreitamente definidos. Um crescente número de pacotes de software e de livros de IA está disponível para ambientes baseados em COBOL e em PC (veja, por exemplo, [ 19851, [ 19851, [ 1985), [ 1986] e [ 19851. Uma crescente quantidade de aplicações de IA, de diagnós ticos médicos a exploração de petróleo, avaliações comerciais e planeja mento de impostos, estão entrando no fluxo principal do mundo dos negócios . O que isso tem a ver com a análise estruturada? A conexão entre a inteligência artificial e os sistemas especialistas funciona em ambas as direções: a análise estruturada pode auxiliar no processo de construção de um sistema especialista, e a tecnologia dos sistemas especialistas e ajudar no processo de análise estruturada. Quando se constrói um sistema especialista, três aspectos do siste ma podem ser dominantes: a incerface homem-máquina, a representação do conhecimento e o mecanismo de inferência que avalia e interroga o banco de conhecimentos. A interface homem-máquina pode envolver entradas em linguagem natural (Inglês, Francês, Alemão etc.) e uma combinação de gráficos, texto e som como saída. O banco de conheci mentos pode ser expresso como uma série de regras IF-THEN-ELSE ou como uma série de quadros . O mecanismo de inferência pode basear- se na técnica de caminhamento em avanço (forward chaining) ou na de carninhamento retrospectivo (backward chaining) e ser implementado com uma ‘export shell” oferecida por um fornecedor. Mas o que há de significativo sobre tudo isso é que os componen tes dos sistemas especialistas estão agora tornando-se parte de um siste ma maior, por exemplo, um sistema operativo que alimenta e atualiza o banco de conhecimentos ou que utiliza a saída do componente do siste ma especialista para executar outras funções do sistema. Assim, as fer ramentas de modelagem da análise estruturada podem ser usadas para 571
auxiliar a modelar o sistema geral. Porém, ainda mais importante, is quer dizer que durante os próximos 5 ou 10 anos, você terá que aprei der a tecnologia dos sistemas especialistas e artificiais para poder ser ui bom analista de sistemas, O livro de Kelier (IKelIer, 1986)) é um boi meio para começar, já que ele mostra muitas das interações entre análise estruturada e os sistemas especialistas. Em sentido inverso, a IA pode auxiliar no processo de análise e truturada, agindo como um guia para um analista júnior através d; diversas etapas e processos descritos neste livro. Pode-se facilmeni imaginar, por exemplo, um “analista assistente” que responderia un’ série de perguntas do analista humano e que produziria um diagrama c contexto proposto ou uma lista de eventos. Pense um pouco: você coi segue recordar, agora que atingiu o fim do livro, todas as normas diretrizes das centenas de páginas lidas? Você acredita que se lembrai delas daqui a um ano? Não seria ótimo ter um sistema especialista disp nível em um PC que o pudesse lembrar de como desenhar DFD, DER STD que fossem corretamente equilibrados? Embora isto seja entusiamante, você não deve imaginar que ( sistemas especialistas afastarão os analistas humanos. Os pesquisador nesta área indicam que todos os sistemas especialistas bem-sucedido de diagnosticadores médicos a analisadores de documentos, devem es sucesso ao fato de concentrarem-se em um domínio muito limitado d conhecimento. Um analista de sistemas, portanto, realmente precisa s perito em diversas áreas diferentes: ele precisa conhecer a tecnologia d análise estruturada apresentada neste livro; precisa conhecer a área d aplicação do usuário; tem que saber bastante sobre contabilidade, pai poder produzir cálculos exatos de custo/beneficio; deve ser perito ei comunicações e psicologia cogniuva, para poder comunicar-se de mod eficaz com o usuário; e também deve ser versado em hardware e sof ware de computadores, para poder comunicar-se eficazmente com c projetistas e os programadores. As estimativas atuais (veja, por exemph EBarstow, 19871 são de que os sistemas especialistas estarão aptos a aux liar na tarefa do analista em sistemas simples em meados da década d 90, mas só depois do fim do século é que a tecnologia dos sistemas ei pecialistas será capaz de fazer a análise de grandes sistemas. 25.2.5 O Impacto das Novas Gerações de Hardware Enormes somas de dinheiro estão sendo gastas hoje por empresa privadas, universidades, órgãos de pesquisa, estabelecimentos militares governos por todo o mundo, com o objetivo de produzir hardware subi tancialmente mais poderoso durante os próximos 10 ou 15 anos. Uni recente previsão feita em uma palestra na 1986 FalI Joint Çomput 572 Conference por Gordon Beil, da National Science Foundation, afirmou que a tecnologia do hardware será aperfeiçoada por um fator de 10 nos próximos 5 anos, e depois por outro fator de 10 nos 5 anos seguintes, e por mais outr fator de 10 nos 5 anos subseqüentes. Na mesma confe rência, o físico laureado com o prêmio Nobel, Ken Nilson, fez uma previsão ainda mais otimista: um aperfeiçoamento por um fator de 100 nos próximos 5 anos, seguido por outro fator de 100 nos 5 anos seguin tes e por mais outro fator de 100 nos 5 anos subseqüentes. Desse modo, esses dois eminentes cientistas sugeriram que dentro dos próximos 10 a 15 anos podemos esperar que o hardware seja de 10 a 106 vezes mais poderoso que os computadores de hoje.
O que tem isso a ver com análise de sistemas? Simplesmente isto: a definição dos requisitos do usuário para um sistema de informações deve ser feita dentro do contexto do que o usuário e o analista de sis temas consideram ser possível com a tecnologia disponível. Mas o que julgamos ser possível fundamenta-se amplamente no que sabemos agora sobre a tecnologia de computadores. Pode-se objetar que a maioria dos usuários finais e dos analistas de sistemas sequer utiliza a tecnologia de hardware existente, e, portanto, o que farão com uma tecnologia um milhão de vezes mais avançada? A experiência passada com outros progressos tecnológicos, por exemplo, na área das comunicações (dos sinais de fumaça ao telégrafo, telefone etc.) e dos transportes (dos cavalos aos automóveis, aviões etc.) dá-nos uma pista; nossa primeira reação à tecnologia radicalmente aper feiçoada é continuar fazendo o mesmo tipo de coisas que fazíamos an tes, porém de maneira um pouco mais rápida e com mais facilidade (e mais economicamente, em muitos casos). Só mais tarde é que começa mos a vislumbrar aplicações inteiramente novas para a nova tecnologia. Como exemplo, considere o ramo dos transportes, que todos co nhecemos; embora as viagens aéreas sejam relativamente novas (compa radas à história da espécie humana), elas têm estado conosco durante toda a nossa vida e têm um importante impacto na idéia, consciente ou inconsciente, explícita ou implícita, que fazemos do modo como deve mos viver nossas vidas. Suponha que alguém lhe diga que um trem supersônico esteja disponível para levá-lo da costa oriental dos Estados Unidos à costa ocidental à velocidade de 4.800 quilômetros por hora . Qual seria o efeito disso em sua vida profissional? E em sua vida social? Que tipo de modificações você começaria a fazer hoje se estivesse ra zoavelmente certo de que essa avançada tecnologia estaria disponível dentro dos próximos 3 a 5 anos? É exatamente nessa situação que nos encontramos como analistas de sistemas no restante deste século; a cada vez que somos brindados com tecnologia de processamento mais poderosa, nossa primeira reação (e a dos usuários finais, também) é reimplementar as aplicações já 573 existentes de uma forma um pouco mais eficiente, O desafio serã encor trar aplicações Inteiramente novas - usos inteiramente novos e rad: calmente d da tecnologia de computação - em relação a aplicações que são presentemente desenvolvidas. 25.3 CONCLUSÃO É importante que você tenha uma perspectiva voltada para o futun ao concluir este livro e começar a praticar análise estruturada no mund real. Embora a modelagem, a resolução iterativa de problemas, a subdi visão top-down e outras idéias discutidas neste livro serão quase segura mente válidas para um futuro visível, muitos detalhes (ex.: a tecnologi: disponível de apoio à análise estruturada e até outras técnicas como subdivisão de eventos) podem ser modificados ou substituidos. Você não deve supor que o que aprendeu neste livro seja imutável permanente e imune a modificações. Como toda ciência, e principalmen te como todos os outros aspectos da
ciência da computação, a área d análise de sistemas está destinada a continuar modificando-se, evoluind e (esperamos) aperfeiçoando-se durante o século vindouro e além. Pan alguns, é assustador perceber que metade do que se aprende ness área técnica estará obsoleto em 5 anos. Para outros, e espero que voc se inclua nesta categoria, isso é uma fonte de constante renovação entusiasmo. E com essa observação chegamos ao final deste livro. Você aindi não é um veterano analista de sistemas, mas deve possuir suficiente: ferramentas e técnicas para iniciar a profissão sem receio de fracassar Possa você desfrutar da prática da análise estruturada em sistemas d informações que irão beneficiar a sociedade. E que você retorne err menos de 5 anos para ver o que mudou. Tchau! REFERÊNCIAS 1. Tom deMarco, Structured Analysis and Systems Spec Englewood Cliffs, N.J.: PrenticeHall, 1979. 2. Chris Gane e Trish Sarson, Slnsctured Systems Analysis: Tools an Techniques. Englewood Cliffs, N.J.: Prentice-Hall, 1978. 3. Arthur C. Clarke, Proj’iles of the Future. Nova Jorque: Holt Rinehart, and Winston, 1984. 4. Jared Taylor, “Lighiyear’s Ahead of Paper”, PC Magazine, 16 & abril de 1985. 5. Frank Derfier, “Expert-Ease Makes JÉs Own Rules”, PC Magazine 16 de abril de 1985. 574 6. Robin Webster, «M. 1 Makes a Direct Hit”, PC Magazine, 16 de abril de 1985. 7. Robert E. Kelier, Expert System Technology: Development and Applicalion. Englewood Cliffs, N.J.: YOURDON Press, 1986. 8. Frank Rose, mb lhe Heart of lhe Mmd. Nova lorque: Harper & Row, 1985. 9. D. Barstow, «Artificial Intelligence and Software Engineering”, Proceedíngs of the 9th Intemational Conference on Software Engi neering. Washington, D.C.: IEEE Computer Society Press, março de 1987. 10. Paul Ward e Steve Melior, Structured Development of Real-Time Systems. Nova lorque: YOURDON Press, 1986. 11. Steve McMenamin e John Palmer, Essential Systems Analysis. Nova lorque: YOURDON Press, 1984. 12. Craig Brod, Technostress. Nova lorque: John Wiley, 1984. PERGUNTAS E EXERCÍCIOS 1. Quais são os três grandes estágios evolutivos da análise de sistemas ocorridos nos últimos 20 anos? 2. Quais são as cinco principais modificações ocorridas na área da análise de sistemas nos últimos 10 anos?
3. O que os termos lógico e físico significam no contexto deste capitulo? 4. O que é subdivisão de eventos? O que ela veio substituir na área da análise de sistemas? 5. Por que a modelagem física do sistema atual foi relegada na análise de sistemas? 6. Que ferramentas foram acrescentadas à área da análise de sistemas para auxiliar na modelagem de sistemas de tempo real? 7. O que é um diagrama de estrutura de dados? Como ele foi substi tuído na área de análise de sistemas? 8. Como os computadores estão começando a afetar as tarefas e ati vidades dos chefes mais graduados das organizações? 9. Por que o ensino da análise estruturada e do projeto estruturado às crianças nos anos vindouros terá impacto nos projetos de desen volvimento de sistemas? 10. . Por que a análise estruturada possivelmente será um fator de competição internacional entre os Estados Unidos, Europa e muitos países do Terceiro Mundo? 11. Projeto de Pesquisa: qual a percentagem de programadores e analistas de sistemas que dispõe de estações de trabalho com es tojo de ferramentas em suas organizações? 575 12.
Por que as ferramentas automatizadas são importantes para
análise dé sistemas? 13.
Por que os desastres de manutenção terão impacto na anális
estruturada no futuro? 14.
Que relações possivelmente haverá no futuro entre a inteligência
artificial e a análise estruturada? 15.
Por qual percentagem, ou múltiplo, espera-se que o hardware seja
aperfeiçoado nos próximos 10 a 15 anos? 16. Por que os contínuos aperfeiçoamentos do hardware terão impactc na forma como é feita a análise de sistemas? NOTAS 1
Três exemplos são John Reed, atual presidente da Citicop, Richard
Crandail, dirigente da American Airlines, e Frank Lautenberg, que foi presidente da ADP (empresa de serviços de pagamento de pes soal) e atualmente é um dos dois senadores por Nova Jersey. Existem também diversas pessoas que foram programadores e analistas de sistemas e que hoje são membros do Congresso.
2
Veja a discussão desse assunto em “The Computer Industry in
Japan’, de D. Tajima e T. Matsubara, Computer, Volume 14, n 5 (maio de 1981), pgs. 89-96. 3
Um grande volume de trabalho ainda é executado em hardware de
processamento especializado, com utilização de linguagens de programação especializadas, como Lisp e Prolog: Entretanto, (1) a maioria das empresas preferiria integrar suas aplicações de IA com as outras aplicações que executam em seu hardware de grande porte padrão IBM, (2) a maioria dos programadores preferiria utilizar linguagens conhecidas, como COBOL, do que linguagens esotéricas como Prolog e (3) as aplicações de IA orientadas para os negócios terão de obter informações por meio de “grampos” no banco de conhecimentos, que já existe no computador de 8rand porte. 4
Veja a descrição de quadros em IKelier, 19861.
5
Isso não é ficção científica. Planos sérios de engenharia para esse
trem supersônico foram preparados no MIT. 576 P. 1 4’ A FERRAMENTAS AUTOMATIZADAS O homem é um animal que utiliza ferramentas.... Sem ferramentas ele nada r€presenta, com elas ele é tudo. Thomas Carlyle, Sartor Resartus, Livro 1, Capítulo 4 A.1 OS ANTECEDENTES DAS FERRAMENTAS AUTOMATIZADAS Uma ferramenta automatizada pode ser definida como algo que substitui o trabalho manual do programador, do analista de sistemas, ou até do usuário final que precisa informar seus requisitos aos profissionais da computação. Desse modo, existem muitas coisas que podem ser consideradas como ferramentas: Linguagens de programação de alto nível, desde o COBOL e Pascal, até as atuais
linguagens de quarta geração que permitem aos programadores o uso de sentenças semelhantes à linguagem natural, de alto nível, que são automaticamente convertidas nas instruções primitivas, de baixo nível, que o computador compreende. .. Listagens de referências cruzadas, programas de impressão de relatórios, e outros programas utilitários que oferecem informa ções auxiliares e estáticas sobre seus programas. Ferramentas de testes e de depura ção, simuladores e con gêneres, que prestam informações ao programador sobre o 579 comportamento dinâmico de seu programa em tempo de e’ cu As ferramentas de testes auxiliam o programador a cri uma grande variedade de casos de teste para garantir que u programa seja bem testado. As ferramentas de depuração aj dam o programador a localizar erros depois de perceber qi algo está errado. Os simuladores oferecem uma representaç mais visual e gráfica da execuçàó do programa, por exempi apresentando o programa como um fluxograma na tela do t mina!, e simulando o comportamento do programa durante execução mostrando o fluxo de controle através do fluxograni Terminais de time-sharing (tempo compartilhado) que subs tuem os ambientes de desenvolvimento batch. Essa batalha travada e vencida há 15 anos na maioria das organizações software, mas é importante compreender que o terminal time-sharing é uma ferramenta. Nos anos 60 e no início dos an 70, os programadores tinham de escrever seus programa manualmente, em formulários adequados; os comandos do pr grama eram depois perfurados em cartões (lembra-se d cartões perfurados?) e, em seguida, alimentados no computad durante a noite. Se houvesse algum erro (se o programador vesse escrito um comando sintaticamente incorreto ou se operador da perfuradora tivesse errado alguma perfuração), s ria entregue um relatório de erros para o programador na m nhã seguinte. E o ciclo recomeçaria. Tudo isso desapareceu e meados da década de 70 na maioria das empresas atualmente, programador digita seu programa diretamente em um termin de time-sharing, concorrentemente com centenas de outros pr gramadores e/ou usuários finais. O programa pode ter sua cc reção sintática conferida de imediato, o mesmo acontecenc com os testes e com depuração. Hoje é difícil imaginar-se u ambiente diferente. Mas isso é devido em parte ao fato de terminais não-inteligentes poderem ser adquiridos por menos $500. Há dez anos o preço estava em torno dos $3.000 ou mai e ninguém tinha certeza de que um programador merecesse u investimento dessa envergadura. Computadores pessoais que possibilitam o desenvolvimento programas ojj-line. Hoje, o investimento de $3.000 é um comp tador pessoal. Os terminais não-inteligentes são bons, poré somente se o computador de grande porte ao qual eles est iam ligados pode proporcionar tempo de resposta rápido consistente para que os programadores possam trabalhar prodi tivamente. A maioria deles não pode; muitas vezes levam 580 segundos para reagir à mais trivial entrada, e 10 para entradas mais significativas. Uma alternativa atraente é um computador pessoal que o programador pode uti1izar para elaborar um pro grama, fazer as correções necessárias e revisões utilizando um programa
comum de processamento de palavras, compilar o programa para ver se há erros de sintaxe que o computador principal rejeitaria, e executar alguns limitados testes off-line. Pacotes de controle de código fonte que impedem que um pro-. gramador faça modificações não autorizadas nas versões oficiais de programas no meio da noite. Nos grandes projetos de pro gramação, uma das dificuldades é O gerenciamento da configu ração: assegurar a existência de total controle sobre os vários componentes do sistema final. Cada programador trabalha em sua própria tarefa e pode necessitar de dezenas de revisões daquela tarefa antes de completá-la. Mas a parte dele interage com outras partes semelhantes da responsabilidade de diversos outros programadores. A menos que todos saibam que versão de que parte deve ser considerada a versão oficial a anarquia será geral. Um pacote de controle de código fonte é como um bibliotecário automatizado: ele impede a retirada e a adulteração de documentos oficiais. • Análise de sistemas e bancadas de proj ei o. As ferramentas acima descritas referem-se principalmente à tarefa de escrever pro gramas (isto é, decidir quais comandos COBOL ou FORTRAN devem ser utilizados para resolver um bem definido problema). Mas não é aí que reside a maior dificuldade de se construir um sistema de software. O problema real está nos primeiros estágios da análise de sistemas (descobrir o que o sistema deve fazer) e de projeto (descobrir como deve ser a estrutura geral do sistema). Atualmente estamos começando a ver ferramentas que oferecem auxílio aos analistas de sistemas e projetistas de sistemas. A maioria das ferramentas acima descritas têm estado disponíveis nos últimos 10 a 15 anos e muitas são largamente utilizadas nas organiza ções de sistemas de informações gerenciais (SIG). As bancadas, por outro lado, são muito recentes e mal começam a aparecer na indústria de software de 1987. São es.sas ferramentas que, em minha opinião, têm a potencialidade de salvar a indústna amencana de software. Como pudemos ver neste livro, a análise de sistemas bem-sucedida é firmemente fundamentada nos modelos do sistema que deve ser computadorizado. As ferramentas de bancada do analista e do projetista 581 estão relacionadas principalmente com o desenvolvimento eficier desses modelos. Por exemplo, eles auxiliam o analista de sistemas construir diagramas gráficos que capacitam o usuário final a entender que o sistema fará para ele. As bancadas também auxiliam o analista e projetista a garantir que o modelo seja completo, acurado e consisteni de modo a que os erros descobertos no decorrer da fase de prograrr ção serão apenas erros de programação, e não um reflexo de um m: entendido permanente entre o usuário final e o analista de sistemas . para finalizar, as bancadas podem prestar auxilio ao programador i conversão do modelo em um programa atuante. Futuramente, presuni se que as bancadas automatizarão completamente esse processo. A indústria de software vem falando em ferramentas como essa 1 cinco anos ou mais; entretanto, não se fez muito a respeito. Isso se de’ em parte ao fato de a tecnologia de engenharia de software ainda não i permeado a indústria, porém isso é mais uma questão
econômica. Con afirmei, não foi antes dos meados dos anos 70 que a maioria das orgai zações de SIG aceitou a idéia de que cada programador deve ter u terminal nãointeligente em sua mesa, e passaram-se outros cinco an para que muitas empresas realmente adquirissem os terminais e destin2 sem um computador de grande porte em separado para a equipe desenvolvimento de sistemas (nesse ínterim, dois ou três programador muitas vezes tinham de compartilhar um terminal, de modo muito sem lhante a duas ou três pessoas compartilhando o mesmo telefone em u escritório e toda a equipe de desenvolvimento de sistemas tinha compartilhar o mainframe com centenas de usuários finais tentan executar trabalho útil em seus terminais). Nesse meio tempo, os computadores pessoais e as estações i teligentes começaram a aparecer no mercado consumidor. No final d anos 70 e início dos 80, a maioria dos programadores ignorava máquinas, por não serem muito poderosas, não pelos padrões mainframe pelos quais eles julgavam a capacidade de um computadc Uma estação inteligente de poder suficientemente alto, capaz de auxili o analista/projetista em seus modelos de engenharia de software custal entre $50.000 e $100.000 por volta de 19801981, o que deixava o a sunto fora de cogitações para a maioria das empresas de SIG. Apen umas poucas organizações com enormes projetos e imensos orçament4 poderiam considerar tal despesa; e o máximo que se podia esperar e uma estação inteligente para todo um departamento com centenas pessoas. Algumas das primeiras estações foram desenvolvidas em er presas aeroespaciais, contratadas da defesa e fabricantes de sofisticad estações gráficas de computadores, mas a comunidade estudiosa corrente principal de SIG desconhecia a idéia. Por volta de 1983, as coisas começaram a mudar. Poderos computadores pessoais, com gráficos de alta resolução e adequa 582 capacidade de memória, caíram abaixo da mágica barreira dos $1O.OOO Alguns eram estações inteligentes orientadas para a engenharia, construí das por novas e agressivas companhias de computadores, como a Apolio Computer e Sun Computer; alguns foram verdadeiros lampejos de luz como o computador Lisa da Apple. A maioria, contudo, revelou-se como configurações personaliza das do popularíssimo computador pessoal da IBM. Com sua arquitetura aberta, a IBM possibilitou a todos os interessados a construção de confi gurações de empregos especiais adequadas às suas necessidades. Dessa forma, a indústria de ferramentas de software pôde construir uma pode rosa estação inteligente composta pelo chassis de um PC-IBM, pela placa gráfica do fornecedor A, pela expansão de memória do fornecedor B e um monitor de vídeo de alta resolução do fornecedor C. A capacidade de construir uma poderosa estação de trabalho com a sigla IBM na parte frontal é de fundamental importância no mercado. A realidade é que nas empresas comerciais - bancos, empresas de segu ros, e as agências governamentais não-militares o computador pessoal deve ter a sigla IBM no painel frontal; isto, infelizmente, é mais importan te que a superioridade tecnológica do hardware. As empresas científicas e de engenharia não se preocupam tanto com o computador que utili zam (embora muitas preferissem que qualquer computador pessoal que comprassem fosse parecido com o
DEC VAX) e as empresas de defesa não se importam com o tipo de computador que usam, desde que seu custo possa ser incluído no contrato com o governo. Existem atualmente algumas empresas nos Estados Unidos e na Europa adquirindo produtos de software e estações de hardware para auxiliarem analistas e projetistas de sistemas. A tabela A.1 apresenta uma lista representativa dos fornecedores e dos produtos que estavam dis poníveis em 1987. Uma das forças impulsoras por trás deste quadro de empresas é a crença de que nos próximos 5 a 10 anos virtualmente todos os funcionários de colarinho branco dos Estados Unidos e especialmente todos os programadores, analistas de sistemas, projetistas de sistemas e os usuários finais de sistemas de processamento, terão um poderoso computador pessoal em suas mesas. O poder do hardware estará lá; agora tudo que precisamos fazer é ampliar esse poder com uns poucos recursos adicionais de hardware e alguns software muito poderosos. A maioria dos produtos funciona nos IBM PC, embora alguns for necedores tenham escolhido o Apple Macintosh ou os computadores mais poderosos Apollo ou VAX. Virtualmente todos os produtos ofere cem ao usuário um conjunto de ícones (formas que podem ser utilizadas na criação de desenhos) e um “mouse” para selecionar os ícones. Isso pode ser-lhe familiar se você já tiver utilizado programas gráficos como o MacPaint ou MacDraw no Macintosh ou o PC-Draw ou o EGA-Paint em IBM PC. Entretanto, os produtos de estaçõr3 de trabalho de analistas são 583 Tabela A.1: Fornecedores de Estações Inteligentes para Analista Fornecedor
Produto
AIMS Plus, Inc.
Aims Plus
1701 Directors Blvd. Austin, DC 75234 Cadre Technologies Inc.
Teamwork S/A
222 Richmond Sreet Providence, RI 02903 Cap Gemini Software !vlulti Pro 2350 VaIley View, #420 Dailas, DC 75234 CGI Systems Inc.
Pacbase
One Blue Hill Plaza P.O. Box 1645 Peari River, NY 10965 Computer Corp. ofAmerica PC/Workshop Four Cambridge Center
Cambridge, MA 02142 Cortex Corp. CorVision 128 Roberts Road Waltham, MA 02154 DBMS, Inc.
Developer Workstauon
1717 Park Street Napervilie, IL 60540 Iconix Software Engineering, Inc. Iconix 1037 Third Street, Suite 105 Santa Monica, CA 90403 Index Technology
Excelerator
101 Main Street Cambridge, MA 02142 Ken Orr & AssociatesThe Design Machine 1725 Gage Blvd. Topeka, KS 66604 584 Knowledgeware
Information Engineering
3340 Peachtree Road NE
Workbench
Atlanta, GA 30326 Meta Systems Structured Architect 315 E.Eisenhower Parkway Suite 200 Ann Arbor, MI 48104 Nastec Corp. DesignAid 24681 Northeastern Highway Sothfield, MI 48075 Promod Inc. Promod 22981 Alcade Drive Laguna Hilis, CA 92653 StarSys, Inc. MacBubbles 11113 Nortee Drive Silver Spring, MD 20902-3619
Tektronix
CASE
P.O. Box 500, Station Y3-314 Beaverton, OR 97077 Yourdon Inc. Analist/Designer Toolkit 1501 Broadway New York, NY 10036 em número muito maior; eles abrangem o recurso de desenhos. E, como veremos a seguir, eles dispõem de muitos recursos não encontrados em simples programas de desenho. A.2 RECURSOS IMPORTANTES EM FERRAMENTAS AUTOMATIZADAS É fácil pensar em bancadas automatizadas para analistas e projetis tas de sistemas como nada mais que produtos para desenhar eletronica mente. Certamente é verdadeiro que a capacidade gráfica desses produ tos é a parte mais visível e mais “sexy”, porém é apenas um de seus importantes recursos. As bancadas devem oferecer os seguintes recursos para que sua utilização seja significativa no desenvolvimento de um sis tema complexo: 585 • Suporte gráfico para múltiplos tipos de modelos • Recursos de verificação de erros para garantir a correção dc modelos • Referências-cruzadas dos diferentes modelos • Suporte adicional de engenharia de software A. 2.1 Suporte Gráfico Como temos visto neste livro, os modelos da análise estruturad apóiam-se em diversos tipos de informações: texto, dicionários de dado e diagramas gráficos. Os textos e os dicionários de dados podem ser au tomatizados com utilização de processadores de palavras e computadc res de grande porte convencionais; o que sempre faltou foi o suport gráfico. O analista de sistemas precisa de uma estação inteligente de tra balho que o permita compor, revisar e armazenar os seguintes tipos d diagramas: • Diagramas de fluxo de dados (DFD) • Diagramas estruturais (DE) • Fluxogramas (FG) • Diagramas de entidades-relacionamentos (DER) • Diagramas de transições de estado (DTE) Desse modo, uma bancada de analista deve possibilitar a compo sição do DFD mostrado na figura Ai(a). A tela que o analista contempla ao compor um diagrama desse tipc é mostrada na figura A.i(b).
Devo dizer que compus esse diagrama utilizando um simples pro grama de desenho chamado MacDraw em um computador Apple Macintosh, que estou usando para escrever este livro Levei 15 minuro para compor o diagrama e mais 30 segundos para copiá-lo diretamente no texto deste capítulo. Eu poderia ter desenhado o diagrama manual mente em 3 minutos, colando-o no capítulo com tesoura e fita gomada em cerca de 3 minutos. A vantagem do suporte gráfico evidentemente não provém do desenho inicial do diagrama, e sim da facilidade da modificações. 586 : Figura A.1 (b): Uma típica tela de uma estação de trabalho de analista 587 Figura A.1 (a): Um DFD típico Figure U.1( _____ Relatório de !defaturas Em um típico projeto de desenvolvimento de sistemas, um di grama como o da figura A. 1 pode ser modificado uma dúzia de vezes. N realidade, um analista de sistemas da Tektronix disse-me que ele e usuário final tinham modificado um DFI) como o da figura A. 1 mais cem vezes até que finalmente concordassem que ele finalmente era ur modelo correto dos requisitos do usuário Ninguém em sã consciênci deve pretender redesenhar manualmente um diagrama cem veze entretanto a introdução de uma pequena mudança em um diagrama n tela de um computador costuma levar cerca de apenas um minutc Alguns resultados iniciais do Hartford Insurance Group, que tem mais d 600 estações de trabalho instaladas, apontaram uma melhora da prc dutividade em torno de 40% devida unicamente ao apoio gráfic automatizado (veja ECrawford, 19851). Também quero ressaltar que os programas gráficos de empreg geral como o MacDraw ou o MacPaint (no Macintosh) ou o PC Draw oi EGAPaint (no IBM PC) não são de fato adequados ao engenheiro d software. Para construirmos modelos formais de engenharia de software devemos primeiro decidir que ícones, ou simbolos gráficos, serão em pregados. Em seguida devemos definir regras que definam as proprieda des dos ícones e as conexões válidas entre esses ícones. A figura AI, p0 exemplo, utiliza os quatro ícones associados a um DFD padrão: o círcu lo, o retângulo, a notação para depósito de dados e uma linha represen tando o fluxo de dados entre um lugar e outro. O MacDraw, todavia permitiu-me a inclusão de triângulos, hexágonos e qualquer outra repre sentação gráfica no diagrama. E o MacDraw não sabe que quando un fluxo de dados é interligado a uma bolha os dois objetos devem, daí en diante, ser tratados como um grupo ou um objeto composto Em un nível mais simples, tive dificuldades em criar bolhas (círculos) de tama nho uniforme, e levei uma eternidade para colocar ponta de setas na extremidades das linhas. A.2.2 Recursos de Verificação de Erros Embora o suporte gráfico seja indubitavelmente necessário, ele d modo algum justifica por si só o dispêndio de $10.000 em uma estaçãc de trabalho. Uma bancada de analista deve examinar o modelo criad pelo analista ou pelo projetista de sistemas para garantir
que esteja completo e internamente consistente. A figura A.1, por exemplo, deveri ser analisada do seguinte modo: • Todos os ícones estão interligados? Existe algum depósito di dados ou bolha de processo flutuando livres pelo diagrama, serr entradas e saídas? 588 • Todas as bolhas de processo têm pelo menos uma saída? Se não, ela é um possível buraco negro que devora os dados mas não produz qualquer saída. • Todos os fluxos dc dados (as linhas com nomes que interligam os quadros e bolhas) têm nome? Todos os nomes constam no dicionário de dados? • Todos os processos (as bolhas) têm nomes únicos (exclusivos)? Podem ser feitas veriíicações de erros análogas nos DE, FG, DER e DTE. E essa verificação pode ser estendida a diferentes níveis de mode lagem. A figura Ai, por exemplo, poderia ser um subsistema de baixo nível representado por uma única bolha (bolha número 1) em um siste ma de contabilidade de nível mais elevado modelado na figura A.2. A bancada do analista deve garantir qua as entradas e saídas mos tradas na figura A.1 correspondam às da bolha 1 da figura A.2. Se não houver essa correspondência o modelo estará inconsistente e será um inferno algumas semanas (ou meses) mais tarde quando alguém tentar declaraçóes Figura A.2: Um DFD de nível mais elevado 589 o de de -as converter o modelo gráfico em COBOL. O mesmo tipo de bala ceamento (equilíbrio) pode ser aplicado a diversos outros modelos qi compõem uma visão top-down de um sistema. A.2.3 Verificação Cruzada de Diferentes Modelos O recurso mais importante de uma bancada de trabalho de anali ta/projetista é sua aptidão em efetuar verificações cruzadas da consi tência dos vários tipos diferentes de modelos de um sistema. Existe dois aspectos: verificação cruzada de modelos em uma fase do projeto verificação cruzada de modelos em diferentes fases do projeto. Na fase de análise de um projeto, por exemplo, o principal objetis é determinar o que o usuário deseja do sistema, com pouca ou nenhurr referência à específica tecnologia de processamento que será utiliza para implementar os requisitos. Para isso, precisamos dos
DFD para re saltar a divisão dos requisitos em funções separadas e a interface enti as funções. Precisamos dos DER para ressaltar os objetos de dados arm: zenados no sistema e os relacionamentos entre esses objetos. E precis. mos de DTE para ressaltar os estados em que o sistema pode se encoi trar e o comportamento tempodependente desse sistema. Além dissi utilizamos um dicionário de dados para manter a definição de todos elementos de dados do sistema e alguma forma de descrição textual pa definir a orientação formal da empresa para cada função de nível ma baixo do sistema. O ponto principal é que todos esses modelos devem ser conslstei tes entre si. Se o DFD referir-se a um elemento de dados que não este presente no dicionário de dados, algo está errado; se o dicionário d dados definir elementos de dados que não apareçam em qualquer outi modelo, algo está errado. Se o DFD exibir depósitos de dados que n estejam definidos no DER, existe uma inconsistência; e se o DER apn sentar objetos que não estejam definidos no dicionário de dados e n estejam presentes em um DFD, também existe uma inconsistência. Com discutimos no capítulo 14, toda essa verificação cruzada pode ser feii manualmente, mas, na melhor das hipóteses, é um processo entediante sujeito a erros. Meus diversos anos de experiência com engenharia d software em típicos ambientes de SIG permitem-me afirmar com algurr confiança (infelizmente) que essa atividade não deve ser feita manua mente, apesar das exortações dos gerentes de projeto e das melhor intenções dos técnicos. Além da verificação de consistência entre os modelos de uma fa do projeto, é importante comparar os modelos desenvolvidos em fas diferentes. Por exemplo, os modelos desenvolvidos durante a fase d análise devem ser comparados com os modelos desenvolvidos durani 590 a fase de projeto. A comparação deve demonstrar correspondência um- para-um entre eles: cada requisito descrito no modelo de análise (DFD, DER etc.) deve estar representado em algum ponto do modelo de proje to (DE etc.) e cada característica descrita no modelo de projeto deve corresponder a um requisito descrito em algum ponto do modelo de análise. O problema mais comum é, naturalmente, que um requisito no modelo de análise seja esquecido e não apareça em lugar algum do modelo de projeto. Isso ocorre com freqüência quando o modelo de análise de siste mas é elaborado por um grupo de pessoas e o modelo de projeto (e a codificação e os testes subseqüentes) o é por outro grupo. No caso mais extremo (que muitas vezes ocorre em projetos do governo), os dois grupos podem trabalhar em empresas diferentes. Em qualquer dos casos, os dois grupo muitas vezes representam diferentes interesses e pers pectivas, e podem não ter boas comunicações entre si em qualquer ní vel. Dessa forma, um requisito que a equipe de análise tenha conside rado como perfeitamente claro pode não ser compreensível para a equi pe de projeto. Há ocasiões em que o problema é exatamente o inverso do que vimos acima: a equipe de projeto decide introduzir características que nunca foram solicitadas pelo usuário nem documentadas no modelo da análise. Isso pode acontecer inocentemente, mas costuma ocorrer quan do alguém da equipe de projeto diz: «embora não tenham pedido, apos to que os usuários vão adorar este recurso”. Ou o veterano e levemente cínico projetista
comenta: «apesar de os usários não terem pedido o recurso X, eu sei, pela minha experiência, que vão pedi-lo na próxima semana. É mais fácil incluí-lo agora do que esperar que o peçam”. Não importa se esses motivos são ou não razoáveis. O importante é que o assunto seja discutido em lugar de permitir-se que o projetista tome uma decisão unilateral. Da mesma forma, o modelo de projeto deve ser comparado com os programas codificados. Como antes, deve haver uma correspondência de um-para-um entre os componentes do código (a implementação real dos modelos de análise e de projeto) e os componentes do modelo de projeto. A.3 A FUTURA TECNOLOGIA DAS FERRAMENTAS • AUTOMATIZADAS Muitos dos recursos acima descritos já existem nas bancadas de trabalho de analistas/projetistas à disposição no mercado. Alguns desses recursos estão implementados de uma forma um tanto primitiva, mas estão sendo aperfeiçoados quase que diariamente. Não obstante, todos 591 os produtos devem ser vistos como ferramentas de primeira geraçi eles representam apenas o início de uma série de desenvolvimentos qi ocorrerão nos próximos 5 ou 10 anos. O cronograma para a segunda e a terceira gerações de ferrament automatizadas de desenvolvimento é pouco nítido. Algumas delas d pendem dos recursos das empresas que as estão elaborando; outras d pendem do desenvolvimento continuado da tecnologia de hardware qi proporcionará crescente capacidade às estações pessoais de trabalho. muitas ainda dependem do problema da transferência de tecnologia. grandes empresas estão apenas começando a experimentar com un ou duas estações em meados dos anos 80 e decorrerão alguns anos a que a tecnologia de primeira geração permeie a indústria de dese volvimento de software. Entretanto, tenho esperanças de que se você visitar uma gran empresa profissional de SIG em 1995, descobrirá que cada program dor (se ainda houver programadores) e cada analista de sistemas e ca usuário final e cada gerente de projeto tem em sua mesa uma estaçi inteligente que é 10 a 100 vezes mais poderosa que as estações atuai Elas oferecerão os seguintes recursos: • Redes para utilização a nível de projetos • Suporte personalizado de metodologia de engenharia d software • Controle de documentos • Recursos para gerência de projetos • Métricas para estatísticas de produtividade e de software • Verificação antecipada de complexidade excessiva • Testes e simulações automatizados • Provas de correção assistidas por computador
• Geração de código (codificação de programas) • Suporte de IA de código reutílizável • ‘Quadros negros” para a equipe de projeto 592 A.3,1 Redes para Utilização a Nível de Projetos As ferramentas automatizadas são úteis mesmo em pequenos pro jetos de uma só pessoa; o mesmo vale para a engenharia de software. Porém o projeto pequeno tem a vantagem de o serviço poder ser refeito diversas vezes até ficar pronto, de modo que o uso de modelos e ferra mentas formais não tem conotação de urgência. As ferramentas automatizadas serão muito utilizadas nos grandes projetos de desenvolvimento de software multipessoas, multianos e de muitos milhões de dólares. Em projetos desse tipo existem alguns analis tas de sistemas (muitas vezes uma dezena ou mais), alguns usuários fi nais (muitas vezes em diferentes localizações geográficas) e alguns pro jetistas e programadores. Em ambientes assim, é importante que não somente o trabalho de cada analista de sistemas seja internamente con sistente, mas também o trabalho dos analistas A e B sejam consistentes entre si. Isso quer dizer que é necessário haver um nível de inteligência acima do nível do analista de sistemas ou programador. Embora haja muitas maneiras de se implentar isso, uma das arquiteturas mais atraen tes é mostrada na figura A.3. Muitos dos fornecedores listados na tabela A.1 estão diligenciando para oferecer esse tipo de rede, principalmente em minicomputadores Wang ou DEC VAX. O minicomputador a nível de projeto deve ter suficiente capacida de de memória e suficiente poder de processamento para executar a verificação de consistência em nível de projeto. Também deve dispor de suficiente capacidade para desempenhar funções adicionais. Deve pos sibilitar que os programadores possam ser diretamente interligados ao computador de grande porte da organização para a execução dos testes Estações remotas de trabalho Figura A.3: Uma bancada de anahsta/projetista a nível de projeto 593 e de outras tarefas de rotina. E é aí o lugar onde deve ser colocada inteligência associada a muitas das funções descritas a seguir. É evidente que a utilização de tal minicomputador, com sua capa dade de memória, canais de comunicação, e outras características, onerar o custo do suporte automatizado. Em dólares de 1985, o custo uma estação de trabalho de utilização exclusiva e adequadamente con gurada está entre $8.000 e $15.000; com o hardware e o software para minicomputador de nível de projeto, o preço pode facilmente dobn Trata-se de um preço bem pago, mas dificilmence será suportado por u orçamento de operação para um só ano de uma grande equipe de SIi custaria milhões de dólares para uma empresa com algumas centenas desenvolvedores de sistemas. Ele deverá ser reconhecido como parte um investimento de capital no esforço de tornar a equipe mais produti’ e mais profissional.
A.3.2 Suporte Personalizado de Metodologia de Engenharia de Software As ferramentas automatizadas costumam suportar uma específi forma de notação e de procedimentos de engenharia de software. ( diagramas deste apêndice, por exemplo, e os apresentados anteriormej te neste livro, usam a notação descrita em diversos livros da YOURDO Press. Surpresa! Mas diversos produtos CASE também suportam outr conhecidas metodologias de engenharia de software, como a notaçi Gane/Sarson e a Warnier/Orr. Diversas outras ferramentas automatizad de suporte atualmente disponíveis suportam mais de uma marca d metodologias de engenharia de software. Existe, contudo, algo bem mais importante que apenas suportar metodologia do fornecedor A ou do fornecedor B: a ferramenta autom tizada deve possibilitar uma metodologia personalizada. Uma organiz ção de SIG quase sempre percebe que qualquer das conhecidas met dologias de engenharia de software não apresenta uma adequada not ção ou um adequado conjunto de diretrizes para o tipo peculiar c sistema que está desenvolvendo. Para exemplificar, pode ser que organização de SIG queira utilizar triângulos para ressaltar as entradas saídas de marcianos e dos exploradores da Jornada nas Estrelas c Capitão Kirk (a maioria de nós não precisa se preocupar com tais entr das e saídas, porque jamais pensamos em exigir triângulos em nossa fe ramenta automatizada). E talvez a organização de SIG tenha resolvid publicar um edito pelo qual nenhum diagrama de fluxo de dados podei ter mais de 13 bolhas; uma outra empresa pode decidir que nenhui sistema deverá ter mais de três níveis de diagramas de fluxo de dados. assim por diante. 594 É claro que esse tipo de personalização deverá ser possível ou a ferramenta deixará gradualmente de ser utilizada à proporção que os analistas de sistemas descobrirem que ela não preenche suas necessida des. A maioria das ferramentas automatizadas atuais não dispõe desse recurso; virtualmente todos os produtos da segunda geração o possuirão ou desaparecerão do mercado. A.3.3 Controle de Documentos Como vimos, a análise estruturada apóia-se em diversos modelos gráficos formais, suportados por elementos textuais como dicionários de dados e especificações de processos; as estações inteligentes automati zam o desenvolvimento e a manutenção desses documentos. Entretanto, possibilitam algo mais: o controle dos documentos. Isso, embora possa aparentar ser direto, é um conceito radical na maioria das organizações de SIG. Muitas delas só recentemente começaram a controlar o código fonte produzido na fase de programação do projeto. Mas, assim como é desastroso permitir que um programador efetue “pequenas” modificações em um programa operativo no meio da noite, também é perigoso permitir que um analista de sistemas execute uma “ligeira” mudança em um DFD ou em um DER no meio da fase de análise de um projeto, a menos que a alteração tenha sido autorizada e aprovada. Para que esse recurso funcione, precisamos distinguir entre as bi bliotecas privativas que cada membro do projeto mantém em sua estação exclusiva e o arquivo do projeto mantido no minicomputador de nível de projeto mostrado na figura A.3. O que queremos
controlar é o arquivo do projeto. Uma vez que o analista ou o projetista tenha indicado que completou um modelo (ou um diagrama) e está pronto para submetê-lo ao arquivo do projeto, o analista deixa de ser o único proprietário do material. A.3.4 Gerência de Projetos O controle de documentos é um aspecto de outro recurso que pode ser provido por um minicomputador de nível de projeto: a gerên cia de projetos. O gerente de um projeto pode ter sua própria estação inteligente de trabalho e utilizar os recursos do minicomputador para coordenar e supervisionar as atividades da equipe do projeto. Com ade quado suporte de software, ele pode ter certeza de saber quando o analista A terminar o DFD em que estiver trabalhando; ele pode instruir o minicomputador a encaminhar o DFD ao analista B para revisão e 595 comentários, podendo, assim, atribuir outra tarefa ao analista A. 1 poderá empregar todo esse material para atualizar o cronograma e orçamento do projeto; e, tendo em vista que o minicomputador cons va o registro imparcial de quando o analista A começou e terminou s DFD, ele provavelmente terá uma entrada muito mais acurada e n tendenciosa para as atividades de escalonamento do projeto. O gerer do projeto pode utilizar as aptidões de mala eletrônica que quase ceji mente serão oferecidas pela arquitetura da figura A para comunicar- com sua equipe. Talvez seja dificil fazer uma estimativa grosseira valor desse recurso, mas a maioria das equipes de projetos descobri que não pode mais passar sem ele depois de tê-lo utilizado. A.3.5 Métricas para Estatísticas de Produtividade e de Software Como foi dito acima, o minicomputador de projeto pode cons var seu próprio registro das datas de início e término de cada tarefa desenvolvimento de um DFD, a revisão do DFD, o caminhamento pc DFD etc.) executada por um analista de sistemas, projetista ou progi mador, Dessa maneira, as medições da produtividade podem ser efetL das de modo quase invisível, que esperamos que possa reduzir o imp to do princípio da incerteza de Heiscnberg . Compare isso com o pro to de desenvolvimento de software de hoje em dia, em que os progi madores e analistas de sistemas gastam uma hora ou perto disso a ca semana registrando informações sobre como despenderam seu temç Existe uma mal disfarçada tendência para preencher o formulário maneira a fazê-lo parecer-se com o que o chefe deseja (os prograrr dores podem ser marotos e vigaristas, mas não estão totalmente d ligados da realidade!) Além disso, se o processo de registro tomar ur hora, então ele estará interferindo com o próprio trabalho; esta é a rr neira como os fïsicos nucleares referem-se ao princípio da incerteza Heisenberg. Quase todas as outras métricas de software que a equipe de proje decidir controlar podem ser executadas pelo minicomputador de ní de projeto. Assim, a equipe pode decidir que é importante saber quant DFD serão necessários para o sistema, ou quantos elementos de dad( ou quantas primitivas funcionais ou quantas revisões foram exigidas um DFD antes que ele fosse finalmente aceito pelo usuário. Essas inft mações poderão ser valiosas para futuros projetos, podendo também úteis para estimativas de tamanho e custo de projetos. 596 A.3.6 Verificação Antecipada da Complexidade Excessiva
Uma das métricas mais úteis a longo prazo é a da complexidade. Existem modelos matemáticos da complexidade de programas que po dem ser usados para predizer a dificuldade de testar e manter um progra ma Se os modelos matemáticos forem aplicados automaticamente a cada módulo ou a cada programa do sistema em desenvolvimento, os desenvolvedores e o gerente do projeto terão um aviso antecipado de partes potencialmente perigosas do sistema, possibilitando que sejam experimentadas construções alternativas. A.3.7 Testes e Simula ções Assistidos por Computador Como já mencionado neste apêndice, já existem pacotes de testes e animadores assistidos por computador que proporcionam ao programa dor a representação gráfica da execução de seu programa. Não existe motivo pelo qual esse recurso inteligente não possa ser introduzido na estação remota do minicomputador de nível de projeto. Na realidade, quase todas as ferramentas convencionais de suporte de programas relacionadas no início deste apêndice podem ser incorpo radas a bancadas automatizadas de trabalho. Quando as estações pes soais inteligentes tornarem-se mais poderosas, deverá ser possível que o programador acompanhe o processo de modelagem com a codificação (se não for possível gerá-la automaticamente), com a compilação e com os testes. Somente quando o programa estiver pronto é que o programa dor deverá carregálo no minicomputador de nível de projeto. A.3.8 Provas de Correção Assistidas por Computador Como discutimos no capítulo 23, a área de provas de correção assistidas por computador ainda não está desenvolvida a um grau em que programadores e analistas médios possam utilizá-las. Mas existe um Largo espectro entre a verificação informal de consistência e as provas formais de correção. Com as ferramentas automatizadas de suporte avançaremos gradualmente da verificação informal dc consistência, aproximando-nos das provas formais completas de correção. A obtenção jisso exigirá um nível de treinamento e sofisticação por parte dos pro ramadores mais elevado que o atual. Portanto, não se deve esperar a presença desse recurso na maioria das estações orientadas para as em presas dentro dos próximos 5 anos. 597 A. 3.9 Geração de Código Uma importante meta de muitos fabricantes de ferramentas é geração automatizada de código COBOL ou FORTRAN pelas bancad de trabalho. Dessa maneira, não seria preciso examinar-se o códig assim como hoje dificilmente alguém examina os Is e Os binários que hardware do computador realmente entende. Nesse contexto, estariam lidando com especificações computáveis, desenvolvidas pelo usuár final e pelo analista de sistemas. Talvez nunca sejamos capazes de conseguir isso para todos sistemas, nem sejamos capazes de insistir no necessário nível de espec ficações rigorosas e formais de todos os usuários finais. Porém, dando-: mais ênfase às atividades de análise e projeto, podemos facilmente r duzir a programação a uma simples atividade burocrática. Ainda que ni possamos automatizá-la
completamente, podemos fazer com que se executada pelos funcionários de nível júnior, em vez de ocupar os gr duados em Ciência da Computação que ganham $40.000 por ano. A.3.1O Suporte de IA de Código Reutilizável Ainda mais atraente que o conceito da geração automática de cóc go é o conceito de código reutilizável. Na imensa maioria dos projet( (orientados para o comércio e orientados para fins científicos e de engi nharia) a maior parte do software que pretendemos desenvolver já f feito antes. O novo sistema deste ano é, de fato, quase igual ao sisten do ano passado, e não muito diferente do anterior a este. E muitas d primitivas funcionais de baixo nível já foram programadas centenas c vezes antes e existem grátis como rotinas de bibliotecas oferecidas corr parte do sistema operacional do fornecedor. A única coisa que distingL o novo sistema deste ano como único é a exclusiva combinação d funções previamente implementadas ou alguns parâmetros que podei ser introduzidos no programa ao começar sua execução. Por exemplo, sistema de pagamento deste ano é basicamente o mesmo do ano pa sado, com a alteração de apenas algumas taxas. Isso indica que o analista de sistemas (e mais ainda o projetista c sistemas) não deve encarar cada novo projeto como uma grande expli ração científica mas como uma caç2da em busca de módulos de bibliot cas, sub-rotinas.e programa já ex..stentes, que possam ser interligadc para atender às necessidades do i.suário. É nesse aspecto que a inteligência artificial pode ser um ótim auxílio. Comparando as características de uma função identificada p analista de sistemas (ex.: número de entradas, natureza das saídas e ei pecificações das transformações ou as normas que descrevem como 598 entradas convertem-se em saídas etc.) com uma biblioteca de funções implementadas, um sistema especialista pode sugerir ao projetista diver sos potenciais candidatos a serem utilizados na implementação do siste ma. E ele pode interagir com o analista de sistemas para mostrar-lhe que com uma pequena modificação dos requisitos (isto é, com um ligeiro compromisso dos requisitos originais do usuário) uma função existente de biblioteca pode ser usada in situ. A.3. 11 Quadros Negros para a Equzje do Projeto Alguns dos principais pesquisadores do país (em laboratórios de pesquisa como o MCC, em Austin, Texas, por exemplo) acreditam que a melhora real da produtividade nos anos 90 virá dos efeitos sinergéticos de uma equipe de projeto ao invés de provir de um indivíduo; isso porque os grandes sistemas atuais não são construídos por indivíduos, mas por grupos de grupos de pessoas (muitas vezes em empresas dife rentes). A maioria dos conceitos descritos até agora refere-se à melhora da produtividade de um único funcionário, mas a inteligência do mmi computador de nível de projeto poderia ser utilizada para prover uma visão prática a nível de projeto de todo um sistema à proporção que ele toma forma e cresce. A idéia de um quadro negro de projeto está sendo implementada no MCC como parte do projeto Leonardo; ele deve apresentar resultados fascinantes pelo final da década. O grupo de pesquisa está realizando experiências com a idéia de um quadro negro para uso comum na forma de um vídeo com as dimensões de uma parede. Estão também investi
gando a idéia de usar as sensações de aroma e som, bem como as cores, para acrescentar novas dimensões aos modelos gráficos descritos neste livro. Se obtiver sucesso, o projeto Leonardo será a bancada automatiza da de trabalho de terceira ou quarta geração para os desenvolvedores de sistemas de meados da década de 90! A.4 CONCLUSÃO ‘Minha tendência e entusiasmo por este aspecto do desenvolvi mento de sistemas é evidente; não posso esconder e não tenho porque me desculpar. Eu realmente creio que ele representa o único mecanismo que nos pode auxiliar a alcançar e manter contato com as hordas de programadores pelos países do mundo que dispensarão a mágica indús tria que criamos nos Estados Unidos nos últimos 25 anos. Alguns dirão que essa tecnologia é muito cara, que nenhum pro gramador vale um investimento de $25.000. Talvez não, mas como os preços do hardware estão sempre caindo, os $25.000 de hoje serã $10.000 amanhã e $5.000 no ano seguinte. Parece-me uma grande ironi que um país que investe de $50.000 a $75.000 em equipamento par seus fazendeiros e operários negue uns poucos milhares de dólare para seus trabalhadores da informação. Essa relutância, essa negação en admitir que os investimentos possam ser necessários, é o último suspin da Revolução Industrial, o último alento do que Alvin Toffler denomino de «Segunda Onda”. Admito que uma atividade de software dominada pelas estaçõe automatizadas origine algumas perguntas relevantes: ela torna obsoleto os programadores? ela destruirá nossa criatividade? podemos suporta os custos? ela garante que obteremos melhorias substanciais em noss capacidade de produzir software de alta qualidade com maio produtividade? Nada existe de mágico nas ferramentas automatizadas de software qualquer pessoa com senso comum pode responder a essas perguntas As ferramentas automatizadas certamente não tornarão obsoletos o programadores a curto prazo nem tornarão obsoletos os programadore de manutenção pelos próximos 20 anos ou mais. Enquanto isso, seria bom desenfatizar a atividade da programação, que manterá a tendênci apresentada desde a invenção da primeira linguagem de alto nível err fins dos anos 50. Isso não ameaça o emprego de nenhum programador lembre-se que temos uma demanda de sete anos de trabalho de desen. volvimento de sistemas na maioria das organizações! As estações automatizadas destruirão a criatividade dos de senvolvedores de software? Bobagem! Tapeação! Os Sistemas CAD/CAI (computer-aided design) destroem a capacidade de um projetista e projetar um automóvel ou um avião esteticamente belo? Não/Cem vezes Não, não e não! Muito ao contrário. A disponibilidade de ferramenta automatizadas de suporte ajudam o programador e o analista de sistema a concentraremse na parte realmente criativa da tarefa e a despendereni menos tempo preocupando-se com os aspectos mundanos dela. Uma vez que a bancada de trabalho possibilite que o analista de sistemas gaste mais tempo inventando mais modelos dos requisitos do usuário, ela o tornará mais criativo. Podemos suportar o custo dessas estações de trabalho? A resposta simples é: não podemos suportar o custo de não utilizarmos essas esta ções! Com elas, teremos uma oportunidade de salvar a indústria america na de software; sem elas, não há esperanças.
Para os que desejarem algo mais prático, lembrem-se que o custo de uma sofisticada estação de trabalho, presumindo-se a inclusão do suporte do minicomputador de nível de projeto, está em torno dL $25.000 . Esse valor equivale aproxi madamente ao salário anual, em 1987, de um programador comum com um ou dois anos de experiência. Se incluirmos o custo extra (seguridade, 600 pensões de 100%), isso representará cerca de seis mese do custo de um programador. Como podemos facilmente justificar a amortização do custo do hardware e do software associado em 3 anos, o custo é aproxi madamente igual a 15% do custo anual de um programador. Em outras palavras, se ela aumentar a produtividade do programador em 15% em cada ano, ela se paga por si mesma. Porém, uma bancada automatizada de desenvolvimento de soft ware garante o aumento da produtividade por um fator de 10? Quem emite seriamente uma pergunta dessas ainda deve acreditar no coelhi nho da Páscoa. Ir à igreja todos os domingos garante que você irá para o céu? Estupidez, arrogância, preguiça, e outras fraquezas humanas sem pre tornarão possível o fracasso apesar das melhores ferramentas e su portes; não há como impedir essa possibilidade. Mas, se acreditarmos no poder dos sistemas de informações e dos suportes automatizados para a sociedade e para as empresas, devemos acreditar nele para a atividade que constrói sistemas para o resto da humanidade. Não deve ser sempre verdade que os filhos do sapateiro serão os últimos a usar sapatos. REFERÊNCIAS 1. Jack Crawford, palestra na Wang Computer Company, em 6 de maio de 1985. 2. James Martin, An Infor,nation Systems Man Englewood Cliffs, N.J.: Prentice-Hall, 1984. 3. Paul Ward e Steve Mellor, Structured Systems Development for Real-Time Systems, Volumes 1-3. Nova lorque: YOURDON Press, 1985. 4. Meilir Page-Jones, Tbe Practical Gulde to Structured Systems De sign, 2’ ed. Nova lorque: YOURDON Press, 1988. 5. Steve McMenamin e John Palmer, Essential Systems Analysis. Nova Torque: YOURDON Press,1984. 6. Paul Ward, Systems Development Without Pain. Nova lorque: YOURDON Press, 1984. 7. Brian Dickinson, Developing Structured Systems. Nova lorque: YOURDON Press, 1980. 8. Edward Yourdon, Managing the System L Cycle, 2. ed. Nova lorque: YOURDON Press, 1988. 9. Edward Yourdon e Larry Constantine, Structured Design. Engle wood Cliffs, N.J.: Prentice-Hall, 1979.
10. David King, Current Praclices in Software Englneering. Nova lor que: YOURDON Press, 1983. 601 11.
Tom DeMarco, Structured Analysis and System Specificatíoi-
Englewood Cliffs, N.J.: Prentice-Hall, 1979. 12.
Tom DeMarco, Concise Notes on Software Engineering. Nova lor
que: YOURDON Press, 1979. 13.
Chris Gane e Trish Sarson, Structured Systems Ana 1y and Desig
Nova lorque: Improved Systems Technologies, 1977. 14.
Ken Orr, Structured Systems Development. Nova Iorque
YOURDON Press, 1977. NOTAS Isso é importante porque sabemos que 50% dos erros de um proje to comum de desenvolvimento de sistemas, hoje, devem-se a mal entendidos entre o usuário final e o analista de sistemas; 75% d custo da remoção de erros de um sistema operativo são relativos erros originados na fase de análise de sistemas. 2
Segundo a opinião da maioria dos programadores, é mais ou me
nos como duas ou três pessoas compartilhando a mesma escova d dentes. 3
$10.000 é considerado mágico por ser o nível no qual são exigido
graus mais elevados de autorização para que se possa despende fundos incorporados. Um gerente de projeto pode muitas veze. observar os beneficios práticos de uma estação inteligente de eri genharia de software e apresentar estudos realistas de custo/bene ficio. Porém se a decisão envolver $20.000, ela subirá ao nível d um vice-presidente assistente que passou semanas tentando man ter-se acordado o tempo suficiente para fazer algo útil na empresa Agora ele pode organizar uma comissão, estabelecer padrões, pes quisar a indústria e endereçar memorandos a dezenas de outro igualmente sonolentos vice-presidentes assistentes. Enquanto tod essa tomada de decisão de alto nível está em andamento, o gerent de projeto encolhe os ombros, tenta esquecer que ele um dia sub
meteu a solicitação em primeiro lugar, e volta a utilizar suas técni cas da Idade da Pedra de construção de sistemas. Como você pod perceber, eu sou inteiramente objetivo e de forma alguma m exalto emocionalmente com este assunto. 4
A maioria dos desenvolvedores de software usa produtos CASE qu
podem ser processados em computadores IBM PC, mas os diagra mas deste livro não foram produzidos por esses produtos. Pan utilizá-los eu teria de enconirar um modo de mesclar os diagrama. com os arquivos de texto deste livro, que estou redigindo em un Macintosh. 602 5 Tratava-se, evidentemente, de um diagrama mais complicado que o da figura A.1. Na realidade, a maioria dos diagramas de fluxo de dados do mundo real é mais complexa; eles têm sete ou oito bo lhas, três ou quatro depósitos, doze ou mais fluxos de dados e alguns terminadores externos. 6 Na realidade, você pode dizer a MacDraw que certos objetos do desenho deveriam ser agrupados, de modo a que pudessem ser movimentados em conjunto; mas isso não garante que o resultado, após a movimentação, fosse o desejado. Alguns outros pacotes de desenho, como o Design, da Meta Software (55 Wheeler Street, Cambridge, MA 02138), são mais sofisticados no modo como ma nipulam objetos e conectores. Mas, qualquer que seja a sofisticação que o pacote de desenho apresente, isso não importa muito sem as regras de verificação de erros discutidas na seção A.1.2. 7 Embora o princípio da incerteza de Heisenberg seja habitualmente associado à área da fisica nuclear, ele também é aplicável aqui. O princípio afirma que não é possível medir um fenômeno sem se modificar o fenômeno. Se um trabalhador precisar despender 10% de seu tempo medindo seu próprio trabalho, sua produtividade re duz-se em pelo menos 10% - e o fato de ele saber que está sendo avaliado (face às medidas que ele próprio está fazendo) tende a modificar seu comportamento. 8 Como discutimos no capítulo 23, um dos modelos mais conhecidos é a medida de complexidade ciclomática de McCabe. Desejando mais detalhes sobre esse e outros modelos, veja Controlling Soft ware Profects de Tom DeMarco (Nova Jorque: YOURDON Press, 1982). 9 Programas simples de desenho estão disponíveis por menos de $100, e mesmo os programas mais sofisticados de desenho custam apenas algumas centenas de dólares. A mais barata estação inteli gente de trabalho para analistas, com os recursos descritos na se ção A.2, custa cerca de $895 em 1987; esses preços provavelmente cairão gradativamente nos próximos dois anos. Mesmo uma esta ção de
trabalho dispendiosa está custando em torno de apenas $8.000 em 1987. 603 B DIRETRIZES PARA ESTIMATIVAS B.1 INTRODUÇÃO Como analista de sistemas, você provavelmente será solicitado a produzir várias estimativas em relação a seu projeto. Na realidade, você pode ser o único responsável pela produção das estimativas em alguns casos; em outras situações, o gerente do projeto pode pedir-lhe que de senvolva algumas estimativas para seu uso. Que coisas precisam ser estimadas em um projeto de desenvolvi mento de sistemas? Isso depende do projeto, porém as principais coisas que normalmente precisam ser estimadas SÃO: • Recursos humanos. Quantos programadores, analistas de sis temas, projetistas de bancos de dados, peritos em telecomuni cações, representantes do usuário e outros tipos de pessoas se rão necessárias ao projeto? • Cronog ramas. Por quanto tempo o projeto se estenderá? Quanto tempo deverá ser gasto em cada uma das fases do projeto (ex.: análise, projeto, programação, testes etc.)? • Escalonamento do pessoal. Além de sabermos de quantas pes soas o projeto necessitará, precisamos saber quando essas pes soas serão necessárias. Se o projeto precisa de dez programa• dores, serão os dez necessários ao mesmo tempo? • Orçamento. Quanto custará o desenvolvimento do sistema? O principal custo será provavelmente o causado pelos salários pagos á equipe de desenvolvimento, e isso habitualmente pode ser calculado diretamente quando a equipe e o escalonamento dela já forem conhecidos. Mas, naturalmente, existem outros 605 custos associados a um projeto; esses custos são tratados deta lhadamente no apêndice C. Lembre-se de que você normalmente terá de fazer essas estimativa mais de uma vez. Geralmente é feito um conjunto de estimativas no estágios iniciais do projeto (durante o estudo de viabilidade, por exem plo), mas eles podem precisar ser feitos muitas vezes, quando os usuá rios e a direção examinarem as ramificações das diferentes barganhas Um exemplo evidente disso é a barganha entre tempo e funcionalidad (ex.: o gerente do projeto pode dizer ao usuário: ‘tenho certeza de qu poderemos entregar o sistema em 1° de janeiro, se você abandonar a funções X, Y e Z”); outro exemplo é a barganha entre tempo e pessoa (ex.: o usuário poderia dizer ao gerente do projeto: «se você dispusess de mais três programadores, conseguiria prontificar o sistema em tem p0?”. Pode haver algumas iterações até que a equipe de projeto, direção e a comunidade usuária atinjam
um compromisso aceitável B.2 OS RISCOS DAS ESTIMATIVAS Costumamos ter uma grande experiência na área das estimativas basta pensarmos em todas as situações originadas pela pergunta: “Quan to tempo você acha que levaremos até a casa de sua avó?”. E todo conhecemos intuitivamente o conceito de uma estimativa otimista e d uma pessimista. Mas estimar o projeto dc desenvolvimento de um siste ma é um tanto diferente, porque (1) a abrangência da tarefa é muit maior e mais complexa e (2) as conseqüências de um erro de estimativa costumam ser muito mais severas que as de chegarmos meia hora atrasa dos na casa de nossa avó 2• Existem diversos problemas aos quais vod deve estar atento antes de começar a estimar orçamentos, cronograma e requisitos de recursos: • A diferença entre estimar e negociar • A grande variação das habilidades técnicas • O perigo de estimar seu próprio trabalho • A falta de um banco de dados de estimativas • A insistência da direção por prematuras estimativas detalhadas • A dificuldade a nível industrial de medir-se a unidade di trabalho 606 • Estimativas fundamentadas em pressuposições de horas extras não remuneradas Dependendo de sua posição no projeto e de sua influência junto à direção e aos usuários, você pode conseguir evitar que alguns desses problemas venham a tornar-se sérios. Mas, ainda que você seja um ana lista júnior no projeto, deve conhecer os problemas das estimativas, pois, afinal de contas, são eles que determinam o sucesso ou o fracasso de seu projeto. Discutiremos em seguida cada um desses problemas detalhadamente. B.2.1 A D Entre Estimar e Negociar Geralmente há muitas negociações no início de um projeto (e muitas vezes durante a fase de desenvolvimento do projeto!). Isso é normal, porque a comunidade usuária muitas vezes tem pouco conheci mento do volume de trabalho que envolve um complexo sistema de informações e tende a “pedir a Lua”, isto é, uma imensa funcionalidade em um absurdamente reduzido espaço de tempo, e por pouco ou ne nhum dinheiro. Entrementes, o gerente do projeto vê-se frente a uma limitada equipe e um pequeno orçamento; portanto, ele precisa trabalhar com os usuários para ajudá-los a descobrir quais os arranjos possíveis. Porém esse processo de negociação, tão necessário e tão comum em projetos de desenvolvimento de sistemas, não deve ser confundido com as estimativas. O que se deve evitar é o entendimento entre o usuá rio e o analista (ou quem quer que faça as estimativas) em conversas deste tipo: Usuário: “Então, quanto tempo você levará para construir o sistema XYZ? Analista: “Bem, parece que ele estará pronto em l de abril”.
Usuário: “Não está bom, precisamos dele em 1 de janeiro”. sem a intenção de discutir outras barganhas entre funcionalidade e recur sos rsso às vezes é seguido por um apelo do usuário aos sentimentos de devoção, dever e patriotismo da equipe de projeto. Isso será discutido como um problema à parte na seção B.1.8. Em alguns casos, essa situação simplesmente reflete a falta de co nhecimento da parte do usuário; ela habitualmente pode ser corrigida com uma cuidadosa explicação das atividades de desenvolvimento de um sistema. Em outros casos, entretanto, ela reflete a abordagem geral 607 do usuário, seu “paradigma” de ação para lidar com pessoas e organiz ções que lhe fornecem produtos e serviços. Para o usuário típico, vo deve estar percebendo, a organização interna de processamento dados não é muito diferente de um fornecedor externo; a negociaçã na tentativa de baixar o preço ou reduzir os prazos em alguns meses, algo muito natural. E é razoável agir assim (do ponto de vista dei quando a pessoa ou a organização que fornece o serviço tem uma rn gem de lucro que pode ser reduzida mediante habilidosas negociaçõe Mesmo no caso de uma organização interna de processamento dados, a negociação (sem aceitar barganhas em funcionalidade, recu sos, orçamento ou prazos) pode ser razoável se as suas estimativas incli rem uma margem de erro (também conhecida por fator de contingênci que o usuário imagina ser excessivamente grande. Mas se você tiver feii estimativas cuidadosas e realistas, e o usuário propuser a redução pa uma equipe menor, um orçamento menor e prazos mais apertado então seu projeto terá adentrado o domínio dos altos interesses para quais as técnicas e ferramentas discutidas neste livro provavelmente ni serão de muita ajuda. Pode ter chegado o momento de acertar as su contas. B.2.2 A Grande Variação das Habilidades Técnicas É comum fazerem-se estimativas do trabalho a ser executado co base no talento médio (isto é, o típico programador ou analista c sistemas, que pode escrever 15 linhas de código, ou desenhar quati bolhas de DFD, em um dia médio). É importante ter-se em mente qu numerosos estudos feitos nos últimos 10 anos documentaram uma o dem de diferença de magnitude entre profissionais talentosos e mede cres na área . Se o seu projeto dispõe de um grupo dos assim chamadc superprogramadores, você poderá superestimar drasticamente o tempo dinheiro necessários para terminar o projeto. De importância maior é fato de que uma equipe composta por pessoal tecnicamente limitad pode fazer com que seu projeto não cumpra os prazos e ultrapasse orçamento de modo substancial. Um grande problema dessa área é que o desempenho real d pessoal experiente não se correlaciona fortemente com a maioria dc testes padronizados da capacidade de programar. Assim, você deve fur damentar suas estimativas na reputação ou na experiência de trabalh anterior de cada pessoa, podendo, também, partir do pressuposto d que todos no projeto estâo dentro da média. Como a maioria das empr sas não mantém registros cuidadosos e detalhados sobre a produtividad de cada pessoa em um ambiente de desenvolvimento de sistemas, se lhe-á muito difícil obter evidências documentadas em
que se poss 608 confiar. Tudo o que você tem a fazer é realizar seu próprio julgamento e modificar as estimativas, do modo mais adequado, durante o desenrolar do projeto. B.2.3 O Perigo de Fstimar seu Próprio Trabalho Um dos piores erros que você pode cometer é estimar seu próprio trabalho; é quase tão arriscado quanto utilizar a estimativa de uma só pessoa, uma vez que o julgamento dessa pessoa pode ser afetado por uma série de fatores. Se você avaliar seu próprio trabalho, provavelmente acabará viti mado por um dos seguintes mitos: • “Sou melhor que a maioria das pessoas aqui, e tenho certeza de que posso terminar o projeto muito mais cedo” É muito comum sobrestimarmos a capacidade de alguém. Ao avaliarmos a capa cidade de outra pessoa, tendemos a ser conservadores; ao esti marmos nossa própria capacidade, tendemos ao otimismo. • “Sei que o chefe precisa que este projeto seja feito muito rapida mente, e de fato quero ajudá-lo”. Na maioria dos casos, isso é um sentimento altruísta; é muito natural querer que seu chefe seja bem-sucedido. Mas isso pode nublar seu julgamento sobre o verdadeiro tempo necessário para terminar o projeto. Na pior das hipóteses, as estimativas otimistas são feitas como um esforço para impressionar seu superior (lembrese que ele está fazendo o mesmo para o superior dele, que está fazendo a mesma coisa para o chefe dele etc.) visando uma melhoria ou promoção. Se você souber o que está fazendo e for capaz de aceitar o risco, ótimo mas não se esqueça de que estará brin cando com fogo. • ‘Quero trabalhar duro para terminar este projeto no prazo” A intenção de trabalhar além da hora é elogiável, mas perigosa como já foi sugerido. Além disso, lembre-se de que a decisão de trabalhar longas horas é muitas vezes feita em um momento de • entusiasmo no início do projeto; seis meses mais tarde, pode não parecer uma idéia assim tão boa. • ‘já trabalhei em sistemas assim antes, este vai ser fácil’ Bem, talvez, se você, de fato, já trabalhou em um projeto exatamente como este, ou muito parecido. Entretanto, existe uma tendência no início de um projeto para enxergarmos similaridades com 609 projetos anteriores e presumirmos de forma otimista que ser mos capazes de prontificar o novo projeto com maior rapide; Você provavelmente descobrirá que o novo projeto é de fato ur tanto diferente, ao entrar nos detalhes; e provavelmente e quecerá todos os problemas encontrados no último projeto. Por esses motivos, é muito importante que as estimativas sejar feitas por alguém que não seja a pessoa responsável pelo trabalho. também altamente desejável que ninguém tenha um banco de dados d estimativas (discutido na seção B.1.4) ou um pacote de estimativas co putadorizadas (discutido na seção B.4) para obter estimativas de mais d uma pessoa. Obtenha avaliações provenientes de pelo menos três pe soas; isso proporcionar-lhe-á
estimativas do melhor caso e do pior casc juntamente com uma avaliação do caso intermediário. B.2.4 A Falta de um Banco de Dados de Estimativas Quando nos defrontamos com um novo projeto, gostaríamos d dispor de estatísticas sobre uma centena de projetos semelhantes par podermos produzir estimativas corretas. Algumas firmas de consultoria ‘software houses” estão capacitadas a fazer iSSO: quando solicitadas avaliar o tempo e o custo de, digamos, um sistema de controle de pedi dos, eles podem dizes: ‘Bem, este é quase igual ao sistema de control de pedidos 137 que construímos, portanto ele levará X homens/mês, dólares e Z pessoas”. Mesmo dentro de nossa própria organização é possível que tenhan sido desenvolvidos 137 sistemas de controle de pedidos nos últimos de ou vinte anos. Mas isso não significa necessariamente que será fácil es timar o orçamento ou o cronograma para o l sistema de controle d pedidos; se os registros não tiverem sido cuidadosamente conservado tudo o que você poderá utilizar serão boatos e rumores. Em uma or ganização de processamento de dados, que atua como um setor d serviços internos, sem ter de se preocupar com aspectos de lucros/per das ou com considerações de fluxo de caixa, não existe um incentiv real para conservar cuidadosamente esses registros. Algumas grandes organizações de processamento de dados estã começando a modificar essa atitude e estão iniciando o desenvolvimen to de grandes bancos de dados detalhados que podem ser empregado na geração de estimativas muito mais acuradas para futuros projetos Algumas firmas de consultoria que se estão especializando nessa áre desenvolveram bancos de dados de literalmente milhares de projetos esses bancos de dados costumam ser usados para fornecer parâmetro: aos modelos de estimativas computadorizadas discutidas na seção B.4. 610 Entrementes, existe uma grande probabilidade de que você se de fronte com a estimativa de algo único. Certamente que você deve procu rar outros projetos semelhantes em seu local de trabalho, mas lembre-se de que você poderá ver-se em uma situação análoga à do arquiteto a quem perguntaram em quanto tempo ele construiria uma casa subterrâ nea em um pântano. B.2.5 A Insistência da Direção por Estimativas Detalhadas Prematuras Como regra geral, é quase impossível produzir-se estimativas deta lhadas de custos, de tempo e de requisitos de recursos para um projeto antes de ter sido executado um considerável volume de trabalho detalha do de análise e de projeto do sistema. Afinal, como informar ao usuário quanto vai custar um sistema se você ainda não sabe o que ele deseja? Não obstante, muitas vezes há uma grande pressão dos usuários e da direção para que se apresente uma estimativa, que ambos presumem ser uma previsão exata e detalhada, em um estágio muito inicial do projeto. Por quê? Simplesmente porque eles precisam tomar uma decisão tipo sim/não em investir tempo, dinheiro e pessoal necessários à construção do sistema. A demanda por uma estimativa prematura é bastante compreen sível; a única coisa que não é realista é a pressuposição de que uma avaliação prematura pode ser detalhada ou
acurada. É muito mais ade quado oferecer-se à direção uma série de estimativas durante o projeto, sendo cada uma progressivamente mais detalhada e mais exata do que a anterior. Desse modo, se a equipe de projeto estiver desenvolvendo um sistema para uma aplicação, com a qual seus componentes estejam bastante familiarizados, pode ser produzida a seguinte série de estimativas: • Ao final do levantamento ou estudo de viabilidade: uma estima tiva que pode variar por mais ou menos 50%. Isto é, a equipe de projeto pode informar à direção que o sistema tomará um ano e custará $200.000, mais ou menos 50%. A direção deve, portanto, prever a possibilidade de o projeto levar 18 meses e custar $300.000. • Ao final da fase de análise: uma estimativa que pode variar em ± 25%. • Ao final da fase de projeto: uma estimativa revista que pode variar em ± 10%. 611 • Ao final da fase de programação (quando os testes ainda estã por serem feitos): uma estimativa final que não deve variar en mais de ± 5%. B.2.6 Uma D!ficuldade a Nível Industrial em Medir a Unidade de Trabalho Muitas indústrias têm meios padronizados de medir o volume d trabalho a ser feito em um projeto. Alguém que esteja construindo um casa, por exemplo, pode medir a tarefa em termos do número de tijolo a serem colocados ou o número de cômodos a serem construídos. Mas na área do desenvolvimento de sistemas ainda não existe um mod convencionado de medir-se a unidade do trabalho a ser feito. O método mais comum é medir-se o número de instruções d programa a serem escritas. Esse método também é conhecido como li nhas de código. Assim, em alguns projetos, podemos ver referências KLOC, que significa kilo lines of code (quilolinhas de código). Mas exis tem muitos problemas com as linhas de código como medida da unidad de trabalho. • Os comentários em um programa devem ser contados com linhas de código? • Devemos considerar somente o código entregue ao usuário, ot. também devemos contar o código escrito para testes, programa utilitários e outras atividades de suporte durante o projeto? (1 em uma escala maior, devemos contar as linhas associadas projetos cancelados na tentativa de medir a produtividade d empresa?) • E se o programador tiver escrito mais de uma instrução por li nha da listagem do programa? E as sentenças complexas qu ocupam mais de uma linha? • Ainda mais importante, como devemos considerar o fato de quc alguns programadores
usam mais linhas para escrever a mesma função que outros programadores? Como vimos na seção B.2.2 isso pode representar uma ordem de diferença de magnitude! Como afirmou Capers Jones em Programming Produclivítj (EJones,1985]) maneiras diferentes de medir a unidade de trabalho po dem distorcer de duas ordens de magnitude os resultados relatados d produtividade; talvez seja por isso que alguns programadores propalarr 612 “ ser 10 e até 100 vezes mais produtivos que seus colegas! Em face desses problemas, algumas organizações estão agora começando a utilizar pon tos de funções como unidade de trabalho; isso corresponde grosseira mente às bolhas atômicas do nível mais baixo de um DFD B.2.7 Estimativas Fundamentadas em Pressuposições de Horas Extras Não Remuneradas Como já dissemos, os usuários e os gerentes de projeto podem reagir aos conflitos de cronogramas sugerindo, implícita ou explicita mente, que a equipe de projeto trabalhe em horas extras, em fins de se mana, dispense os feriados e adie as férias. Isso normalmente vem acom panhado por apelos à lealdade, ao profissionalismo, dedicação, de voção, orgulho, honra e patriotismo dos participantes do projeto. Deixo a você decidir se a determinação de trabalhar horas extras é uma necessária demonstração de patriotismo. Em alguns estabelecimen tos isso pode ser verdadeiro: cada projeto pode ser organizado de tal modo que só será bem-sucedido se a equipe de projeto trabalhar regu larmente 80 horas por semana. Alguns projetos (como o projeto Apollo, da NASA, que pôs os primeiros homens na Lua no final da década de 60) podem ser tão estimulantes que todos ficarão mais do que satisfeitos em apresentarem-se para o necessário serviço extraordinário. E não é inco mum descobrir-se que um projeto que aparentava estar sob controle ultrapassou o prazo no último mês, obrigando a algumas semanas de dias prolongados e fins de semana de trabalho. Mas você deve lembrar-se que trabalhar é como correr: você pode correr à máxima velocidade por algumas dezenas de metros, mas não pode correr em uma maratona à máxima velocidade. Da mesma forma, você pode trabalhar 14 horas por dia durante algumas semanas, mas é irreal, na maioria dos casos, presumir que possa trabalhar 14 horas por dia em um projeto de três anos. Pessoas casadas, com filhos, ou Outros interesses, simplesmente se recusarão a continuar trabalhando nesse horário após poucos meses; se necessário, pedirão demissão e procura rão outro emprego. Pessoas jovens e solteiras podem estar mais decidi das a devotar todos os seus momentos de vigília (bem como seus so nhos) ao projeto, principalmente se perceberem que isso pode acelerar suas carreiras ou seu conhecimento profissional. Mesmo que os membros da equipe concordem em trabalhar 14 horas por dia, nada garante que o trabalho deles seja eficiente. Isso é principalmente válido no caso de o serviço extraordinário prolongar-se por um período de vários meses: as longas horas vespertinas são muitas vezes improdutivas, e pode-se notar que são cometidos mais erros
quan do os funcionários trabalham cansados e com suas mentes exauridas. B.3
DIRETRIZES PARA ESTIMATIVAS
Existem quatro importantes diretrizes a serem lembradas ao fazer mos estimativas do volume de trabalho a ser feito em um projeto d desenvolvimento de sistemas: • Faça as unidades de estimativa tão pequenas quanto possível. • Faça as unidades de trabalho tão independentes quant possível. • Leve em consideração o fator de comunicação. • Faça a distinção entre serviço novo e serviço aproveitado. Essas diretrizes serão discutidas a seguir. B.3.1 Faça as Unidades de Estimativa Tão Pequenas Quanto Possível Esta deveria ser uma sugestão evidente, mas ela não é tão observa da quanto você imagina; ela também tem algumas armadilhas, comc você poderá ver. Mas, em geral, é bem melhor estimar o orçamento e cronograma para uma unidade de trabalho de uma semana do que fazei estimativas em termos de ‘homem/milênio” . Grandes projetos têm gran de complexidade; se tentar estimar o volume de trabalho envolvido você quase certamente cometerá grandes erros. É muito mais sensat fundamentar as estimativas em pequenos volumes de trabalho Isso naturalmente implica em que todo o projeto seja fragmentad em pequenas unidades de trabalho, o que acontece naturalmente com resultado da análise, projeto e programação estruturados; infelizmente como vimos na seção B.1.5, você pode ser solicitado a preparar um detalhada estimativa dos requisitos de orçamento e de recursos antes di ocorrência da subdivisão detalhada do trabalho. Não existe uma soluçã mágica para este problema; tudo o que você pode fazer é tentar conven cer seus superiores e os usuários que uma estimativa detalhada e corre ta exige algum esforço inicial para identificar as unidades do trabalho ser feito. Mas qual deve ser o tamanho das unidades de trabalho? Alguma empresas medem o trabalho em unidades de um mês, o que parece sei muito grande - os projetos podem ficar seriamente fora de controle fl( intervalo de um mês. Talvez seja iis razoável medir o trabalho err unidades iguais a uma semana; como disse um veterano gerente & 614 projeto: “Nada útil pode ser feito em menos de uma semana». Entretanto, a unidade mais comum talvez seja o dia; ele se ajusta à perfeição ao modo como organizamos nossa vida profissional. Algumas organizações realmente medem seu trabalho em unidades de uma hora; embora de fato existam muitas atividades que tomam uma hora ou menos (ex.: definir um elemento de dados no dicionário de dados), essa unidade parece ser excessivamente pequena para ser utilizada. B.3.2 Faça as Unidades de Trabalho Tão Pequenas Quanto Possível
Um problema que tem prejudicado muitas estimativas é a intera ção, ou o acoplamento, entre dois fragmentos de trabalho. Se um sistema estiver dividido em muitas e muitas interações, o volume total de traba lho para desenvolver esse sistema será muito maior que a soma linear do trabalho de todos os fragmentos. Se for feita uma modificação no fragmento 13, por exemplo, essa modificação pode causar problemas no fragmento 14, e uma modificação no fragmento 14 pode resultar em modificações no fragmento 15, e assim por diante. Esse efeito de onda tem feito estragos em muitos projetos. A solução é dividir o sistema em fragmentos pequenos e indepen dentes que se acoplem apenas frouxamente com outros fragmentos. Isso requer um cuidadoso trabalho; esse aspecto foi discutido no capítulo 20 como a principal razão lógica para agruparmos as bolhas de baixo nível no modelo comportamental preliminar em agregados de nível mais elevado. A idéia de independência modular também é importante duran te a fase de projeto; isso foi discutido no capítulo 22. B.3.3 Leve em Consideração o Fator de Comunicação Mesmo em um projeto em que todos os módulos sejam indepen dentes entre si, as pessoas precisam falar umas com as outras. Se o projeto estiver sendo conduzido por uma só pessoa, então as únicas comunicações necessárias serão com o usuário (e talvez alguns entendi mentos com a direção). Porém um projeto típico tem muitos analistas de sistenías, projetistas, especialistas em bancos de dados e programadores; pior ainda, algumas dessas pessoas podem trabalhar em empresas dife rentes ou até falarem linguas diferentes. Assim sendo, suas estimativas devem incluir algum tempo para a comunicação entre todos os componentes do projeto. Essas comunica ções podem tomar a forma de reuniões, memorandos, conversas telefô nicas, e outras. Lembre-se que o volume de comunicações amplia-se à 615 proporção que cresce o tamanho da equipe do projeto: o número de vi; de comunicação entre os membros da equipe cresce com o fatonal d número de indivíduos. B.3.4 Faça a Distinção Entre Serviço Novo e Serviço Aproveitado Se tiver sorte, a equipe do projeto poderá fazer uso de serviç feitos para projetos anteriores; muitas vezes isso toma a forma de módi los em uma biblioteca comum de software . Entretanto, você não de pressupor que os módulos reutilizáveis estejam livres; será preciso ui certo trabalho para (1) encontrá-los, (2) examiná-los para ver se ek perfazem as funções desejadas e (3) conhecê-los melhor, para sab como utilizá-los. É mais apropriado estimar que os módulos aproveit; dos exigirão uma certa fração (talvez 25% ou talvez menos de 10%) d trabalho que seria necessário para desenvolver esses módulos desde princípio. B.4
FÓRMULAS PARA ESTIMATIVAS
Durante os últimos 20 anos, a indústria de desenvolvimento de si temas investiu um enorme volume de tempo e esforço no desenvolv mento de modelos, ou fórmulas, para ajudar a predizer o tempo a S despendido, os recursos e o custo de um sistema. Alguns desses modelc estão agora amplamente em uso; talvez o mais conhecido seja o model
COCOMO desenvolvido por Barry Boehm na TRW . Mas, como diz Tor DeMarco em Controlltng Software ProfecLs, Não existem modelos de custos transportáveis. Se você ficar espe rando que alguém em algum lugar desenvolva um conjunto de fór mulas que você possa utilizar para prever os custos de seu próprio negócio, você talvez fique esperando para sempre. Grande parte de nossa indústria concluiu, lepois de admitir este fato, que a mode lagem de custos era irrelevante. Eu considero essa conclusão errada. Se os modelos de custos desenvolvidos localmente puderem ser usados para melhorar a precisão do processo de avaliação de custos, e a melhora vale o custo do desenvolvimento dos modelos, então a idéia é viável. Contudo, é interessante examinarmos algumas das fórmulas usada em outras organizações; elas podem dar-nos um ponto dc partida para desenvolvimento de nossas próprias fórmulas. Algumas dessas fórmula 616 nvolvem até 40 fatores ou parâmetros; mas, como veremos, algumas nvolvem apenas um fator. B.4,1 Fórmulas para Estimar o Tempo de Trabalho Três fórmulas comuns para a estimativa do esforço (medido em pessoas/mês) são baseadas em linhas de código. Walston e Felix desen volveram um modelo na IBM (veja [ e Felix, 1977]), fundamenta do em cerca de sessenta projetos, que é expresso como E=5.2L 091 onde E é medido em pessoas/mês e L é medido em milhares de linhas de código. De forma semelhante, Bailey e Basii desenvolveram uma fórmula baseada em 19 projetos; ela é expressa como E=3.4+0.72’DL 117 mais ou menos 25% onde o esforço era também medido em pessoas/mês e DL significa mi lhares de linhas de código entregues; veja IBailey e Basili, 1983]. Para finalizar, o modelo COCOMO, de Barry Boehm, tem uma fórmula de esforço para três diferentes tipos de sistemas: sistemas orgâ nicos, sistemas sernidestacados e sistemas embutidos: E=2.4KDSI 105 (sistemas orgânicos) E=3.OKDSI 1.12 (sistemas semidestacados) E=3.6’KDSI 1.20 (sistemas embutidos) onde KDSI representa “kilo delivered source in&ructions” (quilo-instru ções-fonte entregues); veja maiores detalhes em [ 19811. B.4.2 Fórmulas para a Estimativa do Tempo
Após desenvolver uma estimativa do volume do trabalho a ser feito, você pode pensar que seja fácil estimar a extensão do tempo que o projeto exigirá. Afinal, se você tem um projeto estimado em 10 pessoas/ mês de trabalho, e há 5 pessoas disponíveis, ele deve levar 2 meses para ser completado. Mas, e se somente 2 pessoas estiverem disponíveis? O projeto levará 5 meses para ficar pronto? 617 De um modo geral, a nossa preocupação aqui é com a bargan tempo e pessoal. Muitos anos de dolorosa experiência ensinaram-n que a barganha não é simples: duplicar o número de pessoas em i. projeto não reduz necessariamente a duração do projeto pela metade.] realidade, Fred Brooks, o arquiteto do original sistema operacior OS/360, cunhou a frase: “O acréscimo de mais pessoas a um projeto software atrasado apenas o atrasa ainda mais”. Há dois motivos para is (1) a inclusão de mais pessoas aumenta as comunicações necessári entre os membros da equipe, o que reduz a produtividade e (2) algum tarefas do projeto são indivisíveis, só podendo serem feitas por ur pessoa e a inclusão de mais gente de nada adiantará. Embora seja uti idéia útil, ela não nos diz especificamente de quantas pessoas um proje necessitará e nem quanto tempo será com ele despendido. Essa ár também foi tema de pesquisa; Barry Boehm encontrou, por exempi que o tempo de desenvolvimento de um projeto pode ser expresso pe seguinte fórmula: T=2.5E 0.33 onde E é o esforço do projeto medido em pessoas/mês; veja os detalh em EBoehm, 1981], Também foram feitos estudos sobre “manpower loading” (lotaçi de capacidade humana) ótima para um projeto; as três fórmulas ma conhecidas fundamentam-se na obra de Norden, Putnam e Parr; ve [ 19631, [ e Fitzsimmons, 1979] e tParr, 1980]. Norden foi primeiro a descobrir que a equipe de um projeto obedece a uma cun semelhante à mostrada na figura B.1. O diagrama também é conhecido como a distribuição de Rayleig] com base na fórmula matemática da curva. Putnam apresentou uma fó mula que determina o número de pessoas necessárias ao projeto ei função do tempo. Pessoas(O=2K*a*t*exp( 2) onde K é o esforço total do projeto (expresso em pessoas/mês) e a é ur fator de aceleração que estabelece a subida inicial da curva (observe qu K representa a área total sob a curva). Um modelo alternativo foi desenvolvido por Parr lParr, 1980 embora a forma geral apresente alguma semelhança com a figura B.1, ei estima uma quantidade maior de pessoas nas fases iniciais do projeto. ( modelo de Parr é descrito pela seguinte fórmula: Pessoas(t)= 1/4sech 2 618 12 14 16 18 Tempo
Figura B.1: A alocação típica de pessoas em um projeto B.5 MODELOS DE ESTIMATIVA COMPUTADORIZADA A idéia de utilizar fórmulas com expoentes e secantes hiperbóli cas provavelmente não é muito atraente; você pode ter certeza de que a maioria dos analistas de sistemas veteranos há muito já esqueceu o que seja uma secante hiperbólica e não faz idéia de como calcular um ex poente! Mas não é preciso guardar de memória qualquer das fórmulas, e nem é necessário executar os cálculos manualmente. Existem disponí veis atualmente muitos pacotes de avaliação de projetos; a maioria fun dona em PC e muitos deles utilizam o modelo COCOMO de Boehm e o modelo de Putnam, acima descrito. Alguns também podem incorporar os diagramas PERT e GANTT discutidos no capítulo 16. Se estiver trabalhando em algo que não seja um sistema trivial, você definitivamente deve examinar esses pacotes. Eles não somente executam os cálculos para você, mas possibilitar-lhe-ão fazer simulações do tipo “e se” para verificar os efeitos da inclusão dc pessoas ao projeto ou d diminuição de pessoas face a doenças ou outras calamidades. REFERÊNCIAS 1. Tom DeMarco, Controllin Sof/ware /‘rojecls. Nova lorque: YOURDON Press, 1982. 619 2.
Barry Boehm, Software Engíneering Econornícs. Englewood Cl
Nj.: Prentice-Hall, 1981. 3.
Workshop on Quantítative Software Modeis for Relíability, Com
xíty, and Cost: An Assessment ofthe State ofthe Art. IEEE Cata No. TH0067-9. Nova lorque: Institute of Electrical and Electror Engineers, 1979. 4.
Victor Basili, Tutorial on Model and Metrics for Software Mana
ment and Engineering. Nova Lorque: Institute of Electrical Electronics Engineers, 1980. 5.
C.E. Waiston e C.P. Felix, «A Method of Programming Measu
ment and Estimation”, lBMSysteinsJournal, Volume 16, Númer4 (janeiro de 1977), pgs. 54-73. Reimpresso em Writings ofthe Re lution, Edward Yourdori (editor). Nova lorque: YOURDON Pre 1982, pgs. 389-408. 6.
j.W. Bailey e V.R. Basili, «A Meta-Model for Software Developm
and Resource Expenditures”, Proceedings of the 5th Internatioi Conference on Software Engineering. Nova lorque, Institute Electrical and Electronic Engineers, 1983.
7.
P.V.Norden, “Useful Tools for Project Management”, Operat
Re in Research and Development. Nova lorque: Wiley, 19 8.
Larry Putnam e A. Fitzsimmons, «Estimating Software Costs”, Da
mation, setembro de 1979, pgs. 89-98; outubro de 1979, pgs. r 178; novembro de 1979, pgs. 137-140. 9.
F.N.Parr, «An Alternative to the Rayleigh Curve Model for Softw
Development Effort”, IEEE Transactions on Software Engineer Volume SE-6, Número 3 (maio de 1980), pgs. 291- 296. 10.
T.Capers Jones, Programming Productivity. Nova Iorque: McGra
Hill, 1985. NOTAS 1
Lembre-se também que as estimativas quase certamente precisat
ser revistas durante o projeto à proporção que as circunstânc mudarem. Fatores externos (condições comerciais, novos comI tidores, fusões etc.) podem fazer com que o usuário mude s opinião sobre a funcionalidade requerida, sobre as despesas or mentárias ou sobre a data exigida de entrega. Fatores interr (mudanças na equipe, dificuldades inesperadas de implementaç etc.) também podem causar modificações nos orçamentos e cror gramas, habitualmente de modo substancial. 2
Algumas avós talvez discordem totalmente dessa suposição!
3
Existe um Outro elemento de barganha, mas dificilmente fala
sobre ele explicitamente: a qualidade. Muitos gerentes de proj 620 tentam operar milagres entregando toda a funcionalidade exigida dentro dos prazos impostos pelo usuário e com os recursos menos- que-ótimos oferecidos; mas o inevitável resultado é um sistema que tem mais erros e é menos manutenível do que seria se as coisas fossem diferentes. 4 Uma das primeiras indicaç disso foi um artigo intitulado “Ex ploratory Experimental Studies Concerning Online and Offline Programming Performance”, de H. Sackman, Wj. Ericksn e E.E. Grant na edição de janeiro de 1968 de Communtcations of the ACM O estudo mostrou uma variação de 26/1 entre os melhores e os piores programadores, que haviam recebido a mesma tarefa de programação. Essa variação entre bons e maus programadores foi observada diversas vezes duranie os últimos 20 anos. 5 Deus está olhando por sobre meu ombro e está dizendo: “Não, não é ótimo”. Talvez
você queira assumir o risco de não ser capaz de entregar o projeto no prazo e orçamento otimistas que você estiver prometendo, porém um fracasso fará mais do que prejudicar sua carreira. Fazer estimativas otimistas e irreais é antiético, antiprofis sional e intelectualmente desonesto, quando seu superior, seus usuários e toda a organização podem sofrer consideráveis perdas por sua incapacidade de entregar o que prometeu. 6 A expressão ponto de função foi apresentada por A.J. Albrecht para descrever isso; veja “Measuring Application Development Producti vity”, Proceedings of the Joint SI-IA RFJGUIDE Application Develop ment Symposium (Chicago: GUIDE International Corp., 1979). Tom deMarco utiliza a expressão “function bang” mais ou menos da mesma forma; veja seu livro, Controlling Software Profects (Nova Jorque: YOURDON Press, 1982) para maiores detalhes. Veja tam bém Programming Productivity, de Capers Jones (Nova lorque: McGraw- Hill, 1986), onde consta uma completa discussão das di ficuldades de medir a produtividade e os muitos fatores que a afetam. 7 Um homem/milênio é o mesmo que mil homens/ano de trabalho. Eu utilizo a palavra «homem” deliberadamente, porque estou con vencido que as mulheres são demasiadamente inteligentes para se deixarem induzir a fazer estimativas em unidades tão grandes e tão machistas! A expressão «homem/milênio” foi sugerida originalmen te por um cliente da minha firma, uma grande empresa de utilidade pública da Califórnia. 8 Mas também pode ser possível reutilizar partes de um projeto, partes de um modelo de requisitos de usuário ou até partes de um estudo de viabilidade. No passado, normalmente não se fazia isso porque o modelo de projeto, os modelos da análise e os estudos de viabilidade não eram bem documentados e nem se fazia sua 621 manutenção. Agora, com a proliferação dos produtos de estaçô inteligentes de análise do tipo discutido no apêndice A, isso e tornando-se mais prático. 9 Para uma discussão mais detalhada desse modelo veja Softwa Engtneertng Economics, de Barry Boehm (Englewood Cliffs, N, Prentice-Hall, 1981). 622 c CÁLCU DE CUSTO/BENEFÍCIO C.1 INTRODUÇÃO Este apêndice dedica-se às técnicas de cálculo do custo/beneficio, uma importante parte do esforço de analise de qualquer sistema. Seu objetivo é, naturalmente, demonstrar aos usuários do novo sistema, bem como a outros grupos de diretores da empresa, que os benefícios do novo sistema excedem os custos esperados. Como analista júnior você talvez não seja envolvido nesse esforço, ou talvez receba a tarefa de desenvolver o modelo de custo/beneficio para uma pequena parte do sistema
geral. Mesmo como analista de sistemas sênior a cargo de todo o projeto, você pode não participar dos cálculos de custo/benefício; eles podem ser feitos, por exemplo, por um independente grupo de finanças, em separado. Ou ele pode não ser executado! Muitos sistemas são desenvolvidos em algumas organizações simplesmente para satisfazer exigências governamentais obrigatórias (ex.: sistemas de relatórios para o “Equal Employment Opportunity Act” ou novos sistemas para lidar com as modificações da legislação sobre impostos). É claro que, mesmo nesses casos, quando não há benefícios a serem auferidos do sistema (exceto pelo fato de evitar sanções e ter autorização de permanecer no merca do!), normalmente a direção deseja saber qual será o custo do sistema; mas isso pode ser executado como parte das atividades de avaliação discuiidas no apêndice B. Existe um outro motivo pelo qual o estudo de custo/benefício pode não ser executado: o usuário talvez não o deseje. Assim como um consumidor pode não ser capaz de justificar um Cadillac, em termos de custo (ele talvez precisasse apenas de um pequeno Honda ou até de uma bicicleta), muitos usuários são incapazes de justificar, quanto ao custo, um novo sistema que tenham solicitado. Por vezes eles solicitam 623 um novo sistema pelos mesmos motivos que um consumidor adquire un carro dispendioso - para manter o nível em relação a seus pares ‘.En outros casos, o usuário pode achar que existe a legítima necessidade dc novo sistema, embora reconhecendo que todos os benefícios sâ intangíveis ou extremamente difíceis de quantificar; o usuário podc justificar a solicitação do novo sistema alegando uma “intuição d empresário” de que ele valerá o custo. Como analista de sistemas, não é da sua competência insístfr en que deva ser efetuado um cálculo de custo/beneficio; afinal de contas, sistema é do usuário, e se ele quiser construílo sem justificá-lo, é prerro gativa dele. Entretanto, é uma boa idéia descobrir se foi feito um cálcuk de custo/beneficio para o projeto e, caso afirmativo, se ele é razoável Se não existir esse estudo, ou se os benefícios forem muito vagos (ou s os custos foram subestimados de forma gritante), você deve compene trar-se de que o projeto é vulnerável. No pior dos casos, você perceberá que o usuário não está muitc: entusiasmado com o projeto, mas foi pressionado pela direção superior com base nos cálculos otimistas do gerente do projeto que realment deseja construir o sistema (porque vai melhorar sua carreira, porque ek acha que todos os usuários devem ser computadorizados, ou por cc outras razões). No melhor dos casos, o usuário autorizou o sistema e est muito entusiasmado com ele a despeito da falta de um cálculo raciona de custo/beneficio. Mas os usuários são volúveis: o sistema predileto di hoje pode tornar-se o sistema descartado de amanhã. E os usuários vão e vêm: o usuário que autorizou o projeto onterr pode ser substituído amanhã por um novo usuário que tem uma visãc muito diferente da conveniência do projeto. Desse modo, se não houve um estudo de custo/benefício (e for evidente que ninguém quer elab rá-lo), meu conselho é muito simples; mantenha seus assentamento atualizados, porque você poderá estar em busca de um novo empregc antes do projeto
terminar. Nas seções a seguir, examinaremos diversos aspectos dos cálculo de custo/benefício: • Análise de custos • Análise de benefícios • Como expressar a economia • Análise de riscos 624 C.2 ANÁUSE DE CUSTOS O objetivo desta atividade é, naturalmente, calcular antecipada mente todos os custos associados ao sistema - não somente o custo de construir o sistema, mas também o custo de sua Instalação, operação e manutenção, bem como os custos agregados. Discutiremos todos eles a seguir. C.2.1 O Custo da Construção do Sistema No apêndice B discutimos as técnicas para estimar a extensão do tempo necessário para construir um sistema e o número necessário de pessoas. Lembre-se que você não só precisa calcular o custo dos progra madores e dos analistas de sistemas, mas também o de todas as outras pessoas envolvidas no desenvolvimento do sistema: • Burocratas • Diretores • Membros da comunidade usuária • Consultores e programadores contratados • Possivelmente membros da auditoria, do controle de qualidade ou da equipe de operações Na maioria dos casos você poderá obter com a direção (ou com o departamento de contabilidade) o salário médio das categorias de pes soas incluídas em seu projeto; esse salário médio pode ser expresso em termos de custos horários, custos mensais ou anuais. Certifique-se de considerar o fator de encargos de sua empresa; isto é, você provavel mente terá de multiplicar cada salário por um fator de, digamos, 150% para cobrir os custos de seguros, beneficios, e diversos outros fatores agregados de encargos. Você também pode obter esses valores com a direç ou com o departamento de contabilidade. Lembre-se de que as pessoas que trabalham no projeto não estarão disponíveis 100% do tempo: algum tempo será necessariamente perdido face à inatividade, às férias, licenças e coisas semelhantes. Sua firma pode ter um fator padronizado para aplicar a esse tempo perdido: caso contrário, você pode admitir o valor mínimo de 10%; 20 a 25% não são tão irreais (é possível que isto já tenha sido considerado nas estimativas de recursos vista no apêndice B. Verifique esse detalhe para assegurar-se 625
de que o fator de tempo perdido não tenha sido deixado de lado e ne seja aplicado duplamente). Em muitos projetos você deve incluir também o custo do trem mento da equipe de desenvolvimento. Os componentes da equipe p dem precisar ser adestrados em novas metodologias de desenvolvimei to, novas linguagens de programação ou em diversos recursos de har ware e de software relativos ao fornecedor do equipamento que estiv sendo utilizado. Outro custo que deve ser levado em consideração é do tempo de máquina, terminais, estações de trabalho e ferramentas c desenvolvimento (editores, pacotes de testes etc.) que sejam necessárk ao desenvolvimento do sistema. Em alguns casos, os terminais e ferramentas de desenvolvimento podem já existir e seu projeto pode n incorrer em despesas adicionais; em virtualmente qualquer cas( portanto, o projeto deverá incluir os custos do tempo de máquina envo vido (observe que isso pode incluir os custos de memória em disco, custos de telecomunicações, e os custos relativos a papel, formulários Outros itens correlatos). Alguns projetos novos são desenvolvidos com pessoas novas, ist é, pessoas que não trabalhavam para a organização anteriormente a projeto e para as quais presumivelmente não existiam acomodações nc escritórios. Assim sendo, você talvez tenha de incluir custos de recrut; mento (despesas de transporte para os candidatos a empregos, taxas d recrutamento para as agências de empregos etc.), assim como despesa com pessoal relativas ao treinamento de adaptação inicial pelo qu devem passar todos os novos empregados. E pode ser necessário inclu o custo do espaço, mobiliário, telefones e outros equipamentos para novo pessoal. Em alguns projetos existem também custos de transporte de visit que precisam ser feitas a instalações remotas dos usuários que precisei ser entrevistados. Evidentemente, este não é um fator para um projet em que todos os usuários estejam localizados na mesma área geográfic da equipe de desenvolvimento; mas, nos projetos em que existem dive sos grupos de usuários em diferentes localizações (muitas vezes ei diferentes países), essa despesa pode ser importante. A propósito, a dir ção muitas vezes presumirá que todas as informações necessárias podei ser coletadas em uma viagem; nos projetos reais, muitas vezes são n cessárias diversas viagens para resolver dúvidas e mal-entendidos . Dessa forma, os custos do desenvolvimento de um sistema podei ser muitos e diferentes entre si. A lista a seguir resume a discussão acim ela pode não ser completa, mas cobre os itens mais importantes: • Salários e encargos relativos a todo o pessoal ligado ao projeti • Custos de treinamento 626 • Tempo de máquina e ferramentas de desenvolvimento para a equipe • Custos do recrutamento da nova equipe • Espaço e equipamento de escritório para a nova equipe • Despesas de transporte com visitas a usuários remotos
C.2.2 O Custo da Instalação do Sistema Em um projeto simples, pode ser suficiente telefonar ao usuário e informar que o desenvolvimento do sistema está terminado; você pode ser capaz de entregá-lo em um disquete, e deixar que ele o instale em seu próprio computador pessoal. Mas, no caso de sistemas grandes e complexos, o processo de instalação é muito mais do que isso, havendo muitos custos envolvidos. Entre eles estão: • Custos de treinamento de usuários • Custos de conversão de bancos de dados • Custos de instalação do fornecedor • Custos da aprovação legal • Custo do processamento paralelo • Custo da equipe de desenvolvimento durante a instalação Normalmente, toda a comunidade usuária precisará de algum trei namento para familiarizar-se com a utilização do sistema. Pode ser ne cessário um treinamento adicional para os usuários supervisores, poden do, ainda, ser necessário algum treinamento para a equipe de operações e para diversos outros grupos auxiliares. Observe que isso significa que também devemos incluir o custo do desenvolvimento dos cursos de treinamento do usuário, o custo dos manuais de treinamento ou da do cumentação dos cursos, bem como o custo dos recursos de treinarnento dos usuários (salas de aula etc.). Para terminar, não esqueça o custo do tempo do usuário durante o processo de treinamento; você pode ser solicitado a calcular este último em termos dos salários dos usuários, ou a ter de calculá-lo em termos do custo de substituição das pessoas que 627 estiverem desempenhando as tarefas dos usuários enquanto est estiverem sendo adestrados. Os custos de conversão de bancos de dados podem ser ignorad se você estiver instalando um novo sistema para o qual não existe prec cessor. Mas se esse novo sistema estiver substituindo um outro sisterr então quase certamente haverá um banco de dados que precise 5 adaptado para o novo sistema. Se o banco de dados já existente não computadorizado (isto é, pastas de arquivos repletas de pedaços papel), poderá haver um substancial custo relacionado à entrada dados; isto é, alguém (ou talvez um grande grupo de pessoas) provav mente terá de sentar-se a um terminal e introduzir todos os dados impc tantes no computador. Se os dados existentes já estiverem computado zados, poderá haver um custo um tanto menor envolvido na convers mecânica dos arquivos antigos para o novo formato Os custos de instalação do fornecedor não devem ser ignoradc principalmente se o sistema envolver novo hardware, novo equipamen de telecomunicações e/ou novo software. Os fornecedores geralmen dão uma boa estimativa dos custos de instalação, e você deve consegi. que eles apresentem cotações a custos fixos. Para alguns sistemas poderá haver um custo de licenças ou outr formas de aprovações de várias autoridades, locais, estaduais ou do g verno federal. Isso também pode incluir
testes ambientais dc emissõ de radiação proveniente das telas dos terminais utilizados pelos oper dores de entrada de dados do usuário. Se a aprovação legal for u procedimento simples, envolvendo apenas o preenchimento de formi lários, você poderá estimar os custos de modo bem acurado; se, invés, ela envolver um processo de testes não rigorosamente fixados, si estimativa será apenas aproximada. Os custos do processamento paralelo, se houver esse process mento, também deve ser incluído na avaliação dos custos de instalaçã Em muitos tipos de sistemas o usuário insistirá em que o sistema anti seja processado em paralelo com o novo por um certo período. Is. pode implicar na duplicação temporária da equipe usuária ou outn despesas relacionadas. Você deve informar-se (se possível, na especific ção do sistema) do período em que esse processamento em paralelo v perdurar; essa informação poderá ajudá-lo a desenvolver uma estimatii adequada. Tenha cuidado em não esquecer o custo da equipe de desenvc vimento envolvida na instalação. Normalmente, os programadores analistas de sistemas que estiveram envolvidos no desenvolvimento d projeto estarão fortemente envolvidos em sua instalação. Evidentementi além de seus salários (e possivelmente as horas extras) e encargos, VO( também deve considerar quaisquer despesas de transporte necessári; à instalação do sistema em uma localização remota do usuário. 628 Finalizando, lembre-se que a instalação de grandes sistemas não ocorre de uma só vez; um novo sistema bancário, por exemplo, pode ser instalado em uma agência de cada vez, durante um período de vários meses. Isso significa que, de um modo geral, o custo de instalação das primeiras ramificações (Ou áreas de usuários) serão mais caras do que as seguintes, porque a equipe de instalação irá adquirindo mais expe riência e (esperamos) qualquer problema inicial com o sistema será resolvido após as primeiras instalações. Por outro lado, se o processo de instalação prolongar-se por diversos meses (ou mesmo anos), você deve considerar a possibilidade da renovação da equipe: pessoas que adquiri ram experiência com a instalação do sistema e com o treinamento de grupos usuários podem cansar-se do processo e transferirem-se para um novo emprego em outro lugar. C.2.3 O Custo do Dinheiro O dinheiro necessário para desenvolver e instalar um sistema não dá em árvores; ele pode ser obtido pela empresa através de um emprés timo ou pode provir de suas atuais reservas. Dessa forma, existe um cus to relacionado à utilização do dinheiro. Dependendo de sua organiza ção, você pode ser solicitado a expressá-lo como sendo o custo do em préstimo feito ou em termos dos juros que o dinheiro poderia estar ren dendo se tivesse sido investido em lugar de ser utilizado em seu projeto. Essa é uma área em que você deve recorrer à orientação do depar tamento de contabilidade. Eles certamente terão uma diretriz padr para tratar desses assuntos, e é importante que seu projeto observe a mesma abordagem. C.2.4 Custos Operacionais Após haver instalado o sistema, haverá um custo para que o usuá rio possa continuar sua operação. Entretanto, isso também deve repre sentar uma área em que seu novo sistema economizará dinheiro, por quanto ele presumivelmente será mais barato que o atual
sistema de que o usu dispõe (a menos que você lhe tenha acrescentado um grande volume 4 funcionalidade). Os custos operacionais típicos São: • Custos de hardware e de suprimentos e equipamentos correlatos • Custos de software • Custos de pessoal 629 • Custos de manutenção • Custos dos recursos Hardware é empregado aqui em um sentido muito abrangent incluindo o custo dos equipamentos computacionais (presumindo- que eles ainda não tenham sido adquiridos em sua totalidade, mas ve também a seção C.2.6), equipamentos de telecomunicações, terminai estações inteligentes e suprimentos (papel, formulários, discos flexívei disk packs, fitas para impressoras etc.). Lembre-se de que alguns iter de hardware podem ser considerados como material consumível un vez que se desgastam com o uso e precisam ser substituídos. Isso mcli terminais, algumas impressoras e talvez outros tipos de materiais c hardware. Certifique-se de que os períodos futuros reflitam os custos d; substituições que forem necessárias. Custos de software, nesta discussão, significam os custos continu: dos de “leasing” de sistemas operacionais, pacotes de gerenciamento c bancos de dados e outros softwares de sistemas que sua empresa poc ter com um fornecedor de software. Custos de pessoal incluem a equipe de operações, o pessoal d suporte técnico, programadores de manutenção, e o custo dos usuárk diretamente envolvidos na operação diária do sistema. Como já foi disci tido, você provavelmente terá de expressar isso como um custo pai considerar seguros, beneficios e outros encargos. Custos de manutenção incluem o esperado custo mensal (o anual) da manutenção dos equipamentos computacionais; sua estimati neste aspecto deve incluir não somente o custo da manutenção prevei tiva oferecida pelo fornecedor, mas também qualquer custo complemei tar relativo aos reparos provocados pelas falhas dos equipamento Também devem ser incluídos os custos de manutenção do software dc fornecedores, se isto for aplicável; o contrato de manutenção oferecid pelos fornecedores costuma incluir um telefone especial para supoil técnico, bem como mudanças gratuitas (ou a preços reduzidos) pai novas versões de seus pacotes. Além disso, o custo de manutenção deve incluir uma estimativa d custo do reparo e do aperfeiçoamento do software aplicauvo, que pod ser um importante fator de custo, o que é evidenciado pelo fato de qu a maioria das organizações despe ide mais de 50% de seus orçamentc de processamento de dados em manutenção. Existem diversas maneir; de estimar os custos de manutenção do novo sistema: • Se o seu sistema for substituir um sistema antigo, você pode e timar que o novo sistema exigirá o mesmo volume de esforço d 630
manutenção. Esse esforço é bastante conservador, por implicar em que o sistema antigo tenha sido desenvolvido com utilização de técnicas de engenharia de software modernas e que o novo sistema não utilizará técnicas ainda mais modernas e mais efi cientes. Isso é improvável no caso de o sistema antigo ter já 10 ou 15 anos, mas pelo menos representa um tipo de estimativa de pior possibilidade. • Uma estimativa otimista pode fundamentar-se na economia esperada na manutenção do sistema atual. Muitas organiza ções descobriram, por exemplo, que seus custos de manuten ção reduziram-se por um fator de cinco ou mais em virtude da utilização cuidadosa da análise estruturada, do projeto estrutu rado e da programação estruturada Você deve examinar outros projetos semelhantes no âmbito de sua própria empresa para verificar se foram obtidas economias desse tipo; se assim for, pode ser razoável esperar economias semelhantes em seu projeto. Acautele-se, contudo, contra a tentação de mostrar substanciais reduções no pessoal com base na instalação de seu projeto; isso raramente ocorre, pelos motivos discutidos na seção C.3.1. • Caso não exista um sistema atual para ser usado em compa rações (ou se você quiser evitar estimativas excessivamente otimistas ou pessimistas), experimente determinar o custo médio de manutenção de sistemas semelhantes em sua organização. Ele provavelmente será baseado em alguma unidade normali zada (ex.: valor da manutenção por linha de código por ano ou valor da manutenção por ponto dc função por ano), mas as es timativas que você fez no apêndice B devem possibilitar que você efetue as adequadas estimativas de manutenção para o seu projeto. Um custo final que deve ser estimado quando calculamos o custo operacional do novo sistema é o das instalações físicas (a sala do compu tador e as comodidades de escritório para a equipe de operações, para o pess de manutenção do fornecedor e para a equipe usuária). Se o novo sistema for ser executado em um mainframe central já instalado, esses custos de comodidades podem já estar embutidos no custo geral do hardware acima discutido. Entretanto, se você estiver desenvolvendo um sistema totalmente novo que terá suas próprias comodidades de funcionamento, isso pode ser um custo importante. 631 C.2.5 O Custo das Falhas Existe ainda um outro custo a ser considerado: o custo das potei ciais falhas do novo sistema. É prático embutir esse custo na categor dos custos de funcionamento, mas isso tende a ocultar o que se tomai um aspecto de crescente importância dos sistemas de informações r futuro: a confiabilidade. Existem, como pode-se imaginar, diversas formas de falhas de ui sistema: em alguns casos, o sistema torna-se completamente indispon vel até que o erro seja corrigido, enquanto que em outros casos o si tema continua funcionando, porém uma ou mais de suas saidas est incorretas. Em alguns casos, algumas funções do sistema podem nã funcionar, e em outros casos, alguns usuários podem não consegu acesso ao sistema. Todas essas formas de falhas têm um custo associad custos de hardware, custos de software, custos do pessoal envolvido r correção do erro, possíveis custos legais se o sistema tiver provocad perdas financeiras ou alguma outra perda grave, e possivelmente perd de receita ou perda de clientes.
Como devemos estimar coisas assim? Seria ingenuidade ignori toda essa área, pois ainda não atingimos a capacidade de constru sistemas perfeitos; por outro lado, se você indagar a um dos program; dores ou a um dos analistas de sistemas do projeto quantas falhas elc calculam que existam no novo sistema, eles irão olhá-lo como se voc estivesse sofrendo de alguma nova forma de senilidade. A atitude mais responsável que você pode adotar é (1) examinar taxa de falhas do sistema atual, se você estiver construindo um nov sistema para substituir um já existente, e (2) examinar a taxa de falhas d todos os outros sistemas de sua organização 6• Após isso você poderá e tar capacitado a fazer algumas suposições razoáveis sobre a taxa de f lhas que pode ser esperada do novo sistema. Seu projeto talvez sej construído com substancialmente menos erros que o sistema atual, o até mesmo menos que o sistema médio de sua empresa; você deve, n verdade, empenhar-se em um aperfeiçoamento de no mínimo dez vez ou mais. Se não existirem estatísticas disponíveis sobre confiabilidade d software do sistema atual de sua empresa e nem uma base sobre a qu; possa ser feita uma estimativa para o novo sistema, você deve, pel menos, incluir este fato no documento da análise de riscos; veja maiorc informações na seção C.5. Se você estiver construindo um sistema grar de e complexo no qual uma falha teria conseqüências de longo alcanc potencialmente desastrosas, é profissionalmente inaceitável não exist um modelo de confiabilidade de software, a despeito do fato de qu a maioria das empresas atualmente não se preocupe com isso. Par 632 maiores informações nessa área, veja Software Reliabilily, de Glen Myers (Reading, Mass.: Addison-Wesley, 1979). C.2.6 Faça Distinção entre Custos de Capital e Custos de Despesas Alguns dos custos relativos ao novo sistema serão despendidos durante o ano em que ocorrem; isto é, sua organização reconhecerá esses custos na declaração de L&P (e nos pagamentos de impostos arqui vados no IRS) durante o ano de sua ocorrência. Outros custos são capi talizados, isto é, os custos são diluídos por um período de diversos anos. Embora isso não afete o custo total do sistema, a classificação de um custo como de despesa e não como de capital pode ter grande impacto na situação da empresa em relação aos impostos. De forma semelhante, a decisão de incluir alguns custos como relativos a compras em lugar de aluguéis pode ter significativo impacto no fluxo de caixa da empresa, ainda que o custo total permaneça o mesmo. Normalmente as aquisições de hardware são consideradas como despesas de capital, e o custo é distribuído por um período de 5 a 7 anos (dependendo das leis vigentes sobre impostos). O custo do desenvolvi mento de software pode ou não ser capitalizado. Custos de instalação e de operação são normalmente despendidos no período em que ocorrem, embora possa haver pequenas variações nessa área. Evidentemente, essa não é uma área em que você possa criar sua própria doutrina de contabilização. É importante descobrir que padrões financeiros são utilizados em sua empresa e segui-los de modo consistente. C.3 ANÁUSE DE BENEFÍCIOS
É bem mais dificil calcular os beneficios esperados de um novo sistema de informações do que calcular seus custos. Em alguns casos, como mencionado no início deste apêndice, pode ser impossível - ou porque o sistema seja mandatório ou porque o usuário decidiu que quer o sistema quaisquer que sejam os beneficios concretos que possam ser identificados. É a tentativa de calcular beneficios concretos que causa tantos problemas. Os usuários não costumam se deixar levar pelo entusiasmo com coisas como “melhor controle” ou “informações no momento apro priado” ou “melhores ambientes para tomadas de decisões”, mas se lhes for perguntado quanto pensam economizar ou qual o proveito que será obtido, eles provavelmente responderão vagamente: “Oh, muito, muito... 633 Tenho certeza que será ótimo!”. Na verdade, o novo sistema será 6h - mas palavras como ótimo não se ajustam muito bem a uma plani que mostra comparações numéricas de custos e benefícios. Dessa maneira, seu maior trabalho ao executar um cálculo de c to/beneficio será o de fazer com que os usuários estipulem benefi concretos que possam ser medidos e calculados de forma quantitati Caso você não seja capaz de fazer isso (o que acontece em mui projetos e com muitos analistas de sistemas), tente fazer com que analistas de sistemas comparem seu novo sistema com algum outro si ma com benefícios conhecidos. Desse modo, você pode dizer ao us rio: “Suponha que você tivesse de escolher entre o novo sistema so que estamos falando e o Sistema X. Qual deles você considera mais portante? Se só pudéssemos implementar um deles, qual você escol ria?” Presumindo que o Sistema X tenha alguns benefícios concreto ele associados, isso deve dar-lhe pelo menos um modo grosseiro determinar o valor aproximado do novo sistema. Nas próximas seç faremos a diferenciação entre os benefícios táticos e os benefícios esi tégicos oferecidos pelo novo sistema. Neste contexto, um beneficio co é o que permite que a organização continue executando a mes atividade comercial, mas a um custo mais baixo (ou com lucros maion um benefício estratégico é o que possibilita que a organização inicie tipo inteiramente novo de atividade ou inicie atividades em uma rn área ou com novos clientes. C.3.1 Beneficios Táticos Os benefícios táticos estão muitas vezes relacionados a reduçi do pessoal burocrata ou administrativo; embora isso não pareça mús para os ouvidos dos usuários burocratas, é sem dúvida um fato da vi Um novo sistema de informações pode possibilitar que uma função s executada com a metade do número de usuários e até menos que is Isso geralmente é motivado pelo fato de que os usuários estão presen mente executando cálculos ou registros de dados à mão, quando i poderia ser computadorizado; ou são forçados a executar as mesn atividades (ou registrar os mesmos dados) múltiplas vezes, quando i poderia ser feito pelo computador dc uma só vez; ou eles despend um tempo considerável na recuperação de dados, o que poderia ser fc rapidamente por um computador. Embora isso seja um evidente beneficio do novo sistema, cui em não superestimar o efeito. Em alguns casos, pode haver menos e nomia do que foi estimado; as leis e a
natureza paternal dos níveis termediários de chefia da organização usuária podem impedir q alguns daqueles usuários burocratas sejam despedidos. E, igualmei 634 importante, você deve compreender que os níveis mais graduados de direção estão cada vez menos impressionados pela economia de um ou dois funcionários; eles estão interessados em maiores e melhores benefïcios provenientes da introdução de um novo sistema. Uma forma de benefício tático ligeiramente mais interessante é a economia advinda da capacidade de processar as transações da empresa com maior rapidez. O tempo de retorno mais veloz (ou a capacidade de manipular mais transações por segundo) não somente proporciona a oportunidade de reduzir os custos com funcionários como conduz a um melhor fluxo de caixa para a organização (isto é, convertendo os pedi dos dos clientes em dinheiro mais rapidamente, acelerando o tempo de entrega dos pedidos etc.). O que se tem a fazer é quantificar e expressar isso em dinheiro. Mas, para exemplificar, considere o seguinte diálogo entre o analista de sistemas e o usuário: Analista: Quantos pedidos você processa por dia? Usuário: Bem, processamos 10.000 pedidos por dia. Mas, sempre há alguns atrasados de modo que, em média, um pe dido leva cerca de uma semana para ser processado e remetido. Analista: E a fatura é enviada para o cliente juntamente com seu pedido, certo? Assim, o cliente não tem que pagá-la antes de receber o pedido, não é? Usuário: Isso mesmo. Analista: Então, se pudermos reduzir o tempo de processamento de um pedido de cinco dias para apenas um, p0- deríamos receber o pagamento do cliente quatro dias mais cedo, em média. E se o pedido médio gira em torno de $1000 e nós processarmos 10.000 pedidos por dia, significa que estaremos lidando com cerca de $10 milhões ao dia. A posse de $10 milhões quatro dias mais cedo do que antes, para os pedidos de cada dia, valeria Um sistema novo também pode proporcionar economia em reta ção ao equipamento computacional; o sistema antigo pode estar sendo processado em um dispendioso computador de grande porte, enquanto o novo sistema é executado em um pequeno PC na mesa do usuário. Essa mudança não somente diminui os custos do hardware de proces samento, como também economiza dinheiro na área dos custos das 635 acomodações, dos operadores, e coisas semelhantes. E, se o novo s tema reduzir o volume de papéis e formulários impressos, isso també deverá refletir-se como economia. Assegure-se de que seus cálculos c tejam completos neste aspecto; lembre-se de que serão necessári menos armários para arquivamento de documentos, menores escritórir menos máquinas de escrever e, talvez, menos chamadas telefônicas e tre sua empresa e os clientes, e assim por diante.
Os custos de manutenção do novo sistema também devem propc cionar um beneficio, como vimos na seção anterior. As despesas manutenção do hardware devem reduzir-se (a menos que o novo sist ma seja processado no mesmo equipamento instalado na organização), os custos da manutenção de software serão presumivelmente menor que os do sistema atual. C.3.2 Beneficios Estratégicos do Novo Sistema Em muitos casos, os beneficios de um sistema que realmente tê interesse e importância são os estralégicas - não somente a oportunid de de economizar uns poucos funcionários ou algumas folhas de pap mas a capacidade de a organização fazer coisas que não seriam possíw com o sistema atual. Existem diversos exemplos de benefícios estratél cos em potencial: • Localizar ou atrair novos clientes que a organização, de out modo, não seria capaz de localizar. • Penetrar em novos mercados ou oferecer novos produtos qi não estavam disponíveis anteriormente. • Obter, reproduzir ou distribuir conhecimentos e habilidad que antes eram exclusivos de um ou dois funcionários empresa. Em uma economia tão competitiva como parece ser a nossa, u sistema de informações que possa atrair novos clientes ou que pos evitar a perda dos clientes atuais para os concorrentes é realmente vali so. Em alguns casos, isso pode ser possível porque o novo sistema ofer ce funções que não estavam disponíveis antes; em outros casos, pode s conseqüência da capacidade do sistema em identificar possíveis nov clientes que a empresa desconhecia anteriormente. Qualquer que seja situação, você deve tentar quantificar esse benefício em termos aumento de clientes ou do aumento da participação no mercado e, partir daí, em termos de receita e lucros. 636 Uma forma mais difícil de beneficio estratégico é a capacidade do novo sistema em fornecer informações não disponíveis anteriormente. O exemplo típico disso é a capacidade do sistema em identificar tendên cias e padrões (ex.: tendências de vendas por território ou por época ou a preferência dos clientes por diferentes produtos). Isso é possível em quase todos os sistemas automatizados que substituem um sistema ma nual; e normalmente existe a oportunidade para qualquer tipo de siste ma on-line ou de temporeal de apresentar essas tendências de uma forma mais oportuna do que seria possível com um sistema na modali dade batch. De modo análogo, um sistema com aptidões gráficas pode fornecer informações de uma forma mais eficiente do que um sistema atual que produz informações em formato tabular ou em relatórios numéricos. E um sistema elaborado com uma linguagem de programa ção de quarta geração e um moderno sistema de gerenciamento de banco de dados pode possibilitar a leitura de todo o banco de dados com essa finalidade. Uma forma relativamente nova de beneficio tornada possível pelos sistemas especialistas comerciais é o encapsulamento de conhecimentos que anteriormente eram exclusivos de uma ou duas pessoas. Esse conhe cimento é normalmente voltado para apreciações, diagnósticos ou ava liações, e o perito humano que possua essas aptidões é habitualmente
considerado um valioso bem para a empresa; dessa maneira, a capacida de do novo sistema em simular essas aptidões é um beneficio cujo valor deve poder ser calculado. À proporção que as técnicas de inteligência artificial continuarem a crescer, poderemos identificar como beneficio a capacidade do sistema em dfsseminar o conhecimento originalmente pertencente a somente um ou dois peritos humanos da empresa. Assim, um perito humano da empresa pode ter algumas normas de julgamento que ele utiliza para diagnosticar as prováveis causas das falhas de algum sistema mecânico (uma plataforma de extração de petróleo, por exemplo). Evidentemente, seria estrategicamente benéfico obter o conhecimento daquele perito hu mano e simulá-lo para utilização por outras pessoas; mas a capacidade de estender essa perícia e aumentar a aptidão de diagnosticar para lidar com falhas do sistema pode ser de uma ordem de grandeza mais valiosa. C.4 COMO EXPRESSAR OS CUSTOS E BENEFÍCIOS DO SISTEMA Se todas as despesas e todos os benefícios do sistema ocorressem de forma instantânea, seria relativamente simples representar o valor do sistema como sendo a diferença entre os benefícios e os custos. Porém, como já dissemos, os custos habitualmente ocorrem por um período de 637 anos; e ainda que uma despesa realmente aconteça em um determinad momento (a compra de um equipamento, por exemplo), as normas d contabilização da empresa podem desdobrá-la em um período de vário anos. Assim sendo, você talvez tenha de demonstrar os custos e os bene ficios do novo sistema proposto ao longo de um determinado período d tempo. Existem quatro métodos conhecidos para iSSO: • Fluxo de caixa • Retornos de investimentos (RDI) • Taxa interna de retorno (TIR) • Valor atual líquido (VAL) Examinaremos cada um deles a seguir. C.4.1 Flu Quer o seu sistema apresente ou não um eventual lucro (bene fícios que excedam os custos), a direção poderá querer saber quant precisará ser investido para que se possa esperar um fluxo de caix; positivo; evidentemente, eles estarão mais interessados nisso em relaçã aos grandes projetos do que em relação aos pequenos. Observe que fluxo de caixa do projeto pode ser inteiramente diferente da informaçã oficialmente divulgada como lucros e perdas da empresa. Por exemplo a equipe do projeto pode ser responsável por uma despesa de $100.00( em salários durante um esforço de um ano em desenvolvimento d sistemas; mas as leis dos impostos podem permitir que esse custo sej; depreciado (ou amortizado) por um período de, digamos, 5 anos. Assim a organização pode relatar custos dc apenas $20.000 em seus pagamen tos de impostos do ano, mas os $100.000 em dinheiro já se foram. D forma semelhante, os benefícios do novo sistema podem parecer to talmente diferentes do ponto de vista de fluxo dc caixa em relação a
ponto de vista dos lucros e perdas informados ao Internal Revenw Service. Na maioria dos casos, é conveniente apresentar tantu o fluxo d caixa anual çomo o agregado. Sua análise de custo/benefício pode pro duzir, para a direção, uma tabela como esta: 638 Projeções Projeto X Fluxo dc Caixa Ano 1 Ano 2 Ano 3 Ano 4 TOTAL Economias de Caixa O 10.000 50.000 100.000 160.000 Despesas de Caixa 50.000 30.000 20.000 10.000 110.000 Caixa Líquida -50.000 -20.000 30.000 90.000 50.000 Caixa Agregada -50.000
-70.000 -40.000 50.000 50.000 C.4.2 Retornos de Investimentos Outra maneira de avaliar os custos e benefícios do sistema é calcu lar o retorno de investimento. Suponha, por exemplo, que você tenha investido $110.000 em ações ou em imóveis e que possa revendê-los por $160.000 (observe que são os mesmos valores usados no exemplo do fluxo de caixa). Isso significaria que você lucrou $50.000 em um investi mento de $110.000; em termos perccntuais, isso representaria um retor no de investimento de 45%. Isso soa melhor do que investir cm poupança! Mas, espere; no exemplo acima, o lucro não ocorreu ao final do primeiro ano; na verda de, levou 4 anos. Assim, isso faz com que o retorno do investimento esteja em torno de 11% ao ano. Mesmo isso pode conduzir a conclusões erradas, porque não foi considerado o valor atual do dinbeiro futuro. Isso é discutido a seguir. C.4.3 Valor Atual Líquido Se alguém lhe desse $100 hoje, você saberia o valor desse dinheiro: você teria uma boa noção de quanto você poderia comprar com essa importância. Mas quanto valem $100 se você souber que só os terá daqui a um ano? Isso é conhecido como o valor atual ou o valor descontado. O valor atual da quantia que você receberá no futuro é definido como a importância que você teria de investir hoje, à taxa de juros vigentes, para atingrr o montante especificado. Desse modo, o valor atual de $100 do próximo ano é aproximadamente $95,24 à taxa de juros de 5%. Geralmente, quando queremos calcular o valor atual de alguma quantia (que chamaremos de F), daqui a n anos, usamos a seguinte fórmula: P=F/(1 +iY 639 onde i é a taxa de juros. Assim, no exemplo acima, o valor atual do benefícios pode ser calculado da seguinte forma (admitindo-se a taxa d juros de 5%): Cálculos Projeto X Valor Atual Ano 1 Ano 2 Ano 3 Ano 4 TOTA
Economias de Caixa O 10.000 50.000 100.000 160.00 Valor Atual O 9.070 43.192 82.270 134.53 Como pode-se ver, isso torna os retornos financeiros do projet bem menos impressivos, mas é muito mais realista. Para ser ainda mai realista, precisamos entender que os custos futuros precisam sofrer des contos análogos aos dos benefícios futuros. Assim como um benefício d $10.000 no final do segundo ano vale hoje apenas $9.070, um custo d $10.000 que ocorrerá no final do segundo ano representa um custo atua de apenas $9.070. Isso leva à definição do valor atual líquido de um projeto: a dife rcnça entre o valor atual dos benefícios e o valor atual dos custos. Para nossa amostra de projeto, isso conduziria aos seguintes cálculos: Cálculos Projeto X Valor Atual Líquido Anol Ano2 Ano3 Ano4 TOTAl Economias de Caixa O 10.000 50.000 100.000 160.00(
Valor Atual dos Benefícios O 9.070 43.192 82.270 134.53 Despesas de Caixa 50.000 30000 20.000 10.000 110.00( Valor Atual dos Custos 47.619 27.211 17.277 8.227 1O0.33 Valor Atual Líquido Acumulado -47.619 -65.760 -39.845 34.198 34.19k Assim, o valor atual líquido do sistema - o valor de hoje do bene fício que esperamos obter do sistema ao final de 4 anos - é $34.198. 640 C.4.4 Taxa Interna de Retorno A taxa interna de retorno é análoga à taxa percentual que os ban cos, os fundos de investimento e outras instituições financeiras anunciam relativamente a suas contas de poupança e outras modalidades de in vestimento. A taxa interna de retorno (TIR) é definida como a taxa de juros que seria necessária para gerar as economias de caixa a cada ano (isto é, os benefícios do sistema, que já identificamos) dado um investi mento
igual às despesas de caixa que identificamos. No exemplo acima, imagine que tivéssemos investido um total de $110.000 em uma conta de poupança hipotética por um período de 4 anos. A questão é: qual a taxa de juros que deveria ser usada para que pudéssemos ter direito a uma retirada de $160.000 no final do quarto ano, sem que fosse deixado dinheiro no “banco” no final? Comparando isso com a «prime rate” e com várias outras taxas de investimento, a direção pode verificar se o novo sistema é realmente um bom investimento. Suponha que descrevamos os futuros benefícios a serem obtidos ao final dos anos 1, 2, ... N como BI, B2, ... Bn; suponha ainda que os custos futuros sejam descritos como C C2, ... Cn. Então, a seguinte fórmula polinomial deve ser resolvida para encontrar-se a taxa de juros i: C1/(1 +i)+C2/(1 +i) . . +Cnj(1 +j)N=B1/(1 +i)+B2/(1 +i) ..+BnI(1 ÷i)N Essa não é uma fórmula que possa ser facilmente resolvida nas costas de um guardanapo ou mesmo com uma simples calculadora de quatro funções. Contudo, pode-se obter calculadoras com funções de TIR (IRR) embutidas; além disso, existem programas de emprego espe cial para utilização em PC e em computadores de grande porte para es se tipo de análise financeira. Se você não dispuser prontamente dessas ferramentas, solicite auxílio do setor de finanças ou de contabilidade. C.5 ANÁUSE DE RISCOS Como parte dos cálculos de custo/benefício, você deve estar pre parado para executar uma análise de riscos para o novo sistema; você deve prepará-la mesmo que a direção não a solicite. O motivo para isso é quê não podemos predizer, com absoluta certeza, que obteremos os benefícios estimados ou que ocorrerão os custos previstos. As coisas podem revelar-se melhores do que a estimativa; o que causa maior preo cupação é o fato de elas poderem ser muito piores. A direção normalmente desejará saber quais serão as conseqüên cias se as coisas não correrem bem durante o projeto; e desejarão saber o que poderá não ir bem. Especificamente, desejarão saber as condições 641 sob as quais os custos estimados poderão ser significativamente maiore e sob quais condições os beneffcios poderão ser significativamente infe riores ao esperado. Como podem os custos ser superiores à sua estimativa? Aqui estãi algumas possibilidades; cabe a você identificar os riscos específicos di seu próprio projeto: • O fornecedor do hardware pode entrar em falência. • A equipe do projeto pode sofrer muitas substituições, doenças outros problemas. • A tecnologia utilizada no projeto pode não funcionar conform foi anunciada, principalmente se ela for uma nova tecnoIogi que nunca foi usada antes.
• A oportunidade pode ser perdida; por exemplo, o sistema podi não estar pronto para ser instalado até 2 de janeiro, e as norma governamentais podem impedir que o sistema seja realmenu instalado até o 1 de janeiro seguinte. • Problemas doutrinários ou contratuais podem surgir de uniões contratantes externos e outros. • A equipe do projeto pode não ter o necessário conhecimento d aplicação ou pode ter outras deficiências (treinamento inade quado e pouca experiência) que conduzam a uma produ tividade inferior às expectativas. • Negócios confusos ou circunstâncias econômicas podem forçai o cancelamento do projeto. • Diversos custos ocultos podem originar-se, por exemplo, d uma sobrecarga adicional de papéis que não eram necessário no sistema anterior. Os beneficios estimados, de forma análoga, podem não se materia lizar. Eis alguns possíveis motivos: • Os usuários operativos podem achar mais dificil do que espera vam a utilização do novo sistema, levando a demoras e soluções de continuidade (isso é especialmente importante se os bene ficios do sistema foram atribuídos a maior produtividade do usuários). 642 • Melhoras esperadas na participação no mercado podem não ocorrer. O sistema pode não originar mais clientes, mais pedi dos, mais negócios ou maiores receitas. • O sistema pode não apresentar o comportamento previsto; por exemplo, ele pode não processar tantas transações por segundo como era de se esperar. • O valor das novas informações tornadas disponíveis pelo sis tema pode não ter nenhum beneficio concreto. Para lidar com esses riscos, é muitas vezes uma boa solução com parar um pior caso, um melhor caso e um caso esperado. Quanto mais precisa e realista for a maneira pela qual isto for feito, melhor; não adianta enganar você mesmo e a direção com pressuposições desneces sariamente otimistas sobre custos e beneficios. De forma semelhante, embora ninguém espere que ocorra a situação do pior caso, é importan te para a direção saber quão mal as coisas podem ir. Uma nota final sobre análise de riscos: a direção muitas vezes esta rá a par de mais riscos do que você (ex.: uma potencial fusão entre sua companhia e uma outra empresa que tornará inútil o sistema). Eles podem avaliar esses riscos, e muitas vezes nada lhe dirão sobre eles; eles precisam que você avalie os riscos técnicos do projeto. NOTAS 1 Isso é especialmente válido para algumas indústrias altamente competitivas, onde novos sistemas de processamento de dados são desenvolvidos para oferecer novos tipos de serviços ao mercado (ex.: novos sistemas bancários, de cartões de crédito e de «pas
sageiro assíduo” de linhas aéreas. Desse modo, seu usuário talvez não possa justificar, quanto ao custo, esse novo sistema por seus próprios méritos, mas pode saber que ele ou ela deve desenvolver o sistema para manter-se competitivo. 2 Como analista de sistemas sênior, você deve saber disso perfei tamente. Mas, para um analista de sistemas júnior, trazido para o projeto depois deste já estar em andamento a seis meses, isso pode não ser tão evidente. A essa altura, o projeto já tem vida própria e lutará por sua existência independentemente do usuário e de qual- quer processo racional de tomada de decisão. 3 Isso às vezes pode ser reduzido se a sua empresa dispuser de extensivos recursos eletrônicos de comunicações ou de outras for mas de sistemas de comunicação além do telefone. 643 Existe um custo oculto que você não deve esquecer: durante conversão do banco de dados antigo para o novo, é inevitável descoberta de erros. Isso é especialmente válido, como se pod imaginar, se o banco de dados existente for manual e as entrada tiverem sido feitas manualmente; você encontrará dados ausente incompletos, e dados evidentemente incorretos. Quanto mais ant gos forem esses dados, mais erros provavelmente serão encontn dos. Além disso, o próprio processo de conversão pode ser sujeit a erros, principalmente se for um processo manual. Assim, prova velmente haverá um custo relacionado à correção de dados. Seri possivelmente uma boa idéia obter uma amostra aleatória do bar co de dados existente para conseguir uma estimativa do número d erros que serão encontrados e, em seguida, estimar o custo d correção desses erros (na maioria dos casos, as correções terão d ser feitas manualmente). 5 Para cálculos detalhados dessas economias, leia Pro,çrammin,g Prc ducttvity, de Capers Jones (Nova lorque: McGraw-Hill, 1985). 6 Isso naturalmente presume que alguém em sua empresa control esse tipo de coisas. Um levantamento em cerca de 500 instalaçõe americanas de processamento de dados, levado a efeito por Lient e Swanson em 1980, indica que aproximadamente 50% das eni presas não controlavam as falhas de operação de seus sistema leia Software Maintenance Management, de Lientz e Swansor Reading, Mass.: Addison-Wesley, 1980. 644 D CAMINHAMENTOS (WALKTHROUGHS) E INSPEÇÕES D.1 INTRODUÇÃO
Este apêndice apresenta uma rápida visão geral de uma técnica conhecida como caminhamento. Você poderá considerá-la útil para conduzir verificações das especificações desenvolvidas durante um projeto de análise de sistemas. Entretanto, para utilizar esse conceito, você precisará saber o que é um caminhamento, para que serve, quais são os seus participantes e quais são seus procedimentos. Depois de ler este apêndice, você pode precisar de mais informa ções. Duas possíveis fontes de consulta são Structured Walkthroughs, 3’ ed., de Edward Yourdon (Nova lorque: YOURDON Press, 1985) e Technical Inspections and Reviews, de Daniel Freedman e Gerald Weinberg (Boston: Little, Brown, 1977). D.2 OQUE É UM CAMINIIAMENTO? De acordo com a utilização do termo na indústria de desenvolvi mento de sistemas, é uma revisão coletiva de qualquer produto técnico. Isso significa que a revisão envolve outros analistas de sistemas que es tejam trabalhando com você, bem como usuários, programadores, projetistas de sistemas, pessoal de operações e outros que possam estar envolvidos em diversos aspectos do projeto em que você está trabalhan do. Mas um caminhamento, sob condições normais, não inclui seu che fe, ou a chefia do departamento, ou o vice-presidente da organização usuária. É claro que essas eminentes pessoas desejarão Ler uma oportuni dade de rever diversos aspectos do projeto, incluindo as especificações em que você estiver trabalhando. Mas eles normalmente estão menos envolvidos nos detalhes técnicos do que você pensa, e podem não ser 645 capazes de oferecer qualquer sugestão detalhada. E os interesses sã habitualmente um fator nessas revisões de alta potência. Isso não qu dizer que tais revisões sejam ruins ou que sejam irrelevantes, sigriific apenas que são diferentes dos caminhamentos tratados neste apêndia O perigo de admitir membros da direção em uma revisão de exarn coletiva é que geralmente introduzem-se os interesses políticos, e/ou caminhamento tornar-se-á uma avaliação do desempenho de uma pe soa, ao invés de uma revisão técnica de um pmduto. Observe que pode haver muitos tipos diferentes de caminhamer tos em um projeto comum: • Caminhamentos de análise • Caminhamentos de projeto • Caminhamentos de código • Caminhamentos de testes Como o tema deste livro é a análise de sistemas, focalizaremos c caminhamentos de análise. Em termos práticos, isso significa que ur grupo de analistas de sistemas, juntamente com outras partes interess das, reúne-se para rever diagramas de fluxo de dados, diagramas d entidades-relacionamentos, diagramas de transições de estado, itens d dicionário de dados e especificações de processos, isto é, todos os pr dutos técnicos desenvolvidos pelo analista de sistema.
D.3 POR QUE FAZER CAMINTIAMENTOS? O principal motivo de realizar-se um caminhamento é localiza erros tão rápida e economicamente quanto possível. Como já menciona mos anteriormente, é normalmente muito mais barato descobrir e elim nar erros tão cedo quanto possível, cm vez dc esperar até que um prodi. to esteja pronto e remetido para a etapa seguinte de desenvolvimento. Existem outros meios de descobrir erros além dos caminhamento a pessoa que elaborou o produto (ex.: um DFD) pode revisá-lo e tenta descobrir seus próprios erros. Mas o senso comum e muitos anos d experiência na área do processamento de dados indicam que esse é urr modo muitas vezes antteconômtco de Ça7.eT as co P pessoas m vezessão incapazes de perceber seus próprios erros, não importando profundidade com que examinem seus próprios trabalhos. Isso vale par alguém que esteja lendo um documr rto em busca de erros tipográficc ou que esteja lendo um programa de computador à procura de “bugs 646 ou examinando um DFD em busca de erros. Um grupo de perscrutado res entendidos e interessados no assunto pode muitas vezes encontrar erros com rapidez muito maior. Outro meio de encontrar erros é usar uma estação de trabalho de analista do tipo discutido no apêndice A; isso é grosseiramente análogo a usar um compilador para encontrar erros sintáticos em um programa, ao invés de examinar visualmente a listagem do programa. Se você dispuser de uma estação de trabalho de analista, não deixe de usála para identi ficar todos os erros de sintaxe que ela for capaz de descobrir. Porém, assim como um compilador não descobre todos os erros de um progra ma (p.ex.: ele não localiza erros em tempo de execução nem erros lógi cos, porque ele executa uma análise estática ao invés de uma análise dinâmica do programa), uma estação de trabalho de analista não conse gue encontrar todos os erros de um conjunto de modelos de especifica ções. O caminhamento ainda constitui-se em um útil complemento a quaisquer ferramentas que estejam disponíveis. Na verdade, uma das coisas que a estação de trabalho é incapaz de fazer é a análise do estilo dos produtos, que é algo que as pessoas são altamente qualificadas para fazer. Dessa forma, ao examinarem um DFD, os revisores humanos podem fazer perguntas como: • Existem bolhas em demasia no diagrama? • Os nomes dos processos são significativos? • Os diagramas foram desenhados de forma esteticamente agradá vel? É provável que o usuário examinará realmente o diagrama ou ficará confuso? • Os fluxos de dados foram agrupados de modo significativo entre um nível e outro? • As atividades elementares foram agrupadas de um modo inteli gente para compor bolhas de nível mais elevado? Além disso, existem outros benefícios que as organizações costumam descobrir na técnica do caminhamento: treinamento e segur Um processo de revisão coletivo é um excelente veículo para ensinar os membros novos da equipe do projeto (e também aos
membros antigos e desgastados da equipe!) os detalhes relativos à aplicação, à análise de sistemas ou os detalhes da notação de diagramas de fluxo de dados. E como todos os componentes do grupo de revisão tornam-se um tanto familiarizados com o produto (e muitas vezes intimamente familiarizados com ele), o caminhamento converte-se em 647 uma questão de segurança contra o inesperado, o extemporâneo afa tamento do produtor da equipe do projeto; alguém deve ser capaz encarregar-se do trabalho feito pelo produtor e dar-lhe continuidade. O grande perigo de tudo isso é que o produtor pode não concc dar com os benefïcios e considerar todo o processo de caminhameni como uma invasão de sua privacidade. Se o produtor considerar os DF como sendo de sua propriedade (em vez de um bem comum), então e e ressentir-se de ter de mostrá-los a outrem. Se sua idéia de estilo d ferir muito da dos examinadores, poderão ocorrer violentas discussõ no caminhamento. E se o produtor for contrário à idéia de treinamento segurança, ele pode muito bem rejeitar a idéia de um caminhamento. Em geral, os caminhamentos são realizados em locais em que idéia de equipe já está aceita e consagrada; em um projeto típico, sign fica que cada componente deve compreender que uma falha ou err sério em seu trabalho pode comprometer o sucesso de todo o projeto, que quer dizer que a possibilidade de erros em seu trabalho é urr legítima preocupação dos demais componentes da equipe. Para maiorc detalhes sobre o conceito de equipes, especialmente as assim chamad «equipes não-egocêntricas”, leia a clássica obra de Gerald Weinberg fl Psycbology of Computer Programming (Nova Jorque: Van Nostran Renhold, 1971). D.4 QUANDO O CAMINHAMENTO DEVE SER REALIZADO Um caminhamento deve ocorrer em virtualmente qualquer pont do desenvolvimento de um produto técnico - do momento em que el representa um brilho nõs olhos do produtor, ao ponto em que o prc dutor esteja absolutamente convencido de que o produto está terminad e pronto para ser entregue ao cliente (ou ao estágio seguinte do prc cesso de desenvolvimento). Geralmente é preferível fazer um cami nhamento tão cedo quanto possível, mas não tão prematuramente que produto ainda esteja incompleto e cheio de erros triviais que o autor pc deria ter eliminado. Vamos utilizar o exemplo de um diagrama de fluxo de dados par ilustrar esse detalhe. O produtor normalmente fará diversas iterações d (1) discutir a parte importante do sistema com o usuário; (2) visualiza mentalmente um DFD; (3) esboçar diversas versões incompletas do DF em guardanapos de papel e no verso de envelopes; (4) esboçar um: versão relativamente limpa do DFD em uma folha de papel em branco (5) introduzir os detalhes do DFD em uma estação automatizada d analista do tipo discutido no apêndice A; (6) conduzir quaisquer opera ções de verificação de erros que estejam disponíveis no produto d 648 estação para eliminar erros de sintaxe; (7) imprimir uma versão final do DFD em um plotadora ou em uma impressora laser e (8) entregar o DFD ao chefe com o triunfante
anúncio de que a tarefa terminou antes do prazo. Neste caso, é cedo demais para realizar-se um significativo cami nhamento nos estágios (1), (2) ou (3); o caminhamento poderá ser rea lizado eficazmente nos estágios (4), (5) ou (6). Os estágios (7) e (8) são muito tardios. O momento exato de se realizar o caminhamento depende do suporte automatizado disponível, de quão rapidamente ele pode tor nar-se disponível (isto é, o analista terá de esperar quatro dias para ter acesso à estação de trabalho, que é compartilhada por 27 outros analis tas?), e quanto custa a utilização do suporte automatizado. O principal motivo de evitar-se um caminhamento em um estágio tardio é que o produtor terá investido tanto do seu ego no produto que normalmente relutará em efetuar qualquer modificação, além das corre ções dos erros maiores (e as vezes nem mesmo esses!). Assim, o pro dutor pode ter desperdiçado dcsnecessariamcnte um bom tempo eli minando erros de seu produto, quando a equipe de revisão poderia fazê lo muito mais rápida e economicamente se tivesse examinado o produto em um momento anterior. E, para terminar, devemos lembrar a psicologia dos próprios revi sores: eles despendem seu próprio tempo participando da localização dos erros de outrem, e ressentir-se-ão disso, não importa o quanto sua equipe possa ser não-egocêntrica como eles propalam. Considerando esse sentimento, não deve ser mostrado aos revisores um produto mal feito e incompleto; mas também não lhes deve ser apresentado um pro duto terminado imutável e perfeito. Se você vai gastar uma hora do seu tempo revisando o DFD do seu colega, é agradável saber que você fez algo de útil ao encontrar um erro que o próprio produtor não viu. Se, por outro lado, você gastar uma hora examinando um produto sem encontrar nada para criticar, existe uma natural tendência humana para encarar esse esforço como algo semelhante a um desperdício de tempo e para que você esteja menos disponível na próxima vez que for chamado para participar de um caminhamento. D.5 PERSONAGENS DE UM CAMINHAMENTO Muitas organizações realizam caminhamentos sem nenhum trei namento ou formalismo do que o que foi acima descrito porém muitas descobriram ser vantajoso introduzir algum formalismo ou estrutura na revisão; daí a conhecida expressão caminhamento estruturado. Uma ca racterística comum de um caminhamento estruturado é um conjunto de 649 personagens formais desempenhados pelos revisores. Diferentes revisc res podem desempenhar diferentes papéis entre um e outro caminh2 mento; e em alguns casos um revisor pode desempenhar mais de ur papel. Eis os personagens que costumam ser encontrados em um cam nhamento: Apresentador, a pessoa que explica ao grupo revisor o que produto faz, que pressuposições foram feitas quando ele f criado, e assim por diante. Em muitos casos, o apresentador é produtor, mas nem sempre. Algumas empresas acham que se produtor apresentar seu próprio produto, (1) o produto pod ser tão enigmático que nunca seria
aceito se o produtor nã estivesse imediatamente disponível para explicá-lo e (2) o prc dutor pode sutilmente (e talvez inocentemente) fazer uma 12 vagem cerebral na audiência revisora e levá-la a cometer o mesmos erros, descuidos e erros de omissão e cometimento qu cometeu. • Presidente, a pessoa que organiza e controla a reunião. Seu o1 jetivo é manter a discussão desenrolando-se de uma forma orde nada e construtiva para impedir discussões paralelas, bem com críticas ao apresentador. Por motivos óbvios existe a tendênci de deixar o gerente de projeto servir como presidente; mas pela razões descritas anteriormente neste apêndice, a presença d um gerente na revisão coletiva muitas vezes modifica o caráte da revisão de um modo muito negativo. • Escrivão, a pessoa que faz o registro escrito dos eventos impor tantes da revisão. Além de coisas triviais como a data em qu ocorreu o caminhamento, que produto esteve sendo exami nado, e quem compareceu ao caminhamento, o escrivão fa: anotações sobre as questões técnicas significativas que foran levantadas, erros que tenham sido encontrados e sugestões pan aperfeiçoamento ou modificações feitas pelos revisores. • Porta-voz da manutenção, um revisor cuja principal orientaçã é a manutenção do produto a longo prazo. Ele normalment estará interessado em que o produto não seja muito idiossin crásico ou não seja insuficientemente documentado. Ele tende; desempenhar um papel mais importante nos caminhamento relativos a projetos e códigos do que nos caminhamentos di análise. 650 • Mantenedor dos padrões, o papel dessa pessoa é evidente: asse gurar que o produto seja consistente com os padrões gerais que tenham sido adotados pelo projeto e/ou pela organização. Às vezes, o principal papel dessa pessoa é orientar o produtor e outros membros da equipe sobre se o produto deverá em última análise ser considerado aceitável (em termos de obediência aos padrões) por um grupo formal de controle de qualidade. Existem duas últimas observações a serem feitas sobre esses per sonagens: primeiro, lembre-se que os papéis podem mudar entre um e outro caminhamerito. Segundo, lembre-se de induir o usuário como um desses personagens caso o usuário seja um ativo participante do projeto. D.6 PROCEDIMENTOS DE CAMINHAMENTOS Como indicamos na seção precedente, os caminhamentos bem- sucedidos normalmente caracterizam-se por um conjunto de persona gens e procedimentos formais. Os procedimentos variam de empresa para empresa, mas a seguinte lista é típica: 1. Programe o caminhamento com um ou dois dias de adianta mento e distribua adequado material informativo aos revisores. Se o caminhamento for marcado sem um aviso suficientemente antecipado, os revisores não terão oportunidade de estudar o produto antes que o caminhamento seja iniciado. 2. Assegure-se de que os revisores tenham despendido algum tempo na revisão do produto. Um modo fácil de fazer isso é solicitar que cada revisor traga para o caminhamento pelo menos um comentário positivo e um negativo sobre o produto. O
risco que existe é que alguns dos revisores estejam tão ocupados ou tão desinteressados no produto que não façam qualquer tarefa antecipada e apenas mantenham-se sentados silenciosamente durante o caminhamento sem prestar nenhuma contribuição. 3. Solicite ao apresentador que faça uma ligeira apresentação do produto. Isso muitas vezes é feito com utilização de diagramas em páginas sucessivas, projetores dc transparências, e coisas desse tipo. É aí que o grupo literalmente caminha através do produto. 651 4. Solicite comentários aos revisores. Isso normalmente é orqu trado pelo presidente, que pode resolver andar pela sala, licitando a cada revisor que mostre um erro ou faça ui apreciação sobre o produto. 5. Assegure que os problemas sejam apresentados, porém não. lucionados no caminhamento. Isso é especialmente importar no caso de ser apontado um erro não trivial; deixe o produi discorrer sobre como resolvê-lo em sua vez de pronunciar- em vez de permitir a ocorrência de um “brainstorm” c sestruturado. Isso é também um importante procedimer quando surgem problemas de estilo: o produtor pode discorc dos comentários, e é preferível que ele os considere após a re nião (ou fale separadamente com a pessoa que fez a sugest sobre o estilo). 6. Faça o caminhamento relativamente curto - não superior uma hora. Não se pode esperar que alguém mantenha um ai nível de concentração por mais do que uma hora; a atenção c meça a divagar, e existe um sério risco de que o caminhamen degenere em uma conversa informal. 7. Estabeleça uma resolução de acordo com o resultado da reuni; de caminhamento. As recomendações que costumam ser feit pelos revisores são (1) “Consideramos que o produto deva pe manecer como está”, ou (2) “Pensamos que alguns erros deva ser corrigidos e alguns problemas menores de estilo devem tratados, mas confiamos em que o produtor fará as modificaçõ necessárias sem mais revisões” e (3) “Encontramos tantos em e/ou problemas de estilo que gostaríamos que fosse feito u outro caminhamento quando o produtor tiver feito todas modificações apropriadas”. Dependendo da natureza da equiç e do modo como as pessoas assumem a responsabilidade p suas tarefas na empresa, essa recomendação pode ser tornac obrigatória, ou pode representar simplesmente uma sugestã opcional feita pelos revisores. D.7 RESUMO Embora a técnica do caminhamcnto seja um processo simples direto de revisão, não é tão amplamente utilizada como se possa pensai Um motivo disso é o aparente aumento do tempo necessário para cor duzir-se os caminhamentos: eles podem tomar dc 5 a 1 do tempo tot; 652 do projeto. Por outro lado, a maioria das organizações que utilizaram o caminhamento relataram substanciais reduções no número de erros que permaneceram ocultos. O motivo mais importante para a não utilização do caminhamento talvez seja o fato de que alguns programadores e analistas de sistemas continuam a considerar seus programas
e diagramas de fluxo de dados como de sua propriedade particular, ao invés de um bem comum. Desse modo, eles preferem não mostrar seu trabalho para Outros e resistem fortemente às críticas e sugestões de melhorias. Esse é um perigoso mo do de ver as coisas; cada vez mais empresas estão começando a perceber que devem introduzir alguma forma de revisão coletiva para terem su cesso no aumento da qualidade dos sistemas que produzem. 653 E TÉCNICAS DE ENTREVISTAS E DE COLETA DE DADOS E.1 INTRODUÇÃO Este apêndice discute algumas diretrizes para as entrevistas que vo cê fará durante a fase de análise de sistemas do projeto de desenvolvi mento de um sistema. Você provavelmente entrevistará usuários, geren tes, auditores, programadores que fazem a manutenção de sistemas já existentes e várias outras pessoas. Por que fazemos entrevistas durante a análise de sistemas? Os motivos são estes: • Precisamos coletar informações sobre o comportamento de um sistema atual ou sobre os requisitos de um novo sistema de pes soas que têm essas informações armazenadas em algum lugar em suas cabeças. • Precisamos verificar nossa própria compreensão, como analistas de sistemas, do comportamento de um sistema atual ou dos re quisitos de um novo sistema. Essa compreensão deve ter sido adquirida através de entrevistas prévias em combinação com informações coletadas de modo independente. • Precisamos coletar informações sobre o(s) sistema(s) atual(is) para executarmos os estudos de custo/benefkio (veja maiores informações sobre essa área no apêndice C). Este apêndice cobre os seguintes tópicos sobre o processo de entrevistas: • Tipos de entrevistas 655 • Problemas fundamentais das entrevistas • Diretrizes gerais para a realização de entrevistas E.2 TIPOS DE ENTREVISTAS A forma mais comum de entrevista é uma reunião pessoal e dire entre você (talvez acompanhado por um ou dois analistas auxiliares d mesmos projetos) e um ou mais
interlocutores (entrevistados). Norma mente tomam-se apontamentos com papel e lápis por um dos entrevist dores; menos costumeiramente, a entrevista pode ser gravada ou um( secretário(a) tomará notas durante a entrevista. Neste apêndice, vam presumir que sua entrevista será desse tipo geral, mas não farei qualqu pressuposição sobre gravadores ou estenógrafas. Você deve perceber que as informações obtidas em uma entrevisi também podem ser obtidas por outros meios, por exemplo, solicitand se que os entrevistados respondam por escrito a um questionário forma ou solicitando que descrevam por escrito os requisitos do novo sistem Também podemos aumentar as entrevistas pela presença de vários e pecialistas (que podem até conduzir a entrevista enquanto o analista d sistemas participa como assistente), como peritos em indústria, psicók gos comportamentais e negociadores. E, finalizando, você deve lembn que outros meios de obtenção de dados (ex.: videocassete) podem s utilizados para registrar uma entrevista. Durante a década de 80, uma forma especializada de entrevisi tornou-se popular em algumas empresas de SIG; ela é conhecida com JAD (de Joint Application Development) ou projeto acelerado, ou análi em equipe, e por vários outros nomes. Ela consiste em uma rápida entn vista e um processo acelerado de coleta de dados em que todos c principais usuários e o pessoal da análise de sistemas agrupam-se ei uma única e intensiva reunião (que pode prolongar-se de um dia a uni semana) para documentar os requisitos do usuário. A reunião costuni ser supervisionada por um especialista treinado que atua como mediad para encorajar melhores comunicações entre os analistas de sistemas os usuários. Embora todas essas variações tenham de fato sido usadas, elas sã relativamente raras e não serão discutidas em maiores detalhes nesi apêndice. A entrevista mais utilizada ainda é a reunião pessoal entre ur analista de sistemas e um usuário final. 656 E.3 PROBLEMAS FUNDAMENTAIS À primeira vista, pode parecer que o processo de entrevistar um usuário seja uma questão simples e direta. Afinal de contas, você é uma pessoa inteligente e capaz de expressar-se; e o usuário também o é. Os dois são pessoas racionais e ambos têm o mesmo objetivo: passar infor mações relativas a um novo sistema proposto da mente do usuário para a sua. Qual é o problema’ Na realidade, existem muitos problemas que podem ocorrer. Em muitos projetos de alta tecnologia, tem-se observado que a maioria dos problemas dificeis não envolvem hardware nem software, mas sim o »peopleware”. Os problemas de peopleware na análise de sistemas são muitas vezes encontrados nas entrevistas: é a entrevista onde “o pneu toca na estrada» entre o usuário e o analista de sistemas. Os problemas mais comuns a que você deve estar atento São: ErUrev a pessoa errada no momento errado. É muito fácil, por causa dos problemas e interesses organizacioriais, falar com a pessoa que é o perito oficial na orientação do usuário, que demonstra nada saber a respeito dos verdadeiros requisitos do sistema; também é possível perder a oportunidade de falar com o usuário desconhecido que realmente sabe quais são os requi sitos. Mesmo que encontre a pessoa certa, você talvez tente entrevistá-la durante um período em que o usuário não está disponível ou esteja
mergulhado sob outras pressões e emergências. • Fazer peiguntas erradas e obter respostas erradas. A análise de sistemas é, como Tom DeMarco gosta de dizer, uma forma de comunicação entre estranhos. Os usuários e os analistas de sis temas têm vocabulários diferentes, experiências básicas diferen tes e muitas vezes um diferente conjunto de pressuposições, percepções, valores e prioridades. Desse modo, é fácil fazer ao usuário uma pergunta racional sobre os requisitos do sistema e o usuário não entender absolutamente a pergunta, sem que • nenhum dos dois perceba o fato. E é fácil para o usuário prestar lhe algumas informações sobre os requisitos e você não enten der essas informações, novamente sem que nenhum dos dois perceba o fato. As ferramentas de modelagem apresentadas an teriormente neste livro são uma tentativa de fornecer uma lin guagem comum e sem ambigüidades para diminuir esses mal entendidos. Porém as entrevistas costumam ser realizadas em uma língua comum (inglês, espanhol, francês, português etc.), portanto o problema é real. Isso explica porque é tão importar marcar entrevistas subseqüentes para confirmar que ambas partes entenderam as perguntas e as respostas. Criar ressentimentos recíprocos. Como veremos na seção E. existem algumas razões pelas quais o usuário pode não se sen à vontade ou mesmo colocar-se em posição antagônica na e trevista com um analista de sistema (ex.: porque ele percebe qi o verdadeiro objetivo do novo sistema que o analista está e pecificando é tomar-lhe o emprego). E o analista pode ressent se do modo como o usuário está respondendo as perguntas (e pode perceber que o usuário a está insultando sugerindo qi ela é jovem demais e inexperiente para oferecer qualquer o nião sobre os requisitos do novo sistema). Em qualquer caso, ressentimento pode surgir entre as duas partes, tornando comunicação muito mais difícil. Não existe um modo mágico de garantir que esses problemas ni ocorrerão; eles são a conseqüência das interações pessoa-a-pessoa, cada uma dessas interações é única. Contudo, as sugestões dadas a s guir podem ajudar a reduzir a probabilidade desses problemas; fora iss você dependerá de prática para melhorar cada vez mais em cada ents vista subseqüente. E.4
DIRETRIZES PARA A REALIZAÇÃO DE
ENTREVISTAS As seguintes diretrizes podem ser de grande auxílio na direção c entrevistas bem-sucedidas com seu usuário. E.4. 1 Desenvolva um Plano Geral de Entrevistas Antes de tudo, é extremamente importante que você descub quem deve ser entrevistado. Caso contrário, você desperdiçará o temp de todos e criará um enorme tumulto, por falar com pessoas erra± sobre coisas erradas. Isso requer que você obtenha um organograma da empresa qu mostre as pessoas da organização usuária, bem como a hierarquia entr elas. Se não existir um organograma formal, encontre alguém que saib como a organização funciona e peça ajuda. Se o organograma existi certifique-se de que esteja correto e atualizado; as empresas muitas
veze 658 modificam-se com muito mais freqüência do que o ciclo editorial anual em que os diagramas são produzidos! O fato de conhecer o esquema organizacional não lhe diz necessa riamente com quem você deve entender-se; às vezes, a pessoa que mais sabe a respeito de algum aspecto de um sistema é um funcionário admi nistrativo ou burocrata que sequer aparece no organograma. Como vi mos no capítulo 3, muitas vezes existem três níveis de usuários em uma organização grande e complexa - o usuário verdadeiro, o usuário su pervisor operativo e o usuário supervisor executivo - e é muitas vezes de grande importância falar com todos os três níveis. Em muitos casos também é importante conversar com os usuários na seqüência adequada e na combinação certa. Isto é, você pode estar entrevistando Marta, que diz: “Bem, eu, naturalmente, recebo todos os meus dados de entrada de Jorge; ele poderá falar-lhe sobre esses dados. E, em seguida, faço o seguinte...”. Em um caso assim, muitas vezes é melhor falar primeiro com Jorge, deixando para falar com Marta depois. Ou você pode estar entrevistando Paulo, que diz: “Bem, na verdade, Susana e eu desempenhamos essa função juntos; ela faz uma parte e eu faço o resto...”. Nesse caso, seria evidentemente mais produtivo entrevis tar Susana e Paulo simultaneamente. Por vezes você poderá saber em que seqüência os usuários deverão ser entrevistados face a seu conheci mento geral da organização e por vezes os próprios usuários lhe dirão uma vez que saibam que serão entrevistados. E.4.2 Cert de que Você Tem Autorização para Falar com os Usuários Em algumas organizações ir formais não haverá restrições em sua escolha dos usuários com quem você quer falar ou sobre como as entre vistas serão marcadas. Porém isso é incomum em empresas grandes; é politicamente perigoso vagar pela organização usuária realizando entre vistas sem prévia autorização. Na maioria dos casos, a autorização virá ou do encarregado de um setor usuário (um departamento, divisão ou grupo) ou do representante nomdado que estará adido ao projeto de desenvolvimento do sistema. Em qualquer caso, os usuários têm legítimas razões em querer aprovar, antecipadamente, quem você for entrevistar: • Eles podem saber que alguns usuários não serão capazes de compreender ou exprimir bem os requisitos do sistema. • Eles podem desconfiar de que alguns dos usuários do ní operativo sejam “renegados” que apresentarão requisitos fal (ou requisitos que a direção não aprove). • Eles podem recear que as entrevistas interfiram com as ai buições normais de trabalho que os usuários tenham de e, cutar. Por causa disso, desejarão marcar as entrevistas para momentos apropriados. • Eles podem recear que as entrevistas sejam vistas como o iziíc de um esforço de substituição dos usuários humanos port. sistema computadorizado, provocando demissões
e coisas des gênero. • Eles podem considerar que eles próprios (os diretores) sabc mais a respeito dos requisitos do sistema do que qualquer out e por isso não desejam que você entreviste qualquer usuário nível operativo. • Pode estar havendo uma batalha política em andamento em ti nível de chefia muito mais elevado, entre o setor usuário e organização de desenvolvimento de sistemas. Desse modo, gerente usuário pode não ter reais objeções a suas entrevista porém, impedindo que elas sejam feitas, ele estará envian uma mensagem política para o chefe do chefe do seu chefe. Por todos esses motivos, é uma boa medida obter uma prévia aul rização. Na maior parte dos casos, basta uma autorização verbal; se organização for terrivelmente burocrática ou paranóica, você pode pre sar de uma autorização escrita. Isso, a propósito, também significa qi você deve estar cônscio e atento à política organizacional se tiver certe da necessidade de falar com um usuário (normalmente um usuário nível operativo) com quem você tenha sido avisado para não convers Você talvez pense em combinar algumas reuniões clandestinas fora d instalações, mas geralmente é mais seguro levar para cima a solicitaç através da cadeia de comando de seu setor de forma a que ela pos descer pela cadeia de comando da organização usuária 1• E.4.3 Planeje a Entrevista para Fazer Uso Eficiente do Tempo O principal aspecto desta sugestão é que você deve compreend que está tomando o tempo do usuário e que ele (ou o chefe dele) poi 660 achar até que você esteja desperdiçando o tempo dele. Assim sendo, é importante que você planeje e prepare tão antecipadamente quanto possível para poder fazer uso eficiente da entrevista. A primeira coisa a fazer é certificar-se de que o usuário conhece o assunto da entrevista. Em alguns casos isso pode ser feito por telefone; em outros, pode ser adequado preparar uma lista das perguntas que serão feitas, ou dos tópicos que serão abordados, ou dos DFD que você deseja revisar, e remetê-la ao usuário com um dia ou dois de antecipa ção. Se você não puder fazer isso, é um indício de que você de fato não está preparado para a entrevista. E se o usuário não tiver lido o material remetido, é sinal de que (1) está muito ocupado, (2) está desinteressado, (3) opõe-se a toda a idéia da entrevista ou (4) é incapaz de entender as perguntas apresentadas. Um aspecto relacionado: colete, antes da entrevista, tantos dados pertinentes quanto possível. Se houver formulários ou relatórios que sejam pertinentes à discussão, geralmente você poderá obtê-los ante cipadamente. Se existirem outros documentos escritos do usuário des crevendo o novo ou o antigo sistema consiga-os e estude-os antes da entrevista. Se você tiver preparado suas perguntas antecipadamente, você deve ser capaz de realizar a entrevista em uma hora ou menos. Isso é importante; não só o usuário é geralmente incapaz de reservar mais do que uma hora de cada vez, mas também (como eu disse no
apêndice D) as pessoas normalmente não conseguem se concentrar intencionalmen te (principalmente se estiverem examinando diagramas um tanto estra nhos) por mais do que cerca de uma hora. Isso naturalmente significa que você deve organizar a entrevista para abranger um escopo relativa mente limitado, focalizando normalmente uma pequena parte do siste ma. Isso também pode significar que você tenha de marcar algumas entrevistas com o mesmo usuário para abranger inteiramente a área em que ela ou ele está envolvido(a). Finalizando, marque uma reunião subseqüente para rever o mate rial que você coletou. Normalmente, você irá para sua mesa com todas as informações colhidas na entrevista, colocará seu “chapéu de analista”, e executará bastante trabalho com os dados brutos. Pode haver DFD a serem desenhados ou itens a serem criados no dicionário de dados; cálculos de custo/benefício podem precisar ser feitos; as informações provenientes da entrevista podem precisar ser correlacionados com dados de outras entrevistas, e assim por diante. Em qualquer caso, os dados dessa entrevista serão manipulados, documentados, analisados e convertidos em uma forma que o usuário pode nunca ter visto antes. Desse modo, você pode precisar marcar uma entrevista posterior para verificar (1) que você não cometeu nenhum engano em seu entendi mento do que o usuário lhe disse, (2) que o usuário não mudou de 661 opinião nesse ínterim 2 e (3) que o usuário entende a notação ou representação gráfica dessas informações. E.4.4 Utilize Ferramentas Automatizadas que Sejam Adequadas, Mas Não Abuse Durante a entrevista, você pode achar conveniente utilizar ferr mentas de prototipação, principalmente se o objetivo da entrevista f discutir a visão que o usuário tem da interface pessoa-máquina, E modo semelhante, se você estiver revisando um diagrama de fluxo dados e discutindo possíveis modificações, achará prático usar uma d ferramentas CASE estudadas no apêndice A. Lembre-se, portanto, que o objetivo dessas ferramentas é facl1lt as discussões e não complicá-las; elas devem permitir que você e usuário examinem alternativas e modificações com rapidez e facilidad elas podem ajudá-lo a registrar seu conhecimento de um requisito c usuário e corrigir imediatamente quaisquer erros que você teni cometido. Se, entretanto, a tecnologia introduzir-se no assunto, deixe-a foi da entrevista. Se o usuário tiver de aventurar-se além de seu ambieni normal de atividade (para outro prédio, na sala do computador) podei encarar a ferramenta como um aborrecimento. Se o usuário não esLiv familiarizado com a tecnologia de computadores e for solicitado a utilizi a ferramenta, poderá rejeitá-la. E se você não estiver familiarizado com ferramenta (ou se a ferramenta for lenta, tendente a erros ou de empre limitado) isso interferirá sensivelmente na entrevista. Em qualquer de ses casos, talvez seja preferível usar a ferramenta “off-line”
depois da ei trevista; você, então, poderá mostrar ao usuário a saída da ferrameni sem causar quaisquer problemas desnecessários. E.4.5 Tente Descobrir em Que Informações o Usuário Está Mais Interessado Se você tiver de desenvolver um modelo completo de sistema pai alguma parte de um sistema, você possivelmente necessitará deterjnin; entradas, saídas, funções, caracterí: tempo-dependentes e a mem ria armazenada do sistema. Poréri a ordem em que você obtém essa informações costuma não ter muita importância, ou, pelo menos, nã deve significar muito para você. Mas pode significar muito para o usuário, e você deve deiixá-l começar a entrevista por onde ele preferir. Alguns usuários desejarã começar pelas saídas, isto é, pelos relatórios e valores de dados que ek 662 querem que o sistema produza (na realidade, eles talvez nem saibam que entradas serão necessárias para produzir as saídas desejadas). Ou tros usuários poderão estar mais interessados nas entradas ou nos deta lhes de uma transformação funcional. Outros ainda preferirão falar sobre os detalhes dos dados de um depósito de dados. Como quer que seja, faça o que puder para enxergar os requisitos do sistema da perspectiva desses usuários, e conserve essa perspectiva em mente quando lhes fizer as perguntas necessárias à sua entrevista. E.4.6 Use um Estilo Adequado de Entrevistar Como diz William Davis [ 19831: Sua atitude em relação à entrevista é importante na determinação de seu sucesso ou fracasso. Uma entrevista não é uma competição. Evite ataques; evite o uso excessivo do jargão técnico; conduza uma entrevista, não uma tentativa de persuasão. Fale com as pessoas, não fale muito alto, nem muito baixo, nem indiretamente. Uma en trevista não é um julgamento. Faça perguntas detalhadas, mas não faça perguntas para confirmar outras respostas. Lembre-se que o en trevistado é o perito e que é você que precisa de respostas. Para concluir, de modo algum critique a credibilidade de outras pessoas. Não diga “Fulano disse-me algo diferente” ou “Você não sabe o que está dizendo”. Fazer perguntas detalhadas nem sempre é fácil; dependendo da personalidade do entrevistado e do tema da entrevista, você pode preci sar de uma gama de estilos para extrair as informações necessárias. Eis aqui alguns estilos que podem mostrar-se úteis: • Relacionamentos. Peça ao usuário para explicar o relaciona mento entre o que está em discussão e as demais partes do sis tema. Se o usuário estiver falando sobre um assunto (p.ex.: um cliente), peça-lhe que explique seu relacionamento com outros aspectos; se ele estiver descrevendo uma função (ex.: uma bolha de um DFD), peça-lhe que explique seu relacionamento com • outras funções. Isso não só o auxiliará a descobrir mais detalhes sobre o item em pauta,
mas também o ajudará a descobrir inter- faces (ex.: fluxos de dados de uma bolha para outra no DFD) e relacionamentos formais. • Pontos de vista alternativos: Solicite ao usuário que descreva o ponto de vista de outros usuários em relação ao item que esteja sendo discutido. Pergunte ao usuário, por exemplo, o que seu 663 chefe pensa sobre uma bolha do DFD, ou um tipo de objeto DER; ou pergunte o que pensa seu subordinado. Detalhamenta Solicite ao usuário uma informal descrição n rativa do item em que você estiver interessado. ‘Fale-me sobn modo como você calcula o valor das remessas”. Ou, se esti falando com o usuário sobre um tipo de objeto no DER, vc cria dizer: ‘Fale-me a respeito de um cliente. O que vc sabe (ou precisa saber) sobre um cliente?” • Dependências: Pergunte ao usuário se o item em discussão pende, para sua existência, de alguma outra coisa. Isso é es cialmente útil quando se discutem possíveis tipos de objeto relacionamentos no DER. Em um sistema de controle de pc dos, por exemplo, você pode perguntar ao usuário se se possível haver um pedido (se isso for o item em discussão) sc que haja um cliente. • Confirmaçãa Diga ao usuário o que você acha que ouviu dizer; use suas próprias palavras em lugar das dele e peça cc firmação. Desse modo, você pode dizer: ‘Deixe-me ver se tendi o que você disse: sempre que algo entra no sistema, vc sempre tem que o processar e enviar uma mensagem de tuação para o setor de auditoria”. E.5 POSSÍVEIS FORMAS DE RESISTÊNCIA NA ENTREVISTA Como já dissemos, você deve estar preparado para o fato de q alguns usuários serão contrários à própria idéia de uma entrevista; ess uma das razões para garantir que o chefe ou alguém com autoridade setor esteja ciente e tenha permitido a entrevista. Algumas das objeç mais comuns (e algúmas possíveis respostas a essas objeções) são seguintes: • Você está tomando tempo demais de mim. A resposta a issc explicar que você compreende, e desculpar-se pelo tempo q você precisa tomar, mas que você já preparou tudo e fará entrevista no tempo mais curto que for possível. Isso nai ralmente exige que você chegue pontualmente na hora marca para o início da entrevista, mantenha a discussão no rumo p visto, e encerre-a no momento em que você tenha dito que faria. 664 • Você está ameaçando meu emprego. Isso muitas vezes é uma reação muito emocional que pode ou não ter fundamento. Em bora você possa pensar em diversas maneiras de responder a esse comentário, lembre-se de que você não é o patrão dessa pessoa e de que você não está em posição de garantir que o emprego dela não esteja em perigo, ou de informá-la do con trário. Você pode tentar negar a responsabilidade dizendo: “Eu nada tenho a ver com isso; estou apenas documentando os re quisitos do sistema sob a direção da gerência”, mas o usuário entrevistado não aceitará isso. Ele vai considerá-lo como o “pe rito em eficiência” cuja tarefa é orientar a direção em como o emprego dele pode ser eliminado pela computadorização. A solução para esse problema, caso ele ocorra, é fazer
com que seja levado ao conhecimento dos níveis superiores dos usuários e obter o pronunciamento oficial deles, pessoalmente ou por escrito, se possível. • Você não conhece nossa empresa, como você quer dizer-nos como deve ser o novo sistema? A resposta a essa pergunta é: “Você tem razão! É por isso que o estou entrevistando para saber o que você pensa sobre quais devam ser os requisitos!”. Por outro lado, se você for um analista engenhoso, deverá su gerir várias maneiras de “melhorar” as coisas (especialmente se parte ôu todo o serviço feito atualmente pelo usuário for uma manifestação de uma antiga e ineficiente implementação de um sistema); assim, esse tipo de comentário pode ser inevitável. Entretanto, o verdadeiro truque é continuar sendo tão respeitoso quanto possível e reconhecer constantemente a experiência do usuário em sua própria área, embora continuando a perguntar se ele teria a fineza de explicar-lhe (e portanto ajudando a que você aprenda) porque sua idéia não funcionaria. • Você está tentando mudar o modo como as coisas são feitas aqui. Uma variação do comentário acima. O artificio neste caso é mostrar ao usuário que embora você possa estar propondo al • gumas (radicais) mudanças na implementação do sistema atual, você não pensa em modificar as características essenciais desse sistema, exceto nas áreas onde eles mesmos tenham solicitado uma alteração. Lembre-se, contudo, que algumas características da implementação do sistema atual podem ter de ser preser vadas, por causa das interfaces do sistema atual com outros sis temas externos que exijam que as entradas ou as saídas apresen tem formatos prescritos. 665 • Não queremos esse sistema. Esta é uma variação da queixa “vo está querendo tirar meu emprego”. A verdadeira resposta é qi você está ali, conduzindo a entrevista, porque a direção usuái quer o novo sistema. Não é da sua competência convencer usuários operativos que eles devem querer o novo sistema (n importa o quão maravilhoso você considere que ele seja); faz isso é colocar o peso da responsabilidade sobre seus ombr onde ele não deve ficar. • Por que você está desperdiçando nosso tempo com esta enti vista? “Sabemos o que queremos, e se você fosse competem você saberia imediatamente o que queremos. Por que você ni vai em frente e constrói o sistema?” Esta é uma reclamação difi de se lidar, porque relaciona-se com o fato fundamental de qi os usuários e os analistas de sistemas estão falando linguas dif rentes e estranhas; se o usuário não perceber esse fato, ele te grandes problemas. Uma solução possível é fazer uma analogi pergunte ao usuário se ele permitiria que um arquiteto o meçasse a construir-lhe uma casa sem detalhados entendime tos e plantas, seguidos por estreita comunicação durante toda construção da casa. Pergunte ao usuário se ele gostaria de diz’ ao arquiteto: “Construa-me uma bela casa de três quartos. Vo sabe como ela deve ser, não?” Lembre-se, contudo, que com disseminada disponibilidade das linguagens de quarta geração dos computadores pessoais, o usuário pode achar que po construir ele próprio o sistema; sucessos fáceis com projet simples (planilhas eletrônicas, por exemplo) podem ter-lhe d do a impressão de que todos os sistemas são fáceis de impl mentar. Isso pode explicar a impaciência dele
em relação você. E.6
OUTROS PROBLEMAS
As diretrizes acima alertaram-no sobre os inúmeros problemas p líticos com que você pode se defrontar em uma entrevista e os muit motivos pelos quais o usuário pode mostrar-se hostil. Mas ainda existei alguns problemas para os quais você deve estar atento: • Uma discussão que focalize mais os problemas de impleme tação do que os problemas dos requisilos. Isso muitas vezc ocorre quando o usuário diz: “Eis como eu gostaria que voc construísse o sistema...”. Isso acontece quase sempre quando 666 usuário está raciocinando em termos da implementação do sistema atual; e pode acontecer se o usuário conhecer alguma coisa da tecnologia de computadores (ex.: quando ele possui um PC particular ou quando ele é um ex-programador). Lembre- se que não é sua obrigação em uma entrevista de análise des crever características de implementação do sistema a não ser que sejam tão importantes que realmente pertençam ao modelo de implementação do usuário que discutimos no capítulo 21. Confusão entre sintomas e problemas. Isso ocorre em muitas áreas, não apenas na área do processamento de dados. Imagine um paciente que esteja conversando com um médico e diga: «Doutor, meu problema é que meu rosto está quente. O sr. pode resolver esse problema para mim?” É de se presumir que isso seja um sintoma, uma espécie de febre, indicadora de algum tipo de problema médico, O importante é compreender que isso seja um sintoma e não o problema real, e descobrir qual seja esse problema. O mesmo acontece vezes sem conta nas entre vistas de análise de sistemas. Entretanto, boa parte dele depende de onde a fronteira foi estabelecida no diagrama de contexto: se a queixa do usuário é um sintoma ou um problema depende de ela estar associada a alguma coisa dentro dos limites do sis tema ou fora deles. Desse modo, você deve dar especial atenção ao desenvolvimento do modelo ambiental; isso é detalhada- mente discutido no capítulo 18. • O usu4río pode ser incapaz de explicar o que ele quer que o sistema faça ou pode mudar de opinião. Esse é um problema comum e o analista de sistemas deve estar preparado para ele. Quanto maior for esse problema mais importante torna-se a prototipação. Para maiores detalhes sobre a prototipação veja o capítulo 5. • Desentendimento entre usuários de mesmo nível, subordinados e chefes. Infelizmente, isso coloca o analista de sistemas no papel de mediador entre as partes em desentendimento. Como analista, você não pode abdicar desse papel; você não pode dizer: «Quando vocês decidirem o que querem e entrarem em um acordo, procurem-me.” Em vez disso, você deve agir como um negociador conduzindo todos os interessados a
uma sala e trabalhando com eles na tentativa de chegar a um consenso. Isso, infelizmente, envolve habilidades e procedimentos fora do escopo deste livro. 667 E.7 FORMAS ALTERNATIVAS DE COLETA DE DADOS As entrevistas não são o único modo de coletarmos informaçô sobre os requisitos de um sistema. Na realidade, quanto mais inform: ções você puder colher de outras fontes, mais produtivas poderão s suas entrevistas pessoais. Entre as alternativas para as en&evistas.pod mos citar: • Questionários: Você pode remeter questionários escritos para usuários dentro de sua organização, para as pessoas (ou setore que interagem com o sistema, para os diretores que aprovarai o projeto e para outros. • Demonstrações feitas pelos fornecedores. Os fornecedores c hardware e os fornecedores de software podem já haver desei volvido sistemas prontos para a aplicação em que você este interessado. Solicitando-lhes uma demonstração dos recuru desses sistemas pode não somente auxiliá-lo a decidir se o pn duto é uma boa solução, mas também revelar funções e dadc armazenados que você pode não ter percebido. • Vrsitas a outras instalações. Procure outras empresas que est jam no mesmo ramo de atividades ou que tenham sistem semelhantes àquele em que você esteja trabalhando. Combin uma visita à instalação para obter informações diretas sobre características e aptidões do sistema. • Coleta de dados. Procure formulários, relatórios, manuais, pr cedimentos escritos, registros, imagens de tela de terminais e l tagens de programas que já existam na organização usuári: Lembre-se, todavia, que esses recursos normalmente estão rel cionados com a implementação atual do sistema; como vimc no capítulo 18, isso costuma incluir informações redundant e/ou contraditórias e/ou obsoletas. Não obstante, isso muití vezes é um bom ponto de partida para você familiarizar-se coi o terreno antes de iniciar as entrevistas pessoais com o usuári • Pesquisa externa. Se você estiver construindo um sistema p ra uma nova aplicação, para a qual o usuário não dispõe d qualquer experiência para descrever os requisitos, talvez sej necessário tentar obter informações em sociedades profissionai (ACM, IEEE ou DPMA), ou em periódicos e livros técnicos e ei relatórios de pesquisas. 668 E.8 RESUMO
A habilidade de comunicação, a diplomacia e outros aspectos hu manos relativos a entrevistas não são facilmente transmitidos por um li vro. Trata-se de algo que você tem de aprender fazendo ou observando: como analista de sistemas de nível júnior, é uma boa medida acom panhar um veterano para participar de algumas entrevistas que ele reali ze. Além disso, solicite realimentação: peça a seus superiores que des cubram o que os usuários pensam do modo como você está conduzindo suas entrevistas. E ofereça realimentação aos usuários: diga-lhes o que acontecerá com os resultados das entrevistas, para que não pensem que tudo tenha sido uma perda de tempo. REFERÊNCIAS 1. Abraham Maslow, Motivation and Personality. Nova lorque: Harper & Row. 1954. 2. Charles J. Stewart e Cash Stewart, Jntetviewing Principies and Practices, 2’ cd. Dubuque, Iowa: William C. Brown,1978. 3. William S. Davis, Systems Analysis and Design: A Structured Appmach. Reading, Mass.: Addison-Wesley, 1983. NOTAS 1 Tudo isso envolve política organizacional que está fora do escopo deste livro. Para maiores informações, leia um dos livros sobre a teoria gdrencial e organizacional; ou consulte o delicioso livro de Robert Block 7 Poiitics of Projects (Nova lorque: YOURDON Press, 1981). 2 Por que o usuário mudaria de opinião entre uma entrevista e a seguinte? Normalmente porque a entrevista faz com que ele foca lize sua atenção em algo em que até ali ele só pensou de forma vaga. Suas perguntas durante a entrevista podem fazer com que ele veja os requisitos de modo diferente. 669 F ESTUDO DE CASO: A YOURDON PRESS F.1 INTRODUÇÃO Nenhuma discussão sobre análise de sistemas estaria completa sem pelo menos um exemplo ilustrativo das diversas ferramentas de modelagem e técnicas discutidas neste livro. Infelizmente, quase todos os estudos de casos são inteiramente fictícios ou versões extremamente simplificadas e “saneadas” de situações reais. Além disso, é difícil en contrar um exemplo que ilustre uma aplicação tanto comercial como científica. Este estudo de caso descreve os requisitos para a computadoriza ção das atividades de processamento de informações da YOURDON Press. Por um lado, ela é bastante representativa de uma atividade edito rial real que funcionou por aproximadamente 10 anos. Na verdade, uma das coisas que desejo mostrar neste estudo de caso é que nem tudo é feito por motivos racionais (inclusive a formação de empresas e o início de muitos
projetos de desenvolvimento de sistemas!), e que muitos siste mas têm de lidar com muitas “incursões” aborrecidas e desagradáveis no mundo real. Por outro lado, a YOURDON Press agora reuniu-se às fileiras dos exemplos fictícios, uma vez que foi adquirida pela Prentice-Hall em 1986, e suas atividades de processamento de informações subordinaram- se ás da Prentice-Hall Desse modo, este estudo de caso descreve como teriam sido os requisitos de processamento de informações da YOURDON Press, caso ela tivesse continuado como uma editora independente. As seções a seguir apresentam um rápido retrospecto das opera ções da YOURDON Press, o modelo ambiental do sistema, o modelo comportamental e o modelo de implementação do usuário. 671 F.2 ANTECEDENTES Para se entender os trabalhos da YOURDON Press, é necessá gastar algum tempo explicando o Contexto maior da corporação den da qual ela existia: YOURDON inc. Sem a YOURDON inc. não haveri YOURDON Press; embora sem a YOURDON Press, é Claro qu YOURDON inc. não teria alcançado o mesmo sucesso. A YOURDON inc. foi formada como uma extensão de ativida independentes de consultoria e palestras que exerci por alguns anos fins da década de 60 ao início da de 70. A empresa foi formada em ai de 1973 porque meu contador me informou de que uma corporaç oferecia certas vantagens fiscais que não me seriam oferecidas coi consultor autônomo. Não obstante essa orientação prática sobre imp tos, a nova corporação não efetuou de fato qualquer operação antes dia da mentira (primeiro de abril) de 974. Como acontece com a maioria das empresas (e com muitos p jetos de processamento!), uma das primeiras atividades foi criar o noi da empresa. Minha mulher e eu, que éramos os únicos acionistas, di tores, funcionários e empregados, gostamos do nome “Artichokes A Other Fur-Bearing Animals, Inc.”, mas percebemos que não caberia nossa fachada. Por fim, escolhemos o nome “Superprogrammers, Lii ted”, e demos entrada nos papéis no estado de Nova lorque para reí trar o nome. Depois de duas semanas, quando já íamos publicar alg anúncios de nossa primeira série de seminários sobre programação truturada, o órgão competente nos avisou que o nome de nossa empn não tinha sido aprovado: ele era muito parecido com o nome de ou companhia. Ao investigarmos, descobrimos que a outra companhia denominada “Supermarkets Products, Inc. Sem nos desesperarm rapidamente escolhemos um nome que tínhamos uma razoável cert de que não seria cópia de alguma outra: meu próprio nome. Eni nasceu a YOURDON inc. As atividades iniciais da empresa foram seminários profission sobre técnicas avançadas de programação e projeto de sistemas on-li dirigidos a programadores e analistas veteranos de grandes empresa agências do governo. Os seminários compunham-se de cerca de horas de palestras em salas de aula e eram acompanhados por cerca uma centena de páginas de anotações de aulas; as anotações de au relativas ao seminário sobre técnicas avançadas de programação tori ram-se um livro: Techniques of ProRram Struclure and Design, pul cado pela Prentice-Hall em 1975.
Face ao grande número de participantes do seminário, tornou econômico imprimir as anotações de aulas em um volume modera& encadernar as páginas; desse modo, elas assumiram uma certa semelk ça com um livro, embora algumas páginas estivessem impressas 672 cabeça para baixo e outras caíssem do livro à menor provocação. Apesar disso, alguns dos participantes solicitaram a compra de cópias adicionais das notas de aula, e, dessa forma, como atividade paralela, a YOURDON inc. entrou no negócio de venda de “livros”. Entretanto, a YOURDON inc. ocupava-se principalmente em ativi dades de treinamento: o número de cursos de treinamento distintos cres ceu para aproximadamente 50 pelos meados dos anos 80, e a empresa atualmente já treinou cerca de 250.000 profissionais de processamento de dados nos Estados Unidos e em 30 outros países. As atividades de consultoria profissional também começaram a se expandir e muitos dos membros técnicos da companhia agora trabalham como consultores, lideres de projetos e analistas de sistemas em importantes projetos de desenvolvimento de sistemas na América do Norte e ria Europa. E em meados da década de 80, a empresa ingressou no mercado CASE, com um produto tipo caixa de ferramentas para analistas do tipo descrito no apêndice A. Em 1987, a YOURDON inc. possuía escritórios em 8 cidades, com uma equipe de aproximadamente 150 pessoas. A YOURDON Press começou como uma divisão da YOURDON inc. em 1976 com a publicação em brochura de três livros: Structured Design, por Yourdon e Constantine; Learning lo Program in Stru.ctured COBO4 por Yourdon, Gane e Sarson; e How To Manage Slructured Pro gramming, de Yourdon. Assim como em tantas outras operações co mercias, isso ocorreu sem muito planejamento ou preocupações de orga nização: os livros pareciam ser uma boa maneira de popularizar os con ceitos das técnicas estruturadas desenvolvidas e comercializadas nos se minários da YOURDON inc. Os três primeiros livros foram produzidos em uma simples máqui na de escrever IBM Selectric e preparados em folhas de 8.5 por 11 po legadas; tudo isso precedeu os dias da impressão e editoração adequa da. A publicidade era bastante modesta, consistindo apenas em uns poucos anúncios na Computerworld e remessas para a lista de clientes dos seminários da YOURDON. As véndas eram igualmente modestas; na verdade, nos primeiros anos de sua existência, a YOURDON Press re presentava somente uma pequena fração dos rendimentos gerais da empresa. Em conseqüência, o sistema de informações que englobava as itil dais atividades da YOURDON Press era pequeno e manual em sua natu reza. Os pedidos eram recebidos pelo telefone ou pelo correio, mas pedidos por cartões de crédito não eram aceitos. As faturas eram datilo grafas à mão em formulários de fatura em quatro vias e os pedidos eram manualmente empacotados um a um. O material era armazenado em um dos mais elegantes espaços de armazenamento do mundo: os escritórios envidraçados do 38 andar da YOURDON inc. na Avenue of the Ameri cas, 1133, com vista para toda Manhattan. 673 A automatização chegou à YOURDON inc. na primavera de 19; na forma de um
minicomputador PDP-I1/45, de segunda mão, e u misterioso sistema operacional chamado UNIX . Poucos meses mais t de, uma fotocompositora, duas dúzias de terminais e o pacote TROFF composição foram acrescentados. Isso facilitou imediatamente a prod çào, em composição, de livros da YOURDON Press e terminou por co duzir à automatização de diversos aspectos das atividades de treiname to e de contabilidade geral da YOURDON inc. Porém as atividades o racionais da YOURDON Press, aquelas que poderiam ser considerad como um sistema de informações”, continuaram a funcionar de mo manual por mais alguns anos. Em 1980, um número limitado de aplicações computadorizadas 1 desenvolvido para a YOURDON Press, com utilização dos práticos reci. sos de canalização do sistema operacional UNIX. Entre 1980 e 1985, linguagem de programação C e alguns shell scriprs do UNIX foram uti zados para acrescentar gradualmente alguns programas simples pa processamento de pedidos, relatórios de vendas, rótulos de embarque diversos relatórios contábeis. Embora esses programas fossem fáceis serem desenvolvidos e de operação razoavelmente confiável, eles fora desenvolvidos a retalho, de modo semelhante ao que se vê muitas vez hoje em uma organização de PED, onde os usuários têm acesso a piar lhas eletrônicas, geradores de relatórios e linguagens de programação quarta geração. Eles também eram um pouco limitados; por exemplo, os detalhes de um pedido precisassem ser modificados após sua entrad o sistema não podia fazer isso. O editor de texto padrão do UNIX e utilizado para fazer a modificação, que estava armazenada no comp tador como um simples texto ASCII, finalizado por um caracter fim-de-linha. Uma das mais dificeis atividades da operação diária da YOURDC Press era a tarefa de produzir uma informação atualizada mosiran todos os pedidos, pagamentos, devoluções de livros e créditos de u cliente relativos a um determinado período. Igualmente dificil era o pr cesso de conciliar essas atividades (que ocorriam como interações ent os clientes e o pessoal administrativo da YOURDON Press) com registros financeiros mantidos pelo setor de contabilidade da YOURDC inc. Por diversos motivos, a YOURDON Press e o Departamento Contabilidade sempre pareceram estar “fora de sincronia” entre si. Is tornava-se mais complicado pelo fato de que o escritório da YOURDO inc. em Londres tinha seu próprio inventário de livros e fazia sei próprios embarques e seu faturamento de maneira independente do e critório de Nova lorque; os preços eram estipulados em libras esterlin em vez de dólares e geralmente eram um pouco mais elevados que preços estabelecidos pelo escritório de Nova Iorque . A cada trimestr quando tinham de ser preparados os documentos financeiros, era; 674 realizadas longas, frustrantes e entorpecedoras reuniões em que os rela tórios impressos em computador do Departamento de Contabilidade eram comparados manualmente com os emitidos pela YOURDON Press para que as diferenças fossem conciliadas. Os ânimos explodiam; grita vam-se insultos, obscenidades e diversos epítetos reciprocamente; ás vezes voavam objetos em todas as direções. Não era uma atividade agra d.ável para se esperar a cada trimestre. Desse modo, por volta de 1986, era evidente que teria de ser de senvolvido um completo sistema para que a YOURDON Press pudesse continuar crescendo; foi então iniciado o planejamento do novo sistema. Contudo, também era evidente que seria necessário um
vultoso volume de capital para continuar a ampliação dos negócios, não somente para o equipamento adicional de computação, mas também para modernizar o equipamento de composição (que já estava obsoleto) e aumentar as atividades editoriais e comerciais da divisão. Por fim, decidiu-se que seria mais sensato permitir que as atividades editoriais fossem adquiridas por uma empresa maior, o que conduziu á fusão com a Prentice-Hall. Assim, os modelos de sistema descritos a seguir representam o que os requisitos seriam se a YOURDON Prcss continuasse a funcionar como empresa independente. O planejamento do novo sistema de informações também coincidiu com uma série de mudanças organizacionais na YOURDON Press e no restante da YOURDON inc. De sua origem em 1974 a aproxima damente 1983, a empresa utilizava a estrutura organizacional mostrada na figura F.1 Entre 1984 e 1986, a companhia adotou uma organização mais regional e acrescentou uma nova divisão para seus produtos de software, como se vê na figura F.2. ?ndas & rcializaçã Figura F.1: Est organizacional da YOURDON inc., 1974-1983 1 675 A Soft ware Figura F.2: Estrutura or da YO(JRDON inc., 1ÇÀS E, durante esse período, a YOURI)ON Prc gradativamcnte desenvolve a estrutura organizacional mostrada na figura F.3. Como parte dessa reorganização, as operações de remessa c YOURDON Press mudaramse das elegantes acomodações ocupada pelo resto da equipe para um depósito cm Yonkcrs, Nova lorque. Des forma, havia uma separação física dc umas 20 milhas entre as pesso que davam entrada a pedidos e as que embalavam livros em caixas remetiam os pedidos aos clientes. Os quatro grupos principais da YOURI)ON Prcss tinham as seguir tes responsabilidades: • Serviços administrativos responsabilizava-se pela maioria da interações diárias entre a YOURI)ON Press e os clientes. Dc se modo, esse grupo recebia pedidos; emitia faturas; recebi Figura F.3: Estrutura organizacional da YOURDON Press 676 pagamentos; discutia devoluções de livros e créditos com os clientes; interagia com o
depósito quanto a remessas de livros; e também entendia-se com o Departamento de Contabilidade, como já foi mencionado. Vendas e comercialização era responsável pela produção de catálogos dos diversos livros da YOURDON Press; colocando anúncios em revistas sobre computadores e jornais de negócios; enviando folhetos promocionais a várias listas postais; e propon do vendas via telefone a grandes compradores de livros técnicos de computação. • Aquisições era responsável pela procura de novos autores e no vos livros. Esse setor da YOURDON Press encarregava-se de to dos os contatos com os autores até o momento da entrega do manuscrito final. • Editorial era encarregada de receber o manuscrito final e trans formá-lo em um livro publicado. Isso não só envolvia a copiedi ção do livro, mas também entendimentos com gráficas visando propostas das versões iniciais do livro. Editorial responsabiliza va-se também pelo acabamento artístico e produção da capa e do conteúdo. Deve-se lembrar que a YOURIX)N Press era um estabelecimento bastante pequeno em comparação com outras editoras conhecidas como McGraw-Hill, Harcourt-Brace, Prentice-Hall e Random House. Pode-se ter uma idéia da çscala do empreendimento examinando-se os seguintes dados estatísticos: • A YOURDON Press tinha aproximadamente 50 livros em sua lista; cerca de 4 a 6 novos títulos eram incluídos à lista a cada ano. • Os livros eram escritos por cerca de duas dúzias de autores, e o grupo da aquisição tratava com aproximadamente 200 poten ciais autores, isto é, pessoas que demonstravam interesse em •escrever um livro, mas que de fato ainda não tinham nada escrito. • A YOURDON Press processava em torno de 50 pedidos por dia. • O valor médio de um pedido girava em torno de $100, que nor malmente representava três ou quatro livros. Alguns pedidos, 677 naturalmente, eram de apenas um livro; outros eram maiore Havia grandes celebrações sempre que aparecia um pedid superior a $5.000. • Eram despachados cerca de 50.000 livros por ano. Malgrado a pequena escala, a YOURDON Press funcionava d modo muito semelhante ao das grandes editoras. As vendas eram feita via pedidos escritos, por telefone, ou diretamente (isto é, um cliente qu entrava nos escritórios da YOURDON inc./YOURDON Press para corr prar um livro). Os pagamentos podiam ser efetuados a dinheiro (o qu era raro), por cheque ou por cartão de crédito. Como questão de norm; os pedidos inferiores a $100 tinham de ser pagos antecipadamen os pedidos grandes, principalmente os de livrarias e empresas, norma mente exigiam fatura. Para entender as operações de uma editora, é preciso conhecer conceito de devoluções. Se um cliente individual ou uma corporaçã chegasse à conclusão de que um livro não se
adequava a suas necessid des ou que tinha sido danificado na remessa, geralmente devolviam livro e solicitavam um reembolso. Isso ocorria normalmente dentro d alguns dias depois que a remessa tivesse sido recebida pelo cliente. A livrarias, por outro lado, tinham o privilégio de devolver até a metad dos livros de um pedido no prazo de um ano a partir da data de cntrad do pedido; isso é normal na indústria editorial, porque as livrarias muita vezes não sabem de antemão qual será a demanda por um livro e quc rem evitar encalhes de estoque que não conseguem vender. F.3
O MODELO AMBIENTAL
F.3. 1 A Declaração de Objetivos O objetivo do YOURDON Press lnformauon System (YPIS) é mar ter informações necessárias à venda de livros a clientes. Isso inclui entra da de pedidos, faturamento, geração de documentos de remessas, cor trole de inventário e produção de relatórios sobre direitos autorais relatórios contábeis. 678 F.3.2 O Diagrama de Contexto Figura F.4: Diagrama de Contexto do sistema YPJS F.3.3 A Lista de Eventos A lista de eventos do YPIS compõe-se de 40 eventos. A maioria deles é dirigida pelo fluxo, embora a maior parte dos eventos relativos ao Departamento de Contabilidade seja periódica. Os eventos são rela cionados a seguir; os eventos periódicos estão marcados com um T após a descrição do evento. 1. Cliente pede livro (isso também inclui pedidos urgentes). 2. Cliente envia pagamento. 3. Cliénte solicita informações sobre livros (preço etc.). 4. Cliente solicita permissão para restituir um livro. 5. Cliente indaga a situação de um pedido de livros. 6. Cliente indaga a situação de uma fatura. 679 7.
Cliente necessita da posição (mensal). (1)
8.
Cliente solicita crédito.
9.
Cliente quer cheque de reembolso.
10.
Contabilidade precisa (diariamente) da receita em dinheiro. (T)
11.
Contabilidade precisa (diariamente) do relatório de receita. (1)
12. Contabilidade precisa (mensalmente) do relatório da receita líqu da. (1) 13. Contabilidade precisa (trimestralmente) do relatório de direit( autorais dos autores. (T)
14.
Contabilidade precisa (mensalmente) dos dados de inventário. O
15. Contabilidade precisa (mensalmente) do relatório de comissões c vendas. Ç 16. A Direção estabelece novo limite de crédito para um cliente. 17. Contabilidade precisa (mensalmente) do relatório de contas a rec ber atrasadas. (D 18. Gráfica apresenta cotação para pedido dc impressão (ou reimpre sã o). 19.
Direção autoriza um pedido de impressão.
20.
Gráfica informa quantidade exata de impressão e data de entrega
21.
Gráfica remete fatura de impressão.
22.
Direção solicita cotação de pedido de impressão.
23. Comercialização solicita etiquetas postais do banco de dados d clientes. 680 24. Comercialização precisa de estatísticas de vendas de livros. 25. Comercialização precisa data de entrada em estoque de novos títulos. 26. Editores anunciam novo título de livro (data de prontificação gráfica). 27. Autores precisam de relatórios de direitos autorais trimestrais. (D 28. Depósito precisa de dados para remessas e etiquetas postais. (1) 29. Depósito recebe livros da gráfica. 30. Depósito recebe devoluções de livros de cliente. 31. Depósito realiza (mensalmente) inventário fisico. 32. Depósito remete pedido de livros para cliente. 33. Depósito anuncia que um livro está em falta no estoque. 34. O Departamento de Aquisições anuncia o projeto de um novo livro. 35. Vendedor apresenta pedido cm nome de cliente. 36. Comercialização declara que um livro não é mais impresso. 37. Cliente informa mudança de endereço. 38. Autor informa mudança de endereço. 39. Cliente dcre ao plano da agência. 40. Fatura precisa ser rcmcUda para cliente. (1) 681 F.4
O MODELO COMPORTAMENTAL
F.4. 1 O Modelo Comportamental Preliminar: Diagramas de Fluxo de Dados Cada um dos 40 eventos listados na seção F.3.3 tem um diagraír de fluxo de dados
associado. É claro que a atividade de impressão de ui livro torna impossível, para dizer o mínimo, interligar todos os 40 diagr; mas em um único diagrama composto representando todo o sistem Como ressaltamos no capítulo 19, esse é o tipo de exercício que exi uma folha de papel muito grande - ou várias folhas pequenas colada Deixo isso como exercício para o leitor. Os diagramas foram desenhados com a Versão 2.0 do pacote d software Design, da Meta Systems Inc., dc Cambridge, Mass. Embora nã seja uma completa caixa de ferramentas CASE, ele é mais sofisticado qu a maioria dos pacotes gráficos simples; e tem a vantagem de funcion; em um computador Macintosh, que foi utilizado na preparação des livro. Para acomodar o programa Dcsign, apresentei os depósitos nc DFD com a notação vista na figura F.5. [ NOMEDODEPÓSIT Figura F.5: Notação de depósitos no estudo de caso da YOURDON Press Ao desenhar os DFD preliminares, tomei nota dos erros que encor trei e das modificações que percebi que precisavam ser feitas em outra partes do modelo; essas notas estão relacionadas abaixo dc cada DFD. motivo para isso é enfatizar que em um projeto do mundo real o analist de sistemas raramente desenha um DFD perfeito da primeira vez; ap pensar sobre o sistema e depois de continuas entrevistas com o usuáric é inevitável que se descubram erros no DFD cm exame ou em algum outra parte do modelo do sistema. Não foi feita qualquer tentativa de criar um dicionário de dadc organizado durante o desenvolvimento do modelo comportament preliminar. Após a criação do modelo dc DFD inicial, foram esboçada as especificações de processo para verificar se havia algum erro evider te; muitos desses erros aparecem como comentário3 nas páginas seguir tes. Em seguida foi criado um conjunto dc DFI) cm níveis, sendo tarr bém desenvolvido o dicionário dc dados. 682 Notas Depois de desenhar a primeira versão deste diagrama, lembrei-me que os pedidos em cartão de crédito normalmente exigem uma autorização se o valor estiver acima de um certo limite. A YOURDON Press aceitava pedidos pagos pelo Mastercard, Visa e American Express, daí a interface com o terminador “AGÊNCIAS DE CRÉDITO’. 2. Um pouco mais de raciocínio sobre a situação de crédito eviden ciou que a definição de cliente no depósito CLIENTES teria de incluir o campo limite-de-crédito. Ficou também evidente que havia a necessidade de um evento para mudar o limite de crédito do cliente (evento 16) que antes não tinha sido percebida. 3. Observe que os pedidos não são despachados na modalidade de um por vez, com a exceção dos pedidos urgentes. Os detalhes de um pedido urgente são enviados imediatamente para o Depósito; todos os outros pedidos são simplesmente armazenados no depósi to PEDIDOS. Como um evento separado (evento 28), o Depósito 683 Evento 1: Cliente pede livro
recebe etiquetas postais e instruções de embarque para um grup de pedidos (normalmente os pedidos de um dia). Esqueci-me dc pedidos urgentes na versão inicial do diagrama. 4. Quando estava desenhando este diagrama, percebi também a n cessidade de um depósito ARQUIVOS, que é uma cópia do pedid original do cliente (ou, no caso de pedido por telefone, uma cóp do formulário do vendedor), mais uma cópia da fatura gerada pai o pedido. A cópia da fatura não é necessária em um modelo esse cia! (uma vez que pode ser regerada), mas os outros documentc são necessários no caso de uma dúvida posterior com o cliente, no caso de auditorias ou investigações das autoridades fiscais etc 5. Perceba que os pedidos podem ser recebidos pelo correio, p telefone ou pessoalmente. Não mostramos isso no DFD acima, uni vez que são funções transportadoras. 6. Observe que o sistema não renova pedidos de livros da gráfic automaticamente. Em vez disso, a direção é informada nas diversa ocasiões em que o inventário caiu abaixo de um limite preestabek cido. Isso pode ocorrer como resultado do evento 1, bem como d diversos outros eventos. 7. Os pedidos podem ser recebidos de novos clientes (principalmeni novas livrarias ou empresas que encetarão contínuos negócios coi a YOURDON Press). Assim, um novo registro terá de ser criado e: CLIENTES com a taxa de desconto padrão etc. Esta é a razão d seta de duas pontas entre a bolha 1 e o depósito CLIENTES. 684 Evento 2: Cliente envia pagamento. Notas O pagamento pode ser referente a várias faturas diferentes, mas nem sempre é evidente que fatura(s) está (estão) incluída(s). Às ve zes os clientes não identificam a fatura que está sendo paga; al gumas vezes eles identificam faturas que já foram pagas e às vezes citam números de faturas inexistentes. 2. Às vezes não fica bem definido dc onde vem o pagamento. Isso vale principalmente para as cadeias dc livrarias: a livraria XYZ na cidade A pode pertencer a um conglomerado, PQR, na cidade B. Se um cheque qualquer, oriundo da PQR Corp., chegar endereçado à YOURDON Prcss, podemos não conseguir identificar a fatura e até a empresa envolvida. Pagamentos desse tipo são incluídos em uma categoria contábil denominada dinheiro não aplicado. A pressupo sição é a de que se continuarmos remetendo faturas atrasadas para a livraria XYZ eles informarão que a fatura foi paga pela PQR. 3 Nada garante que o pagamento corresponda ao valor exato da fa Alguns pagamentos são maiores ou menores por uma pe quena importância aleatória. Alguns clientes tentam não pagar os impostos sobre vendas ou as taxas dc remessa; isso costuma resul tar em pagamentos inferiores em um ou dois dólares ao valor devido. 685
ID-de-cl lente + Evento 3: Cliente solicita informações sobre livros. Notas 1. O cliente geralmente indaga coisas como o preço de um livro, o quando um novo livro deverá estar em estoque, ou a tabela d desconto por volume. 686 + consulta resposta-de informação-de-livro Notas 1. Os clientes devem obter permissão da YOtJRI)ON Press antes cc restituir livros. Eles nunca o fazem. 2. As devoluções reais chegam mais tarde e podem ou não coincidir com a devolução pretendida e que havia sido autorizada. 3. Observe que uma devolução solicitada tem que ser comparada com o pedido original. Evento 4: Cliente solicita permissão para restituir um livro. D-de-cliente + solicitação-de-devoluçáo Notas 1. A remessa de um pedido de cliente pode ser retardada por caus da demanda no depósito ou por falta de estoque do livro. É a pc tencial demora que provoca a consulta do cliente. 2. Se o cliente resolver cancelar o pedido nesse momento, isso considerado como um evento à parte. 3. Outra possibilidade é que o pedido não tenha sido recebido n YOURDON Press (ou por extravio pelos Correios ou em algur lugar na sala de despachos do escritório do cliente ou d; YOURDON Press). 4. O pedido pode ter sido recebido na YOURDON Press e processa do; na realidade pode ser até que o depósito tenha remetido pedido, mas ele tenha sido extraviado pelos Correios (ou po outra agência de entregas) no caminho até o usuário. Esse caso tratado do mesmo modo (ex.: o usuário pode resolver cancelar pedido nesse momento ou solicitar um crédito e entregar o pcdid novamente). 5. Enquanto eslava preparando este I)Fl), percebi que as faturas nàc eram enviadas para o cliente (o despacho dos livros pci 688 Evento 5: Cliente indaga a situação de um pedido de livros.
resposta-de ID-de-depósito + nade fatura + de-pedido ID-de-cliente + consulta-dedepósito(almoxarifado) e o envio da fatura pelo escritório central da YOURDON Press são dois eventos distintos). Assim, precisamos de um depósito separado para faturas e um evento periódico para fazer com que as faturas sejam remetidas. Evento 6: Cliente indaga sobre a situação de uma fatura. Notas 1. A pergunta do cliente pode ser relativa à taxa de desconto que foi cotada na fatura, ou às taxas de remessa, impostos sobre vendas ou outros detalhes da fatura. 2. Se o usuário fizer uma indagação mais geral sobre todos os seus pedidos, pagamentos e coisas assim, o evento 7 é a parte do siste ma que cuida do assunto. 3. Para este evento é necessário um número-de-fatura para que se possa recuperar informações sobre o pedido (número-de-fatura é um componente de consulta-sobrefatura, como será visto no dicionário de dados). 689 Evento 7: Cliente necessita da posição (mensalmente). Notas 1. Enquanto trabalhava neste DFD, descobri a ncccssidadc dc u evento para permitir que o cliente solicitasse um crédito (evento 8 2. Observe que este evento é periódico (isto é, as posições são gcn das regularmente, uma vez por mês). 690 Evento 8: Cliente solicita crédito. Notas 1. O cliente pode receber um crédito por diversos motivos: • Um erro no pedido original (o cliente pode ter recebido um des conto errado ou ter sido cobrado um preço errado etc). • O cliente recebeu mercadoria danificada (ex.: os livros foram rasgados pelo correio). • O cliente recebeu uma remessa menor do que deveria por causa de um erro do depósito. Então ele deseja um crédito pelos livros não recebidos, em lugar de receber os livros que faltaram. • O cliente pagou a mais por uma ou mais faturas anteriores e só agora descobriu o fato (normalmente o pagamento excessi vo tornar-se-ia evidente quando ele recebesse sua posição seguinte). 691
ID-de depósito + n de fatura + notificação-de-não-remessa solicitação-de-aut-de-crédito/ resposta-de-a ut-de-créd ito ‘1 houve uma excessiva demora na remessa, de modo que o clier te resolveu cancelar o pedido. 2. A tarefa principal desta bolha é atualizar a situação do crédito d cliente. 3. Entretanto, observe que a direção pode autorizar o crédito. Fst evento foi desenhado para retratar uma imediata resposta da dirc ção, de forma a que uma resposta possa ser dada ao cliente. lss evita um depósito “pendente” dc solicitações de auiorizações d crédito, que, de outra forma, seria necessário. 4. Observe que esta atividade nada tem a ver com devoluções d livros, que são tratadas separadamente. Evento 9: Cliente quer cheque de reembolso. resposta-de
solicitação-de cheque
reembolso
de-reembolso
Notas 1. Nada há a opor se o cliente realmente necessita de um acerto d crédito. Na maioria dos casos, o cliente aplicará um crédito suplc mentar em futuras compras. Entretanto, por vezes ele quer un cheque, ou porque não pretenda fazer qualquer compra futura oi por algum outro motivo. 692 Evento 10: Contabilidade precisa (diariamente) da receita em dinheiro. Evento 11: Contabilidade precisa (diariamente) do relatório da receita. dinheiro + relatório-de-caixa relatório da - receita - diária 693 Evento 12: Contabilidade precisa (mensalmente) do relatório da receita líquida. 694 relatórios-da-receita Evento 13: Contabilidade precisa (trimestralmente) do relatório de direitos autorais dos autores. Notas
1. Precisamos ter acesso ao depósito LIVROS para obtermos a taxa de direitos do autor do livro (o mesmo autor pode ter taxas diferentes de direitos para livros diferentes). 2. Precisamos ter acesso ao depósito AUTORES para obtermos o número do Seguro Social do autor, seu endereço etc. 3 Também precisamos ter acesso ao depósito LIVROS para vermos se existe algum adiantamento pendente (que pode ter sido con cedido como resultado do evento 34) e para atualizá-lo para refletir os direitos cumulativos presentemente devidos. 4. Observe que os direitos relativos a qualquer período podem ser negativos se as devoluções de livros relativas àquele período exce derem o número de novos livros pedidos. 695 5. Precisamos do depósito PEDIDOS porque a contabilidade quc detalhes sobre quem comprou os livros. Não precisamos disso n evento 27. Evento 14: Contabilidade precisa (mensalmente) dos dados de inventário. relatório de inventário Notas 1. O inventário é atualizado dc forma não sincronizada em decoi rência de pedidos, devoluções, recebimento dc novas remessas d gráfica e de inventários flsicos. 2. Observe que este relatório mostra livros que foram pedidos, ma que podem não ter sido remetidos pelos depósitos. Ele não corrc ponderia necessariamente a um inventário fisico feito simultanca mente em virtude do duto dc pedidos que foram processados ma ainda não tenham sido remetidos. 696 Notas 1. Presume-se que os vendedores recebem uma comissão mesmo que o cliente não tenha pago pelo pedido. É ignorado o problema real de restituir a comissão se o cliente nunca vier a pagar pelo pedido e a fatura correspondente tenha que ser anulada. 2. Observe que muitas vendas não estão associadas a um determina do vendedor; os pedidos são recebidos, sem serem solicitados, em decorrência de campanhas postais diretas, revistas sobre processa mento de dados, e coisas semelhantes. 3. Este modelo também pressupõe que todos os vendedores recebem a mesma taxa de comissão, e que a comissão é a mesma para todos os livros. Entretanto, a taxa dc
comissão pode ser alterada pela di.reção a cada vez que este evento ocorre. 4. O modelo também presume que temos dc mostrar os delalbes do pedido aos vendedores, porque (sendo eles típicos vendedores paranóicos) eles não acreditam no computador. 697 Evento 15: Contabilidade precisa (mensalmente) do relatório de comissões de vendas. relatório de Um ite-de-cródito Evento 16: Direção estabelece novo limite de crédito para um cliente. Notas 1. A direção pode decidir alterar o limite de crédito de um cliente p uma série de razões, das quais a mais comum é o demorado pag mento de faturas anteriores. Entretanto, também pode ocorrer p* motivo de falência do cliente ou se a direção perceber que condições gerais do mercado se modificaram. 698 Evento 17: Contabilidade precisa (mensalmente) do relatório de contas a receber atrasadas. 699 Evento 18: Gráfica apresenta cotação para pedido de impressão (ou de reimpressão). Notas 1. Observe que o sistema não processa a cotação da gráfica; ela simplesmente passada para a í 2. Como o sistema não faz qualquer processamento, não fica eviden ciado porque esse evento deva ocorrer (por outro lado, pode-s objetar que o sistema tem a responsabilidade de servir como con duto, ou interface, entre as gráficas externas e a direção d YOURDON Press). De qualquer forma, isto permite a futura possi bilidade de o sistema fazer pedidos automaticamente, com base en critérios preestabelecidos. 700 Evento 19: Direção autoriza um pedido de impressão. código-de-livro + quantidade-pedida + data-de-disponibilidade 701 Evento 20: Gráfica informa quantidade exata de impressão e data de entrega. Notas
1. A contabilidade precisa das informações de pedidos de livros revis tos para poder controlar os custos unitários. Isso, em combinaçãc com o evento 14, permite que a contabilidade controle o valor dc inventário na modalidade FIFO (primeiro a entrar primeiro a sair). 2. Observe que isso pressupõe que a gráfica não faz modificações importantes em sua cotação original. Na prática, a gráfica imprime uma quantidade menor ou maior que a originalmente prevista em cerca de 1 a 2% (ex.; um pedido de impressão de 2.000 cópias de um livro pode resultar na impressão de 2.037 livros). Normalmente, a gráfica também aguarda até esse momento para cotar a remessa e outras alterações. 702 ID-de-gráfica + pedido-de-impressãoEvento 21: Gráfica envia fatura de impressão. Notas 1. Este diagrama pressupõe que a direção atenderá à fatura da gráfica imediatamente. Observe que o YPIS não produz um cheque - apenas informa à contabilidade que deve ser emitido um cheque. 2. Este modelo também pressupõe que haverá uma fatura separada para cada pedido de impressão e também que haverá somente um pedido de impressão pendente em cada momento. 3. ‘Observe que o faturamento ocorre de forma não sincronizada com a remessa dos livros pela gráfica. Como um evento em sepa rado, o depósito informa ao sistema que os livros foram recebidos da gráfica. 4. Presume-se também que o valor da fatura é igual ao que foi apre sentado na estimativa revista (evento 20). 703 fatura-de-gráfica aprovada código-de-livro + quantidade + Notas 1. Observe que geralmente são consultadas diversas gráficas para quc se obtenha várias cotações de preços. Essas cotações são recebida como um evento assíncrono, e cada cotação é enviada para a dire ção (evento 18). 2. Observe que as gráficas não respondem com a cotação de imedia to; contudo, presumese que eventualmente o farão. 704 5. Observe que algumas gráficas insistem em um pagamento parcia adiantado sobre faturas; este modelo não leva isso en consideração. Evento 22: Direção solicita cotação de pedido de impressão. solicitação-de cotação
{quantida Evento 23: Comercialização solicita etiquetas postais do banco de dados de clientes. etiquetas-postais solicitação-de etiquetas 705 Evento 24: Comercia1izaç precisa de estatísticas de vendas de livros. Evento 25: Comercialização precisa de dados de entrada em estoque de novos títulos. 706 Evento 26: Editores anunciam novo título de livro (data de prontificação gráfica). Notas 1. Enquanto deseLlvolvia este modelo, percebi a necessidade de oca sionalmente suprimir livros do sistema. Isso raramente acontece, mas a comercialização vez por outra decide «matar» um livro decla rando-o fora de impressão (evento 36). 2. Embora este evento realmente crie um novo registro livro (o livro não é considerado real e fazendo parte do sistema até que os editores tenham terminado de editá-lo e estejam prestes a enviá-lo para uma gráfica), precisamos criar também um registro autor. Isso é feito pelo evento 34. 707 Notas 1. Este evento é semelhante ao evento 13, exceto pelo fato de o rei tório ser entregue aos autores e não à contabilidade. 2. Observe que a contabilidade quer ver informações detalhadas, ii duindo a identificação dos clientes a quem foi vendido um livr Essa informação não é dada aos autores. 708 Evento 27: Autores precisam de relatórios trimestrais de direitos autorais. relatório trimestral- de-direitos L IIUb Evento 28: Depósito precisa de dados de remessas e etiquetas postais. 709 Evento 29: Depósito recebe livro da gráfica. Notas 1. Não é levada em consideração a possibilidade de uma remess parcial da gráfica. Isso acontece ocasionalmente: se houver um demanda fora do comum por um novo livro (Ou pela reimpressã de um livro já existente), a gráfica pode acelerar a entrega da primeiras centenas de cópias (talvez por via aérea) e remeter restante do pedido de impressão
posteriormente. 2. Este modelo também presume que o volume recebido pelo depósi to seja igual ao especificado no evento 20. 710 Evento 30: Depósito recebe livros de cliente. Notas 1. O sistema pode instruir o depósito a recusar devoluções de livros que não tenham sido autorizadas. Isso significa que o depósito de verá notificar os Correios (ou a empresa que efetuou a remessa) que os pacotes deverão ser devolvidos ao remetente. 2. Observe que às vezes é impossível saber quem está fazendo a devolução; isto é, as informações encontradas nos pacotes de livros podem não corresponder a qualquer cliente. 711 Evento 31: Depósito realiza (mensalmente) inventário físico. 712 ID-de-depósito + contagem-física LIENS.OE Evento 32: Depósito remete pedido de livros para cliente. Nota 1. Presume-se que não haja remessas parciais relativas a um pedido. 713 Evento 33: Depósito anuncia que um livro está em falta no estoque. Notas 1. Observe que a situação de falta de estoque pode ocorrer ou causa de um pedido de reimpressão que ainda não foi recebido, em decorrência de um pedido inesperadamente grande ou p furtos ocorridos no depósito etc. 2. Em conseqüência da situação de falta em estoque, os pedidos pr cessados subseqüentemente podem não ser atendidos por compi to, mas isso é problema do depósito. 714 ID-de-depósito + titulo-de-livro + fora-de-estoque Notas 1. Este diagrama mostra que o evento 13 deve ler o depósito LIVROS para verificar se
existe algum adiantamento pendente. 2. Este evento também cria um novo registro de autor caso se trate de um novo autor. 715 Evento 34: O departamento de aquisições anuncia o projeto de um novo livro. Evento 35: Vendedor apresenta pedido em nome de cliente. Notas 1. Observe que este evento é igual ao evento 1, exceto pelo fato que o pedido é apresentado por um vendedor em lugar do client 716 1.Evento 36: Comercialização declara que um livro não será mais impresso. Notas 1. Isso pode ser executado externamente pela simples suspensão de toda a publicidade em torno de um determinado livro. Em algum momento não mais haverá pedidos dele. 2. Quando executado como aqui mostrado, ele impede novos pedi dos. Supõe-se que os depósitos eliminarão o estoque remanescente para abrir espaço de armazenamento. 3. Em situações reais, são tomadas medidas para “liquidar” o estoque existente do livro. Pode-se vender o estoque remanescente ao autor ou a uma livraria que vende com descontos por, digamos, $O.1O o exemplar. 4. bbserve que o registro livro não pode ser eliminado de LIVROS pelo menos até que tenham sido emitidos o relatório contábil mensal e a relação trimestral de direitos amorais. Além disso, pode ainda haver pedidos pendentes que ainda não tenham sido despa chados pelo depósito. 717 5. Observe que todos os depósitos precisam ser informados da occ rência desse evento. 6. Nesta altura, estamos pressupondo que não há pedidos pendent na gráfica: se as vendas foram insatisfatórias ao ponto de retirarm o livro de impressão, é virtualmente impossível imaginar que teni sido emitido um pedido de reimpressão. Evento 37: Cliente informa mudança de endereço. 718 Evento 38: Autor informa mudança de endereço. 719 Evento 39: Cliente adere ao plano da agência. Notas
1. O plano da agência é conhecido por diversos nomes na área edit rial (ex.: “plano padrão dc remessas”, “plano garantido de remc sas”, “plano permanente de pedidos” etc.). Ele é utilizado qua’ que exc por livrarias. A livraria apresenta um pedi inicial de uma certa quantidade de livros e concorda em aceitar u certo número de cópias de cada novo livro que a YOURDON Pre publicar. 720 ID-de-cliente + resposta-a-plano da-agência Evento 40: Fatura precisa ser remetida para cliente. 721 F.4.2 O MODELO COMPORTAMENTAL FINAL: DIAGRAMAS DE FLUXO DE DADOS O modelo comportamental inicial mostrado nas últimas páginas transformado em um conjunto de DFD subdividido em níveis. A sub visão em níveis ascendentes produziu o diagrama de figura 1 mostra4 na página seguinte; ele é tão complexo que não mostrei os detalhes todas as entradas e saídas de todas as bolhas. As figuras subseqüeni mostrarão quais eventos foram agrupados. Em um dos casos, um ever isolado (o evento 26) não foi subdividido em níveis ascendentes, aparece como o processo 5 na figura 1. Em um outro caso (evento 1) necessária uma adicional subdivisão descendente por causa da coi plexidade do processamento. 722 Figura O: O DFD de nível mais elevado 723 entrada-de-
saídas-de
gráficas 724 Figura 1: Processar ped idos Figura 1.1: Processar pedido 725 baixo 726 Figura 2: Gerenciar clientes Figura 3: Produzir relatórios contábeis 727 728 Figura 4: Gerenciar gráficas
código-de etiquetas.postais LIVRO resposta-deFigura 6: Interagir com comercialização 729 ID-de-depósito + número-de fatura + data Figura 7: Interagir com depósitos 730 relatório-dedi adiantamento/ resposta-de autorização-de adiantamento resposta-de adiantamento Figura 8: Interagir com autores 731 F.4.3 O DICIONÁRIO DE DADOS O dicionário de dados está organizado na forma descrita no cap tulo 10. Os termos autodefinidos (elementos de dados cujos significadc são suficientemente bem conhecidos e que não requerem definição e plícita) são apresentados com a definição de . Veja, como exemplo, definição de “país” e “estado”. AUT-DE-DEVOLUÇAO-# = *depósjto de dados utilizad para controlar o número seguin te de uma devolução autorizad * aut-de-devoluçào-# aut-de-devolução-# = *número seqüencial utilizad para identificar um conjunt específico de livros devolvido que tenham sido autorizados* {dígito-numérico} autor = *informaçõe$ existentes sobr cada autor* @ID-de-autor + detalhes-de autor + saldo-de-direitos AUTORES
= {autor}
autorização-dedevolução-de-livro *resposta ao cliente quando
depósito notifica o sistema d que as devoluções de livro foram recebidas* [ devolução não está au torizada” 1 “Esta devoluçã está autorizada”] autorização-de-faturade-gráfica
= *resposta da direção depois d
verificação de uma fatura d gráfica* [ 1 “NÃO”] caracter-alfabético
= *uma letra do alfabeto*
** 732 caracter-alfanumérico = *um número, uma letra ou um sinal de pontuaçâo* [ 1 dígitonumérico 1 sinal-de-pontuação cliente - *um cliente da YOUPDON Press* @ID-de-cliente + (nome-de-em presa) + nome-de-cliente + endereço-de-cl + saldo- atual + limite-de-crédito + nível-deplano_da_agência **CLIENTES -
{cliente}
código-de-ano = *Q5 dois últimos dígitos do ano atual. P.ex.: “88”, se o ano atual for 1988* 2 {dí gito-numérico ) 2 código-de-livro = *código numérico que idez cada livro* l{dígito-numérico} código-postal = *código nadense
postal americano, ca-
ou inglês*
** comissão-total= *total pago em
comissões a
vendedor durante o
de
período
um mês com base em
todos os
livros que
vendido.
ele tenha
Calculado no processo
3.6*
** consulta-de-crédito
= solicitação de autorização
a uma agência de cartões de
um
crédito para a compra de li vros * “Solicitação de
autorização” +
número-do-cartão_de_crédito + total-do-pedido contagem-de-inve
= *informação relativa
contagem física efetuada
por
um
+
na-
a
depósito* (detalhe-de-inventário) data 733 contagem-fisica
= *contagem do número de cópia
de um mesmo titulo encontrada em um inventário fisico reali zado por um depósito* ** cotação-de-gráfica
*cotaçâo de uma gráfica; um
oferta para a inpressão de uni certa quantidade de livros po um determinado preço* código-de-livro + preço-de gráfica crédito *crédito pessoal dado a u cliente face a algum problem com um pedido* @número-da-fatura + ID-de cliente + data-do-crédito código-de-livro + quantidade de-livros-de-crédito + valor do-crédito CRÉDITOS
=
créditos-de-vendas
(crédito) *créditos relativos a um deter
minado livro durante um period
uma
especificado* *unidades: dólares* data-da-devolução
= *data em que um grupo de livro
foi devolvido* ** data-de-disponibilidade impressão
foi
chegar ao
depósito*
= *data
solicitada
em
que
dev
** data-de-remessa
= *data em que o depósito despa
cha um pedido* ** data-de-vendas
= *data
após a qual todos o
pedidos, créditos e devoluções devem ser incluidos no rela tório
de estatisticas de ven
das* ** 734 data-do-crédito
- *data em que um crédito foi
concedido * ** data-do-pagamento
*data em que o pagamento foi
feito* ** data-do-reembolso
= *data em que o reembolso foi
aprovado * ** data-do-saldo-atual
- *d na qual
cliente foi
calculado pela
última vez
(normalmente sendo
produzido um extrato para o clíente*
o saldo atual do
um livro
cuj
data-revista
*nova data
estipulada pela
gráfica para a entrega de um lote de livros presentemente sendo impressos* ** desconto
*percentual de desconto ofere-
ciclo a um pedido, expresso como uma fração do preço a ser pago, isto é: um desconto de 10% se ria expresso cono 0.90* *jntenjalo: O l.00 detalhe-de-inventário - *contagem fisica
de
um único
titulo* código-de-livro
+
contagem
fisica despesas-de-remessa = *importância despendida na re messa de um livro para o clien te. Ela pode ter um valor pa dronizado, p.ex.: $1,50, ou po de ser *baseada nas despesas reais impostas por um transportador* *unidades: dólares; intervalo: o - 100* 735 detalhes-de-autor
- *tjtulo_de.cortesja + primeirc
nome + último-nome + endereço cidade + código-postal + (pai + número_de_telefone* detalhes-de-cliente
- *jnfor provindas de
cliente para alterar dÁdoS c seus registros; ex.: um no endereço*
(nome-de-cliente) + (nome da-empresa) + (endereço-de cliente) detalhes-de-devolução
= **
fitem-de-devolução) detalhes-de-pedido
= *dados brutos a partir do
quais será preparado um pedid válido e colocado no depósit de dados PEDIDOs*\ ID de cliente experimental {item-de-pedido} + taxa-de-im posto-sobre-vendas + despesas de-remessa + tipo-de-pagament + (pagamento-de-pedido) (número-de-cartão-de-crédito) pedido-sem-estoque-OK + tipo de-pedido detalhes -de-pedi doválido = *dadog brutos
a partir do
quais um pedido válido pode se. preparado e colocado no depó sito de dados PEDIDOS* *ID_de_cliente
+ {item-de-pe
dido} + taxa-de-imposto-sobre vendas + despesas-de-remessa - tipo-de-pagamento + (pagamento- de-pedido) + (número-de-cartão de-crédito) + pedido-sem estoque-OK + tipo-de-pedido detalhes-do-pagamento
= *info detalhadas
pagamento de um item ou
fatur&
(número-da-fatura) + valor total 736 devolução
- *jnfOz sobre um grupo de
livros devolvidos e aceitos
sobre
pela YOURDON Press* data-da-devolução + código-delivro + quantidade-devolvida + valor-da-devolução devolução-autorizada - *jnfo sobre um grupo de livros que a YOURDON Press te nha autorizado um cliente a de volver em troca de crédito* @aut-de-devolução-# + detalhesde-devolução DEVOLUÇÕES
- (devolução
DEVOLUÇÕES-AUTORIZADAS * {devolução-autorizada devoluções-de-vendas
*devoluções relativas a
vro durante um período
especi
ficado de
tempo*
*unidades:
dólares*
dígito-numérico
um li
- *um simples digito numérico!*
** DINHEIRO
-
{dinheiro}
dinheiro
*informações sobre cheques,
dinheiro vivo e outras formas de moeda* @data-do-dinheiro + ID-de- cliente + {número-da-fatura} + valor direito-de-item
= *direitos garantidos pela venda
de uma ou mais cópias do mesmo livro em um único pedido* *unidades: dólares* 737 documentos-de-remessa = *lista de separação e etiqueta postais enviadas aos depósito para que possam separar sufi cientes cópias de cada livro despachar os pedidos do dia, mais uma cópia de cada pedidc para que o depósito saiba qu livros devem ser embalados para cada cliente* {ID-de-depósito + lista-de- separação + {rótulo-de-remessa} + {pedido}}
endereço-de-cliente - *endereço para envio de contas: para onde são remetidas as fa turas de clientes* endereço + cidade + estado código-postal + (pais) endereço-de-gráfica - *endereço em que a gráfica pode ser contactada* endereço + cidade + estado + código-postal escolha-de-plano-daagência
- *escolha do cliente de acei
tação de um nível de plano da agência* O_4* estado *estado ou província em um en dereço* ** estatísticas-de-vendas = *relatório para a Comerciali zação sobre as vendas liquidas de livros relativamente a um determinado período de tempo* {código-de-livro + receita-de vendas + devoluções-de-vendas + créditos-de-vendas etiquetas-postais
- *etiquetas postais
produzidas
para o departamento de comer cialização* {cliente} 738 fatura - *infor contidas em uma fatura da YOURDON Press* @número-da--fatura + nome-decliente + endereço-de-clie + pedido fatura-de--gráfica
- *fatura recebida
fica, relativa a um
pedido de
impre as ão * código-de-livro
+
valor-da-
de
uma grá
fatura fatura-de-gráfica aprovada
- fatura de gráfica aprovada
pela direção* código-de-livro + valor-dafatura FATURAS
- {fatura}
gráfica = *jnfo sobre cada uma das gráficas com que
a YOURDON
Press tem negócios* @ID-de-gráfica +
nome-de-
gráfica + endereço-de-gráfica GRÁFICAS - {gráfica} ID-de *jdentjfjcação de cada autor da YOURDON Press. Os números da Social Security não são utili zados porque nem todos os au tores são cidadãos americanos* último-nome + primeiro-nome ID-de-cliente = *jdentjfjcação de um cliente da YOURDON Presa. Clientes desco nhecidos ou não identificados são citados como “receita não apli cada”, principalmente quanto a pagamentos [ 1 “receita não aplicada”] 739 experimental = *informações sobre um cliente ao ser apresentado
seu primeiro
pedido* [+
(nome-de-
cliente) 1 “novo”
+ nome-de-
cliente +
(nome-da-empresa) +
endereço-de-cliente) lD-c1e-
= *identificação
depósitos onde
são
os livros da YOUPDON [ 1 “LON” 1 “DC”
dos
diversos
armazenados Press*
“SF0” 1
“YONKERS” 1 “OTTAWA”] ID-de-gráfica = *código único que identifica uma gráfica* (digito-numérico} ID-de-vendedor
= *identificação de um vendedoz
da YOURDON inc. ** imposto-sobre-vendas= *iglposto local ou estadual so bre vendas
relativo a um pe
di do * *unjdades.
dólares*
indicador-de-fora-deimpressão
*indicação binária se um livrc
está fora do estoque de forma a que pedidos subseqüentes (se houver algum) serão rejeitados [ NÃO) informação-de-devoluçãode-livro
*informações sobre um grupo de
livros que foi devolvido ao de pósito por um cliente* (ID-de-cliente) + (nome-de cliente) + (código-de-livro 4 quantidade-devolvida} + autori zação-de-devolução-# 740 instruções-de_devolução =
*nstruções ao depósito sobre
como lidar com livros que o
um conjunto de
cliente devolveu*
(“Cliente não identificado; aceitar livros, mesmo assim” 1 “Devolução não
autorizada; fa
vor remeter devolta” 1 “Livro não existe” 1 “Devolução au torizada”] instruções-de-pedido_de_ impres são
*instruções da direção para re
imprimir um livro* ID-de-gráfica + código-de-livro + quantidade-a-imprimir + datade-disponibilidade inventário-total-delivro
total
de exemplares de
um determinado
titulo, em todos
os depósitos da YOURDON Press* ** item-de-devolução
*infonpações sobre uma ou mais
cópias de um único titulo que o cliente deseja devolver* código-de-livro + quantidade-adevolver item-de-inventárjo
= *um grupo de livros, com o mes
mo titulo, localizado em um só depósito* @código-de-livro + @ID-de depósito + quantidade-de-inve ntário item-de-pedido
= @número-da-fatura + @código-de-
livro + quantidade-pedida + preço-unitário + desconto
I1
{item-de-inventário}
ITENS-DE-PEDIDO -
{item-de-pedido}
741 limite-de-crédito - *valor do crédito que será con cedido a um cliente para pedi dos não previamente pagos* *unidades: dólares; intervalo 1-10. 000* lista-de-separação = *jndicação do número de cópia de cade livro que um de precisa separar para satisfaze os pedidos de um dia* {título-de-livro + quantidade aseparar livro
= *informaçôes existentes sobr
um livro da YOURDON Press* @código-de-livro + título-de livro + total-em-estoque quantidade-pedida + data-em- estoque + taxa-de-direitos indicador-de-fora-de-impressâc + estoque-mínimo LIVROS
= {livro}
mensagem-de-estoquebaixo *mensagem enviada À direçâ quando o sistema percebe que estoque total de um livro cai abaixo de um limite pré-esta belecido* código-de-livro + total-emestoque + “tempo para reim pressão” motivo-do-crédito
* do cliente para solici
tar um crédito* [ em excesso” “Demora excessiva” 1 “Remessa insuficiente” “Livros danifi cados” 1 na-data= *a data em que foi realizado ux inventário físico* **
742 nível-de-plano-daagência
*código que indica que nivel de
“estatutos” o cliente escolheu para os futuros livros da YOURDON Press* *inte O_4* nome-da--empresa
=
*nome de uma empresa ou de uma
organização* ** nome-de-cliente
*tjtulo_de_cor + primeiro-
nome + último-nome nome-de-gráfica
*nome da empresa gráfica*
** nome-de-vendedor
=
*nc,me de um vendedor da YOUPDON
inc. * ** notificação-de-remessa
*mensagem de depósito ao ser
recebida uma impressão da grá fica * (“Livro não existe” 1 “Recebido da gráfica” + código-de-livro + quantidade-recebida] número-da-fatura
-
*n único atribuido a cada
fatura; um número típico de fa tura é B88_5067* “B” + código-do-ano + {dígito numérico número-de-telefone *um número de telefone* ** número-do-cartão-decrédito =
*um número de cartão de crédito
fornecido por um cliente quando
ele deseja carregar um pedido de livros em seu cartão de crédito* ** 743 pagamento
= *pagamento feito em relação
um pedido de livros ou em re lação a uma fatura* (ID-de-cliente) + data-do-pa gamento + detalhes-do-pagamentc pagamento-de-pedido = *pagamento feito p c1ient COM o pedido* *unidades: dálares* PAGAMENTOS pais
= {pagamento}
= *nome de um pais, ex.: “Ca
nadá” * ** pedido = *um pedido de um livro d YOURDON Press* @número-da-fatura + ID-de cliente + data-do-pedido {item-pedido} + despesas-deremessa + imposto-sobre-vendas + data-de-remessa + (ID-de vendedor) + total-do-pedido ID-de-depósito pedido-de-impressão = *p de irr feito a urna gráfica* código-de-livro + quantidade-a- imprimir pedido-de-impressãorevisto = *revisão de um pedido de im pressão, efetuada por uma grá fica. Consiste habitualmente en
pequenas modificações na quan tidade a ser impressa* código-de-livro + quantidaderevista + data-revista pedido-sem-estoque-OK apresentará um
= *indicação de
se um cliente
pedido mesmo que
não haja livrossuficientes nc estoque* [ 1 “Não”] PEDIDOS
= {pedido}
744 preço-de-gráfica
- *preço relativo a urna cotação
de gráfica* ** preço-unitário - *preço estabelecido para um exemplar de um livro da YOURDON Press ou para um pedido uni tário; observe que pode ser di ferente do preço unitário “pa drão” ou “a retalho” anunciado para o livro* *unidades: dólares* primeiro-nome
= *0 primeiro nome de uma pessoa*
** quantidade-a-devolver *n de cópias do mesmo ti tulo que um cliente deseja res tituir para obter crédito* ** quantidade-a-imprimir *ni de cópias de um livro a serem impressas* ** quantidade-a-separar = *número de cópias de um livro que precisam ser separadas para satisfazer os pedidos de um dia
no depósito* ** quantidade-de-inventário= *contagem do número de exem plares do mesmo titulo, locali zados em um mesmo depósito* ** quantidade-de--livrosdo-crédito
= *número de cópias de um livro
para o qual está sendo procu- rado um crédito* ** quahtidade-devolvida *número de que foram
cópias de um livro
restituidos ao de-
pósito por um cliente* ** 745 quantidade-do-pedido= *nún.iero decópias de um livr que foram
solicitadas*
** quantidade-pedida
- *número de cópias de um livr
pedidas a uma gráfica como par te de um pedido de impressAo* quantidade-recebida - *núinero de cópias de um livn que foram
realmente recebida
da gráfica
em conseqüência d
um pedido
de impressâo*
** quantidade-revista = *revisão do número de livros serem impressos pela gráfica como parte de um pedido di impressão* ** receita-de-vendas = *receita bruta de vendas de ur determinado livro durante ur especificado periodo de ternpo *unidades: dólares* receita-total
= *valor total da receita
de todos os
pedidos de
livro
bruta
em um n *unidades: dólares* receita-total-de-livros = *receita total proveniente d venda de um livro durante un periodo de três meses, conside rando-se créditos e devoluções * dólares* reembolso = *informações sobre um reem bol so* @data-do-reembolso + @ID-de cliente + valor-do-reembolso REEMBOLSOS
= {reembolso}
relatório-de-comissões = *relatórjo de comissões de vendas * {{ID-de-vendedor + número-da-fatura + valor-da comissão} + total-da-comissào} 746 relatório-de-contasa-receber
*relatório para a Contabilidade
mostrando o saldo atual de cada cliente* {ID-de-cliente + débito-atual} relatório-de-direitosde-autor
= *relatório para os autores mos
trando direitos ganhos ou per didos em vendas, créditos e de voluções de cada livro durante um perlodo de três meses * (total-de-cópias-de-livro + re ceita-total-de-livro + totalde-direitos-de-livro relatório-de-inventário
*relatório produzido para o
Departamento de Contabilidade* ({ID-de-depósito + código-delivro + quantidade-de-inventário} + inventário-total-delivro) relatório-de-receitadiária *relatório enviado ao Depar
tamento de Contabilidade a cada dia * (número-da-fatura + nome-decliente + nome-da-empresa + total-do-pedido 1 + total-da-receita-diária relatório-de - receita mensal *relatório da receita total, devoluções e créditos relativos a um único mês, enviado ao De partamento de Contabilidade* receita-total + total-de-devo luções + total de crédito relatório-trimestral1e-direitos
- * relatório para o Departamento
de Contabilidade mostrando os direitos ganhos ou perdidos em vendas, créditos e restituições de cada livro durante um perío do de três meses* 747 {{ ID-de-cliente + nome-de-clienti + número-da-fatura + receita-de item + direito-deitem} + total de-cópias-de-livro + receita-to tal-de-livro + total-de-direitos de-livro) renda-de-item - *renda bruta da venda de uma 01 mais cópias do mesmo livro ei um único pedido* *unidades: dólares* resposta-a-alteraçãode-cliente
- *resposta ao cliente que noti
ficou uma alteração de ende reço, etc* (“Cliente não existe” “Ai’ teração aceita”] resposta-a-fatura-degráfica = *resposta do sistema quando recebe uma fatura d gráfica*
à gráfic
[ há pedidos pendente desse livro”] resposta-a-fora-deestoque
= *mensagem ao depósito em res
posta à sua indicação de que ur titulo está sem estoque naquei depósito * [ não existe” 1 “Erro item de inventário não encon trado” 1 “mensagem de falta d estoque recebida”] resposta-a-informaçõesde-livro = *i sobre titulo, preç etc de um livro* livro resposta-a-inv-fisico - *mensagem do sistema a ur depósito em resposta a um invew tário fisico realizado* [ não existe” “código de
livro inválido”
codigo-de-l ivro] 748 resposta-a-limite-decrédito *resposta a instruções da di reção para alterar o limite de crédito de um cliente* [ não existe” 1 “limite de crédito inválido” 1 “Novo limite de crédito OK”] a-pedido
= *resposta ao cliente ao intro
duzir um pedido* [ da conpra excede valor pago” 1 “Crédido solicitado ne gado” 1 “Pedido excede limite de crédito” 1 “Não há livros suficientes para atender seu pedido” “Cliente não existe” 1 “Livro não existe” 1 “Taxa de
imposto sobre vendas inválida” 1 “Despesas de remessa inváli das” 1 “Pedido aceito”] resposta-a-pedidode-impressão *resposta do sistema a um pe dido de
impressão da direção*
[ não existe” .1
“Quanti
dade de
impressão
inválida” 1
“Pedido
de impressão aceito”]
resposta-a-pedido-deimpressão-revisto _ *r do sistema ao ser re cebido da gráfica um pedido revisto* [ não existe” 1 “Pedido de impressão revisto OK”] resposta-a-remoçãode-livro
= *resposta
à
comercialização
quando ela indicar que
um livro
deve ser
fora de
considerado
impressão* [ não existe” 1 “Livro marcado
como fora
de im
pressão”] 749 resposta-a-solicitaçãode-devolução *resposta a um cliente que de seja devolver um livro* [ não encontrado” “Livros foram remetidos há mai de um ano” “Quantidade d livros não pode ser devolvida’ 1 “Devolução OK” “Favor iden tificar devolução real com” 1 aut-dedevolução-#] resposta-de-adiantamento= *resposta ao editor de aqui sições quando ele faz uma soli citação de adiantamento de di reitos para
um autor*
[ não existe” “Livrc não existe”
1 “Adiantamentc
aprovado” 1 “Adiantamento ne
gado”) resposta-de-agênciade-crédito
= *resposta
de uma agência dE
cartão de
crédito a uma solici
tação de
autorização de co
brança * [1
“Não”]
resposta-de-autorizaçãode-adiantamento
= *resposta da direção a uma so
litação de adiantamento de di reitos para um autor* [
“Não”)
resposta-de-crédito = *resposta ao cliente que deseja uma carta de crédito* [ desse cliente n&c existe” 1 “Crédito já conce dido” “Nenhum pagamento foi feito para esse número de fa tura” 1 “Crédito será mostradc na próxima declaração” 1 “Fa tura não foi paga em excesso” “Valor total do pedido credita do” 1 “Crédito por remessa in suficiente:” + valor-do-créditc 1 “Crédito por livros danifica dos:” + valor-do-crédito] 750 resposta-de-em-estoque
= * a consulta da comer
cialização sobre a data
em que
estará em estoque uma
remessa
de livros da gráfica* [ não existe” “não há remessas esperadas” 1
data-de-
disponibilidade] resposta-de-fatura
= *resposta à consulta de um
cliente sobre uma fatura* [ há pedidos com esse número de fatura” 1 data-do- pedido + {itens-do-pedido} + despesas-de-remessa + imposto- obre -venda s resposta-de-reembolso
= *resposta ao cliente que soli
citou reembolso* [ não existe” 1 “Reem bolso indevido” +
“Saldo atual
é” + saldo-atual 1
“reembolso
aprovado”] resposca-oe-remessa = *mensagem de erro a um depósito em resposta a sua notificação de que foi remetido o pedido de um cliente* “Pedido não encontrado” resposta-de--situaçãode-pedido
= *resposta a um cliente que con
sultou a situação de um pedido que ele apresentou* [ há pedidos para esse número de fatura” 1 data-dopedido + {itens-de-pedidos} + data-de-remessa] rótulo-de-remessa
= *rótulos postais para os pedi
dos do dia ao depósito* nome-do-cliente + endereço-docliente + número-da-fatura saldo-atual
= *total em dinheiro presente
mente devido por um cliente, * *NA DATA DO SALDO_ATUAL* *unidades: dólares; intervalo: 1 000* 751 sinal-de-pontuação clamação,
= *virgponto, ponto de ex
etc.*
** solicitação-de - adiantamento-dedireitos
= *soljcitaçâo do editor ae aqui
sições por um adiantamento de direitos para um autor relati vamente a um livro* ID-de-autor + código-de-livro + valor-do-adiantamento solicitação-de- autorização-
de-adiantamento
= *mensagem à direção, solici
tando aprovação para um adian tamento de direitos para o projeto de um livro* ID-de-autor + código-de-livro + valor-do-adiantamento solicitação-de-chequede-adiantamento
*mensagem ao
Departamento de
Contabilidade,solicitando que seja pago um adiantamento au torizado de direitos* ID-de-autor + código-de-livro + valor-do-adiantamento solicitação-de-chequede-reembolso *mensagem ao Departamento Contabilidade solicitando
de
a
preparação de um cheque de re embolso para um cliente* “Favor pagar” + ID-de-cliente + valor-do-reembolso solicitação-de-códigode-livro
= *mensagem à direção
a atribuição de um
solicitando
código-de
livro a um novo livro* “Favor atribuir novo código de livro ao seguinte livro;” 752 solicitação-de-crédito = *soljcitação feita por um cliente para crédito em relação a um pedido* ID-de-cliente + número-da- fatura + código-de-livro + quantidade-de-livroa-docrédito + nDtivo-do-crédito + valor-de- crédito-solicitado solicitação-de-devolução= livros que um cliente deseja
*info sobre
um ou mais
devolver em troca
de crédito*
número-da-fatura +
detalhes-de-
devolução solicitação-de-etiquetas = para a produção
*solicitação da
Comercialização
de etiquetas
postais * “Favor produzir
etiquetas pos
tais” solicitação-de-preçounitário
*mensagem à Comercialização
solicitando o preço unitário de um novo livro* “Favor indicar preço unitário para o seguinte livro:” solicitação-de-reembolso= *solicitação de um cliente por um cheque no valor do seu saldo de crédito atual* ID-de-cliente + “solicitação de reembol so” solicitação-de-taxade-direitos
= *mensagem ao departamento de
aquisições solicitando uma taxa de direitos para um novo livro* “Favor indicar taxa de direitos para o seguinte livro:” solicitação-de-vendas *solicjtação do departamento de Comercialização para que seja produzido um relatório de ven- das para todos os pedidos, cré ditos e devoluções que tenham ocor rido após a data especificada* data-de-vendas 753 taxa-de-comissão
*taxa de comissão paga a u
vendedor pela venda de livros É expressa por uma fração* *inte O - 0.25* taxa-de-direitos
*taxa de direitos paga a u
autor por um livro express como uma percentagem. Ex.: 1 significa l0%* *intervalo: 5_25* taxa-de--imposto-sobre-
vendas = *percentual do imposto sobr vendas, expresso como uma fra ção decimal. P.ex.: um inpost de 7% sobre vendas seria mdi cado como 0.07* *intex 0.00 - 1.00* tipo-de-pedido = *indica se o pedido foi apre’ sentado por telefone, peL correio ou de forma ocasional [ “Correio” 1 “Oca’ sional”] -- q
*modo como o cliente pretendi
pagar a compra de livros de U! pedido* [ “Cheque” 1 “Car tão de crédito” 1 “Cobrança”] titulo-de-cortesia = *prefixo antes do primeiro nomi de uma pessoa* [ 1 “Sra.” 1 “Srs.” “Srta.” 1 “Dr.” 1 “Prof.”] titulo-de-livro = *título completo de um livro d YOURDON Press* 1 {caracter-alfanumérjco} total-da-receita-diária = *valor total de novas venda registrado a cada dia* *unidades: dólares* 754 total-de-cópias-de-livro=
*n total de cópias de um
livro vendido, considerando devoluções e créditos, durante um período de três meses* ** total-de-crédito
= *valor total dos créditos con
cedidos a todos os clientes em um único mês* *unidades: dólares total-de-devoluções - *importância total relativa a livros que foram devolvidos por todos os clientes em um mês* *unidades: dólares*
total-de-direitos-delivro
- *direitos totais ganhos (ou
perdidos) em vendas, devoluções ou créditos de um livro durante um período de três meses* * dólares* total-do-pedido
= *total faturado de um pedido*
*unidades: dólares* total-em-estoque
*número de cópias de um livro
da YOtJRDON Press que temos em estoque em todos *inte 1 -
os depósitos*
10.000*
último-nome *0 último nome de uma pessoa* valor = *valor em dinheiro recebido em um único pagamento* *unidades: dólares* valor-da--comissão
= *valor da
vendedor relativa a um de livros;
comissão pagaa um
pedido
calculada no pro-
cesso 3.6* ** valõr-da-devolução
= *valor de
que tenham
sido devolvídos*
*unidades:
dólares*
um grupo de livros
755 valor-da-fatura = *quantja cobrada por uma gr fica em uma fatura relativa um pedido de impressào* *unjdadeg: dólares* valor-de-créditosolicitado
*valor solicitado como créditc
*un idades: dólares* valor-do-adiantamento - *jmportâncja solicitada con adiantamento de direitos* * dólares*
valor-do-crédito
= *valor dado como crédito*
*unjdades: dólares* valor-do-reembolso -
a ser restituida
um cliente* *unidades: dólares * vendedor = @IDdevendedor + nome-de-ver dedor VENDEDORES
= {vendedor}
756 F.4. 4 O Diagrama de Entidades-Relacionamentos 757 F.4.5 Espec de Processos PRC 1.1.1 ITAR DETM1 DE P BEGIN IF Id-ds-cliente-exp.rin = “novo” ID-da-cliente = ID-de-cliente disponivel seguinte limite-de-crédito - limite de crédito padrão saldo-atual O nivel-da-plano-da-agôncia
O
cliente ID-de-cliente + nome-de-cliente + (nome-da empresa) + endereço-de-cliente + saldo-atual + limite-de-crédito + nival-de-plano-da-agêncie APPEND registro de novo cliente a CLIENTES ELSE FIND cliente em CLIE2 com ID-de-cflent - ID-da-cliente em detalhe a -da-pedido IF registro não encontrado resposta-a-pedido - “Cliente não existe” DISPLAY resposta-apedido EXI T *obs. :isto significa que o pedido não mais será proces sado * ENDIF DO WHILE houver item-da-pedido em detalhes-da-pedido FIND livro em LIVI com código-da-livro = código-dalivro em item-d.-pedido IF registro não encontrado resposta-a--pedido - “Livro não existe” DI SPLAY resposta-apedido EXI T *obs. : isto significa que o pedido não mais será processado * END 1 F END DO
IF taxa-de-iwposto-sc estiver fora do intervalc resposta-a-pedido - “taxa de irposto sobre vendas inválida” DISPLAY resposta-a-pedido EXI T *obs.: isto significa que o pedido não mais será processado* ENDIF IF despesas-da-remessa esti ier fora do intervalo resposta-a-pedido = “der ‘esas de remessa inválidas” DISPLAY respo a-a-pedido EXI T 758 *obs. :isto significa que o pedido não mais será proces sado* ENDIF d.tal.hea-de-pedido-válido = ID-de-cliente + (itein-da pedido) + taxa-de-imposto-sobrevendas + despesas-da r + tipo-da-pagamento + (pagamento-da-pedido) + (nun + pedidosam-estoque-O + tipo-de-pedido DISPLAY (para o processo 1.1.2) detalhes-da-pedido-válido END 1’RO 1.1.2: VERIFICAR ESTOQUE DE LIVRO BEGIN IF pedido-sem-estoqua-OK “Sim” DISPLAY (para a bolha 1.1.3) detalhes-de-pedidoválido + “YONKERS” ELSE IF tipo-da-pedido = “Ocasional” DO WHILE houver item-da-pedido em detalhes-da-pedido válido FIND item-de-invantário em ITENS-DE-INVENT com código-da-livro = código-delivro em detalhes- de-pedido-válido e ID-de-depósito = local onde foi recebido esse pedido-ocasional READ registro item-da-inventário IF quantidade-da-inventário < quantidade-pedida resposta-a-pedido = “Não há livr suficientes para atender seu pedido” EXI T *obs: isto significa que este pedido não será mais processado* END 1 F END DO
DISPLAY (para a bolha 1 . 1.4) detalhes-da-pedidoválido + ID-da-depósito (do depósito onde foi recebido este pedido ocasional) ELSE livros-suficientes = “Sim” PEPEAT-UNTIL não haja depósitos em DEPÓSITOS ou • livros-suficientes = “Sim” • *obs.: isto significa que pelo menos um depósito será examinado* livros-suficientes = “Sim” DO WHILE houver item-da-pedido em detalhes-de- pedido-válido FIND item-de-inventário em ITENS-DE-INVENTÁRIO com código-de-livro = código-de-livro em detalhes759 de-pedido-válido e ID-de-depósito - ID-da depósito do registro depósito corrente READ registro itexn-de-inventário IF quantidade-da-inventário < quantidade-pedida livros-suficientes - “Não” ENDIF END DO END REPEAT IF livros-suficientes “Não” resposta-a-pedido = “Não há livros suricientes par atender seu pedido” DI SPLAY resposta-a-pedido ELSE DISPLAY (para a bolha 1.1.4) detalhes-de-pedido válido + ID-de-depósito do registro depósito corrente ENDIF ENDIF END PRO 1.1.3 V AUTOPJZAÇÀO DE .tDITO BEGIN preço-total = O PEPEAT UNTIL não haja itam-de--pedido em detalhes-de- pedido-válido ADD (quantidade-pedida) * preço-unitário * desconto) a preço-total
END PEPEAT MULTIPLY preço-total por (1 + taxa-de-inçosto-sobre vendas) ADD despesas-de-remessa a preço-total crédito-OK = “Sim” CASE tipo-de-pagamento de CASE tipo-de-pagamento “Dinheiro” ou tipo-de- pagamento = “Cheque” IF preço-total > pagamento-de-pedido resposta-a-pedido “Valor de compra excede valor pago” DISPLAY resposta-a-pedido *obs.: isto significa que este pedido não será mais processado* crédito-OK “Não” ENDIF CASE tipo-de-pagamento = “Cartão de crédito” consulta-da-crédito = “Solicitação de autorização” + preço-total DISPLAY (para a agência do cartão de crédito) 760 consulta-de-crédito ACCEPT (da agência de crédito) resposta-da-agencia da-crédito IF resposta-da-agência-de-crédito “Não” resposta-a-pedido = “Solicitação de crédito negada” DI SPLAY resposta-a-pedido crédito-OK “Não” *obs.: isto significa que este pedido não será mais processado * ENDIF CASE tipo-da-pagamento - “Cobrança” FIND client. em CLI com ID-da-client. - ID-de cliente em detalhes-da-pedido-válido READ registro client. IF saldo-atual. + preço-total > limite-de--crédito resposta-a-pedido = “Pedido excede limite de crédito” DISPLAY resposta-a-pedido crédito-OK - “Não” *obs: isto significa que este pedido não será mais processado* ENDIF END CASE IF crédito-OK - “Sim”
DISPLAY (para a bolha 1.1.4) detalhes-de-pedido-válido + preço-total + ID-de-depósito DISPL (para a bolha 1.1.5) detalhes-de-pedido-válido + ID-de-depósito ENDIF END PROCESSO 1.1.4 INTRODUZIR PEDIDO BEGIN DO WHILE houver item-da-pedido em detalhes-da-pedido- válido CREATE registro item-de-pedido a partir do próximo item-da-pedido em detalhes-da-pedido-válido APPEND registro item-da-pedido em ITENS-DE-PEDIDO ENJ) DO CREATE registro pedido a partir de detalhes-de-pedidoválido e ID-d.-depósito APPEND registro pedido em PEDIDOS CREATE registro fatura a partir de detalhes-da-pedido válido P registro fatura em F IF tipo-do-pagamento = “Dinheiro” ôu “Cheque” ou “Cartão de crédito” 761 CPEATE
registro
dinheiro
a
partir de
APPEND
registro
dinheiro
a
Dfl
CREATE
registro
pagamento
a
partir de
registro
pagamento
a
PAG1
detalhes-de
pedido-válido detalhes-de-
pedido-válido PPEND ENDIF APPEND deta].hes-d-pedido-vál ido a 7 VOS resposta-a-pedido - “Pedido aceito” DI SPLAY resposta-a-pedido END PRO 1.1.5 V INVENTÁRIO PARA REI BEGIN DO WHILE houver item-da-pedido em detalhes-da-pedido- válido
FIND item-de-inventárjo em ITENS-DE-INVENTÁRIO com código-de-livro = código-de-livro em item-de-pedido ID-de-depó.ito coincidindo com ID-de-dapósito fornecido como entrada neste processo READ registro item-da-inventário SUBTRACT quantidade-pedida de quantidade-dainventário *obs.: esta operação pode resultar em saldo negativo, *0 que significa que o depósito não poderá satisfazer’ o pedido até à chegada de uma reimpressão* WRITE registro item-da-inventário FIND livro em LIV com código-de-livro código-da- livro em itam-da-pedido READ registro livro SUBTRACT quantidade-pedida de total -em--estoque WRITE registro livro IF total-em-estoque < estoque-minimo mensagem-de-estoque-baixo = código-da-livro + totalem-estoque + “hora de reimprimir” DISPLAY mensagem-da-estoque-baixo END 1 F END DO END PRO 1.2: PI PEDIDO DE VE A esta altura, a norma para o processamcnio do pedido ULI vendedor é a mesma que a do processamento de um pedido normal dc cliente. Veja os detalhes na figura 1.1. 762 PRO 1.3: REGISTR1 CLIENTE NO PLANO DA 7 Pré-condição -1 Existe um cliente em CLIENTES que coincide com ID-de client, com nível-de-plano-daagência - O e com escolha-de-plano--da-agência > O e escolha-da-plano-da- agência menor ou igual ao nível máximo da agência. Pós-condição-1. nivel-de-plano-da-agência em cliente é ajustado em escolha-de-plano-da-agência. PROCESSO 1.4: ENVIAR FATURAS BEGIN DO WHILE houver faturas em FPITURAS READ próxima fatura
DISPLAY fatura END DO END PROCESSO 2.1: PROCESSAR PAGA BEGIN IF ID-da-client. presente FIND registro em CLIENTES com ID-da-cliente coincidente IF registro não encontrado WRITE detalhes-de-pagamento em PA com ID-de-client
“receita não aplicada”
ELSE StJBTRACT valor-total de saldo-atual WRITE registro em CLI WRITE detalhes-de-pagamento em PAGA ELSE WRITE detalhes-da-pagamento em PA com ID-da cliente - “receita não aplicada” WRITE data de hoje + ID-de-cliente + detalhes-de pagamento em DINREIRO ENDIF END PROCESSO 2.2: FORNE INFORNAÇÕES SOBRE LIVROS BEGIN FIND registro livro em LIVROS com título-de-livro coincidente resposta-a-informações-da-livro = conteúdo de todo o registro livro DISPLAY resposta-a-informações-de-livro END 763 PRO 2.3: PRO SOLICITAÇ DE DEVOLUÇ BEGI N FIND pedido em P que satisfaça n ei solicitação-da-devolução IF registro não encontrado rasposta-a-solicitação-da-davolução = “Pedido não encontrado” DI SPLAY resposta-a-solicitação-da-davolução
ELSE READ registro pedido IF data-d.-r mais de um ano atrás resposta-a-solicitação-da-devolução - “Livros foram remetidos a mais de um ano” DI SPLAY resposta-a-solicitaç&o-da-davo ELSE tudo-OK = “sim” REPEAT TJNTIL não haja itam-de-devolução em detalhes de-devolução FIND itam-da-pedido em ITENS-DE-PEDIDO que satisfaça numero da fatura em solicitação-da devolução e código-da-livro em itezn-dedavoluçã4 IF registro não encontrado DISPLAY “Livro não fez parte do pedido” tudo-OK “não” ELSE REAl) registro item-de-pedido IF quantidade-a-devolver em item-da-davolução maior que metade de quantidade-pedida em item-da-pedido resposta-a-solicitação-da-devolução = “Quantidade de livros não pode ser devolvida’ DI SPLAY resposta-a-solicitação-da-devolução tudo-OK - “não” ENDIF ENDIF END-REPEAT IF tudo-OK = “sim” REAl) aut-de-davolução-# de AUT-DE-DEVOLUÇAO-# resposta-a-solicitação-da-devolução “Devolução OK,” + “Favor identificar devolução real com” 1 aut-da-davolução-# DISPLAY resposta-a-solicitação-da-devolução WRITE detalhes-da-devolução, aut-da-davoluç&o-f em DEVOLUÇÕES AUTORIZADAS
ADD 1 a aut-da-devolução-1 WRITE aut-da-devoluçào-# em AUT-DE-DEVOLUÇAO-# ENDIF END 1 F 764 ENDIF END PRO 2.4: RE A c S SITUA% DE PEDIDO BEGI N FIND pedido em PEDIDOS com numero-da-fatura coincidente IF registro não encontrado resposta-de “Não há pedidos para esse número de fatura” DISPLAY resposta-de ELSE REAl) registro pedido em PEDIDOS com número-da-fatura coincidente resposta_d. datado- pedido + (item-da--pedido) + data-da-remessa DI SPLAY resposta-de-situaç ENDIF END PRO 2.5: RESPOND A CONSULTA SOBRE TURA BEGIN FIND pedido em PEDIDOS com número-da-fatura coincidente IF registro não encontrado resposta-de-fatura - “não há pedidos para esse número de fatura” DISPLAY resposta-da-fatura ELSE REAl) registro pedido resposta-de-fatura = data-do-pedido + (item-da-pedido) + despesas-de-remessa + imposto-sobre-vendas DISPLAY resposta-de-fatura ENDIF END
PR 2.6: PRODUZIR CAR DE CRÉDITO BEGIN FIND pedido em PEDIDOS com ID-de-cliente coincidente e flúmero-da-fatura coincidindo com número-da-fatura em solicitaç&o-da-cródjto IF registro não encontrado resposta-de-crédito
“Pedido desse cliente não
existe” DISPLAY resposta-da-crédito ELSE FIND crédito em C com número-da-fatura 765 coincidindo com número-da-fatura em solicitação-de crédito IF registro não encontrado resposta-da-crédito - “Crédito já foi concedido” DI SPLAY resposta-da-créd ELSE CASE n OF CASE motivo-do-crédito - “Pagamento em excesso” FIND pagamento em P com numero-dafatura coincidente com número-da-fatura em so IF registro não encontrado resposta-da-crédito
“Nenhum pagamento foi
feito para esse número de fatura” DISPLAY resposta-da-crédito ELSE read pagamento FIND pedido em PEDIDOS com nun número-da-fatura em solicitaçào-de-cré IF valor-total > total-do-pedido resposta-de-crédito - “Crédito será apresentado na próxima declaração”
ELSE resposta-de - “Fatura não foi paga em excesso” ENDIF DI SPLAY resposta-d.-cré ENDIF CASE motivo-do-cré - “Demora excessiva” crédito número-da-fatura + ID-da-cljente + datá-atual + total-do pedido APPEND crédito em DITOS resposta-d.-ci = “Valor total do pedido creditado” DISPLAY resposta-da-crédito CASE motivo-do-crédito
“Remessa insuficiente”
IF total-do pedido > valor-da-crédito_solicitado crédito número-da-fatura + ID-da-cliente + data-atual + valor-da-crédito_solicitado resposta-da-crédito
“Crédito por
remessa insuficiente:” + valor-da-crédito_solicitado DISPLAY resposta-da-crédito ELSE crédito - numero-da-fatura + ID-da cliente + data-atual + total-do-pedido resposta-dacrédito - “Crédito por remessa insuficiente:” + total-do-pedido 766 DISPLAY resposta-da-crédito ENDIF APPEND crédito em CRÉDITOS CASE motivo-do-crédito
“Livros danificados”
IF total-do-pedido > valor-de-crédito-solicitado crédito - número-da-fatura + ID-de-client. + data-atual + valor-de-crédito- sol. icitado resposta-de-crédito
“Crédito por livros
danificados: “+ valor-de-crédito-solicitado
DISPLAY resposta-de-crédito ELSE crédito - número-da-fatura + ID-de-cliant. + data-atual + total-do-pedido resposta-de-crédito - “Crédito por livros danificados:” ÷ total-do-pedido DISPLAY resposta-de-crédito ENDIF APPEND crédito em DITOS ENDCASE ENDIF ENDIF END PRO 2.7: INFC9W CONTABILIDADE DA MBCESSIDADE DE R BEGIN FIND cliente em CLIE com ID-de-cliente igual a ID-de-cliente em solicitaçao-da-reambolso IF registro não encontrado resposta-de-reembolso - “cliente não existe” DISPLAY resposta-da-reembolso ELSE READ registro cliente IF saldo-atual maior ou igual a zero resposta-de-reembolso = “Reembolso indevido” + “Débito atual é” + saldo-atual DISPLAY resposta-de-reembolso ELSE resposta-de-reembolso
“reembolso aprovado”
solicitaçao-de-cheque-de-reaxnbolao = “Favor pagar” + ID-de-client. + saldo-atual DISPLAY resposta-de-reembolso DISPLAY solicitaçao-de-cheque-de-reembolso WRITE zero em saldo-atual em registro cliente
WRITE data-atual + ID-de-cliante + saldo-atual em REEMBOLSOS ENDIF 767 ENDIF END PROa.SSO 2.8: ESTABELEX NOVO LIMITE DE C BEGI N FIND cliente em CLIENTES com ID-de-cliente coincidente IF registro não encontrado resposta-a-limite-de-crédito “Cliente não existe” ELSE read registro cliente IF novo-limite-de-crédito < O resposta-a-limite-de-crédito = “Limite de crédito inválido” DISPLAY resposta-a-limite-de-crédito ELSE resposta-a-limite-de-crédito “Novo limite de crédito OK” DISPLAY resposta-a-limite-de-crédito REPLACE limite-de-crédito com novo-limite-decrédito WRITE registro cliente ENDIF ENDIF END PRO 2.9: ALT DETAI1 DE CLIENTE BEGI N FIND cliente em CLIENTES com ID-de-cliente coincidente IF registro não encontrado resposta-a-alteração-de-cliente - “Cliente não existe” DI SPLAY resposta-a-alteração-de-cliente ELSE read registro de cliente REPLACE nome-de-cliente, nome-da-empresa, endereço-decliente com nome-de-cliente, nome-da-empresa, endereço-de-cliente em detalhes-de-cliente resposta-a-alteração-de-cliente = “Alteração aceita” DI SPLAY resposta-a-alteração-de-cliente ENDIF END
PflSSO 3.1: PRODUZIR RE DE CAD@ BEGI N caixa = O DO WHILE houver registros em DINHEIRO READ próximo registro dinheiro 768 DISPLAY dinheiro caixa - caixa + valor END DO relatório-de-caixa - caixa DI SPLAY relatório-de-caixa END PROCESSO 3.2: PRODUZIR RELATÓRIO DA RECEI DIÁRIA BEGIN total-diário - O DO WHILE houver pedido em PEDIDOS com data-do-pedido = data-atual READ próximo pedido com data-do-pedido = data-atual ADD número-da-fatura, nomedo-cliente, nome-da- cpresa, total-do-pedido como uma nova linha em relatório-da-receita-diária ADD total-do-pedido a total-diário END DO ADD total-diário como uma nova linha em relatório-da- receita-diária DISPLAY relatório-da-receita-diária PROCESSO 3.3: PRODUZIR RELATÓRIO DA RECEI NSAL receita-total O total-da-devoluções O total-de-crédito - O DO WHILE houver pedido em PEDIDOS com data-do-pedido deste mês ADD total-do-pedido a receita-total END DO DO WHILE houver devoluçao em DEVOLU( com data-da davoluç*o deste mês ADD valor-da-devoluç a total-da-devoluções END DO DO WHILE houver créditos em CE com data-do-crédito deste mês
ADD valor-do-crédito a total-de-crédito END DO relatório-da-receita-mensal = receita-total, total-dadevoluções, total-da-crédito DISPLAY relatório-da-receita-mensal END 769 PROCZSSO 3.4: PRODUZIR RELATÕRIO TRI) DE DIREITOS BEGIN DO WHILE houver livro em LIVROS total-da-livros - O receita-total = O total-de-direitos - O BF.AD próximo registro livro DO WHILE houver pedido em PB com data-do-pedido deste trimestre READ próximo registro deste pedido DO WHILE houver itam-de-pedido em IT com numero-da-fatura igual a número-dafatura no registro pedido atual e código-de-livro igual a código-de-livro no registro livro atual READ itam-da-pedido seguinte ADD quantidade-pedida a total-de-livros esta-receita - quantidade-pedida * preço-unitário * das conto ADD esta-receita a receita-total ADD (esta-receita * taxa-da-direitos) a total-dedireitos APPEND ID-de-cliante, noma-da-cliente, número-da- fatura, esta-receita, (esta-receita * taxa-de- direitos) a próxima linha de relatório- trimestral-de-direitos END DO END DO DO WHILE houver crédito em tDITOS com código-de- livro igual a código-de-livro no registro livro atual e data-do-crédito deste trimestre READ crédito seguinte SUBTRACT quantidade-da-livros-do-crédito de total- de-livros SUBTRACT valor-de-crédito de receita-total SUBTRACT (valor-do-crédito * taxa-de-direitos) de total-de-direitos
APPEND ID-de-cliente, nome-de-cliente, número-da- fatura, valor-do-crédito, (valor-docrédito * taxa-de-direitos) à próxima linha de relatório- trimestral-da-direitos END DO DO WHILE houver devolução em DEVOLUÇÕES com código-da- livro igual a códigode-livro no registro livro atual e data-da-devolução deste trimestre READ devolução seguinte ST.JBTRACT quantidade-devolvida de total -de-livros SUBTBACT valor-da-devolução de receita-total SUBTRACT (valor-da-devolução * taxa-da-direitos) 770 de total-de-direitos APPEND ID-de-cliente, nome-de-cliente, número-da fatura, valor-da-davoluçào, (valorda-davoluçào * taxa-de-direitos) à próxima linha de relatório trimestral-da-direito3 END DO APPEND total-de-livros, receita-total, total-dedireitos à próxima linha de rai.atório-trixneatral d-direitos END DO DISPLAY relatório-trimeetral-da-direitos END PROCESSO 3.5: PRODUZIR RELATÓRIO DE INVENT BEGIN REPEAT UNTIL não haja livro em LIVROS READ próximo livro em LIVROS total-deinventário O REPEAT UNTIL não haja iten-de-inventário em ITENS-DE INVENT com código-delivro igual a código-delivro em livro ADD quantidade-da-inventário a total-de-inventário ADD ID-de-dapósito, código-de-livro, quantidade-de- inventário à próxima linha de relatório-dainventário END REPEAT ADD total-de-inventário à próxima linha de relatório- da-inventário END REPEAT END PRO 3.6: PP RELATÓRIO DE COMISSÕES DE VENDAS BEGIN
DO WHILE houver vendedor em VE2 REPJD próximo registro vendedor comissão-devendedor - O DO WHILE houver pedido em PEDIDOS com ID-de-vendedor igual a ID-de-vandedor em vendedor e com data-do-pedido deste mês READ registro pedido seguinte comissão taxa-de-comissão * total-do-pedido ADD comissão a comissão-de-vendedor APPEND ID-de-vendedor, número-da-fatura, comissão à próxima linha de relatório-da-comissões END DO APPEND comissão-de-vendedor à próxima linha de 771 relatório-d.-conu END DO END PRO(ZSSO 3.7: PRODUZIR DECLARAÇÕES BEGIN REPEAT tJNTIL não haja cliente em CLIENTES READ próximo registro cliente novo-saldo - saido-atual DO WHILE não haja pedido em P com ID-d-cliente ID-de-cliente no registro cliente atual e data-dopedido posterior a data-do-saldo-atual READ registro pedido seguinte ADD total-do-pedido a novo-saldo APPEND pedido à próxima linha de declaração END DO DO WHILE houver pagamento em PAGAZ. com ID-de-cliente - ID-de-cliente no registro cliente atual e data-do-pagamento posterior a data-do-saldo-atual READ registro pagamento seguinte SUBTRACT valor-total de novo-saldo IPPEND pagamento à próxima linha de declaração ENDDO
DO W}iILE houver reembolso em REEMBOLSOS com ID-de-cliente = ID-de-cliante no registro cliente atual e data-do-reembolso posterior a data-do- saldo-atual PEAD próximo registro reembolso ADD valor-do-reembolso a novo-saldo APPEND reembolso à próxima linha de declaração END DO DO WHILE houver crédito em CR com ID-da-cliente ID-de-cliente no registro cliente atual e data-do-crédito posterior a data-do-saldo-atual READ próximo registro crédito SUBTRACT valor-do-crédito de novo-saldo APPEND crédito à próxima linha de declaração END DO DO WHILE houver devolução em DEVOLUÇÕES com ID-da-cliente = ID-de-cliente no registro cliente atual e data-da-devolução posterior a data-do-saldo atual REAl) próximo registro devolução SUBTRACT valor-da-devolução de novo-saldo APPEND pagamento à próxima linha de declaração END DO 772 APPEND novo-saldo à próxima linha de declaração DISPLAY declaração SET data-do-saldo-atual no registro pedido atual na data atual SET saldo-atual no registro pedido atual em novo-saldo END REPEAT END PR 3.8: PRODUZIR REIÂT( DE CON’ A RECEBER BEGIN REPEAT UNTIL nâo haja cliente em .IENTES PEAD próximo registro cliente novosaldo saldo-atual DO WHILE houver pedido em PEDIDOS com ID-da-clienta =
ID-da---cliente no registro cliente atual e data-dopedido posterior a data-do-saldo-atual READ próximo registro pedido ADD total-do-pedido a novo-saldo END DO DO WHILE houver pagamento em PP. com ID-de-oliente = ID-da-cliante no registro cliente atual e data-do-pagamento posterior a data-do-saldo- atual READ próximo registro pagamento SUBTRACT valor-total de novo-saldo END DO DO WHILE houver reembolso em REEMBOLSOS com ID-de-clienta ID-de-cliente no registro cliente atual e data-da-reembolso posterior a data-do- saldo-atual READ próximo registro reembolso ADD valor-do-reembolso a novo-saldo END DO DO WHILE houver crédito em CRÉDITOS com ID-de-cliente = ID-de--cliente no registro cliente atual e data-docrédito posterior a data-do-saldo-atual READ próximo registro crédito SUBTRACT valor-do-crédito de novo-saldo APPEND crédito à próxima linha de declaração -END DO O WHILE houver devolução em DEVOLU com ID-da-cliente = ID-da-cliente no registro cliente atual e data-de-devolução posterior a data-do- saldo-atual REAl) próximo registro devolução SUBTRACT valor-da-devolução de novo-saldo END DO 773 END BEPEAT APPEND ID-da-cliente, novo-saldo â próxima linfla de relatório-da-contas-a-receber DI SPLAY relatório-da-contas-a--receber END PRO 4.1: RE CC71 DE c REGI N ACCEPT
(da
gráfica)
ID-de-gráfica, cotação-de-gráfica
DISPLAY
(à
direção)
ID-da-gráfica, cotação-de-gráfica
END PRO 4.2: ESENTAR PEDIDO DE I BEGI N FIND livro em LIV com código-de-livro igual a códigc da-livro em instruçôes-depedido-da-impras são IF registro não encontrado resposta-a-pedido-da-impressão - “Livro não existe” DI SPLAY resposta-a-pedido-de-impressão ELSE IF quantidada-a-iitprimir < O resposta-a-pedido-de-iitç - “Quantidade de impres5ão inválida” DI SPLAY resposta-a-pedido-de-impressão ELSE resposta-a-pedido-da-impressão - “Pedido de irnpress aceito” DI SPLAY resposta-a-pedido-da-impressão SET quantidade-pedida de livro em quantidade-aimprimir SET data-da-disponibilidade de livro em data-dedisponibilidade em instruções-da-pedido-de impres são WRITE registro livro pedido-da-impressão = código-da-livro + quantidade-a imprimir DI SPLAY pedido-da-impressão, ID-de-gráfica ENDIF END 1 F END PRO( 4.3: REVISAR PEDIDO DE LIVROS BEGI N FIND livro em LIVI com c go-da-livro igual a códigc da-livro em pedido-de-impressãorevisto 774 IF registro não encontrado rosposta-a-pedido-do-in
“Livro não
existe” DISPLAY resposta-a-pedido-da-impress&o-revisto ELSE Read registro livro Set quantidad. -podida n quant idada-revi ata Set data-da-disponibilidade em data-revi sta Write registro livro em LIV resposta -a-pedido-ixrçres são-revisto - “Pedido de impressão revisto OK” DISPLAY resposta-a-podido-da-impressão-revisto ENDIF END PRO 4.4: P FATURA DE .FICA BEGIN FIND livro em LIVROS com código-de-livro coincidindo com código-de-livro em fatura-de-gráfica IF registro não encontrado resposta-a-fatura-de-gráfica = “Não há pedidos pendentes desse livro” DISPLAY resposta-a-fatura-de-gráfica ELSE DISPLAY fatura-de--gráfica (à direção para aprovação) ACCEPT autorização-da-fatura-do-gráfica IF autorização-da-fatura-da-gráfica “SIM” resposta-a-fatura-de-gráfica - “Fatura rejeitada; favor consultar a direção” DISPLAY resposta-a-fatura-da-gráfica ELSE resposta-a-fatura-da-gráfica “Fatura aceita” DISPLAY resposta-a-fatura-do-gráfica fatura-do-gráfica-aprovada = fatura-de-gráfica DISPLAY fatura-da-gráfica-aprovada ENDIF ENDIF END PPO( 4.5: SOLICITP.R COTAÇÀO DE URÁFICA
BEGI N DO WHIIE houver gráfica em (i READ próximo registro gráfica IF gráfica igual a qualquer ID-de-gráfica na entrada desse processo solicitação-da-cotação = código-da-livro + 775 (quantidade) DI SPLAY solicitação-da-cotação ENDIF ENDDO END PRO 5: CRIAR NOVO REGISTRO DE LIVRO BEGIN DISPLAY (à direção) titulo-de-livro + solicitação-da- código-de-livro ACCEPT (da direção) código-da-livro DISPLAY (para aquisições) titulo-da-livro + solicitaçãc da-taxa-da-direitos ACCEPT (de aquisições) taxa-da-direitos DISPLAY (à comercialização) titulo-da-livro + solicitação-da-preço-unitário ACCEPT (da comercialização) preço-unitário livro = código-de-livro + titulo-da-livro + ID-da-autor taxa-da-direitos SET total-em-estoque em zero SET data-de-disponibilidad, em data-em-estoque APPEND livro em LIVROS END PRO
6.1:
PRODUZIR ETIQUETAS
POSTAIS
BEGIN SORT CLIENTES DISPLAY
por código-postal
em etiquetas-postais
etiquetas-postais
END PRO 6.2: PRODUZIR ESTATtSTICAS DE VENDAS BEGI N REPEAT UNTIL não haja livro em LIVROS receita-da-vendas = O devoluções-da -vendas O créditos-da-vendas = O
DO WHILE houver pedido em P com data-do-pedido posterior a data-da-vendas READ próximo registro pedido DO WHILE houver item-d.-pedido no registro pedido atual com código-de-livro códigoda-livro no registro livro atual READ próximo item-da-pedido ADD (quantidade-pedida * preço-unitário * dasconto a receita-da-vendas 776 END DO END DO DO WHILE houver devolução em DEVOLU( com data-da- devolução posterior a datade-vendas e código-de- livro - oódigo-d.-livro no registro livro atual ADD valor-da-devolução a devoluções-de-vendas END DO DO WHILE houver crédito em CRÉDITO com data-do-crédito posterior a data-devendas e código-de-livro = código-de-livro no registro livro atual ADD valor-do-crédito a créditos-de-vendas END DO APPEND código-de-livro, receita-da-vendas, devoluçõesde-vendas, créditos-de-vendas á próxima linha de estatisticas-de-vendas END REPEAT DISPLAY estatisticas-da-vendas PRC 6.3: PRCOUZIR DATA EM ESTOQUE BEGIN FIND LIVRO em LIVROS com código-de-livro coincidente IF registro n encontrado resposta-de-em-estoque = “Livro não existe” DI SPLAY resposta-de-em-estoque ELSE READ registro livro IF data-em-estoque = “nulo” resposta-de-em-estoque = “Não há remessas esperadas”
ELSE resposta-da-em-estoque = data-da-disponibilidade DISPLAY resposta-da-em-estoque ENDIF ENDIF END PRO(2SSO 6.4: REMOVER LIVRO REGI N FIND livro em LIVROS com código-de-livro co IF registro não encontrado resposta-a-ren = “Livro não existe” DISPLAY resposta-a-remoção-da-livro ELSE READ registro livro SET indicador-de-fora-da-impressão em SIM WRITE registro livro 777 resposta-a-re “Livro marcado como for de impressão” DI SPLAY resposta-a-remoçÀo-da-livro END 1 F END PRO 7.1: PR DOCUb DE R BEGIN REPEAT UNTIL não haja depósito em D PEãO próximo registro depósito *obs.: esta parte produz a lista de separação para o depósito* PEPEAT UNTIL não haja livro em LIV livros-a-separar = O DO WHILE houver pedido em PEDIDOS com data-clo-pedid = data-atual e ID-de-depósito coincidindo com ID-de-depósito no registro depósito atual READ próximo registro pedido DO WHILE houver itazn-de-padido com rum = número-da-fatura no registro pedido READ próximo regi stro item-de-pedido ADD quantidade-pedida a livros-a-separar
END DO END DO APPEND titulo-de-livro, livros-a-separar à próxima linha de documentos-da-remessa END REPEAT *obs.: esta parte produz as etiquetas_de_remessa* DO WHILE houver pedido em PEDIDOS com data-do-pedido data-atual e ID-de-depóeito = ID-de-depósito no registro depósito atual READ próximo registro pedido APPEND nome-da-cliente, endereço-da-cliente, número- da-fatura à próxima linha de documentos-de-remess END DO *obs.: esta parte produz uma cópia do pedido origina. para o depósito* DO WHILE houver pedido em PEDIDOS com data-do-pedido data-atual e ID-dedapósito = ID-de-depósito no registro depósito atual READ próximo registro pedido APPEND ID-da-cliante, data-do-pedido, despesas-da- remessa, imposto-sobre-vendas à próxima linha de documentos-de-remessa PEPEAT UNTIL não haja itein-de-pedido em IT PEDIDO com numero-da-fatura igual a número-dafatura no registro pedido atual 778 APPEND item-da-podido á próxima linha de documentos -da-rQmassa END REPEAT END DO END REPEAT END PRO 7.2: REGISTE7 REMESSA DE ÁFICA BEGIN FIND livro em LIV1 com titulo-da-livro coincidente IF registro nâo encontrado notificação-da-remessa = “Livro não existe” DISPLAY notificação-de-remessa
ELSE notificação-da-remessa “Recebido da gráfica” + código-da-livro + quantidade-recebida DISPLAY notificação-da-remessa READ registro livro ADD quantidade-recebida a total-em--estoque SET qyantidada-padida em zero WRITE registro livro em LIV READ item-da-inventário em ITENS-DE-INVENTÁRIO com ID-da-dapósito = “YONKERS” e código-da--livro coincidente ADD quantidade-recebida a quantidada-de-inventário WRITE registro item-da-inventário ENDIF END PRC 7.3: REGI STRJ DEVOLUÇÕES DE LIVROS DE CLIENTES BEGIN FIND cliente em CLIENTES com ID-da-clionta coincidindo com ID-de-cliente em informações-de-devoluções-de- livros ou com nu-da-cliente coincidindo com r client. em informações-de-devoluções-da-livros IF registro não encontrado instruções-de-devolução “Cliente não identificado; • aceitar livros, mesmo assim” • DISPLAY instruções-da-devolução ELSE FIND davolução-autorizada em DEVOLUÇÕES-AUTORIZADAS com aut-da-davolução-# igual a aut-de-devolução-# em informações-da-devoluções-de-livros IF registro não encontrado instruções-da-devolução = “Devolução não autorizada; favor remeter de volta” 779 DI SPL instruçÕes-da-davoluç autorizaçao-da-davoluç*o-da-livro “Esta devolução não está autorizada”
DISPLAY (para o cliente) autorizaçào-da-davoluçào-de livro EXI T ELSE instruções-da-devolução “Devolução autorizada” DI SPLAY instruções-da-devolução autorização-da-devolução-da--livro = “Esta devolução está autorizada” ENDIF ENDIF REPEAT UNTIL não haja código-da-livro em irifonsações-da devoluções-da-livros FIND itam-da-inventário em ITENS-DE-INVENTÁRI0 com ID-da-dapósito coincidente e com código-da-livro igual a código-da-livro em informações-da-devoluções- da-livros IF registro não encontrado instruções-da-devolução = “Livro não existe” DI SPLAY instruções-de-devolução ELSE READ registro item-da-inventário ADD quantidade-devolvida a quantidade-da-inventário WRITE registro item-da-inventário FIND livro em LIV com ID-da-livro coincidente READ registro livro ADD quantidade -devolvida a total-em-estoque WRITE registro livro END 1 F END REPEAT APPEND informaçôas-da-devoluções -da-livros em DEVOLUÇÕES END PROCESSO 7.4: REGISTRAR INVENTÁRIO FfSICO BEGIN FIND depósito em D com ID-de-depósito coincidente IF registro não encontrado reaposta-a-inv-fisico “Depósito não existe” DISPLAY reaposta-a-inv-fisico ELSE PEPF.AT tJNTIL não haja detalhe-da-inventário em contagem-de-inventário
FIND item-de-invantário em ITENS-DE-INVENTÁRIO com ID-da-dapósito e código-da-livro coincidentes IF registro não encontrado 780 resposta-a-inv-fisico = “Código de livro inválido” + DISPLAY resposta-a-inv-fisico ELSE dif quantidade-de-inventário - contagem-fisica SET quantidade-da-inventário em contagem-fisica FIND livro em LIVROS com código-de--livro coincidente READ registro livro SUBTRACT dif de total-em-estoque DO WHILE houver pedido em PEDIDOS com data-do- pedido posterior a na-data e com ID-de-dapósito coincidente REJ registro pedido DO WHILE houver itam-de-pedido em ITENS-DE PEDIDO com código-de-livro = código-de-livro em detalhe-da-inventário e número-da-fatura = número-da-fatura em pedido READ item-da-pedido SUBTRACT quantidade-pedida da quantidade-deinventário SUBTRACT quantidade-pedida de total-emestoque END DO END DO WRITE registro item-de-inventário WRITE registro livro ENDIF END REPEAT ENDIF END PRO( 7.5: REGISTRAR R REAL BEGIN FIND pedido em PEDIDOS com numero-da-fatura coincidente IF registro não encontrado resposta-de-remessa = “Pedido não encontrado” DISPLAY resposta-da-remessa ELSE
PEAD registro pedido SET data-da-remessa em data-atual WRITE registro pedido ENDIF END 781 PRO 7.6: RESPONDER A FPILTA DE ESTOQUE BEGI N FIND livro em LIVROS com titulo-da-livro coincidente IF registro não encontrado resposta-a-fora-da-estoque = “Livro não existe” DISPLAY resposta-a-fora-de-estoque ELSE READ registro livro para obter código-da--livro FIND itein-de-inventário em ITENS-DE-INVENT1 com ID-de-dapósito coincidente e código-da-livro coincidente IF registro não encontrado resposta-a-fora-de-estoque = “Erro: item de inventário não encontrado” ELSE READ item-da-invontário SET quantidade-de-inventário em zero WRITE item-de-invantário resposta-a-fora-de-estoque
“Mensagem de falta de
estoque recebida” ENDIF END 1 F END PROCESSO 8.1: PRODUZIR RELA DE DIREITOS AUTORAIS BEGIN DO WHILE houver livro em LIVROS total-de-livros O receita-total = O
total-de-direitos = O PEAD próximo registro livro DO WHILE houver podido em P com data-do-pedido deste trimestre READ próximo registro podido DO WHILE houver itezu-de-podido em ITENS-DE-PEDIDO con numero-da-fatura igual a número-da -fatura no registro podido atual e código-de-livro igual a código-de-livro no registro livro atual PEAD próximo itom-de-podido ADD quantidade-pedida a total-de-livros esta-receita = quantidade-pedida * preço-unitário * desconto ADD esta-receita a receita-total ADD (esta-receita * taxa-de-direitos) a total-dedireitos END DO END DO 782 DO WHILE houver crédito em ÉDITOS com código-da-livro igual a código-da-livro no registro livro atual e data-do-crédito deste trimestre READ próximo crédito SUBTRACT quantidade-da-livros-do-crédito de total-de- livros SUBTRACT val.or-do-crédito de receita-total SUBTRACT (valor-do-crédito * taxa-da-direitos) de total-de-direitos END DO DO WHILE houver devolução em DEVOLUÇÕES com código-da- livro igual a códigoda-livro no registro livro atual e data-da-devolução deste trimestre RFJ’.D próximo registro devolução SUBTRACT quantidade-devolvida de total-de--livros SUBTRACT valor-da-devolução de receita-total SUBTPACT (valor-da-devolução * taxa-da-direitos) de total-de-direitos END DO APPEND total-de-livros, receita-total, total-de- direitos à próxima linha de relatÓrio-dadireitos autorais END DO DISPLAY relatório-da-direitos-autorais END
PRO 8.2: INFORMAR CONTABILIDADE DE ADLAJ DE DIREITOS BEGIN FINO autor em AUTORES com ID-da-autor igual a 10-da-autor em solicitação-da-adiantamento-da-direitos IF registro não encontrado resposta-de-adiantamento = “Autor não existe” DISPLAY resposta-da-adiantamento ELSE FINO livro em LIV1 com código-da-livro igual a código-da-livro em solicitação-da-adiantamento-dedireitos • IF registro não encontrado •
resposta-da-adiantamento
“Livro não existe”
DISPLAY resposta-da-adiantamento ELSE sóli zação-da-adiantamento = solicitação-da-adiantamento-de-direitos DISPIAY (para a direção) solicitação-de-autorizaçãoda-adiantamento ACCEPT (da direção) resposta-da-autorização-de783 adiantamento IF resposta-de_autorização -de = “Sim” rasposta-de-adjan = “Adiantamento aprovado DI SPLAY resposta-d.-adjant DISPLAY (para a Contabilidade) solicitação-de Cheque-da-adiantamento PEAD registro autor ADD valor-do-adjant a saldo-da-direitos WRITE registro autor ELSE reaposta-da-adja “Adiantamento negado” DISPLAY reaposta-da-adiant END 1 F
ENDIF ENDIF END PRO 8.3: ALT DETM DE AUTOR BEGI N FIND autor em AUTORES com ID-de-autor coincidente IF registro não encontrado WRITE detalhes-de-autor em autor END 1 E’ END 784 NOTAS Entrementes, as atividades de processamento de informações da Prentice-Hall estão subordinadas à sua nova empresa proprietária, Simon & Schuster que, por sua vez, faz parte de uma empresa ainda maior, a Gulf + Western, o que serve para demonstrar que os sistemas são quase sempre parte de sistemas maiores. 2 Quando investigamos, descobrimos que a Supermarket Products estava localizada na periferia da cidade de Nova lorque e ocupava- se principalmente da importação de bananas da Guatemala. Não entendemos o que isso tinha a ver com computadores nem por que o estado decidiu que nosso nome poderia prejudicar a pobre Supermarket Products, mas resolvemos não enfrentar a burocracia. 3 O UNIX, naturalmente, já não é mais tão misterioso agora, mas, em meados dos anos 70, dificilmente alguém estranho aos Laboratórios Beli e a algumas universidades já teriam ouvido falar nele. Nem eu, nem a maior parte de meus colegas da YOURDON estávamos tão prescientes: nós devemos essa decisão, que mais tarde viemos a muito apreciar, à insistência do Dr. P. J. Plauger, que veio para a empresa, proveniente da Bell Labs em 1975. Plauger é amplamente conhecido por seus livros cm co-autoria com Brian Kernighan, como The Elements of Programmin Style (Reading, Mass.: Addison-Wesley, 1973) e Software Tools (Nova lorque: McGraw- Hill, 1976). 4 A questão dos inventários separados, e vendas de escritórios sepa rados, começava a assomar no horizonte como um problema cada vez maior. Cada um dos diversos escritórios da YOURDON insistia na necessidade de ter um pequeno estoque local para atender os clientes eventuais que desejassem poder adquirir um livro imedia tamente, em vez de terem de aguardar vários dias (ou semanas) por uma remessa do Quartel General da Galáxia, O escritório cana dense reclamava a necessidade de sua própria estrutura de preços (isto é, preços estabelecidos em dólares canadenses, em vez de dólares americanos) e sua própria campanha publicitária para quistar o mercado canadense de forma diferente em relação ao mercado americano. Em alguns casos, os escritórios remotos sim plesmente entregavam o livro ao cliente e solicitavam ao escritório
• central cm Nova lorque que gerasse a fatura. Em outros casos, o cliente pagava o livro à vista, e solicitava recibo. As vendas do escritório londrino representavam cerca de 10% da receita total da YOURDON Press, enquanto as dos demais escritórios respondiam por menos de 1% da receita total da empresa. 785 L G ESTUDO DE CASO: O PROBLEMA DO ELEVA1 G. 1 INTRODUÇÃO Este apêndice mostra o modelo essencial para um escalonador e controlador de elevadores. Seu principal objetivo é ilustrar o uso dos modelos da análise estruturada para sistemas de tempo real; você verá exemplos de fluxos de controle, de processos de controle e de diagra mas de transições de estado que normalmente não seriam utilizados em uni sistema comercial. Na próxima seção é apresentada uma descrição narrativa do pro blema. Em seguida vêm os vários diagramas que compõem o modelo essencial, o dicionário de dados e as especificações de processos. Obser ve que a maioria das especificações de processos utiliza a abordagem pré-condição/pós-condição discutida no capítuL3 11. O problema dos elevadores foi usado em um programa educacio nal patrocinado pela divisão da ACM em Washington, D. C. em 1986. Os modelos aqui apresentados foram desenvolvidos originalmente por Dennis Stipe, na época na YOURDON Inc. Os diagramas de fluxo de dados e o dicionário de dados foram produzidos em um computador Macintosh II com o MacBubbles da StarSys, Inc.: os diagramas de transi ções de estado foram produzidos com o MacDraw. É importante notar como os diagramas deste capítulo são diferentes dos diagramas do apêndice E, que foram produzidos pelo Design da Meta Software. MacBubbles é um produto CASE especificamente prepa rado para desenhar diagramas de fluxo de dados (com equilíbrio entre diagramas pais e filhos etc.). I)esign é um programa de desenho de emprego geral orientado para o objeto, que pode ser utilizado para desenhar fluxogramas, diagramas de fluxo de dados e virtualmente qualquer outro diagrama de software. Sob o ponto de vista da estética, os diagramas produzidos pelos dois programas são muito diferentes; Penso que os editores que produziram este livro prefeririam um 787 confiável artista humano a ambos os pacotes. Como foi dito no capítu lo 9, o estilo e formato de diagramas dc fluxo dc dados pode ser uma questão sensível para muitos usuários; quando você comparar os apêndices F e G você verá porquê. G.2
UMA DESCRIÇÃO NARRATIVA
O requisito geral é projetar e implementar um programa para esca lonar e controlar quatro
elevadores dc um edificio de 40 andares. Os elevadores serão usados para transportar pessoas entre os andares na forma convencional. Eficiência. O programa deve escalonar os elevadores de maneira eficiente e racional. Por exemplo, se alguém chamar um elevador aper tando o botão de descida no quarto andar, o primeiro elevador que passar descendo pelo quarto andar deve parar para embarcar o(s) passageiro(s). Por outro lado, se um elevador estiver sem passageiros (sem chamadas pendentes) deve permanecer parado no último andar por onde passou até que seja novamente solicitado. Um elevador não deve inverter o sentido de seu movimento até que os passageiros que quiserem transitar no sentido atual tenham atingido seus respectivos destinos (como veremos adiante, o programa não tem como saber quan tos pas.sageíros realmente estão no elevador; ele só tem informações sobre os botões de destino que foram apertados para um determinado elevador. Por exemplo, se algum passageiro nocivo e anti-social tomar o elevador no primeiro andar e apertar os botões do quarto, quinto e vigésimo andares, o programa fará com que o elevador ande e pare no quarto, no quinto e no vigésimo andar. O computador e o programa não têm informações sobre os embarques e desembarques reais de passagei ros). Um elevador que esteja com a lotação esgotada não deve atender a qualquer novo chamado (existe um sensor de excesso dc peso para cada elevador. O computador e o programa podem interrogar esses sensores). Botão de destino: Cada elevador possui em seu interior um painel contendo 40 botões, um botão para cada andar, marcados com os núme ros dos andares (1 a 40). Esses boties de destino podem ser iluminados por sinais enviados do computador para o painel. Quando um passagei ro pressiona um botão de destino ainda não iluminado, o circuito por trás do painel envia uma interrupção ao computador (há uma interrupção separada para cada elevador). Quando o computador rece be um desses sinais de interrupção (vetorizados), o programa lê os adequados registradores de entradas dc oito hits mapeados na memória 788 (um para cada interrupção, portanto um para cada elevador) que contêm o número do andar correspondente ao botão dc destino que causou a interrupção. Naturalmente, o circuito por trás do painel escreve o número do andar no apropriado registrador de entrada mapeado na memória quando ele provoca a interrupção vetorizada (como existem 40 andares nesta aplicação, somente os seis primeiros bits de cada re gistrador de entrada serão utilizados pela implementação; porém o hardware suportaria um edifício com até 256 andares). Luzes dos botões de destino: Como já foi dito, os botões de destino podem ser iluminados (por lâmpadas atrás dos painéis). Quando a rotina de serviço de interrupções do programa recebe uma interrupção de bo tão de destino, ela deve remeter um sinal para que o painel adequado ilumine aquele botão. Esse sinal é enviado pelo carregamento, feito pelo programa, do número do botão no adequado registrador de saída ma peado na memória (existe um registrador desse tipo para cada elevador). A iluminação de um botão informa ao(s) passageiro(s) que o sistema já anotou o pedido e impede também outras interrupções causadas por novos (impacientes?) acionamentos do botão. Quando o controlador pára um elevador em um andar, ele deve enviar um sinal para o painel do seu botão de destino para desligar o botão de destino relativo àquele andar.
Sensores de andar: Existe uma chave sensora de andar para cada andar de cada poço de elevador. Quando um elevador está a oito pole gadas de um andar, uma roda do elevador atinge a chave daquele andar e envia uma interrupção ao computador (existe uma interrupção separa da para o conjunto de chaves em cada poço de elevador. Quando o elevador recebe uma dessas interrupções (vetorizadas), o programa lê o adequado registrador de entrada de oito bits mapeado na memória (exis te um para cada interrupção, portanto um para cada elevador) que contém o número do andar correspondente à chave sensora de andar que provocou a interrupção. Luzes de chegada. O interior de cada elevador contém um painel com um indicador luminoso para cada número de andar. Esse painel localiza-se logo acima das portas. Seu objetivo é informar aos passagei ros do elevador o número do andar ao qual o elevador está chegando (e no qual ele poderá parar). O programa deve iluminar o indicador de um andar quando chegar a esse andar e apagá-lo quando sair desse andar ou chegar a outro andar, O sinal é remetido pelo carregamento, pelo programa, do número do indicador do andar no adequado registrador de saída mapeado na memória (há um registrador para cada elevador). 789 Botões de chamada: Cada andar du edifido possui um painel q contém botões de chamada. Cada andar, excetuando o térreo (P andar e o último (4 andar) apresenta um painel contendo dois botões dc chamada, um com a indicação SOBE e o outro com a indicação 1)ESCE. O painel de chamada do andar térreo tem apenas o botão SOBE e c último andar tem apenas o botão DESCE. Assim, existem 78 botões dc chamada no total, 39 botões SOBE e 39 botões I)ESCE. As pessoas aper tam esses botões para chamar um elevador (é claro que uma pessoa não pode chamar um determinado elevador. O escalonador decide qual ele vador deverá atender a um chamado). Os boiões dc chamada podem ser iluminados por sinais enviados do computador para o painel. Quando um passageiro pressiona um botão de chamada ainda não iluminado, o circuito por trás do painel remete uma interrupção vetorizada para o computador (há uma interrupção para os botões SOBE e outra para os botões DESCE). Quando o computador recebe uma dessas duas inter rupÇÕeS (vetorizadas), o programa lê o adequado registrador de entrada de oito bits mapeado na memória que contém o número do andar cor respondente ao botão de chamada que provocou a interrupção. Natural mente, o circuito por trás do painel escreve o número do andar no adequado registrador de entrada mapeado na memória quando ele causa a interrupção vetorizada. Luzes dos botões de chamada: Os botões de chamada podem ser iluminados (por lâmpadas atrás do painel). Quando a rotina de serviço de interrupções do botão de chamada recebe uma interrupção vetoriza da de um botão SOBE ou DESCE, ela deve enviar um sinal ao painel apropriado para iluminar o boião adequado. Esse sinal é remetido pelo carregamento, pelo programa, do número do botão no adequado regis trador de saída mapeado na memória, um para os botões SOBE e outro para os botões DESCE. A iluminação de um botão informa ao(s) passageiro(s) que o sistema já anotou o pedido e impede também outras interrupções causadas por novos acionamentos do botão. Quando o controlador pára um elevador em um andar, ele deve enviar um sinal para o painel do botão de chamada do andar para desligar o botão (SOBE ou DESCE) adequado para aquele andar.
Controles de motor de elevador (Sobe, Desce, Pára): Existe uma palavra de controle mapeada na memória para cada motor de elevador. O bit O dessa palavra comanda a subida do elevador, o bit 1 comanda a descida e o bit 2 comanda a parada do elevador no andar cuja chave sensora esteja fechada. O mecanismo do elevador não obedece a qual quer comando inadequado ou perigoso. Se não houver uma chave sen sora de andar fechada quando o compulador emitir um sinal de parada, o mecanismo do elevador vai ignorar, esse sinal até que uma chave 790 sensora de andar seja fechada. O programa não tem de se preocupar com o controle das portas de um elevador ou parar o elevador exata mente no nível (base) de um andar, O fabricante do elevador utiliza chaves, relés, circuitos e engrenagens de segurança convencionais para aquelas finalida’des de forma que ele pode garantir a segurança dos elevadores independentemente do controlador do computador. Por exemplo, se o computador emitir um comando de parada para um eleva dor quando este está a oito polegadas de um piso (de modo que a chave sensora de andar esteja fechada), o mecanismo convencional, aprovado, pára e nivela o elevador naquele andar, abre as portas e as segura ade quadamente, e em seguida as fecha. Se o computador emitir um coman do de subida ou descida durante esse período (enquanto a porta está aberta, por exemplo), o mecanismo do fabricante ignora esse comando até que as condições para a movimentação sejam satisfeitas (dessa for ma, é seguro que o computador emita um comando dc subida ou desci da enquanto a porta do elevador esteja aberta). Uma condição para o movimento de um elevador é que o boião deparada não seja apertado. O painel de boiões de destino de cada elevador contém um botão de parada. Esse botão não leva ao computador. Sua única finalidade é segu rar um elevador em um andar com as portas abertas enquanto esse elevador estiver parado no andar. Uma chave deparada de emergência, vermelha, páça e prende o elevador no andar seguinte a que ele atin gir independentemente da escala do computador. A chave vermelha também aciona um alarme audível. Essa chave não está interligada ao computador. Máquina alvo O escalonador e o controlador do elevador podem ser implementados para qualquer microcomputador contemporâneo que seja capaz de manipular esta aplicação. 791 Diagrama de Contexto Modelo Essencial do Elevador 792 G.3
O MODELO ESSENCIAL ______
Sensor de Andar - _J________ 793 Diagrama de Contexto Expandido
Lista de Eventos 1. Passageiro emite chamada de subida. 2. Passageiro emite chamada de descida. 3. Elevador atinge andar da chamada. 4. Elevador não disponível para chamadas. 5. Elevador torna-se disponível para chamadas. 6. Passageiro emite solicitação dc destino. 7. Elevador atinge destino solicitado. 8. Elevador chega a um andar. 9. Elevador abandona um andar. 10. Elevador não se movimenta (sai do serviço). 11. Elevador retorna ao serviço normal. 12. Elevador sobrecarregado. 13. Carga do elevador torna-se normal. 794 S escalonamentos-de.dest gil 2
tivar/desatjvar-s
i
Controlar ‘
andar .ØJ
A
Elevador -
‘ /• c ‘00 -
0l
/ Figura O: Escalonar e controlar elevador modelo essencial do elevador solicitações 1% lo. , 795 Situações -de-e levador % ‘e
Ordens-de-movimento
Solicitações
Figura 1: Armazenar e exibir soliciiação 796 S / Controlar 1
atiVaId
ordemde r -
e\ - - lato ‘o 1< ‘3 g ‘o o. ordem-de-movimento Figura 1.1: Gerenciar ordem de movi rnento 797 Ativar Armazenar Ordem de Movimento Ativar Exigir Ordem de Movimento Chamada Inativa Ordem de Movimento Introduzida
Andar Atingic
Sinalizar Entrada de Movimento Recebida Disparar Lim Chamada Coi Figura 1.1.1; Controlar ordem de movimento 798 Ativar Armazenar Solicitação de Destino Ativar Exibir Solicitação de Destino Destino Inativo Solicitação de Destino Introduzida Andar Atingido Sinalizar Solicitação de Destino Recebida
Disparar Limpar
Destinos Completados
Figura 1.2.1: Controlar solicitação de destino 799 o 1_
1.2.1 • Controlar
ativar!
‘ Solicitaçâo de Destino /
r
Io_
s
i9Q. 1< Ic
•
1 -, o ,
1
e Solicitações-de-destino Figura 1.2: Gerenciar solicita ção de destino 800 - ‘ ti ---
S
- sobr - - dest - - Figura 2: Co;1 rolar elevador 801 .. .‘í_ Figura 2.1: Gerenciar destino de elevador 802 Destino Inativo Destinos Pendentes Recebidos Ativar Determinar Direção Solicitada
Destino Final Atingido
Desativar Determinar Direção
Solicitada
Ativar Referenciar Chegada Sinalizar Escalonamento
a Andar
de Destino Completado
Ativar Determinar Destino
Desativas Gerenciar Chegada
Final a Andar Desativar Determinar Destino Final Destinos Pendentes Figura 2.1.1: Controlar destino 803 Situaçóes.de-elevacjor Figura 2.2: Gerenciar chegada a andar 804 escajonamentosdedestjno IL Limpar controle de subida do elevador Limpar controle de descida do elevador Ajustar controle de parada do elevador Ativar monitorar chegada a andar Ajustar estacionar Ativar armazenar situação do elevador ESTACIONADO DESTINO SOBE controle de parada do elevador Limpar estacionar-elevador controle de subida do elevador ir monitorar evento do elevador ESCALONAMENTO DE DESTINO COMPLETADO Ajustar estacionar-elevador DESTINO DESCE SUBINDO ANDAR NÃO NO ANDAR DESEJADO Sinalizar andar atingido
Disparar determinar andar desejad9 __
1
DESTINO SOBE Dispara determinar andar desejado DEST. ATINGIDO npar controle de bida do elevador ustar controle de rada do elevador sativar monitorar coto do elevador, Limpar controle de parada do elevador Limpar estacionar elevador Ajustar controle de descida do elevador Ativar monitorar movimento do elevador [
DESCENDO
ANDAR NÃO NO ANDAR DESEJADO Sinalizar andar desejado __
1
DESTINO DESCE INTERVALO DE MOVIMENTO Limpar controle de parada do elevador Ajuslar controle de subida do elevador Ativar monitorar movimento do elevador AND. DEST. ATINGIDO Limpar controle de descida do elevador Ajustar controle de parada do elevador Desativar monitorar movimento do elevador ITERVALO DE MOVIMENTO nalizar fora de serviço nalizar reescalonar elevador Limpar controle de parada do elevador Ajustar controle de descida do elevador Ativar monitorar movimento do elevador PARADO NO ANDAR
-1
Sinalizar do volta ao serviço NO ANDAR Sinalizar de volta ao serviço FORA-DE-SERVIÇO-SOBE Sinalizar fora de serviço Sinalizar escalonar elevador Figura 2.2.1: Mover elevador para andar FORA DE SERVIÇO-DESCE 805 Ordens-de-movimento Solicitações-de..Oestino Figura 3: Escalonar elevador 806 Situações-de-elevador o 5 Is Ic / Figura 3.1: Gerenciar escalonamento de chamadas 807 Ordens-de-Movimento %0 % ões-de-Elevador REESCALONAR ELEVADOR Disparar limpar chamados Disparar escalonar chamadas Escalonamento Inativo MOVIMENTO RECEBIDA - ELEVADOR NÃO DISPONÍVEL Disparar escalonar chamadas Escalonamento de Chamadas Pendentes -
!scalonamento de Chamadas
ANDAR ATINGIDO Disparar escalonar cha
ELEVADOR SELECIONADO Sinalizar escalonamento de chamadas pendentes Figura 3.1.2: Controlar escalonamento de chamadas 808 3.2.1 % g Controlar “ 1 Escalonamento - .
) de Destino g
1
__________________
-
-
1 ‘o t ‘3 1 / Solicitações-de-Destino Escalonamentos-de-Destino Situações-de-E levador Figura 3.2: Gerenciar escalonamento de destinos 809 Inativo SOLICITAÇÃO DE DESTINO RECEBIDA ANDAR ATINGIDO Disparar escalonar
Disparar atualizar escaIoname
solicitação de destino de destinos Sinalizar escalonamento de destinos pendentes Figura 3.2.1: Controlar escalonamento de destinos 810 DICIONÁRIO DE DADOS DO
SISTEMA DE CONTROLE DE ELEVADORES andar-atual = valores: 1-40 OBS. : número do andar onde um elevador está andar-da-destino = valores: 1-40 OBS. : números do5 andares onde um elevador deve parar andar-desejado-alcançado OBS.: sinal andar-do-elevador = valores: 1-40 chamadas OBS. : ***Entrada Gerada*** chamadas-pendantes valores: [ 1 off] controle-de-descida-da-elevador OBS.: sinal para o hardware controle-da-parada-da -elevador OBS. : sinal para o hardware controle-da-subida-da-elevador OBS.: sinal para o hardware descendo OBS.: ***Entrada Gerada*** destino-desce OBS.: sinal de que a direção solicitada e descer destino-direção = [ destino-desce] destino-pendente = valores: [ OBS.: indicação de que o elevador tem mais destinos além do andar atual destino - sobe OBS. : ***Entrada Gerada*** 811 destinos-pendantes = (chamadas-pendentes 1 destino- pendente 1 chamadas-pendentes + destino-pendente] OBS. : sinal de que existe um escalonamento de destinos di ração-da sce
OBS. : ***Entrada Gerada*** direção-sobe OBS.: ***Entrada Gerada*** elevador-não-disponivel OBS. : sinal de que um elevador não está disponível para atender a uma chamada avador- selecionado OBS.: sinal de que um elevador foi escalado para uma chamada escalonamento-da-destino = @número-do-elevadcr+ { andar-de- destino }+origem-dasolicitação +dest inação-pendente escalonam ntoa-de-d.stino = {escalonamento-de-destino} estacionado OBS.: sinal estado-da-elevador = (estacionado subindo 1 descendo 1 parado 1 fora-de-serviço] fora-de-serviço OBS.: sinal de que o elevador falhou em reagir ao comando de movimento indicação-da-chamada = valores: 1-40 OBS. : indicação de números dos andares em que um elevador está escalado para parar indicação-da-chegada valores: 1-40 OBS. : indicação do andar ao qual o elevador chegou dicação-da-destino = valores: 1-40 OBS. : indicação dos números dos andares onde o elevador deve parar 812 no-andar OBS. : sinal de que o elevador atingiu um andar núi = valores: 1-40
OBS.: ***Entrada Gerada*** númQro-da-.1.vador = valores: 1-4 OBS. : ***Entrada Gerada*** OBS. : ***Entrada Gerada*** ord = @andar-do-elevador + [ direção-desce 1 direção-sobe + direção -desce] + número-de-elevador ordem-de-moviz OBS.: sinal ord.m-d. -movimento -recebida OBS.: sinal ordens-d = {ordem-de-movimento} parado OBS. : ***Entrada Gerada*** reescalonar-elevador OBS. : sinal para iniciar o reescalonarnento de chamadas para um elevador com defeito sjnal_de_controle_de_elevadorcontroledesUbidade- elevador+contro elevador+controledeparadade elevador situações-de-elevador = {situação-de-elevador} sobrecarga OBS.: sinal do hardware solicitação-de-destino = @núrnero-do-elevador+ [ andar 813 OBS.: sinal de que um passageiro introduzi solicitação aolicitaç&o-d-d OBS.: sinal de que a solicitação está pron ta para escalonamento solicitaçio-origem = [ 1 andar-de-destino chamada + andar-de-destino] solicitaçao-r = ordem-de-movimento-recebida + solicitação-de-destino-recebj so].icitaçô8
ordens-de-movimento + solicitações-de
destino soliCitações-de-destino
{ solicitaçào-de-destino}
situação-de-elevador =
@número-de-elevador+estado-de
elevador+andar-atual subindo OBS.: ***Entrada Gerada*** valores OBS. : ***Entrada Gerada*** 814 L Espeqficações de Processos 1.1.2 ARNAZEN7 ORDEM DE MOVIMENTO Pré-condição entrada-da-ordem-da-movimento
ocorra
Pós-condição entrada-de-ordem-de-movimento
seja armazenada
ordem-da-movimento-introduzida
seja produzida
1.1.3 LIMPAR CHAMADA COMPLETADA Pré-condição Existe um n em situações-da- elevador que coincide com número-da-elevador- designado em ordem-da--movimento e Existe um correspondente andar-atual em situações-de-elevador que coincide com número- de-andar em ordens-da-movimento Pós-condição A entrada correspondente em ordem-de-movimento é nula 1.1.4 EXIBIR ORDEM DE MOVIMENTO Pré-condição Nenhuma Pós-condição Que as ordens-de-movimento estejam exibidas 1.2.3 LIMPAR DESTINOS ATINGIDOS
Pré-condição Existe um numero-de-elevador em situações-de- elevador que coincide com numero-deelevador em solicitações-de-destino e Existe um correspondente andar-atual em situações-de-elevador que coincide com numero- da-andar em solicitações-de-destino Pós-condição A entrada correspondente em solicitações-de- destino é nula 1.2.4 EXIBIR SOLICITAÇÃO DE DESTINO Pré-condição Nenhuma Pós-condição Que as solicitações-da-destino estejam exibidas 815 2.1.2 DETERMINAR DESTINO FINAL Pré-condição Existe um numero-de-elevador em situações-deelevador que coincide com numero-de-elevador em escalonamentos-de-destino e Existe um correspondente andar-atual em situações-da-elevador que coincide com andar-dedestino em escalonamantos-de-deatino e destino-pendente correspondente = 0ff em escalonamentos -da-destino Pós-condição destino-final-atingido seja produzido 2.1.3 DETERMINAR DIREÇÃO SOLICITADA O termo local igual é um numero-de-elevador coincidente em escalonamantos -de-destino e numero-de-elevador em situação-da-elevador Pré-condição 1
igual existe e Existe em escalonamentos-de-destino um andar-de- destino > andar-corrente em situaçãode-elevador Pós-condição 1 destino-sobe seja produzido Pré-condição 2 igual existe e Existe em escalonamentos -de-destino um andar-de- destino < andar-corrente em situação-de-elevador Pós-condição 2 destino-desce seja produzido 2.2.2 MONITORAR CHEGADA A ANDAR Pré-condição 1 andar ocorra Pós-condicão 1 indicação-de-chegada esteja limpa em relação a andar anterior e indicação-de-chegada seja produzida para andar corre spondente e no-andar seja produzido e andar-atual seja atualizado em situações-de- elevador 816 2.2.3 MONITORAR MOVIMENTO DE ELEVADOR andar-atual é lido de situações-de-elevador Pré-condição passam-se 10 segundos sem que andar-atual se modifique Pós-condição intervalo-da-movimento ocorre 2.2.4 ARMAZENAR SITUAÇÃO DE ELEVADOR Pré-condição que seja recebido um sinal de entrada Pós-condição estado-de-elevador seja atualizado em situação- da-elevador 2.2.5 DETERMINAR ANDAR DESEJADO
Pré-condição Existe um numero-de-elevador em situações-da- elevador que coincide com número-daelevador em situações -da-da stino e Existe um correspondente andar-atual em situações-da-elevador que coincide com andarda- destino em escalonamentos-de-dastino Pós-condição andar-desejado-atingido seja produzido 3.1.1 ESCALONAR CHAMADAS BEGIN com ordem-de-movimento, situação-da-elevador e sobrecarga DO WHILE elevador-selecionado não tenha sido sinalizado Encontrar elevador mais próximo IF elevador está se movendo na direção correta ou elevador está estacionado IF elevador não está sobrecarregado introduza ordem-da-movimento por número -de-elevador em escalonamento-de-destino ajuste solicitação-origem em chamada ou em chamada + destino ENDIF IF destinação-pendente = off faça destinação-pendente = on END 1 F sinalize elevador-selecionado ELSE Encontre elevador mais próximo 817 END DO IF nenhum elevador encontrado Sinalize elevador não disponivel ENDIF END 3.1.3 LIMPAR DESTINOS CHAMADOS
Pré-condição Existe um número-de-elevador em situações-da- elevador que coincide com número-daelevador em escalonamento. -de-destino e o correspondente estado-da-elevador = fora-de- serviço em situações-da-elevador e a correspondente solicitação-origem = chamada em escalonamentos-cie-dastino Pós-condição As entradas correspondentes de andar-da-destino são nulas 3.2.2 ESCALONAR SOLICITAÇÃO DE DESTINO Pré-condição Nenhuma Pós-condição escalonamentos-de-dastino seja atualizado por solicitações-de-destino
coincidindo com número-
da-elevador Faça solicitação-origem
= destino ou chanada +
destino IF destino-pendente =oU Faça destino-pendente = off ENDIF 3.2.3 ATUALIZAR ESCALONAMENTO DE DESTINO Pré-condição 1 Existe um numero-da-elevador em situações-da- elevador que coincide com número-deelevador em escalonamento. -de-destino e Existe um correspondente andar-atual em situações-de-elevador que coincide com andarde- destino em escalonamento-de-destino Pós-condição 1 a entrada correspondente de andar-de-destino é nula Pré-condição 2 mesma condição da pré-condição 1
818 e nenhun outra correspondente entrada de andar- da-daatino esteja presente Pós-condiçâo 2 a entrada correspondente de andar-da-destino é nula e o correspondente daatino-pondonta seja ajustada em off 819 ÍNDICE A Abordagem de modelagem clássica, 39297 fracasso da, 392-97 modelo físico atual, 392 modelo físico novo, 392-93 modelo lógico atual, 392 modelo lógico novo, 392 pressuposições, 395 Abordagem top-down no modelo comportamental, 440-42 fenômeno dos seis analistas, 44041 paralisação da análise, 440 subdivisão física arbitrária, 441 Ações, estados, 326 ADABAS sistema de gerenciamento de bancos de dados, 247, 290 Ambiente, sistemas de tempo real, 31 Análise de benefícios, 633-36 benefícios estratégicos do novo sis tema, 636-37 benefícios táticos, 634-36
Análise de riscos, 641-43 Análise estruturada, 151-64, 581 advento das ferramentas automati zadas de análise, 157-59 backlog (demanda) de aplicações, 132-39 cálculos de custo/benefício, 623-44 caminhamentos, 543, 645-53 caminhamentos de análise, 646-53 ciclo devida da prototipação, 98,12024 ciclo de vida do projeto, 97-129 ciclo de vida do projeto estruturado, 109- 16 demanda (backlog) de aplicações, 132-39 desenho de formulários, 486-88 desenvolvimento de sistemas, 49-79, 13 1-50 diagramas de contexto, 4 16-17, 421- 28 diagramas de entidades-relaciona mentos(E-R),88-89, 156,246,289318, 400 diagramas de fluxo de dados (DFD), 84-87, 177-233, 246, 400 diagramas de transições de estado (DTE), 28, 90, 91, 156, 215, 247, 3 19-36, 400 dicionário de dados (DD), 86, 235- 54, 400 diretrizes para estimativas, 605-22 entrevistas, 655-68 especificações de processos, 86-87, 246, 253-87, 400 estudo de caso: a Yourdon Press, 67 1-785 ferramentas automatizadas, 157-59, 579-603 ferramentas de modelagem, 82-83, 167-74
fluxos, 181-87 futuro da, 563-76 casamento da IA e da análise es truturada, 571-72 conhecimento ampliado da aná lise de sistemas, 566-68 hardware de computadores, 57274 impacto dos desastres de manu tenção, 569-70 821 proliferação das ferramentas au tomatizadas, 568-69 impacto na estrutura organizaciona!, 530-31 interface humana, 473-91 lista de eventos, 4 17-20, 428-32, 679- 81, 794 manutenção das especificações, 55376 modelagem, 28, 82-95, 156 modelo ambiental, 399, 400, 4 14-32 modelo comportamental, 399, 400, 139-64 modelo de implementação do usuário, 29, 73, 361,395, 465-503 modelo essencial, 391,397-407,465- 66 modificações antigas na, 563-66 modificações na análise estruturada clássica, 155-56 movimento em direção a, 153-55 projeto de sistemas, 507-25 programação, 5 27-39 prototipação, uso da, 159-60 sistemas automatizados, 20-40 testes, 101-104, 530-31, 539-43 usuários, 50-60 Veja também tópicos específicos Analistas de sistemas fornecedores de estações de trabalho, 584-85 papéis dos, 68-69
programação/testes e, 528-31 Apresentador, como personagem nos caminhamentos, 650 Armazenamento de dados a longo prazo, 493 Auditores, 67 objetivo dos, 67 problemas do trabalho com, 67 Automatização como problema da gerência do pro jeto, 384-86 de sistemas de processamento de informações, 20 B Backlog, Veja Backlog de aplicações Backlog de aplicações, 132-39 backlog desconhecido, 133 backlog invisível, 132 backlog visível, 132 redução do, 133-38 Backlog desconhecido, 133 Backlog invisível, 132 Backlog visível, 132 Bancadas, projeto, 581 Bolhas de geração espontânea, 204 Buracos negros, diagramas de fluxos de dados (DFD), 204 c Cálculos, 493 Cálculos de custo/benefício, 623-44 análise de benefícios, 633-37 benefícios estratégicos do novo sistema, 636-37 benefícios táticos, 634-36 análise de custos, 625-33 custo das falhas, 632-33 custo do dinheiro,629
custos de construção de sistemas, 625-27 custos de instalação de sistemas, 627-29 custos operacionais, 629-3 1 distinção entre custo de capital e custo de despesas, 633 análise dos riscos, 641-43 como expressar custos/benefícios, 637-4 1 fluxo de caixa, 638-39 retorno do investimento, 639 taxa interna de retorno, 641 valor atual líqüido, 639-40 Cálculos de custos, sistemas, 625-27 Caminhamentos (Walkthroughs), 643, 645-53 definição, 645-46 motivos para a realização, 646-48 personagens dos, 649-5 1 procedimentos, 651-52 quando fazer, 648-49 tipos de, 646 Caminhamentos da análise, 646-53 822 motivos de utilização, 646-48 personagens dos, 649-5 1 procedimentos, 651-52 quando utilizar, 648-49 Caminho da auditoria, 497 Cartões perfurados, 474, 476-77 CASE (Computer-Aided Software Engi neering), 158 Ciclo de vida da prototipação, 98, 120-24
candidatos para, 12 1-24 definição, 120 software usado, 121 Ciclo de vida do projeto, 97-129 ciclo de vida da prototipação, 98, 120-24 ciclo de vida do projeto clássico, 100101 implementação bottom-up, 101104 progressão seqüencial, 104-105 ciclo de vida do projeto estruturado, 109-116 ciclo de vida do projeto semi-estrutu rado, 98, 104-108 conceito de, 98-100 implementação top-down, 98, 11620 objetivos do, 99-100 Ciclo de vida do projeto clássico, 100101 implementação bottom-up, 101-104 ciclo de vida em cascata, 101-104 eliminação de erros, 101 testes, 101-104 progressão seqüencial, 104 Ciclo de vida do projeto estruturado, 109- 116 análise de sistemas, 112 controle de qualidade, 114 conversão de bancos de dados, 115 geração de testes de aceitação, 113 implementação, 113 instalação, 115
levantamento, 109-111 projeto, 112 resumo, 115-116 Ciclo de vida do projeto semi-estrutu rado, 98, 105-108 comparado ao ciclo de vida do pro jeto clássico, 105 Ciclo de vida em casacata, 101-104 Código reutilizável, suporte de IA, 59899 Códigos código reutilizável, suporte da IA, 598-99 códigos alfabéticos, 490 códigos externos, 489 Códigos alfabéticos, 490 Códigos de classificação, 490 Códigos externos, 489 Coleta de dados, 668 Coleta de dados formas de, 668 entrevistas, 656-68 Complexidade excessiva, verificação antecipada, 597 Comportamento tempo-dependente, 3 19-20 sistemas de tempo-real, 31 Computador Apoilo, 583 Computador Sun, 583 Computadores pessoais (PC), 580, 81 Computadores VAX, 583-94 Computadores Wang, 593 Computer-Aided Software Engineering (CASE), 158 Computer OutputMicroform (COM), 478 Condições, estados, 326
Confiabilidade como problema de alocação, 5 13-14 no desenvolvimento de projetos de sistemas, 139-42 erros de software, 139-42 restrições, 496-97 Controles batch, 495 Controle de documentos, 595 Controle de qualidade, ciclo de vida de projeto estruturado e, 114 Conversão, 545-46 conversão de bancos de dados, 115 custos de, 627 Conversão de bancos de dados ciclo de vida do projeto estruturado, 115 custos da, 627 823 Correção, como problema da pro gramação, 537 Cronogramas, estimativas de, 605 Custo, um problema de alocação, 512 Custos com pessoal, 630 Custos das falhas, 632-33 Custos das instalações físicas, 631 Custos de capital, comparados com custos de despesas, 633 Custos de despesas, comparados com custos de capital, 633 Custos operacionais, sistemas, 632-33 D Decisão de implementação, 29 Definições, dicionário de dados, 239 Declaração de objetivos modelo ambiental, 414-16
Yourdon Press, 678 Demanda desconhecida, 133 Departamento SIG, 63 Depósito de implementação, 188-90 Depósitos alocação de, 511 atribuição de nomes aos, 196-99 definição de, 188-189 depósito de implementação, 189-91 depósitos de escrita-apenas, 204 depósitos de leitura-apenas, 204 depósitos essenciais, 447 fluxo para, 193-94 interpretação de fluxo proveniente de, 192 píopósito dos, 189 Depósitos de controle, 86, 214 Depósitos de dados alocação de, 511 Veja também Depósitos Depósitos de escrita-apenas, 204 Depósitos de leitura-apenas, 204 Depósitos essenciais, 447 Depósitos externos comunicação através de, 423 modelo de entidades-relacionamen tos, 419 DER, Veja Diagramas de entidades-rela cionamentos (E-R) Desenvolvimento, Veja Desenvolvi mento de sistemas Desenvolvimento de sistemas participantes, 49-79 analista de sistemas, 68-69 auditores, 67 gerência, 60-67 grupo de controle de qualidade,
67 pessoal de operações, 72-73 programadores, 69-72 projetistas de sistemas, 69 setor de padrões, 67 usuários, 50-60 principais problemas, 131-50 confiabilidade, 139-42 eficiência, 144 manutenibilidade, 142-44 portabilidade, 144 produtividade, 132-39 segurança, 144 relacionamento entre a gerência e, 62-63 DFD, Veja Diagramas de fluxo de dados Diagrama de bolhas, Veja Diagramas de fluxo de dados Diagrama de fluxo de dados de alto nível, 440 Diagrama de fluxo de dados inicial, desenvolvimento do, 447-48 Diagrama SADT, 366 Diagramas de análise de problemas (DAP), 357, 359, 360 componentes dos, 359 Diagramas de Bachman, 366, 367 Diagramas de contexto modelo ambiental, 416 construção do, 421-28 nome de processo típico para,421 terminadores duplicados em, 424 Diagramas de entidades-relacionamen tos (E-R), 88-89, 157, 246, 289-318, 400 componentes do, 88, 292-300 indicadores de tipos de objetos associativos, 298-300 relacionamentos, 294-97 tipos de objetos, 292-93 824
definição de, 88 dicionário de dados, notação para, 310-11 diretrizes de construção, 300-301 acréscimode tipos de objetos, 30010 supressão de tipos de objetos, 30610 equilíbrio em relação ao DFD e às especificações de processos, 34445 variações, 365 -68 Yourdon Press, 757 Diagramas de estrutura de dados de DeMarco, 366-67 Diagramas de Ferstl, 357-58 Diagramas defluxo de dados (DFD), 84- 87, 177-233, 247, 400 como evitar DFD excessivamente complexos, 200 como refazer, 201-203 comparados com os diagramas de entidades-relacionamentos (E-R), 289 componentes dos, 84-86, 179-96 depósitos, 85, 188-94 fluxos, 85, 181-88 processos, 85, 180-81 terminadores, 85, 194-96 diagramas de fluxo de dados subdi vididos em níveis, 205-2 14 dicionário de dados (DD), 86 diretrizes de consistência, 204-205 especificação de processos, 86, 87 exemplo de, 85 extensões, para sistemas de tempo real, 214-15 modelo comportamental final, Your don Press, 675-732 modelo comportamental preliminar, Yourdon Press, 679-72 1 problema dos elevadores, 795-810
relacionamentos entre diagramas de transições de estado (DTE) e, 330331 subdivisão em níveis, 454-59 subdivisào ascendente, 454-55, 461 subdivisão descendente, 455-57 utilização em lugar dos diagramas PERT, 38 1-83 variações, 365 Diagramas de fluxo de trabalho, Veja Diagramas de fluxo de dados Diagramas de Gane-Sarson, 365 Diagramas de Hamilton-Zeldin, 357,359 Diagramas de transições de estado (DTE), 28, 89-90, 91, 156, 214-15, 246, 31936, 400 como completá-los, 461 comparados aos diagramas de enti dades-relacionamentos (E-R), 289 construção dos, 3 29-30 diagramas subdivididos, 326-28 notação, 320-26 condições e ações, 326 estados do sistema, 320-22 mudanças de estado, 322-24 relacionamento com outros compo nentes do modelo, 330-31 relacionamento entre diagramas de fluxo de dados e, 331 Diagramas estruturais, 90-91,363-65,516 módulos, 72 Diagramas HIPO, 362-63 Diagramas IPO (entrada-processamento saída), 363 Diagramas PERT, 378-80 lista de atividades, 383 atividades de alto nível, 383 Dicionário de dados (DD), 86, 235-52, 400
aceitação do usuário, 245-47 como completar o, 460 definição do, 236 entradas (itens), 164 equilíbrio do, 340-42, 346-47 em relação às especificações de processos, 340-42 em relação ao DD, 340-4 1 em relação ao DTE, 346-47 implementação do, 247-48 importância do, 235-36 notação, 238-45 definições, 239-40 elementos de dados elementares, 825 240-41 elementos de dados opcionais, 242-43 esquemas de notação, 239 iteração, 243-44 necessidade da, 236-38 seleção, 244 sinônimos, 244-46 notação do diagrama E-R, 3 10-11 problema do elevador, 81 1-13 Yourdon Press, 732-57 Diagramas de estrutura de dadosJackson, 366, 369 Diagramas de fluxo de dados subdividi dos em níveis, 205-2 14 consistência, 210 exibição de depósitos em vários níveis, 210 exibição dos níveis aos usuários, 210
número de níveis, 209 subdivisão, 209 uso de, 213-214 Diagramas de Nassi-Shneiderman, 277- 78, 356, 358 t pseudocódigo, 278 Diagramas subdivididos, 326-28 Diálogo/interface homem/máquina, Veja Interface humana Diretrizes de consistência, diagramas de fluxo de dados (DFD), 204-205 Diretrizes de estimativas, 605-22 fator de comunicação, 615-16 fórmulas, 616-18 para estimar o tempo, 617-18 para estimar o tempo de trabalho, 617 itens a serem estimados, 605-06 modelos de estimativas computado rizadas, 619 perigos, 606-13 de estimar seu próprio trabalho, 609- 10 diferença entre estimar e negociar, 607-608 dificuldade em medir a unidade de trabalho, 612-13 estimativas com base em pressu posições de horas extras não pagas, 613 estimativas detalhadas prematu ras, 611-12 falta de um banco de dados de estimativas, 610-11 grande variação nas habilidades técnicas, 608-609 trabalho novo versus trabalho aproveitado, 616 unidades de estimativas, tamanho das, 614-15 unidades de trabalho, independência das, 615 Discos flexíveis, 474-75 E Eficiência como problema da alocaçao, i !-iz comoproblemada programação, 536-
37 no desenvolvimento de projetos de sistemas, 144 EGA-Paint, 583, 588 Elementos de dados elementares, di cionário de dados (DD), 240-41 Elementos de dados opcionais, di cionário de dados (DD), 242-43 Eliminação de erros, 579 ciclo de vida do projeto clássico, 101 Entrada dispositivos de entrada, 474-75 cartões perfurados, 474 discos flexíveis, 474-75 entrada de voz, 476 fita magnética, 474 leitoras óticas/leitoras de código de barras, 475 telefone, 475-76 terminais e computadores pes soais (PC), 475 entradas redundantes, 494 inserção dc entradas no sistema, 49293 tempo de resposta à, 496 Entrada de voz, 476 Entradas (itens), dicionário de dados (DD), 164 826 Entrevistas, 655-664 diretrizes para a condução, 658-664 autorização para falar com os usuá rios, 659-660 estilos de entrevistas, 663-64 informações de interesse para o usuário, 662-63 planejamento geral, 658-59 problemas a dar atenção, 666-67 resistência, 664-66 uso de ferramentas automatiza das, 662 uso eficiente do tempo, 660-62 formas alternativas de coleta de dados, 668
motivo para realizar, 655 problemas com, 657-58 tipos de, 656 Equilíbrio das especificações de processos em relação ao DFD e ao DD, 342-43 de modelos, 337-5 1 do DD em relação ao DFD e às especi ficações de processos, 344 do DER em relação ao DFD e às especificações de processos, 34445 do DFD em relação ao DD, 340-4 1 do DFD em relação ao DTE, 346-47 do DFD em relação às especificações de processos, 34 1-42 Equipe de desenvolvimento, o custo durante a instalação, 628-29 Erros, software, 139-42 Escalonamento de pessoal, estimativas de, 605 Escrivão, como personagem de cami nhamentos, 650 Especificações de processos, 86-87,246, 253-87, 400 como completar, 460-61 condições pré/pós, 266-71 diagramas de Nassi-Shneiderman, 277-78 equilíbrio em relação ao DFD e ao DD, 342-43 fluxogramas, 275-77 grafos/diagramas. 274 limitação da complexidade das, 26465 linguagem estruturada, 258-66 linguagem narrativa, 274-75 manutenção das, 544 problema dos elevadores, 815-18 requisitos das, 2 53-54 tabelas de decisão, 247-49
Yourdon Press, 758-785 Especificações funcionais gráficas, 155 Especificações funcionais minirnamente redundantes, 155 Especificações funcionais subdivididas, 155 Estações de trabalho (estações inteli gentes), custo das, 599-601 Estado final de sistema, 323, 25 Estado inicial de sistema, 323, 25 Estados do sistema, 321-22 mudanças de estado, 322-26 Estimativa de orçamentos, 605 Estimativas detalhadas prematuras, 61112 Estudo de caso, a Yourdon Press, 671785 antecedentes, 672-78 diagrama de entidades-relacionamen tos (E-R), 757 dicionário de dados (DD), 732-57 escala de operações, 678 especificações de processos, 758-85 estrutura organizacional da Yourdon, Inc., 675-76 grupos principais, 676-77 modelo ambiental, 678-8 1 declaração de objetivos, 678 diagrama de contexto, 679 lista de eventos, 679-81 modelo comportamental final, 72231 diagramas de fluxo de dados (DFD), 723-3 1 modelo comportamental preliminar, 682-785 diagrama de fluxo de dados
(DFD), 683-721 Execuções paralelas, custo das, 628-29 827 F Ferramentas automatizadas, 156-59,579- 603, 662 características das, 585-91 verificação cruzada dos mode los, 590-91 recursos de verificação de erros, 588-90 suporte gráfico, 586-88 futuro das, 591-99 código reutilizável, suporte da IA, 598-99 controle de documentos, 595 estatística da produtividade e métricas de software, 596 geração de código, 598 gerenciamerito de projetos, 59596 prova de correção assistida por computador, 597 quadros da equipe de projeto, 599 redes para uso em projetos, 59394 suporte à metodologia de enge nharia de software personalizado, 594-95 teste e simulação assistidos por computador, 597 verificação antecipada de com plexidade excessiva, 597 tipos de, 579-81 Ferramentas de modelagem, 82-83, 16674 características das, 166-74 diagrama de fluxo de dados (DFD), 177-233 diagramas de entidades-rela cionamentos (E-R), 289-3 18 diagramas de transições de estado
(DTE), 319-36 diagramas HIPO, 362-65 dicionário de dados (DD), 235-52 equilíbrio das, 337-5 2 especificações de processos, 253-87 fluxogramas, 354-62 modelos gráficos, 169 828 modelos minimamente redundan tes, 171-72 modelos transparentes, 172-73 para gerência de projetos, 375-87 subdivisão top-down de modelos, 179-81 Ferramentas de modelagem de temporeal, 595 Fita magnética, 474,477 Fluxo de caixa, 638-39 Fluxogramas de sistemas, 359-61 Fluxos atribuição de nomes, 182 definição de, 181 direção de, 183 escolha de nomes para, 196-99 fluxos convergentes, 184-85 fluxos de diálogo, 184 fluxos divergentes, 185-86 Fluxos de controle, 86, 214-15 Fluxos de dados, diagramas de con texto, 424, 426 Fluxos de diálogo, 427-29 Fluxos divergentes, 185-86 Fluxos sem rótulo, 192, 204 Fluxogramas, 275-77, 354-59 críticas aos, 275
fluxograma clássico, 354-56 fluxograma não-estruturado, 357 notação, 354 variações, 356-59 Formato, de sistema, 466-67 Formulários especiais, 487-88 custo dos, 488 formulários multipartes, 488 tipos de, 488 Formulários multipartes, 488 Formulários normais, 487 Fórmulas estimativas, 616-18 para estimar o tempo, 617-18 para estimar o tempo de trabalho, 617 Fornecedores custos de instalação, 627 demonstrações pelos, 668 L Fronteiras da automatização, 392 modelo de implementação do usuário, 468-73 opções extremas, 468-69 seleção das, 469-73 G-H Geração de código, 598 Geração do teste de aceitação, ciclo de vida do projeto estruturado, 113 Gerência interação entre os analistas de sis temas e, (50-62 níveis de, 60-61 pontos importantes relativos à, 60-62 relacionamento entre projetos desen volvimento de sistemas e, 63-64 Gerência de projeto, 595-96 ferramentas de modelagem, 375-87 comparadas com outras ferramen tas de modelagem de sistemas,
382-84 diagramas de GANTF, 380-81 diagramas PERU, 378-80 necessidade de modelos pela gerência, 376-77 problema da automatização, 384-86 Grafos/diagramas, 274 Grupo de administração de banco de dados (DBA), 290-91 Grupo de administração de dados (DA), 290 Guias de referência, 547 Hardware custo do, 630 futuro do, 572-74 instalação, 576 Hierarquia sincronizada de módulos, 365 Implementação bottom-up ciclo de vida do projeto clássico, 101104 ciclo de vida em cascata, 101-104 eliminação de erros, 101 testes, 101-104 Implementação, ciclo de vida de projeto estruturado, 113 Implementação top-down abordagem radical versus aborda gem conservadora, 116-120 ciclo de vida do projeto sem i-estrutu rado, 105-106 Implementação top-down conservado ra, 116-120 Implementação top-down radical, 116- 120 Inspeções, 543 Veja também Caminhamentos (Wal kthroughs) Instalação ciclo de vida do projeto estruturado, 115 custos da, 627-29 de sistema, 546-47 software, 547 Inteligência artificial
apoio de código reutilizável, 598-99 casamento da análise estruturada e, 571-72 definição de , 35-36,38 e o custo do sistema, 636-37 Interface amistosa ao usuário diretrizes, 480-85 Veja também Interface humana Interface humana, 28, 473-91 códigos de entrada/saída, 489-91 códigos alfabéticos, 490-91 códigos de classificação, 489 códigos externos, 489 requisitos para, 489-90 diretrizes para interfaces amistosas para o usuário, 480-85 dispositivos de entrada, 474-75 cartões perfurados, 474 discos flexíveis, 474-75 entrada de voz, 476 fita magnética, 474 leitoras óticas/leitoras de código de barras, 475 telefone, 475-76 terminais e computadores pes soais (PC), 475 829 dispositivos de saída 135-36, 535 cartões perfurados, 476-77
Linguagem de programação MARK V,
Computer Output Microform 135-36, 535 (COM), 478 Linguagem de programação NOMAD, fita/disco magnético, 477 plotter, 477
467
Linguagem de programação Pascal, 135-
saida de voz, 477
36, 159, 535
saída impressa, 476 Linguagem de programação PC-FOCUS, terminais, 477 135-36 formatos de entrada/saída, 478-85
Linguagem de programação PROLOG,
problemas relacionados, 473-74
39
projeto de formulários, 486-88
Linguagem de programação RAMIS, 535
conteúdo de formulários, 486Linguagem estruturada, 258-66, 272 formulários comuns, 487
definição, 258-59
formulários especiais, 488
objetos, 259
International Business Machines (IBM), 583
sentenças compostas, 262
Intervalo de tempo entre falhas (MTBF), 497
sentenças, 260 verbos, 259
Linguagem narrativa, 274-75
Iteração, dicionário de dados, 243
abordagem de análise estruturada
subdividida, 275 Linguagens de programação de alto ni L
vel, 579
Leitoras de códigos de barras, 475
Linguagens de programaçãode primeira
Leitoras óticas, 475 geração, 534 Levantamento, ciclo de vida do projeto estruturado, 109-11
geração, 535-36
Linguagem de programação ADA, 13536, 535
Linguagens de programação de quarta Linguagensde programaçãode segunda
geração, 534
Linguagem de programação BASIC, 135- Linguagens de programação de terceira 36, 534, 535 geração, 535 Linguagem de programação C, 135-36, 535
Lista de eventos
modelo ambiental, 417,4 19
Linguagem de programação COBOL, 37,
construção do, 428-30
135-36, 159, 273, 531, 534, 535, 551,
problema dos elevadores, 794
579, 598
Yourdon Press, 682-84
Linguagem de prc dBASE III,
Lotus 1-2-3, 33
135-36, 535, 218 , 467 Linguagem de programação FOCUS, 13536, 248,467,535
N
Linguagem de programação FORTRAN, 135-36, 273, 531, 534, 535, 598
MacDraw, 583-87
MacPaint, 583-87
Linguagem de programação IDEAL, 467, Mantenedor de padrões, como persona 535
gem de caminhamentos, 651
Linguagem de programação LISP, 39
Manuais do usuário, 547-48
Linguagem de programação MAN’ITS, 535
Manutenção
custos da, 630-31
Linguagem de programação MAPPER,
de especificações, 553-61
830 importância das, 5 54-56 pré-requisitos necessários, 556 regras, 556-59 desastres, impacto dos, 569-70 programador de manutenção, 71 revisor de manutenção, como papel do caminhamento, 650 Manutenibilidade como problemade programação, 53738 no desenvolvimento de projetos de sistemas, 14 2-44 Mesas de projeto, 581 Microsoft File, 248 Minicomputadorde nível de projeto, 59394 Modelagem, 29, 82-95, 156 comportamento tempo-dependente, dados armazenados, 88-89 estrutura de programa, 90-91 ferramentas, uso de, 82-83 funções do sistema, 84-87 relacionamento entre modelos, 92 tipos de modelos, 82 Modelagem de dados, integração da modelagem de processos e, 565 Modelagem de processos, integração da modelagem de dados e, 565 Modelo ambiental, 399, 4 14-32 aspecto crítico do, 410
componentes do, 4 14-19 declaração de objetivos, 414-16 diagrama de contexto, 416-17 lista de eventos, 4 17-19 construção do, 420-32 diagrama de contexto, 42 1-28 lista de eventos, 428-32 definição do, 409-10 dicionário de dados inicial, 419 fatores do escopo de projeto, 4 10-14 modelo de entidades-relacionamen tos de depósitos externos, 419 Modelo comportamental, 399, 439-50 construção do modelo preliminar, 439-40 abordagem clássica, 440-42 etapas do desenvolvimento, 447identificação das respostas aos eventos, 441-46 interligação das respostas aos eventos 446-47 desenvolvimento top-down do, 440- 42 término de, 453-64 diagramas de transições de esta do, 461 dicionário de dados (DD), 460 especificações de processos, 46061 modelo de dados, 461 subdivisão do DFD em níveis, 454- 59 Modelo de dados, como completar, 454 Modelo de implementação de programa, 5 15-20 Modelo de implementação do usuário, 29, 73, 361, 395, 465-503 especificação de restrições opera cionais, 495-97 fronteiras da automatização, 468-73 escolha das, 469-71 opções extremas, 469
identificação de atividades adicio nais de suporte manual, 491-95 interface humana, 473-91 código de entrada/saída, 489-91 desenho de formulários, 486-88 dispositivos de entrada/saida, 47478 formatos de entrada/saída, 478- 85 problemas relacionados, 473-74 problemas de continuidade, 507-576 futuro da análise estruturada, 56376 manutenção das especificações, 553-61 programação/testes, 527-52 projeto de sistemas (fase), 507- 625 Modelo de implementação, logicalização do, 400-403 Modelo de processador, 508-14 problemas de alocação, 5 11-14 49 89 831 Modelo de tarefa, 5 14-15 Modelo essencial, 391, 397-407, 465-66 componentes do, 400 definição do, 397 detalhes de implementação, 397-98 dificuldades da construção, 397-98 problema dos elevadores, 792-93 Modelo de funções, Veja Diagramas de fluxo de dados Modelo de processos, Veja Diagramas de fluxo de dados Modelo físico atual, desenfatização do, 564-65 Modelos de estimativa computadoriza da, 619 Modelos, equilíbrio de, 337-5 1 Modelos gráficos, 169
Modelos minimamente redundantes, 171-72 Modelos subdivisiveis pela modalidade top-down, 170-71 Modelos transparentes, 172-73 Módulos funcionalmente coesos, 520 Módulos pequenos, programas, 538 Mudanças de estado, 28, 89-90 N Negociação, diferença entre estimativas e, 607-608 Nomes de processos, 4 21-22 Notação diagramas de transições de estado (DTE) condições e ações, 326 estados do sistema, 32 1-22 mudanças de estado, 322-24 dicionário de dados (DD) definições, 239-40 elementos de dados elementares, 240-4 1 elementos de dados opcionais, 24 2-43 • esquemas de notação, 238-39 iteração, 243-44 necessidade de, 236-38 seleção, 244 sinônimos, 244-4 5 fluxogramas, 354-56 o-P Objetos, linguagem estruturada, 259-60 Pacote de software de projeto (Meta Systems Inc.), 682 Pacotes de controle de código fonte, 581 PC-Draw, 583, 588 Pesquisa externa, 668 Pessoal de operações, papel do, 72-73 PFS-File, 248
Plotadora, 477 Poços sem fundo, diagramas de fluxo de dados (DFD), 204 Portabil idade como problema da programação, 537 no desenvolvimento de projeto de sistemas, 144 Prazos, estimativas de, 605 Pré/pós-condições, 266-71 definição de, 266-69 Preparação da localização do computa dor, 546 Pré-requisitos, manutenção das especi ficações, 556 Presidente, como papel no cami nhamento, 650 Primeira versão do diagrama de fluxo de dados, 439 Problema dos elevadores, 787-8 18 descrição narrativa, 788-91 diagramas de fluxo de dados (DFD), 795-810 dicionário de dados (DD), 811-14 especificação de processos, 815-18 lista de eventos, 794 modelo essencial, 792-93 Processo de análise modelo ambiental, 4 09-37 modelo comportamental construção do, 439-50 término do, 453-64 modelo de implementação do usuá rio, 465-503 modelo essencial, 391-407 Processos atribuição de nomes a bolhas de processos, 181 definição de, 180 832 escolha de nomes, 196-99 exemplo de, 180 numeração de, 199-200 Processos de controle, 86, 214-15 Processos sem rótulo, 204
Produtividade como problemade programação, 596 estatísticas, 596 no desenvolvimento de projetos de sistemas, 132-39 Produtos CASE, 594-95 Programa de planilha Framework, 33 Programa de planilha Multiplan, 33 Programa Lightyear, 34, 35 Programação, 527-39 fast-tracking e implementação top down, 531-33 futuro da, 538-39 impacto na estrutura organizacional, 530-31 linguagens de programação, 533-39 gerações das, 534-36 papel doanalista de sistemas na, 52830 problemas importantes, 536-38 Programação estruturada, 538 Programadores, 69-72 contato com analistas de sistemas, 70-7 1 programador de manutenção, 71 Progressão seqüencial, ciclo de vida do projeto clássico, 104-105 Projetistas de sistemas, 69 Projeto de formulários, 486-88 conteúdo de formulários, 486-87 formulários comuns, 487-88 formulários especiais, 488 custo dos, 488 formulários multipartes, 488
tipos de, 488 Projeto de sistemas (fase), 507-25 diretrizes para, 520-22 acoplamento, 520-21 amplitude do controle, 521 coesão, 520 escopo de efeito! escopo de con trole, 521-22 tamanho dos módulos, 521 estágios do, 508-20 metas/objetivos, 520-22 modelo de implementação de programas, 515-20 modelo de processador, 508-14 modelo de tarefa, 5 14-15 programação/testes, 527-52 Projeto (fase) ciclo de vida do projeto estruturado, 112- 13 Veja também Projeto de sistemas (fase) Prototipaçáo,59 uso na análise estruturada, 159-60 Prova de correção, 543 prova de correção assistida por computador, 597 Prova de correção assistida por compu tador, 597 Q-R Quadros negros para a equipe de pro jeto, 599 Questionários, 668 Rbase-5000, 135-36, 248, 467, 535 Recursos humanos, estimativas de, 605 Recursos de verificação de erros, ferra mentas automatizadas, 588-90 Redundância, 494 redundância interna, 494 Redundância interna, 494 Reestruturação de programas, 135-36 Relacionamentos, diagramas de enti dades-relacionamentos (E-R), 88-89 Resistência, a entrevistas, 664-66
Reseostas aos eventos, conexão de, 446- 47 Restrições ambientais, 496-97 Restrições operativas, como problema de alocação, 5 13-14 Restrições políticas, 496 como problema de alocação, 514 Retorno de investimentos, 639 s Saída 833 dispositivos de saída cartões perfurados, 476-77 Computer Output Microform (COM), 478 fita e disco magnéticos, 477 plotadora, 477 saida de voz, 477 saída impressa, 476 terminais, 477 emissão de saídas do sistema, 493 saídas redundantes, 494 Saida de voz, 477 Saída impressa, 476 Segurança como problema de alocaçào, 512 em projetos de desenvolvimento de sistemas, 144 restrições, 497 Seleção, dicionário de dados (DD), 244 Sentenças linguagem estruturada, 260-61 sentenças compostas, 262-64 Sentenças compostas, 262,64 Setor de controle de qualidade objetivo do, 67
problemas de trabalho com, 67-68 Setor de padrões objetivo do, 67 problemas de trabalho no, 67-68 Setor de processamento de dados, 62-63 Simplicidade de estilo, programas, 53839 Simulação assistida por computador, 597 Simuladores, 579-80 Sinônimos, dicionário de dados, 244-45 Sistema de gerenciamento de bancos de dados IDMS, 247, 290 Sistema de gerenciamento de bancos de dados IMS, 247, 290 Sistema de gerenciamento de bancos de dados TOTAL, 247, 290 Sistemas custos de construcão, 625-27 custos de instalação, 627-29 custos operacionais, 629-3 1 definição, 11-14 introdução de entradas no sistema, 492-93 obtenção de saídas do sistema, 493 semelhanças entre, 12 sistemas automatizados, 20-39 sistemas feitos pelo homem, 18-20 sistemas naturais, 14-18 tipos de, 14-15 Sistemas automatizados, 20-39 aplicações, 21 componentes comuns dos, 20 definição de, 19-20
sistemas baseados no conhecimento, 38-39 sistemas de apoio à decisão, 32-37 sistemas de tempo real, 29-32 sistemas on-line, 27-29 Sistemas baseados no conhecimento, 38-39 definição de, 38 Sistemas batch (em lotes), 27-28 Sistemas CAD/CAM, 600 Sistemas de apoio à decisão, 32-37 definição, 32 exemplos de, 32-33 Sistemas de planejamento estratégico, 35-36 modelos típicos dos, 36, 37 Sistemas de processamento de infor mações, automatização dos, 20 Sistemas de tempo-real, 29-32, 3 19-20 ambiente, 31 análise estruturada e, 155-57 características dos, 3 1-32 comportamento tempo-dependente, 31 definição de, 29-30 exemplos de, 319 extensões aos diagramas de fluxo de dados (DFD), 214-15 tipos de, 29-30 Sistemas especialistas, Veja Sistemas baseados no conhecimento Sistemas feitos pelo homem, 18-20 computadorização dos, 18-19 exemplos de, 18 Sistemas naturais, 14-18
sistemas vivos, 14-17 interação dos sistemas feitos pelo homem nos, 16-18 834 sistemas físicos, 14 Sistemas on-line, 27-29 características dos, 27-28 comparados a sistemas batch, 27-28 definição de, 27 mudanças de estado, 28 uso de, 29 Sistemas operativos, relacionamento entre, 35-36 Software custo do, 630 erros de software, 139-42 instalação, 546 manutenção, 142 métricas, 596 Subdivisão de eventos, 157, 564 abordagem do modelo compor tamental, 442-46 Subdivisão em níveis diagramas de fluxo de dados (DFD), 454-59 subdivisão ascendente, 454-59 subdivisão descendente, 454-59 Subdivisão em níveis ascendentes, dia gramas de fluxo de dados (DFD), 454, 460 Subdivisão em níveis descendentes, diagramas de fluxo de dados (DFD), 454-59 Suporte à metodologia de engenharia de software personalizado, 594-95 Suporte de gráficos, ferramentas auto matizadas, 586-88 Tabelas de decisão, 27 1-73
Taxa interna de retorno, 641 Telefone, 475-76 Teoria geral dos sistemas, 13, 40-43 Tetminadores, 194-96, 422-28 atribuição de nomes a, 196-99 comunicação entre o sistema e, 422 definição de, 194 fontes/manipuladores, 425 processo de comunicação, 422 representação gráfica de, 194 terminadores duplicados no diagra Terminais de tempo compartilhado, 580 Testes, 539-43 ciclo de vida do projeto clássico, 101conceitos relacionados, 543-44 ferramentas de testes, 579-80 impacto na estrutura organizacional, 530-31 papel do analista de sistemas nos, 528-30 plano de testes, 540-4 1 descrições, 543 locação/cronograma, 543 objetivo, 543 procedimentos, 543 testes e simulação assistidos por computador, 597 tipos de, 540-43 testes de desempenho, 541 testes de recuperação, 540-4 1 testes funcionais, 540 Testes de desempenho,541 Testes de recuperação, 540-4 1
Testes e simulações assistidos por com putador, 597 Testes funcionais, 540 Tipos de objetos, diagramas de enti dades-relacionamentos (E-R), 88 Treinamento, 547 custo do, 625 U-v Usuários, 50-60 características dos, 58 dassificados por nível de experiência, 59-60 novatos, 60 usuários amadores, 59 ma de contexto, 425 Terminadores duplicados, no diagrama de contexto, 425 Terminais, 475 definição, 27 e computadores pessoais (PC), 475 terminais de tempo compartilhado, 580 102 835 usuários experimentados, 60 classificados por tipo de tarefa, 52-59 usuários de nível executivo, 56 usuários operativos, 53 usuários supervisores, 54-56 heterogeneidade dos, 52 identificação dos, 51 preparação da localizacão, 546 Usuários de nível executivo, 56 Usuários operativos, 53 Usuários supervisores, 54-56 Valor atual líquido, 639-40 Verbos, linguagem estruturada, 259 Verificações de seqüência, 495
Visitas a outras instalações, 668 Volumes de dados, especificação de, 495-96 836 Série Yourdon Press Os clássicos indispensáveis para analistas e programadores GUIA DE IMPLEMENTAÇÃO PARA PROGRAMAÇÃO EM TEMPO REAL Ripps, DL, Destinado a quem já tem experiência com programação em geral e deseja ampliar seus conhecimentos sobre os últimos i avanços na programação em tempo real. cód.807316pp. PROJETO BASEADO EM OBJETOS Yourdon, E. Livro voltado para engenheiros de soft ware, especialmente os responsáveis pelo desenvolvimento da arquitetura global para um sistema. Ajuda na elaboração de projetos de desenvolvimento de sistemas reais. cód.760 * PROJETO ESTRUTURADO DE SISTEMAS Yourdon, E./Constan tine, L. Sintetiza as bases do método Yourdon de análise e projeto de sistemas. Fruto da experiência de anos, este texto famoso derruba todos os padrões preestabeleci dos de identificação, especificação, proje to e implementação de sistemas. cód.714 568pp. ANÁLISE BASEADA EM OBJETOS Coad, P./Yourdon, E. O livro ajuda o analista a melhor se co PROJ 1 ESTRUTU DE SIET [ ADMINISTRANDO O CICLO DE VIDA DO SISTEMA Yourdon. E. ADMINISTRANDO TÉCNICAS ESTRUTURADAS Estratégias Para o Desenvolvimento de Software nos Anos 90 Yourdon, E. municar para extrair as informações ne cessárias do especialista e então retornar todos os
dados analisados para o cliente. A análise baseada em objetos melhora a interação entre analista e especialista. cód.700 236 pp. ANÁLISE ESTRUTURADA MODERNA Tradução da terceira edição americana Yourdon, E. Yourdon descreve neste clássico esta no va tecnologia que modificou a perspec tiva e o enfoque da análise de sistemas. Atualiza a abordagem para a modela gem de um sistema físico atual e apre senta os diagramas de transição de esta dos. Inclui cerca de 1.000 exercícios e estudo de casos. cód.615 824 pp. ANÁLISE ESTRUTURADA E ESPECIFICAÇÃO DE SISTEMAS DeMarco, T. Este é um livro de ferramentas e métodos para o analista. Seu objetivo é trazer or dem e rigor ao processo de especificação para guiar o analista no desenvolvimento de uma Espec Estruturada. Possui mais de 200 exemplos. cód.544 348pp. DO REVISÕES ESTRUTURADAS Yourdon, E. CRIAÇÃO DE SOFTWARE Técnicas Eficientes King, D. Outros títulos da Série: Editora Campus • A Qualidade da Informática Outras maneiras fáceis de receber informações sobre nossos ‘ançamentos e ficar atualizado. • ligue grátis: 0800-265340 (2 a 6 feira, das 8:00 h às 19:00 h) • preencha o cupom e envie pelos correios (o selo será pago pela editora) • ou mande um e-mail para: [email protected] CAMPUS Nome: -- -
______________
Escolaridade: j Masc 1 Fem Nasc: _/_/_ Endereço residencial:
_____________________________________________________________ Bairro__________________ Cidade___________________ Estado:_________________ CEP:________________ lei.:___________ Fax:_______________________ Empresa:
________________________________
CPF/CGC: Costuma comprar livros através de: J Livrarias -_J Feiras e eventos J Mala direta .J Internet Sua área de interesse é: 1 NEGÓCIOSJINTERESSE 1JINFORMÁTICA -- UALIDADE
GERAL
DE VIDA Irjiciante Informática .J Intermediário 1 Avançado
Economia
1 Comunicação
1 História ij Ciência Política ‘o
(D
si
Si’
.
c
Si
cJ
>c/, -
01
o -1 > OD G O’ > o, L Cadastre-se e receba informações sobre nossos lançamentos, novidades e ptomoções
1 LIVROS-TEXTO
Nível: Administração
Para obter informações sobre lançamentos e novidades da Editora Campus, dentro dos assuntos do seu interesse, basta cadastrar-se no nosso site. I rápido e fácil. Além do catálogo completo on-line, nosso sitc possui avançado sistema de buscas para consultas, por autol título ou assunto. Você vai ter acesso às mais importantes publicações sobre Administração, Negócios, Informática, Economia, Divulgação Científica, Qualidade de Vida, Ciências Humanas e Interesse Geral. Nosso site conta com módulo de segurança de última geração para suas compras. Tudo ao seu alcance, 24 horas por dia. Clique www.campus.com.br e fique sempre bem informado. www.campus.com.br É rápido e fácil. Cadastre-se agora. Este livro foi impresso nas oficinas gráficas da Editora Vozes Ltda., Rua Frei Luís, 100 - Petrópolis, RJ, com filmes e papel fornecidos pelo editor.
