Scribd Logo
Fazer o upload

Bem-vindo(a) ao Scribd!

  • Não Existe Bala de Prata

    Enviado por

    eveline.marques
    18 visualizações13 páginas
    Tradução de "No silver bullets" parte do livro O mítico homem-mês

    Título original

    Não existe bala de prata

    Direitos autorais

    © © All Rights Reserved

    Formatos disponíveis

    PDF ou leia online no Scribd

    Você considera este documento útil?

    Este conteúdo é inapropriado?

    Denunciar este documento
    Tradução de "No silver bullets" parte do livro O mítico homem-mês

    Direitos autorais:

    © All Rights Reserved
    Baixe no formato PDF ou leia online no Scribd
    Sinalizar o conteúdo como inadequado
    18 visualizações13 páginas

    Não Existe Bala de Prata

    Enviado por

    eveline.marques
    Tradução de "No silver bullets" parte do livro O mítico homem-mês

    Direitos autorais:

    © All Rights Reserved
    Baixe no formato PDF ou leia online no Scribd
    Sinalizar o conteúdo como inadequado
    de 13
    aJeMyos ap eueyuabuq wa ajuapiy a ejpuass] — eye1g ap jeg a4sixq OLN Resumo! T d a construcio de software envolve tarefas bisicas — a concepgao OG aes estrururas conceinuais complexas que compéem a entidade abstrata de software —, ¢ tarefas acidentais — a representacdo dessas entidades abstratas em linguagens de programagio ¢ © mapeamento destas em linguagens de maquina, dentro de limites de espaco ¢ velocidade. A maioria das grandes conquistas que jé ocorreram em produtividade de software vem da remogio das barreiras artficiais que tomaram as tarefas acidentais dificilimas, como limites severos de hardware, linguagens de programagio deselegantes, falta de tempo de maquina, Quanto do que os engenheitos de software ainda fazem hoje esta dedicado ao acidental, em oposigio a0 essencial? A menos que isso seja mais do que 9/10 de todo o esforso, reduzir todas as atividades acidentais para tempo rnenhum nao representara uma ordem de grandeza em melhoria Eneretanto, parece que chegou o tempo de enderecar as partes essenciais da tarefa de software, aquelas relacionadas com a concepgio de estruturas concei- tuais abstratas de grande complexidade. Eu sugiro: + Explorar o mercado de massa para evitar construir 0 que pode ser com- prado, * Usar a prototipagem ripida como parte de uma iteragio planejada no estabelecimento de requisitos de software. jonando mais € mais fungdes aos + Crescer organicamente o software, a sistemas & medida que sio executados, usados e testados. + Identificar ¢ desenvolver os grandes projetistas conceituais da geracio em ascensio. Introdugao De todos 0s monstros que preenchem os pesadelos de nosso folclore, nio hi mais aterrorizantes que os lobisomens, porque transformam-se inesperadamente de algo familiar em horrores. Para eles, buscamos balas de prata que podem, num passe de magica, langé-los na cova. O familiar projeto de software tem algo desse personagem (a0 menos como visto pelo gerente nao técnico), ustialmente inocente ¢ direto, mas capar de tor- nar-se um monstro de cronogramas perdidos, orgamentos estourados € produtos com falhas. Assim, ouvimos pedidos desesperados de uma bala de prata, algo que faca com que os custos de software caiam to rapidamente quanto os de hardware de computadores. ‘Mas, quando olhamos para o horiaonte de uma década atris, no vemos bala de prata alguma. Nao hé um tinico desenvolvimento, seja em tecnologia ou em técnica de gestéo, que, por si sé, prometa uma ordem de grandeza de methoria dentro de uma década, seja em produtividade, confiabilidade ou simplicidade. Neste capitulo tentaremos descobrir o porqué, examinando tanto a natureza do problema de software como as propriedades das balas propostas. Ceticismo nao € pessimismo, entretanto. Ainda que nao vejamos nenhum avango surpreendente e, de fato, acreditemos que tal seja incoerente com a na- tureza do sofiware, muitas inovagdes encorajadoras estio surgindo. Um esforco constante e disciplinado para desenvolvé-las, propagi-las e explori-las deve con- duzir, de fato, a uma melhoria de uma ordem de grandeza, Nao hé um caminho real,” mas héium caminho. primeiro passo 3 frente na ditecio do controle de doengas foi a substiuigéo das teorias dos deménios ¢ as teorias dos humores pela teoria dos germes, Esse mesmo passo, 0 comego da esperanga, por si varreu todas as esperangas em solu- ‘gies migicas. Ele disse aos trabalhadores que © progresso aconteceria em passos, com grande esforco ¢ que um cuidado persistence, incessante, deveria ser prestado isciplina da limpeza. O mesmo se di com a engenharia de software hoje, Precisa Ser Complicado? — Dificuldades Essenci ‘Nao sé nfo existem balas de prata 3 vista como a prépria natureza do sofewa- re torna improvavel que venha a exist alguma — nao ha invengio que faca pela paolo aor wie soa has iadas plo pubis, neigando sus colbnias no now mundo, (NE) produtividade, confiabilidade ¢ simplicidade do software 0 que os componentes cletrOnicos, transistores e integragio em larga eseala fizeram pelo hardware de computadores. Jamais podemos esperar ver ganhos dobrarem a cada dois anos, & que o progresso Em primeiro lugar, devemos observar que a anomalia ni do software seja muito lento, mas que o progresso do hardware de computador & muito ripido, Nenhuma outta tecnologia, desde o inicio da civilizagao, observou ganhos de scis ordens de grandeza em prego-desempenho num perfodo de 30 anos. Em nenhuma outra tecnologia é possivel escolher obter 0 ganho tanto em aumento de desempenho como na redugio de custos. Esses ganhos fluiram da transformagio da manufacura de computadores de uma indiistria de montagem para uma indiseria de processo. Em segundo lugar, para ver que taxa de progresso podemos esperar em tec= nologia de software, vamos examinar suas dificuldades. Seguindo Aristételes, eu as divido em esséncia — as dificuldades inerentes & natureza do software ~ ¢ aci- dentes ~ aquelas dificuldades que apresentam-se hoje na sua produgio, mas que nnio sio inerentes. Dos acidentes tratarci na prxima secao. Primeiramente, vamos considerar aesséncia, ‘A esséncia de uma entidade de software é um construto de conceitos que se interligam: conjuntos de dados, relagées entre itens de dados, algoritmos chamadas de fungées. Essa esséncia € abstrata, pois o construto conceitual é o mesmo sob muitas representacées diferentes. Ele é, todavia, altamente preciso € ricamente detalhado. ‘Acredito que a parte mais dificil na construgao de software & a expecifcagdo, 0 projeto eo teste de seu construto conceitual, ndo 0 trabalho de representa-lo e testar a fidelidade da representasio. Decerto ainda cometemos erros de sintaxe, mas eles so poeira se comparados com 0s erros conceituais na maioria dos sistemas, Se isso for verdade, construir software sempre seré dificil. Nao hi, incrente- ‘mente, nenhuma bala de prata. ‘Vamos examinar as propriedades inerentes dessa irredutivel esséncia de sis- temas modernos de software: complexidade, conformidade, flexibilidade ¢ invie sibilidade. COMPLEXIDADE, Entidades de software sio mais complexas para o seu tamanho do que, talver, qualquer outra coisa produzida pelo homem, porque nao ha sequer duas partes que sejam similares (ao menos, acima do nivel das declaragées). Se forem similares, transformamos as duas partes em uma, uma sub-rotina, aberta ou fechada, Quanto a isso, temas de software diferem profundamente de com- putadores, prédios ou automéveis, onde clementos repetidos sio abundantes. Computadores digitais sio, por si, mais complexos que muitas das coisas construidas pelas pessoas. Eles tém um niimero muito grande de estados. Isso torna sua concepgio, descricao e testes muito dificeis. Sistemas de software tem estados em ordens de grandeza muito maiores que computadores, Da mesma forma, escalar uma entidade de software nao é meramente repetir ‘5 mesmos elementos em tamanho maior. E necessétio um aumento do niimero cde elementos diferentes. Em muitos casos, os elementos interagem uns com os outros de modo nao linear, ¢ a complexidade do todo aumenta muito mais do que linearmente, A complexidade do software & uma propriedade essencial, nao uma acidental, Assim, descrigbes de uma entidade de software que abstraiam sua complexidade- costumam abstrair eambém sua esséncia, As ciéncias fisicas ¢ matemiticas tiveram grande progresso durante és séculos construindo modelos simplificados para fe- ndmenos complexos, deduzindo propriedades a partir desses modelos e verificando tais propriedades por meio de experimentos. Isso deu certo porque as complexida- des ignoradas nesses modelos nao eram propriedades essenciais aos fendmenos. O mesmo nao se pode afirmar quando as complexidades sio a esséncia, ‘Muitos dos problemas clissicos do desenvolvimento de produtos de software vém dessa complexidade essencial e de seu aumento nao linear com 0 tama- nho. Da complexidade vem a dificuldade de comunicagio entre os membros da equipe, que leva a deficiéncias no produto, aumento dos custos, atrasos de cronograma. Da complexidade também vem a dificuldade de enumerar, e muito ‘menos entender, todos os estados possiveis de um programa, e dai vem a falta de confiabilidade. Da complexidade das fungdes vem a dificuldade de utilizé-las, 0 que torna os programas dificeis de serem utilizados. Da complexidade da estrutu- ra vem a dificuldade de ampliar os programas com novas fung6es sem, com isso, criar efeitos colaterais. Da complexidade da estrutura vém também os estados rio percebidos, que acabam por criar vulnerabilidades de seguranca. ‘Tanto os problemas técnicos como os gerenciais advém da complexidade, A complexidade torna dificil a visio integral do sistema, impedindo, assim, sua integridade conceitual. Ela torna dificil de encontrar e controlar todos os pro~ blemas. Isso cria 0 enorme fardo de aprendizagem ¢ compreensio que torna a roratividade de pessoal um desastre. CONFORMIDADE. As pessoas que trabalham com software no estio sozinhas quan- dlo encaram a complexidade, A fisica lida com objetos trrivelmente complexos mesmo no nivel de particulas “fundamentais’. ‘Todavia, o fisico trabalha na firme renga de que existem principios unificantes a serem encontrados, sejam nos stein repetia 0 argumento de que ‘quarks ou na teoria dos campos unificados. Ei ; deve haver explicagées simples para a natureza, uma vez que Deus nio é capri- choso nem arbitririo. Nio hi crenga assim que dé conforto ao engenheito de software. A maior parte da complexidade que ele deve dominar é arbitréria, imposta sem rima ou azo por muitos sistemas ¢ instituig6es humanas ’s quais suas interfaces devem estar em conformidade. Isso muda de interface para interface ¢ de tempos em tempos, néo em fungio de necessidade, mas apenas porque elas sio projetadas por pessoas diferentes ¢ nao por Deus. i Em muitos casos, 0 software deve adequar-se porque veio & cena mais recen- temente. Em outros porque cle é percebido como o de mais ficil adequacio. Mas mn todos os casos, muito da complexidade decorre da conformidade com outras sfaces. Iss0 no pode ser simplificado apenas pelo reprojeto do software. MUTABILIDADE. A entidade de software é constantemente sujeita a pressées em prol de uma mudanga. Claro, isso é verdade também no que diz respeito a roduzido nao costuma so prédios, auroméveis, computadores. Mas 0 que frer modificagoes depois que sai da fibrica. Os produtos se sucedem em novos modelos, ou modificagées essenciais séo incorporadas em cépias com niimero da série mais recente do mesmo projeto bisico. O recolhimento (recall ou eall- ack) de aucoméveis costuma acontecer poucas vezes, € as mudangas de enge- nharia no campo de computadores, de certa forma, ainda menos. Os dois casos siio muito menos frequentes que as modificagGes de softwares que jd estéo com seus usuarios. | Em parte, isso acontece porque sofrware em um sistema incorpora suas fungées, ¢ cada funglo a parte que sente a maior pressio para a mudanga. Em outra parte, é porque o software pode ser modificado com mais facilidade ~ € pura matéria de pensamento, infinitamente maledvel. Prédios sao, de fato, modi- ficados, mas os custos altos dessas mudangas, compreendidos por todos, servem para frear o impeto dos modificadores. i ‘Todo software de sucesso acaba por ser modificado. Dois processos ocorrem: Como a utilidade de um produto de software & descoberta, as pessoas tentario, tilizé-lo até o limite, ow akém, de seu dominio original, As pressoes em prol da mpliagio de sua funcionalidade vém, primeiramente, de usuirios que gostam de sua funcionalidade isica e invent m novos usos para ela, im segundo lugar, a vida de um sofiware de sucesso vai além da vida da mé quina— veiculo para a qual ele foi inicialmente escrito. Se nao novos computado- tes, surgem ao menos novos discos, novos terminais, novas impressoras, ¢ 0 soft- ware deve estar em conformidade com esses novos veiculos de oportunidades. Em suma, 0 produto de software esté inserido em uma matriz cultural de aplicagées, usuitios, leis e méquinas-veiculo, Todos estes mudam continua- mente ¢ suas mudangas inexoravelmente forcam seu reflexo no produto de software. INVISIBILIDADE. Software ¢ invisivel e é impossivel criar uma boa representagio visual para ele. Abstragdes geométricas séo ferramentas poderosas. A planta baixa de um prédio auxilia tanto arquiteto como o cliente na avaliacio de espacos, fluxo de erafego, vistas. As contradigdes tornam-se Sbvias, omiss6es podem ser detectadas. Modelos em escala de pecas meciinicas e montagens de encaixe repre sentando moléculas, mesmo sendo abstrages, servem ao mesmo propésito. Uma tealidade geométrica ¢ capturada em uma abstracdo geométrica. A realidade do software nao esti intrinsecamente inscrida no espago. As- sim, nao hé representa¢o geométrica pronta para representé-lo, da mesma forma que um terreno tem mapas, circuitos integrados tém seus diagramas, © computadores tém seus diagramas esquemiticos de conectividade. Tio logo tentamos diagramar uma estrutura de software, descobrimos que ela nao é ape- has um, mas, sim, virios grafos genericamente direcionados, superpostos um. acima do outro. Os varios grificos podem representar 0 fluxo de controle, 0 fluxo dos dados, padroes de dependéncia, sequéncia de tempos, relagoes de es- paco de nomes, Estes no estio sequer em uma estrutura planar, quanto menos hierérquica, De fato, uma das maneiras de se estabelecer 0 controle conceitual para tal estrutura é forgar 0 corte de conexées até que um ou mais dos graficos tornem-se hierarquicos.? Apesar do progresso na restrigio e simplificacéo das estruturas de software, clas continuam com sua representagio visual dificil, néo permitindo, assim, a devida atengio a suas mais poderosas ferramentas conceituais. Essa lacuna no prejudica apenas 0 processo de projeto dentro de uma mente, mas também im- pede severamente a comunicacio entre as mentes. Avancos do Passado Resolveram Dificuldades Acident Se examinarmos as trés etapas que mais frucificar cccnologia de soft- ware no passado, descobriremos que cada qual atacou u dificuldade na construgio de software, mas essa dificuldades foram as acidentai diferente e principal ciais. Também podemos verificar os limiteis naturais para a extrapo- lagao de cada um desses ataques. LINGUAGENS DE ALTO NIVEL. Decerto, o mais poderoso avango na produtivida- de, confiabilidade e simplicidade no desenvolvimento de software tem sido © uso progressivo de linguagens de programagio de alto nivel. A maioria dos observadores credita a esse avango no minimo um multiplicador por cinco na produtividade, com ganhos concomitantes em confiabilidade, simplicidade € abr ygencia, ‘© que se obtém com uma linguagem de alto nivel? Ela elimina do programa muito de sua complexidade acidental. Um programa abstrato consiste em cons~ trugoes conceituais: operacées, tipos de dados, sequéncias e comunicagéo. Um programa concreto de méquina preocupa-se com bits, registradores, condigbes, saltos, canais, discos ¢ assim por diante. A medida que a linguagem de alto nivel incorpora as construgdes desejadas a0 programa abstrato ¢ evita todas as demais construgées de nivel mais baixo, ela elimina um degrau completo de complexi- dade que de forma alguma era inerente ao programa. (O melhor que uma linguagem de alto nivel pode fazer é fornecer todas as construgées que 0 programador imagina no programa abstrato, Com certeza, 1 nivel de nossa sofisticacéo de pensamento sobre estruturas de dados, tipos de dados ¢ operagées est aumentando constantemente, mas a uma taxa de cresci- ‘mento sempre menor. E o desenvolvimento de linguagens aproxima-se cada vea ais da sofisticagao dos usuérios. ‘Além disso, em determinado ponto, a elaboragio de uma linguagem de alto nivel torna-se um fardo que aumenta, em vez de reducir, a atividade intelectual do usuario que raramente usa construgées esotéricas COMPARTILHAMENTO DE TEMPO (TIME-SHARING]. A maioria dos observadores cre dita ao compartilhamento de tempo um grande aumento na produtividade dos progtamadores ¢ na qualidade de seu produto, embora nao seja tao grande quan to aquele trazido pelas linguagens de alto nivel O compartilhamento de tempo ataca uma dificuldade bem diferente. Ele preserva a instantaneidade e assim nos permite manter uma visio panorimica da nplexidade. O longo tempo de espera da programagio em lote significa que inevitavelmente esquecemos algum detalhe, se ndo a completa esséncia, do que «stivamos pensando no momento em que paramos de programar e submetemos 0 programa a compilagio e execugio. Essa interrupgio da consciéncia custa tempo, ji que precisamos retomé-la, O efeito mais grave pode ser, muito bem, a queda na compreenséo de tudo 0 que acontece em um sistema complexo, longo tempo de espera, como o causado por complexidades de linguagem cle maquina, é uma dificuldade acidental, e nfo essencial, no processo de software. (Os limites da contribuicio do compartilhamento de tempo sio diretamente deri- vados. O principal efeito é diminuigio do tempo de resposta. Ao aproximar-se de zero, em algum ponto ele ulerapassa o limite da percep¢io humana, cerca de 100 milissegundos. Além desse ponto, nio hi beneficios que possam ser esperados. AMBIENTES DE PROGRAMACAO UNIFICADOS. Unix « Interlisp, os primeiros ambien- tes integrados de programagao a serem utilizados em larga escala, proporciona- ram a percepgio de aumento de produtividade por fatores integrais. Por qué? Eles atacam as dificuldades acidentais no uso de programas em conjunto, fornecendo bibliotecas integradas, formatos unificados de arquivos, canais (pipes) e filtros. Como resultado, estruturas conceituais que, a principio, poderiam sem- pre chamar, alimentar e usar uma a outra podem, de fato, fazer isso facilmente nna pritica. ‘Tamanho avanco, por sua ver, estimulou o desenvolvimento de bancadas de trabalho compleras (coolbenches), pois cada nova ferramenta poderia ser aplicada a qualquer um dos programas que utilizam formatos padrio. Por causa desse éxito, ambientes de desenvolvimento sio o objeto de grande parte da pesquisa atual em engenharia de software. Vamos analisar suas promes- sas ¢ limitagdes na préxima secao. Esperancas para a Prata ‘Vamos agora examinar os desenvolvimentos técnicos que costumam ser mais considerados balas de prata em potencial. Que problemas eles apontam? Eles sao problemas essenciais ou sio os restos de nossas dificuldades acidentais? Eles proporcionam avangos revolucionarios ou incrementais? ‘ADA E OUTROS AVANCOS EM LINGUAGENS DE ALTO NIVEL. Um dos desenvolvimentos recentes mais propalados é a linguagem de programagio Ada, uma linguagem de propésito geral, de alto nivel, da década de 1980. Ada, de fato, nao apenas rflete elhorias evolutivas em conceitos de linguagens mas também incorpora fungées que encorajam um projeto modemno c conceitos de modularidade. Talvez, a filo= sofia Ada seja um avango maior do que a linguagem Ada, jé que é a filosofia da modularidade, da abstragio de tipos de dados, da estruturagio hierdrquica. Ada 6 talver, rica em excesso, resultado natural do processo pelo qual 0s requisitos foram postos em seu projeto. Isso nao é fatal, j4 que subconjuntos funcionais de vocabulérios podem resolver o problema de aprendizagem, e os avangos no hardware nos daréo os MIPS baratos para compensar os custos de compilagao. O avango da estruturagio de sistemas de software é, na verdade, um excelente uso para os MIPS adicionais que nosso dinheiro poder comprar. Sistemas operacio= muito criticados na década de 1960 por seus custos de meméria e ciclos de processamento, tém provado ser uma excelente forma pela qual 0 uso de alguns MIDS e bytes de meméria baratos dao sobrevida a hardware do passado. nda assim, a linguagem Ada nao provard ser a bala de prata que mata 0 monstro da produtividade de software. Ela é, enfim, apenas uma outra lingua- gem de alto nivel, ea maior recompensa de tais linguagens vem da primeira tran= sigio da complexidade acidental da maquina para a declaragdo mais abstrata dé solugées passo a passo. Assim que esses acidentes se resolverem, os restantes serio ppequenos ¢ a recompensa de sua remogio serd, decerto, menor. Posso prever que, em dez anos, quando a eficicia da linguagem Ada for avaliada, seri possivel observar que ela fer uma substancial diferenga, néo por causa de uma funcionalidade particular da linguagem nem por causa de todas as funcionalidades combinadas. Tampouco provario os novos ambientes Ada se= rem a causa de tais melhorias. A maior contribuicao da Ada sera que, a0 passar a utilizila, programadores ocasionalmente serio treinados em técnicas modernas para o projeto de software. PROGRAMACAO ORIENTADA A OBJETOS, Muitos estudantes da arte mantém mais ‘sperangas na programagio orientada a objetos do que em qualquer outro mo- dismo técnico de hoje.’ Estou entre eles. Mark Sherman, de Dartmouth, observa ‘que devemos ter cuidado ao distinguir duas ideias separadas que estio sob 0 : tipos abstratos de dados e tipos hierarquicos, também chamados classes, O conceit do tipo abstrato de dados é 0 de que um tipo de objeto deve ser definido por um nome, um conjunto de valores apropriados € um conjunto de operagoes apropriadas, em ver de por sua estructura de armazenamento, que deve estar escondida. Exemplos sio os pacotes Ada (Ada packages) com tipos pri- vados (prinate types) ou os médulos da linguagem Modula. Tipos hierarquicos, como as classes do Simula-67, permitem a definigao de icas que podem ser depois refinadas pelo fornecimento de tipos rarquias sem interfaces gen: subordinados, Os dois conceitos sio ortogonais ~ podem existir que algo seja escondido (como no caso anterior da estrutura de armazenamento) e que algo seja escondido sem que existam hierarquias. Ambos os conceitos re- presentam avangos reais na arte da construgio de software. Cada uma dessas ideias elimina uma ou mais dificuldades acidentais do pro- cesso, permitindo ao projetista expressar a esséncia de seu projeto sem ter de ex- pressar grandes quantidades de material sintético que nao acrescentam nenhum conteiido novo de informagio. Tanto para tipos abstratos quanto para tipos hie- rirquicos, 0 resultado & a remogo de uma alta ordem de tipos de dificuldades acidentais, permitindo uma mais alta ordem de expressio do projeto. Mesmo assim, tais avangos no podem fazer nada além de remover todas as dificuldades acidentais da expressio do projeto. A complexidade do projeto em si é fundamental, e tais ataques néo fazem diferenga alguma. Um ganho de ordens de grandeza pode ser obtido com a programacio orientada a objeto apenas se a lesnecessitia especificagéo subjacente de tipos, remanescente hoje em nossa lin- ‘guagem de programagio, for por si s6 responsivel por nove décimos do trabalho envolvido no projeto de um programa produto. Tenho ci minhas diividas. INTELIGENCIA ARTIFICIAL. Muiras pessoas esperam que os progressos em inteligéncia artificial tragam o avanco revolucionario que ird dar ganhos de ordens de grandeza na produtividade e qualidade de software.‘ Eu nio. Para ver 0 porqué, devemos dissecar o significado de “inteligéncia artificial” e ver como ela se aplica. Parnas esclareceu 0 caos terminolégico: as denies bastante diferentes de 1A sio de uso comum bj. 1A-I: 0 ws de compusadores ‘para rover problemas que apenas poderiam ser previamentersolvides com aaplca da inte- ligencia humana. I-20 uso de um conuntoespecifio de tencas de progamagio,conhecdas come heuritica on programas bascada em regns (rule-based programming). Neva aborda- gem expecabnas humanos so extudados para detrminarquais heuriscas on reas psa ele tilzam na solo de problemas.) O pregnma €projetade para rover um problema da ‘mancira que os humans parecem soluiond-l A primein defini tem um signifade coregadia(..)Agumas cosas podem encaisarse ua dein de IA hoje, mas ma vez que verifiguemas como » programa funciona eentendamey 0 problema, nao mais pencaremas que ele € 1A. (.)nfelizmente eu nde poso idenifcar uma parte detenologia que € nia nese campo. (.) A maioria do tabalb éepecifamente rela cionade & um problema, ¢alguma absragéo ou criatvidade é necesiria para ver como fazer soma analogia’ Concordo plenamente com essa critica. As técnicas utilizadas para 0 recos nhecimenco da fala parecem ter muito pouco em comum com aquelas usadas para o reconhecimento de imagens, eambas diferem daquelas usadas em sistemas «specialistas. Eu tenho dificuldade em ver como o reconhecimento de imagem, por exemplo, faré alguma diferenga considerével na pritica de programagio. O 10 é verdade para o reconhecimento da fala. A dificuldade em se construir 1m software esti em decidir o que dizer, nao em dizer. Nada que facilite a expres: sio pode trazer mais do que ganhos marginais. A tecnologia de sistemas especic istas, AI-2, merece uma segio prépria. SISTEMAS ESPECIALISTAS (EXPERT SYSTEMS). A parte mais avancada da arte de inte- ligéncia artificial, ¢ a mais amplamente aplicada, 6a tecnologia para a construgio de sistemas especialistas. A maioria dos cientistas de software é diligent na apli- cagio dessa tecnologia a0 ambiente de construcio de software.> Qual €0 conceito, © 0 que ele busca? Um sistema especialista € um programa que contém um motor genético de inferéncia e uma base de regras, projetado para tomar dados e premissas como entrada e explorar as consequéncias légicas por meio das inferéncias derivadas a partir da base de regras, chegando a conclusées e conselhos e oferecendo a explicagéo de seus resultados mediante o tragado de seu raciocinio para o usu rio. Uma caracteristica € que motores de inferéncia podem lidar com dados ~ confusos (fuzzy) ou probabilisticos ~ e regras, em adigao a légica puramente deterministica. ais sistemas oferecem algumas vantagens claras sobre algoritmos programa- dos para chegar is mesmas solugdes no tocante aos mesmos problemas: + A tecnologia do motor de inferéncia é desenvolvida de forma indepen- dente da aplicagio, podendo ser utilizada de varias maneiras. O esforgo muito maior para o desenvolvimento de motores de inferéncia pode ser justficado, De fato, essa tecnologia esté bastante avanada. + As partes cambiiveis dos materiais peculiares & aplicagio sto codificadas na base de regras de maneira uniforme, ¢ ferramentas sio fornecidas para 6 desenvolvimento, a modificagio, teste ¢ a documentagio da base de regras. Isso redutz muito a complexidade da propria aplicagio, Edward Feigenbaum diz que o poder de tais sistemas no vem dos cada ver mais elegantes mecanismos de inferéncia, mas das cada vez mais ricas bases de conhecimento que refletem o mundo real com mais precisio. Eu creio que 0 mais importante avango proporcionado pela tecnologia é a separagdo entre a comple- xidade da aplicacio ¢ 0 préprio programa. Como isso pode ser aplicado ao desenvolvimento de software? De muitas maneiras: sugerindo regras de interface, aconselhando em estratégias para testes, lembrando as frequéncias de ocorréncias de tipos de problemas, oferecendo dicas de otimizacio, etc. Pense em um conselheiro imagindrio de testes, por exemplo. Em sua forma mais rudimentar, um sistema especialista para diagnésticos é muito parecido coma lista de verificagao de um piloto, fundamentalmente oferecendo sugestoes para as possiveis causas de dificuldade, De acordo com o desenvolvimento da base de regras, as sugest6es tornam-se mais especificas, levando mais sofisticada- ‘mente em conta os sintomas dos problemas relatados. E possivel visualizar um assistente de depurasio que oferece, inicialmente, sugestbes bastante genéricas, mas, & medida que mais ¢ mais a estrucura do sistema é incorporada na base de regras, mais ¢ mais particulares tornam-se as hipéteses que ele gera ¢ 0s testes {que recomenda, Tal sistema especialista pode divergir radicalmente dos conven- cionais, jé que sua base de regras talver. pudesse ser modularizada hierarquica- mente, correspondendo com exatidio ao produto de software. Assim, quando 0 produto é modificado de forma modular, a base de regras de diagnésticos pode set modificada também da mesma forma. (O trabalho requerido para gerar as regras de diagnéstico é mesmo que ter de ser feito, de qualquer maneira, para gerar 0 conjunto de casos de testes para os ‘médulos ¢ para o sistema. Se for exccutado de uma maneira genérica aprop! com uma estrutura uniforme para as regras e para um bom motor de inferéncia disponivel, isso pode, de ato, reduzir 0 esforco total na introdugio de casos de teste ¢ também ajudar durante todo o tempo de vida de manutengio ¢ testes de modificagées. Da mesma forma, podemos postular outros conselheiros — prova- velmente muitos dees, ¢ provavelmente muito simples ~ para outras partes da tarefa de construcéo de software. Muitas dificuldades impedem que cedo se perceba a utilidade de conselheitos «specializados para o desenvolvedor de programas, Uma parte crucial desse pano- rama imagindrio é 0 desenvolvimento de maneiras simples para sair da especifi- cago da estrutura do programa rumo & geragdo automatica ou semiautomdtica de regras de diagndsticos. Ainda mais dificil e importance é a tarefa, dividida em duas partes, da aquisigao de conhecimento: encontrar especialistas articulados, capazes de autoanalise, que saibam 0 porgué de fazerem as coisas; ¢ desenvolver técnicas eficientes para extrair 0 que eles sabem, destilando tal saber em bases de regras. O requisito essencial para a construcéo de um sistema especialista é ter um especialista. A contribuigéo mais poderosa de sistemas especialistas sera, decerto, a de pt 4 servigo do programador inexperiente a sabedoria ¢ a experiéncia acumuladas pelos melhores programadores. Nao é uma contribuicéo pequena. A lacuna en- tre a melhor pritica de engenharia de software e uma pritica mediana é muito grande ~ talvez maior do que em qualquer outra disciplina de engenharia. Uma ferramenta que dissemina a boa pritica seria importante, PROGRAMACAO “AUTOMATICA. Hi quase 40 anos as pessoas estdo antevendo e escre- vendo sobre “programagio automidtica’, a geragdo de um programa para resolver um problema a partir da descrigio das especificagées de tal problema. Algumas pessoas escrevem, hoje, como se estivessem na expectativa de que essa tecnologia venha a prover 0 préximo avango.” Parnas insinua que 0 termo € usado no sentido de glamour, nao semintica, afirmando: Em suma, a pregramagio auromética tem sido um exfemismo para a programasio com uma linguagem de alte nivel que néo estédisponivel, no momento, ao programador® No fundo, ele argumenta que na maioria dos casos é o método de solucio, € ‘nfo o problema, para o qual a especificagéo necessita ser dada. Existem as excegées. A técnica para a construgio de geradores é muito pode= rosa e é geralmente usada, com grande vantagem, em programas para ordenagio, ‘Alguns sistemas para a integracao diferencial de equagdes também permititam @ especificagio direta do problema. O sistema avaliavaos parimettos, escolhia uma reca de métodos de solugio ¢ gerava os programas, ae Kamera © ncrURme em EnYeTMeTNE Ue DOrTware 1B Essas aplicagoes tém propriedades bastante favoriveis: * Os problemas so prontamente caracterizados por uma quantidade relati vamente pequena de parimetros. + Ha muitos métodos conhecidos de solugio que fornecem uma bibliotec: de alternativas. * Aaanilise extensiva levou a regras explicitas de selegao das técnicas de solu ‘10, dados os parametros do problema. verificar como tais regras podem ser generalizadas para o munde mais amplo do sistema de software normal, em que casos com propriedades tio puras so a excecao. E também dificil imaginar como tal avango em generalizagio poderia, concebivelmente, acontecer. PROGRAMACAO GRAFICA. Uma matéria favorita para dissertagées de Ph.D. em en- sgenharia de software é a programagio grifica ou visual, a aplicagéo da computa- do grafica para projeto de software.’ As vezes, a promessa de tal enfoque é pos- tulada a partir da analogia com o projeto de chips VLSI,* no qual a computagéo grifica tem um papel importante. Outras vezes, a abordagem é justificada a0 considerar que diagramas de fluxo so 0 meio ideal para o projeto de programas © que é preciso fornecer ferramentas poderosas para a sua construgio. Nada sequet convincente ¢ tampouco emocionante surgiu, ainda, de tais cesforgos. Estou convencido de que nada surgird Em primeiro lugar, como jé argumentei em outro texto, o diagrama de fluxos € uma abstragio muito pobre da estrutura de software." De fato, ele é mais bem visto como uma tentativa de Burks, von Neumann ¢ Goldstine de fornecer uma linguagem de controle de alto nivel, incrivelmente necessiria, a seu computador proposto. Na forma deploravel, com multiplas paginas, cheia de caixas de cone- xdo em que o diagrama de fluxos é elaborado hoje, ele se revelou basicamente inl como ferramenta de projeto ~ programadores desenham seus diagramas de fuxo depois, nao antes, de escrever os programas que tais diagramas descrevem. Em segundo lugar, os terminais de video atuais so muito pequenos, em pi- xels, para mostrar tanto 0 escopo quanto a resolugio de qualquer diagrama sério Grito inerado com sso mimeo de components. VLSI gnc Vry Lag Se nepation, ose) ine ast em eal muito mpl. (NT) ‘¢ detalhado de software. A dita “metifora da mesa de escritério” de uma estagio to do avido”. Qualquer de trabalho atual é em lugar disso, a metifora do “ass 1 que tenha lidado com uma grande quantidade de papéis enquanto sentado na classe econdmica de um aviéo, a0 lado de dois passageiros robustos, iré reconhe- cer a diferenga ~ é possivel lidar apenas com pouquissimas coisas de cada vez. A isio panorimica ¢ 0 acesso aleatério a verdadeira mesa de trabalho fornece uma tum bom niimero de papéis. Além disso, quando as doses de criatividade aumen- tam, mais do que um programador ou escritor ficaram conhecidos por abando- har a mesa de trabalho para o mais espacoso assoalho. A tecnologia de hardware de avangar muito substancialmente antes que a capacidade de visualizacio de ossos objetivos seja suficiente para a tarefa de projeto de sofeware.* Mais fundamentalmente, como jé argumentei, 0 software € muito dificil de se-visualizar. Quer diagramemos o fluxo de controle, o agrupamento das varidvels segundo seu escopo, referéncias cruzadas entre varidveis, fuxo de dados, estru tuias hierirquicas de dados, ou seja ki o que for, nés perceberemos apenas uma dimensio do rigorosamente interligado clefante de software. Se sobrepusermos todos os diagramas getados por muitas visualizagbes relevantes sera dificil extrait dda( qualquer panorama global. A analogia com 0 VLSI é em si enganosa ~ 0 pro- jero de um chip é um objeto com camadas bidimensionais, cuja geometria reflete sua esséncia, Um sistema de software nao é assim. VERIFICACAO DE PROGRAMA. Muiro do esforgo em programagio moderna é dedi- cado a0 teste € 4 solugao de bugs. Sera que existe, talvez, uma bala de prata que climine os erros em sta fonte, na fase de projeto do sistema? Sera que a produ- tividade e a confiabilidade do produto podem ser radicalmente melhoradas 20 se seguir a estratégia profundamente diversa de testar com corresio 0s projetos, antes que uma quantidade imensa de trabalho seja colocada na implementagéo ¢ teste dos mesmos? Nio acredito que encontraremos a magica aqui. A verificagio de programa & um conceito poderoso ¢ seré muito importante para coisas como nticleos de sistemas operacionais seguros. A tecnologia néo promete, entretanto, economizat seo gna. ie he ope afer soe fice the oftoere ds sk." A ado iter pori Tee "sotes que a ecop de nosios cop” mar la perders mute de seu semtido, lm de perder rtlmenve aida {Eativocdmico emda no texto, que ao pimiro "cape" no Sento do qu € pose ver

    Você também pode gostar