Extração de Modelos Comportamentais de Programas ... - PUC-Rio

Extração de Modelos Comportamentais de Programas Java
Concorrentes Anotados
Aluno: Elthon Allex da Silva Oliveira 1
Orientadores: Jorge César Abrantes de Figueiredo 1
e Dalton Dario Serey Guerrero 1
1 Grupo de Métodos Formais – GMF
Coordenação de Pós-Graduação em Informática – COPIN
Departamento de Sistemas e Computação – Universidade Federal de Campina Grande
Av. Aprígio Veloso, 882, Caixa Postal: 10.106, CEP: 58.109-970, Campina Grande-PB
{elthon,abrantes,dalton}@dsc.ufcg.edu.br
Nível: Mestrado
Ano de Ingresso: 2004
Previsão de Conclusão: Março de 2006
Aprovação da proposta:17/12/2004
Resumo. Um dos problemas encontrados na aplicação de técnicas de modelchecking,
para a verificação de programas Java multi-thread, é a dificuldade
em produzir e manter os modelos comportamentais. Uma possível solução é
desenvolver técnicas para gerar automaticamente esses modelos a partir do
código. Tais técnicas, contudo, tendem a produzir modelos não suficientemente
abstratos, levando assim ao problema da explosão do espaço de estados, o que
torna estas técnicas impraticáveis devido à quantidade de memória exigida.
Como solução para este problema, neste trabalho é apresentada uma técnica
que faz uso de anotações de código escritas junto ao código Java. Através
destas anotações, são inseridas informações que expressam o comportamento
esperado do código. Tais informações são usadas para gerar modelos formais
mais abstratos de acordo com a necessidade do usuário da técnica.
Palavras-chave: Verificação de software, modelagem formal, linguagem de
anotação de código, Java multi-thread.

1. Caracterização do problema
1.1. Introdução
Com o objetivo de detectar a presença de erros em sistemas de manufatura, protocolos de
comunicação e também sistemas de software, concorrentes ou não, diversas linguagens
de modelagem formal foram criadas. Dentre elas, podemos citar CSP [Hoare 1985], redes
de Petri [Jensen 1997] e Promela [Holzmann 1997]. Entretanto, existem alguns problemas
que dificultam bastante o uso destas linguagens de modelagem de forma vasta no
desenvolvimento de software:
1. Necessidade de um profissional conhecedor da linguagem, o que implica em custos
maiores e torna o uso da técnica inviável em diversos projetos de desenvolvimento.
Haveria também a possibilidade de os próprios programadores se especializarem
em uma das linguagens, mas o tempo gasto por eles na fase de modelagem
seria bastante desmotivador.
2. Hoje em dia, a adoção de processos ágeis, como por exemplo
XP [Jeffries et al. 2000], no desenvolvimento de software tem proporcionado
uma grande velocidade na entrega dos resultados, o que provoca muitas iterações
no ciclo de criação do software. Isto acarreta um processo constante de evolução
do software. Este processo de evolução faz com que haja uma grande dificuldade
de se manter o modelo formal atualizado em relação ao programa modelado.
3. Existência de uma grande lacuna entre o modelo formal do programa e este último,
pois há sempre a dúvida de como garantir que o modelo formal expressa correta e
inteiramente o comportamento esperado pelo programa, e vice-versa.
4. Por último, programas com múltiplas linhas de execução são bastante difíceis de
se acompanhar a execução. Nestes tipos de programas, a detecção de erros exige
muito tempo e muita atenção, pois a intercalação entre as linhas de execução existentes
gera inúmeras seqüências possíveis. Isto gera a necessidade de um suporte
ferramental que de alguma forma, automatize o processo de verificação deste tipo
de programa, pelo menos no que se refere a parte de intercalação.
Com base nos problemas apresentados, pode-se ver que a automação de algumas
etapas do processo de verificação formal, poderia contribuir para a inserção desta última
no processo de desenvolvimento das metodologias ágeis.
1.2. Objetivo
Visto que há uma dificuldade em se usar métodos formais nos processos de desenvolvimento
de software, faz-se necessária a construção de técnicas e ferramentas que possam
“esconder”, do desenvolvedor, o método formal empregado na verificação formal de software.
O objetivo deste trabalho é construir uma ferramenta que seja capaz de fazer
verificação formal em programas Java concorrentes ou não. Além disso, ela possibilitará
ao usuário definir o nível de abstração a ser empregado na verificação de seu programa.
Tal ferramenta não exigirá conhecimento algum sobre métodos formais. Ela exigirá apenas
capacidade, por parte do usuário, de descrever o comportamento de seu próprio código
usando a linguagem de anotação definida neste trabalho. Como um dos propósitos do
trabalho é facilitar o uso de model checking no desenvolvimento de software, a ferramenta
será implementada na forma de um plugin (detalhes sobre o plugin serão omitidos

Figura 1. Espaços de estados gerados a partir de códigos Java e Java anotados.
neste artigo devido a restrições de espaço) do Eclipse [Eclipse Foundation 2005]. O plugin
gerará modelos (abstrações do comportamento do programa) diretamente a partir do
código Java e das anotações feitas neste código.
Com o intuito de prover ao usuário poderes de decisão sobre o nível de abstração
do modelo, é definida uma linguagem de anotação de código, capaz de modelar aspectos
relevantes de Java concorrente. Esta linguagem de anotação servirá como uma linguagem,
semelhante a Java, de descrição comportamental do programa a verificar. Assim,
o usuário poderá determinar o nível de abstração na qual deseje que a verificação
atue. Na Figura 1, pode-se ter uma idéia do efeito causado pela presença das anotações.
O código anotado é desprezado e somente as anotações são consideradas. A verificação
será feita por alguma ferramenta (verificador de modelos) que suporte a linguagem formal
escolhida como linguagem alvo.
2. Fundamentação teórica
Cada vez mais a programação concorrente vêm sendo usada com o propósito de aumentar
o desempenho de alguns programas desenvolvidos. Este tipo de programação faz
uso de múltiplas linhas de execução (multi-thread), ao invés de apenas uma como na
programação seqüencial, num único processo. O uso de múltiplas linhas de execução traz
alguns benefícios:
• Capacidade de resposta: parte da aplicação pode continuar executando enquanto
outra seção está bloqueada ou executando uma operação demorada.
• Compartilhamento de recursos: As linhas de execução de um mesmo processo
tem acesso à memória e aos recursos do processo.
• Economia: É mais demorado e mais dispendioso criar um novo processo do que
uma nova linha de execução.
• Utilização de arquiteturas com múltiplos processadores: em sistemas com um
único processador, apenas um processo (ou mesmo uma linha de execução) pode
ser executado por vez, embora a rápida alternância entre os processos passe a
ilusão de paralelismo. Em um sistema multiprocessado, as linhas de execução,
inclusive de um mesmo processo, podem ser executados simultaneamente em diversos
processadores.
Para uma explicação mais detalhada sobre múltiplas linhas de execução, consultar
[Tanenbaum 2001].

A linguagem de programação Java possui um bom suporte para programação concorrente.
Há duas formas de se usar várias linhas de execução num mesmo processo: por
meio de herança, estendendo a classe Thread; ou implementando a interface Runnable,
onde faz-se necessário implementar o método run(). Para uma explicação mais detalhada,
ver o capítulo referente a programação concorrente com múltiplas linhas de execução do
livro [Eckel 2003].
Verificação de modelos Esta é uma técnica automática para analisar o espaço de estados
finito de sistemas concorrentes [Clarke et al. 1996]. Tradicionalmente, a aplicação da
verificação de modelos ocorre através de três etapas: modelagem (construção de um modelo
formal do sistema que contenha o comportamento do sistema), especificação dos comportamentos
desejáveis(descrito formalmente através de lógicas temporais ou máquinas
de estado), e verificação (modelo e especificações são submetidas ao verificador de modelos).
Na última etapa é obtida uma resposta do verificador: verdadeiro (as especificações
são satisfeitas pelo modelo) ou falso mais contra-exemplo (um trace com os passos que
levam a um estado onde as especificações não são verdadeiras).
Como mencionado na Seção 1, o modelo é descrito através de uma linguagem formal
e, a partir daí, é gerado automaticamente o espaço de estados com todos os estados
possíveis. O principal desafio à aplicação de verificação de modelos em programas é o
problema conhecido como explosão do espaço de estados. Em [McMillan 1993] é apresentada
uma técnica para redução do espaço de estados. As propriedades a serem verificadas
são escritas de forma manual utilizando, geralmente, alguma lógica temporal: LTL
(Linear Temporal Logic) [Pnueli 1977] e CTL (Computation Tree Logic) [Sifakis 1989].
Anotação de código Como forma de inserir informações extra no código dos programas,
alguns trabalhos fazem uso de anotações junto ao código. Geralmente estas
anotações se encontram na forma de comentários com algum caracter (e.g. @) que as
preceda, indicando que são anotações. Um exemplo de anotação sem abstração alguma,
no contexto deste trabalho, para o código if(condição) x++; seria @choice{ condição: {
x = x+1; } .
As anotações podem ter funcionalidades variadas: servir apenas como
documentação (e.g. Javadoc), definir restrições (e.g. [Holmgren 2005]), propriedades
a serem verificadas (e.g. [Robby 2000]) e também podem servir como modelo do programa,
como é o caso da linguagem definida neste trabalho.
3. Caracterização da contribuição
Este trabalho irá aproximar ainda mais o uso da verificação formal, no desenvolvimento de
projetos, e os desenvolvedores, pois a extração de modelos aqui apresentada será feita de
forma automática pela ferramenta a ser implementada na forma de plugin para o Eclipse.
Acredita-se que sendo integrada a um ambiente de desenvolvimento já consolidado e
difundido, a ferramenta terá mais chances de ser bem recebida pelo público alvo.
Além disso, como a modelagem estará na forma de anotações semelhantes a
código Java, acredita-se também que a tradicional lacuna existente entre o modelo formal
e o programa modelado seja amenizada, diminuindo assim o risco de inserção de
características inexistentes ou omissão de características relevantes.

4. Estado atual do trabalho
Algumas etapas definidas no início do trabalho já foram concluídas. O trabalho foi inicialmente
dividido em quatro etapas. A primeira, já concluída, constituiu-se de uma revisão
bibliográfica para obtenção do embasamento teórico necessário: linguagens de anotação
e verificadores existentes.
A segunda etapa tratou da construção de um protótipo do plugin do Eclipse, capaz
de modelar as seqüências de troca mensagens entre objetos de uma única linha de
execução, este protótipo não lida com programas concorrentes. A ferramenta traduz apenas
as anotações para a linguagem Promela e usa o Spin [Holzmann 1997] como verificador
de modelos.
Na terceira etapa foi feito um estudo sobre as características e propriedades da
programação Java concorrente escrevendo alguns programas simples. Desta forma, a linguagem
de anotação, definida também nesta etapa, pôde contemplar a maioria das características.
Um estudo comparativo entre linguagens de modelagem formais foi concluído.
O propósito deste estudo foi detectar qual linguagem estaria mais apta a modelar programas
Java concorrentes e qual possuia suporte ferramental mais apropriado, dentro do
escopo deste trabalho.
Ainda na terceira etapa, serão definidas estratégias e/ou algoritmos para geração
automática de modelos a partir do código e anotações. Um exemplo prático foi omitido
neste artigo devido a restrições de espaço. O código do protótipo do plugin será refatorado
para que suporte a nova linguagem de anotação definida, o algoritmo de extração e a nova
linguagem alvo.
E por fim, na quarta e última etapa, será realizada a validação da ferramenta e
técnica propostas através de um estudo de caso e de uma comparação entre os espaços
de estados gerados a partir dos modelos feitos neste trabalho e feitos em outros trabalhos
existentes. Além disso, o novo plugin será implementado.
5. Trabalhos relacionados (visão comparativa)
Alguns trabalhos correlatos foram encontrados, uma boa parte deles ainda está em andamento.
Um dos primeiros trabalhos a ser feito foi [Luckham and Henke 1984], uma
extensão da linguagem ADA chamada ANNA (ANNotated Ada). Neste trabalho, as extensões
apenas modelavam as propriedades e o modelo era extraído diretamente do código
fonte.
Em [Jungclaus et al. 1991] é apresentada a linguagem TROLL. Ela é utilizada
na modelagem formal de sistemas de informação (reativos) OO. Duas desvantagens deste
trabalho são: a ausência de modelagem de comunicação assíncrona; e a sua aplicação deve
ser feita na fase inicial do projeto, o que inviabiliza sua utilização dentro das metodologias
ágeis, pois nelas há uma constante evolução por parte do sistema.
No trabalho descrito em [Limited 2004], há uma linguagem chamada Perfect Language
que é usada na ferramenta Perfect Developer. Perfect Language é semelhante a uma
linguagem de programação. Ela descreve o modelo e os requisitos do usuário. Uma vantagem
é que boa parte do código do programa pode ser gerado a partir das especificações,
contudo não suporta programas com várias linhas de execução.

E em [Robby 2000], é apresentada uma linguagem de especificação de constraints
que serve para especificar propriedades em programas Java, como asserções e predicados.
Esta linguagem faz parte do projeto Bandera que gera modelos comportamentais a partir
do próprio código Java. Há um plugin para o Eclipse implementado. Contudo, o usuário
não consegue definir o nível de abstração na geração do modelo comportamental, o que é
feito no trabalho aqui apresentado.
6. Validação dos resultados
Espera-se validar este trabalho com uma comparação entre os modelos obtidos a partir
de nossa tradução e os modelos obtidos a partir das traduções existentes; e um estudo de
caso que contemple características de concorrência relevantes, como deadlocks, livelocks,
race conditions, etc. Além disso, um plugin, que implemente a técnica aqui apresentada,
também será desenvolvido.
Referências
Clarke et al., E. M. (1996). Formal methods: State of the art and future directions. ACM
Computing Surveys, 28(4):626–643.
Eckel, B. (2003). Thinking in Java. Prentice Hall International, Inc., Upper Saddle River,
New Jersey, USA, 3rd edition.
Eclipse Foundation (2005). Eclipse.org Main Page. http://www.eclipse.org.
Hoare, C. (1985). Communicating Sequential Processes. Prentice-Hall International Series
in Computer Science.
Holmgren, A. (2005). Using Annotations to add Validity Constraints to JavaBeans Properties.
http://java.sun.com/developer/technicalArticles/J2SE/constraints/annotations.html.
Holzmann, G. (1997). The Model Checker SPIN. IEEE Transactions on Software Engineering,
23(5).
Jeffries, R., Anderson, A., and Hendrickson, C. (2000). Extreme Programming Installed.
Addison Wesley, Boston, MA, USA.
Jensen, K. (1997). Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical
Use, volume 2. Springer-Verlag.
Jungclaus, R., Saake, G., Hartmann, T., and Sernadas, C. (1991). Object-Oriented Specification
of Information Systems: The TROLL Language. Technical Report 91-04.
Limited, E. T. (2004). Perfect language. http://www.eschertech.com/product documentation/.
Luckham, D. and Henke, F. W. (1984). An overview of ANNA - a specification language
for ADA. Technical report, Stanford University.
McMillan, K. L. (1993). Symbolic Model Checking: An Approach to the State Explosion
Problem. Kluwer Academic Publishers.
Pnueli, A. (1977). The temporal logic of programs. In 18th IEEE Symposium on Foundations
of Computer Science, pages 46–57.
Robby (2000). Bandera specification language: A specification language for software
model checking. Master’s thesis, Kansas State University.
Sifakis, J., editor (1989). Proceedings of the 1989 International Workshop on Automatic
Verification Methods for Finite State Systems (CAV ’89), number 407 in lncs, Grenoble,
France. Springer.
Tanenbaum, A. S. (2001). Modern Operating Systems. Prentice-Hall, New Jersey, London,
Sydney, 2 edition. http://www.prentice-hall.com.