De Arte a Cincia: Procura dos Princpios Fundamentais do Desenvolvimento de Software

O desenvolvimento de grandes sistemas de software difcil e imprevisvel. Os projectos de software so frequentemente cancelados, terminam fora de prazo, excedem os oramentos, ou produzem resultados de baixa qualidade. Tudo isto faz com que a engenharia de software seja bastante diferente de outras disciplinas de engenharia convencionais. Analisando as coisas de forma superficial, os problemas da engenharia de software podem ser facilmente explicados pelo facto do desenvolvimento de software ser artesanato e no uma disciplina da engenharia. Para se tornar uma disciplina da engenharia, o desenvolvimento de software ter que passar por uma mudana de paradigma, deixando a fase do teste e erro e especificar um conjunto de princpios fundamentais. Neste primeiro artigo (dividido em duas partes) procuramos suportar esta teoria e propor um primeiro princpio de desenvolvimento de software, assim como um conjunto correspondente de requisitos de software axiomticos. No segundo artigo, ser apresentado um conjunto de regras de desenho "universal design pattern" que apresenta quatro tipos de elementos de desenho. Os quatro tipos combinados permitem descrever um sistema de software completo numa nica viso. Arte versus engenharia Quando olho para as fabulosas catedrais gticas europeias, costumo perguntar quem foram os arquitectos que as desenharam e as construram. Como que adquiriram o conhecimento necessrio para criarem estruturas que, alm de belas, tambm so suficientemente robustas para resistir s foras da natureza durante sculos? Como que conseguiram construir esses edifcios sem computadores, sem ferramentas hidrulicas e sem os modernos materiais de construo? Claramente, os arquitectos medievais tinham um conhecimento extraordinrio sobre o desenho e construo de edifcios pelo que eram altamente respeitados e honrados como mestres da sua profisso. De facto, eram mestres, mas no merecem ser chamados de engenheiros. Porque no? A razo simples. Apesar dos arquitectos medievais terem um conhecimento profundo sobre a forma de como construir edifcios altos, no sabiam nada sobre as leias da fsica. Sabiam que a forma de um tecto em arco tinha que ser cnica, mas nunca ouviram falar de

equaes diferenciais. O conhecimento dos arquitectos medievais baseava-se exclusivamente na experincia resultante do teste e erro e no tinha qualquer fundamento cientfico. Em resumo, podemos dizer que os arquitectos medievais sabiam como fazer as coisas, mas no tinham qualquer ideia sobre a razo porque as coisas tinham que ser feitas dessa formai. O desenho e a construo de edifcios eram uma arte, pelo que os mestres medievais de arquitectura eram artistas e no engenheiros. A diferena entre o mestre de arquitectura medieval e o moderno engenheiro civil tem a ver com o facto deste ltimo compreender a razo das regras arquitecturais. Pode deduzir as regras a partir das leis da fsica e, consequentemente, provar a fiabilibilidade de um desenho antes de efectuar qualquer trabalho de construo e mesmo que no tenha qualquer experincia prtica. Pelo contrrio, os arquitectos medievais tinham que acumular esse conhecimento lenta e penosamente, atravs do processo de teste e erro. Eventualmente, alguns tornavam-se mestres e passavam os seus conhecimentos aos aprendizes. Alguns desses aprendizes acabariam tambm por se tornar mestres e passar o seu conhecimento aos aprendizes das geraes seguintes. Foi assim que a arte medieval da arquitectura foi amadurecendo lentamente ao longo do tempo mas continuando a ser arte. O desenho e a construo de edifcios passou abruptamente de arte para uma disciplina da engenharia quando se passou a basear nos fundamentos cientficos fornecidos pelas leis da fsica. A maturidade, por si s, no transforma uma arte numa disciplina da engenharia. A engenharia requer uma mudana de paradigma. A arte baseia-se no teste e erro, enquanto que a engenharia se baseia num conjunto de princpios fundamentais (frequentemente as leis da fsica aplicveis). A partir desses princpios, todo o conhecimento pode ser inferido. O teste e erro o selo da arte, enquanto os princpios fundamentais so o selo da engenharia. O que actualmente o desenvolvimento de software? Com base nesta distino, caso para perguntarmos se actualmente o desenvolvimento de software arte, uma disciplina da engenharia, ou algo intermdio. Muitos especialistas em desenvolvimento de software declarariam provavelmente que o desenvolvimento de software ainda no uma disciplina da engenharia, mas est a avanar nesse sentido. Eu acho que essa ideia uma miragem. Na minha opinio, o desenvolvimento de software arte pura. No pode ser uma disciplina da engenharia e no tem nenhum dos aspectos da engenharia porque no tem princpios fundamentais. Todo o conhecimento de como se desenvolve software baseia-se exclusivamente no processo de teste e erro. verdade que j foram efectuados alguns progressos desde o surgimento do desenvolvimento de software. Alguns mestres do desenvolvimento de software como Grady Booch, Jim Rumbaugh e Walker Royce, por exemplo inventaram mtodos e regras bem sucedidos para guiar aqueles que fazem desenvolvimento de software. A esses mtodos e regras chamamos normalmente boas prticas. Mesmo assim, tal como os arquitectos medievais, os especialistas em desenvolvimento de software aprenderam e validaram essas boas prticas atravs do teste e erro. Aquilo que falta actualmente ao desenvolvimento de software um conjunto de princpios fundamentais onde se possam basear as suas regras e mtodosii. A falta de princpios fundamentaisiii de desenvolvimento de software tem consequncias srias, frequentemente materializadas na expresso a crise do software. Os projectos de software so muitas vezes cancelados antes da sua concluso. Por sua vez, aqueles que so concludos excedem frequentemente o oramento e os prazos, ou fornecem resultados de baixa qualidade. Como outros autores j explicaram, o factor chave para o sucesso de um projecto de software

uma boa arquitectura. A incapacidade para criar rotineiramente uma boa arquitectura exactamente aquilo que distingue o desenvolvimento de software das disciplinas de engenharia tradicionais. Mas porque razo existe esta embaraosa discrepncia? Ao contrrio do especialista em desenvolvimento de software, o engenheiro utiliza um conjunto de princpios fundamentais para provar a qualidade de um desenho antes de ser efectuado qualquer trabalho de construo. Pelo contrrio, quem desenvolve software ter que se basear em testes para avaliar a qualidade de uma arquitectura. Ou seja, tem que chegar a uma boa arquitectura atravs de um processo de teste e erro. Este facto explica a razo porque os dois maiores problemas dos projectos de software mal sucedidos so os fragmentos tardios e o trabalho repetido, assim como o fracasso tardio do desenho. Os especialistas em desenvolvimento de software criam um desenho arquitectural no incio do desenvolvimento de software, mas no tm qualquer forma de avaliar imediatamente a qualidade desse desenho. Os especialistas em desenvolvimento no tm princpios fundamentais para provar se o desenho adequado. O teste do software revelar eventualmente todos os defeitos arquitecturais, mas isso s acontece numa fase posterior do desenvolvimento, quando a correco desses defeitos j onerosa e causadora de perturbaes. O que h de diferente na engenharia de software? A incapacidade da comunidade de especialistas em desenvolvimento para transformar o desenvolvimento de software numa disciplina da engenharia bem sucedida provocou alguns embaraos. O baixo sucesso dos projectos de software coloca claramente o desenvolvimento de software margem das disciplinas de engenharia. Foram propostas muitas razes para explicar porque razo a engenharia de software teria de ser diferente das outras disciplinas da engenharia. De seguida, vamos ver trs exemplos bem conhecidos. Todas as disciplinas da engenharia envolvem elementos de arte e cincia. Esta afirmao verdadeira, mas o elemento cientfico e no o artstico que distingue a engenharia da arte. O elemento cientfico exactamente aquilo que falta ao desenvolvimento de software, uma vez que no tem princpios fundamentais (onde se deve basear qualquer cincia). Por outro lado, o elemento artstico da engenharia negocivel. Uma ponte desenhada por um engenheiro civil pode ser feia, mas ser certamente segura. Pelo contrrio, o desenvolvimento de software totalmente arte e a qualidade de um sistema depende apenas das capacidades artsticas de quem o desenvolveiv. Outras disciplinas da engenharia tm uma longa histria e uma grande experincia passada, mas a engenharia de software ainda est no seu estado de infncia. De facto, muitas disciplinas da engenharia tm uma longa histria, uma vez que emergiram de uma arte antiga. No entanto, a transio de arte para uma disciplina da engenharia no uma questo de maturidade. sempre o resultado de uma mudana de paradigma, passando do teste e erro para um conjunto de princpios fundamentais. A maior parte das modernas disciplinas da engenharia efectuaram essa mudana de paradigma de forma bastante abrupta quando passaram a basearse nas leis da fsica. O desenvolvimento de software porque no tem nenhuma base cientfica continua a ser uma arte. Apesar de aumentar a sua maturidade ao longo do tempo, este aspecto, por si s, no ir torn-la uma disciplina da engenharia. Os projectos de software so to imprevisveis porque o software tem uma flexibilidade ilimitada. Isto no faz qualquer sentido. A verdade que muitos especialistas em desenvolvimento de software no sabem como criar boas arquitecturas de software, nem como identificar as ms. A falta de princpios fundamentais no desenvolvimento de software faz com que seja impossvel distinguir objectivamente entre arquitecturas

boas e ms. Como tal, as arquitecturas de software so frequentemente ms. Mesmo assim, a grande flexibilidade do software verdade que o software muito flexvel permite que um projecto avance bastante no sentido da implementao, mesmo quando se trata da pior arquitectura. No entanto, eventualmente, os defeitos arquitecturais transformam-se em grandes obstculos, que causam muito trabalho fragmentado e repetido, alm de obrigarem a reforos oramentais e a atrasos e de produzirem geralmente software de baixa qualidade. No a grande flexibilidade do software que faz com que os projectos de software sejam difceis de gerir. antes a incapacidade dos especialistas em desenvolvimento de software para criarem boas arquitecturas, de forma rotineira e previsvel. O desenvolvimento de software inerentemente uma actividade de desenho Como que nos metemos nesta confuso? Porque razo o esprito de teste e erro est to profundamente impregnado no desenvolvimento de software? Porque no explormos as leis fundamentais do desenvolvimento de software e ainda no descobrimos os seus princpios fundamentais? Para respondermos a estas questes, precisamos de compreender que o desenvolvimento de software inerentemente uma actividade de desenho, sem qualquer aspecto de construo ou fabrico. Muitas pessoas podero achar esta afirmao difcil de aceitar, mas pode ser facilmente justificada. Temos uma boa compreenso daquilo que o desenho, onde termina e onde comea a construo ou o fabrico. Consideremos os dois argumentos que se seguem: 1. A fronteira entre o desenho e a construo est sempre bem marcada por um artefacto: o plano. O desenho envolve todas as actividades necessrias para criar um plano, enquanto que a construo envolve todas as actividades necessrias para criar produtos com base no plano. De uma forma ideal, o plano especificaria o produto a ser criado em todos os seus detalhes o que raramente acontece. Mesmo assim, o propsito de um plano descrever o produto que vai ser construdo, de forma to precisa quanto possvel. Ser que o desenho arquitectural de um sistema de software descreve o produto de forma to precisa quanto possvel? Nem pensar. O desenho arquitectural destina-se a descrever o essencial, mas no certamente todos os detalhes de um sistema de software. Desta forma, torna-se claro que o desenho arquitectural no um plano. S o cdigo de linguagem de alto nvel que descreve todos os detalhes de um sistema de software, posicionando-se assim como o plano do software. Uma vez que todas as actividades que conduzem ao plano so desenho, todo o desenvolvimento de software tem que ser desenho. 2. O esforo (tempo, dinheiro e recursos) necessrio para criar um produto comercial pode ser dividido em esforo de desenho e esforo de produo. Qual a diferena? O esforo de desenho comum a todas as cpias do produto e s feito uma vez. O esforo de produo tem que ser efectuado sempre que criada uma cpia do produto. Um produto de software tipicamente o executvel binrio de um programa disponibilizado num CD-ROM. Claramente, o esforo para criar o cdigo fonte de um programa incluindo o desenho arquitectural, o desenho detalhado e o cdigo de linguagem de alto nvel s tem que ser efectuado uma vez, independentemente do nmero de cpias que sejam produzidas do software. Desta forma, o esforo para criar o cdigo fonte de um programa inteiramente um esforo de desenho, pelo que todo o desenvolvimento de software desenho. Os especialistas em desenvolvimento de software no constroem software; desenham software. O resultado final desse esforo de desenho o cdigo de linguagem de alto nvelv o plano do software. o compilador/linker que constri mecanicamente o produto de software um binrio executvel a partir do cdigo de linguagem de alto nvel. O desenho arquitectural de um sistema de software corresponde aos modelos ou aos desenhos utilizados em algumas disciplinas da

engenharia. Para compreendermos a razo porque os especialistas em desenvolvimento de software ainda no identificaram os princpios fundamentais, imaginemos um mundo em que a criao de um arranha-cus no exigiria mais do que um plano detalhado. Com o plano (planta), bastaria a um arquitecto carregar num boto para ter o arranha-cus construdo instantaneamente e virtualmente por custo zero. O arquitecto iria depois testar o arranha-cus e compar-lo com as especificaes. Mesmo que o edifcio russe ou no passasse os testes, o arquitecto poderia demolilo e remover o entulho instantaneamente e, mais uma vez, sem qualquer custo. Ser que este arquitecto iria passar muito tempo a verificar formalmente se o desenho do arranha-cus era compatvel com as leis da fsica? Ou iria mesmo tentar explorar e compreender essas leis? Dificilmente. Provavelmente, conseguiria obter resultados mais depressa construindo, testando e demolindo o arranha-cus algumas vezes, melhorando o plano a cada tentativa. Num mundo onde a construo e a demolio so gratuitas, o teste e erro a abordagem de eleio. A investigao bsica para os anormais. O desenvolvimento de software acontece exactamente num mundo assim. Quem desenvolve software cria um plano do software sob a forma de um programa de linguagem de alto nvel. Depois disso, deixa para o compilador e para o linker a tarefa de construo do produto de software, algo que feito num piscar de olhos e virtualmente sem qualquer custo. A criao do plano requer um esforo considervel, mas a construo por meio do compilador e do linker praticamente gratuita. Desta forma, os especialistas em desenvolvimento de software no se preocupam certamente com a demolio e a remoo do entulho pelo menos, enquanto no esgotar o espao do disco. No admira, portanto, que o esprito do teste e erro esteja to profundamente enraizado no processo de desenvolvimento de software e que a comunidade que desenvolve nunca se tenha preocupado em explorar os princpios fundamentais do desenvolvimento de software. Na realidade, o teste e erro permitiu-nos evoluir muito ao longo do tempo. No entanto, com a complexidade crescente dos sistemas de software modernos, estamos a aproximar-nos do limite. Para alm de um certo nvel de complexidade, torna-se impossvel criar arquitecturas de qualidade com base no teste e errovi. Proposta: um primeiro princpio de desenvolvimento de software Sem princpios fundamentais, o desenvolvimento de software continuar a ser uma arte para sempre e persistir a chamada crise do software (projectos cancelados, atrasos, oramentos excedidos e baixa qualidade). , portanto, necessrio ir procura de alguns princpios fundamentais. Mas onde? As leis da fsica no se aplicam ao software. Ser que isto quer dizer que no existem princpios fundamentais no desenvolvimento de software? Ou ser que ns que ainda no procurmos suficientemente bem para os encontrar? Vejamos como que a presena de um princpio fundamental por exemplo, a lei da gravidade afecta a arquitectura de um sistema. De um ponto de vista abstracto, um princpio fundamental no faz mais do que induzir requisitos no negociveis, com os quais os arquitectos tm de lidar. A estes requisitos chamo requisitos axiomticos. Por exemplo, no mundo da construo civil, um simples requisito axiomtico seria: o edifcio deve resistir fora da gravidade. O que torna os requisitos axiomticos to especiais o facto de se aplicarem a todos os sistemas que alguma vez foram ou sero construdos. Na realidade, os requisitos axiomticos so to bvios e comuns que esto normalmente implcitos. No entanto, a partir dos requisitos axiomticos, as disciplinas tradicionais da engenharia derivaram um conjunto de regras arquitecturais regras essas que todos os planos ou desenhos tm de cumprir para merecerem ser considerados. Os desenhos que violam essas regras esto obviamente margem dos princpios fundamentais e tm

provavelmente falhas. Apesar de ser demasiado difcil identificar os princpios fundamentais do desenvolvimento de software, j bastante fcil encontrar alguns requisitos axiomticos requisitos que se aplicam a qualquer sistema de software. Apresentamos de seguida uma lista desses requisitos: O software tem que obter dados de uma ou mais interfaces externas (hardware). O software tem disponibilizar dados para uma ou mais interfaces externas (hardware). O software tem que manter dados internos para serem utilizados e actualizados a cada ciclo de execuo. O software tem que transformar os dados de entrada em dados de sada (utilizando possivelmente os dados internos). O software tem que efectuar transformaes de dados to rapidamente quanto possvel.

Isto parece bvio. Mas acreditem que so muito poucos os sistemas de software com uma arquitectura capaz de satisfazer (de forma bvia) os requisitos axiomticos apresentados atrs. Muitos sistemas de software podero satisfaz-los implicitamente, mas no de forma bvia. Os requisitos axiomticos apresentados parecem estar relacionados de alguma forma com o ambiente de hardware de um sistema de software. Consequentemente, proponho que o primeiro princpio fundamental subjacente do desenvolvimento de software o seguinte: o software corre com base em hardware e interage com hardware hardware esse que tem uma velocidade limitada. um pouco surpreendente que o ambiente de hardware desempenhe um papel to dominante na arquitectura de software. Muitas abordagens ao desenho de software parecem ignorar o ambiente de hardware a nvel das visualizaes lgica, estrutural e dinmica da arquitectura. O hardware tratado frequentemente como uma questo de implementao, com pouca significncia para a estrutura e comportamento arquitectural. No entanto, acredito que o ambiente de hardware deve ser uma das principais foras orientadoras para o desenho arquitectural de um sistema de software. Prximo passo: definir um padro de desenho universal Na segunda parte deste artigo, o enfoque colocado nas regras de desenho associadas aos princpios fundamentais e aos seus requisitos axiomticos. Essas regras representam um padro de desenho universal altamente til para orientar o desenho de software. O padro de desenho universal um primeiro passo no caminho para tornar o desenvolvimento de software uma actividade de engenharia previsvel e repetvel. ANEXO Uma explicao simples para a confuso do desenvolvimento de software O facto do desenvolvimento de software ser inerentemente uma actividade de desenho ajuda a explicar vrios aspectos que, de outra forma, seriam confusos. Deixamos de seguida alguns exemplos. Q. Porque razo muito mais difcil criar uma estrutura detalhada de trabalho para as implementaes de software do que para a construo de arranha-cus? R. Porque a implementao de software o equivalente do desenho do arranha-cus (ou seja, a criao da planta do edifcio) e no da sua construo. O trabalho de desenho naturalmente menos pacfico de planear do que o trabalho de construo, uma vez que a abrangncia e a complexidade do produto final s so descobertas ao longo do trabalho de desenho.

Q. Porque razo podemos implementar dois mdulos de software em paralelo, enquanto que os andares de um edifcio tm que ser construdos sequencialmente? R. Porque o equivalente da implementao do mdulo de software o desenho e no a construo de um andar de um edifcio. Dois arquitectos podem muito bem desenhar dois andares de um edifcio em paralelo, desde que respeitem certas limitaes de interface tal como dois especialistas em desenvolvimento de software podem implementar dois mdulos em paralelo. Pelo contrrio, o compilador com constri verdadeiramente o produto de software tem que compilar os mdulos de acordo com a sequncia correcta, tal como os andares de um edifcio tm de ser construdos de acordo com a sequncia correcta. Q. Porque razo no conseguimos obter economias de escala no desenvolvimento de software? R. A falta de economia de escala com que deparamos no desenvolvimento de software inerente sua natureza de desenho. Sabemos, com base noutras indstrias, que a economia de escala s se aplica a processos produtivos, no a tarefas de desenho. Isso acontece porque o desenho, alm de ter de lidar com cada um dos elementos de desenho, tem de lidar tambm com todas as interaces entre os elementos de desenho. O nmero de interaces entre os elementos de desenho aumenta com o nmero de elementos de uma forma no linear. Isto verdadeiro mesmo com uma reutilizao extensiva e com componentes comerciais j existentes. Como o desenvolvimento de software puro desenho, nunca conseguir atingir verdadeiras economias de escala. Q. Poderemos tirar partido de economias de escala na produo de software? R. No, porque os produtos de software so produzidos pelo compilador, o linker e outras ferramentas de sistema operativo por um custo largamente negligencivel. Como tal, o preo de escala de um produto de software s tem que cobrir o seu custo de desenho. Noutras indstrias, o custo de produo de cada cpia do produto diminui consideravelmente com o aumento do nmero de cpias produzidas. Isto no se aplica aos produtos de software. Q. Porque razo o software tem um nvel to baixo de reutilizao? R. Na maior parte das indstrias, a reutilizao de elementos de desenho existentes tem um duplo benefcio: acelera o desenho do sistema e diminui o custo de produo. Os componentes electrnicos, por exemplo, so to populares porque so baratos um resultado da produo em massa. Desta forma, a utilizao de componentes electrnicos standard permite baixar o tradicionalmente elevado custo de produo dos sistemas electrnicos. Infelizmente, isto no se aplica ao software, dado que os produtos desta natureza so produzidos por um custo quase inexistente. A integrao de componentes standard no permite poupanas em termos de produo. Antes pelo contrrio, pode obrigar ao pagamento de royalties. Baseado no artigo From Craft to Science: Searching for First Principles of Software Development, de Koni Buhrer, especialista em engenharia de software na Rational Software (IBM).

Tel: (+351) 239 497 230 / 2 Fax: (+351) 239 497 231 E-mail: tim@engenharia-software.com Internet: www.engenharia-software.com

Mais precisamente, o mestre medieval no tinha meios de justificar formalmente as coisas. Por exemplo, se um aprendiz perguntasse ao mestre porque teria de fazer as coisas dessa forma, o mestre teria de responder porque eu digo que assim. Um engenheiro moderno, pelo contrrio, j poderia responder: de

acordo com as leis da mecnica esttica se considerarmos esta frmula e por a adiante, acabando por fornecer uma justificao formal sobre a razo porque as coisas tm de ser feitas de uma certa forma.
ii

Algumas pessoas podero argumentar que as boas prticas constituem os princpios fundamentais do desenvolvimento de software. No entanto, no isso que acontece, infelizmente. A razo deve-se ao facto de no sabermos se essas boas prticas so realmente boas prticas. No temos qualquer saber sobre a razo porque uma prtica de desenvolvimento de software merece ser chamada de boa ou m apenas sabemos que foi bem sucedida em algumas aplicaes no passado. A identificao das boas prticas atravs de teste e erro poder conduzir-nos eventualmente a uma melhor compreenso dos princpios e mecanismos bsicos que determinam a qualidade de uma prtica de desenvolvimento de software. No entanto, por si s, a identificao das boas prticas no permite que o desenvolvimento de software ultrapasse o seu estado actual de arte.

Para ser mais claro, os princpios fundamentais no so princpios orientadores. Os princpios fundamentais so axiomas bem definidos que permitem a verificao formal das regras e procedimentos do desenvolvimento de software. Se for perguntado se um desenho bom, um engenheiro poder responder: apliquei as frmulas da mecnica esttica para verificar. Um especialista em desenvolvimento de software responderia: estou confidante que sim, dado que parece bom mais ou menos como um artista avalia uma escultura. Ou o desenho detalhado, se o compilador conseguir gerar cdigo directamente a partir dos modelos de desenho. O desenvolvimento iterativo s permite expandir o limite de complexidade que conseguimos gerir atravs do teste e erro.
vi v iv

iii