Engenharia Model Driven e Inteligência Artificial
Em oposição à tradicional programação manual, a utilização de modelos e a inteligência artificial são tópicos quentes na moderna engenharia do software. Quem experimenta, quem começa a trabalhar num ambiente MDE (Model Driven Engineering), já não sai deste contexto. Não quer regredir. Voltar atrás, à programação manual, significa perder produtividade, perder agilidade, perder capacidade de mudar a forma como se trabalha à sua volta, perder tempo. No fundo, perder qualidade de vida, e não apenas profissional.
A complexidade do software tem vindo sempre a aumentar. O número de camadas que suportam um sistema de informação (hardware, sistema operativo, SGBD, comunicações, browsers, programação), o número de tecnologias diferentes que são necessárias para o seu funcionamento, a evolução rápida e acelerada destas tecnologias, a dimensão e o número de componentes que compõem uma solução, os requisitos não funcionais (como eficiência, testabilidade ou experiência de utilização), as interações com muitos outros sistemas… Desenvolver software é hoje uma atividade extremamente complexa e altamente profissionalizada.
Como refere Vasco Amaral, professor da NOVA-FCT, vencer a complexidade é a razão de ser da Engenharia do Software.
E esta missão da Engenharia do Software tem um ainda maior desafio: as partes interessadas (os stakeholders) do software – aqueles que o usam, que nele se baseiam para tomar decisões, ou que a ele recorrem para exercer os seus direitos (utilizadores, gestores, cidadãos) – querem cada vez mais estar presentes na conceção e, até, na produção da própria solução.
Hoje em dia, a Engenharia do Software está atrasada em relação às outras engenharias, na utilização de Modelos. Certamente podemos esperar, e há muitos anos, que a construção de um edifício seja precedida de uma planta detalhada do edifício. A Engenharia Civil tem essa prática totalmente instituída, mas a Engenharia do Software não. O Modelo, que equivaleria à Planta, na maior parte das vezes não existe ou está embutido e é difícil de isolar no próprio código do software.
Este atraso não resulta da juventude da engenharia do software que, embora mais recente do que outras engenharias, já existe seguramente desde os anos 60 do século passado. Seis décadas seriam tempo mais do que suficiente para generalizar uma boa prática, se o seu benefício fosse apercebido e reconhecido.
Na realidade, a engenharia do software atrasou-se, nos últimos trinta anos e neste domínio da utilização de modelos, face às suas congéneres.
Uma pequena história, totalmente real, demonstra isso. Nos anos 1980, surgiram, em paralelo, os sistemas CAD (Computer Aided Design), CAM (Computer Aided Manufacturing) e CASE (Computer Aided Software Engineering). Passados 30 anos, todos os alunos de Engenharia Civil (e de Arquitetura) aprendem a utilizar CAD na Universidade; todos os alunos usam CAD, mesmo para projetos fora da disciplina onde o aprenderam; e quando chegam às empresas, continuam a usar CAD em todas as atividades que desenvolvem. Nada disto aconteceu com o CASE. Perguntem a um estudante atual de Engenharia Informática o que significa a sigla CASE e nem isso saberá. O último livro publicado sobre CASE data de 2003.
Inteligência Artificial aplicada ao desenvolvimento de software
O mesmo aconteceu em relação à inteligência artificial aplicada ao desenvolvimento de software. Este era um tema que reunia um número elevado de investigadores nos anos 1980, em torno de motores de inferência, de linguagens específicas como o PROLOG ou o LISP, de sistemas periciais (Expert Systems). Defendiam, por exemplo, o primado da programação declarativa face à procedimental, o que, já na altura, aproximava muito a inteligência artificial e a utilização de modelos.
Há 30 anos, as expetativas em relação à engenharia do software e à inteligência artificial eram muito elevadas. Herbert Simon, Prémio Nobel da Economia, previra, já alguns anos antes, em 1956: “Machines will be capable, within twenty years, of doing any work a man can do”.
Nos anos mais recentes, a inteligência artificial voltou a estar na moda, e há todo um hype em seu torno, o que se traduz em muitos recursos financeiros e muitos jovens talentos dirigidos para este domínio. O que é muito bom. No entanto, o desenvolvimento de software foi afastado dos temas a serem objeto da inteligência artificial. Parece haver até uma espécie de bullying, que afasta os sistemas periciais, reservando a IA para a robótica, para o processamento de linguagem natural e para o machine learning, não se afastando esta última muito do que ainda há poucos anos se chamariam métodos quantitativos ou métodos de previsão.
Participação da Quidgest
A Quidgest foi, desde a sua criação em 1988, pioneira na utilização da inteligência artificial e da modelação.
Curiosamente, por esta ordem. Primeiro, a inteligência artificial com a criação de um sistema pericial para avaliação de investimentos agrícolas, o ALFAIA, desenvolvido em PROLOG. Em 1989, o ALFAIA permitiu dar um salto na produtividade dos técnicos envolvidos, que passaram de avaliar em média 0,6 projetos por dia para conseguir avaliar, em média, 25 projetos por dia. Uma produtividade e uma qualidade fundamentada da decisão que seria invejável, ainda hoje, na análise de concessão de créditos por parte das instituições bancárias. O entusiasmo do pioneirismo de Hélder Coelho foi uma fonte de inspiração para a Quidgest neste desafio.
O bichinho do aumento drástico de produtividade através da utilização de tecnologias da informação já estava definitiva e irremediavelmente instalado na Quidgest. Decididamente, queríamos ter um papel relevante na revolução tecnológica do nosso tempo e na transformação digital da sociedade. Em 1990, seguiu-se a modelação aplicada ao desenvolvimento de software, com o Genio. O primeiro passo foi a identificação de padrões que permitissem definir, sem ambiguidades, qualquer sistema de informação, criando o seu modelo (o equivalente à planta da engenharia civil). O segundo passo foi o de gerar automaticamente o software decorrente desse modelo. Tal como um corredor de maratona, o Genio desenvolve constantemente a sua capacidade, continuando a dar os dois passos, através de avanços, ora no modelo, ora na geração automática correspondente. Os ensinamentos de Ana Lucas e a beleza e simplicidade dos conceitos que nos transmitiu sobre bases de dados, foram fundamentais para iniciarmos esta caminhada, que ainda hoje trilhamos.
ALFAIA e GENIO, os sistemas pioneiros da Quidgest, já eram declarativos (em linha com a MDE) e já usavam motores de inferência (como a inteligência artificial). Ambos já permitiam aumentos extraordinários de produtividade.
Retrocesso da Engenharia de Software
Mas, aos poucos e poucos, na indústria e mesmo na investigação académica, ficámos isolados. Projetos falhados e resultados muito abaixo das expetativas trouxeram uma descrença generalizada em relação à utilização de modelos e de inteligência artificial no desenvolvimento de software. Como é frequente no mundo das tecnologias, a toda a excitação inicial, seguiu-se uma profunda desilusão. Apenas uma meia-dúzia de empresas persistiu nesta linha de trabalho, em todo o mundo. E a Quidgest foi uma delas.
Três fatores contribuíram para este retrocesso da engenharia do software:
- A ausência de uma disciplina de desenvolvimento numa lógica de qualidade total;
- O levantamento de processos como base para a conceção do software;
- O UML. Aos quais se junta, mas não vamos abordar aqui, a inexistente pressão para a indústria do software atual, paga a peso de ouro, ser mais eficiente.
Quanto à disciplina de desenvolvimento. O Caravela, um projeto emblemático do IST no início dos anos 90 permitia (aliás, exigia) que após a geração de código alguém colasse as pontas soltas de modo a garantir que a solução funcionasse. Esta má prática, em total contradição com as boas práticas da qualidade, impedia que os problemas fossem resolvidos na origem e que ficassem corretamente disponíveis para utilizações futuras. Criava aquilo que se designa por “Technological Debt”, a qual, como outras dívidas, só tende a acumular. Note-se, a propósito, que a ignorância da indústria do software tradicional em relação aos conceitos da Qualidade Total continua a ser gritante. Este é, hoje em dia, o único setor de atividade em que o controlo de qualidade (o chamado “Quality Assurance”) está separado da produção. O Caravela recebia mais atenção do que o seu contemporâneo Genio (onde esta indisciplina não é permitida), o que é pena, porque o seu insucesso perdurou mais no imaginário académico do que o sucesso da solução da Quidgest.
Quanto ao predomínio dos processos, em oposição à estrutura de dados, como base para a construção de software. Houve um breve período, com o surgimento dos SGBD relacionais nos anos 1980, em que a estrutura de dados, e não o fluxo dos processos, constituía o primeiro passo para a conceção de software. Obviamente, qualquer software tem, quer dados, quer processos. Mas a ordem pela qual entram na conceção (ou no “Design Thinking”) não é irrelevante. A modelação, nesse período, era data-driven e não process-driven. Os MRP/ERP dos anos 1970 e a generalidade dos projetos de software a partir de meados da década de 1990 iniciaram o seu desenvolvimento pelo levantamento de processos. Mesmo o SCRUM, sendo duvidoso que neste aspeto deva ser considerado Agile, começa por histórias. Ora não existe, no levantamento de processos ou em histórias, nada que se equipare em simplicidade e formalismo matemático ao modelo relacional que suporta a estruturação das bases de dados. Partindo dos processos, o salto para a modelação e para a inteligência artificial é muito mais difícil e muito mais incerto. Adicionalmente, o levantamento de processos, contrariamente ao levantamento de dados, é um trabalho sem fim. Rentável para consultores, mas desesperadamente demorado para quem precisa do software.
Finalmente, o UML (Unified Modelling Language). A associação de modelo a UML pode ser responsável pelo afastamento de muitos estudantes e jovens engenheiros de software em relação ao Model Driven Development (MDD). MDD e UML não são sinónimos, muito pelo contrário. A Quidgest é uma entusiasta defensora do MDD e uma crítica feroz de quase tudo no UML. No UML só são relevantes, embora possam ser simplificados, os modelos que estruturam os dados. Mas a amálgama que resultou na unificação veio dar igualdade de tratamento, veio dar o mesmo estatuto, a um conjunto de outros diagramas que são irrelevantes e só atrapalham. O problema fundamental é que o UML não consegue fazer a ponte entre os requisitos e a solução: aceita tudo o que se coloca no papel, a realidade é demasiado complexa para ser representada, a atualização da documentação não é garantida. Várias formas de suprir estas lacunas fundamentais do UML têm sido ensaiadas pela Academia, mas não seguidas pela Indústria. Esta concluiu que o problema está mesmo no UML e que as suas fraquezas lhe são intrinsecamente inerentes. A modelação necessária para o desenvolvimento de software não pode usar como referência a planta da engenharia civil. Não é apenas um artefacto independente que se consulta durante a construção. Uma das mais significativas inovações do Genio da Quidgest em relação ao UML, é que o Genio nasce na direção oposta, do software para o modelo. E esta é uma mudança de paradigma considerável.
