Ambiente de engenharia de software

O Ambiente de Engenharia de Software - AES - (SEE - do inglês Software Engineering Environment) pode ser entendido como um conjunto de ferramentas criadas para auxiliar a criação e desenvolvimento de um processo de software. De uma forma geral, pode ser aplicado a processos de tamanho variado, desde pequenos e simples, até aqueles que gerenciam todos os dados, desde custos, alocação de recursos, desenvolvimento, chegando até a fase de testes. A criação de um AES visa dar suporte às atividades humanas, deixando os participantes cientes da capacidade do ambiente, ou seja, de tudo que este ambiente provê para facilitar a execução das tarefas. O AES também possibilita a correspondência entre os processos que constituem o desenvolvimento de um software, mantendo uma localização quanto a sequência das etapas deste.

Ambientes de Engenharia de Software Centrados no Processo

Os Ambientes de Engenharia de Software Centrados no Processo, (PSEE - do inglês Process-centred Software Engineering Environment) são um tipo de Ambientes de Engenharia de Software que nos últimos anos surgiu para apoiar a definição rigorosa de processos de software, automatizando a gerência do desenvolvimento. Entre os serviços fornecidos podemos citar: análise, simulação, execução e reutilização das definições de processos, que cooperam no aperfeiçoamento contínuo de processos. Enquanto os programas de computador são escritos para definir o comportamento de uma máquina determinística, os programas de processo são escritos para definir possíveis padrões de comportamento entre elementos não-determinísticos (atores) e ferramentas automatizadas. Assim, um Ambiente de Engenharia de Software Centrado no Processo deve permitir que os atores envolvidos no processo recebam orientação e assistência nas suas atividades. E ainda, os processos podem ser alterados dinamicamente a partir de mudanças organizacionais ou nos requisitos do software. Podemos enumerar três tipos principais de modelos:

• Modelos Abstratos: modelo de alto nível que é projetado para regular a funcionalidade e interações entre os papéis de desenvolvedores, gerentes, usuários e ferramentas em um PSEE.
• Modelos Instanciados: instância de um modelo abstrato, com objetivos e restrições específicos, envolvendo agentes, prazos, orçamentos, recursos e um processo de desenvolvimento;
• Modelos Executados: modelo que registra o passado histórico da execução de um processo, incluindo os eventos e modificações realizadas no modelo associado.

Técnicas de Inteligência Artificial aplicadas a AES

Inteligência Artificial - IA - é uma ciência que abrange um grande número de subcampos, indo desde áreas de uso comum (como aprendizado e percepção) até fins mais específicos (como jogos de xadrez). Como a IA automatiza tarefas intelectuais ela tem uma grande utilidade para atividades intelectuais humanas, que utilizará técnicas de IA no processo de desenvolvimento de software com PSEE's.

Sistemas Especialistas

Sistemas Especialistas (SE’s) são uma classe de software que colabora com a tomada de decisões em áreas que dependem de especialistas humanos. Basicamente um SE utiliza o conhecimento de um ou mais especialistas e usa a soma destes conhecimentos para auxiliar na tomada de decisão de um usuário. Um SE é um Sistema Baseado em Conhecimento (SBC), que atua em áreas e tarefas bem claras. Em sua estrutura cada SE é dividido em duas partes principais:

- a Base de Conhecimento (BC), que contém o conhecimento heurístico e atual sobre o domínio de aplicação do SE e

- a Máquina de Inferência (MI), que usa o conhecimento da BC para construir a linha de raciocínio que leva à solução do problema.

O conhecimento de especialistas pode ser representado através de lógica, regras de produção, redes semânticas, frames e raciocínio baseado em casos. É possível combinar duas abordagens diferentes (como por exemplo regras de produção e redes semânticas) para representar o conhecimento de um sistema.

Sistemas Baseados em Regras

Para representar conhecimento em IA um dos mais populares paradigmas utilizado é o paradigma de regras. Basicamente uma regra possui uma parte condicional à esquerda (se.) e uma executora (ou conclusiva) à direita (então.). A parte condicional define as condições combinada de maneira lógica e a parte à direita representa as ações ou conclusões deduzidas quando todas as condições forem satisfeitas. Podemos representar esta definição como:

   SE COND1,COND2,. CONDn ENTÃO
        CONCL1,., CONCLn

OU

   SE COND1,COND2,. CONDn ENTÃO
        AÇÃO1,., AÇÃOn

O conjunto de predicados é chamado de Memória de Trabalho (MT). A parte à direita determina novos predicados para a MT. Quando esta parte à direita contém apenas predicados o sistema é chamado Dedutivo, já quando a parte à direita especifica ações o sistema é chamado Reativo.

Sistemas Fuzzy

Sistemas Fuzzy combinam a flexibilidade e representação de conhecimento de alto nível dos SE's convencionais com a habilidade de tratar problemas complexos e não lineares com o mínimo de regras. O principal benefício do Sistema Fuzzy é a redução dos custos de desenvolvimento, execução e manutenção. No entanto eles não são aplicados a todos os tipos de sistemas. A lógica Fuzzy trata valores que variam de forma contínua de 0 a 1 (diferente da lógica Booleana que trata somente dois valores: ou 0 ou 1). Assim, um fato pode ser quase verdadeiro (0,9), quase falso (0,1) ou "meio verdade" (0,5). A utilização de lógica fuzzy permite expressarmos conhecimento em forma de regra, o que é relativamente parecido com a linguagem natural.

Raciocínio Baseado em Casos

Raciocínio baseado em casos (CBR - do inglês Case-Based Reasoning) é uma técnica que se utiliza da experiência adquirida para a resolução de problemas. Neste sistema a ideia é descrever e acumular casos significativos para a área de conhecimento especializado e buscar descobrir, por meio de analogia, quando um problema é parecido com um problema já resolvido anteriormente e tentar utilizar a solução utilizada neste novo problema. Uma experiência é a representação de um caso, que representa um pedaço de conhecimento. Contém o contexto onde a solução pode ser aplicada e qual foi a solução. Um caso pode ser a descrição de um evento, uma história ou algum registro contendo tipicamente o problema no momento em que o caso ocorreu mais a solução para esse problema. A descrição de um novo problema a ser resolvido é posicionada no espaço do problema. O caso com a descrição mais similar é recuperado e sua solução é encontrada. Se necessário, pode ser feita uma adaptação e uma nova solução pode ser criada.

Agentes

Agente é tudo o que podemos considerar como capaz de perceber seu ambiente (através de sensores) e de agir sobre esse ambiente (através de atuadores). Considerando um sistema, chamamos agente cada uma de suas entidades ativas. Sociedade é o conjunto de agentes. O agende raciocina considerando seu ambiente, os outros agentes e partir disto decide o que deve fazer (ações a serem tomadas, objetivos a serem alcançados).

Aprendizado

A parte principal do comportamento inteligente é a habilidade de se adaptar ou aprender a partir de experiências. Podemos citar algumas técnicas como:

• por indução: através de um conjunto dados específicos ou exemplos, o sistema procura inferir conceitos e leis gerais;
• por redes neurais: elas podem ser usadas em aprendizado supervisionado ou não supervisionado. Em uma rede de neurônios artificiais existem somadores, multiplicadores e limites. As entradas possuem pesos que são ajustados no processo de aprendizagem;
• por casos: dados alguns casos de referência, para descobrir uma propriedade de uma situação ou dado específico, são encontrados os casos mais similares de acordo com as propriedades conhecidas;
• por implantação direta do conhecimento: incluindo-se novas regras diretamente na BC.

Formas de Aplicação

Modelagem e Reutilização

Através de regras fuzzy, situações do tipo "se nível de qualidade da tarefa anterior é alto, então faça operação 1". Neste caso, o nível de qualidade depende de uma avaliação que não é precisa, mas que é importante para o desenvolvimento do processo. Para a recuperação de processos de software adequados à situação que se quer modelar, podem ser usados sistemas CBR.

Execução

Na fase de execução, o componente principal é a máquina de processo. Este componente centraliza o controle do desenvolvimento de software e é responsável por inúmeras tarefas: verificar consistência, direitos de acesso, próximas atividades a serem executadas, agendas dos usuários, etc. Para distribuir essas tarefas podemos utilizar agentes. Um agente poderia cuidar das agendas dos usuários, outro das atividades e seus estados e assim por diante. Como os agentes têm a capacidade de aprendizado, eles poderiam atuar de maneira específica ao ambiente e seus usuários. Eles poderiam observar o ambiente e complementar sua base de métricas com informações relativas à execução dos processos. A máquina de execução poderia observar a execução das atividades, percebendo o atraso em determinada atividade ela poderia determinar o que causou este atraso e definir o desenvolvedor como "lento", utilizando uma regra fuzzy pode-se verificar se determinada atividade está atrasada e seu desenvolvedor é "lento" e assim passar a atividade para outro desenvolvedor. Também é possível utilizar CBR pois considerando uma parada na execução o sistema poderia verificar um caso similar e solucionar o problema com uma solução já utilizada.

Simulação

Através da simulação de processos de software é possível detectar falhas, inconsistências e comportamentos anormais na descrição do processo. O usuário pode prever o progresso do desenvolvimento e comparar modelos. A simulação de processos também pode usar lógica fuzzy como foi proposta na execução. Para que a simulação atinja seus objetivos é necessário que ela seja baseada em situações reais. Portanto um sistema CBR poderia ser utilizado para prover conhecimento real sobre situações de execução de processo e como são resolvidas essas situações.

Interface

A interface com o usuário de um AES depende do papel que ele executa no desenvolvimento.

Um gerente precisa ver resultados quantitativos e qualitativos do trabalho dos desenvolvedores. As suas ações visam ajustar o processo para que não atrase e atinja os objetivos, sendo que para isso ele necessita interagir com os desenvolvedores.

Um desenvolvedor precisa ver as tarefas a serem desenvolvidas e os objetos a serem manipulados. Precisa também priorizar e delegar tarefas quando possível.

Os agentes de interface poderiam auxiliar esses usuários. Da mesma forma que um agente pode adquirir competência no tratamento das mensagens de seus usuários, ele pode adquirir competência no tratamento das tarefas que o desenvolvedor deve executar e tornar-se seu assistente pessoal de processo. O agente pode auxiliar um usuário novato indicando as tarefas mais importantes e fornecendo todas as informações necessárias para o desenvolvimento das mesmas. Por outro lado, com um usuário mais experiente, o agente pode deduzir que o mesmo não necessita de tantas informações para realizar seu trabalho e apresentar somente as informações necessárias. Adquirindo competência, o agente pode automaticamente delegar tarefas para outros desenvolvedores, marcar reuniões e trocar informações com outros agentes para solucionar os problemas que surgirem. Um desenvolvedor experiente não fica satisfeito com um sistema que o obriga a seguir passos programados e informa a todo instante como fazer seu trabalho. Um agente de interface pode identificar isso e filtrar as informações de acordo com o nível do usuário facilitando assim o aumento da produtividade no desenvolvimento de software.

PSEEs que utilizam IA

A seguir são descritos brevemente alguns Ambientes de Engenharia de Software que utilizam técnicas de Inteligência Artificial.

Marvel

Marvel é um PSEE resultante de um projeto de mesmo nome na Columbia University desde 1986. Sua ideia era desenvolver um PSEE que orientasse e assistisse os usuários que trabalham em projetos de grande escala. Para isso, reuniram-se as áreas de Engenharia de Software e Inteligência Artificial. Marvel segue o paradigma de orientação a objetos e é baseado em uma linguagem de regras. O processo sendo modelado é decomposto em passos de processo. Cada passo é encapsulado em uma ou mais regras.

Merlin

Merlin é um PSEE construído dentro de um projeto na University of Dortmund. O protótipo do ambiente usa o paradigma de regras para descrever e executar processos de software. Uma definição de processo no Merlin possui atividades, papéis, documentos e recursos. Um documento é ligado a um conjunto de atividades e a um conjunto de ferramentas que suportam as atividades. Nesta abordagem os usuários recebem todas as informações relevantes em um espaço de trabalho chamado working context associado ao papel do usuário. Este espaço de trabalho contém os documentos a serem manipulados, suas dependências com outros documentos e as atividades que devem ser realizadas. Quando uma atividade realizada influencia um working context, acontece uma atualização dinâmica nos working contexts dependentes deste evento. A máquina de execução do Merlin constrói e atualiza os working contexts dos usuários. Cada atividade possui pré-condições que definem, por exemplo, os papéis que podem desempenhar a atividade, a pessoa responsável, os direitos de acesso aos documentos ou a dependência com outras atividades. Quando as precondições de uma atividade são verdadeiras, a atividade é inserida no working context. Merlin suporta mudanças dinâmicas no processo, permitindo que um processo não seja totalmente definido antes de iniciar. A linguagem escolhida para o ambiente é baseada em Prolog.

Articulator

Articulator é um ambiente baseado em conhecimento para processo de desenvolvimento de software. Ele provê um meta-modelo de processo de desenvolvimento de software, uma linguagem baseada em objetos e um mecanismo de simulação automática. Para simular a execução de processos, o Articulator usa uma abordagem multiagentes onde os desenvolvedores são modelados como agentes cognitivos. A arquitetura do ambiente contém cinco subsistemas:

• base de conhecimento,
• simulador de comportamento,
• mecanismo de consulta,
• gerenciador de instanciação
• gerenciador de aquisição de conhecimento.

O meta-modelo do Articulator consiste de recursos, agentes e tarefas. Os recursos são objetos nas tarefas dos agentes. As tarefas consomem e produzem recursos. Um agente representa uma coleção de comportamentos e atributos associados. O comportamento do agente emerge durante a execução das tarefas (incluindo comunicação, acomodação e negociação) levando em consideração a situação do agente. Os agentes são modelos gerais de desenvolvedores, times de desenvolvimento e organizações. Ferramentas de desenvolvimento são modeladas somo subclasse de agentes. As tarefas são representadas através de uma rede de ações que os agentes realizam. Como não existe execução real de processos neste ambiente, os agentes são agentes cognitivos que simulam execução de tarefas e várias situações para auxiliar a geração da descrição do processo. A simulação é importante para detectar falhas como alocação de recursos, cronograma, dentre outras.

Pandora

Pandora é uma máquina de processos baseada em programação em lógica e conceitos de lógica temporal. Todos os eventos são registrados e o sistema possui um algoritmo de aplicação de regras que otimiza os passos de execução. Além disso, o sistema possui um mecanismo de sincronização que garante que as atividades cooperativas ou que devem ser executadas em alguma ordem serão sincronizadas. Pandora integra os paradigmas de eventos para modelar interatividade entre mensagens e de regras para representar o conhecimento do processo. O conhecimento pode ser declarativo ou procedural. Conhecimento declarativo descreve o domínio do discurso, no caso, o modelo de processo enquanto conhecimento procedural descreve o comportamento que o processo pode assumir durante o desenvolvimento, ou seja, as regras e eventos que disparam evolução de processo. O sistema reage aos eventos externos e dispara as ações internas. As regras e eventos são especificados em uma linguagem de lógica de primeira ordem acrescida de operadores de lógica temporal (Linguagem Pandora) onde o tempo é caracterizado por uma linha sequencial simples de eventos. Isto permite expressar quantitativamente o tamanho dos intervalos temporais, a distância temporal entre os eventos e a viabilidade das atividades modeladas quanto às proposições lógicas estabelecidas. É possível estabelecer não apenas quais atividades são permitidas a cada momento, mas também como as atividades interagem (ou seja, sincronização entre atividades paralelas e disparo de atividades engatilhadas). Pandora é implementada em Prolog e consiste de dois módulos principais:

• compilador de regras e
• interpretador de regras.

O compilador checa as regras quanto a sintaxe e as transforma em uma representação interna. O interpretador permite ativação das ferramentas do sistema operacional, permite rastreamento da aplicação de regras e observação dos estados internos.

Referências

• SANTOS, Gleison; ROCHA, Ana Regina; TRAVASSOS, Guilherme Horta. Ambientes de Engenharia de Software Orientados a Corporação. Universidade Federal do Rio de Janeiro. 2004.
• SILVA, Renato Afonso Costa. Inteligência Artificial aplicada a Ambientes de Engenharia de Software. Universidade Federal de Viçosa. 2005.
• SILVA, Fabio Augusto das Dores. Modelo de Simulação de Processos de Software baseado em Conhecimento. Universidade Federal do Rio Grande do Sul. 2001.

Ligações externas

• Marvel^{[ligação inativa]} Ambiente Centrado em Processo desenvolvido na Columbia University.
• Merlin^{[ligação inativa]} Ambiente Centrado em Processo desenvolvido na University of Dortmund.
• Articulator Ambiente Baseado em Conhecimento.
• Pandora Máquina de Processos Baseada em Programação Lógica.