Alloy no Escopo do Trabalho

Alloy não será utilizada como base formal para o trabalho aqui proposto. Utiliza-se Alloy ape- nas como ferramenta para possibilitar a especificação e verificação de propriedades desejadas no sistema para analisar se um dado cenário de evolução irá impactar a corretude do sistema.

Durante o desenvolvimento da aplicação, o desenvolvedor deve definir um modelo Alloy para o sistema e um conjunto de propriedades que devem ser verificadas. Evidentemente, apenas as partes críticas do sistema devem ser modeladas, visando uma maior eficiência no processo.

Ao adicionar um componente, pode-se então verificar se o modelo do componente, mesclado ao modelo da aplicação, mantém a corretude das propriedades iniciais. Este processo é automati- zado através da utilização do Alloy Analyzer, que verifica a corretude das propriedades de acordo com todos os modelos, mesclados em um modelo único. Por fim, o resultado da análise é retor- nado ao desenvolvedor, indicando que as propriedades foram verificadas ou os cenários em que as propriedades não foram verificadas (contra-exemplos).

A motivação para a utilização de Alloy é definida em dois níveis, conceitual e de ferramenta, com foco na inserção da especificação e verificação formal no processo de desenvolvimento de software. Conceitualmente, o fato da linguagem ter características similares à abordagem orien- tada a objetos permite uma maior familiaridade de desenvolvedores de software com seu para- digma. Outros trabalhos [114, 115, 116] foram desenvolvidos utilizando Redes de Petri Colo- ridas [117] como formalismo. Porém, não foi encontrada uma maneira eficaz de inserir a mo- delagem e a verificação do software no processo de desenvolvimento. Neste caso, a mudança de paradigma e de ambiente de desenvolvimento dificultam a utilização do método formal no processo de construção de software.

No nível de ferramenta, o Alloy Analyzer é leve, de fácil extensão e de código aberto. Sendo assim, é possível realizar alterações que facilitem a integração deste com ferramentas de desen- volvimento de software, escondendo a complexidade do processo de verificação do desenvolvedor e, potencialmente, aumentando a produtividade. Além disso, a descrição da especificação de um sistema é textual, facilitando a manipulação da especificação e das propriedades a serem verifica-

das.

Neste contexto de ferramentas, em [118] foi desenvolvido um plug-in para a plataforma Eclipse para anotação e verificação de propriedades em código Java. Para isso, utilizou-se a linguagem Promela [119] e o verificador de modelos Spin [120], integrado ao plug-in do Eclipse. Neste caso, ocorreu o mesmo problema de mudança de paradigma na linguagem, dificultando o trabalho do desenvolvedor. Com a utilização de uma linguagem orientada a objetos como base para a especificação formal e a integração do Alloy Analyzer às ferramentas de desenvolvimento, espera-se inserir o passo de verificação formal ao processo sem trazer perdas significativas à pro- dutividade do desenvolvedor.

Capítulo 3

Trabalhos Relacionados

Neste capítulo são apresentadas as abordagens correlatas à infra-estrutura proposta neste trabalho, agrupadas de acordo com o tipo de arquitetura e paradigma utilizados. A seguir, são apresentados os tópicos de comparação entre as abordagens. Tem-se, então, uma breve descrição das principais características de cada abordagem e da sua adequação aos requisitos definidos como tópicos de comparação. Por fim, os resultados da comparação são descritos em um quadro comparativo e discutidos em relação à infra-estrutura proposta neste trabalho.

3.1

Tópicos de Comparação

A seguir são apresentados os tópicos de comparação dos trabalhos relacionados, os quais se ba- seiam na motivação para uma infra-estrutura de suporte à EDSNA descrita no capítulo de intro- dução deste documento.

1. Suporte à evolução dinâmica não antecipada - Qual o suporte da abordagem à evolução não antecipada de software? Quais cenários de evolução não antecipada são contemplados (inserção, mudança e remoção de módulos, redefinição arquitetural, etc)? Qual o nível de transparência do processo para o desenvolvedor, ou seja, em que nível o desenvolvedor deve apontar ou não os possíveis pontos de extensão? Qualquer parte da aplicação desenvolvida pode ser evoluída ou apenas determinados módulos? A evolução pode ocorrer dinamica- mente? Há suporte ao versionamento de módulos para garantir uma evolução gradativa, ou seja, há suporte à manutenção e co-existência de módulos de mesma funcionalidade?

2. Suporte à composição de aplicações - Existe um modelo ou técnica para disciplinar a organização dos módulos e composição da aplicação? Existe encapsulamento das funcio- nalidades em módulos coesos e fracamente acoplados para facilitar o processo de evolução da aplicação ou a evolução deve ser gerenciada no nível de linguagem/código? Há suporte à composição recursiva, ou seja, é possível compor novas aplicações com base em aplicações existentes?

3. Especificação formal do modelo/técnica de desenvolvimento - Há uma descrição formal, não ambígua, do modelo ou técnica de desenvolvimento?

4. Suporte para aplicações corporativas - Há suporte ao desenvolvimento de aplicações cor- porativas? Se sim, quais características são contempladas (transação, web, segurança, per- sistência, distribuição, etc)?

5. Processo de desenvolvimento - Há um processo/método para guiar o desenvolvedor na uti- lização da abordagem? A gerência de evolução dinâmica não antecipada é transparente em relação à aplicação do processo ou é explicitamente definida como uma fase a ser executada pelo desenvolvedor?

6. Suporte à verificação formal no processo de evolução - Há suporte à verificação for- mal para identificar possíveis impactos da evolução sobre a corretude da especificação do sistema? Esse suporte está vinculado ao processo de desenvolvimento?

7. Ferramentas de auxílio ao desenvolvimento e à execução - Existem arcabouços, ferra- mentas ou ambientes para permitir o desenvolvimento de software utilizando a abordagem proposta ou apenas uma descrição arquitetural/conceitual da mesma? Há ferramentas de suporte à verificação formal, composição da aplicação, disponibilização de módulos/com- ponentes, etc? Existem ferramentas de apoio à execução de aplicações utilizando a aborda- gem proposta, ou seja, é possível desenvolver novas aplicações e disponibilizá-las em uma infra-estrutura de execução ou servidor de aplicação?

8. Independência de linguagem e plataforma - A abordagem é dependente de linguagem ou plataforma específica, ou seja, depende dos mecanismos e características de uma linguagem de programação ou de uma plataforma de hardware ou sistema operacional?

É importante observar que, na comparação realizada, não foram considerados apenas os traba- lhos correlatos que preenchem todos os requisitos descritos acima. Da mesma forma, não foram apenas consideradas as abordagens baseadas em componentes. Todos os trabalhos encontrados na literatura relacionados ao desenvolvimento de aplicações com algum tipo de suporte à compo- sição e à evolução de aplicações foram considerados. Esta foi a melhor forma encontrada para estabelecer um estado da arte na área na qual se insere o trabalho descrito neste documento.