Dissertacao Setembro

Ambiente integrado para vericao e teste
da coordenao de componentes
tolerantes a falhas
Simone Hanazumi
Dissertao apresentada
ao
Instituto de Matemtica e Estatstica
da
Universidade de So Paulo
para
obteno do ttulo
de
Mestre em Cincias
Programa: Cincia da Computao
Orientadora: Profa. Dra. Ana Cristina Vieira de Melo
Durante o desenvolvimento deste trabalho a autora recebeu auxlio nanceiro da FAPESP
Processo: 2008/03235-0
So Paulo, setembro de 2010
Ambiente integrado para vericao e teste
da coordenao de componentes
tolerantes a falhas
Esta verso denitiva da dissertao
contm as correes e alteraes sugeridas pela
Comisso Julgadora durante a defesa realizada
por Simone Hanazumi em 01/09/2010.
Comisso Julgadora:
Profa. Dra. Ana Cristina Vieira de Melo (orientadora) - IME-USP
Prof. Dr. Flvio Soares Corra da Silva - IME-USP
Prof. Dr. Mario Jino - FEEC-UNICAMP
Agradecimentos
A Deus, por ter me dado foras para concretizar a realizao deste trabalho.
Ao Instituto de Matemtica e Estatstica da Universidade de So Paulo e seus pro-
fessores, por prover o ambiente para o desenvolvimento deste trabalho e o conhecimento necessrio
para sua realizao.
Fundao de Amparo Pesquisa do Estado de So Paulo (FAPESP), pelo nanci-
amento da pesquisa por meio de bolsa
1
.
Profa. Dra. Ana Cristina Vieira de Melo, pela sua pacincia, amizade, conana e,
sobretudo, pelas valiosas orientaes feitas para o andamento e concluso deste trabalho.
Aos meus pais e minha irm, pelo apoio e pela conana no sucesso deste trabalho, em todas
as horas.
Aos meus amigos e colegas, em especial a David Paulo Pereira, Kleber da Silva Xavier
e Paulo Roberto A. F. Nunes, por suas colaboraes, crticas e sugestes que auxiliaram no
desenvolvimento deste trabalho.
A todos aqueles que me apoiaram e acreditaram no meu sucesso.
Muito obrigada.
1
Processo: 2008/03235-0
i
ii
Resumo
Hoje, diante das contnuas mudanas e do mercado competitivo, as empresas e organizaes tm
sempre a necessidade de adaptar suas prticas de negcios para atender s diferentes exigncias de
seus clientes e manter-se em vantagem com relao s suas concorrentes. Para ajud-las a atingir
esta meta, uma proposta promissora o Desenvolvimento Baseado em Componentes (DBC), cuja
ideia bsica a de que um novo software possa ser construdo rapidamente a partir de componentes
pr-existentes. Entretanto, a montagem de sistemas corporativos mais conveis e tolerantes a falhas
a partir da integrao de componentes tem-se mostrado uma tarefa relativamente complexa. E a
necessidade de garantir que tal integrao no falhe tornou-se algo imprescindvel, sobretudo porque
as consequncias de uma falha podem ser extremamente graves.
Para que haja uma certa garantia de que o software seja tolerante a falhas, devem ser realizadas
atividades de testes e vericao formal de programas. Isto porque ambas, em conjunto, procuram
garantir ao desenvolvedor que o sistema resultante da integrao , de fato, convel. Mas a viabi-
lidade prtica de execuo destas atividades depende de ferramentas que auxiliem sua realizao,
uma vez que a execuo de ambas constitui um alto custo para o desenvolvimento do software.
Tendo em vista esta necessidade de facilitar a realizao de testes e vericao nos sistemas
baseados em componentes (DBC), este trabalho de Mestrado se prope a desenvolver um ambiente
integrado para a vericao e teste de protocolos para a coordenao do comportamento excepcional
de componentes.
Palavras-chave: Testes, Vericao Formal, Coordenao de Componentes.
iii
iv
Abstract
Nowadays, because of continuous changes and the competitive market, companies and organiza-
tions have the necessity to adapt their business practices in order to satisfy the dierent requirements
of their customers and then, keep themselves in advantage among their competitors. To help them
to reach this aim, a promising purpose is the Component-Based Development (CBD), whose ba-
sic idea is that a new software can be built in a fast way from preexisting components. However,
mounting more reliable and fault-tolerant corporative systems from components integration is a re-
latively complex task. And the need to assure that such integration does not fail becomes something
essential, especially because the consequences of a failure can be extremely serious.
To have a certain guarantee that the software will be fault-tolerant, testing activities and formal
verication of programs should be done. This is because both, together, try to assure to developer
that the resulting system of the integration is, in fact, reliable. But the practical feasibility of
executing these activities depends on tools which support it, once both executions have a high cost
to software development.
Having the necessity to make test and verication easier in systems based in components (CBD),
this work has, as main objective, the development of an integrated environment for verication and
test of protocols to the coordination of components exceptional behaviour.
Keywords: Tests, Formal Verication, Components Orchestration.
v
vi
Sumrio
Lista de Figuras xi
Lista de Tabelas xiii
1 Introduo 1
1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Componentes e Desenvolvimento Baseado em Componentes (DBC) . . . . . . 1
1.1.2 Testes e Vericao Formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organizao dos Captulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Teste de Software 5
2.1 Termos Utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Conceito e Importncia dos Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Objetivos e Limitaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Etapas do Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Fases e Estratgias de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1 Testes Unitrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.2 Testes de Integrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.3 Testes de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Design de Casos de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.1 Testes Black-Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.2 Testes White-Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Critrios de Testes para Comportamento Normal de Programas . . . . . . . . . . . . 14
2.7.1 Critrios de Fluxo de Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.2 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Critrios de Teste para o Comportamento Excepcional de Programas . . . . . . . . . 17
2.8.1 Estrutura de excees em Java . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8.2 Termos utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.3 Denio e uso de excees . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8.4 Ativao e desativao de excees . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8.5 Critrios de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8.6 Grafo de Fluxo de Controle para Mecanismos de Tratamento de Exceo . . . 20
2.8.7 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9 Ferramentas para Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
vii
viii SUMRIO
2.9.1 Ferramentas para Cobertura de Cdigo . . . . . . . . . . . . . . . . . . . . . 22
2.9.2 Ferramentas para Gerao de Requisitos de Teste . . . . . . . . . . . . . . . . 23
2.9.3 Justicativa da Escolha da OConGraX . . . . . . . . . . . . . . . . . . . . . . 24
2.10 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Vericao de Programas 27
3.1 Conceito de Vericao de Programas . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 Mtodos Formais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Denio de Vericao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.3 Limitaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Etapas para a Vericao de Programas . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Abordagens para a Vericao de Programas . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Sistema de Prova de Programas . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 Vericao de Modelos (Model Checking) . . . . . . . . . . . . . . . . . . . . 31
3.4 Ferramentas para Vericao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Ferramentas para Model Checking . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 Justicativa da Escolha do JPF/JPF Exceptions . . . . . . . . . . . . . . . . 34
3.5 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Componentes e Aes Atmicas Coordenadas 37
4.1 Desenvolvimento Baseado em Componentes (DBC) . . . . . . . . . . . . . . . . . . . 37
4.1.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2 Padres de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Sistemas Tolerantes a Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 Tratamento de Excees no Componente . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Tratamento de Excees na Arquitetura . . . . . . . . . . . . . . . . . . . . . 39
4.3 Aes Atmicas Coordenadas (Aes CA) . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Aninhamento e Composio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2 Tratamento de Excees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Uma Implementao das Aes Atmicas Coordenadas . . . . . . . . . . . . . . . . . 41
4.4.1 Arquitetura do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.2 CoordinatedAtomicAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.3 ExceptionTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.4 Participant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.5 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.6 Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.7 Transaction e External Object . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.8 Coordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.9 Exemplo de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5 Propriedades sobre Coordenao de Componentes 61
5.1 Propriedades sobre Aes Atmicas Coordenadas . . . . . . . . . . . . . . . . . . . . 61
5.1.1 Lgica Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
SUMRIO ix
5.1.2 Alloy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1.3 CSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Implementao das Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.1 Programao de Propriedades Customizadas no JPF . . . . . . . . . . . . . . 65
5.2.2 Escolha das Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.3 Limitaes do JPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 Propriedades Implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.1 Propriedade 1: Desfazimento de Transaes . . . . . . . . . . . . . . . . . . . 69
5.3.2 Propriedade 2: Tratamento das Excees . . . . . . . . . . . . . . . . . . . . . 72
5.4 Exemplo de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4.1 Propriedade 1: Desfazimento de Transaes . . . . . . . . . . . . . . . . . . . 76
5.4.2 Propriedade 2: Tratamento das Excees . . . . . . . . . . . . . . . . . . . . . 77
5.5 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6 Integrao de Teste e Vericao 79
6.1 Validao e Vericao (V&V) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.1.1 Abordagem Teste + Vericao . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2 OConGraX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2.1 Arquitetura da Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2.2 Funcionalidades da OConGraX . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3 Java PathFinder Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.3.1 Java PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.3.2 Propriedades Relativas a Tratamento de Exceo . . . . . . . . . . . . . . . . 89
6.3.3 Funcionalidades do Java PathFinder Exceptions . . . . . . . . . . . . . . . . . 90
6.4 Integrao das ferramentas via XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.4.1 Modelo XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.4.2 OConGraX - Gerao do XML . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.4.3 JPF Exceptions - Leitura do XML . . . . . . . . . . . . . . . . . . . . . . . . 97
6.4.4 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.5 Integrao das Ferramentas via Interface Grca . . . . . . . . . . . . . . . . . . . . 101
6.5.1 Interface Grca da Java V&V . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.5.2 Adaptaes da Interface para Integrao . . . . . . . . . . . . . . . . . . . . . 103
6.5.3 Novas Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.5.4 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.5.5 Anlise da Cobertura dos Pares du . . . . . . . . . . . . . . . . . . . . . . . . 108
6.6 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7 Concluses 111
7.1 Contribuio Cientca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.2 Escrita de Artigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.2.1 Artigos Publicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.2.2 Artigos em Julgamento e em Processo de Escrita . . . . . . . . . . . . . . . . 113
7.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
x SUMRIO
A Especicao do framework em CSPm 115
A.1 Especicao do Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
A.2 Especicao das Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
B Cdigo do Exemplo de Instanciao do Modelo de Aes Atmicas Coordenadas123
B.1 Pacote exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
B.1.1 Classe AccountAlreadyExistsException . . . . . . . . . . . . . . . . . . . . . . 123
B.1.2 Classe InvalidAccountNumberException . . . . . . . . . . . . . . . . . . . . . 123
B.2 Pacote simulation.database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
B.2.1 Classe BankAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
B.2.2 Classe BankDatabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
B.2.3 Classe Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
B.3 Pacote simulation.exceptionTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
B.3.1 Classe ExceptionTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
B.4 Pacote simulation.participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
B.4.1 Classe Participant0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
B.4.2 Classe Participant1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
B.5 Pacote simulation.handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
B.5.1 Classe Participant0Handler0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
B.5.2 Classe Participant1Handler0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
B.6 Pacote simulation.roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
B.6.1 Classe Participant0Role0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
C Cdigo Fonte de Propriedade de Tratamento de Exceo 133
C.1 Propriedade: Bloco de Captura Vazio . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
C.2 Sada da Vericao Feita pela JPF Exceptions . . . . . . . . . . . . . . . . . . . . . 134
C.2.1 Propriedade 1: Desfazimento de Transaes . . . . . . . . . . . . . . . . . . . 134
C.2.2 Propriedade 2: Tratamento das Excees . . . . . . . . . . . . . . . . . . . . . 135
D Cdigo Fonte para Integrao via XML 139
D.1 Gerao do XML pela OConGraX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
D.1.1 XMLGenerator.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
D.2 Leitura do XML pelo Java PathFinder Exceptions . . . . . . . . . . . . . . . . . . . 143
D.2.1 Mtodo readOcongraXml, da classe ExecutedPath.java . . . . . . . . . 143
Referncias Bibliogrcas 145
Lista de Figuras
1.1 Esquema da Abordagem Teste + Vericao [XHdM08] . . . . . . . . . . . . . . . . 2
2.1 Modelo de trs universos desenvolvido por Avizienis [Avi82], em que percebemos as
diferenas de contexto em que esto inseridos uma falha, um erro e um defeito . 6
2.2 Diagrama de atividades de teste de software, baseado em [Som06]. . . . . . . . . . . 7
2.3 Fases do teste de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Estruturas de controle na notao de grafo de uxo de controle [Pre01] . . . . . . . . 13
3.1 Esquema do processo de vericao de um sistema a posteriori [BK08]. . . . . . . . . 28
3.2 Esquema do processo de model checking [BK08] . . . . . . . . . . . . . . . . . . . . . 31
4.1 Componente tolerante a falhas [dMF01] . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Diagrama de representao de uma ao CA. . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Aes CA aninhadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Aes CA compostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Esquema de arquitetura do modelo implementado. . . . . . . . . . . . . . . . . . . . 43
4.6 Exemplo - Comportamento Normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.7 Exemplo - Comportamento Excepcional . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Classe PropertyListenerAdapter e suas dependncias . . . . . . . . . . . . . . . . . . 66
6.1 Esquema da Abordagem Teste + Vericao [XHdM08] . . . . . . . . . . . . . . . . 80
6.2 Esquema da arquitetura da OConGraX . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.3 GUI da OConGraX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4 Visualizao das denies e usos do mtodo main do exemplo 6.2, em que pode-se
ver as denies e usos do objeto obj. . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.5 Visualizao dos pares du do objeto obj, do exemplo 6.2. . . . . . . . . . . . . . . . 83
6.6 Screenshots mostrando algumas das funcionalidades da OConGraX. . . . . . . . . . . 84
6.7 Tela com as opes para gerao do arquivo XML . . . . . . . . . . . . . . . . . . . . 86
6.8 Visualizao do grafo de uxo de controle para a exceo e do exemplo 6.2 . . . . . . 86
6.9 Tela para seleo do projeto a ser vericado . . . . . . . . . . . . . . . . . . . . . . . 91
6.10 Tela para seleo das propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.11 Tela para seleo dos listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.12 Tela de estatsticas de cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.13 Tela de rastreamento de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.14 Esquema da integrao via XML entre OConGraX e JPF Exceptions . . . . . . . . . 94
xi
xii LISTA DE FIGURAS
6.15 Execuo no Java PathFinder Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 100
6.16 Java V&V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.17 GUI da Java V&V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.18 Java V&V - Aba Listeners da JPF Exceptions. . . . . . . . . . . . . . . . . . . . . 103
6.19 Java V&V - Aba Properties da JPF Exceptions. . . . . . . . . . . . . . . . . . . . . 104
6.20 Java V&V: visualizao da rvore de denies e usos e do OCFG . . . . . . . . . . 105
6.21 Seleo do projeto a ser vericado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.22 Seleo das propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.23 Congurao dos listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.24 Estatsticas de cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.25 Estatsticas da busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Lista de Tabelas
2.1 Denies e usos do objeto shapeObj do exemplo . . . . . . . . . . . . . . . . . . . . 16
2.2 Critrios e pares du . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Critrios baseados em denio-uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Critrios baseados em ativao-desativao . . . . . . . . . . . . . . . . . . . . . . . . 21
xiii
xiv LISTA DE TABELAS
Captulo 1
Introduo
Neste captulo apresentada a motivao e os objetivos a serem alcanados neste trabalho. A
motivao provm, principalmente, dos problemas enfrentados atualmente na rea de Desenvolvi-
mento Baseado em Componentes relativos conabilidade do software gerado; j os objetivos, por
sua vez, expem como o trabalho que est sendo desenvolvido pode ajudar na resoluo destes
problemas. Ao nal do captulo, o modo como este documento est organizado apresentado.
1.1 Motivao
No mercado global de competio acirrada e mudanas constantes, as organizaes precisam,
continuamente, adaptar suas prticas de negcio para atender s diferentes exigncias impostas
por governos, clientes, fornecedores e parceiros comerciais, mantendo a vantagem competitiva sobre
seus concorrentes. Uma das mais interessantes e promissoras propostas o Desenvolvimento Baseado
em Componentes (DBC), que promete uma alta produtividade no processo e sistemas com maior
exibilidade, conabilidade e qualidade.
1.1.1 Componentes e Desenvolvimento Baseado em Componentes (DBC)
Com o crescimento e a popularizao do mercado de componentes, muitos fornecedores de
software tm se especializado no desenvolvimento e comercializao de componentes que atendam
s necessidades especcas dos desenvolvedores de sistemas. Estes componentes so mais conhecidos
como COTS
1
ou de prateleira.
Utilizar estes componentes pr-existentes, integrando-os e assim construir rapidamente um novo
software, a ideia bsica da abordagem do DBC. Alm de prover um grande ganho da produtividade
no desenvolvimento de software graas reutilizao de componentes j existentes [Pre01], poss-
veis mudanas nos requisitos, impulsionadas pelas necessidades de negcio, podem ser facilmente
aplicadas com a substituio de um pequeno nmero de componentes.
Entretanto, a montagem de sistemas corporativos que sejam conveis e tolerantes a falhas,
a partir da integrao de componentes comerciais, tem-se mostrado uma atividade relativamente
complexa [Crn02, GAO95, Voa98]. Garantir que esta integrao no falhe passou a ser algo impres-
cindvel, sobretudo porque as consequncias de uma falha poderiam acarretar, por exemplo, grandes
prejuzos nanceiros, perda material e de vidas humanas.
1.1.2 Testes e Vericao Formal
Com o objetivo de denir quais requisitos so necessrios para estabelecer um bom teste do
software, denem-se os critrios de teste [Wey88, MK94, CK99, KSH
+
95]. Mesmo considerando
o direcionamento da escolha de conjuntos de testes a serem realizados a partir dos critrios, tais
conjuntos so, na sua maioria, ainda muito complexos. Apesar do esforo de contemplar todo o
1
Do ingls Commercial-O-The-Shelf
1
2 INTRODUO
cdigo do software e, com isso, ter uma chance maior de ter os defeitos encontrados, os testes so
capazes de assegurar o funcionamento do software apenas para o conjuntos de testes a que ele foi
submetido.
Uma outra abordagem para garantir o funcionamento do software como inicialmente especi-
cado, so as tcnicas de vericao formal de programas, as quais procuram assegurar que os
programas funcionam de acordo com a especicao ou atendem a um conjunto de propriedades re-
levantes. Existe atualmente um esforo no desenvolvimento de ferramentas que auxiliem a vericao
formal de programas, inclusive no paradigma de orientao a objetos para a linguagem Java, por
exemplo, explorada neste projeto [VHB
+
03, HDD
+
03, RDH04, EM04, DHJ
+
01, PDV01a, HD01].
Assim como nos testes, assegurar o bom funcionamento de programas por meio da vericao for-
mal tem um impacto considervel no custo do desenvolvimento de software. Teste e vericao de
programas so, portanto, atividades complementares no desenvolvimento de software e podem ser
exploradas como tal [Xav08, HDD
+
03, RDH04, EM04, HD01, PDV01a, DHJ
+
01].
A viabilidade prtica de testes de software depende de mecanismos e ferramentas que auxiliem
esta atividade, de forma a automatizar a gerao de casos e dados de testes a serem aplicados.
Por outro lado, a aplicao prtica de vericadores formais em linguagens de programao depende
da predenio de propriedades, j que os desenvolvedores de software, em geral, no possuem
treinamento adequado para denir novas propriedades. Alm disso, faz-se necessrio o uso conjunto
de ferramentas de ambas as atividades para que sejam exploradas suas complementaridades.
No desenvolvimento de sistemas baseados em componentes (DBC), o teste e a vericao de-
vem ser realizados tanto para os componentes individuais como para os seus mecanismos de in-
tegrao. O projeto Formalizao da Orquestrao de Componentes Tolerantes a Falhas (CNPq:
551038/2007-1) tem como objetivo principal dar suporte ao tratamento formal para os mecanismos
de integrao de componentes tanto para o comportamento normal como para o comportamento
excepcional. Dentro deste projeto maior, este trabalho de Mestrado se prope a desenvolver um
ambiente integrado para a vericao e teste de protocolos para a coordenao do comportamento
excepcional de componentes. A integrao proposta no trabalho entre validao e vericao almeja
a reduo do espao de testes por meio da utilizao dos resultados da vericao para gerao
de um conjunto de testes, conforme ilustrado a seguir.
Figura 1.1: Esquema da Abordagem Teste + Vericao [XHdM08]
Maiores detalhes desta abordagem so fornecidos na Seo 6.1.
OBJETIVOS 3
1.2 Objetivos
A meta deste trabalho construir um ambiente que facilite a realizao tanto de testes como
de vericao de sistemas baseados em componentes tolerantes a falhas. Para isso, foi denido
inicialmente um conjunto de propriedades desejveis relativas coordenao do comportamento
excepcional de componentes; e posteriormente, foi feita a integrao de ferramentas para teste e
vericao de programas Java:
1. OConGraX (Object Control-Flow Graph with eXceptions) [HM07, NHdM09]
2
: esta ferramenta,
escrita na linguagem Java [GJSB05a],recebe um sistema tambm escrito em Java e devolve
ao usurio informaes como: objetos e excees contidos no software recebido como entrada,
suas denies e usos [CK99, SH98], e um grafo de controle de uxo de objetos e de excees
[CK99, SH98, SH99]. Estas informaes, em conjunto, permitem realizar testes white-box de
maneira mais rpida e eciente.
2. JPF Exceptions (Java PathFinder Exceptions) [Xav08]: utilizando-se do sistema JPF (Java
Pathnder) [VHB
+
03, Jav], o aplicativo desenvolvido nesse trabalho permite a realizao de
vericao de propriedades relativas ao comportamento excepcional dos componentes e testes
utilizando os critrios baseados em uxos de objetos e excees de programas [CK99, SH99].
Dessa forma, os objetivos a serem alcanados neste trabalho so:
Denio de propriedades relativas coordenao do comportamento excepcional dos com-
ponentes: predenir um conjunto de propriedades relativas coordenao do comportamento
excepcional dos componentes para que sejam utilizadas diretamente pelos desenvolvedores.
Desta forma, o desenvolvedor de componentes pode vericar os seus mecanismos de coor-
denao, a partir de uma arquitetura padro, sem precisar denir novas propriedades para
cada sistema especicamente, tornando prtico o uso de vericadores formais na construo
de sistemas baseados em componentes.
Integrao dos trabalhos acima citados: permitir a comunicao entre ambos via XML. Esta
comunicao consiste na gerao de um arquivo XML contendo as denies e usos de objetos
e excees, mais os pares de denio e uso de excees, por parte da OConGraX. Em seguida,
o arquivo gerado dever ser lido pela JPF Exceptions para obteno dos dados de denies e
usos oriundos da OConGraX. Estes dados so usados ento pela JPF Exceptions para realizar
a vericao de propriedades e os rastreamento dos pares de denies e usos cobertos durante
a vericao.
Desenvolvimento de um aplicativo em Java, com uma interface grca que permita ao tes-
tador utilizar facilmente todas as funcionalidades de testes e vericao proporcionadas pela
integrao dos dois trabalhos citados. Este aplicativo dedicado a programas escritos na
linguagem Java.
1.3 Organizao dos Captulos
Este trabalho est organizado nos seguintes captulos:
Captulo 2: apresentao da teoria relacionada a testes de programas e de algumas ferra-
mentas utilizadas para automatizar este processo.
Captulo 3: apresentao da teoria relacionada vericao de programas e de algumas
ferramentas utilizadas para a automao deste processo.
2
A ferramenta OConGraX foi desenvolvida no IME-USP por mim, durante iniciao cientca feita sob orientao
da Prof
a
Ana C. V. de Melo [HM07].
4 INTRODUO
Captulo 4: apresentao da teoria relacionada a componentes e aes atmicas coordenadas,
e da implementao do modelo de aes atmicas coordenadas a ser utilizado para a realizao
de vericao de suas propriedades.
Captulo 5: apresentao das propriedades sobre as aes atmicas coordenadas e sua im-
plementao na ferramenta JPF Exceptions.
Captulo 6: apresentao da ideia de V&V (uso integrado de validao e vericao), uma
descrio das ferramentas a serem utilizadas no trabalho e o resultado da integrao entre
elas.
Captulo 7: apresentao das concluses nais sobre o desenvolvimento deste trabalho.
Captulo 2
Teste de Software
Neste captulo apresentada a teoria relativa a testes de programas utilizada neste trabalho.
Inicialmente, descrevemos os termos relativos a este tema que sero utilizados ao longo do texto.
Em seguida, abordamos os tpicos relacionados teoria de testes:
o conceito e a importncia do teste;
seus objetivos e limitaes;
as etapas do processo de teste de um software;
as fases e estratgias de teste existentes;
as tcnicas para projeto de casos de teste e os critrios de teste.
Ao nal, apresentamos algumas das ferramentas utilizadas para automatizar parte do processo
de teste de software, tornando-o mais vivel para aplicao prtica.
2.1 Termos Utilizados
Nesta seo, apresentamos alguns termos
1
[Bin00, Avi82, DMJ07, Int06, Xav08, Per07, WFW09]
a serem utilizados no decorrer do texto:
Bug: problema em um sistema de software, como falha ou defeito.
Falha: ocorre quando um sistema ou componente no fornece a funcionalidade esperada,
devido, por exemplo, a condies fsicas anmalas. Pode ser percebida por meio de sadas
incorretas, nalizaes anormais ou o no cumprimento de metas estabelecidas para restries
de tempo e espao.
Erro:
2
manifestao de uma falha no sistema, causando modicaes no estado do sistema
por meio de valores diferentes dos esperados.
Defeito: causado por um erro, denido como um desvio de execuo em relao especi-
cao original do sistema.
Dados de testes: correspondem aos dados de entrada a serem utilizados no teste de um
programa.
1
Embora utilizadas neste texto, as denies para os termos aqui apresentadas nem sempre so seguidas por no
serem unanimidade entre os pesquisadores da rea [DMJ07].
2
O termo erro pode ser empregado tambm de uma maneira informal, como tendo qualquer um dos signicados
apresentados para falha e defeito.
5
6 TESTE DE SOFTWARE
Figura 2.1: Modelo de trs universos desenvolvido por Avizienis [Avi82], em que percebemos as diferenas
de contexto em que esto inseridos uma falha, um erro e um defeito
.
Casos de testes: denem o estado anterior ao teste do elemento a ser testado, bem como
de seu ambiente, as entradas ou condies de teste e os resultados esperados. Os resultados
esperados denem o que o sistema deve produzir a partir das entradas de teste. Isto inclui
mensagens geradas pelo sistema, excees, valores retornados e o estado resultante do sistema
e de seu ambiente.
Conjunto de testes (Test suite): conjunto de casos de teste relacionados.
Execuo de testes: a execuo de um conjunto de testes.
Test driver: classe ou programa utilitrio que aplica casos de teste a um sistema.
Stub: consiste numa implementao que simula o funcionamento de um mtodo, mdulo ou
componente do sistema, cujo cdigo ainda est incompleto. Seu uso ocorre principalmente
para efeito de teste do sistema.
Cobertura de teste: mtrica que descreve a quantidade de requisitos de teste exercitada
no cdigo-fonte de um programa por um dado conjunto de teste. Critrios de teste baseados
nessa mtrica especicam o que deve ser coberto (isto , exercitado por ao menos um teste) no
sistema, limitando assim o conjunto de testes necessrios para testar efetivamente o programa.
2.2 Conceito e Importncia dos Testes
Segundo Bertolino [Ber03], o teste de software consiste na vericao dinmica do comporta-
mento do programa por meio de um conjunto nito de casos de teste, selecionados apropriadamente
a partir de um domnio de execuo geralmente innito, e na comparao do comportamento obtido
com o esperado de acordo com a especicao. Ele constitui uma importante fase do desenvolvi-
mento de software, e sua importncia se d, principalmente, devido ao fato de ser por meio dele
que bugs de software so identicados. Corrigindo estes bugs, a probabilidade de falha no software
diminui, tornando assim o seu uso mais seguro e convel.
No caso de sistemas crticos, como os utilizados em aeronaves e na rea da sade, a realizao
de testes ainda mais importante (seno imprescindvel), para se evitar eventos catastrcos que
envolvam perdas de vidas e/ou de grandes somas de dinheiro. Como exemplos de eventos destas
propores, pode-se citar o caso da queda do foguete francs Ariane 5, em 1996, que ocorreu devido
a um erro de converso de um valor de ponto utuante de 64 bits para um inteiro de 16 bits
[Inq96], e o caso da perda de uma sonda da NASA em Marte devido a incompatibilidades entre
dois componentes de software, onde um deles utilizava o sistema ingls e o outro o sistema mtrico
de medidas [MPI00].
2.3 Objetivos e Limitaes
As principais metas a serem alcanadas com o teste de software [Som06, Pre01] so:
ETAPAS DO PROCESSO 7
Descobrir bugs no software que fazem com que ele no funcione adequadamente. Para isto,
importante que os casos de teste a serem projetados tenham alta probabilidade de encontrar
erros ainda no descobertos.
Mostrar aos desenvolvedores e ao cliente que o software funciona de acordo com sua especi-
cao.
importante salientar aqui que, como Dijkstra armou [Dij70], Testes de programas podem
ser usados para mostrar a presena de erros, mas nunca para mostrar sua ausncia. Desta forma,
testes jamais podem ser usados para demonstrar que o software est completamente livre de erros,
mas sim, podem ser utilizados para convencer que o software desenvolvido bom o suciente para
uso operacional.
Outra questo relacionada aos testes o fato de ser necessrio muito tempo para sua realizao.
Como armou Pressman [Pre01], cerca de 30 a 40% de todo o esforo no desenvolvimento de um
software gasto em testes, o que torna este processo tambm bastante caro. Para tornar o teste
de programas vivel, ferramentas que automatizam etapas desta atividade esto sendo construdas.
Algumas delas so apresentadas na Seo 2.9.
2.4 Etapas do Processo
Testar um software uma tarefa dinmica e complexa, que demanda tempo para sua realizao.
De um modo geral, podemos dividir o processo de teste nas seguintes etapas [Som06]:
1. Fazer o design dos casos de teste: primeira etapa a ser feita, consiste no planejamento de
casos de teste com todas as suas entradas e respectivas sadas esperadas, com a nalidade de
encontrar possveis erros no cdigo. Idealmente, deve-se escrever uma quantidade de casos de
teste no muito grande, mas suciente para que estes casos cubram todas as funcionalidades
e estrutura do programa [Pre01].
2. Preparar os dados de teste: prover os dados de entrada, especicados nos casos de teste,
para execuo no programa.
3. Executar o programa com os dados de teste: utilizando os dados de teste, o conjunto
de testes do programa executado e os resultados retornados pelo software so colhidos.
4. Comparar os resultados obtidos com os esperados: fazer a comparao dos resultados
obtidos na execuo do programa, com os resultados esperados nos casos de teste. Caso haja
divergncia nos valores, preciso averiguar no software os erros que causaram este problema,
identic-los e corrigi-los.
Na Figura 2.2, podemos ver um diagrama mostrando estas etapas de maneira esquematizada.
Figura 2.2: Diagrama de atividades de teste de software, baseado em [Som06].
8 TESTE DE SOFTWARE
2.5 Fases e Estratgias de Teste
Fases (ou nveis) de teste tm como funo determinar o escopo de cobertura que o teste de
um software deve ter. De acordo com Delamaro et al. [DMJ07], so trs as fases principais no
desenvolvimento de testes: testes unitrios, testes de integrao e testes de sistemas. A Figura 2.3
ilustra este conceito, apresentando por meio de um diagrama as trs fases em sua ordem correta de
realizao.
Figura 2.3: Fases do teste de software
Alm de escopos prprios, cada fase possui estratgias de teste que podem ser usadas durante sua
realizao. Estas estratgias so as responsveis por guiar o desenvolvimento do testes, de maneira
planejada e ecaz.
Nas prximas sees, descrevemos cada uma dessas fases e suas respectivas estratgias.
2.5.1 Testes Unitrios
Testes unitrios [Pre01, DMJ07] possuem como foco principal o teste nas menores unidades/-
mdulos de um programa ou componente. No caso de programas procedimentais, poderamos con-
siderar como unidades suas funes; no caso de programas orientados a objetos, elas poderiam ser
os mtodos, ou mesmo as classes do programa.
Nesta fase, os erros a serem descobertos esto relacionados principalmente ao cdigo do pro-
grama, sobretudo na implementao de algoritmos e na manipulao de estruturas de dados. Exem-
plos de bugs a serem encontrados, so: computaes erradas, comparaes incorretas e uxos de
controle imprprios.
Procedimento para a Realizao dos Testes Unitrios
Os testes unitrios so feitos, em geral, juntamente com o processo de implementao do
cdigo. Por ser testado apenas um nico componente/mdulo do programa, e por ele no ser
um programa stand-alone, preciso utilizar um test driver e stubs para a execuo dos testes.
Para evitar uma carga de trabalho adicional, deve-se manter estes cdigos auxiliares o mais
simples possvel.
2.5.2 Testes de Integrao
Aps vericar que os mdulos de um programa funcionam bem isoladamente, por meio dos testes
unitrios, necessrio garantir que, ao coloc-los funcionando juntos, no ocorram bugs. Para isso,
a segunda fase dos testes deve ser feita, a fase dos testes de integrao [Pre01, DMJ07].
Os testes de integrao so feitos de modo incremental, de forma que a cada mdulo integrado
ao sistema, testes sejam realizados para garantir que esta integrao no gerar erros. Assim, caso
algum erro seja encontrado, ele pode ser isolado e corrigido facilmente.
Para realizar os testes de integrao, diversas estratgias existem. A seguir, descrevemos trs das
principais estratgias [Pre01]: a de integrao top-down, a de integrao bottom-up e a de regresso.
FASES E ESTRATGIAS DE TESTE 9
Testes para Integrao Top-Down
A integrao top-down consiste em, a partir do mdulo principal do programa (utilizado
como test driver), adicionar seus mdulos diretamente subordinados sucessivamente, por meio
da substituio dos stubs construdos anteriormente. Para a incorporao destes mdulos
subordinados, duas abordagens podem ser adotadas: a integrao em profundidade (depth-rst
integration), que integra todos os componentes do maior caminho de controle da estrutura;
e a integrao em largura (breadth-rst integration), que incorpora todos os componentes de
um mesmo nvel hierrquico.
Uma vez integrado, o componente deve ser testado para assegurar que erros no esto sendo
inseridos durante o processo, garantindo assim a qualidade do software.
Com a aplicao desta estratgia de teste, os pontos principais de deciso e controle so
vericados logo no incio do processo de teste, considerando que o sistema tenha uma hierar-
quia consistente e os nveis mais altos desta hierarquia contenham tais pontos. Desta forma,
problemas nesses pontos principais do programa so detectados mais cedo, o que essencial
para o desenvolvimento do software. Ademais, se a abordagem utilizada for a de integrao
em profundidade, possvel ter uma funcionalidade completa do programa implementada e
devidamente demonstrada. Isto d conana ao desenvolvedor e ao cliente para prosseguir
com o desenvolvimento do sistema.
Apesar das vantagens, e de esta estratgia parecer simples, na prtica muitos problemas podem
surgir quando ela aplicada. Estes problemas so causados, em geral, pela necessidade de se
integrar componentes de nvel hierrquico mais baixo para testar componentes que esto
no alto da hierarquia. Isto ocorre porque, inicialmente, stubs substituem os componentes de
nvel hierrquico baixo, no gerando um uxo signicativo de dados para os componentes j
integrados. Com isso, os testadores podem seguir trs alternativas:
1. Atrasar a realizao dos testes at que os stubs sejam substitudos pelos
mdulos reais: isto pode dicultar o acesso causa de possveis erros encontrados,
alm de violar a natureza da integrao top-down.
2. Desenvolver stubs que simulem o funcionamento do mdulo real: isto pode
signicar uma carga maior de trabalho adicional, uma vez que os stubs tornam-se mais
e mais complexos.
3. Utilizar uma outra forma de integrao: ao invs da estratgia top-down, utilizar
por exemplo a estratgia bottom-up.
Testes para Integrao Bottom-Up
A integrao bottom-up comea com os mdulos do nvel hierrquico mais baixo, e os integra,
continuamente, aos mdulos que se encontram diretamente acima na hierarquia. Desta forma,
a necessidade de stubs eliminada, j que os componentes subordinados j esto integrados
no momento do teste dos componentes de nvel hierrquico mais alto.
Para a realizao desta integrao, primeiro os mdulos de nvel hierrquico mais baixos so
combinados em um cluster, que faz uma tarefa especca do programa. Em seguida, um test
driver escrito, para testar o cluster. Uma vez que o cluster vericado (e corrigido), o driver
utilizado removido e a integrao prossegue subindo na estrutura do programa.
A principal desvantagem desta abordagem a de que um programa no existe como uma
entidade at que o seu ltimo mdulo seja adicionado [Mye79], problema que no existe na
abordagem top-down.
10 TESTE DE SOFTWARE
Testes de Regresso
Esta estratgia utilizada nesta fase de teste para minimizar os efeitos colaterais
3
que possam
ser causados pela integrao dos componentes do programa. Ela consiste na re-execuo de
um subconjunto de testes realizados numa fase anterior, assegurando assim que as mudanas
ocasionadas pela integrao no geram efeitos colaterais.
O sub-conjunto de testes a ser utilizado no teste de regresso possui trs classes de casos de
testes:
1. Um conjunto representativo de testes que exercitam todas as funes do software;
2. Testes adicionais que focam nas funes do software que podem ser afetadas pelas mu-
danas causadas pela integrao;
3. Testes que focam nos componentes de software que sofreram alguma alterao no processo
de integrao.
2.5.3 Testes de Sistemas
O teste de sistemas [Pre01, DMJ07] engloba uma srie de testes, cujo principal objetivo o de
exercitar todas as funcionalidades do sistema computacional completo, garantindo assim que todos
os elementos do sistema foram integrados adequadamente e realizam suas funes corretamente.
A seguir, trs tipos de teste de sistemas so apresentados: o teste de carga (ou de stress), o teste
de desempenho e o teste de recuperao.
Teste de Carga (ou de Stress)
Esta estratgia utilizada para vericar o comportamento do sistema em situaes anormais,
que demandam uma grande quantidade, volume e frequncia de seus recursos. Para isso,
so executados testes que forcem o programa a enfrentar tal situao, como por exemplo, a
execuo de casos de teste que precisam que a memria do sistema e outros recursos sejam
utilizados em sua capacidade mxima. A ideia conhecer o limite do sistema desenvolvido.
Teste de Desempenho (ou de Performance)
No teste de performance, testes so projetados para vericar o desempenho em tempo de exe-
cuo do sistema, dentro do contexto de sistemas integrados. Frequentemente esta estratgia
aplicada juntamente com a de teste de carga, pois ambas fazem uso tanto do hardware
quanto do software. Para monitor-la e vericar os resultados, deve ser utilizado um aparelho
externo que faa a medio da utilizao de recursos pelo sistema.
Vericar a performance da execuo de um sistema necessrio, sobretudo no caso dos siste-
mas de tempo real e dos sistemas embarcados, uma vez que eles exigem rapidez na resposta
do sistema.
Teste de Recuperao
Consiste em fazer com que o sistema falhe de diversas maneiras, a m de avaliar o modo
como se d sua recuperao. Caso a recuperao seja feita automaticamente pelo prprio
sistema, a corretude da reinicializao e/ou da recuperao dos dados vericada. J no caso
da recuperao ser feita com interveno humana, avaliado o tempo necessrio para que o
sistema seja restabelecido.
Esta estratgia deve ser aplicada principalmente em sistemas que devem ser tolerantes a
falhas (e assim devem continuar funcionando aps a ativao de uma falha), e em sistemas
que precisam retornar ao funcionamento rapidamente para evitar transtornos a seus usurios.
3
Por efeitos colaterais, entende-se a existncia de erros em funes que funcionavam corretamente antes de sua
integrao com outras partes do cdigo, e a posterior propagao destes erros.
DESIGN DE CASOS DE TESTES 11
2.6 Design de Casos de Testes
Mtodos para guiar o projeto de casos de teste tm sido criados com o intuito de ajudar os
desenvolvedores de teste a realizar esta tarefa do modo melhor e mais completo possvel. Estes
mtodos fornecem, por meio de uma abordagem sistemtica, mecanismos que auxiliam na derivao
de casos de teste que possuem alta probabilidade de encontrar erros no software.
Para fazer o design dos casos de teste, duas abordagens principais so utilizadas [Pre01]:
1. Assegurar que todas as funes especicadas na fase de requisitos do produto estejam imple-
mentadas e funcionando corretamente. Assim, testes devem ser feitos de modo a demonstrar
que as funcionalidades do produto satisfazem sua especicao, ao mesmo tempo em que
feita uma varredura para encontrar eventuais erros nos software. Esta abordagem tambm
conhecida como teste black-box.
2. Vericar que todas as partes internas do software funcionam de acordo com a especicao
fornecida nas fases anteriores de seu desenvolvimento. Assim, os testes devem ser conduzidos
de modo a procurar exercitar todos os componentes do software, fazendo uma varredura na
estrutura do cdigo procura de bugs. Esta abordagem conhecida como teste white-box.
Nas prximas sees, detalhamos estas abordagens, descrevendo os procedimentos e tcnicas que
podem ser feitos para a adoo de cada uma delas no desenvolvimento dos casos de teste, baseados
na teoria apresentada por Pressman [Pre01] e Delamaro et al. [DMJ07].
2.6.1 Testes Black-Box
Os testes black-box, tambm conhecidos como testes funcionais, buscam validar o comportamento
de um programa, avaliando se ele se ajusta s especicaes fornecidas. Esta abordagem no exige
conhecimento sobre a estrutura do cdigo do programa, o que possibilita sua aplicao a programas
tanto de pequeno quanto de grande porte. Ademais, os testes funcionais permitem, alm de detectar
bugs, ver como o programa reage a situaes de falha, e se a consistncia e integridades dos dados
externos mantida.
Os possveis erros a serem identicados pelos testes black-box podem ser separados nas seguintes
categorias:
Funes incorretas ou inexistentes;
Erros de interface;
Erros na estrutura de dados ou no acesso a dados externos;
Erros de performance ou comportamento;
Erros de incio e trmino.
Por meio da utilizao dos testes funcionais, um conjunto de casos de teste que satisfazem os
seguintes critrios derivado:
Casos de teste que reduzem signicativamente o nmero de casos de teste adicionais que
devem ser projetados para alcanar um nvel de teste aceitvel;
Casos de teste que nos informam sobre a presena ou ausncia de categorias de erros, ao invs
de dar informaes sobre um erro especco associado ao teste em questo.
Para fazer a derivao de tais casos de teste, tcnicas foram desenvolvidas. Apresentamos algu-
mas delas a seguir [Pre01]:
Particionamento de Equivalncia
Este mtodo divide o domnio de entrada em classes de equivalncia, das quais so derivados os
casos de teste. Por classe de equivalncia, entende-se um conjunto de estados vlidos ou inv-
lidos para as condies de entrada e de sada. Estas, podem ser um valor numrico especco,
uma faixa de valores, um conjunto de valores relacionados ou uma condio booleana.
Obtendo-se as classes de equivalncia, casos de teste para cada item do domnio de entrada e
sada so desenvolvidos e executados, com o intuito de descobrir possveis categorias de erros
presentes no cdigo. Os casos de teste so selecionados de maneira que o maior nmero de
atributos das classes de equivalncia vlidas seja exercitado numa nica vez.
Anlise do Valor Limite
A tcnica da anlise do valor limite foi desenvolvida com a nalidade de selecionar casos de
teste que exercitam os valores limites do domnio de entrada, valores nos quais os erros tendem
a se concentrar. Ela complementar tcnica do particionamento de equivalncia, e analisa
tanto o domnio de entrada, quanto o domnio de sada do programa, de modo que:
1. Para um intervalo de valores do domnio de entrada, so testados seus valores mnimo e
mximo;
2. Para testar os valores limites do domnio de sada, devem ser criados casos de teste cujos
resultados de execuo sejam os valores mnimo ou mximo permitidos para os dados de
sada;
3. Caso as estruturas de dados internas tambm tenham limites, como por exemplo arrays,
os testes devem exercitar cada uma delas em seus valores limites.
Teste de Comparao
Em sistemas crticos, muitas vezes hardware e software redundantes so utilizados, a m de
minimizar a possibilidade de erros. Para desenvolver software redundante, diversas equipes
trabalham em verses independentes da aplicao, fazendo uso de uma mesma especicao.
Desta forma, para garantir a consistncia do trabalho, as verses so testadas paralelamente
com os mesmos dados de entrada dos casos de teste projetados utilizando outras tcnicas
de teste funcional (ex.: particionamento de equivalncia), e a sada de cada uma das verses
ento vericada. Se as sadas forem todas iguais, assumimos que todas as verses esto
corretas; caso contrrio, feita uma busca em cada aplicao para se encontrar o defeito que
causou o resultado diferente.
A realizao dos testes black-box ocorre, em geral, nas etapas nais do desenvolvimento do
software. Isto porque eles se concentram em achar erros no domnio da informao, e no na estru-
tura/cdigo do programa, o que traz como consequncia a necessidade de ter boa parte do sistema
j funcionando para que suas funcionalidades sejam testadas adequadamente.
2.6.2 Testes White-Box
Testes white-box, ou testes estruturais, preocupam-se em examinar detalhadamente os procedi-
mentos adotados no cdigo do programa, fazendo uma varredura pelos caminhos lgicos do programa
e vericando se, em determinados pontos, os resultados obtidos coincidem com os resultados espe-
rados. Alguns dos casos de teste que podem ser derivados utilizando mtodos de testes estruturais
visam a garantir que:
Todos os caminhos independentes de um mdulo do software foram executados ao menos uma
vez;
Todas as decises lgicas so exercitadas, exercitando tanto o lado verdadeiro, quanto o falso;
DESIGN DE CASOS DE TESTES 13
Todos os laos do programa so executados em seus limites, inclusive os limites de operaes
internas;
A estrutura dos dados externos exercitada, assegurando sua validade.
A seguir, apresentamos algumas tcnicas relativas ao teste white-box utilizadas para derivar
casos de teste [Pre01]:
Teste de Caminho Bsico
Proposta por McCabe [McC76], esta tcnica parte de uma medida de complexidade derivada
do cdigo, e utiliza-a como um guia para denir um conjunto bsico de caminhos de execuo.
Os casos de teste gerados devem, necessariamente, exercitar cada instruo do programa ao
menos uma vezes. Eles so derivados a partir de quatro passos, mostrados abaixo:
1. Desenhar um grafo de uxo correspondente ao cdigo a ser testado: o grafo de
uxo uma representao dos caminhos de execuo do programa (Figura 2.4). Cada n
representa uma instruo do cdigo, enquanto as arestas orientadas mostram a direo
do uxo de execuo.
Figura 2.4: Estruturas de controle na notao de grafo de uxo de controle [Pre01]
2. Determinar a complexidade ciclomtica do grafo: a complexidade ciclomtica
(CC) uma mtrica de software que mede quantitativamente a complexidade lgica do
programa. No contexto da tcnica de teste de caminhos bsicos, o valor da complexidade
ciclomtica determina o limite superior para o nmero de caminhos independentes no
conjunto bsico do programa, e para o nmero de testes que devem ser realizados para
assegurar que todas as instrues foram executadas ao menos uma vez. Para calcular o
valor desta mtrica, utilizando o grafo, devemos efetuar um dos dois clculos:
(a) CC = AN + 2, onde A o nmero de arestas do grafo, e N o nmero de ns;
(b) CC = P + 1, onde P o nmero de ns predicativos contidos no grafo.
3. Determinar um conjunto bsico de caminhos linearmente independentes: por
caminhos linearmente independentes, entende-se qualquer caminho do programa que
introduza pelo menos um novo conjunto de instrues de processamento ou uma nova
condio [DMJ07]. No contexto do grafo de uxo, a cada novo caminho linearmente
independente, uma aresta includa. Neste passo, o nmero de caminhos limitado
superiormente pelo valor da complexidade ciclomtica calculado anteriormente.
4. Preparar casos de teste que foram a execuo de cada caminho independente:
os dados devem ser escolhidos de modo que as condies nos ns predicativos sejam
apropriadamente exercitadas a cada caminho testado.
Teste de Estruturas de Controle
Apesar da tcnica anterior ser bastante simples e eciente, ela no suciente se aplicada
sozinha. Para melhorar o teste white-box, ento, outros mtodos para testes de estruturas de
controle foram desenvolvidos, e so apresentados a seguir.
Testes de Condio: mtodo para design de casos de teste que busca exercitar todas
as condies existentes no programa. A vantagem deste mtodo a de que se o conjunto
de testes obtido for efetivo para encontrar erros nas instrues de condio do programa,
ento provavelmente ele tambm o para encontrar erros no programa [Pre01].
Testes de Laos: embora desempenhem, muitas vezes, papis fundamentais no algo-
ritmo implementado, os laos so muitas vezes negligenciados na hora dos testes. Este
mtodo para design de casos de teste procura alterar este cenrio, focando na validao
de todos os laos existentes no programa.
Testes de Fluxo de Dados: este mtodo seleciona os caminhos para teste de um
programa de acordo com a localizao das denies e usos de suas variveis. Particu-
larmente, a variante deste mtodo para programas orientados a objeto foi parcialmente
automatizada pela ferramenta OConGraX [HM07, NHdM09], a ser utilizada neste tra-
balho. Maiores detalhes sobre esta variante so dadas na Seo 2.7.
Diferentemente dos testes funcionais, os testes estruturais so, em geral, aplicados j nas fases
iniciais do desenvolvimento do programa. Isto ocorre porque eles consideram essencialmente a es-
trutura do cdigo e sua lgica, que j cam disponveis para teste desde o incio da implementao.
Ademais, estes testes so normalmente aplicados a pequenos mdulos do software, pois em mdu-
los de maior porte o nmero de caminhos lgicos tende a aumentar signicativamente, afetando a
viabilidade de aplicao de tal abordagem de teste.
2.7 Critrios de Testes para Comportamento Normal de Programas
Critrios de testes so, grosso modo, um conjunto de regras que estabelecem certos requisitos a
serem alcanados com os testes de programas. A partir de um critrio especco, feita a seleo
de um test suite contendo casos de teste que alcancem tais requisitos da maneira mais eciente
possvel.
Atualmente, diversos critrios de teste existem para serem aplicados com tcnicas de teste cor-
respondentes, aos mais diversos tipos de programas. Em especial, nosso interesse est nos critrios
para testes estruturais aplicados a programas do paradigma de orientao a objetos (OO), como
os programas escritos na linguagem Java. So estes programas que tm a escrita de casos de teste
facilitada pela ferramenta OConGraX [HM07, NHdM09], a ser utilizada neste trabalho de Mestrado.
A seguir, apresentamos os critrios de testes proposto por Chen e Kao [CK99] para programas
OO, critrios nos quais foi baseada a implementao da OConGraX [HM07, NHdM09] para a anlise
do comportamento normal de programas ( i.e., anlise de cdigo em que excees no so lanadas
e/ou tratadas). Posteriormente, um exemplo de aplicao destes critrios mostrado.
2.7.1 Critrios de Fluxo de Objetos
Os critrios de uxo de objetos, propostos por Chen e Kao [CK99], so baseados em uxo de
dados, e englobam as caractersticas da programao OO. Primeiramente, vamos denir alguns
conceitos necessrios para o entendimento desta proposta de seleo de casos de teste, para ento
apresentarmos os critrios propriamente ditos:
Denio de Objeto: um objeto denido quando seu estado inicializado ou alterado, ou
seja, quando uma das seguintes condies ocorre:
1. O construtor do objeto chamado;
2. O valor de um atributo de estado denido, ou seja, feita uma atribuio explcita a
ele;
3. Uma funo que altera o valor de um atributo de estado chamada;
Uso de Objeto: um objeto usado quando uma das seguintes condies ocorre:
CRITRIOS DE TESTES PARA COMPORTAMENTO NORMAL DE PROGRAMAS 15
1. Um de seus atributos de estado utilizado em uma computao ou predicado;
2. Uma de suas funes que utilizam os atributos de estado utilizada;
3. O objeto passado como parmetro para alguma funo.
Binding: ocorre quando um objeto pode ser associado a diferentes classes em tempo de
execuo, numa substituio polimrca.
Par du de Objetos: composto por uma denio e um uso de um objeto, sendo que, a partir
da denio, possvel chegar ao uso por meio de um caminho em que no ocorra redenio.
Grafo de Fluxo de Objetos (OCFG): grafo semelhante ao do teste do caminho bsico (ver
Seo 2.6.2), que representa o uxo dos objetos dos programas OO levando em considerao
as instrues nas quais eles so denidos e/ou usados, e utilizado para encontrar os pares
du de objetos, sobretudo em cdigos de maior porte. O grafo composto por super-ns que
representam os mtodos das classes. Dentro dos super-ns encontram-se os ns que contm
o nmero da linha e a instruo do cdigo na qual ocorre a denio e/ou uso do objeto. A
direo do uxo de execuo do objeto dentro de um mtodo indicada por arestas orientadas
cheias; quando o uxo envolve um n de outro mtodo, a aresta que faz a ligao inter-mtodo
orientada e tracejada.
Os critrios de uxo de objetos propostos so denidos a seguir:
All-bindings: todo possvel binding de cada objeto deve ser exercitado ao menos uma vez
quando o objeto denido ou usado. Se uma instruo envolve mltiplos objetos, ento toda
combinao de um possvel binding precisa ser testado ao menos uma vez.
All-du-pairs: todos os pares du de todos os objetos devem ser exercitados ao menos uma
vez.
2.7.2 Exemplo
Para exemplicar a aplicao dos critrios de uxo de objetos, apresentamos na Listagem 2.1
um exemplo [Pru04] adaptado para linguagem Java. O cdigo do exemplo apresenta algumas classes
Java que devem ser testadas (Frame, Circle, Shape e Square) e uma classe de testes.
1 abstract cl ass Shape{
2 i nt per i met er ;
3 public void s et Per i met er ( i nt per i met er ) {
4 thi s . per i met er = per i met er ;
5 }
6 public i nt get Per i met er ( ) {
7 return per i met er ;
8 }
9 public void t r i p l e ( ) {
10 s et Per i met er (3 per i met er ) ;
11 }
12 public abstract void draw( ) ;
13 }
14 cl ass Square extends Shape {
15 protected i nt x , y ;
16 public Square ( i nt i ni t Per i met er , i nt x , i nt y) {
17 thi s . x = x ;
18 thi s . y = y ;
19 per i met er = i ni t Pe r i me t e r ;
20 }
21 public void draw( ) {
22 System . out . pr i nt l n ( "Desenhando Square com peri metr o " + per i met er ) ;
23 }
24 }
25 cl ass Ci r c l e extends Shape {
26 protected i nt x , y ;
27 double r adi us ;
28 public Ci r c l e ( i nt i ni t Per i met er , i nt x , i nt y) {
29 thi s . x = x ;
30 thi s . y = y ;
31 per i met er = i ni t Pe r i me t e r ;
32 r adi us = i ni t Pe r i me t e r /(2Math . PI ) ;
33 }
34 public void draw( ) {
35 System . out . pr i nt l n ( "Desenhando Ci r c l e com peri metr o " + per i met er ) ;
36 }
37 }
38 cl ass Frame {
39 Shape shapeObj ;
40 public void drawFrame ( ) {
41 i f ( shapeObj . get Per i met er ( ) >10)
42 shapeObj . t r i p l e ( ) ;
43 shapeObj . draw( ) ;
44 }
45 public Shape setShapeObj ( i nt shape , i nt peri meter , i nt x , i nt y) {
46 i f ( shape == 1)
47 shapeObj = new Square ( peri meter , x , y) ;
48 el se
49 shapeObj = new Ci r c l e ( peri meter , x , y) ;
50 return shapeObj ;
51 }
52 }
53 cl ass Teste {
54 public stati c void main( St r i ng [ ] ar gs ) {
55 Frame frameObj = new Frame ( ) ;
56 i nt shape = I nt e ge r . par s e I nt ( ar gs [ 0 ] ) ;
57 i nt per i met er = I nt e ge r . par s e I nt ( ar gs [ 1 ] ) ;
58 i nt x = I nt e ge r . par s e I nt ( ar gs [ 2 ] ) ;
59 i nt y = I nt e ge r . par s e I nt ( ar gs [ 3 ] ) ;
60 frameObj . setShapeObj ( shape , peri meter , x , y) ;
61 frameObj . drawFrame ( ) ;
62 }
63 }
Listagem 2.1: Exemplo de programa Java
Para aplicar os critrios, devemos primeiramente obter as denies e usos dos objetos. Pegando
como exemplo o objeto shapeObj do cdigo em questo (Listagem 2.1), por meio de uma simples
anlise do cdigo ( i.e., sem a necessidade da construo do OCFG) obtemos estes dados. Na Tabela
2.1, as linhas onde ocorrem as denies e usos de shapeObj so apresentadas.
Tabela 2.1: Denies e usos do objeto shapeObj do exemplo
Objeto Denio Uso
shapeObj 42, 47, 49 41, 42, 43
Para selecionarmos os casos de testes baseados nestes critrios, o segundo passo analisar o
uxo de objetos, identicando as ocorrncias de bindings e pares du. A Tabela 2.2 apresenta os
pares du que devem ser exercitados para atender aos critrios de uxo de objetos.
Tabela 2.2: Critrios e pares du
Critrio Pares du
All-bindings (42,41), (42,43), (47,41), (47,42), (47,43), (49,41), (49,42), (49,43)
All-du-pairs (42,41), (42,43), (47,41), (47,42), (47,43), (49,41), (49,42), (49,43)
CRITRIOS DE TESTE PARA O COMPORTAMENTO EXCEPCIONAL DE PROGRAMAS 17
Neste caso em particular, os pares du a serem exercitados em ambos os critrios coincidiram.
Entretanto, h casos em que o critrio all-bindings pode exigir mais pares, como no caso de um
comando utilizar mais de um objeto. Nesta situao, necessrio exercitar todas as possveis com-
binaes adicionais exigidas por este critrio. Para exemplicar, suponha que temos no cdigo da
Listagem 2.1 a seguinte linha:
System . out . pr i nt l n ( "Soma dos per met r os = " + shape1 . get Per i met er ( ) + shape2 .
get per i met er ( ) ) ;
Para aplicar o critrio all-bindings, seria necessrio testar o comando utilizando dois objetos
Circle, dois objetos Square e a combinao entre um Square e um Circle.
2.8 Critrios de Teste para o Comportamento Excepcional de Pro-
gramas
Atualmente, para a anlise de um programa ser completa, ela deve levar em considerao os
mecanismos para tratamento de excees. Estes mecanismos, existentes em linguagens como Java
e C++, passaram a ser utilizados em grande parte dos programas existentes [SH98] e, por isso,
se no forem considerados durante a anlise e teste estrutural de programas baseados em uxo,
os percentuais de cobertura que informam o quanto do conjunto de uxo de controle ou dados do
programa foram cobertos pelo test suite podem estar incorretos.
Harrold e Sinha [SH99] apresentam critrios de teste baseados em uxo de dados, onde denem
conceitos de denio e uso para excees. Alm disso, eles apresentam uma tcnica para anlise
de uxo de excees [SH98] para programas Java, que facilita a identicao das denies e uso
para aplicao dos critrios.
A seguir vamos apresentar estes critrios de teste. Para isso, preciso conhecer um pouco
melhor a estrutura de excees da linguagem Java, que utilizada nas tcnicas de anlise de uxos
de excees.
2.8.1 Estrutura de excees em Java
As excees [Eck02, Gak07, Suna, Xav08] so estruturas utilizadas para descrever e tratar uma
situao anormal (evento excepcional) que ocorre durante a execuo de um programa. No momento
em que ocorre uma exceo, o uxo de execuo do aplicativo transferido do local onde surgiu a
exceo (lanamento da exceo) at um ponto que pode ser denido pelo programador (captura
da exceo) [GJSB05b], para que ela possa ser tratada. Esse tratamento consiste, em geral, num
conjunto de instrues que permite ao programa recuperar-se da situao excepcional.
Cdigos que permitem a recuperao do sistema na ocorrncia de excees so bastante fre-
quentes, sobretudo em linguagens como Java, que possuem estruturas especcas para isso [SH98].
Isto pode ser explicado devido ao fato da utilizao correta e consciente destes mecanismos fazer
com que o programa seja mais robusto e tolerante a falhas, o que essencial no mundo atual.
Mecanismos para Tratamento de Excees em Java
Em Java, h quatro elementos principais utilizados para tratar excees: try, catch, throw e
nally. Sua sintaxe para utilizao apresentada a seguir.
1 try {
2 // bl oco de cdi go com oc or r nc i a de exceo .
3 }
4 catch ( Excepti onType1 e1 ) {
5 // tratamento da exceo do t i po Excepti onType1 .
6 }
7 catch ( Excepti onType2 e2 ) {
8 // tratamento da exceo do t i po Excepti onType2 .
9 }
10 catch ( Excepti on e3 ) {
11 // tratamento de todos os t i pos de exceo .
12 }
13 f i nal l y {
14 // cdi go executado ao f i n a l do bl oco t r y
15 // ou ao f i n a l da s equnci a de bl ocos trycatch ,
16 // i ndependentemente da oc or r nc i a de excees em t r y .
17 }
Listagem 2.2: Sintaxe da construo de tratamento de excees em Java [SH98].
Try dene um bloco de cdigo em que uma ocorrncia excepcional pode acontecer. Este bloco
pode conter um comando throw, e vir acompanhado de um conjunto de blocos denidos pelo
elemento catch e de um bloco denido por nally.
Throw utilizado para lanar uma exceo de forma explcita. Catch, por sua vez, um
elemento que recebe como parmetro um nico tipo de exceo e dene um bloco que a trata.
Esta exceo , em geral, lanada dentro de um bloco try, que pode estar no mesmo mtodo
ou no do bloco catch.
O bloco denido por nally opcional, e caso exista, o ltimo elemento da sequncia de
blocos try-catch ou vem logo aps um bloco try. O cdigo descrito nele (em geral, realizando
liberao de recursos adquiridos no bloco try correspondente) executado obrigatoriamente,
independentemente da execuo do programa ter tido uma ocorrncia excepcional ou no. No
caso do bloco try ser nalizado com um comando de transferncia de controle (return, break
ou continue), o bloco nally (se houver algum) sempre ser executado.
Alm dos quatro elementos para tratamento de exceo descritos acima, Java dene uma
instruo throws que deve ser utilizada na declarao de um mtodo quando este pode lanar
excees para o cdigo invocador (excees implcitas). Esta instruo no considerada
na denio dos critrios, mas importante para a denio das propriedades baseadas em
excees implementadas no Java PathFinder Exceptions [Xav08].
2.8.2 Termos utilizados
Aqui, apresentamos algumas denies de termos a serem utilizados no critrio de teste. Para
exemplic-los, usamos o cdigo Java presente na Listagem 2.3.
Tipo de Exceo: Classe da exceo. No exemplo, temos a classe Exception.
Objeto de Exceo: Instncia de uma classe de exceo. Representamos por eobj
i
, onde i
representa a linha onde o objeto foi instanciado. No exemplo, temos um objeto de exceo
instanciado na linha 11, e o representamos por eobj
11
.
Varivel de Exceo: varivel cujo tipo um tipo de Exceo. No exemplo, temos a varivel
e.
Varivel temporria de exceo: varivel de exceo associada a alguma clusula throw.
Representamos a varivel por evar
i
, onde i representa a linha do respectivo throw. No exemplos
temos uma varivel temporria de exceo denida pelo comando throw na linha 11 (evar
11
).
Objeto de exceo ativo: objeto de exceo lanado atravs de uma clusula throw.
Em qualquer instante s pode existir um nico objeto de exceo ativo. Representado por
evar
active
. Em cada instante do programa esta varivel pode ter o valor null, quando no
existir nenhuma exceo no tratada, ou algum objeto eobj
i
. No exemplo, o objeto de exceo
inicializado na linha 11.
CRITRIOS DE TESTE PARA O COMPORTAMENTO EXCEPCIONAL DE PROGRAMAS 19
2.8.3 Denio e uso de excees
Harrold e Sinha [SH99] estabeleceram os seguintes conceitos para denio e uso de excees:
Excees so denidas nas seguintes condies:
1. Um valor associado a uma varivel de exceo.
Ex: Exception e = new Exception();
2. Em um n catch um valor associado a uma varivel de exceo e evar
active
associado a
null.
Ex: catch(Exception e)
3. Em um n throw que utiliza uma varivel temporria de exceo evar.
Ex: throw new Exception();
4. Em um n throw feita uma associao a evar
active
.
Ex: throw new Exception(); ou throw e;
Excees so utilizadas nas seguintes condies:
1. O valor de uma varivel de exceo acessado.
Ex: System.out.println(e);
2. Em um n catch o valor de evar
active
acessado.
Ex: catch(Exception e)
3. Em um n throw com uma varivel temporria de exceo.
Ex: throw new Exception();
Um conjunto denio-uso para uma exceo (e-du) uma tripla ( v, i, j ), onde tem-se
i a linha de denio da varivel v, e j a de seu uso.
Para o exemplo da Listagem 2.3 temos as seguintes triplas e-du:
(e, 4, 5)
(evar
11
, 11 , 11)
(evar
active
, 11 , 4 )
(evar
11
e, 11, 5)
2.8.4 Ativao e desativao de excees
Alm das denies e usos, excees apresentam um outro conceito associado a ativao e
desativao [SH99], ou seja, quando um objeto de exceo associado ou desassociado a evar
active
.
Uma clusula throw ativa uma exceo e uma clusula catch desativa uma exceo. Alm disso,
uma exceo pode ser desativada dentro de uma clusula nally com o uso de return, break, continue
ou outra clusula throw.
Um conjunto ativao-desativao para uma exceo ( e-ad ) uma tripla ( v, i, j ) onde tem-se
i a linha de ativao do objeto v, e j a de sua desativao.
Para o exemplo do item anterior temos a seguintes tripla e-ad:
(eobj
11
, 11, 4)
2.8.5 Critrios de Teste
Os critrios de teste exigem que sejam realizadas operaes com dados sobre o programa de
forma a exercitar os conjuntos denio-uso e ativao-desativao. Ou seja, devem ser gerados
casos de teste com dados que percorram as triplas denidas anteriormente.
A seguir, descrevemos os critrios denidos por Sinha e Harrold [SH99] que exercitam esses
conjuntos denio-uso e ativao-desativao de excees em programas Java:
all-throw: devemos varrer todos os ns throw.
all-catch: devemos varrer todos os ns catch.
all-e-defs: devemos varrer os caminhos de programa de forma a cobrir todas as denies
de excees e pelo menos um uso de cada uma.
all-e-use: devemos varrer todas as triplas denio-uso das excees.
all-e-act: devemos varrer os caminhos de programa de forma a cobrir todas as ativaes de
excees e pelo menos uma desativao de cada uma. anlogo ao critrio all-e-defs, trocando
as denies e usos por ativaes e desativaes.
all-e-deact: devemos varrer todas as triplas ativao-desativao das excees.
2.8.6 Grafo de Fluxo de Controle para Mecanismos de Tratamento de Exceo
Como dito em sees anteriores (ver Sees 2.6.2 e 2.7), a criao de um grafo de uxo de
controle interessante para a identicao das denies e usos de objetos, principalmente para
programas maiores, em que se torna muito difcil tal identicao por meio da anlise direta do
cdigo fonte. O mesmo vale para os mecanismos de tratamento de exceo: a gerao de um grafo que
represente adequadamente o uxo de propagao e tratamento das excees um grande facilitador
no momento dos testes.
Chen e Kao [CK99] descreveram o grafo de uxo de objetos (OCFG), sucintamente descrito
na Seo 2.7. Sinha e Harrold [SH98] propuseram um grafo de uxo de controle semelhante para
programas Java, mas com a capacidade de representar o uxo das excees apropriadamente.
Para representar o uxo excepcional no OCFG, adaptamos a tcnica apresentada por Sinha e
Harrold [SH98], e adotamos os seguintes passos:
1. Blocos try so iniciados por um n contendo apenas o comando try. Os demais ns do bloco
so representados conforme o uxo normal/excepcional do programa.
2. Para cada n do OCFG em cuja instruo ocorre um lanamento de exceo (throw), uma
aresta de sada gerada.
3. Caso a exceo seja capturada por uma clusula catch no mesmo mtodo, esta aresta ser
cheia e ser conectada ao n correspondente; caso a captura ocorra num mtodo distinto, a
aresta a ser conectada ao n correspondente ser tracejada.
4. Blocos nally so tratados como se fossem mtodos, possuindo ns de entrada e sada.
2.8.7 Exemplo
Na Listagem 2.3 encontra-se um exemplo simples com um trecho de cdigo que inclui o uso de
todas as instrues de tratamento de excees em Java ilustrado. Este cdigo ser utilizado para
exemplicar a aplicao dos critrios de teste mencionados nesta seo.
FERRAMENTAS PARA TESTES 21
2 try {
3 m1( ) ;
4 } catch ( Excepti on e ) {
5 System . out . pr i nt l n ( e ) ;
6 }
7 }
8 public stati c void m1( ) throws Excepti on{
9 try {
10 i f (new Random( ) . next I nt ( 10) > 5)
11 throw new Excepti on ( ) ;
12 el se System . out . pr i nt l n ( "Mensagem bl oco t r y " ) ;
13 } f i nal l y {
14 System . out . pr i nt l n ( "Mensagem bl oco f i n a l l y " ) ;
15 }
16 }
17 }
Listagem 2.3: Cdigo Java com tratamento de erros extrado de [Xav08]
Neste exemplo temos uma chamada(linha 3) a um mtodo denominado m1 feita dentro de um
bloco protegido de cdigo (bloco delimitado por uma instruo try). Este mtodo declara que pode
lanar uma exceo (linha 8) por meio da instruo throws. Para captura desta exceo temos o
bloco catch que vai da linha 4 linha 6.
Dentro do mtodo m1 temos a gerao de um nmero aleatrio entre 0 e 10, que pode gerar o
lanamento de uma exceo (linha 11), caso seja maior do que 5. Alm disso, temos um bloco de
execuo incondicional delimitado pela instruo nally (linhas 13 a 15).
Para ilustrar a aplicao dos critrios de testes para os mecanismos de tratamento de excees,
apresentamos as Tabelas 2.3 e 2.4. Elas denem as triplas a serem percorridas para cada um dos
critrios de teste, com base no exemplo de cdigo da Listagem 2.3.
Tabela 2.3: Critrios baseados em denio-uso
critrio tripla e-du
all-throw (evar
11
, 11 , 11)
all-catch (e, 4, 5)
all-e-defs (e, 4, 5), (evar
11
, 11 , 11), (evar
active
, 11 , 4 )
all-e-use (e, 4, 5), (evar
11
, 11 , 11), (evar
active
, 11 , 4 ), (evar
11
e, 11, 5)
Tabela 2.4: Critrios baseados em ativao-desativao
critrio tripla e-ad
all-e-act (eobj
11
, 11, 4)
all-e-deact (eobj
11
, 11, 4)
2.9 Ferramentas para Testes
A automao de algumas etapas das atividades de testes se fazem necessrias para que este
processo seja vivel na prtica de desenvolvimento de software, como foi dito na Seo 2.3. Esta
automao se faz ainda mais necessria no caso dos testes white-box, em que a construo de grafos
de uxo de controle e da consequente anlise do cdigo implementado, consistem em tarefas bastante
complexas e demoradas quando estas devem ser aplicadas a programas de maior porte.
Por serem os testes estruturais (sobretudo os que consideram critrios de controle de uxo apli-
cados a programas Java) um dos focos principais deste trabalho, descrevemos a seguir ferramentas
que existem atualmente para a automao destes testes em software. Elas so separadas em duas
categorias: ferramentas para anlise da cobertura de cdigo e ferramentas para gerao de requisitos
de teste.
2.9.1 Ferramentas para Cobertura de Cdigo
A cobertura de cdigo uma abordagem baseada nos testes estruturais, e consiste em analisar
a quantidade de cdigo coberto pelos testes. Quanto maior a cobertura, maior a probabilidade
de se encontrar erros e corrigi-los. E consequentemente, maior a conana construda no cdigo
implementado, uma vez que todos os testes sejam executados e no encontrem erros no programa.
A seguir, apresentamos algumas ferramentas utilizadas para automatizar a anlise da cobertura
de cdigo de programa Java. Em geral, elas fazem este levantamento considerando os testes unitrios
feitos com o auxlio do framework JUnit
4
[JUn].
EMMA/EclEmma [EMM]: um kit de ferramentas escrito em Java para a medio de
cobertura de cdigo Java. Pode ser usado tanto em cdigos de pequeno porte, quanto cdigos
de grande porte. Suas principais funcionalidades so:
Instrumentao do bytecode do cdigo para anlise de cobertura dos testes. A instru-
mentao pode ser desde arquivos .class individuais at um arquivo .jar completo;
Apresentao da cobertura de cdigo de classe, mtodo, linha e blocos, feita por meio da
anlise da execuo de um conjunto de testes unitrios, em geral escritos e executados
com o auxlio do JUnit. A vericao do EMMA detecta inclusive a cobertura parcial de
uma nica linha de cdigo;
As estatsticas de cobertura so agregadas nos nveis de mtodo, classes, pacotes e todas
as classes;
Os resultados da cobertura podem ser exportados nos seguintes tipos de relatrio: texto,
HTML ou XML;
A execuo do EMMA no sobrecarrega o sistema, e apresenta os resultados com bastante
rapidez.
Para um uso integrado com a IDE Eclipse [Eclb], foi desenvolvido o plugin EclEmma [Ecla],
que possui basicamente as mesmas propriedades do EMMA.
Coverlipse [Cov]: um plugin da IDE Eclipse, em que os resultados de cobertura so dados
diretamente aps a execuo dos testes com o JUnit. Suas funcionalidades so:
Visualizao da cobertura de cdigo dos testes JUnit por meio dos critrios de blocos de
instrues , e todos os usos;
Apenas uma nica execuo necessria para a avaliao de todos os critrios de cober-
tura;
Fcil adio/remoo de pacotes do teste;
O feedback se d diretamente no editor da IDE, junto com uma explicao dos resultados
obtidos sob um ponto de vista especializado;
No necessrio aprender novos mtodos de congurao para a utilizao do plugin.
Basta congur-lo do mesmo modo que o JUnit para sua execuo normal na IDE Eclipse.
4
O framework JUnit utilizado para auxiliar a escrita de testes unitrios em programas Java, e executar o test
suite escrito. Ele amplamente usado pelos desenvolvedores Java, e os testes unitrios escritos com ele so focados
na vericao das funcionalidades implementadas no cdigo do programa ( i.e., nenhum critrio mais especco e
rigoroso adotado, como no caso dos testes estruturais.)
FERRAMENTAS PARA TESTES 23
CodeCover [Cod]: uma ferramenta tambm integrada IDE Eclipse. Suas funcionalidades
so:
Visualizao dos critrios de cobertura: por instruo, por ramicao, por lao e por
deciso;
Faz a instrumentao do cdigo de modo a obter uma medio mais precisa das estats-
ticas de cobertura;
Gerao de relatrio customizvel no formato HTML e CSV;
Medida de cobertura por caso de teste;
Integrao com o JUnit para reconhecimento automtico dos casos de teste.
2.9.2 Ferramentas para Gerao de Requisitos de Teste
Requisitos de teste compreendem os dados que devem ser exercitados por meio de testes, de
maneira que critrios de teste sejam satisfeitos. Dentre os critrios de teste, podemos citar o de
uxo de objetos e os que englobam tratamento de exceo (ver Sees 2.7 e 2.8 respectivamente).
A seguir, descrevemos algumas ferramentas disponveis para automao de testes estruturais que
possuem, como uma de suas funcionalidades, a gerao de requisitos para determinados critrios de
teste.
POKE-TOOL (Potential Uses Criteria Tool for Program Testing) [Cha91, MCJ89,
DMJ07]: uma ferramenta desenvolvida na FEEC-Unicamp para apoio ao teste de programas
nas linguagens C, Fortran e COBOL. Suas funcionalidades so:
Instrumentao do cdigo recebido, viabilizando o rastreamento do caminho de execuo
dos testes e uma posterior avaliao da adequao de um dado conjunto de teste;
Gerao dos requisitos de teste (ns, arestas, caminhos ou pares du), feitos de acordo com
o critrio que o usurio deseja testar. Dentre os critrios disponveis, esto: todos-ns,
todas-arestas e os critrios da famlia Potenciais-Usos
5
(todos-potenciais-usos, todos-
potenciais-usos/du e todos-potenciais-du-caminhos), aplicados por meio de uma interface
grca. Por linha de comando, alguns dos critrios de Rapps e Weyuker [RW82, RW85]
para teste de uxo de dados esto disponveis, como os critrios todos-usos (em que so
considerados todos os usos de variveis), todos-c-usos (em que so considerados todos os
usos computacionais de variveis), e todos-usos (em que so considerados todos os usos
predicativos de variveis).
Execuo e avaliao de casos de teste de acordo com o critrio selecionado. O resul-
tado da avaliao o conjunto de elementos requeridos que restam ser executados para
satisfazer o critrio e o percentual de cobertura obtido pelo conjunto de teste. Tambm
so fornecidos o conjunto de elementos que foram executados, as entradas e sadas, bem
como os caminhos percorridos pelos casos de teste. O processo de execuo/avaliao
deve continuar ate que todos os elementos restantes tenham sido satisfeitos, executados
ou detectada a sua no executabilidade.
DaTeC (Data-ow Testing of Classes) [DGP09, DGP08]: um prottipo construdo
para auxiliar o teste de uxo de dados de programas Java, por meio da instrumentao de
seu bytecode. Desenvolvido em conjunto pela Universidade de Milo Bicocca e Universidade
de Lugano, suas principais funcionalidades so:
5
O critrio Potenciais-Usos [Mal91], distingue-se dos critrios de uxo de dados por considerarem os chamados
potenciais usos de variveis, que so ns nos quais possvel chegar por meio de um caminho livre de redenio a
partir de um n de denio de uma varivel, independente de haver uma referncia explcita a um uso desta varivel.
Instrumentao do bytecode Java para identicao das associaes de denio-uso con-
textuais. O conceito de associaes de denio-uso contextuais apresentado por Souter
e Pollock [SP03], e consiste em encontrar o contexto de cada denio e uso do objeto e
formar os pares du correspondentes;
Apresentao dos dados de cobertura do uxo de dados contextual, mostrando desde
todas as associaes cobertas e no cobertas, at um resumo dos pares cobertos para
classes selecionadas pelo usurio.
JaBUTi (Java Bytecode Understanding and Testing) [VMWD05, DMJ07]: uma ferra-
menta desenvolvida no ICMC-USP, que utiliza a anlise de bytecode Java para gerar requisitos
para testes estruturais intra mtodos (que focam na deteco de erros dentro de cada mtodo
individualmente) que utilizam critrios de uxo de controle de dados. Suas funcionalidades
so:
Anlise do bytecode para gerao de requisitos de teste para os critrios: todos-ns, todas-
arestas, todos-usos e todos-potenciais-usos;
Gerao de um grafo de uxo de dados para cada mtodo do cdigo;
Uso de um test driver para instrumentao das classes e carregamento e execuo do
programa instrumentado;
Visualizao da cobertura, para cada mtodo, dos testes executados;
Gerao de estatsticas de cobertura e mtricas de qualidade dos testes executados.
OConGraX (Object Control-Flow Graph with Exceptions) [HM07, NHdM09]: uma
ferramenta desenvolvida no IME-USP, escrita em Java para programas Java. Suas funciona-
lidades so:
Identicao das denies, usos e pares du de objetos e excees (requisitos para os
critrios de uxo de objetos de Chen e Kao [CK99], e para os critrios que envolvem os
mecanismos para tratamento de excees Java de Sinha e Harrold [SH99]);
Armazenamento num arquivo XML com as informaes de denies, usos e pares du
de objetos e excees;
Gerao do OCFG com informaes adicionais sobre os mecanismos de tratamento de
excees utilizados;
Gerao de um arquivo de imagem contendo o OCFG com as informaes de mecanismos
de tratamento de excees.
2.9.3 Justicativa da Escolha da OConGraX
Dentre as ferramentas descritas para testes, a OConGraX foi a escolhida para este trabalho.
Ela se diferencia das demais por satisfazer os seguintes itens:
Utilizao de critrios especcos para gerao de dados a serem utilizados: a
implementao da gerao de requisitos de teste foi baseada em critrios especcos para
testes estruturais, oferecendo um nvel mais formal de seleo de casos de teste em comparao
s ferramentas de cobertura que fazem uso do framework JUnit, no qual os testes unitrios
escritos so testes funcionais e que no seguem necessariamente um critrio.
Gerao de requisitos considerando o critrio de uxo de objetos: na OConGraX,
as denies, usos e pares du so obtidos por meio da anlise do cdigo e do OCFG gerado,
levando em conta o uxo dos objetos no programa para a posterior aplicao dos critrios
apresentados por Chen e Kao [CK99]. Isto a difere, por exemplo, da JaBUTi, na qual os
requisitos de teste so gerados levando em considerao o uxo de variveis.
CONCLUSO 25
Gerao de requisitos considerando o comportamento excepcional dos programas:
um dos principais diferenciais da OConGraX a gerao de requisitos de teste considerando
no apenas o uxo dos objetos e o comportamento normal do programa, mas tambm consi-
derando o uxo das excees e o comportamento excepcional deles [SH98, SH99]. A gerao
de requisitos levando em conta as excees uma funcionalidade pouco oferecida pelas fer-
ramentas existentes. O prottipo DaTeC, apesar de oferecer requisitos e dados de cobertura
baseados no conceito novo de associaes denio-uso contextuais, no estende esta funcio-
nalidade para excees.
Linguagem Java: o cdigo analisado pela OConGraX est escrito na linguagem Java, lingua-
gem esta que usa o paradigma OO e possui estruturas adequadas para tratamento de excees.
Estas duas caractersticas so essenciais para a proposta deste trabalho, o que torna a OCon-
GraX a melhor escolha para ferramenta de teste. A POKE-TOOL no serviria para este m,
uma vez que ela voltada para teste de programas escritos em linguagens imperativas, como
C.
Uma descrio mais minuciosa da ferramenta OConGraX e suas funcionalidades dada no
Captulo 6 deste documento.
2.10 Concluso
Neste captulo, abordamos o conceito e a importncia dos testes, elemento importante da abor-
dagem de validao e vericao. Mostramos suas fases e as estratgias existentes para este m, as
tcnicas para projetar casos de teste e os critrios de teste. Entender o processo de teste de soft-
ware essencial para este projeto, uma vez que um dos objetivos principais deste trabalho o de
validar cdigo Java por meio desse processo, utilizando a ferramenta escolhida para esta nalidade,
a OConGraX [HM07, NHdM09], conforme visto na Seo 2.9.3.
No prximo captulo, apresentamos o conceito complementar ao de testes, utilizado na aborda-
gem V&V: o da vericao de programas.
Captulo 3
Vericao de Programas
Neste captulo apresentamos a teoria relacionada vericao de programas utilizada neste
trabalho. Os seguintes tpicos tericos so abordados aqui:
o conceito de vericao de programas;
as etapas do processo de vericao de um software;
as tcnicas para a realizao da vericao de programas.
Finalizando o captulo, uma descrio de alguns dos vericadores existentes para automao
desta atividade feita.
3.1 Conceito de Vericao de Programas
Como visto no Captulo 2, testes so bons instrumentos para detectar erros e, portanto, cons-
tituem um processo importante para construir a conana de um programa, tanto para os desen-
volvedores quanto para os clientes nais. Entretanto, eles no so capazes de demonstrar que um
software est completamente livre de erros: apesar de todo esforo para se construir e selecionar
casos de teste que cubram todas as funcionalidades e cdigo do programa, pode haver algum bug
que tenha escapado ao processo. Isto ocorre porque os testes no so capazes de demonstrar a
ausncia de erros no software [Dij70], o que pode ser tornar um problema grave no caso de sistemas
complexos de grande porte e sistemas crticos, uma vez que uma falha nestes sistemas pode ter
efeitos desastrosos (ver Seo 2.2).
Para suprir esta necessidade de demonstrar a corretude de um programa, surgiu o conceito de
vericao de programas. A vericao de programas faz uso de mtodos formais para provar que
um programa foi implementado corretamente.
3.1.1 Mtodos Formais
De acordo com a Enciclopdia de Engenharia de Software [Mar94], mtodos formais podem
ser assim denidos: como tcnicas baseadas matematicamente para a descrio de propriedades do
sistema. Eles provm frameworks nos quais as pessoas podem especicar, desenvolver e vericar
sistemas de uma forma ordenada.
Ainda segundo Marciniak [Mar94], um mtodo formal se ele possui base matemtica, dada
tipicamente por uma linguagem de especicao formal. Esta base prov um meio de denir preci-
samente noes como consistncia, completude, especicao, implementao e corretude.
Para a vericao de programas, estes precisam ser especicados formalmente utilizando meto-
dologias e linguagens formais. Exemplos destes mtodos ou linguagens so Z [WD96], B [Wor96] e
VDM [Jon90] para sistemas sequenciais; para sistemas concorrentes, CCS [Mil89] e CSP [Hoa85]; e
para agentes mveis, -calculus [Mil99].
27
28 VERIFICAO DE PROGRAMAS
A utilizao de mtodos e especicaes formais de programas, alm de serem necessrias para
a realizao de sua vericao, so importantes pois evitam problemas como ambiguidade e con-
tradies, que podem atrapalhar todo o desenvolvimento do software. Ademais, os mtodos formais
podem ser usados no desenvolvimento de software (ex.: abordagem de desenvolvimento de software
cleanroom [Pre01, Som06]), alm de serem altamente recomendados pelas agncias espaciais como
ESA e NASA para o desenvolvimento de sistemas crticos seguros [BK08].
3.1.2 Denio de Vericao
Vericao de programas consiste em conferir se o software est sendo desenvolvido corretamente
[Boe81]. De um modo mais formal, podemos deni-la da seguinte maneira: dada uma especicao
e um programa P, mostrar que P um modelo para a especicao (i.e., P satisfaz ) [Fra92,
MSF06]. Esta vericao tambm conhecida como vericao a posteriori, pois a especicao e
o programa so fornecidos. Nela, devemos ter formas de comparar a especicao com o programa
para que possamos provar que este ltimo um modelo para a especicao [MSF06].
H duas abordagens principais para a realizao da vericao de programas: a de vericao de
modelos tambm conhecida como model checking; e a de sistema de prova de programas. Detalhes
sobre estas abordagens so dadas na Seo 3.3.
3.1.3 Limitaes
A utilizao de mtodos e vericao formais no desenvolvimento de software, apesar de garantir
uma implementao mais segura, enfrenta uma certa resistncia para sua aplicao real na prtica.
Isto ocorre pois muitos consideram esta metodologia demasiadamente complicada e complexa. Alm
disso, ela ainda est sujeita falha humana: a especicao de um programa deve ser feita por
pessoas, e no h como garantir que esta especicao realmente corresponde ao que o software
deve fazer [Fra92].
3.2 Etapas para a Vericao de Programas
Para a realizao da vericao de programas, de um modo geral, preciso seguir algumas
etapas [BK08] (uma viso esquemtica deste processo pode ser visto na Figura 3.1). Estas etapas
so discutidas a seguir:
Figura 3.1: Esquema do processo de vericao de um sistema a posteriori [BK08].
1. Especicao do Sistema: constitui a base para qualquer atividade de vericao, pois
descreve de maneira formal as funcionalidades que devem estar implementadas no programa.
ABORDAGENS PARA A VERIFICAO DE PROGRAMAS 29
Para a realizao desta especicao, devem ser utilizados um dos mtodos ou linguagens
formais disponveis para o tipo de sistema a ser implementado, de modo a descrever o sistema
da forma mais precisa e no ambgua possvel [MSF06].
2. Denio de Propriedades: a partir da especicao, deve-se denir propriedades que o
produto/prottipo desenvolvido precisa satisfazer. Um exemplo de propriedade, seria a no
ocorrncia de deadlocks no sistema.
3. Desenvolvimento do Produto/Prottipo: corresponde ao processo de planejamento e
implementao do produto/prottipo.
4. Vericao do Programa: com o produto/prottipo pronto para execuo, e as proprieda-
des j denidas, feita a vericao propriamente dita. Caso o produto/prottipo no satisfaa
alguma das propriedades de especicao, signica que um erro foi encontrado e, portanto,
o programa no est correto. Para fazer esta vericao, podem ser usados vericadores, que
so ferramentas que automatizam esta etapa.
3.3 Abordagens para a Vericao de Programas
Para fazer a vericao de programas, diversas abordagens e tcnicas foram desenvolvidas ao
longo dos anos. Dentre essas, duas se destacam:
Vericao de modelos (model checking) [BK08]: tcnica baseada em modelos de siste-
mas
1
que explora todos os possveis estados do sistema de maneira exaustiva. O vericador de
modelos (model checker), ferramenta que faz esta abordagem de vericao, examina todos
os possveis cenrios do sistema, de uma maneira sistemtica. Desta forma, pode-se mostrar
que um modelo de sistema realmente satisfaz uma certa propriedade.
Sistema de prova de programas [MSF06]: tcnica na qual a corretude dos programas
vericada por meio da utilizao de um sistema de provas de um dos mtodos ou linguagens
formais utilizadas para a especicao do sistema, como Z [WD96], VDM [Jon90], B [Wor96]
e lgica de Hoare [Hoa69].
A seguir, descrevemos os procedimentos necessrios para a aplicao de cada uma das tc-
nicas. No caso particular da tcnica de sistema de prova de programas, vamos explicar o
procedimento para sua aplicao com a lgica de Hoare.
3.3.1 Sistema de Prova de Programas
De acordo com Melo et al. [MSF06], para aplicar esta tcnica de vericao de programas
precisamos de:
1. Uma especicao escrita em uma linguagem com fundamento matemtico para que seja
precisa e no ambgua;
2. O programa escrito em uma linguagem que tem o signicado de seus comandos denido de
forma precisa semntica formal da linguagem de programao;
3. Uma forma de associar e comparar as asseres da especicao com os comandos do pro-
grama; as linguagens de especicao e programao devem, portanto, ser comparveis;
4. Um sistema de prova que usamos para mostrar que um programa satisfaz uma dada especi-
cao.
1
Os modelos descrevem o possvel comportamento do sistema de uma maneira matematicamente precisa e no-
ambgua, e so acompanhados por algoritmos que sistematicamente exploram todos os estados dos modelos do
sistema, fornecendo assim a base para diversas tcnicas de vericao, dentre as quais a do model checking [BK08].
Aqui, vamos usar para exemplicar esta tcnica a semntica da linguagem e o sistema de provas
associado denidos por meio da lgica de Hoare [Hoa69]. Assim, a associao dos comandos dos
programas com as asseres so feitas por meio das regras deste sistema de provas.
Procedimento para a Prova da Corretude de Programas [MSF06]
Utilizando o sistema de provas da lgica de Hoare [Hoa69], queremos provar a validade da
assero:
Prog
Nesta assero, temos a tripla Prog , tambm conhecida como Tripla de Hoare. Nela,
corresponde s pr-condies, que so propriedades sobre o estado inicial do programa Prog.
J representa as propriedades sobre o estado nal do programa Prog, as ps condies.
Desta maneira, uma interpretao para esta assero dada por correo parcial seria:
Para todo estado que satisfaz , se a execuo de Prog a partir do estado sigma
termina produzindo o estado
, ento
satisfaz .
Para mostrar a validade desta assero, devemos utilizar provas de programas. Estas podem
ser divididas em correo parcial e correo total.
Correo Parcial: a tripla Prog satisfeita sob correo parcial se, para todos
os estados que satisfazem , o estado resultante da execuo do programa Prog satisfaz
a ps-condio , se Prog termina. Neste caso,
par
a relao de satisfazibilidade para
a correo parcial:
par
Prog .
Na prtica, correo parcial um requisito ineciente porque no garante a terminao
do programa: qualquer programa que no termina satisfaz a sua especicao.
Correo Total: a tripla Prog satisfeita sob correo total se, para todos os
estados que satisfazem , o estado resultante da execuo do programa Prog satisfaz a
ps-condio , e Prog termina. Neste caso,
tot
a relao de satisfazibilidade para a
correo parcial:
tot
Prog .
Na correo total, a satisfazibilidade e a terminao do programa devem ser provados,
o que muito interessante na prtica. Desta forma, qualquer problema que entra em
um lao innito de repetio no satisfaz sua especicao sob a relao de correo
total.Ademais, pode-se dividir a tarefa de provar correo total de programas em: provar
correo parcial e provar que o programa termina.
Para provar as triplas de Hoare, que foram denidas considerando o programa como um
todo, sob quaisquer das duas formas de correo, devemos utilizar o sistema de provas. Este
denido sobre cada elemento sinttico da linguagem, e as provas so realizadas usando induo
sobre as estruturas dos programas. Isto , as regras provam a correo de uma assero para
um comando mais complexo, pela prova de correo das asseres de seus sub-comandos.
Assim, h dois elementos no sistema de provas: as regras de inferncia sobre cada um dos
elementos sintticos dos programas e o mecanismo de prova utilizando as regras denidas.
Ambos os elementos no sero descritos neste texto. Maiores informaes sobre eles podero
ser obtidas nos livros de Hoare [Hoa69] e Melo et al. [MSF06].
Correo e Completude do Sistema de Provas [MSF06]
Para provar a correo do sistema de provas, necessria apenas a prova de correo para
cada uma das regras (induo estrutural), j que o sistema composicional. Esta prova pode
ser encontrada no livro de Winskel [Win93].
ABORDAGENS PARA A VERIFICAO DE PROGRAMAS 31
Para provar a completude do sistema de provas, devemos usar um artifcio: a introduo de
asseres de programas como axiomas do sistema, a partir dos quais pode-se fazer uma prova
de completude relativa do sistema de provas. Esta prova pode ser encontrada em no livro de
Francez [Fra92].
3.3.2 Vericao de Modelos (Model Checking)
Model checking uma tcnica automatizada que, dado um modelo de estados nitos de um
sistema e uma propriedade formal, checa sistematicamente se esta propriedade satisfeita para
um dado estado desse modelo. Esta vericao feita utilizando fora-bruta, em que o vericador
varre todos os estados do modelo. Caso a propriedade no seja satisfeita, um contra-exemplo
apresentado, mostrando a localizao da falha.
As propriedades a serem checadas usando esta tcnica so de natureza qualitativa: elas vericam,
entre outras coisas, se os resultados gerados so os esperados e se o sistema no entra em situao de
deadlock. Outras propriedades que podem ser vericadas so as propriedades de tempo, que podem
querer checar, por exemplo, se o tempo de resposta do sistema est dentro do perodo esperado.
Na Figura 3.2 apresentado um esquema geral do processo de vericao de modelos. Este
processo discutido a seguir em maiores detalhes, uma vez que esta a abordagem de vericao
a ser utilizada neste trabalho de Mestrado.
Figura 3.2: Esquema do processo de model checking [BK08]
Procedimento para a Aplicao do Model Checking [BK08]
Para aplicar esta tcnica de vericao, as seguintes fases devem ser realizadas:
Fase de Modelagem:
Modelar o sistema em questo usando a linguagem de descrio do modelo do veri-
cador de modelo a ser utilizado;
Para uma primeira avaliao do modelo, fazer algumas simulaes;
Formalizar a propriedade a ser checada usando a linguagem de especicao de
propriedades.
Fase de Execuo: executar o model checker para vericar a validade da propriedade no
modelo do sistema.
Fase de Anlise:
Se a propriedade foi satisfeita, checar a prxima (se houver);
Se a propriedade foi violada, deve-se:
1. Analisar o contra-exemplo gerado pela simulao;
2. Renar o modelo, design, ou propriedade;
3. Repetir todo o procedimento.
Se a memria for insuciente para a realizao da vericao, tentar reduzir o modelo
e repetir todo o procedimento.
Ademais, toda a vericao deve ser planejada, administrada e organizada.
Vericadores de Modelos
Para trabalhar com vericadores de modelos, algumas abordagens podem ser adotadas [VHB
+
03,
Xav08]:
Traduo: ferramentas que funcionam exclusivamente como vericadores de modelos
possuem linguagem prpria para a descrio destes modelos, de modo que necessria
uma traduo entre a linguagem de programao e a de modelo. Exemplo de ferramenta
que utiliza esta abordagem: SPIN [Hol97, SPI].
Criao de vericadores customizados: permite a criao de seu prprio vericador
de modelo, j adequado s caractersticas da linguagem de programao a ser utilizada.
Esta abordagem usada pela ferramenta Java PathFinder [VHB
+
03, Jav].
Vantagens e Desvantagens da Vericao de Modelos
Como toda abordagem, h prs e contras para sua aplicao [BK08]. Eles devem ser analisados
cuidadosamente para que esta tcnica seja utilizada da melhor maneira possvel, de modo a
obter resultados satisfatrios com sua aplicao.
Listamos agora algumas das vantagens do model checking.
uma abordagem de vericao geral que aplicvel a uma grande variedade de apli-
caes, tais como sistemas embarcados, engenharia de software e design de hardware;
Suporta vericao parcial, i.e., propriedades podem ser checadas individualmente, per-
mitindo assim focar primeiro nas propriedades essenciais. No necessria uma especi-
cao de requisitos completa;
Prov informao de diagnstico no caso da propriedade ser invalidada: isto muito til
para o processo de debugging
2
;
O uso de model checking no requer um alto grau de interao com o usurio e nem um
alto grau de percia;
Goza de um interesse crescente pela indstria;
Pode ser facilmente integrado a ciclos de desenvolvimento existentes;
Tem suporte matemtico: baseado na teoria de algoritmos de grafos, estrutura de dados
e lgica.
Embora as vantagens da vericao de modelos sejam signicativas, deve-se considerar tam-
bm suas desvantagens. Listamos a seguir alguns dos pontos fracos desta tcnica de vericao.
Sua aplicabilidade sujeita a questes de deciso: para sistemas de estados innitos, ou
raciocnio sobre tipos de dados abstratos (que requer lgica indecidvel ou semi-decidvel),
model checking no ecientemente computvel.
2
Debugging o nome que se d ao processo de localizar a causa de um bug no software [Pre01]
FERRAMENTAS PARA VERIFICAO 33
Esta tcnica verica um modelo do sistema, e no o sistema real (produto ou prottipo)
em si; qualquer resultado obtido , portanto, to bom quanto o modelo de sistema.
Tcnicas complementares, como testes, so necessrias para ajudar a encontrar erros de
cdigo;
Verica apenas os requisitos estabelecidos, i.e., no h garantia de completude. A validade
de propriedades que no foram vericadas no podem ser julgadas;
Sofre do problema de exploso de espao de estados, i.e., o nmero de estados necessrios
para modelar o sistema precisamente pode facilmente exceder a quantidade de memria
disponvel no computador. Apesar do desenvolvimento de diversos mtodos efetivos para
combater este problema, modelos de sistemas reais podem ser ainda muito grandes para
caber na memria;
Seu uso requer certa percia em encontrar abstraes apropriadas para obter modelos de
sistemas menores e para estabelecer propriedades no formalismo lgico utilizado;
No garantido que ela render resultados corretos; como com qualquer ferramenta, o
vericador de modelos pode conter defeitos de software, mesmo com testes.
3.4 Ferramentas para Vericao
Automatizar o processo de vericao de programas algo extremamente til e necessrio para
que sua aplicao seja realizada nos mais diversos programas e sistemas em desenvolvimento hoje.
Para isso, vrias ferramentas foram desenvolvidas. No nosso caso, particularmente, nos interessa
as ferramentas que automatizam a vericao de modelos e, por esta razo, descrevemos a seguir
algumas ferramentas usadas para este m.
3.4.1 Ferramentas para Model Checking
Para realizar o model checking, diversos vericadores e ferramentas tm sido desenvolvidos,
de modo a auxiliar na realizao de tarefas como a extrao de modelos de sistema, escrita das
propriedades em linguagem especca, e a realizao da vericao em si. Ademais, eles devem lidar
adequadamente com os problemas desta abordagem, sendo o principal a exploso de estados
3
do
modelo a ser vericado.
Aqui, apresentamos algumas destas ferramentas e vericadores utilizados atualmente para a
aplicao da vericao de modelos, mostrando suas principais caractersticas.
SPIN (Simple Promela INterpreter) [Hol97, SPI]:
Vericador de modelo desenvolvido pela Bell Labs que checa a consistncia lgica de
uma especicao, e pode ser usado para rastrear erros de design em sistemas distribu-
dos, tais como sistemas operacionais, protocolos de comunicao de dados e algoritmos
concorrentes;
O sistema a ser vericado deve estar descrito na linguagem de especicao PRO-
MELA(PROcess MEta LAnguage) [Hol91]; as propriedades, por sua vez, devem ser
especicadas em frmulas LTL (Lgica Temporal Linear) [Pnu77, Lam94, MP92];
A vericao exaustiva feita usando a teoria de reduo de ordem parcial para otimizar
a procura;
Trabalha de maneira on-the-y, o que signica que ele evita a necessidade de se pr-
construir um grafo de estados global como pr-requisito para a vericao das proprie-
dades do sistema.
escalvel, tratando ecientemente problemas de grande porte;
3
Segundo Hatcli e Dwyer [HD01], exploso de estados consiste no crescimento exponencial do tamanho de um
modelo de estados nito medida que o nmero de componentes do sistema cresce.
Oferece suporte ao uso de computadores com mltiplos processadores para execuo da
vericao de modelos.
FeaVer (Feature Verication System) [Fea]:
Vericador de modelo desenvolvido pela Bell Labs, usado vericar propriedades no ser-
vidor de acesso da Lucent
sPathStar
(TM)
[VHB
+
03];
O modelo do sistema extrado do cdigo em C e descrito em PROMELA [Hol91];
a vericao ocorre utilizando uma biblioteca de propriedades especicadas em LTL
[Pnu77, Lam94, MP92];
Para a execuo da vericao, utilizado o SPIN [Hol97, SPI].
Bandera [CDH
+
00, HD01? ]:
Conjunto de ferramentas desenvolvido pelo Laboratrio SAnToS da Universidade do
estado do Kansas para a realizao de model checking em software Java;
Dado o cdigo-fonte de um programa Java, retorna o modelo do programa numa das
linguagens de entrada dos vrios vericadores existentes, como por exemplo a lingua-
gem PROMELA para o vericador SPIN. Bandera tambm realiza o mapeamento do
resultado do vericador para o cdigo-fonte original.
Para fazer o processo de traduo da linguagem de programao para a linguagem do
vericador, so utilizadas diversas tcnicas de otimizao como fatiamento, abstrao de
dados e restrio de componentes;
Permite a adio de novas propriedades. Estas devem ser denidas numa linguagem de
especicao prpria do Bandera, a linguagem BSL [HD01];
Modelos so gerados de acordo com a propriedade a ser testada;
Pode ser utilizada de modo integrado a IDEs Java (ex.: Eclipse), e a outras ferramentas
de vericao de modelos (ex.: Java PathFinder);
Oferece suporte aos elementos introduzidos com Java 5.0 e ao tratamento de excees.
JPF (Java PathFinder) [VHB
+
03, Jav]:
Vericador de modelo desenvolvido pela NASA, que faz uma busca exaustiva de violaes
de propriedades dado um programa Java;
Para fazer a busca exaustiva, o JPF foi implementado de modo a funcionar de forma
semelhante a uma mquina virtual Java (JVM), na qual o bytecode analisado e todos
os caminhos possveis do programa so executados;
As propriedades so implementadas no JPF utilizando a prpria linguagem Java e re-
cursos do prprio cdigo de implementao deste vericador;
facilmente integrvel com outras ferramentas e extensvel, alm de oferecer suporte
aos elementos introduzidos com Java 5.0 e ao tratamento de excees. Um exemplo de
aplicao que estende o JPF a Java PathFinder Exceptions (JPF Exceptions)
[Xav08]: ela checa propriedades de tratamento de exceo num sistema Java utilizando o
JPF, e estas propriedades j esto denidas e implementadas neste vericador. Ademais,
ela gera estatsticas de cobertura relativas aos estados varridos durante a vericao.
3.4.2 Justicativa da Escolha do JPF/JPF Exceptions
Neste trabalho, optamos por trabalhar com o vericador JPF e a ferramenta JPF Exceptions
por eles se diferenciarem das demais pelos seguintes motivos:
CONCLUSO 35
Linguagem Java: neste trabalho de Mestrado, o uso de uma linguagem OO e que possua
mecanismos para tratamento de exceo adequados e bem denidos essencial. Por esta razo,
ferramentas para programas procedimentais, como FeaVer, no foram escolhidos.
Suporte a tratamento de excees: assim como no caso da escolha da ferramenta OCon-
GraX [HM07, NHdM09] (ver Seo 2.9.3), importante que a ferramenta escolhida lide ade-
quadamente com os mecanismos para tratamento de excees, para vericar o comportamento
do programa no caso de ocorrncia de excees durante a execuo de algum de seus mtodos.
E isto feito principalmente pela JPF Exceptions.
Facilidade na especicao de novas propriedades: este um dos pontos mais impor-
tantes que diferenciam a ferramenta e o vericador escolhidos das demais aplicaes: no caso
deles, as propriedades podem ser especicadas utilizando a prpria linguagem Java, sem a
necessidade de aprender linguagens novas e especcas para o vericador, como ocorre no caso
do Bandera e do SPIN.
Uma descrio mais detalhada do vericador JPF e da ferramenta JPF Exceptions dada no
Captulo 6 deste documento.
3.5 Concluso
No presente captulo, apresentamos o conceito, as etapas do processo e as tcnicas da chamada
vericao de programas. Abordamos suas caractersticas principais, bem como mostramos as ferra-
mentas existentes para sua realizao. Da mesma maneira que os testes de software, a vericao de
programas um conceito importante, cujo entendimento de suma importncia para a compreenso
da abordagem de validao e vericao a ser utilizada neste projeto.
Para este trabalho, conforme visto na Seo 3.4.2, a ferramenta escolhida para exercer a funo
de vericao de cdigo Java a JPF Exceptions [Xav08]. Esta ferramenta, junto com a OCon-
GraX [HM07, NHdM09], permitir a construo do ambiente integrado de teste e vericao de
coordenao de componentes tolerantes a falhas, objetivo maior deste trabalho.
No prximo captulo, abordamos o conceito de coordenao de componentes tolerantes a falhas,
que consiste no protocolo a ser testado e vericado no ambiente construdo neste projeto.
Captulo 4
Componentes e Aes Atmicas
Coordenadas
Neste captulo abordada a teoria referente aos componentes tolerantes a falhas e sua coorde-
nao. Os seguintes tpicos so apresentados:
o conceito de DBC e componentes;
tratamento de excees nos componentes e na arquitetura;
o conceito de aes atmicas coordenadas;
uma implementao em Java do modelo de aes atmicas coordenadas.
4.1 Desenvolvimento Baseado em Componentes (DBC)
O DBC constitui, segundo Pressman [Pre01], um processo no qual so obtidos os requisitos do
cliente, e o estilo da arquitetura do sistema escolhido de modo a satisfazer os objetivos do produto
a ser escolhido. Feito isso, os seguintes passos devem ser realizados:
1. Seleo de potenciais componentes para reuso;
2. Qualicao dos componentes para assegurar que eles se acomodam adequadamente arqui-
tetura do sistema;
3. Adaptao dos componentes, caso modicaes precisem ser feitas para integr-los apropria-
damente;
4. Integrao dos componentes para formar sub-sistemas e a aplicao como um todo.
Ademais, componentes personalizados podem ser construdos para satisfazer aspectos do sistema
que no podem ser implementados utilizando os componentes existentes.
4.1.1 Componentes
Na rea da computao, o termo componente possui vrias denies. Para Szyperski [Szy02],
um componente de software denido como uma unidade de composio com interfaces
1
con-
tratualmente
2
denidas e apenas dependncias explcitas de contexto. So implantados de forma
1
Uma interface, segundo Bachmann et al [BBC
+
02] uma fronteira na qual duas entidades independentes
comunicam-se ou interagem entre si. Se a entidade for um componente, a interface especica um ponto especco de
acesso a determinado servio.
2
Um contrato [Mey92, LC02] descreve um conjunto de asseres para a caracterizao precisa do comportamento
de um componente. Ele tambm dene, formalmente, as obrigaes recprocas de cada componente em uma deter-
minada interao.
37
38 COMPONENTES E AES ATMICAS COORDENADAS
independente e esto sujeitos composio por terceiros. De modo semelhante, Souza [DW99] dene
componente como uma parte reutilizvel de software, desenvolvida independentemente e empregada
na construo de unidades maiores, por meio de sua adaptao.
4.1.2 Padres de Componentes
Devido ao potencial impacto da reutilizao de componentes na indstria de software, empresas
tm proposto padres para os componentes de software. Estes padres denem a maneira como
uma aplicao pode acessar objetos reutilizveis [Pre01], e visam a garantir aos desenvolvedores
que os componentes padronizados sejam interoperveis [Som06].
Os exemplos mais importantes destes padres so: OMG/CORBA
3
, Microsoft COM
4
e Sun
JavaBeans Components
5
.
4.2 Sistemas Tolerantes a Falhas
Sistema tolerante a falhas corresponde a um software que incorpora tcnicas para tratar ade-
quadamente as excees que podem ocorrer durante sua execuo [XRR
+
95a]. No caso de sistemas
concorrentes e que utilizam componentes, essencial que este tratamento seja eciente, de modo a
manter as propriedades de concorrncia e o bom funcionamento do software.
A seguir, apresentamos abordagens para o tratamento de excees no componente, e na arqui-
tetura do sistema.
4.2.1 Tratamento de Excees no Componente
Nos componentes tolerantes a falhas que implementam mecanismos internos para o tratamento
de excees, as respostas so divididas em normais e excepcionais. Respostas normais so produzidas
quando o componente realiza corretamente o servio requisitado. Respostas excepcionais (excees)
so aquelas produzidas quando algum evento anormal ocorre durante a execuo do servio.
Desta forma, o processamento do componente tolerante a falhas deve ser particionado em ativi-
dade normal e atividade excepcional, conforme mostra a Figura 4.1. A atividade normal implementa
os servios especicados para o componente, enquanto a atividade excepcional implementa as roti-
nas de tratamento para as excees lanadas. Assim, o tratamento de excees considerado uma
tcnica essencial para a estruturao interna do componente tolerante a falhas porque introduz
uma separao clara entre a execuo normal do cdigo e o tratamento das condies anormais (ou
excepcionais).
Figura 4.1: Componente tolerante a falhas [dMF01]
3
http://www.omg.org
4
http://www.microsoft.com/com
5
http://java.sun.com/beans
AES ATMICAS COORDENADAS (AES CA) 39
As excees dos componentes podem ser classicadas como:
Excees Internas: as excees internas ocorrem quando o componente detecta uma situ-
ao inesperada durante a atividade normal. Aps o lanamento de uma exceo interna, o
prprio componente realiza o seu tratamento, retornando atividade normal logo em seguida.
Excees de Defeito: caso no seja possvel a recuperao da exceo interna, o componente
lana uma exceo de defeito indicando que no foi possvel realizar o servio solicitado. Este
tipo de exceo tambm denominado de exceo externa pois as atividades relacionadas ao
tratamento da mesma so externas ao componente que a lanou.
Excees de Interface: so lanadas por um componente quando ele recebe solicitaes
que no esto em conformidade com sua especicao. Normalmente, este tipo de exceo
provocado por uma falha na combinao entre os componentes na montagem do sistema.
4.2.2 Tratamento de Excees na Arquitetura
Em sistemas complexos, compostos de vrios componentes, necessria uma maneira ordenada
e eciente de lidar com as excees que podem ser lanadas pelo sistema, e com a concorrncia
entre os componentes. Para isso, algumas abordagens foram desenvolvidas:
Transaes [GR92]: aes lgicas que realizam uma sequncia de operaes bsicas em
objetos ou dados compartilhados, muito utilizadas em sistemas de banco de dados. Para pro-
teger os dados compartilhados, as transaes so feitas obedecendo-se s propriedades ACID
(Atomicidade, Consistncia, Isolamento e Durabilidade). Entretanto, seu uso para sistemas
concorrentes limitado, uma vez que apenas um nico processo pode entrar na transao
por vez. Ademais, as transaes lidam, em geral, com falhas no hardware e no com erros de
software, no oferecendo portanto um mecanismo adequado para tratar excees.
Conversaes [Ran75]: as conversaes constituem uma tcnica para realizar recuperao
coordenada num conjunto de processos. Elas provm um suporte efetivo para cooperao entre
aes, tolerncia a falhas e recuperao de erros. Porm, elas no evitam o problema chamado
contrabando de informao (do ingls: information smuggling) [Kim82], o que pode trazer
graves consequncias na realizao da recuperao de erros, por exemplo.
Aes Atmicas Coordenadas (Aes CA) [XRR
+
95a, XRR
+
95b, Rom01, RXR96]:
integra caractersticas de transaes e conversaes sem os problemas enfrentados por ambos,
constituindo assim um modelo poderoso para a coordenao dos mltiplos componentes de
um sistema e para o tratamento de excees no nvel arquitetural.
Para este trabalho de Mestrado, optamos por utilizar o modelo de aes CA para a coordenao
de componentes e tratamento de excees. Alm de no ter as vulnerabilidades de transaes e
conversaes, as aes CA tm boa performance e escalabilidade, sendo usadas na especicao
de sistemas crticos reais, como o controle de trens nas estaes [BRR
+
00], e o sistema de um
dispositivo para administrao de insulina para controle de diabetes [ACP05].
4.3 Aes Atmicas Coordenadas (Aes CA)
O modelo de Aes Atmicas Coordenadas (CA) [XRR
+
95a, XRR
+
95b, Rom01, RXR96] integra
os conceitos de aes atmicas (ou conversaes), transaes ACID (que garantem as proprieda-
des ACID de Atomicidade, Consistncia, Isolamento e Durabilidade) e tratamento concorrente de
excees, visando a coordenar a concorrncia, comunicao e recuperao de erros entre mltiplos
componentes de um sistema.
Cada ao CA constituda por um conjunto de componentes (tambm denominados partici-
pantes) que interagem entre si, de modo cooperativo, para realizar uma atividade. Sua estrutura
tambm conta com objetos externos, que funcionam como repositrios de informao, e que so
compartilhados pelos participantes, ou seja, o acesso aos objetos externos d-se de forma concor-
rente, por meio de transaes ACID.
Na Figura 4.2, podemos ver um esquema de Ao CA que envolve dois componentes e um
objeto externo. Cada componente representado por uma seta horizontal de execuo ao longo do
tempo. O objeto, representado por uma linha horizontal, e o escopo da ao CA delimitado pelo
retngulo.
Figura 4.2: Diagrama de representao de uma ao CA.
A ao CA da Figura 4.2 inicia-se com uma transao no Objeto Externo 1, sendo este incio
representado pela primeira seta vertical direcionada ao objeto. Em seguida, o Componente 1 se
comunica com o Componente 2, conforme indica a seta bidirecional entre estes componentes. Depois,
o Componente 2 efetua uma comunicao com o Objeto Externo 1, representada por uma seta
vertical pontilhada. E, por m, a transao nalizada por meio de um commit, identicado por
uma segunda seta vertical direcionada ao objeto externo.
4.3.1 Aninhamento e Composio
Para manter a exibilidade e escalabilidade em sistemas complexos, as aes CA possuem as
caractersticas de aninhamento e composio. Por aninhamento, entende-se que uma ao CA pode
ter uma ou mais aes CA internas a ela, como pode ser visto na Figura 4.3.
Figura 4.3: Aes CA aninhadas
UMA IMPLEMENTAO DAS AES ATMICAS COORDENADAS 41
Desta ao interna, um sub-conjunto dos componentes da ao externa participam, e o objeto
externo o mesmo utilizado pela ao CA mais externa. Assim que a ao CA aninhada for
concluda, os componentes voltam a participar da ao CA externa.
A composio de aes CA, por sua vez, permite o reuso de uma mesma atividade por vrias
aes CA do sistema. Na composio, uma ao CA precisa que outra ao, cujos participantes e
objetos externos so prprios, seja nalizada para ento prosseguir. Isto pode ver visto na Figura
4.4, em que a ao CA 1 precisa que uma ao CA 2 seja realizada para continuar.
Figura 4.4: Aes CA compostas
4.3.2 Tratamento de Excees
No modelo de aes CA, uma ou vrias excees podem ser lanadas no sistema num dado
instante. Para que elas sejam tratadas adequadamente, de uma maneira eciente e ordenada, alguns
passos devem ser seguidos [Per07, XRR
+
95a]:
1. Identicao da exceo (ou excees) lanada por um dos participantes da ao CA;
2. Os demais participantes da ao CA so informados do lanamento, e tm suas atividades
interrompidas;
3. No caso de mais de uma exceo ter sido lanada, utilizar a rvore de excees proposta por
Campbell e Randell [CR86], na qual elas so combinadas de modo a obter uma nica exceo
que represente todas as excees lanadas. Esta exceo nica ser a exceo tratada pelos
participantes da ao CA;
4. Cada um dos participantes da ao CA executa o tratamento da exceo. Caso este tratamento
seja bem sucedido, as transaes iniciadas nos objetos externos so conrmadas; caso con-
trrio, as transaes so abortadas e desfeitas e, se o sistema no conseguir ser devidamente
recuperado ao estado anterior ao lanamento da exceo (ou excees), ela (ou a exceo
resultante da rvore de excees) propagada ao CA pai.
4.4 Uma Implementao das Aes Atmicas Coordenadas
Para viabilizar a implementao e vericao de propriedades sobre as aes atmicas coorde-
nadas, foi necessrio implementar um protocolo de coordenao excepcional de componentes. Desta
forma, optamos por implementar, em Java, o modelo de coordenao segundo as aes CA, especi-
cado formalmente na Tese de Doutorado de Pereira [Per07] e no artigo de Pereira e Melo [PdM10].
A especicao completa em CSPm encontra-se no Apndice A.
A escolha de implementar, em Java, tal modelo de coordenao de componentes segundo as
aes CA foi feita aps considerarmos a utilizao de outras alternativas de implementao para a
coordenao de componentes. Estas alternativas, que descrevemos a seguir, mostraram-se inviveis
para o propsito deste trabalho, sobretudo no que diz respeito implementao das propriedades
de coordenao excepcional de componentes.
Utilizao de Java EE/EJB: pelo fato de Java EE ser a plataforma de programao uti-
lizada para implementao de software corporativo e de componentes, sua utilizao para
a implementao do protocolo de coordenao excepcional de componentes foi considerada
inicialmente.
Problemas encontrados: o principal problema encontrado, e que resultou na sua no utili-
zao, foi a incompatibilidade de uso desta plataforma com o vericador escolhido para este
trabalho, o Java Pathnder [Jav]. Este vericador compatvel com a plataforma Java SE
6
,
e utilizamos, portanto, esta plataforma para o desenvolvimento do trabalho.
Utilizao do JPA: a JPA, ou Java Persistence API
7
, bastante usada para a implemen-
tao de transaes entre o programa e um ou mais objetos externos (e.g.: banco de dados),
tanto em Java EE, quanto em Java SE.
Problemas encontrados: a utilizao da JPA no foi possvel pois ela no permite o ani-
nhamento de transaes [KS06]. Isto ocorre porque ela restringe a chamada do mtodo que
inicia a transao, de forma que uma nova chamada a esse mtodo s seja possvel caso a
chamada anterior tenha sido nalizada. Para a implementao das propriedades do modelo
de coordenao segundo as aes CA, esta restrio limita por demais a utilizao das aes
CA de modo escalvel e exvel, conforme apresentado na Seo 4.3.1. Por isso, optamos por
no utilizar a JPA e fazer uma implementao prpria de transaes que permitam o seu
aninhamento.
Com tais alternativas mostrando-se inviveis, foi necessrio escolher e implementar, em Java
SE, um modelo adequado de aes atmicas coordenadas. A especicao em CSP/CSPm [Per07,
PdM10] mostrou-se adequada ao propsito deste trabalho por estar denida em linguagem formal
e conter um modelo genrico com todos os processos e eventos necessrios para a implementao
do protocolo de coordenao excepcional de componentes, considerando as aes CA aninhadas.
Assim como no modelo original, a implementao do modelo em questo pode ser instanciada para
sistemas especcos de forma que teremos a implementao de um modelo-base de coordenao do
comportamento excepcional dos componentes.
4.4.1 Arquitetura do Modelo
Para a implementao do modelo em Java, simplicamos a ideia de componente: agora, os
componentes passam a ser objetos pertencentes a uma determinada classe. Desta forma, o modelo
consiste em coordenar estes objetos conforme o conceito de aes CA.
Seguindo e adaptando a especicao [Per07, PdM10] em CSP, a arquitetura do modelo imple-
mentado consiste em trs classes principais: CoordinatedAtomicAction, Coordinator e Participant.
Para a comunicao com o objeto externo, foi criada uma interface Transaction, cujos mtodos
devem ser implementados para a utilizao deste modelo. Analogamente, foi criada a interface Ex-
ceptionTree, cujo mtodo de resoluo de rvore de exceo, usado no tratamento das excees de
uma ao CA, deve ser denido pelo usurio de acordo com as excees a serem lanadas por seu
6
Neste trabalho, para efeito de simplicao, chamamos a plataforma Java SE apenas de Java.
7
API a abreviatura de Application Programming Interface (ou Interface de Programao de Aplicaes)
sistema. As classes Role e Handler implementam, respectivamente, o comportamento normal/lan-
amento de excees e o tratamento de excees lanadas. Na Figura 4.5 apresentado um esquema
com a comunicao entre estas classes.
Figura 4.5: Esquema de arquitetura do modelo implementado.
Nas prximas sees, detalhamos os mtodos implementados e sua correlao com os processos
especicados em CSP.
4.4.2 CoordinatedAtomicAction
Esta classe representa uma ao atmica coordenada, possuindo em seus campos os elementos
que a constituem:
//nmero que i d e n t i f i c a a ao CA.
// obr i gat or i ament e , a pr i mei r a ao CA deve t e r i ndex = 0.
private i nt i ndex ;
// coordenador r e s pons ve l por todo o pr oces s o de coordenao des t a ao .
private Coordi nator coor di nat or ;
// ao CA pai
private Coordi natedAtomi cActi on parentCaa ;
// vet or contendo todos os pa r t i c i pa nt e s des t a ao
private Vector<Par t i ci pant > pa r t i c i pa nt s ;
// vet or contendo todas as aes CA ani nhadas ( ou aes CA f i l h a s )
private Vector<Coordi natedAtomi cActi on> nes t edAct i ons ;
// vet or contendo todas as excees envol vi das no s i s t ema
private Vector<Excepti on> except i ons ;
// vet or contendo todas as excees propagadas
private Vector<Excepti on> propagatedExcepti ons ;
// vet or contendo todas as t r ans a e s
private Vector<Tr ans act i onI nt er f ace > t r ans ;
// r vor e de r e s ol u o de excees l anadas concorrentemente
private Except i onTr eeI nt er f ace except i onTr ee ;
// r e l a t a o s t at us at ual da ao . Pode s e r : STARTED ( ao i ni c i a da ) ,
//STOPPED ( ao no i ni c i a da ou ao f i na l i z a da ) ou
//INTERRUPTED ( ao suspensa ) .
private St r i ng s t at us ;
Uso da Classe
Para instanciar uma ao CA, deve-se fornecer o nmero que a identicar (index). No mo-
mento da construo, o vetor de excees propagadas inicializado, e seu status denido
como STOPPED. Os demais elementos devem ser fornecidos pelo usurio e setados na ins-
tncia da ao CA.
Diferenas em Relao Especicao
Devido s diferenas entre CSP e Java, foram necessrias adaptaes do cdigo. As principais
alteraes consistem na utilizao de variveis adicionais: o vetor de excees propagadas, a
ao CA pai e o status da ao. Estas variveis so utilizadas para facilitar a comunicao de
eventos entre ao CA, coordenador e participantes, em substituio aos canais utilizados em
CSP.
4.4.3 ExceptionTree
Interface que representa a rvore de resoluo de excees de uma ao CA.
//Recebe um vet or que contm as excees l anadas concorrentemente ,
// apl i c a o mtodo de r e s ol u o e armazena a exceo r e s ul t a nt e na
// pr i mei r a pos i o do vet or . Os demai s el ementos do vet or devem s e r
// removi dos .
public abstract void r es ol veExcept i on ( Vector<Excepti on> except i ons ) ;
Uso da Interface
Para utilizar esta interface, o usurio deve criar uma classe que a herda, e implementar o
mtodo requisitado. Feito isso, o usurio deve criar uma instncia dessa classe e coloc-la na
ao CA correspondente. O mtodo implementado ser utilizado pelo coordenador da ao.
4.4.4 Participant
Para representar os participantes das aes CA, foi implementada a classe Participant. Esta
classe representa um participante da ao como uma thread. Para tornar possvel a realizao de
todas as atividades previstas na especicao, esta classe faz uso de outras duas threads, Role e
Handler, que implementam, respectivamente, o comportamento normal e o comportamento excep-
cional do participante (maiores detalhes sobre Role e Handler so descritos nas Sees 4.4.5 e 4.4.6).
A seguir, os campos da classe so apresentados.
// vet or com as thread r e s pons ve i s pel o comportamento normal
//do par t i c i pant e em cada ao CA.
private Vector<Role> r o l e s ;
// vet or com as thread r e s pons ve i s pel o comportamento e xc e pc i onal
//do par t i c i pant e em cada ao CA.
private Vector<Handler> handl er s ;
// vet or com todas as aes CA na qual e s t e par t i c i pant e r e a l i z a
//alguma at i vi dade .
private Vector<Coordi natedAtomi cActi on> caaVector ;
//nmero que i d e n t i f i c a o par t i c i pant e .
private i nt numberId ;
//nmero que i d e n t i f i c a a ao CA na qual o par t i c i pant e termi nou
//de r e a l i z a r sua at i vi dade .
private i nt endCaaIndex ;
//nmero que i d e n t i f i c a a prxima ao CA ani nhada na qual e s t e
// par t i c i pant e deve r e a l i z a r alguma at i vi dade .
private i nt nextNestedActi onIndex ;
// i nf orma o t i po de trmi no a s e r r e qui s i t ado pel o par t i c i pant e
//numa ao CA. Pode s e r NORMAL, EXCEPTIONAL ou ABORT.
private St r i ng endRequest ;
// i nf orma o s t at us do par t i c i pant e . Pode s e r STARTED, STOPPED ou SUSPENDED.
private St r i ng s t at us = "" ;
Mtodos Implementados
Para seguir o comportamento denido na especicao, foram implementados mtodos na
classe Participant que realizam esta tarefa. Eles foram divididos em trs categorias: mtodos
para incio de atividade, de monitoramento da execuo e para sinalizao do trmino da
atividade, e so descritos em detalhes a seguir.
Mtodo para Incio de Atividade: para iniciar a atividade, o participante precisa fazer
primeiro a requisio de entrada na ao para o coordenador. Para isso foi implementado o
mtodo, entryRequest, descrito a seguir.
public void entryRequest ( i nt caaIndex ) {
Coordi natedAtomi cActi on caaAux ;
for ( i nt i = 0; i < caaVector . s i z e ( ) ; i ++) {
// encontra , no vet or de aes CA, a ao CA na qual a r e qui s i o deve
s e r f e i t a .
caaAux = caaVector . get ( i ) ;
i f ( caaAux . getI ndex ( ) == caaIndex ) {
// i n i c i a o coordenador da ao
i f ( caaAux . get Coor di nat or ( ) . getCoordState ( ) . equal s ( "STOPPED" ) ) {
caaAux . get Coor di nat or ( ) . setCoordState ( "STARTED" ) ;
}
. . .
//soma ao contador do coordenador e s t a r e qui s i o de entrada . Assim
//que e s t e contador chegar ao val or de f i ni do no coordenador , a ao
i n i c i a .
caAux . get Coor di nat or ( ) . i ncrementRequestCount ( ) ;
}
}
}
Mtodo de Monitoramento da Execuo: uma vez iniciada a ao, o participante deve
iniciar sua execuo. Para esta implementao, optamos por juntar os sub-processos Execution
e Suspension denidos na especicao no mtodo beginParticipantAction. Este mtodo o
responsvel por controlar a execuo da atividade normal (representada pelo vetor de Roles)
e por responder requisio do coordenador da ao para abortar a atividade ou iniciar a
execuo do tratamento de exceo lanada no contexto da ao CA. Este mtodo descrito
a seguir.
public void begi nPar t i ci pant Act i on ( i nt caaIndex ) {
. . .
// r e qui s i o de entrada para o coordenador
thi s . entryRequest ( caaIndex ) ;
. . .
// i n i c i a o comportamento normal aps a conf i rmao
//do coordenador do i n c i o da ao .
thi s . r o l e s . el ementAt ( rol eVi ndex ) . s t a r t ( ) ;
while ( thi s . r o l e s . get ( rol eVi ndex ) . i sEndOf Executi on ( ) == f al se ) {
// enquanto a at i vi dade normal no s e encerra , v e r i f i c a s e h
//alguma r e qui s i o f e i t a pel o par t i c i pant e ou pel o coordenador .
i f ( thi s . caaVector . el ementAt ( caaVi ndex ) . get St at us ( ) . equal s ( "INTERRUPTED
" ) ) {
// s e a ao f o i i nterrompi da , a at i vi dade normal encer rada .
} el se i f ( thi s . get St at us ( ) . equal s ( "SUSPENDED" ) ) {
// s e o par t i c i pant e f o i suspenso , s i g n i f i c a que e l e deve i n i c i a r
//a at i vi dade normal de uma ao
. . .
// i n i c i a a ao aninhada , f azendo uma chamada r e c ur s i va .
begi nPar t i ci pant Act i on ( nestedActi onI ndex ) ;
// aps o trmi no da ao aninhada , retoma a at i vi dade normal
//da ao suspensa .
}
}
i f ( thi s . caaVector . el ementAt ( caaVi ndex ) . get St at us ( ) . equal s ( "INTERRUPTED" )
) {
// s e a ao f o i i nterrompi da , pr e c i s o v e r i f i c a r s e houve um aborto
//da ao ou s e o tratamento de uma exceo deve s e r i ni c i a do .
. . .
i f ( thi s . caaVector . get ( caaVi ndex ) . get Coor di nat or ( ) . i s Handl i ngExcept i on
( ) ) {
// i n i c i a o tratamento e xc e pc i onal
thi s . handl er s . get ( handl erVi ndex ) . s t a r t ( ) ;
. . .
// aps f i n a l i z a r o tratamento , chama o mtodo de r e qui s i o de
trmi no
//da at i vi dade do par t i c i pant e para o coordenador da ao .
} el se {
i f ( thi s . caaVector . get ( caaVi ndex ) . get Coor di nat or ( ) .
i s Except i onPr opagat i on ( ) ) {
// s e f o r s i na l i z a do que a exceo deve s e r propagada ,
//o par t i c i pant e r e q ui s i t a trmi no e xc e pc i onal .
} el se {
// s e no f o i s i na l i z a do tratamento de exceo ou propagao ,
// r e qui s i t ado o trmi no em aborto .
}
}
}
el se {
// s e no houve i nt er r upo , r e qui s i t ado o trmi no normal
//ou excepci onal , caso alguma exceo tenha s i do l anada durante
//a at i vi dade normal des t e par t i c i pant e .
}
}
Mtodos para Sinalizao do Trmino da Atividade: aps a nalizao da execuo,
o participante deve fazer a requisio de trmino ao coordenador da ao. Esta requisio
pode ser de trmino normal, excepcional ou aborto. A requisio para trmino normal ocorre
quando a atividade normal ou excepcional do participante foi concluda com xito. A requisio
para trmino excepcional ocorre quando alguma exceo foi lanada durante a execuo da
atividade do participante, ou no caso da exceo ser propagada para a ao pai. Por m, a
requisio para trmino em aborto ocorre quando a atividade do participante foi abortada
devido requisio do coordenador da ao.
Para cada tipo de requisio de trmino, foi implementado um mtodo correspondente. A
seguir, apresentamos o mtodo para o caso de requisio de trmino normal.
public void normalEndRequest ( i nt caaIndex ) {
// i nf orma o nmero i de nt i f i c a do r da ao CA para a qual s er r e qui s i t ado
o trmi no da
// at i vi dade do par t i c i pant e .
thi s . setEndCaaIndex ( caaIndex ) ;
// i nf orma o t i po de trmi no r e qui s i t ado .
thi s . setEndRequest ( "NORMAL" ) ;
}
Os mtodos para as demais requisies de trmino so anlogas a esta. Apenas o mtodo
para requisio de trmino excepcional informa ao coordenador, adicionalmente, que este
participante propagou ou lanou uma exceo.
Uso da Classe
Para implementar os participantes de seu sistema, o usurio deve implementar classes que
herdam de Participant, informar um nmero que servir para identicar este participante
no sistema, e chamar o mtodo beginParticipantAction. As atividades para comportamento
normal e excepcional de cada participante dever ser implementado em classes distintas (ver
Sees 4.4.5 e 4.4.6).]]
O processo Execution especicado teve sua implementao feita de modo ligeiramente dife-
rente: ao invs de blocos de execuo, as atividades foram separadas por Roles, sendo que no
caso de uma atividade ser interrompida para execuo de outra atividade numa ao aninhada,
ela retomada ao trmino da ao lha. O processo Suspension, que especica a interrupo
de todos os participantes para incio do tratamento cooperativo de exceo foi implementado
de acordo, assim como o processo para requisio de trmino em aborto.
Os processos Query e Update, referentes consulta e atualizao do estado de um objeto
externo no foram implementados, uma vez que o acesso a estes mtodos possvel por meio
do vetor de transaes, que deve ser denido na classe Participant.
4.4.5 Role
Para implementar o comportamento normal do participante, foi criada esta classe Role. Ela
classe representa uma thread e, portanto, sua ao principal dever ser implementada no mtodo
run. A seguir, a Listagem com os campos desta classe apresentada.
// var i ve l bool eana que i nterrompe a execuo des t a thread
// caso tenha seu val or de f i ni do para " t r ue ".
private boolean threadSuspended ;
// var i ve l bool eana que i nf orma o trmi no de execuo da thread .
private boolean endOf Executi on ;
// r e l a t a o s t at us da execuo des t a thread . Pode s e r NORMAL ( para
// trmi no normal ) , EXCEPTIONAL ( para trmi no com l anamento de
// exceo ) ou INTERRUPTED ( para aborto ou suspenso do par t i c i pant e ) .
// par t i c i pant e cuj o comportamento normal r epr es ent ado por e s t a thread .
private Par t i c i pant par t i c i pant ;
// ao na qual e s t a thread executada .
private Coordi natedAtomi cActi on caActi on ;
// vet or que contm as t r ans a e s at i vas nes t a ao CA.
protected Vector<Tr ans act i onI nt er f ace > t r ans ac t i ons ;
Uso da Classe
Para implementar o comportamento normal de um participante, o usurio dever criar uma
classe que herda de Role e programar o que ela deve fazer no contexto de uma nica ao CA
da qual este participante faz parte. Caso haja mais de uma ao CA na qual este participante
esteja inserido, necessrio criar uma classe Role para cada uma destas aes.
4.4.6 Handler
Para implementar o comportamento excepcional do participante, que equivale ao tratamento
da exceo lanada na ao CA, foi criada a classe Handler. De modo semelhante classe Role,
Handler representa uma thread que deve ser acionada no momento que o participante requisitado
a tratar uma exceo lanada no contexto de uma ao CA. Os campos desta classe so mostrados
abaixo.
// var i ve l bool eana que i nf orma o trmi no de execuo da thread .
private boolean endOf Executi on ;
// r e l a t a o s t at us da execuo des t a thread . Pode s e r NORMAL ( para
// trmi no normal ) , EXCEPTIONAL ( para trmi no e xc e pc i onal ) .
// par t i c i pant e cuj o comportamento normal r epr es ent ado por e s t a thread .
private Par t i c i pant par t i c i pant ;
// ao na qual e s t a thread executada .
private Coordi natedAtomi cActi on caActi on ;
// vet or que contm as t r ans a e s at i vas nes t a ao CA.
protected Vector<Tr ans act i onI nt er f ace > t r ans ac t i ons ;
Como pode ser percebido, os campos desta classe so praticamente os mesmos da classe Role. A
nica exceo a varivel threadSuspended que no consta em Handler. Isto acontece porque esta
varivel utilizada para suspender a ao da thread, e de acordo com a especicao, o tratamento
de uma exceo no pode ser interrompido.
Mtodos da Classe
Alm dos Getters e Setters, esta classe possui o mtodo throwException, mostrado a seguir.
public void throwExcepti on ( ) throws Excepti on {
Vector<Excepti on> excVector = thi s . getCaActi on ( ) . get Except i ons ( ) ;
Excepti on except i on = thi s . getCaActi on ( ) . get Coor di nat or ( ) .
getPropagatedExcepti ons ( ) . f i r s t El e me nt ( ) ;
for ( i nt i = 0; i < excVector . s i z e ( ) ; i ++) {
i f ( excVector . get ( i ) . get Cl as s ( ) . getSimpleName ( ) . equal s ( except i on .
get Cl as s ( ) . getSimpleName ( ) ) ) {
throw excVector . get ( i ) ;
}
}
}
Este mtodo foi implementado para fazer o lanamento da exceo a ser tratada, que est
armazenada no vetor propagatedExceptions do coordenadador da ao CA correspondente. O
lao deste mtodo utilizado para garantir que a exceo a ser lanada pertence ao universo
de excees do sistema, denido pelo vetor exceptions da ao CA.
Uso da Classe Para implementar o comportamento excepcional do participante, o usurio
dever criar uma classe que herda Handler. Nesta classe, o mtodo run a ser implementado
dever conter um bloco try-catch com uma chamada ao mtodo throwException mostrado
acima, sendo o tratamento feito, consequentemente, no catch da respectiva exceo a ser
tratada.
De modo anlogo ao que ocorre com a classe Role, necessrio implementar um Handler para
cada ao CA na qual o participante esteja inserido, caso haja a possibilidade de ocorrer um
lanamento de exceo durante a execuo desta ao CA.
4.4.7 Transaction e External Object
Os objetos externos, conforme descrito na especicao, interagem com os participantes e com
o coordenador da ao de modo que as propriedades ACID sejam preservadas num contexto transa-
cional. Nesta implementao, optamos por, ao invs de implementar o processo ExternalObject da
especicao em Java, criar uma interface TransactionInterface que agisse como um intermedirio
entre a comunicao do objeto externo com os demais elementos da ao CA. Deste modo, esta
interface ser a responsvel por comunicar ao objeto externo as requisies de alteraes em seu
estado feitas pelos participantes e pelo coordenador, e transmitir a eles se tais requisies foram
efetivamente concludas ou no. Os mtodos desta interface so listados a seguir.
// i n i c i a uma nova t r ans ao no obj et o ext er no
public abstract void begi n ( ) ;
// conf i rma a t r ans ao i ni c i a da no obj et o ext er no
public abstract void commit ( ) ;
// de s f az a t r ans ao i ni c i a da no obj et o ext er no
public abstract void r ol l bac k ( ) ;
// r et or na o estado da t r ans ao ( at i va ou i nat i va )
public abstract boolean i s Ac t i ve ( ) ;
// r et or na o obj et o ext er no
public abstract Obj ect get Ext er nal Obj ect ( ) ;
// e s t a be l e c e o obj et o ext er no
public abstract void s et Ext er nal Obj ect ( Obj ect ext er nal Obj ) ;
Uso da Interface
Antes de utilizar esta interface, o usurio deve ter implementado o objeto externo de seu
sistema. Para cada objeto externo do sistema, o usurio dever implementar uma classe que
herda esta interface TransactionInterface, e que conter uma referncia a este objeto e a
implementao dos mtodos requisitados. Aps implementar tal classe, o usurio deve criar
uma instncia dela e coloc-la na ao CA correspondente. Os mtodos implementados sero
utilizados pelo coordenador e pelos participantes da ao.
Por no se tratar da interface do objeto externo em si, a interface Transaction possui os
mtodos getExternalObject e setExternalObject que retornam e denem, respectivamente um
objeto externo instanciado pelo usurio em seu sistema. Os demais mtodos possuem processos
correspondentes na especicao. O nico processo da especicao que no consta como um
mtodo desta interface o processo InitState, que armazena o estado inicial do objeto externo.
Isto ocorre pois consideramos tal processo implcito na construo do objeto externo e de
carter opcional nesta interface.
4.4.8 Coordinator
A classe Coordinator representa o coordenador da ao CA. Ele o responsvel por implementar
o protocolo de coordenao e tratamento cooperativo de excees dos participantes da ao, bem
como o responsvel por fazer o controle transacional entre os participantes e os objetos externos do
sistema.
Nesta implementao, o coordenador uma thread que controla as threads que representam os
participantes da ao CA. Seus campos so listados a seguir.
// ao CA coordenada
private Coordi natedAtomi cActi on caa ;
// ao CA pai
private Coordi natedAtomi cActi on parentCaa ;
// vet or com as aes CA ani nhadas
private Vector<Coordi natedAtomi cActi on> nes t edAct i ons ;
// vet or com os pa r t i c i pa nt e s da ao CA
private Vector<Par t i ci pant > pa r t i c i pa nt s ;
// vet or contendo os pa r t i c i pa nt e s em execuo na ao CA
private Vector<Par t i ci pant > run ;
// vet or contendo os pa r t i c i pa nt e s que i r o t r at ar uma exceo do s i s t ema
private Vector<Par t i ci pant > pHandl ers ;
// vet or contendo os pa r t i c i pa nt e s que l anaram excees
private Vector<Par t i ci pant > par t i cRai s eExcept i on ;
// vet or contendo os t i pos de excees que devem s e r propagadas pel a ao CA
// para a ao pai
private Vector<Excepti on> f Si g na l ;
// vet or contendo as excees l anadas e/ou propagadas para e s t a ao
private Vector<Excepti on> propagatedExcepti ons ;
// vet or de t r ans a e s
private Vector<Tr ans act i onI nt er f ace > t r ans ac t i ons ;
// obj et o contendo o mtodo de r e s ol u o de excees l anadas concorrentemente
private Except i onTr eeI nt er f ace excepti onTreeRes ;
// var i ve l que s i n a l i z a o i n c i o do tratamento e xc e pc i onal a s e r f e i t o pe l os
// pa r t i c i pa nt e s da ao CA
private boolean handl i ngExcepti on ;
// var i ve l que s i n a l i z a a i nt er r upo das at i vi dade s dos pa r t i c i pa nt e s
private boolean i nt e r r upt i ng Pa r t i c i pa nt s ;
// var i ve l que s i n a l i z a a propagao de uma exceo para a ao CA pai
private boolean except i onPr opagat i on ;
// var i ve l que s i n a l i z a a i nt er r upo da at i vi dade do coordenador
private boolean coor dI nt er r upt ed ;
// var i ve l que s i n a l i z a o l anamento de uma exceo por um par t i c i pant e da
// ao CA
private boolean except i onRai s ed ;
// var i ve l que c ont r ol a as r e q ui s i e s de entrada na ao CA f e i t a pe l os
// pa r t i c i pa nt e s
private i nt entryRequestCount ;
// var i ve l que c ont r ol a a i nt er r upo das at i vi dade s dos pa r t i c i pa nt e s
//da ao CA
private i nt i nt er r upt edPar t i cCount ;
// i nf orma o estado do coordenador . Pode s e r STARTED ou STOPPED
private St r i ng coor dSt at e ;
// i nf orma o t i po de trmi no da ao : NORMAL, EXCEPTIONAL ou ABORT
private St r i ng caaEnd ;
Mtodos Implementados
Para garantir o comportamento especicado, foram implementados mtodos na classe Coordi-
nator que seguem os sub-processos denidos na especicao CSP. Para facilitar sua descrio,
eles foram separados em seis categorias: mtodo run do coordenador, mtodos de incio da
ao, de monitoramento da execuo, de tratamento cooperativo de excees, de aborto da
ao e de trmino da ao.
Mtodo Run do Coordenador: diferentemente das outras classes apresentadas, o coorde-
nador possui j denido o mtodo run, o mtodo principal da classe, responsvel pela execuo
da thread. Este mtodo apresentado abaixo.
@Override
public void run ( ) {
try {
// coordenador es per a o i n c i o de sua at i vi dade , que ocor r e
//quando seu estado passa de STOPPED a STARTED
while ( getCoordState ( ) . equal s ( "STOPPED" ) ) {
. . .
wai t ( ) ;
. . .
}
// r ecebe as r e q ui s i e s de entrada dos pa r t i c i pa nt e s na ao
thi s . r e c I ni t Re que s t ( ) ;
} catch ( CoordI nterruptedExcepti on ex ) {
//no caso da ao t e r s i do abortada , j ogada uma exceo do
// t i po CoordI nterruptedExcepti on . Como o aborto da ao CA0
//no pode oc or r e r ( poi s e s t a a ao CA i n i c i a l ) , f e i t a
//a v e r i f i c a o do ndi c e da ao ant es de s e r e q u i s i t a r o
// aborto .
i f ( caa . getI ndex ( ) > 0)
recAbortRequest ( ) ;
el se
System . out . pr i nt l n ( " [ERROR] : t r yi ng to abort CAA0" ) ;
}
}
Mtodos de Incio da Ao: conforme visto no item anterior, o primeiro mtodo chamado
corresponde ao mtodo responsvel por receber as requisies dos participantes para entrar na
ao CA. Aps todos os participantes terem requisitado sua entrada na ao CA, as transaes
so iniciadas e a ao comea. Estes mtodos so mostrados a seguir.
public void r e c I ni t Re que s t ( ) throws CoordI nterruptedExcepti on {
// es per a todos os pa r t i c i pa nt e s r e qui s i t ar e m sua entrada na ao
while ( getEntryRequestCount ( ) < pa r t i c i pa nt s . s i z e ( ) ) {
. . .
wai t ( ) ;
. . .
}
//quando todas as aes foram r e qui s i t adas , a ao i ni c i a da
begi nTrans ( ) ;
}
public void begi nTrans ( ) throws CoordI nterruptedExcepti on {
// as t r ans a e s so i ni c i a da s
for ( i nt i = 0; i < t r ans ac t i ons . s i z e ( ) ; i ++) {
t r ans ac t i ons . get ( i ) . begi n ( ) ;
}
// aps todas as t r ans a e s serem i ni c i adas , a ao s e i n i c i a
begi nActi on ( ) ;
}
public void begi nActi on ( ) throws CoordI nterruptedExcepti on {
//o s t at us da ao al t e r ado para STARTED, s i nal i z ando seu i n c i o
//ao coordenador e aos pa r t i c i pa nt e s
thi s . caa . s e t St at us ( "STARTED" ) ;
// i n c i o do monitoramento da execuo das at i vi dade s da ao
moni tor ( ) ;
}
Mtodo de Monitoramento da Execuo: iniciada a ao, o coordenador passa a moni-
torar a execuo das atividades dos participantes. Todos os participantes em execuo so
colocados no vetor run, e as requisies de trmino de cada um dele so observadas pelo
coordenador. No caso de trmino excepcional, o coordenador inicia o tratamento cooperativo
da exceo; no caso de aborto, lanada a exceo CoordInterruptedException que ser cap-
turada no mtodo run; no caso de trmino normal, o participante removido do vetor run.
O mtodo monitor apresentado abaixo.
public void moni tor ( ) throws CoordI nterruptedExcepti on {
// adi o dos pa r t i c i pa nt e s no vet or run , para moni torar
// sua at i vi dade .
for ( Par t i c i pant par t i c i pant : pa r t i c i pa nt s ) {
run . add( par t i c i pant ) ;
}
// enquanto o vet or com pa r t i c i pa nt e s em execuo no f i c a r vazi o ,
//e enquanto a i nt er r upo da ao no r e qui s i t ada , o monitoramento
// f e i t o .
while ( run . s i z e ( ) != 0 && ! i s Coor dI nt er r upt ed ( ) ) {
for ( Par t i c i pant p : run ) {
St r i ng endRequest = p . getEndRequest ( ) ;
// trmi no normal
i f ( endRequest . equal s ( "NORMAL" ) ) {
run . remove ( p) ;
break ;
}
// trmi no e xc e pc i onal exceo propagada de ao ani nhada
i f ( except i onPr opagat i on == true ) {
abort ( ) ;
return ;
}
// trmi no e xc e pc i onal exceo l anada em at i vi dade dos
// pa r t i c i pa nt e s des t a ao
i f ( except i onRai s ed == true ) {
abort ( ) ;
return ;
}
}
}
// s e a i nt er r upo f o i r e qui s i t ada , a exceo l anada
i f ( i s Coor dI nt er r upt ed ( ) == true ) {
throw new CoordI nterruptedExcepti on ( ) ;
}
// seno , o commit das t r ans a e s pode s e f e i t o .
el se {
commitTrans ( ) ;
}
}
Mtodos do Tratamento Cooperativo de Excees: no caso de trmino excepcional, o
coordenador deve abortar as aes aninhadas e suspender os demais participantes, para que
o tratamento cooperativo da exceo seja iniciado. Isto feito pelos mtodos abort e suspend-
Participants.
public void abort ( ) {
for ( Coordi natedAtomi cActi on act i on : nes t edAct i ons ) {
Coordi nator coord = act i on . get Coor di nat or ( ) ;
i f ( coord . getCoordState ( ) . equal s ( "STARTED" ) ) {
// aes ani nhadas so abortadas e f e i t o r ol l bac k
//de suas t r ans a e s
. . .
coord . rol l backTransAbort ( ) ;
. . .
// es per a a conf i rmao do aborto da
. . .
}
}
s us pendPar t i ci pant s ( ) ;
}
public void s us pendPar t i ci pant s ( ) {
// s t at us da ao de f i ni do como INTERRUPTED
thi s . caa . s e t St at us ( "INTERRUPTED" ) ;
// vet or pHandl er contendo os pa r t i c i pa nt e s que devem t r at ar a exceo
// de f i ni do . Estes pa r t i c i pa nt e s englobam os que es t o em execuo
// ( cont i dos no vet or run ) , e os que no l anaram ou propagaram
// excees ( cont i dos no vet or par t i cRai s eExcept i on ) .
pHandl ers = new Vector<Par t i ci pant >() ;
. . .
// es per a todos os pa r t i c i pa nt e s r e s pons ve i s por t r at ar a exceo
//terem sua at i vi dade i nt err ompi da
while ( i nt er r upt edPar t i cCount < pHandl ers . s i z e ( ) ) {
. . .
wai t ( ) ;
. . .
}
// r e s e t end r eques t of pa r t i c i pa nt s
for ( Par t i c i pant p : pHandl ers ) {
p . setEndRequest ( "" ) ;
}
r e s o l ve ( ) ;
}
Aps o aborto das aes aninhadas, e a suspenso das atividades dos participantes, o tra-
tamento cooperativo pode ser iniciado. Para isso, preciso resolver as excees que podem
ter sido lanadas concorrentemente. Em seguida, deve-se escolher se a exceo resolvida ser
propagada ao CA pai, ou se ela ser tratada no contexto da ao CA atual. No caso de se
escolher o tratamento cooperativo da exceo, preciso checar se este foi bem sucedido ou no.
Caso tenha sido, feito o commit das transaes. Caso contrrio, o rollback das transaes
feito. Os mtodos responsveis por estas atividades so mostrados a seguir.
public void r e s o l ve ( ) {
//chama o mtodo para r e s ol u o das excees l anadas
excepti onTreeRes . r es ol veExcept i on ( propagatedExcepti ons ) ;
// i n i c i a o tratamento cooper at i vo da exceo r e s o l vi da
choose ( ) ;
}
public void choose ( ) {
// s e a exceo per t ence ao vet or f Si gnal , e l a deve s e r propagada
// para a exceo pai . I s t o v e r i f i c a do pel a f uno a ux i l i a r
// cont ai ns Except i on ( )
i f ( cont ai ns Except i on ( ) ) {
s i g na l ( ) ;
}
// caso cont r r i o , a exceo t r at ada cooperati vamente pe l os
// pa r t i c i pa nt e s da ao
el se {
handl e ( ) ;
}
}
public void s i g na l ( ) {
// para propagar a exceo , todos os pa r t i c i pa nt e s em execuo
//devem termi nar excepci onal mente
while ( pHandl ers . s i z e ( ) != 0) {
. . .
//com a conf i rmao do trmi no excepci onal , o par t i c i pant e
// removi do do vet or pHandl ers .
}
// f i n a l i z a d a s as at i vi dade s dos pa r t i c i pa nt e s des t a ao , f e i t o o
// r ol l bac k das t r ans a e s e a exceo propagada para a ao pai .
rol l backTransExcep ( ) ;
thi s . parentCaa . getPropagatedExcepti ons ( ) . add( propagatedExcepti ons .
f i r s t El e me nt ( ) ) ;
thi s . parentCaa . get Coor di nat or ( ) . s et Except i onPr opagat i on ( true ) ;
}
public void handl e ( ) {
// para f a z e r o tratamento cooper at i vo da exceo , o coordenador s i n a l i z a
// aos pa r t i c i pa nt e s seu i n c i o pel a var i ve l handl i ngExcepti on
thi s . setHandl i ngExcepti on ( true ) ;
//tambm s i na l i z a do aos pa r t i c i pa nt e s que o tratamento pode s e r
// i ni c i a do poi s a i nt er r upo das at i vi dade s de todos os pa r t i c i pa nt e s
//da ao f o i concl u da
thi s . s e t I nt e r r upt i ng Pa r t i c i pa nt s ( true ) ;
v e r i f y ( ) ;
}
public void v e r i f y ( ) {
// var i ve l ut i l i z a da para s i n a l i z a r s e a exceo f o i t r at ada
//com s uces s o , ou no .
boolean r e que s t Si gnal = f al se ;
while ( pHandl ers . s i z e ( ) != 0) {
// checa o t i po de trmi no dos pa r t i c i pa nt e s . Caso haj a
// trmi no excepci onal , r e que s t Si gnal passa a s e r t r ue .
}
respond ( r e que s t Si gnal ) ;
}
public void respond ( boolean r e que s t Si gnal ) {
// s e o tratamento no f o i bem sucedi do , f e i t o o r ol l bac k
// das t r ans a e s
i f ( r e que s t Si gnal == true ) {
}
// caso cont r r i o , o commit das t r ans a e s f e i t o .
el se {
commitTrans ( ) ;
}
}
Mtodos do Aborto da Ao: caso seja requisitado o aborto da ao, lanada a exceo
CoordInterruptedException. Esta ser capturada no mtodo run da classe Coordinator, e o
mtodo responsvel por interromper as atividades da ao chamado. Ele apresentado
abaixo.
public void recAbortRequest ( ) {
//o aborto das aes ani nhadas f e i t o pel o mtodo
// abortNested . Este mtodo semel hante ao mtodo abort
//implementado para a r e a l i z a o do tratamento de exceo .
abortNested ( ) ;
// ao CA i nt er r ompi da
caa . s e t St at us ( "INTERRUPTED" ) ;
. . .
// f e i t a a v e r i f i c a o da i nt er r upo dos pa r t i c i pa nt e s
. . .
//ao f i na l , o r ol l bac k das t r ans a e s f e i t o
rol l backTransAbort ( ) ;
}
Mtodos de Trmino da Ao: terminadas as atividades dos participantes, resta nalizar
o coordenador e a ao CA. Para isso, deve ser feito o commit (ou rollback) das transaes e o
status do coordenador e da ao devem ser atualizados para STOPPED. A seguir, mostramos
os mtodos para nalizao normal.
public void commitTrans ( ) {
for ( i nt i = 0; i < t r ans ac t i ons . s i z e ( ) ; i ++) {
t r ans ac t i ons . get ( i ) . commit ( ) ;
}
endActionNormal ( ) ;
}
public void endActionNormal ( ) {
thi s . setCaaEnd ( "NORMAL" ) ; // t i po de f i n a l i z a o da ao NORMAL
thi s . caa . s e t St at us ( "STOPPED" ) ;
f i na l i z e Ac t i o n ( ) ;
}
public void f i na l i z e Ac t i o n ( ) {
thi s . setCoordState ( "STOPPED" ) ;
}
Para a nalizao excepcional ou em aborto, os mtodos so semelhantes, apenas com a
substituio do commit por rollback, e com a substituio do tipo de nalizao da ao CA.
Uso da Classe
Para utilizar esta classe, deve-se informar a ao CA durante a construo de sua instncia.
Em seguida, ela pode ter sua execuo iniciada por meio do mtodo start, da classe Thread
de Java.
O que difere esta implementao da especicao o fato da substituio do processo CSP
CoordinatorState pela varivel coordState na classe Coordinator. Outra diferena em relao
ao tratamento cooperativo das excees: na implementao, apenas os participantes em exe-
cuo e que no lanaram excees no contexto da ao so acionados para fazer o tratamento,
enquanto que na especicao, todos os participantes fazem o tratamento. Isto foi feito pois
consideramos na implementao que, caso um participante decida lanar a exceo, ele o faz
por no conseguir fazer o tratamento local dela e, por isso, ele no participa do tratamento
cooperativo da exceo. Este tratamento ento feito pelos demais participantes em execuo
(participantes que j nalizaram suas atividades no so chamados pois na implementao a
thread do participante j ter sua execuo nalizada) na ao.
4.4.9 Exemplo de Uso
Para mostrar como funciona esta implementao do modelo de aes CA, vamos apresentar um
exemplo que consiste em duas aes CA aninhadas, com dois participantes e um objeto externo.
O objeto externo consiste numa representao de um banco de dados, em que so armazenados
dados de uma conta bancria. Os participantes interagem entre si e fazem operaes de leitura e
adio de dados no banco. O cdigo fonte contendo a implementao de cada um dos elementos
disponibilizada no Apndice B.
Comportamento Normal
Primeiramente, vamos mostrar o funcionamento do exemplo no caso de no ocorrer nenhum
lanamento ou propagao de excees durante a realizao destas aes. Para ilustrar as operaes
a serem realizadas nas aes pelos participantes, mostramos o seguinte esquema da Figura 4.6.
Figura 4.6: Exemplo - Comportamento Normal
Na ao CA 0, as operaes a serem feitas antes da ao CA 1 ser iniciada so:
Participante 0: leitura da conta de nmero 1 comunicao do nmero da conta a ser
adicionada ao participante 1.
Participante 1: obteno do nmero da conta a ser adicionada ao banco de dados, informada
pelo participante 0.
Na ao CA 1, as operaes a serem feitas so:
Participante 1: adio da conta no banco de dados.
Ao nal da ao CA 1, as operaes a serem feitas pela ao CA 0 so:
Participante 1: comunicao do sucesso da operao para o participante 0.
Participante 0: leitura da conta de nmero 1, aps conrmao do sucesso da operao pelo
participante 1.
Para executar este exemplo, foi criada uma classe Simulator, que instancia estes elementos. O
cdigo desta classe mostrado a seguir.
1 package s i mul at i on ;
2
3 import s i mul at i on . database . Transacti on ;
4 import except i on . Inval i dAccountNumberExcepti on ;
5 import s i mul at i on . framework . Coordi natedAtomi cActi on ;
6 import s i mul at i on . framework . Coordi nator ;
7 import s i mul at i on . framework . Handl er ;
8 import s i mul at i on . framework . Par t i c i pant ;
9 import s i mul at i on . framework . Rol e ;
10 import s i mul at i on . framework . Tr ans ac t i onI nt e r f ac e ;
11 import j ava . u t i l . Vector ;
12 import s i mul at i on . except i onTr ee . Excepti onTree ;
13 import s i mul at i on . pa r t i c i pa nt s . Par t i ci pant 0 ;
14 import s i mul at i on . pa r t i c i pa nt s . Par t i ci pant 1 ;
15 import s i mul at i on . pa r t i c i pa nt s . handl er s . Par t i ci pant 0Handl er 0 ;
16 import s i mul at i on . pa r t i c i pa nt s . handl er s . Par t i ci pant 1Handl er 0 ;
17 import s i mul at i on . pa r t i c i pa nt s . r o l e s . Par t i ci pant 0Rol e0 ;
20
21 /
22
23 @author Simone
24 /
25 public cl ass Si mul ator {
26
27 stati c Vector<Role> r o l e s 0 ;
28 stati c Vector<Role> r o l e s 1 ;
29 stati c Vector<Handler> handl er s 0 ;
30 stati c Vector<Handler> handl er s 1 ;
31 stati c Vector<Par t i ci pant > par t i c i pant s 0 ;
32 stati c Vector<Par t i ci pant > par t i c i pant s 1 ;
33 stati c Vector<Tr ans act i onI nt er f ace > t r ans ac t i ons 0 ;
34 stati c Vector<Tr ans act i onI nt er f ace > t r ans ac t i ons 1 ;
35 stati c Vector<Excepti on> except i ons ;
36 stati c Vector<Coordi natedAtomi cActi on> nes t edAct i ons ;
37 stati c Vector<Coordi natedAtomi cActi on> caaVector ;
38
39 stati c Coordi natedAtomi cActi on caa0 , caa1 ;
40 stati c Coordi nator coord0 , coord1 ;
41 stati c Excepti onTree excTree ;
42 stati c Transacti on t0 , t1 ;
43 stati c Par t i c i pant p0 , p1 ;
44 stati c Rol e r0 , r1 , r2 ;
45 stati c Handl er h0 , h1 ;
46
47
48 public stati c void main( St r i ng ar gs [ ] ) {
49 // i n i c i a l i z a o das va r i ve i s
50 r o l e s 0 = new Vector<Role >() ;
51 r o l e s 1 = new Vector<Role >() ;
52 handl er s 0 = new Vector<Handler >() ;
53 handl er s 1 = new Vector<Handler >() ;
54 par t i c i pant s 0 = new Vector<Par t i ci pant >() ;
55 par t i c i pant s 1 = new Vector<Par t i ci pant >() ;
56 t r ans ac t i ons 0 = new Vector<Tr ans act i onI nt er f ace >() ;
57 t r ans ac t i ons 1 = new Vector<Tr ans act i onI nt er f ace >() ;
58 except i ons = new Vector<Excepti on >() ;
59 nes t edAct i ons = new Vector<Coordi natedAtomi cActi on >() ;
60 caaVector = new Vector<Coordi natedAtomi cActi on >() ;
61
62 // i ns t anc i a o da r vor e de r e s ol u o de excees
63 excTree = new Excepti onTree ( ) ;
64
65 // i ns t anc i a o da ao CA 0 , e do seu vet or de t r ans a e s
66 caa0 = new Coordi natedAtomi cActi on ( 0) ;
67 t0 = new Transacti on ( ) ;
68 t r ans ac t i ons 0 . add( t0 ) ;
69 // i ns t anc i a o da ao CA 1 , e do seu vet or de t r ans a e s
70 caa1 = new Coordi natedAtomi cActi on ( 1) ;
71 t1 = new Transacti on ( ) ;
72 t r ans ac t i ons 1 . add( t1 ) ;
73
74 // adi o das aes CA no vet or
75 caaVector . add( caa0 ) ;
76 caaVector . add( caa1 ) ;
77
78 // i ns t anc i a o do par t i c i pant e 0 , s eus r o l e s e handl er s
79 p0 = new Par t i c i pant 0 ( caaVector , 0) ;
80 r0 = new Par t i ci pant 0Rol e0 ( p0 , caa0 , 1) ; // adi o no BD da conta 1
81 r o l e s 0 . add( r0 ) ;
82 p0 . s e t Rol e s ( r o l e s 0 ) ;
83 h0 = new Par t i ci pant 0Handl er 0 ( p0 , caa0 ) ;
84 handl er s 0 . add( h0 ) ;
85 p0 . s et Handl er s ( handl er s 0 ) ;
86 // adi o do par t i c i pant e 0 no vet or de pa r t i c i pa nt e s da ao CA 0
87 par t i c i pant s 0 . add( p0 ) ;
88
89 // i ns t anc i a o do par t i c i pant e 1 , s eus r o l e s e handl er s
90 p1 = new Par t i c i pant 1 ( caaVector , 1) ;
91 r1 = new Par t i ci pant 1Rol e0 ( p1 , caa0 ) ;
92 r2 = new Par t i ci pant 1Rol e1 ( p1 , caa1 ) ;
93 r o l e s 1 . add( r1 ) ;
94 r o l e s 1 . add( r2 ) ;
95 p1 . s e t Rol e s ( r o l e s 1 ) ;
96 h1 = new Par t i ci pant 1Handl er 0 ( p1 , caa0 ) ;
97 handl er s 1 . add( h1 ) ;
98 p1 . s et Handl er s ( handl er s 1 ) ;
99
104
105 // adi o da exceo Inval i dAccountNumberExcepti n ao vet or de
106 // excees das aes CA. Para e f e i t o de s i mpl i f i c a o , apenas
107 // e s t a exceo s er adi ci onada .
108 Inval i dAccountNumberExcepti on exc = new Inval i dAccountNumberExcepti on ( ) ;
109 except i ons . add( exc ) ;
110
111 // de f i ni o de va r i ve i s da ao CA 0
112 caa0 . setTrans ( t r ans ac t i ons 0 ) ;
113 caa0 . s e t Pa r t i c i pa nt s ( par t i c i pant s 0 ) ;
114 nes t edAct i ons . add( caa1 ) ;
115 caa0 . s et Nes t edAct i ons ( nes t edAct i ons ) ;
116 caa0 . s et Except i ons ( except i ons ) ;
117 caa0 . set Except i onTree ( excTree ) ;
118 // i ns t anc i a o do coordenador da ao CA 0
119 coord0 = new Coordi nator ( caa0 ) ;
120 caa0 . s et Coor di nat or ( coord0 ) ;
121
122 // de f i ni o de va r i ve i s da ao CA 1
123 caa1 . setTrans ( t r ans ac t i ons 1 ) ;
124 caa1 . s e t Pa r t i c i pa nt s ( par t i c i pant s 1 ) ;
125 caa1 . s et Nes t edAct i ons (new Vector<Coordi natedAtomi cActi on >() ) ;
126 caa1 . s et Except i ons ( except i ons ) ;
127 caa1 . set Except i onTree ( excTree ) ;
128 caa1 . setParentCaa ( caa0 ) ;
129 // i ns t anc i a o do coordenador da ao CA 1
130 coord1 = new Coordi nator ( caa1 ) ;
131 coord1 . s e t f Si g na l ( except i ons ) ;
132 caa1 . s et Coor di nat or ( coord1 ) ;
133
134 // i n c i o da execuo dos pa r t i c i pa nt e s
135 for ( Par t i c i pant par t i c : par t i c i pant s 0 ) {
136 par t i c . s t a r t ( ) ;
137 }
138 // i n c i o da execuo dos coordenadores
139 caa0 . get Coor di nat or ( ) . s t a r t ( ) ;
140 caa1 . get Coor di nat or ( ) . s t a r t ( ) ;
141 }
142 }
O resultado desta execuo mostrado a seguir.
Par t i c i pant 0: entry r eques t CA act i on 0 coor di nat or s t ar t e d
Coordi nator 0: wai t i ng .
Coordi nator 0: s t a r t i ng .
Coordi nator 0: gat her i ng pa r t i c i pa nt s .
Coordi nator 0: s t a r t i ng ac t i on .
Par t i ci pant 0 Rol e0 : s t a r t i ng .
Par t i ci pant 0 Rol e0 : r eadi ng r ecor d 1
Account does not e x i s t .
Par t i ci pant 0 Rol e0 : s e t t i ng number on Par t i c i pant 1.
Par t i ci pant 0 Rol e0 : number s e t t e d .
Par t i ci pant 1 Rol e0 : number s e t t e d ok .
Par t i ci pant 1 Rol e0 : nest ed act i on s t ar t e d .
Par t i ci pant 1 Rol e1 : s t a r t i ng
Par t i ci pant 1 Rol e1 : addi ng r ecor d ( 1 , Simone , 900. 00)
Par t i ci pant 1 Rol e1 : r ecor d added
Par t i c i pant 1: Normal Ending
commit
Coordi nator 1: ac t i on f i ni s he d
Par t i ci pant 1 Rol e0 : nest ed act i on f i ni s he d .
Account Number : 1
Name : Simone
Bal ance : 900. 0
commit
Comportamento Excepcional
Agora, vamos mostrar o funcionamento do exemplo no caso no caso de ocorrer lanamento e/ou
propagao de excees durante a realizao destas aes. As operaes a serem realizadas nas aes
pelos participantes so esquematizadas na Figura 4.7.
Figura 4.7: Exemplo - Comportamento Excepcional
Na ao CA 0, as operaes a serem feitas antes da ao CA 1 ser iniciada so:
Participante 0: leitura da conta de nmero 1 comunicao do nmero da conta a ser
adicionada ao participante 1.
Participante 1: obteno do nmero da conta a ser adicionada ao banco de dados, informada
pelo participante 0.
Na ao CA 1, as operaes a serem feitas so:
Participante 1: adio da conta no banco de dados. Aqui, ser lanada uma exceo porque
o nmero da conta a ser adicionada no banco de dados ser invlido (valor negativo). Como
nenhum outro participante est nesta ao, esta exceo ser propagada para a ao pai, a
ao CA 0.
Ao nal da ao CA 1, as operaes a serem feitas pela ao CA 0 so:
Participante 0: tratamento da exceo lanada.
Participante 1: tratamento da exceo lanada.
Para executar este exemplo, preciso alterar a linha 80 da classe Simulator para:
80 r0 = new Par t i ci pant 0Rol e0 ( p0 , caa0 , 1) ; // adi o no BD da conta 1 (ERRO! )
O resultado da execuo do exemplo com esta alterao apresentado abaixo.
Par t i c i pant 0: entry r eques t CA act i on 0 c oor di nat or s t ar t e d
Par t i c i pant 1: entry r eques t CA act i on 0 c oor di nat or s t ar t e d
Account does not e x i s t .
Par t i ci pant 0 Rol e0 : s e t t i ng number on Par t i c i pant 1.
Par t i ci pant 0 Rol e0 : number s e t t e d .
Par t i ci pant 1 Rol e0 : number s e t t e d ok .
Par t i ci pant 1 Rol e0 : nest ed act i on s t ar t e d .
Par t i ci pant 1 Rol e1 : s t a r t i ng
Par t i ci pant 1 Rol e1 : addi ng r ecor d ( 1, Simone , 900. 00)
Par t i c i pant 1: Except i onal Ending
EXCEPTION RAISE
r ol l back excep
EXCEPTION SIGNAL
Par t i ci pant 1 Handl er0 : s t a r t i ng .
Excepti on handl i ng s uc c e s s f ul
Par t i ci pant 0 Handl er0 : s t a r t i ng .
Excepti on handl i ng s uc c e s s f ul
commit
4.5 Concluso
Neste captulo, abordamos a teoria referente aos componentes, ao desenvolvimento baseado em
componentes e ao tratamento de excees no nvel do componente e de arquitetura. Dentro desta
teoria, o conceito de aes atmicas coordenadas mostrou-se o mais importante por ser o protocolo
que garante a coordenao de componentes tolerantes a falhas e, por esta razo, este protocolo foi
o escolhido para este trabalho.
Para a realizao da implementao de propriedades para vericao de cdigo com este proto-
colo, foi necessria a realizao da implementao de um modelo genrico que implementasse este
protocolo em Java. Por esta razo, optamos pela implementao do modelo genrico especicado
em [Per07, PdM10] na linguagem formal CSP/CSPm, conforme pode ser visto na Seo 4.4. Em-
bora existam outras implementaes de coordenao de componentes via aes CA feitas em Java
[CGP
+
06], uma implementao prpria d, alm de um melhor entendimento do cdigo necess-
rio para a programao desse protocolo de coordenao, uma maior exibilidade e segurana para
programar adequadamente as propriedades referentes s aes CA na ferramenta de vericao
escolhida para este trabalho, a JPF Exceptions[Xav08]. Estas propriedades e sua implementao
nesta ferramenta so o tema do prximo captulo deste documento.
Captulo 5
Propriedades sobre Coordenao de
Componentes
Neste captulo, vamos discorrer sobre os seguintes tpicos relacionados s propriedades sobre
coordenao de componentes:
descrio de propriedades relacionadas coordenao de componentes
1
especicadas formal-
mente em trabalhos da rea.
implementao das propriedades de coordenao de componentes relativas ao seu comporta-
mento excepcional.
5.1 Propriedades sobre Aes Atmicas Coordenadas
Para modelar a coordenao de componentes, utilizamos as aes atmicas coordenadas. Por
isso apresentamos, a seguir, propriedades denidas por cada um dos trs trabalhos que formalizam
as propriedades de aes CA. Elas foram separadas de acordo com a linguagem e mtodo formal
utilizado por cada um dos trabalhos: Lgica Temporal, Alloy e CSP.
5.1.1 Lgica Temporal
Desenvolvido por Randell et al. [RRS
+
98], este trabalho tem como objetivo formalizar as aes
atmicas coordenadas, e demonstrar o seu uso na prtica, por meio da implementao de prottipos
e sua utilizao para soluo de sistemas reais. Para formalizar o conceito de ao CA, foi utilizada
a Lgica Temporal Linear [Pnu77, Lam94, MP92].
As propriedades de aes CA formalizadas so divididas em quatro categorias: propriedades
elementares, de interface, de enclosure e de tolerncia a falhas. Aqui, elas so apresentadas de
modo informal.
Propriedades Elementares
Caracterizam a ordenao relativa aos estados de execuo de aes (aninhadas).
Uma ao CA que termina precisa ter comeado antes.
Uma ao CA que comea deve terminar em algum tempo no futuro.
1
Conforme dito anteriormente (ver Seo 4.2.2), vamos utilizar o modelo de aes CA para a coordenao de
componentes e, portanto, as propriedades a serem aqui descritas dizem respeito a este modelo.
61
62 PROPRIEDADES SOBRE COORDENAO DE COMPONENTES
Propriedades de Interface
Especicam entradas, sadas e possveis resultados relacionados s pr e ps condies das aes
CA.
Se uma ao CA comea, todos os seus papis
2
devem ter sido chamados antes.
Se uma ao CA termina, todos os seus papis devem voltar ao seu devido curso.
Os possveis resultados provenientes da ao CA podem ser divididos em trs categorias princi-
pais: normais, excepcionais e sem resultados (ocorre quando a ao abortada). A seguir, apresen-
tamos as propriedades relativas aos resultados e suas categorias:
Se a ao CA comea com a pr-condio satisfeita e termina normalmente, ento sua ps-
condio tambm deve ser satisfeita.
Se a ao CA comea com a pr-condio satisfeita e termina excepcionalmente, ento uma
de suas ps-condies excepcionais deve ser satisfeita.
Se a ao CA termina com um aborto, ento todas as suas modicaes feitas em objetos
externos devem ser desfeitas.
Propriedades de Enclosure
Foram a ao CA a ter uma qualidade de membro exclusivo, ou seja: informao s pode ser
transferida na entrada e sada da ao; e durante a execuo de uma ao, um papel dentro da ao
no pode interagir de maneira alguma com um papel ou thread
3
que no est na ao.
Para compreender as propriedades de enclosure, preciso denir alguns termos:
Aes estritamente serializadas: so aes no mesmo nvel de aninhamento cujas execu-
es no se sobrepem em nenhum ponto no tempo;
Aes concorrentes: so aes no mesmo nvel de aninhamento que, num mesmo ponto no
tempo, realizam suas operaes;
Execuo concorrente (intercalvel) serializada: corresponde execuo de duas aes
no mesmo nvel de aninhamento cujos efeitos na interseo dos objetos externos das aes so
sempre equivalentes aos efeitos de execues estritamente serializadas das duas aes.
A seguir, so enunciadas as propriedades de enclosure propriamente ditas:
Para aes CA no mesmo nvel de aninhamento, apenas suas execues intercalveis seriali-
zadas so permitidas.
Para qualquer papel pertencente ao conjunto de papis que esto na ao pai e no na ao
CA em questo, apenas execues intercalveis serializadas destes papis e da ao CA so
permitidas.
Propriedades de Tolerncia a Falhas
Correspondem a propriedades relevantes para o tratamento de excees e recuperao de erros.
Uma ao CA s naliza normalmente se nenhuma exceo ocorre ou se a recuperao de
erros bem sucedida.
2
Um papel especica uma sequncia de operaes num conjunto de objetos
3
Thread, neste contexto, um agente/representante da computao.
PROPRIEDADES SOBRE AES ATMICAS COORDENADAS 63
A nalizao excepcional de uma ao CA implica na sinalizao de uma exceo apropriada
que especica um resultado excepcional.
A nalizao em aborto de uma ao CA remove qualquer efeito que esta ao tivesse tido
em seus objetos externos, e sinaliza uma exceo especial de aborto.
A nalizao em falha de uma ao CA ocorre se a recuperao de erros no possvel. Neste
caso, uma exceo especial de falha sinalizada.
Se uma exceo lanada dentro de uma ao e no pode ser tratada localmente por um
papel, ento todos os papis da ao tratam a exceo cooperativamente.
A sinalizao de uma exceo numa ao aninhada faz com que todos os papis da ao pai
tratem a exceo cooperativamente.
5.1.2 Alloy
No trabalho desenvolvido por Castor Filho et al. [FRR05, CFRR09], apresentada uma abor-
dagem para modelar e vericar sistemas distribudos tolerantes a falhas que utiliza o tratamento de
exceo como principal mecanismo tolerante a falha. A abordagem tem como componente principal
um modelo formal de aes CA, que especica a estruturao do sistema em termos destas aes,
bem como as informaes relativas ao uxo de exceo entre as aes.
Para a especicao do modelo, foi utilizada a linguagem Alloy [Jac02]. Ela considerada uma
das linguagens formais mais simples, e baseada na lgica relacional de primeira-ordem. De modo
similar a outras linguagens de especicao, Alloy suporta estruturas de dados complexas e modelos
declarativos. Ademais, em Alloy, os modelos so analisados dentro de um dado escopo utilizando
um analisador prprio para esta linguagem [JSS00].
A seguir, apresentamos alguns exemplos de propriedades denidas pelos autores deste trabalho
como sendo as propriedades de interesse que um sistema deve satisfazer. Elas so apresentadas
de modo informal, e divididas em trs categorias: bsicas, desejveis, e especcas da aplicao.
A formalizao destas propriedades pode ser vista no trabalho de Castor Filho et al. [FRR05,
CFRR09].
Propriedades Bsicas
Denem as caractersticas de aes CA vlidas. Eles especicam o mecanismo de tratamento de
exceo coordenado e como as aes devem ser organizadas.
Se um participante realiza um papel numa ao aninhada, ele tambm deve realizar um papel
na ao que a contm.
No h ciclos no aninhamento de aes; a organizao das aes no sistema hierrquica, de
modo que o grafo formado por suas denies no possua ciclos.
O mecanismo de resoluo de exceo de uma ao soluciona todas as possveis combinaes
de excees internas concorrentes, a menos que seja explicitamente declarado o contrrio.
Propriedades Desejveis
Correspondem a propriedades gerais que frequentemente so consideradas bencas, apesar de
no fazerem parte do mecanismo de aes CA. Elas descrevem requisitos importantes que muitos
sistemas tolerantes a falhas devem satisfazer. Em geral, elas assumem que as propriedades bsicas
j foram satisfeitas.
Aes CA do nvel mais alto da hierarquia (ou seja, no so aninhadas e nem compostas) no
possuem excees externas; isto garante que o sistema , de fato, tolerante a falhas, uma vez
que todas as excees que chegam a estas aes so tratadas.
Todas as excees internas de uma ao so tratadas dentro dela e, portanto, no h propa-
gao de excees.
Propriedades Especcas da Aplicao
Estas propriedades so regras sobre o uxo de excees numa aplicao baseada em aes CA
especca. Elas devem ser especicadas pelo desenvolvedor de acordo com a necessidade de cada
sistema.
5.1.3 CSP
Em seu trabalho, Pereira [Per07] apresenta um framework para a estruturao de sistemas
concorrentes e tolerantes a falhas em CSP (Communicating Sequencial Processes) [Hoa85], baseando
a estruturao dos sistemas no modelo de aes CA, e permitindo a construo por aninhamento.
A linguagem formal CSP descreve o comportamento de um sistema concorrente de forma precisa,
utilizando um conjunto de leis algbricas. Grosso modo, podemos dizer que CSP decompe o sistema
em sub-sistemas menores que operam de modo concorrente e interagem entre si. A unidade bsica
desta linguagem o evento que indica a ocorrncia de qualquer ao de interesse do sistema que
afete o comportamento deste.
Para a especicao das propriedades, foi utilizado o modelo de renamento por rastros de
CSP (traces renement) [RHB97]. Este modelo se baseia em sequncias, ou rastros de eventos, que
descrevem a execuo dos processos. Um processo Q um renamento de P se todas as possveis
sequncias de eventos em Q constituem tambm sequncias de eventos em P.
A seguir, apresentamos o texto extrado do trabalho de Pereira que descreve informalmente as
propriedades de aes CA propostas por ele. Estas propriedades foram denidas para formalizao
das caractersticas do modelo de aninhamento das aes CA. Sua especicao formal encontra-se
no Apndice A.2, e explicada em detalhes no trabalho de Pereira [Per07, PdM10].
Propriedades de Sincronismo
Descrevem as condies de sincronismo exigidas no modelo de aes CA, envolvendo o momento
de participao dos componentes.
A ao CA inicia com a entrada sncrona de seus participantes.
A ao CA termina com a sada sncrona de seus participantes.
A ao CA s termina aps ter sido iniciada anteriormente.
A ao CA s termina aps a nalizao de suas aes aninhadas.
Propriedades de Condies de Trmino
Descrevem as possveis condies de trmino de uma determinada ao CA.
A ao CA termina normalmente se:
1. A atividade normal da ao naliza com sucesso, ou seja, nenhuma exceo lanada
pelos participantes.
2. A atividade excepcional da ao naliza com sucesso, ou seja, as excees lanadas so
completamente tratadas pelos participantes.
A ao CA termina excepcionalmente se a atividade excepcional da ao naliza com a pro-
pagao de uma exceo externa, ou seja, o tratamento no nalizado adequadamente.
A ao CA termina em aborto se a atividade da ao (normal ou excepcional) for interrompida
pela ao pai.
IMPLEMENTAO DAS PROPRIEDADES 65
Propriedades de Aninhamento
Descrevem as caractersticas de aninhamento das aes CA.
Os participantes da ao CA aninhada (ou lha) so tambm participantes da ao pai.
Os participantes da ao CA aninhada (ou lha) devem acessar apenas um subconjunto dos
objetos externos associados ao pai.
Propriedades de Transao
Descrevem as exigncias de controle transacional sobre objetos externos a partir do incio e
trmino de uma determinada ao CA.
Quando a ao CA inicia, transaes so criadas para cada objeto externo correspondente.
Quando a ao CA termina normalmente, todas as transaes criadas nos objetos externos
so conrmadas.
Quando a ao CA termina excepcionalmente ou em aborto, todas as transaes criadas nos
objetos externos so desfeitas.
Propriedades de Tratamento de Excees
Descrevem as particularidades do tratamento cooperativo e concorrente de excees, lanadas
pelos participantes de uma determinada ao CA ou propagadas de alguma ao CA aninhada.
As excees internas da ao CA so tratadas na prpria ao.
As excees externas da ao CA so propagadas para a ao pai.
Quando uma exceo lanada, todos os participantes da ao CA correspondente devem
iniciar as respectivas atividades excepcionais.
Quando uma exceo propagada, todos os participantes da ao CA pai devem iniciar as
respectivas atividades excepcionais.
A atividade excepcional do participante deve incluir tratamento para todas as excees inter-
nas, incluindo as excees resolvidas.
5.2 Implementao das Propriedades
Nesta seo, descrevemos as implementaes das propriedades relativas coordenao de com-
ponentes por meio das aes atmicas coordenadas. O cdigo destas propriedades foi adicionado
ferramenta JPF Exceptions [Xav08] e, para sua realizao, foi utilizado o modelo apresentado na
Seo 4.4.
5.2.1 Programao de Propriedades Customizadas no JPF
Implementar propriedades customizadas no vericador JPF, utilizado pela ferramenta JPF Ex-
ceptions, requer basicamente a realizao de dois passos:
1. Implementar a propriedade numa classe que herda a superclasse PropertyListenerAdapter do
vericador;
2. Registrar esta propriedade para que o vericador a reconhea e faa sua checagem no cdigo
recebido como entrada.
No primeiro passo, a necessidade de se herdar de PropertyListenerAdapter ocorre porque esta
classe engloba tanto as funes de propriedade (necessria para fazer a varredura do cdigo em
busca de violaes) quanto de listener (necessria para fazer a observao de eventos de interesse
para a propriedade). Um esquema mostrando as classes que PropertyListenerAdapter contm so
mostrados a seguir.
Figura 5.1: Classe PropertyListenerAdapter e suas dependncias
Os mtodos de interesse utilizados para a implementao de propriedades no JPF tanto as re-
lativas coordenao deste trabalho, quanto as relativas ao tratamento excepcional implementadas
na JPF Exceptions e que esto presentes nessa classe, so apresentados abaixo.
package gov . nasa . j pf ;
. . .
public cl ass Pr opert yLi st enerAdapter extends Generi cProperty implements
Sear chLi s t ener , VMListener , Publ i s her Ext ens i on {
// Property i nt e r f a c e
// checa a vi ol a o da propri edade , i ndi cada pel o val or bool eano
// r et or nado . Por padro , o val or r et or nado t r ue
public boolean check ( Search search , JVM vm) {
return true ;
}
// the VMListener i nt e r f a c e
//mtodo chamado a cada i ns t r u o executada pel o v e r i f i c a do r
public void i ns t r uct i onExecut ed (JVM vm) {}
//mtodo chamado quando h a oc or r nc i a de l anamento de exceo
public void excepti onThrown (JVM vm) {}
. . .
// the Sear chLi s t ener i nt e r f a c e
//mtodo chamado quando o v e r i f i c a do r f az o backt r acki ng
public void s t at eBackt r acked ( Search s ear ch ) {}
//mtodo chamado quando a busca por vi o l a e s excede algum l i mi t e ,
//como n ve l de prof undi dade mximo da busca , e o heap da JVM.
public void s ear chCons t r ai nt Hi t ( Search s ear ch ) {}
//mtodo chamado quando a v e r i f i c a o f i na l i z a da
IMPLEMENTAO DAS PROPRIEDADES 67
public void s ear chFi ni s hed ( Search s ear ch ) {}
. . .
}
Os mtodos acima so sobrescritos na implementao das propriedades customizadas, utilizando-
se a anotao @Override. Deste modo, os cdigos que compe o corpo destes mtodos so persona-
lizados para que estes veriquem a violao das propriedades durante a execuo do JPF.
Com relao ao segundo passo para implementao de propriedades no vericador JPF, que
consiste em seu registro de forma que o JPF reconhea estas implementaes como proprieda-
des a serem checadas, ele feito automaticamente na JPF Exceptions por meio de um listener,
que observa o evento de seleo da propriedade para checagem na interface grca utilizada pelo
aplicativo e o registra quando o vericador acionado. Este listener, foi aproveitado para a imple-
mentao da integrao grca entre as ferramentas OConGraX e JPF Exceptions, conforme pode
ser visto na Seo 6.5 e, desta maneira, para implementar as propriedades relativas coordenao
de componentes, basta fazer o passo 1 aqui descrito.
5.2.2 Escolha das Propriedades
Para este trabalho, cujo foco a coordenao de componentes tolerantes a falhas, vamos direcio-
nar a implementao para as propriedades relacionadas ao tratamento excepcional no contexto das
aes atmicas coordenadas. Deste modo, vamos nos restringir s seguintes propriedades, baseadas
nas mencionadas na Seo 5.1.
Propriedades de Trmino de Transaes:
1. Se uma ao CA termina excepcionalmente ou em aborto, todas as transaes devem ser
desfeitas.
Propriedades de Tratamento de Excees:
1. Se uma exceo lanada dentro de uma ao, todos os participantes da ao CA cor-
respondente devem tratar a exceo cooperativamente.
2. Se uma exceo propagada de uma ao aninhada para uma ao pai, os participantes
da ao pai devem tratar a exceo cooperativamente.
3. Excees internas da ao CA so tratadas na prpria ao.
4. Excees externas da ao CA so propagadas para a ao pai.
5. A ao CA do nvel mais alto da hierarquia no possui excees externas e, portanto,
no pode propagar excees.
Embora esta seja a lista das propriedades relativas ao comportamento excepcional dos compo-
nentes no contexto das aes CA, elas no foram implementadas em sua totalidade no vericador
JPF, devido a restries deste vericador na sua aplicao no modelo de aes CA implementado
neste trabalho (ver Seo 4.4), conforme descrito a seguir.
5.2.3 Limitaes do JPF
A implementao das propriedades no vericador JPF implica na existncia de um modelo
que implemente a coordenao de componentes por meio das aes CA. Desta forma, utilizamos o
modelo descrito na Seo 4.4 para este m. Entretanto, encontramos alguns problemas para executar
a vericao do JPF neste modelo:
Exploso de Estados: um dos problemas a serem enfrentados pelos vericadores que uti-
lizam model-checking (ver Seo 3.3.2). A exploso de estados ocorre quando o nmero de
estados necessrios para modelar um sistema excede um limite razovel, podendo acarretar
um consumo de memria maior que a quantidade fsica existente no hardware, resultando
assim em erro. Este problema ocorre quando executamos a vericao pelo JPF no nosso
modelo de aes CA implementado, devido ao fato do controle das vrias threads ser feito por
estruturas como laos. Isto traz como consequncias os seguintes problemas:
Tempo de execuo demorado;
Consumo de memria maior que o suportado pelo heap da JVM.
Bibliotecas Java: bibliotecas da linguagem Java, como java.awt, java.net e java.io no
possuem suporte adequado no vericador.
Por causa destas limitaes, as implementaes das propriedades s poderiam ser feitas com as
seguintes restries:
Interrupo da Vericao
Para tentar evitar o problema de exploso de estados, a varredura feita pelo vericador deve
ser nalizada assim que as seguintes condies sejam satisfeitas:
1. Uma exceo lanada
4
;
2. O tratamento da exceo realizado;
3. A ao CA-0 nalizada.
Apesar desta restrio ser obedecida, podem ocorrer situaes nas quais o consumo de memria
exceda o suportado pelo heap da JVM. Nestas situaes, a checagem das propriedades pode
ter resultados incorretos e/ou incompletos.
No Utilizao de Bibliotecas Java No Suportadas pelo JPF
Para evitar problemas na vericao, recomendvel no utilizar as bibliotecas java.awt,
java.net e java.io para instanciao do modelo de aes CA.
A restrio de interromper a vericao traz como consequncia o fato de, em alguns casos,
fazer com que a varredura feita pelo vericador no abranja a totalidade do programa. A restrio
de no utilizar algumas bibliotecas Java no suportadas pelo JPF, por sua vez, acaba limitando o
universo de programas em que a vericao das propriedades pode ser aplicada.
5.3 Propriedades Implementadas
Devido aos problemas relatados na Seo 5.2.2, as propriedades implementadas foram restritas
a duas:
1. Desfazimento de Transaes (Rollback Transactions): se uma ao CA termina excep-
cionalmente ou em aborto, todas as transaes devem ser desfeitas.
2. Tratamento das Excees (Exception Handling): se uma exceo lanada (ou pro-
pagada) dentro de uma ao, todos os participantes responsveis por trat-la devem iniciar
suas atividades excepcionais. Esta propriedade equivale juno das propriedades 1 e 2 de
tratamento de excees apresentadas na Seo 5.2.2.
A implementao destas propriedades foi feita conforme descrito na Sees 6.3.2 e 5.2.1, em que
so apresentadas as propriedades da JPF Exceptions. Ela mostrada em detalhes a seguir.
4
Caso uma exceo no seja lanada, corre-se o risco da vericao ser interrompida antes de se checar a violao
da propriedade e, portanto, esta situao foi descartada
PROPRIEDADES IMPLEMENTADAS 69
5.3.1 Propriedade 1: Desfazimento de Transaes
A ideia desta propriedade vericar se:
caso haja propagao de exceo, a ao correspondente desfaz suas transaes;
caso haja lanamento de exceo, a ao correspondente desfaz suas transaes se o tratamento
no foi bem sucedido; caso contrrio, as transaes so conrmadas.
Para realizar esta vericao, criamos a classe RollbackTransactionProperty. Ela herda de Pro-
pertyListenerAdapter para que o JPF a reconhea como uma propriedade a ser checada, conforme
consta na Seo 5.2.1. Os mtodos a serem sobrescritos so:
// checa a vi ol a o da propri edade , i ndi cada pel o val or bool eano r et or nado .
return true ;
}
Para se certicar que a propriedade satisfeita ou no, verica-se a ocorrncia dos seguintes
eventos:
Propagao de exceo: sinalizada pela chamada do mtodo signal da classe Coordinator
do framework (ver Seo 4.4), indica que a ao termina excepcionalmente e, portanto, o
desfazimento das transaes deve ser feito obrigatoriamente.
Tratamento cooperativo de exceo: sinalizada pela chamada do mtodo handle da classe
Coordinator do framework, indica que a ao pode terminar excepcionalmente, caso o trata-
mento no tenha sido bem sucedido; ou normalmente, caso o tratamento tenha obtido xito.
No primeiro caso, devemos desfazer as transaes obrigatoriamente; no outro, as transaes
devem ser conrmadas. Para observar o tipo de trmino da ao aps a chamada do handle,
checado o valor da varivel requestSignal, presente no mtodo respond da mesma classe. Se
o valor for false, o tratamento da exceo no foi bem sucedido; caso contrrio, o tratamento
ocorreu com sucesso.
A seguir, apresentamos o cdigo da implementao desta propriedade com comentrios que
visam a auxiliar o entendimento do cdigo.
1 package br . usp . j pf . property . caa ;
2
3 import br . usp . j pf . l i s t e n e r . Li s t e ne r Ut i l s ;
4 import br . usp . j pf . property . Re f l e c t i o nUt i l s ;
5 import gov . nasa . j pf . PropertyLi stenerAdapter ;
6 import gov . nasa . j pf . jvm.JVM;
7 import gov . nasa . j pf . jvm. MethodInfo ;
8 import gov . nasa . j pf . jvm. bytecode . I ns t r uc t i on ;
9 import gov . nasa . j pf . jvm. bytecode . I nvoke I ns t r uc t i on ;
10 import gov . nasa . j pf . s ear ch . Search ;
11 import gov . nasa . j pf . jvm. ThreadInf o ;
13
14 /
15
16 @author Simone Hanazumi
17 /
18 public cl ass Rol l backTransacti onProperty extends Pr opert yLi st enerAdapter {
19 // vet or que contm o nome das t hr eads que coordenam a ao CA
20 Vector<Stri ng> coordThreadNames = new Vector<Stri ng >() ;
21 // var i ve l bool eana que i nf orma s e a pr opr i edade f o i s a t i s f e i t a ou vi ol ada
22 boolean r ol l backTr ans Pr oper t y = true ;
23 // var i ve l que i ndi c a s e uma exceo f o i l anada na ao CA
24 boolean excepti onThrown = f al se ;
25 // var i ve l que i ndi c a s e a ao termi na excepci onal mente
26 boolean excepti onal End = f al se ;
27 // var i ve l que i nf orma s e a exceo f o i propagada
28 boolean s i g na l = f al se ;
29 // var i ve l que armazena o nome da thread coordenadora da ao CA na qual
30 //houve l anamento de exceo
31 St r i ng threadRai seExc = "" ;
32 // var i ve l que armazena o nome do mtodo que vi ol ou a pr opr i edade
33 St r i ng methodName = "" ;
34 // var i ve l que armazena o nome da thread da pr i mei r a ao CA ( ao CA0)
35 St r i ng f i r s t Co or di na t o r = "" ;
36
37 @Override
38 // checa s e a pr opr i edade f o i vi ol ada ou no
39 public boolean check ( Search search , JVM vm) {
40 return r ol l backTr ans Pr oper t y ;
41 }
42
43 @Override
44 // observa o l anamento de uma exceo durante a v e r i f i c a o
45 public void excepti onThrown (JVM vm) {
46 excepti onThrown = true ;
47 }
48
49 @Override
50 // v e r i f i c a a cada i ns t r u o executada s e a pr opr i edade s a t i s f e i t a ou no
51 public void i ns t r uct i onExecut ed (JVM vm) {
52 I ns t r uc t i on i ns t r uc t i o n = vm. ge t Las t I ns t r uc t i on ( ) ;
53 ThreadInf o t i ;
54 St r i ng threadName = "" ;
55 // checa s e a i ns t r u o per t ence a uma c l a s s e de i nt e r e s s e
56 i f ( ! Li s t e ne r Ut i l s . f i l t e r ( i ns t r uc t i o n ) ) {
57 boolean methodCal l ed = Re f l e c t i o nUt i l s . i s I nvoke I ns t r uc t i on ( i ns t r uc t i o n ) ;
58 i f ( methodCal l ed ) {
59 I nvoke I ns t r uc t i on i nvoke I ns t r uc t i on = ( I nvoke I ns t r uc t i on ) i ns t r uc t i o n ;
60 MethodInfo methodInfo = i nvoke I ns t r uc t i on . getInvokedMethod ( ) ;
61 // checa s e a i ns t r u o i nvocada per t ence a uma c l a s s e de i nt e r e s s e
62 i f ( ! Li s t e ne r Ut i l s . f i l t e r ( methodInfo ) ) {
63 t i = vm. getLastThreadI nf o ( ) ;
64 threadName = t i . getName ( ) ;
65 // s e o mtodo i n i c i a uma transao , ento sua thread de execuo
66 // uma thread coordenadora da ao CA
67 i f ( methodInfo . getFullName ( ) . cont ai ns ( " begi nTrans " ) ) {
68 // adi ci ona a thread ao vet or de t hr eads coordenadoras
69 addCoordThread ( threadName ) ;
70 }
71 // s e uma exceo f o i l anada , v e r i f i c o seu tratamento
72 i f ( excepti onThrown == true ) {
73 // s e a thread chama o mtodo de i n c i o do tratamento ,
74 // e l a a thread coordenadora da ao em que a exceo
75 // f o i l anada
76 i f ( methodInfo . getFullName ( ) . cont ai ns ( " abort " ) ) {
77 threadRai seExc = threadName ;
78 }
79 // s e o mtodo chamado f az a propagao da exceo ,
80 //a f i n a l i z a o da ao do t i po e xc e pc i onal
81 el se i f ( methodInfo . getFullName ( ) . cont ai ns ( " s i g na l " ) ) {
82 s i g na l = true ;
83 excepti onal End = true ;
84 }
85 // s e a exceo f o i t r at ada na ao , pr e c i s o v e r i f i c a r
86 // s e a ao termi na normalmente ou excepci onal mente
87 el se i f ( methodInfo . getFullName ( ) . cont ai ns ( " respond" ) ) {
88 i f ( ! t i . getBool eanLocal ( " r e que s t Si gnal " ) ) {
89 excepti onal End = f al se ;
90 } el se {
91 excepti onal End = true ;
92 }
93 }
94 // s e a exceo vai s e r tratada , no h propagao
95 el se i f ( methodInfo . getFullName ( ) . cont ai ns ( " handl e " ) ) {
96 s i g na l = f al se ;
97 }
98 // s e a thread em execuo a thread coordenadora da ao
99 //na qual houve l anamento de exceo , v e r i f i c o sua at i vi dade
100 //em r e l a o s t r ans a e s
101 i f ( threadName . equal s ( threadRai seExc ) ) {
102 // s e as t r ans a e s so conf i rmadas , v e r i f i c o s e o f i n a l da
103 // ao normal . Se no f or , h vi ol a o da pr opr i edade
104 i f ( methodInfo . getFullName ( ) . cont ai ns ( "commitTrans" ) ) {
105 i f ( excepti onal End ) {
106 methodName = methodInfo . getFullName ( ) ;
107 r ol l backTr ans Pr oper t y = f al se ;
108 t i . pr i nt St ackTr ace ( ) ;
109 } el se {
110 coordThreadNames . remove ( threadName ) ;
111 }
112 f i na l i z e Se a r c h ( threadRai seExc , vm) ;
113 }
114 // s e as t r ans a e s so de s f e i t a s , v e r i f i c o s e o f i n a l da
115 // ao e xc e pc i onal . Se no f or , h vi ol a o da pr opr i edade
116 el se i f ( methodInfo . getFullName ( ) . cont ai ns ( " r ol l bac k " ) ) {
117 i f ( excepti onal End ) {
119 } el se {
120 methodName = methodInfo . getFullName ( ) ;
121 r ol l backTr ans Pr oper t y = f al se ;
123 }
124 f i na l i z e Se a r c h ( threadRai seExc , vm) ;
125 }
126 }
127 // s e a thread em execuo no a de coordenao da ao
128 //em que houve l anamento de exceo
129 el se {
130 i f ( ! s i g na l ) {
131 i f ( threadName . compareTo ( threadRai seExc ) < 0) {
132 i f ( methodInfo . getFullName ( ) . cont ai ns ( "commitTrans" ) ) {
134 }
135 }
136 f i na l i z e Se a r c h ( threadName , vm) ;
137 }
138 }
139 }
140 }
141 }
142 }
143 }
144
145 // adi ci ona a thread de coordenao ao vet or cor r es pondent e e de f i ne
146 //a thread da pr i mei r a ao CA
147 private void addCoordThread ( St r i ng threadName ) {
148 i f ( ! coordThreadNames . cont ai ns ( threadName ) ) {
149 coordThreadNames . add( threadName ) ;
150 i f ( f i r s t Coo r di na t o r . equal s ( "" ) ) {
151 f i r s t Co or di na t or = threadName ;
152 }
153 }
154 }
155
156 // s e no h aes pendentes e s e a thread em execuo cor r es ponde
157 // thread coordenadora da pr i mei r a ao CA, a v e r i f i c a o f i na l i z a da
158 private void f i na l i z e Se a r c h ( St r i ng threadName , JVM vm) {
159 i f ( coordThreadNames . isEmpty ( ) && threadName . equal s ( f i r s t Coo r di na t or ) ) {
160 vm. getJPF ( ) . get Sear ch ( ) . ter mi nate ( ) ;
161 }
162 }
163
164 @Override
165 // r et or na o mtodo que r e s ul t ou na vi ol a o da pr opr i edade
166 public St r i ng getErrorMessage ( ) {
167 return methodName ;
168 }
169 }
5.3.2 Propriedade 2: Tratamento das Excees
Nesta propriedade, devemos vericar se as seguintes condies so satisfeitas quando uma exce-
o lanada:
os participantes da ao correspondente so suspensos (mtodo suspend chamado) e iniciam
o tratamento da exceo (mtodo handle chamado);
os participantes da ao correspondente so suspensos (mtodo suspend chamado) e fazem
a propagao da exceo para a ao pai (mtodo signal chamado).
Para realizar esta checagem, criamos a classe ExceptionHandlingProperty. Ela herda de Pro-
pertyListenerAdapter para que o JPF a reconhea como uma propriedade a ser checada, conforme
descrito na Seo 5.2.1. Os mtodos a serem sobrescritos so os mesmos da propriedade anterior.
// checa a vi ol a o da propri edade , i ndi cada pel o val or bool eano r et or nado .
return true ;
}
Para vericar se esta propriedade satisfeita, os seguintes eventos so observados quando uma
exceo lanada:
Suspenso dos Participantes: o mtodo suspend da classe Coordinator do framework
(ver Seo 4.4) chamado, fazendo com que as atividades dos participantes da ao sejam
interrompidas. Este mtodo marca o incio efetivo do tratamento da exceo.
Propagao ou Tratamento Cooperativo das Excees: aps a vericao da suspen-
so, preciso decidir se a propagao da exceo ser feita (chamada ao mtodo signal ) ou
se o tratamento cooperativo ser feito (chamada ao mtodo handle). Se nenhum destes m-
todos chamado, a exceo no foi tratada e, portanto, a propriedade violada. Note que
aqui apenas vericamos se estes mtodos de tratamento de exceo so chamados, no sendo
vericada a ordem de chamada destes mtodos.
O cdigo contendo a implementao desta propriedade apresentado a seguir. Para facilitar o
entendimento de seu funcionamento, foram inseridos comentrios ao longo da implementao.
1 package br . usp . j pf . property . caa ;
2
3 import br . usp . j pf . l i s t e n e r . Li s t e ne r Ut i l s ;
4 import br . usp . j pf . property . Re f l e c t i o nUt i l s ;
10 import gov . nasa . j pf . jvm. bytecode . I nvoke I ns t r uc t i on ;
13
14 /
15
17 /
18 public cl ass Handl i ngExcepti onProperty extends Pr opert yLi st enerAdapter {
19 // vet or que armazena as s e gui nt e s i nf or maes das t hr eads que coordenam
20 //a ao CA na e s t r ut ur a CoordThreadInfo : nome da thread e uma va r i ve l
21 // bool ena que i ndi c a s e na ao CA que e l a coordena houve l anamento
22 //de exceo
23 Vector<CoordThreadInfo> coordThreadS = new Vector<CoordThreadInfo >() ;
24 // var i ve l bool eana que i nf orma s e a pr opr i edade f o i s a t i s f e i t a ou vi ol ada
25 boolean handl i ngExcProperty = true ;
26 // var i ve l que i ndi c a s e uma exceo f o i l anada na ao CA
27 boolean excepti onThrown = f al se ;
28 // var i ve l que i ndi c a o i n c i o do tratamento e xc e pc i onal
29 boolean begi nni ngHandl i ng = f al se ;
30 // var i ve l que i ndi c a a chamada aos mtodos de tratamento ou propagao
31 //da exceo
32 boolean handl i ngExc = f al se ;
33 // var i ve l que armazena o nome da thread coordenadora da ao CA na qual
34 //houve l anamento de exceo
35 St r i ng threadRai seExc = "" ;
36 // var i ve l que armazena o nome da thread da pr i mei r a ao CA ( ao CA0)
37 St r i ng f i r s t Co or di na t o r = "" ;
38
39 @Override
40 // checa s e a pr opr i edade f o i vi ol ada ou no
42 return handl i ngExcProperty ;
43 }
44
45 @Override
46 // observa o l anamento de uma exceo durante a v e r i f i c a o
48 excepti onThrown = true ;
49 }
50
51 @Override
52 // v e r i f i c a a cada i ns t r u o executada s e a pr opr i edade s a t i s f e i t a ou no
53 public void i ns t r uct i onExecut ed (JVM vm) {
54 I ns t r uc t i on i ns t r uc t i o n = vm. ge t Las t I ns t r uc t i on ( ) ;
55 ThreadInf o t i ;
56 St r i ng threadName = "" ;
57 // checa s e a i ns t r u o per t ence a uma c l a s s e de i nt e r e s s e
58 i f ( ! Li s t e ne r Ut i l s . f i l t e r ( i ns t r uc t i o n ) ) {
59 boolean methodCal l ed = Re f l e c t i o nUt i l s . i s I nvoke I ns t r uc t i on ( i ns t r uc t i o n ) ;
60 i f ( methodCal l ed ) {
61 I nvoke I ns t r uc t i on i nvoke I ns t r uc t i on = ( I nvoke I ns t r uc t i on )
i ns t r uc t i o n ;
62 MethodInfo methodInfo = i nvoke I ns t r uc t i on . getInvokedMethod ( ) ;
63 // checa s e a i ns t r u o i nvocada per t ence a uma c l a s s e de i nt e r e s s e
64 i f ( ! Li s t e ne r Ut i l s . f i l t e r ( methodInfo ) ) {
65 t i = vm. getLastThreadI nf o ( ) ;
66 threadName = t i . getName ( ) ;
67 // s e o mtodo i n i c i a uma transao , ento sua thread de execuo
68 // uma thread coordenadora da ao
69 i f ( methodInfo . getFullName ( ) . cont ai ns ( " begi nTrans " ) ) {
70 // adi ci ona as i nf or maes da thread no vet or cor r es pondent e
71 addCoordThread ( threadName ) ;
72 }
73 // s e uma exceo f o i l anada , v e r i f i c o seu tratamento
74 i f ( excepti onThrown == true ) {
75 // s e a thread i n i c i a o aborto das aes ani nhadas , ento
76 // e l a a thread coordenadora da ao na qual a exceo
77 // f o i l anada
78 i f ( methodInfo . getFullName ( ) . cont ai ns ( " abort " ) ) {
79 i nt k = getCoordVectorIndex ( threadName ) ;
80 i f ( k != 1) {
81 CoordThreadInfo i nf o = coordThreads . get ( k) ;
82 // a t ua l i z o a i nf ormao da thread , conf i rmando
83 //que e l a deve t r at ar ou propagar uma exceo
84 i nf o . setExcepti onThrown ( true ) ;
85 }
86 i f ( ! threadRai seExc . equal s ( threadName ) ) {
87 threadRai seExc = threadName ;
88 // r e s e t o os val or e s das va r i ve i s bool eanas de c ont r ol e
89 handl i ngExc = f al se ;
90 begi nni ngHandl i ng = f al se ;
91 }
92 }
93 // s e os pa r t i c i pa nt e s so suspensos , o tratamento da exceo
94 // i ni c i o u ef et i vament e
95 el se i f ( methodInfo . getFullName ( ) . cont ai ns ( " s us pendPar t i ci pant s " ) ) {
96 begi nni ngHandl i ng = true ;
97 }
98 // s e a thread em execuo a thread da ao na qual a exceo f o i
99 // l anada , v e r i f i c o s e f e i t o algum tratamento
100 i f ( threadName . equal s ( threadRai seExc ) ) {
101 i f ( methodInfo . getFullName ( ) . cont ai ns ( " s i g na l " ) | | methodInfo .
getFullName ( ) . cont ai ns ( " handl e " ) ) {
102 handl i ngExc = true ;
104 i f ( k != 1) {
105 coordThreads . remove ( k) ;
106 }
107 }
108 // s e a thread em execuo e s t f i na l i z a ndo sua ao , v e r i f i c o s e
o tratamento
109 //da exceo f o i f e i t o . Se no f oi , a pr opr i edade vi ol ada
110 el se i f ( methodInfo . getFullName ( ) . cont ai ns ( "commitTrans" ) | |
methodInfo . getFullName ( ) . cont ai ns ( " r ol l bac k " ) ) {
111 i f ( begi nni ngHandl i ng && ! handl i ngExc ) {
112 handl i ngExcProperty = f al se ;
114 }
115 el se i f ( begi nni ngHandl i ng && handl i ngExc ) {
117 i f ( k != 1) {
119 }
120 // s e a pr opr i edade no f o i vi ol ada , checo s e a v e r i f i c a o
121 //pode s e r f i na l i z a da
123 }
124 }
125 }
EXEMPLO DE USO 75
126 // s e a thread em execuo no l anou nenhuma exceo , r e t i r o e l a
127 //do vetor , e checo s e a v e r i f i c a o pode s e r f i na l i z a da
128 el se {
130 i f ( k != 1) {
131 CoordThreadInfo i nf o = coordThreads . get ( k) ;
132 i f ( ! i nf o . i sExcepti onThrown ( ) ) {
135 }
136 }
137 }
138 }
139 }
140 }
141 }
142 }
143
144 // adi ci ona a thread coordenadora no vet or cor r es pondent e
145 //e de f i ne a thread da pr i mei r a ao CA ( ao CA0)
146 private void addCoordThread ( St r i ng threadName ) {
147 i f ( ! i s I nVe c t or ( threadName ) ) {
148 coordThreads . add(new CoordThreadInfo ( threadName , f al se ) ) ;
149 i f ( f i r s t Coo r di na t o r . equal s ( "" ) ) {
150 f i r s t Coo r di na t or = threadName ;
151 }
152 }
153 }
154
155 // v e r i f i c a s e a threadName consta no vet or de t hr eads
156 private boolean i s I nVe c t or ( St r i ng threadName ) {
157 for ( CoordThreadInfo coordThreadInf o : coordThreads ) {
158 i f ( coordThreadInf o . getThreadName ( ) . equal s ( threadName ) ) {
159 return true ;
160 }
161 }
162 return f al se ;
163 }
164
165 // r et or na o ndi c e da threadName no vet or
166 private i nt getCoordVectorIndex ( St r i ng threadName ) {
167 for ( i nt i = 0; i < coordThreads . s i z e ( ) ; i ++) {
168 i f ( coordThreads . get ( i ) . getThreadName ( ) . equal s ( threadName ) ) {
169 return i ;
170 }
171 }
172 return 1;
173 }
174
175 // s e no h aes pendentes e s e a thread em execuo cor r es ponde
176 // thread coordenadora da pr i mei r a ao CA, f i n a l i z a a v e r i f i c a o
177 private void f i na l i z e Se a r c h ( St r i ng threadName , JVM vm) {
178 i f ( coordThreads . isEmpty ( ) && threadName . equal s ( f i r s t Co o r di nat o r ) ) {
179 vm. getJPF ( ) . get Sear ch ( ) . ter mi nate ( ) ;
180 }
181 }
182 }
5.4 Exemplo de Uso
Para exemplicar o uso das propriedades implementadas, vamos utilizar o exemplo da Seo
4.4.9, em que feito o tratamento excepcional de uma exceo. Como o cdigo do exemplo no
viola as propriedades, vamos mostrar nas prximas sees as alteraes no cdigo que acarretam
na violao dessas propriedades, e o resultado parcial retornado pela ferramenta JPF Exceptions(o
resultado mais completo pode ser visto no Apndice C).
5.4.1 Propriedade 1: Desfazimento de Transaes
Esta propriedade, que checa se as transaes so desfeitas quando a ao termina excepcional-
mente ou em aborto, violada quando o mtodo de conrmao (commit) chamado no lugar do
mtodo de desfazimento (rollback), e vice-versa. Deste modo, se alterarmos o mtodo respond da
classe Coordinator do framework (ver Seo 4.4) para:
public void respond ( boolean r e que s t Si gnal ) {
i f ( r e que s t Si gnal == true ) {
} el se {
rol l backTransExcep ( ) ; //ERRO: aqui dever i a s e r chamado commitTrans
}
}
Teramos a violao da propriedade, e obteramos a seguinte sada de JPF Exceptions:
JavaPathf i nder v4 . 1 (C) 19992007 RIACS/NASA Ames Research Center
====================================================== system under t e s t
appl i c at i on : s i mul at i on . Si mul ator . cl ass
====================================================== s ear ch s t ar t e d : 03/08/10 13: 24
s i mul at i on . framework . Coordi nator . rol l backTransExcep ( Coordi nator . j ava : 386)
s i mul at i on . framework . Coordi nator . respond ( Coordi nator . j ava : 358)
s i mul at i on . framework . Coordi nator . v e r i f y ( Coordi nator . j ava : 350)
s i mul at i on . framework . Coordi nator . handl e ( Coordi nator . j ava : 331)
s i mul at i on . framework . Coordi nator . choose ( Coordi nator . j ava : 280)
s i mul at i on . framework . Coordi nator . r e s o l ve ( Coordi nator . j ava : 272)
s i mul at i on . framework . Coordi nator . s us pendPar t i ci pant s ( Coordi nator . j ava : 267)
s i mul at i on . framework . Coordi nator . abort ( Coordi nator . j ava : 238)
s i mul at i on . framework . Coordi nator . moni tor ( Coordi nator . j ava : 201)
s i mul at i on . framework . Coordi nator . begi nActi on ( Coordi nator . j ava : 183)
s i mul at i on . framework . Coordi nator . begi nTrans ( Coordi nator . j ava : 173)
s i mul at i on . framework . Coordi nator . r e c I ni t Re que s t ( Coordi nator . j ava : 163)
s i mul at i on . framework . Coordi nator . run ( Coordi nator . j ava : 83)
====================================================== e r r or #1
br . usp . j pf . propert y . caa . Rol l backTransact i onProper t y
s i mul at i on . database . BankDatabase . r ol l bac k ( )V
====================================================== t r ac e #1
. . .
( cdi go de rastreamento que mostra a execuo que r e s ul t ou na vi ol a o da pr opr i edade )
. . .
====================================================== snapshot #1
no l i v e t hr eads
====================================================== r e s u l t s
e r r or #1: br . usp . j pf . propert y . caa . Rol l backTransact i onProper t y "simulation.database.
BankDatabase.rollback()V"
====================================================== s ear ch f i ni s he d : 03/08/10 13: 26
Quando a propriedade no satisfeita, impressa a pilha de execuo da thread que violou a
propriedade, para que seja possvel identicar os mtodos chamados que resultaram nesta violao.
Em seguida, o mtodo que causou esta situao apresentado, seguido do cdigo de rastreamento
que apresenta a execuo feita pelo vericador que resultou na violao.
EXEMPLO DE USO 77
5.4.2 Propriedade 2: Tratamento das Excees
Nesta propriedade, checado se o mtodo suspend (responsvel por interromper as atividades
dos participantes) chamado e, em seguida, vericado se ou o mtodo handle (responsvel pelo
tratamento na prpria ao em que a exceo foi lanada) ou o mtodo signal (responsvel por
propagar a exceo para a ao pai) so chamados. Com a chamada destes mtodos, o tratamento
cooperativo das excees realizado e, portanto, a propriedade satisfeita.
Para violar esta propriedade, devemos rodar o exemplo com a seguinte alterao no mtodo
choose, da classe Coordinator do framework (ver Seo 4.4):
public void choose ( ) {
i f ( cont ai ns Except i on ( ) ) {
anyMethod ( ) ; //ERRO: no chama s i g na l
} el se {
handl e ( ) ;
}
}
Com esta modicao, quando a exceo deveria ser propagada, um mtodo qualquer, que no
signal, chamado. Isto acarreta na violao desta propriedade, como pode ser visto na sada da
ferramenta JPF Exceptions:
====================================================== s ear ch s t ar t e d : 03/08/10 13: 28
s i mul at i on . framework . Coordi nator . anyMethod( Coordi nator . j ava : 321)
====================================================== e r r or #1
br . usp . j pf . propert y . caa . Handl i ngExcepti onProperty
====================================================== t r ac e #1
. . .
( cdi go de rastreamento que mostra a execuo que r e s ul t ou na vi ol a o da pr opr i edade )
. . .
====================================================== snapshot #1
====================================================== r e s u l t s
e r r or #1: br . usp . j pf . propert y . caa . Handl i ngExcepti onProperty
====================================================== s ear ch f i ni s he d : 03/08/10 13: 29
De modo anlogo ao que ocorreu na propriedade anterior, quando a propriedade no satisfeita,
impressa a pilha de execuo da thread que violou a propriedade, para que seja possvel identicar
os mtodos chamados que resultaram nesta violao. No caso desta propriedade, o mtodo que
causou esta violao no apresentado explicitamente, mas pode ser identicado ao analisar a
pilha de execuo da thread. Assim, aps a pilha apresentada a propriedade violada e o cdigo
de rastreamento que apresenta a execuo feita pelo vericador que resultou na violao.
5.5 Concluso
Neste captulo apresentamos as propriedades sobre aes CA descritas formalmente em trabalhos
da rea [RRS
+
98, FRR05, CFRR09, Per07, PdM10], e destacamos as de real interesse neste projeto,
que correspondem s propriedades que envolvem o tratamento das excees. Apesar das limitaes
encontradas (ver Seo 5.2.3) para implementar as propriedades no vericador JPF [VHB
+
03, Jav],
utilizado na ferramenta JPF Exceptions [Xav08], foi possvel implementar duas propriedades: a
propriedade de desfazimento de transaes, que estabelece que no caso da ao terminar excep-
cionalmente ou em aborto as transaes devem ser desfeitas; e a propriedade de tratamento de
excees, que dene que quando h um lanamento de exceo, esta deve ser devidamente tratada
ou propagada para a ao pai.
A implementao destas propriedades conta com o modelo de aes CA (ver Seo 4.4) para
checar a chamada dos mtodos relativos ao desfazimento e conrmao de transaes, e ao trata-
mento e/ou propagao de excees nas aes CA. Estas propriedades foram adicionadas ao cdigo
da ferramenta JPF Exceptions, aumentando assim as opes de vericao da ferramenta.
No prximo captulo, vamos mostrar a abordagem de validao e vericao, a integrao das
ferramentas de teste e vericao, OConGraX [HM07, NHdM09] e JPF Exceptions, e sua aplicao
em cdigo Java que utilize o protocolo de coordenao de componentes denido pelas aes CA.
Captulo 6
Integrao de Teste e Vericao
Neste captulo apresentamos a abordagem de validao e vericao (V&V), na qual os processos
de teste e vericao de software so usados de modo integrado. Resultados interessantes podem
ser obtidos com esta abordagem, que pretendemos seguir neste trabalho com a integrao das
ferramentas OConGraX [HM07, NHdM09] e JPF Exceptions [Xav08]. Desta forma, os seguintes
tpicos sero tratados aqui:
o conceito de validao e vericao;
a integrao entre a OConGraX e a JPF Exceptions, sendo esta explicada por meio da abor-
dagem destes itens:
descrio das ferramentas;
descrio da integrao das ferramentas feita por XML e interface grca.
6.1 Validao e Vericao (V&V)
Os conceitos de validao e vericao so importantes no que diz respeito qualidade do
software desenvolvido. Embora paream iguais, estes conceitos so complementares e distintos,
representando aspectos diferentes a serem assegurados pela qualidade do produto. De modo claro e
sucinto, Boehm [Boe81], os deniu da seguinte maneira:
Validao: certica que o produto construdo o correto;
Vericao: certica que o produto foi construdo corretamente.
Em outras palavras, a validao assegura que o produto nal est de acordo com as expectativas
do cliente, enquanto que a vericao assegura que a implementao do produto satisfaz suas
especicaes [Som06]. De uma maneira geral, pode-se armar que a validao feita por meio
dos testes (ver Captulo 2), enquanto que a vericao feita por meio da vericao formal de
programas (ver Captulo 3).
Para entender a complementaridade destes dois conceitos, devemos relembrar as denies de
teste e vericao de programas. Os testes nos garantem que o software realiza suas funes e se
comporta conforme o esperado, mas apenas para um certo conjunto de testes e casos de teste.
A vericao formal, por sua vez, garante a corretude da implementao do programa dada sua
especicao. Alguns benefcios que podem ser obtidos por meio da utilizao conjunta de testes
e vericao seriam, por exemplo, o uso dos resultados das atividades de teste para especicar as
propriedades a serem vericadas, e o uso de especicaes para guiar os casos de teste [XHdM08].
Outros resultados interessantes que podem ser obtidos fazendo uso desta caracterstica de comple-
mentaridade seriam:
79
80 INTEGRAO DE TESTE E VERIFICAO
Gerao de casos de teste por meio do uso dos contra-exemplos gerados pelo model checker
[Tra00];
Reduo do espao de testes por meio do relatrio resultante da vericao [XHdM08].
Neste trabalho, estamos interessados na reduo do espao de testes, por meio da integrao
entre as ferramentas OConGraX [HM07, NHdM09] e JPF Exceptions [Xav08]. Maiores detalhes so
dados a seguir.
6.1.1 Abordagem Teste + Vericao
Devido aos benefcios da utilizao conjunta de teste e vericao, muitos trabalhos foram
desenvolvidos nesta rea [FWA09]. Algumas abordagens de validao e vericao buscam testar a
especicao formal do sistema, almejando perceber e minimizar o nmero de defeitos de software no
incio dos projetos [ABM98, CSE96, GH99, Mac00]. Outros trabalhos focam em apontar partes do
programa em que um defeito encontrado, medida que propriedades so formalmente vericadas
[DHJ
+
01, EM04, HDD
+
03, HD01, PDV01b, RRDH03].
A abordagem aqui utilizada consiste no uso dos dados de rastreamento gerados pelo vericador
de modelos para reduzir o espao de testes necessrio para garantir a robustez de um programa.
Ela diferencia-se das demais por focar o seu uso em sistemas tolerantes a falhas. Na Figura 6.1 um
esquema ilustrando esta abordagem mostrado.
Figura 6.1: Esquema da Abordagem Teste + Vericao [XHdM08]
Neste trabalho, pretendemos alcanar a reduo de espaos de teste fazendo a integrao da
OConGraX com a JPF Exceptions. Esta integrao permite sua aplicao a sistemas tolerantes a
falhas, uma vez que ambas as ferramentas oferecem suporte aos mecanismos de tratamento de exce-
o Java: a OConGraX, por meio da gerao do OCFG com informaes adicionais de tratamento
de exceo, e dos requisitos de teste para critrios que englobam tais mecanismos [SH98, SH99]; e
a JPF Exceptions pela denio de propriedades relativas ao tratamento das excees.
Para alcanar a reduo do espao de testes, a ideia de, a partir da gerao dos requisitos de
teste (para certos critrios [CK99, SH99]) pela OConGraX, utilizar o vericador da JPF Exceptions
para rastrear quais foram cobertos durante a execuo da vericao do programa, satisfazendo as
propriedades. Com isso, obtemos a quantidade de requisitos que j foram cobertos tirando a neces-
sidade de criar casos de teste para eles e, portanto, temos o espao de testes reduzido [XHdM08].
OCONGRAX 81
6.2 OConGraX
A OConGraX (Object Control Flow Graph with eXceptions) [NdM04, HM07], uma ferramenta
criada com o objetivo de auxiliar a realizao de testes estruturais em programas Java. Suas prin-
cipais caractersticas so:
Interface Grca de fcil interao com o usurio;
Leitura e Anlise de um Projeto Java, de modo a devolver:
Denies e Usos de Objetos e Excees;
Pares de denio-uso de Objetos e Excees;
Grafo de Fluxo de Controle de Objetos (OCFG) com informaes sobre as estruturas
de tratamento de exceo (try, catch, throw, nally) utilizadas no projeto Java recebido
como entrada.
Salvar os dados de Denies e Usos de Objetos e Excees num arquivo XML;
Salvar o grafo gerado como arquivo de imagem.
A seguir, sero apresentados maiores detalhes sobre a arquitetura e desenvolvimento da ferra-
menta, alm de uma descrio mais detalhada de suas funcionalidades.
6.2.1 Arquitetura da Ferramenta
A OConGraX foi desenvolvida utilizando a IDE Eclipse 3.4
1
, e escrita em Java 6. Possui apro-
ximadamente 5500 linhas de cdigo distribudas em 6 pacotes principais:
br . usp . ime . ocongrax . graph
br . usp . ime . ocongrax . program . c ont r ol
br . usp . ime . ocongrax . program . data
br . usp . ime . ocongrax . program . f i l e
br . usp . ime . ocongrax . program . f i l e . f i l t e r s
br . usp . ime . ocongrax . program . vi ew
Listagem 6.1: Pacotes do cdigo-fonte da OConGraX
Estes seis pacotes podem, ainda, ser categorizados nas quatro principais partes que compem a
arquitetura da ferramenta, esquematizada na Figura 6.2. Detalhes sobre cada parte da arquitetura
so mostradas na sequncia:
Figura 6.2: Esquema da arquitetura da OConGraX
1
http://www.eclipse.org
Interface Grca (Graphic User Interface ou GUI ): feita utilizando Java Swing, a in-
terface grca (ver Figura 6.3) d ao usurio acesso rpido e simples a todas as funcionalidades
da OConGraX. Para facilitar a visualizao das informaes retornadas pela ferramenta, o
painel foi dividido em duas partes, utilizando-se o componente JSplitPane do Java Swing:
esquerda, est a rvore de informaes contendo todos os dados relativos s denies e usos
de objetos e excees, organizados de acordo com o mtodo, classe e pacote a que pertencem;
direita, por meio de uma navegao por abas, possvel visualizar as denies e usos de
objetos e excees, os pares du de objetos e excees e o grafo de uxo de controle.
Pacotes: br.usp.ime.ocongrax.program.view
Figura 6.3: GUI da OConGraX
Parser: feito com o auxlio do framework Recoder [Rec], o responsvel por processar os
arquivos .java e identicar os dados referentes a objetos e excees (como, por exemplo,
suas denies e usos). Estes dados so ento armazenados em estruturas de dados criadas
para facilitar seu uso na gerao do grafo de uxo de controle e na gerao do arquivo XML
com os dados das denies e usos de objetos e excees.
Pacotes: br.usp.ime.ocongrax.program.control, br.usp.ime.ocongrax.program.data
Construtor do Grafo: utilizando-se do framework JGraph [JGr], ele constri e mostra o
grafo de uxo de controle feito por meio do processamento das informaes de denies e
usos de objetos e excees obtidos anteriormente pelo parser.
Pacotes: br.usp.ime.ocongrax.graph
Gerador de Arquivos: por meio de requisio feita pelo usurio via GUI, possvel gerar
arquivos de imagem do grafo nos formatos .jpg, .jpeg, .gif, .bmp e .png, e gerar um documento
XML contendo as informaes de denio e uso de objetos e excees.
Pacotes: br.usp.ime.ocongrax.program.file, br.usp.ime.ocongrax.program.file.filters
6.2.2 Funcionalidades da OConGraX
Nesta seo so descritas todas as funcionalidades da OConGraX. Para ilustrar cada uma delas,
vamos utilizar o cdigo mostrado na Listagem 6.2, adaptado de [Xav08]:
1 public cl ass CatchExceptionExample {
2
3 stati c CatchExceptionExample obj ;
4
OCONGRAX 83
6 try {
7 obj = new CatchExceptionExample ( ) ;
8 obj . method ( ) ;
10 e . pr i nt St ackTr ace ( ) ;
11 }
12 }
13 private void method ( ) throws Excepti on{
14 Excepti on exc = new Excepti on ( ) ;
15 throw exc ;
16 }
17 }
Listagem 6.2: Cdigo do exemplo
Denio, Uso e Pares du de Objetos
A implementao da denio, uso e pares du de objetos foi feita baseada nos critrios de teste
descritos na Seo 2.7.1, e propostos por Chen e Kao [CK99]. A identicao de cada denio
e uso feita por meio do Parser: a cada denio identicada na varredura do arquivo .java,
ele armazena o dado num vetor que contm todas as denies de objeto encontradas; o anlogo
acontece a cada uso identicado, sendo este armazenado num vetor que contm todos os usos de
objeto encontrados na varredura dos arquivos. Munida com estes dados, a ferramenta verica os
pares formados, armazenando-os num vetor de pares.
Figura 6.4: Visualizao das denies e usos do mtodo main do exemplo 6.2, em que pode-se ver as
denies e usos do objeto obj.
Para visualizar os dados de denies e usos de objetos, pode-se abrir a aba Def-Use ou
visualizar na rvore de informaes exibida no painel esquerda. Para ver os pares, basta abrir a
aba Def-Use Pairs.
Figura 6.5: Visualizao dos pares du do objeto obj, do exemplo 6.2.
Denio, Uso e Pares du de Excees
A implementao desta funcionalidade foi feita de acordo com o conceito apresentado na Seo
2.8, proposto por Sinha e Harrold [SH98, SH99]. A obteno das denies e usos das excees
foi realizada de modo anlogo a dos objetos: no momento que a leitura realizada (por meio de
uma varredura nas classes e mtodos dos arquivos .java do sistema recebido como entrada), as
denies e usos so armazenadas, respectivamente, num vetor de denies e num vetor de usos.
Estes vetores armazenam todas as denies e usos de objetos e excees do sistema.
A visualizao das denies e usos das excees pode ser feita em trs locais: na aba especca
para visualizao de denies e usos, Def-Use Exc, em que apenas as denies e usos de excees
aparecem, numa notao semelhante a especicada por Sinha e Harrold [SH98, SH99]; na rvore,
mostrada do lado esquerdo do frame da ferramenta; ou na aba Def-Use. Nas duas ltimas, no h
diferenciao nas linhas de denio e uso de objetos e excees, ou seja, todas as linhas em que
h denio e/ou uso de objetos e excees num mtodo (mtodo este escolhido pelo usurio, na
interface) so mostradas.
(a) Visualizao das denies e usos (Aba: Def-
Use) do mtodo method do exemplo 6.2.
(b) Visualizao das denies e usos (Aba: Def-
Use Exc) do mtodo method do exemplo 6.2.
(c) Visualizao dos pares du da exceo exc, do
exemplo 6.2.
Figura 6.6: Screenshots mostrando algumas das funcionalidades da OConGraX.
Gerao do XML
Para poder compartilhar as informaes de denies e usos de objetos e excees, a ferramenta
gera um arquivo com estas informaes no formato XML (eXtensible Markup Language) [W3 ,
Sunb].
1 <?xml version=" 1. 0 " encodi ng=" i s o 88591"?>
2 <el ements>
3 <obj e c t>
OCONGRAX 85
4 <cl assname>. . . </ cl assname>
5 <methodname>. . . </methodname>
6 <name>. . . </name>
7 <pai r>
8 <def>. . . </ def>
9 <use>. . . </ use>
10 </ pai r>
11 . . .
12 <def>. . . </ def>
13 . . .
14 <use>. . . </ use>
15 . . .
16 </ obj e c t>
17 <except i on>
20 <name>. . . </name>
21 <pai r>
22 <def>. . . </ def>
23 <use>. . . </ use>
24 </ pai r>
25 . . .
26 <def>. . . </ def>
27 . . .
28 <use>. . . </ use>
29 . . .
30 </ except i on>
31 </ el ements>
Listagem 6.3: Estrutura do arquivo XML gerado pela OConGraX
A linguagem XML foi utilizada no apenas por apresentar os dados de uma maneira estrutu-
rada, mas tambm por ser recomendada pela W3C (World Wide Web Consortium)
2
e ser exvel,
permitindo que a estrutura a ser utilizada seja denida pelo programador.
A estrutura do arquivo XML utilizada na OConGraX mostrada na Listagem 6.3. A verso de
XML utilizada a 1.0, e a codicao, ISO 8859-1, correspondente s linguas ocidentais.
O elemento raiz elements. Seus lhos so object e exception:
O elemento object armazena os dados de um objeto. Possui os sub-elementos classname,
methodname, name, pair, def e use. Cada sub-elemento armazena, respectivamente, o
nome da classe a qual o objeto pertence, o nome do mtodo a que ele pertence, o nome do objeto, o
par du (com os dados: nmero da linha em que ocorre a denio, e nmero da linha em que ocorre
o uso)
3
, o nmero da linha em que o objeto denido, e o nmero da linha em que ele usado.
Estes mesmos sub-elementos so encontrados para o elemento exception, que armazena os dados
relativos a uma exceo do sistema.
Na OConGraX, so oferecidas algumas opes para gerar o arquivo XML, conforme pode ser
visto na Figura 6.7. Isto foi feito para dar maior exibilidade para o usurio, permitindo que ele
obtenha no XML apenas as informaes relevantes necessrias para ele aplicar critrios de testes
[CK99, SH99] no software que ele deseja testar.
Para o trabalho deste Mestrado, o modo como gerado este XML foi modicado. Mais especi-
camente, a alterao foi feita no pacote br.usp.ime.ocongrax.program.data, que contm
a classe Pair.java (responsvel pelo armazenamento dos dados do par du), e no pacote
br.usp.ime.ocongrax.program.file (responsvel pela gerao do arquivo XML com as in-
formaes de denies e usos de objetos e excees), na classe XMLGenerator.java, para, no
caso de termos um par externo (par no qual o uso de um objeto/exceo ocorre num mtodo dis-
tinto ao da denio), podermos representar suas informaes de uma maneira adequada. Maiores
detalhes sobre as alteraes feitas sero dadas na Seo 6.4.2.
2
http://www.w3.org
3
No caso do par (uso) pertencer a outro mtodo, armazenado no somente o nmero da linha em que ele se
encontra, mas tambm seu nome e a classe em que ele pertence
Figura 6.7: Tela com as opes para gerao do arquivo XML
Grafo de Fluxo de Controle
O grafo gerado pela ferramenta o grafo de uxo de controle de objetos com informaes
adicionais sobre os mecanismos de tratamento de exceo. Sua construo baseada na teoria
apresentada no Captulo 2.8.
Na OConGraX, o grafo gerado referente a um objeto de uma classe ou a uma exceo da
classe. Tanto a classe quanto o objeto/exceo podem ser escolhidos pelo usurio. Alm disso, o
grafo pode ser editado pelo usurio
4
, e a opo Full Graph, que quando marcada faz com que sejam
visualizados todos os ns dos mtodos representados pelo grafo e no apenas os mais relevantes para
o objeto/exceo da classe em questo, foi disponibilizada.
Figura 6.8: Visualizao do grafo de uxo de controle para a exceo e do exemplo 6.2
4
Por edio, entende-se mover os ns do grafo
JAVA PATHFINDER EXCEPTIONS 87
Apesar de ter se baseado no artigo de Sinha e Harrold [SH98], a implementao no obede-
ceu risca a notao sugerida no texto. A seguir, explicamos alguns pontos sobre os elementos
representados no grafo:
Representao dos Ns
Cada n do grafo resultante contm o nmero da linha percorrida e seu contedo. O texto
contido num n diferenciado na ferramenta por meio de cores, da seguinte maneira:
1. Se o objeto/exceo denido no cdigo daquela linha, a cor do texto utilizada na
ferramenta a verde;
2. Se o objeto/exceo usado no cdigo daquela linha, a cor do texto utilizada na ferra-
menta a azul;
3. Se o objeto/exceo denido e usado no cdigo daquela linha, a cor do texto utilizada
na ferramenta a roxa;
4. Se o contedo do n indica o incio e m de um mtodo, a cor do texto utilizada na
ferramenta a vermelha;
5. Se o contedo do n indica o incio e m de um bloco Finally, a cor do texto utilizada
na ferramenta a magenta.
Ademais, para diferenciar os ns que contm linhas pertencentes a blocos denidos por me-
canismos de tratamento de exceo (try, catch, nally), ou que contenham o comando throw,
eles foram pintados em tom alaranjado. Os demais ns passaram a ser coloridos em tom de
azul.
Arestas
As arestas de controle (representadas por setas desenhadas com linha cheia) mostram os
caminhos com os uxos de execues possveis dentro de um mesmo mtodo. No caso de ligar
ns que contenham algum elemento pertencente a uma estrutura de tratamento de exceo,
as arestas passam a ser laranjas, e no mais pretas.
As arestas passa-mensagem (representadas por setas desenhadas com linha tracejada) mos-
tram os caminhos com os uxos de execues possveis entre mtodos distintos, que podem
estar inclusive em classes diferentes. Com o acrscimo do caso das excees, as arestas trace-
jadas passaram a ligar no apenas chamadas a mtodos existentes no cdigo recebido como
entrada, mas tambm os ns throw e catch que formam pares de denio-uso. O uso das
cores anlogo ao feito para as arestas de controle.
Alm de gerar, a OConGraX permite que o usurio faa a manipulao
5
do grafo e o salve como
um arquivo de imagem. Permitir manipular o grafo d exibilidade ao usurio, enquanto salvar o
grafo como arquivo de imagem d a ele a chance de utilizar o grafo e as informaes nele contidas em
outros aplicativos de testes e vericao de programas, alm de permitir que o grafo seja impresso.
6.3 Java PathFinder Exceptions
O aplicativo Java PathFinder Exceptions [Xav08] utiliza a Java PathFinder, ferramenta respon-
svel por vericar as propriedades e gerar o rastreamento de instrues executadas. Ele possui uma
interface grca que permite a seleo do programa e das propriedades relativas a tratamento de
exceo a serem testadas, bem como exibir as estatsticas de cobertura dos critrios. Alm disso, ela
permite a congurao dinmica da ferramenta JPF sem a necessidade de alterao dos arquivos
de propriedades.
Maiores informaes sobre o vericador Java PathFinder e das propriedades relativas a trata-
mento de exceo testadas so dadas a seguir.
5
Por manipulao, entende-se mover e alterar o tamanho dos ns do grafo.
6.3.1 Java PathFinder
Java PathFinder (JPF)
6
um vericador de modelo desenvolvido pelo centro de pesquisas da
NASA. Ele funciona como uma JVM executando um programa alvo de todas as maneiras possveis,
procurando por violaes de propriedades como deadlocks ou excees no tratadas. Caso um erro
seja encontrado, todos os passos seguidos at a ocorrncia do erro so exibidos.
Uma diferena no uso de vericao de modelos em comparao aos testes est na simulao do
no determinismo. O JPF oferece duas caractersticas importantes que auxiliam nesta vericao:
Backtracking: o JPF pode retornar aos passos anteriores da execuo do programa, para
vericar se existem estados no executados. Isto mais eciente do que executar novamente
o programa do incio.
State Matching: o estado do sistema armazenado como um par de uma amostra do heap
e do stack da thread executando. Quando um estado j visitado encontrado, o JPF executa
o backtracking at encontrar um estado novo inexplorado.
Programas grandes podem ocasionar uma exploso de estados, que consiste na gerao de um
nmero muito grande de estados a serem vericados em busca da violao de propriedades. De
forma a minimizar este problema, o JPF conta com os seguintes recursos:
1. Estratgias de busca congurveis: consiste na aplicao de ltros que determinam que
estados so interessantes ou no vericar.
2. Reduo do nmero de estados: a ferramenta utiliza alguns mecanismos, listados a seguir:
Geradores de escolha heursticos: consiste em restringir as escolhas de valores para
teste de estado. Por exemplo, considere um valor oat (representao de nmero real em
Java) de entrada no-determinstica, e um valor limite. Para vericar o comportamento
do sistema, ao invs de gerar todos os possveis valores do tipo oat, bastaria comparar
se ele menor, igual ou maior do que o valor limite, reduzindo assim o nmero de estados
a serem varridos pela vericao.
Reduo de ordem parcial: o mecanismo mais importante em programas concorren-
tes. Consiste em levar em considerao apenas operaes que podem ter efeitos em outras
threads, como instrues que alteram objetos acessveis externamente. Para realizar esta
reduo dinamicamente e sem a interveno do usurio, o JPF utiliza o bytecode de
Java e obtm a informao de alcance dos efeitos das operaes do Garbage Collector
(processo de gerenciamento de memria). Com a reduo de ordem parcial, operaes
com efeito puramente local so desconsideradas, reduzindo assim o nmero de estados a
serem percorridos durante a vericao.
Execuo de VM aninhada: o JPF executa sobre a JVM nativa. Isto permite que
determinadas operaes sejam delegadas para a JVM nativa ao invs de executadas pelo
JPF. Desta forma, estas execues no tm seu estado rastreado.
O JPF oferece, ainda, alguns mecanismos que permitem sua extenso:
Search/VMListeners: permitida a criao de classes Java que utilizam o padro de projeto
Observer para serem noticados quando ocorrem eventos como execuo de determinadas
instrues de bytecode ou avano/retrocesso nos passos de execuo. Podemos utilizar estes
elementos para vericao de propriedades complexas, executar buscas, estender o modelo de
estado interno do JPF ou colher estatsticas de execuo do programa, como por exemplo, a
sequncia de instrues executada.
6
http://javapathnder.sourceforge.net/
Model Java Interface(MJI): permite a separao da execuo com rastreamento de estado
do JPF e a execuo nativa da JVM. Pode ser utilizada para construo de abstraes de
APIs que reduzem a gerao de estados necessria.
Apesar de seus vrios pontos positivos, como o suporte a tratamentos de exceo, suporte a
elementos introduzidos pelas novas verses de Java (como a tipagem de variveis introduzida com
o Java 5) e a extensibilidade nas propriedades testadas (alm de suportar originalmente testes nas
propriedades de deadlock, asseres e excees no tratadas, permite a criao de novas proprie-
dades), h alguns pontos negativos, como a inexistncia de interface grca e o fato do JPF no
permitir o uso de outros vericadores de modelo. Particularmente, a inexistncia de interface grca
um problema que foi sanado com a JPF Exceptions.
6.3.2 Propriedades Relativas a Tratamento de Exceo
No JPF Exceptions, foram criadas algumas propriedades a serem vericadas com a ferramenta
Java PathFinder. A abordagem utilizada foi selecionar algumas prticas usadas comumente no
tratamento de excees em Java e transform-las em propriedades da ferramenta. importante
ressaltar que mesmo que no se deseje utilizar a ferramenta para diminuir o espao de testes ou
gerao de casos de uso manuais, podemos utiliz-la para melhorar a qualidade do cdigo, garantindo
que certas prticas no ocorrem.
Propriedades no Java PathFinder
Um dos motivos da escolha da ferramenta JPF para utilizao neste trabalho, foi a facilidade
na sua customizao e criao de propriedades. Todas as propriedades no JPF so classes Java que
implementam uma interface comum: gov.nasa.jpf.Property.
Outra caracterstica importante utilizada foi a capacidade de criar classes (listeners) que so
noticadas pela ferramenta na ocorrncia de eventos relativos a execuo do cdigo, como execu-
o de instrues e lanamento de excees. Para isso existem algumas interfaces que devem ser
implementadas pelas classes interessadas na noticao de eventos. A criao destas classes segue
o padro de projeto Observer[GHJV00].
Assim, para criao de propriedades customizadas basta criar uma implementao de Property
e registr-la para vericao com a ferramenta. Este registro poder ser feito via customizao
do arquivo de inicializao padro da ferramenta (jpf.properties) ou em tempo de execuo
via cdigo. Normalmente, dependendo apenas da propriedade, devem tambm ser criadas classes
listener para monitorar a execuo da ferramenta.
No caso deste trabalho, como foi necessrio criar um listener para cada propriedade, optou-se
por utilizar uma superclasse disponvel na ferramenta especicamente para estes casos denominada
PropertyListenerAdapter. Todas as propriedades criadas so subclasses de PropertyListenerAdapter.
Apresentao de Prticas Relativas ao Tratamento de Excees
Aqui apresentamos algumas prticas relativas a tratamento de excees, que foram estudadas
junto com suas respectivas propriedades. Estes estudos foram feitos, pois as propriedades de co-
ordenao a serem denidas e implementadas neste trabalho do Mestrado sero desenvolvidas de
maneira similar.
Denominamos Tratamento de Excees o cdigo criado para o tratamento das condies ex-
cepcionais. As condies excepcionais so diferentes dos bugs, e podem ser denidas como problemas
que impedem a continuao da execuo de um cdigo [Eck02]. Exemplos de condies excepcionais
envolvem a perda de uma conexo de rede, a queda de um servidor de bancos de dados, a leitura
de um arquivo de entrada mal-formatado, entre outros.
Linguagens mais modernas como o Java e o C++ incluem estruturas para tratamento de ex-
cees na prpria sintaxe. Quando bem utilizadas, estas estruturas podem melhorar a legibilidade,
conabilidade e manutenibilidade de um programa[Blo01].
Para auxiliar a identicao da presena de prticas relativas ao tratamento de excees que po-
dem dicultar a tarefa de manuteno do sistema[McC, RS03], o seguinte conjunto de propriedades
foram implementadas para o Java PathFinder:
1. Lanar java.lang.Exception na assinatura do mtodo: ocorre quando execu-
tada uma instruo correspondente chamada de um mtodo e java.lang.Exception
pertence ao conjunto de excees lanadas na assinatura do mtodo. O problema que
java.lang.Exception muito genrica, no fornecendo informaes teis sobre os er-
ros que podem ocorrer no processamento do mtodo.
2. Lanar um grande nmero de excees na assinatura do mtodo: ocorre quando
executada uma instruo correspondente chamada de um mtodo e o nmero de elementos
no conjunto de excees lanadas pelo mtodo maior do que n e este conjunto no est
contido no conjunto de tratadores de exceo presentes no cdigo que o chama. O problema
que isto s vlido se cada exceo necessitar de um tratamento diferenciado. Em caso
contrrio, apenas polui o cdigo.
3. Declarar uma exceo na assinatura do mtodo que nunca lanada: ocorre quando
executada uma instruo correspondente chamada de um mtodo e existem excees
pertencentes ao conjunto de excees lanadas pelo mtodo, que no possuem um correspon-
dente comando throw contido no corpo do mtodo, direta ou indiretamente. No necessrio
vericar se o mtodo abstrato, pois necessria uma implementao concreta para ser exe-
cutada. O problema que isto s vlido na denio de mtodos abstratos, alm de obrigar
o desenvolvedor a capturar excees que nunca sero lanadas.
4. Capturar e ignorar a exceo: ocorre quando uma exceo lanada e seu tratamento
consiste em um bloco de cdigo vazio, isto , ocorre quando uma exceo capturada por um
bloco catch vazio. O problema que isto esconde que ocorreram erros na execuo.
5. Capturar java.lang.Exception: ocorre quando executada uma instruo dentro de um
mtodo que possui um bloco de captura de java.lang.Exception em seu cdigo. O ruim que
isto pode gerar problemas se o mtodo que est sendo tratado for modicado para lanar
novas excees que devem ser manipuladas de modo diferenciado, pois o cdigo tratador no
car ciente de que existe esta nova exceo.
Para exemplicar o modo de implementao de uma propriedade, apresentamos no Apndice C
o cdigo fonte da propriedade referente ao bloco de captura vazio (identicada acima como a m
prtica de capturar e ignorar a exceo).
6.3.3 Funcionalidades do Java PathFinder Exceptions
Nesta seo so apresentadas as funcionalidades do Java PathFinder Exceptions. Elas permitem
que o testador congure o Java PathFinder para executar o programa desejado, alm de permitir
a vericao das propriedades citadas anteriormente e dar estatsticas relacionadas cobertura do
cdigo vericado.
Seleo do projeto e congurao do JPF Exceptions
A seleo do projeto a ser analisado feita na aba JPFConfig (Figura 6.9). Conforme pode ser
visto na Figura 6.9, h vrios campos que o testador deve preencher para que a ferramenta possa
localizar o projeto adequadamente:
Base Dir: diretrio raiz do projeto a ser analisado, com o seu cdigo fonte (arquivos .java);
ClassPath: diretrio onde se encontram os arquivos .class do projeto;
Figura 6.9: Tela para seleo do projeto a ser vericado
Main Class: arquivo .java que contm o mtodo main de execuo do projeto;
Max Depth: congura a restrio de profundidade mxima de busca da ferramenta, durante
a vericao, de modo a limitar a vericao em programas muito grandes ou que possam
entrar em loops innitos.
Seleo das propriedades
Na aba Properties (Figura 6.10), pode-se selecionar as propriedades a serem vericadas
(ver Seo 6.3.2), tanto as de tratamento de exceo quanto as nativas, presentes inicialmente no
vericador JPF.
Figura 6.10: Tela para seleo das propriedades
Seleo dos Listeners
Na aba Listeners (Figura 6.11), pode-se habilitar o listener ExceptionChoiceGenerator,
que para cada mtodo executado que declara lanar excees, o cdigo executado simulando o
lanamento de cada uma das excees declaradas, bem como a execuo sem lanar excees. Por
padro, somente sero gerados lanamentos de exceo para mtodos desenvolvidos pelo programa-
dor, mas possvel habilitar esta opo tambm para classes do prprio Java.
Figura 6.11: Tela para seleo dos listeners
Outro listener que pode ser habilitado o do rastreamento da execuo do programa. Pode-se
marcar para gerar um arquivo texto com toda a execuo e, ainda, fazer a vericao dos pares
cobertos: basta informar o caminho para o arquivo XML com as informaes de denies e usos de
objetos e excees, e ainda os locais para salvar os arquivos ok.xml e notOk.xml, que imprimem,
respectivamente, as linhas de critrios percorridas e as no percorridas.
Uma observao importante a ser feita a de que, inicialmente, estava prevista uma integrao
com a ferramenta OConGraX, como pode ser notado pelo campo OcongraXML. Entretanto, esta
integrao no foi realizada satisfatoriamente pois os modelos XML implementados em cada um
era diferente. O modelo XML esperado pelo JPF Exceptions era como o mostrado na Listagem 6.4.
2 <el ements>
3 <obj e c t>
5 <name>. . . </name>
6 <pai r>
7 <def>. . . </ def>
8 <use>. . . </ use>
9 </ pai r>
10 . . .
11 </ obj e c t>
12 <except i on>
14 <name>. . . </name>
15 <pai r>
16 <def>. . . </ def>
17 <use>. . . </ use>
18 </ pai r>
19 . . .
20 </ except i on>
21 </ el ements>
Listagem 6.4: Modelo XML lido pelo JPF Exceptions
Como pode ser visto, este modelo diferente do da OConGraX, apresentado na Listagem 6.3.
Alm disso, o JPF Exceptions no suportava a leitura da informao de pares externos como feita
na OConGraX, na qual aparecia na tag use no apenas o nmero da linha do uso, mas tambm
o nome da varivel no mtodo externo no qual ocorria o uso e o nome da classe a qual este uso
pertencia. Desta forma, em [Xav08], foram geradas entradas XML manualmente, e no geradas pela
OConGraX, para efeitos de teste do aplicativo JPF Exceptions.
Por esta razo, neste trabalho de mestrado, denimos um novo modelo XML que permite uma
integrao real entre essas duas ferramentas. Informaes mais detalhadas sero dadas na Seo
6.4.
Estatsticas de cobertura
Na aba Results (Figura 6.12), aparecem as estatsticas de cobertura aps a vericao. As
estatsticas aparecem ao se clicar no boto Process. Para limpar a tela com os resultados, basta
clicar em Reset.
Figura 6.12: Tela de estatsticas de cobertura
Rastreamento de dados
A aba State (Figura 6.13) exibe as estatsticas relativas aos estados gerados pela ferramenta,
como nmero de estados visitados, por exemplo. Para que as estatsticas sejam geradas e exibidas
pela ferramenta, necessrio habilit-las selecionando o checkbox.
Figura 6.13: Tela de rastreamento de dados
Boto Run
Localizado no inferior da tela do aplicativo, o responsvel por executar o aplicativo JPF
Exceptions e iniciar a vericao de propriedades. Ao nal da vericao, pode exibir as seguintes
mensagens:
No property violated: nenhuma propriedade foi violada.
Property X violated: a propriedade de nome X foi violada.
Constraint Hit: a vericao interrompida devido a uma restrio de busca, como por
exemplo a restrio de profundidade congurada na primeira aba do JPF Exceptions (ver
Figura 6.9).
6.4 Integrao das ferramentas via XML
Conforme visto na Seo 1.2, um dos objetivos deste trabalho a realizao de uma integrao
das ferramentas via um documento XML, conforme pode ser visto na Figura 6.14.
Figura 6.14: Esquema da integrao via XML entre OConGraX e JPF Exceptions
Para esta integrao, necessria a denio de um modelo XML que permita tal integrao,
a gerao deste XML pela OConGraX e a leitura deste XML pela JPF Exceptions. Estas trs
atividades foram realizadas, e detalhes sobre sua implementao so dadas nas prximas subsees.
6.4.1 Modelo XML
Para permitir uma integrao total entre as ferramentas OConGraX e JPF Exceptions, foi
preciso denir um modelo XML que representasse de um modo estruturado os seguintes dados de
cada elemento (objeto ou exceo) do sistema analisado:
Sua identicao: classe e mtodo a que pertence, e nome;
Nmero das linhas de cdigo em que ocorre uma denio e/ou um uso do elemento;
Pares de denio-uso formados ao longo do cdigo. Estes pares podem ser:
Formados no mesmo mtodo, isto , a denio e o uso ocorrem no mesmo mtodo;
Formados em mtodos diferentes, isto , a denio ocorre num mtodo e o uso, em
outro.
Para tornar a estruturao mais simples de ser lida e entendida, foi denido um modelo XML,
apresentado na Listagem 6.5:
INTEGRAO DAS FERRAMENTAS VIA XML 95
2 <el ements>
3 <obj e c t>
6 <name>. . . </name>
7 
8 <pai r>
9 <def>. . . </ def>
10 <use>. . . </ use>
11 </ pai r>
12 
13 <e xt e r na l pa i r s>
14 <pai r>
15 <def>. . . </ def>
16 <e xt e r nal us e>
19 <name>. . . <name>
20 <l i nenumber>. . . </ l i nenumber>
21 </ e xt e r nal us e>
22 </ pai r>
23 </ e xt e r na l pa i r s>
24 <def>. . . </ def>
25 <def>. . . </ def>
26 <use>. . . </ use>
27 </ obj e c t>
28 <obj e c t>
29 . . .
30 </ obj e c t>
31 .
32 .
33 <except i on>
34 . . .
35 </ except i on>
36 .
37 .
38 .
39 <except i on>
40 . . .
41 </ except i on>
42 </ el ements>
Listagem 6.5: Modelo XML para integrao entre OConGraX e JPF Exceptions
Neste modelo, a tag elements engloba todos os elementos (objetos ou excees) do sistema que
foram denidos e usados. Inicialmente, todos os objetos (marcados pela tag object) so mostrados
para, em seguida, todas as excees (marcadas pela tag exception) serem apresentadas. Dentro
de cada objeto (ou exceo), aparecem as tags que identicam os valores obtidos, na seguinte ordem:
classname: nome da classe (no formato: <nome do pacote>.<nome da classe>) a que o
elemento pertence;
methodname: nome do mtodo a que o elemento pertence;
name: nome do elemento;
innerpairs: pares, nos quais tanto a denio quanto o uso do objeto ocorrem no mesmo
mtodo. As informaes do par so fornecidas pelas tags:
pair: identica o par;
def: nmero da linha em que ocorre a denio;
use: nmero da linha em que ocorre o uso;
externalpairs: pares, nos quais a denio do objeto ocorre no mtodo identicado pela
tag methodname, e o uso ocorre em outro mtodo. As informaes do par so fornecidas
pelas tags:
pair: identica o par;
def: nmero da linha em que ocorre a denio;
externaluse: identica o uso externo pelas tags:
classname: nome da classe (no formato: <nome do pacote>.<nome da classe>)
em que ocorre o uso externo;
methodname: nome do mtodo em que ocorre o uso externo;
name: nome do elemento neste mtodo/classe externo;
use: nmero da linha em que ocorre o uso neste mtodo/classe externo.
def: cada tag identica um nmero de linha em que ocorre uma denio do elemento no
mtodo identicado pela tag methodname;
use: cada tag identica um nmero de linha em que ocorre um uso do elemento no mtodo
identicado pela tag methodname.
Assim, com este modelo XML, a gerao do arquivo e a organizao de seus dados pela OCon-
GraX ca melhor e mais organizado (antes, na OConGraX, a identicao dos pares def-uso exter-
nos/internos no era bem estruturada e continha apenas a informao da classe externa e da linha
do uso, omitindo a informao do mtodo externo). E os dados completos so passados ao JPF
Exceptions, permitindo uma anlise completa do sistema por parte dele (antes, a leitura do arquivo
no previa as tags com valores referentes a pares def-uso externos, o que impediu uma verdadeira
integrao com a OConGraX).
6.4.2 OConGraX - Gerao do XML
Para gerar o modelo XML descrito anteriormente em 6.4.1, foi preciso alterar, basicamente, dois
pontos no cdigo:
Estrutura para armazenamento do par du
A estrutura foi modicada de modo que as informaes do uso ocorrido num mtodo ex-
terno fossem guardadas adequadamente e recuperadas posteriormente para gerao do arquivo
XML.
Inicialmente, a classe que representava e armazenava as informaes dos pares possua apenas
dois campos, referentes denio e uso de objetos e excees, como pode ser visto na Listagem
6.6. No campo uso, quando este ocorria num mtodo distinto a da denio, era armazenada
uma String contendo o nmero da linha em que ocorria o uso, o nome da varivel no mtodo
em que o uso ocorria, e o nome da classe a que este uso pertencia.
public cl ass Pai r {
St r i ng l i ne De f ;
St r i ng l i neUs e ;
. . .
}
Listagem 6.6: Campos da classe Pair antes das alteraes feitas para gerao do novo XML.
Com a necessidade de se armazenar de uma maneira mais adequada as informaes quando o
uso ocorria fora do mtodo em que a denio ocorria, foi preciso criar novos campos, e dois
construtores, como apresentados na Listagem 6.7:
public cl ass Pai r {
St r i ng l i ne De f ;
St r i ng l i neUs e ;
boolean i s I nne r Pai r ;
St r i ng external Cl assName ;
St r i ng externalMethodName ;
St r i ng external Vari abl eName ;
public Pai r ( St r i ng l i neDef , St r i ng l i neUse , boolean i s I nne r Pai r , St r i ng
external Cl assName , St r i ng externalMethodName , St r i ng
external Vari abl eName ) {
thi s . s et Li neDef ( l i ne De f ) ;
thi s . setLi neUse ( l i neUs e ) ;
thi s . s e t I nne r Pai r ( i s I nne r Pai r ) ;
thi s . setExternal Cl assName ( external Cl assName ) ;
thi s . setExternalMethodName ( externalMethodName ) ;
thi s . setExternal Vari abl eName ( external Vari abl eName ) ;
}
public Pai r ( St r i ng l i neDef , St r i ng l i neUs e ) {
thi s ( l i neDef , l i neUse , true , "" , "" , "" ) ;
}
. . .
}
Listagem 6.7: Campos da classe Pair aps as alteraes feitas para gerao do novo XML.
Com as criaes dos novos campos, as informaes podem ser acessadas separadamente, faci-
litando a recuperao delas para a gerao do XML; alm disso, possvel diferenciar agora a
natureza do par, se ele externo (em que o uso de um objeto/exceo ocorre num mtodo di-
ferente da sua respectiva denio) ou interno (denio e uso de um objeto/exceo ocorrem
num mesmo mtodo).
A criao dos construtores facilitou o armazenamento dos dados, sendo o primeiro construtor
utilizado para armazenar os dados de um par externo , e o segundo, o utilizado para armazenar
os dados de um par interno.
Gerao do arquivo XML
Para alterar a gerao do arquivo XML, de forma que ele casse como o modelo proposto na
Seo 6.4.1, foi preciso modicar a classe XMLGenerator.java, do pacote
br.usp.ime.ocongrax.program.file. As seguintes alteraes foram feitas:
Acrscimo das tags innerpairs e externalpairs, identicando, respectivamente,
os pares internos e externos de um objeto ou uma exceo;
Criao de dois mtodos utilizados para incluir os pares internos e externos, apresentando
os dados de cada um de modo organizado e estruturado.
A classe XMLGenerator.java, com as modicaes citadas acima, pode ser vista no Apndice
D.1.1.
6.4.3 JPF Exceptions - Leitura do XML
Para que fosse possvel ler este novo XML, foi preciso alterar, essencialmente, dois pontos no
cdigo do JPF Exceptions:
Estrutura de OcongraElement
Na classe OcongraElement, foi adicionado o campo isInnerPair que passar a ser utili-
zado para vericar se um par interno ou externo. Esta informao colhida durante a leitura
do arquivo XML gerado pela OConGraX, e ser utilizada na gerao dos arquivos XML de
rastreamento (ok.xml, notOk.xml).
public cl ass OcongraElement {
private St r i ng cl assName ;
private St r i ng name ;
private boolean i s I nne r Pai r ; //new f i e l d
private boolean obj e c t ;
private i nt l i ne De f ;
private St r i ng threadDef ;
private i nt l i neUs e ;
private St r i ng threadUse ;
private boolean ok ;
. . .
}
Listagem 6.8: Campos da classe OcongraElement.
Mtodo readOcongraXML
Mtodo responsvel pela leitura do arquivo XML da OConGraX, foi modicado para reco-
nhecer corretamente os pares du externos e internos representados no arquivo. Este mtodo
encontra-se na classe ExecutedPath.java, responsvel pela vericao da cobertura do
cdigo, e est disponibilizado no Apndice D.2.1.
Mtodo generateXmlFile
Mtodo encontrado na classe ExecutedPath.java, ele responsvel pela gerao dos
arquivos ok.xml e notOk.xml. Foi alterado para exibir, ao invs da tag pair, as tags
innerpair quando o par a ser impresso interno, e externalpair quando o par a ser
impresso externo. Para isso, a vericao apresentada na Listagem 6.9 foi acrescentada ao
mtodo, onde myElement corresponde a um OcongraElement.
i f ( myElement . i s I nne r Pai r ( ) )
p = doc . createEl ementNS ( null , " i nne r pai r " ) ;
el se
p = doc . createEl ementNS ( null , " e xt e r nal pai r " ) ;
Listagem 6.9: Vericao feita para a identicao mais especca dos pares du nos arquivos ok.xml e
notOk.xml.
Os demais dados referentes ao uso num par externo no foram adicionados nos arquivos XML
gerados pelo JPF Exceptions porque tais informaes podem ser encontradas no XML gerado
pela OConGraX.
6.4.4 Exemplo
Para exemplicar a integrao, geramos com a OConGraX o arquivo input.xml com todas as
informaes de denio e uso de objetos e excees do exemplo da Listagem 6.2. O XML gerado
apresentado na Listagem 6.10.
2 <el ements>
3 <obj e c t>
4 <cl assname>( de f aul t package ) . CatchExceptionExample</ cl assname>
5 <methodname>main( St r i ng )</methodname>
6 <name>obj</name>
8 <pai r>
9 <def>7</ def>
10 <use>8</ use>
11 </ pai r>
12 <pai r>
13 <def>8</ def>
14 <use>8</ use>
15 </ pai r>
17 <def>7</ def>
18 <def>8</ def>
19 <use>8</ use>
20 </ obj e c t>
21 <except i on>
24 <name>e</name>
26 <pai r>
27 <def>9</ def>
28 <use>10</ use>
29 </ pai r>
31 <def>9</ def>
32 <use>9</ use>
33 <use>10</ use>
34 </ except i on>
35 <except i on>
37 <methodname>method ( )</methodname>
38 <name>exc</name>
40 <pai r>
41 <def>14</ def>
42 <use>15</ use>
43 </ pai r>
45 <e xt e r na l pa i r s>
46 <pai r>
47 <def>15</ def>
48 <e xt e r nal us e>
51 <name>e</name>
52 <l i nenumber>9</ l i nenumber>
53 </ e xt e r nal us e>
54 </ pai r>
55 </ e xt e r na l pa i r s>
56 <def>14</ def>
57 <def>15</ def>
58 <use>15</ use>
59 </ except i on>
60 </ el ements>
Listagem 6.10: Arquivo input.xml gerado pela OConGraX.
Em seguida, utilizando o JPF Exceptions, fazemos a vericao de algumas das propriedades
referentes ao catch: bloco catch vazio e exceo no capturada, sendo que nenhuma violada pelo
exemplo (ver Figura 6.15). Ademais, utilizamos como entrada o arquivo input.xml gerado pela
OConGraX para gerar as estatsticas de cobertura de cdigo e os arquivos de rastreamento ok.xml
e notOk.xml (ver Listagens 6.11 e 6.12). No arquivo ok.xml, todos os pares aparecem pois no
ocorre violao alguma de propriedades no exemplo e, portanto, nenhum par mostrado no arquivo
notOk.xml. Alm disso, emok.xml, aparecem as tags threaddef e threaduse, que identicam
as threads que executaram, respectivamente, a denio e o uso de um determinado par.
(a) Congurando o JPF Exceptions. (b) Seleo das propriedades a serem vericadas.
(c) Congurao dos listeners. (d) Estatsticas de cobertura.
(e) Dados do rastreamento.
Figura 6.15: Execuo no Java PathFinder Exceptions
INTEGRAO DAS FERRAMENTAS VIA INTERFACE GRFICA 101
2 <el ements>
3 <obj e c t>
6 <name>obj</name>
7 
8 <def>7</ def>
9 <t hr eaddef>main</ t hr eaddef>
10 <use>8</ use>
11 <t hr eaduse>main</ t hr eaduse>
12 
13 
14 <def>8</ def>
16 <use>8</ use>
19 </ obj e c t>
20 <except i on>
23 <name>e</name>
24 
25 <def>9</ def>
27 <use>10</ use>
30 </ except i on>
31 <except i on>
33 <methodname>method ( )</methodname>
34 <name>exc</name>
35 
36 <def>14</ def>
38 <use>15</ use>
41 <e xt e r nal pai r>
42 <def>15</ def>
44 <use>9</ use>
46 </ e xt e r nal pa i r>
47 </ except i on>
48 </ el ements>
Listagem 6.11: Arquivo ok.xml gerado pelo JPF Exceptions.
2 <el ements />
Listagem 6.12: Arquivo notOk.xml gerado pelo JPF Exceptions.
6.5 Integrao das Ferramentas via Interface Grca
A integrao das ferramentas via XML (ver Seo 6.4) permitiu a comunicao entre a OCon-
GraX e a JPF Exceptions, de modo que o usurio possa usufruir das funcionalidades providas pelo
uso conjunto de validao e vericao (ver Seo 6.1).
Embora a comunicao por arquivos XML seja til, ela ainda exigia que o usurio acessasse as
ferramentas separadamente, o que interfere na praticidade de se utilizar tal abordagem. Por esta
razo, foi implementada uma interface grca que integrasse sob um nico aplicativo as ferramentas
OConGraX e JPF Exceptions (conforme previsto na Seo 1.2). Este aplicativo, nomeado Java
V&V, disponibiliza ao usurio todas as funcionalidades de ambas as ferramentas, facilitando assim
a aplicao da abordagem de validao e vericao num dado sistema Java.
Figura 6.16: Java V&V
6.5.1 Interface Grca da Java V&V
Na Figura 6.17, podemos observar como as ferramentas OConGraX e JPF Exceptions foram
integradas na interface deste aplicativo.
Figura 6.17: GUI da Java V&V
esquerda, o painel contendo a rvore com os dados do sistema (pacotes, classes, campos,
mtodos, parmetros, denies e usos) pode ser visualizada. Esta rvore pertence OConGraX
e, para sua visualizao necessrio carregar um projeto por meio do menu File. direita, na
parte superior, encontram-se as abas da ferramenta OConGraX; j na parte inferior, encontram-se as
abas referentes JPF Exceptions. A diviso por meio dos componentes de Java Swing, JSplitPanes,
permite que o usurio ajuste a visualizao conforme sua necessidade, recolhendo o painel com a
rvore de dados e/ou recolhendo o painel com uma das ferramentas.
Apesar de integradas sob este aplicativo, foi mantida uma certa independncia no funcionamento
de cada uma das ferramentas, de modo que o usurio possa utilizar as funcionalidades de apenas
uma ou outra. Assim, caso o usurio deseje utilizar apenas a JPF Exceptions, ele pode assim faz-lo,
sem ter que, para isso, utilizar a OConGraX para gerar um arquivo XML contendo informaes de
denies e usos de um pacote do sistema a ser testado.
6.5.2 Adaptaes da Interface para Integrao
Para facilitar o acesso do usurio s funcionalidades das ferramentas, foram feitas algumas
adaptaes. Elas so relatadas a seguir, separadas por ferramenta.
OConGraX
Para a Java V&V, foram feitas as seguintes adaptaes para utilizao da OConGraX:
Menus: o menu Main foi renomeado para File, mantendo os mesmos itens. O menu View,
embora tenha o nome mantido, no possui os itens para visualizao das abas da OConGraX.
Ao invs disso, ele possui as opes para visualizao de arquivos XML e de imagem (ver
Seo 6.5.3).
Abas: com a retirada das opes de visualizao das abas do menu View, as quatro abas da
ferramenta foram colocadas no painel da OConGraX, de modo semelhante ferramenta JPF
Exceptions (ver Figura 6.17). No foram feitas alteraes adicionais ao contedo de cada aba.
JPF Exceptions
As adaptaes feitas na JPF Exceptions so referentes integrao com a OConGraX e
insero de novas propriedades para vericao com o JPF. Por isso, as alteraes foram feitas
apenas em duas abas: Propriedades e Listeners.
Na aba Listeners, foi adicionada a opo de utilizar o ltimo arquivo XML gerado pela OCon-
GraX, como pode ser visto na Figura 6.18. Caso o usurio no deseje esta opo, ele pode escolher
um arquivo XML salvo em seu computador.
Figura 6.18: Java V&V - Aba Listeners da JPF Exceptions.
Na aba Propriedades (ver Figura 6.19), por sua vez, foram adicionadas as propriedades rela-
cionadas s aes CA que foram implementadas neste trabalho (ver Seo 5.2).
Figura 6.19: Java V&V - Aba Properties da JPF Exceptions.
6.5.3 Novas Funcionalidades
Para melhorar a utilizao das funcionalidades de validao e vericao proporcionadas pela
ferramenta, foram adicionadas duas novas funcionalidades:
Visualizao de arquivo XML: ao clicar neste item, solicitado ao usurio a seleo de
um arquivo XML. Este arquivo ser ento aberto numa nova janela do aplicativo Java V&V
para que o usurio possa visualiz-lo. Esta funcionalidade est disponvel no menu View, e
tambm pode ser selecionada para que, logo aps a gerao do arquivo XML pela OConGraX,
este seja visualizado pelo usurio.
Visualizao de arquivo de imagem: anlogo ao item anterior, para visualizao de ar-
quivos de imagem do grafo gerado pela OConGraX.
6.5.4 Exemplo
Para exemplicar o uso da Java V&V, vamos utilizar o cdigo do exemplo da Seo 4.4.9. Neste
exemplo, temos duas aes CA (ver Seo 4.3) aninhadas, e a ocorrncia de propagao e tratamento
de excees.
Ao abrir o projeto, a ferramenta OConGraX insere os dados referentes s denies e usos
dos objetos e excees do exemplo. Na Figura 6.20, podemos observar a rvore gerada e o OCFG
do objeto coord0, que corresponde ao coordenador da primeira ao CA do exemplo, na classe
Simulator.
Figura 6.20: Java V&V: visualizao da rvore de denies e usos e do OCFG
Aps a abertura do projeto, podemos gerar o XML com todas as informaes de denies,
usos, e pares du de objetos e excees. Para este exemplo, optamos por gerar o arquivo com os
dados colhidos da classe Simulator do exemplo. Este arquivo apresentado parcialmente a seguir,
contendo as informaes dos objetos coord0 e coord1, que correspondem s threads coordenadoras
das aes CA.
<?xml ve r s i on=" 1. 0 " encodi ng=" i s o 88591"?>
<el ements>
. . .
<obj ect >
<cl assname>s i mul at i on . Si mul ator </cl assname>
<methodname>main( St r i ng )</methodname>
<name>coord0 </name>

<pai r >
<def >119</def >
<use >120</use>
</pai r >

<def >119</def >
</obj ect >
<obj ect >
<name>coord1 </name>

<pai r >
<def >130</def >
<use >131</use>
</pai r >
<pai r >
<def >131</def >
<use >132</use>
</pai r >

<def >130</def >
<def >131</def >
<use >131</use>
</obj ect >
. . .
</el ements>
Feito isso, vamos acionar a JPF Exceptions para vericar no apenas as propriedades, mas
tambm os pares que so cobertos durante sua execuo. Primeiramente, fazemos a seleo do
projeto Java a ser vericado, que consiste no exemplo aqui utilizado.
Figura 6.21: Seleo do projeto a ser vericado
Em seguida, selecionamos a(s) propriedade(s). Neste caso, devemos necessariamente selecionar
uma das propriedades relativas s aes CA implementadas neste trabalho, para que a busca termine
em tempo razovel (ver Seo 5.2.3). Tambm necessrio que a propriedade selecionada no seja
violada pois, caso contrrio, o rastreamento dos pares du no ocorrer.
Figura 6.22: Seleo das propriedades
Antes de executarmos a vericao, devemos selecionar o arquivo XML gerado pela OConGraX
e o caminho dos arquivos ok.xml e notOk.xml, que contero, respectivamente, os pares cobertos e
no cobertos durante a busca por violaes das propriedades. Em seguida, clicamos no boto Run
para iniciar a vericao.
Figura 6.23: Congurao dos listeners
Terminada a vericao, observamos que o resultado retornado foi ConstraintHit: SIZE. Isto
ocorreu porque a vericao e o rastreamento dos pares du foram interrompidos devido ao fato do
consumo de memria exceder a quantidade disponvel no heap da JVM. No caso de executarmos
apenas a checagem da propriedade, sem fazer o rastreamento dos pares du cobertos, o resultado
retornado seria: No property violated. Apesar disso, como a propriedade no chegou a ser violada,
os arquivos ok.xml e notOk.xml foram gerados, e possvel ver a porcentagem de cobertura dos
pares du da classe Simulator do exemplo.
Figura 6.24: Estatsticas de cobertura
Aps ver as estatsticas de cobertura, podemos ver os dados da prpria busca na aba State.
Figura 6.25: Estatsticas da busca
6.5.5 Anlise da Cobertura dos Pares du
Pelo fato da execuo da classe Simulator ser uma das primeiras a ocorrer durante a vericao,
os dados de cobertura de seus pares du esto completos apesar da interrupo da vericao devido
a problemas de estouro de memria. Assim sendo, vamos analisar os pares du no cobertos. O
arquivo notOk.xml que contm tais pares mostrado a seguir.
<?xml ve r s i on=" 1. 0 " encodi ng=" i s o 88591"?>
<el ements>
<obj ect >
<name>caa0</name>

<def >128</def >
<threaddef >main</threaddef >
<use >139</use>
<threaduse>Thread3</threaduse>

</obj ect >
<obj ect >
<name>caa1</name>

<def >123</def >
<use >124</use>
<threaduse>main</threaduse>

</obj ect >
<obj ect >
<name>excTree </name>

<def >117</def >
<threaddef >Thread3</threaddef >
<use >127</use>

</obj ect >
<obj ect >
CONCLUSO 109
<name>except i ons </name>

<def >116</def >
<threaddef >Thread3</threaddef >
<use >126</use>


<def >126</def >
<use >131</use>

</obj ect >
</el ements>
Observando os dados deste arquivo, obtemos os seguintes pares du no cdigo:
// Objeto caa0
caa1 . setParentCaa ( caa0 ) ;
caa0 . get Coor di nat or ( ) . s t a r t ( ) ;
// Objeto caa1
caa1 . setTrans ( t r ans ac t i ons 1 ) ;
caa1 . s e t Pa r t i c i pa nt s ( par t i c i pant s 1 ) ;
// Objeto excTree
caa0 . setExcepti onTr ee ( excTree ) ;
caa1 . setExcepti onTr ee ( excTree ) ;
// Objeto except i ons
caa0 . s et Except i ons ( except i ons ) ;
//
coord1 . s e t f Si g na l ( except i ons ) ;
Como podemos ver, estes pares no so pares du de verdade, e so compostos ou por duas
denies, ou por dois usos. Isto ocorre porque o algoritmo da ferramenta OConGraX para obteno
destes pares, quando no consegue garantir se uma linha de denio ou de uso, considera esta
linha como sendo tanto de denio quanto de uso, criando assim pares du a mais e que na verdade
no existem. E so justamente estes pares que no foram cobertos durante a execuo da vericao
no cdigo de exemplo aqui utilizado.
6.6 Concluso
Neste presente captulo, apresentamos o conceito de validao e vericao (V&V) e suas van-
tagens, juntamente com a proposta de integrao das ferramentas OConGraX e JPF Exceptions
para esta nalidade. Estas ferramentas foram descritas de modo a detalhar seu funcionamento e
como esta integrao se daria: via XML e via uma interface grca que originaria o aplicativo Java
V&V.
Desta forma, mostramos neste captulo o resultado da integrao e a aplicao da abordagem de
validao e vericao em cdigo Java, tanto um cdigo simples (ver Seo 6.4.4) quanto um cdigo
que envolve a coordenao de componentes juntamente com as aes CA (ver Seo 6.5.4). Com
isso, alcanamos o objetivo maior deste trabalho, a completa integrao das ferramentas OConGraX
e JPF Exceptions, e a aplicao prtica do conceito de validao e vericao.
Captulo 7
Concluses
Neste captulo apresentamos as concluses nais relativas ao trabalho desenvolvido. Abordamos
os seguintes tpicos:
contribuio cientca do trabalho;
trabalhos futuros.
7.1 Contribuio Cientca
Os resultados obtidos com o desenvolvimento deste trabalho compem sua contribuio cient-
ca. Eles so descritos a seguir:
Framework Java para aes CA
Baseado na especicao em CSP/CSPm da coordenao de componentes por meio das aes
atmicas coordenadas [Per07, PdM10], este framework foi desenvolvido para tornar possvel
a implementao de propriedades relativas a este protocolo na ferramenta JPF Exceptions
[Xav08]. Ele corresponde a uma implementao genrica, podendo ser utilizado conforme a
vontade do usurio.
O cdigo do modelo implementado neste framework foi escrito em Java (SE). Tal deciso foi
feita aps uma anlise das possveis alternativas, descritas a seguir:
Java EE/EJB: plataforma de desenvolvimento especca para sistemas corporativos
desta linguagem, no foi utilizada devido incompatibilidade de uso desta plataforma
com o vericador escolhido para a realizao deste trabalho.
JPA (Java Persistence API ): utilizado para implementao de transaes entre o
sistema escrito em Java (SE ou EE) e objetos externos, como banco de dados, no foi
usado neste trabalho pelo fato de no permitir o aninhamento de transaes [KS06]. Desta
forma, se utilizssemos tal API, no conseguiramos implementar o framework baseado
na especicao CSP/CSPm, uma vez que esta especicao prev o uso da caracterstica
de aninhamento de aes CA e, consequentemente, prev o uso de transaes aninhadas.
Ademais, pelo fato da implementao estar embasada numa especicao formal, o usurio po-
der vericar propriedades relativas tanto especicao, quanto implementao do modelo
especicado. E isso diferencia este framework de outros baseados no protocolo de coordenao
de componentes via aes CA [CGP
+
06].
Implementao de propriedades na ferramenta JPF Exceptions
A implementao de propriedades relativas coordenao de componentes tolerantes a falhas,
permite garantir que, caso uma exceo seja lanada no sistema, ela seja efetivamente tratada
111
112 CONCLUSES
e as transaes sejam desfeitas ou conrmadas de acordo com o trmino da ao CA. Para
realizar estas implementaes, foi necessrio considerar as seguintes limitaes do vericador
JPF [VHB
+
03, Jav] utilizado a JPF Exceptions:
Exploso de Estados: pelo fato do framework implementado neste trabalho utilizar
vrias threads para realizar a coordenao de componentes via aes CA, e pelo fato do
controle ser feito por estruturas como laos, ocorre uma exploso de estados durante a
busca por violaes de propriedades feita pelo JPF. Com isso, o tempo para execuo de
uma busca numa simulao simples que utilize o framework ca muito demorado, alm
de poder acarretar num uso de memria que ultrapasse o limite disponvel no heap da
JVM.
Soluo: para tentar evitar este problema, optamos por interromper a busca assim
que observarmos os eventos: (1) lanamento de exceo; (2) tratamento da exceo; (3)
nalizao da ao CA-0 nalizada.
Bibliotecas java.awt, java.net e java.io: o vericador JPF no oferece suporte
adequado para os mtodos nativos destas bibliotecas Java.
Soluo: neste caso, optamos por evitar o uso destas bibliotecas nos cdigos dos pro-
gramas e dos exemplos implementados para este trabalho. Tambm recomendado que
o usurio evite o uso de qualquer dessas bibliotecas quando for utilizar a vericao feita
na JPF Exceptions.
Integrao da OConGraX [HM07, NHdM09] e JPF Exceptions
Integrar estas ferramentas de teste e vericao, respectivamente, permitiu a utilizao efetiva
da abordagem de validao e vericao em cdigo Java. Esta integrao, feita via XML e
via interface grca, originou o aplicativo Java V&V, que engloba todas as funes de ambas
as ferramentas, garantindo, por meio da OConGraX, a gerao do grafo de uxo de controle
de objetos e excees e dos pares du para aplicao dos critrios de denies e usos [SH99];
e por meio da JPF Exceptions, a vericao de propriedades relativas a deadlock, tratamento
de excees e coordenao de componentes tolerantes a falhas via aes CA.
7.2 Escrita de Artigos
Nesta seo mostrada a relao de artigos publicados durante este curso de Mestrado, bem
como a relao de artigos em processo de escrita neste momento, cada um seguido de uma breve
descrio.
7.2.1 Artigos Publicados
SEFM08
O artigo Using Formal Verication to Reduce Test Space of Fault-Tolerant Programs [XHdM08]
foi aceito e publicado no SEFM2008 (6th IEEE International Conferences on Software Engineering
and Formal Methods), evento ocorrido em Novembro de 2008 na Cidade do Cabo, frica do Sul. Ele
foi escrito por Kleber S. Xavier, autor da ferramenta JPF Exceptions, por mim, Simone Hanazumi,
e por minha orientadora, Prof
a
Ana C. V. de Melo.
Neste artigo, em anexo no apndice 7.2.1, foi tratada a questo da integrao entre testes
e vericao de sistemas tolerantes a falhas escritos em Java, utilizando a OConGraX e o Java
PathFinder Exceptions. Com esta integrao, possvel reduzir o espao de testes a serem feitos
segundo os critrios de teste de denio/uso de exceo, reduzindo assim os custos na execuo de
tarefas relacionadas a validao e vericao de tais programas.
TRABALHOS FUTUROS 113
TESTCOM09
O artigo OConGraX - automatically generating data-ow test cases for fault-tolerant systems
foi escrito no primeiro semestre de 2009 por Paulo R. F. Nunes, autor da ferramenta OConGra
(verso que precedeu a OConGraX), por mim, Simone Hanazumi, e por minha orientadora, Prof
a
Ana C. V. de Melo. Ele est em anexo no apndice 7.2.1, e foi publicado no TESTCOM/FATES
2009 (Joint Conference of the 21st IFIP Int. Conference on Testing of Communicating Systems and
the 9th Int. Workshop on Formal Approaches to Testing of Software), evento realizado em Novembro
de 2009 em Eindhoven, Holanda.
O assunto tratado no artigo a ferramenta OConGraX e sua utilizao para gerar automatica-
mente, do cdigo-fonte de programas escritos em Java, casos de teste de uxo de dados de objetos e
mecanismos de tratamento de exceo, alm de gerar dados (como grafo de uxo de controle) para
uma anlise mais detalhada do programa Java recebido.
7.2.2 Artigos em Julgamento e em Processo de Escrita
Junto com Paulo R. F. Nunes e minha orientadora, Prof
a
Ana C. V. de Melo, nalizamos um
artigo detalhado sobre a OConGraX, o qual trata desde sua arquitetura at sua utilizao para
gerao de requisitos de teste de uxo de dados de objetos e mecanismos de exceo, e anlise de
programas orientados a objetos. Intitulado OConGraX - A tool for data-ow test requirements,
este est sendo submetido a um peridico especializado na rea de ferramentas para desenvolvimento
de software (em fase nal de formatao).
Relativo segunda fase do projeto, no qual foram desenvolvidos implementao de um modelo
de coordenao de componentes tolerantes a falhas juntamente com um conjunto de propriedades
formais para o JPF (Java PathFinder), eu e a minha orientadora, Prof
a
Ana C. V. de Melo, estamos
escrevendo um artigo para um peridico. Este artigo descreve a implementao do modelo de
coordenao em detalhes, as propriedades genricas no JPF, e como ambos podem ser instanciados
para sistemas baseados em componentes de forma que tenhamos a implementao da coordenao e
possamos provar as propriedades sobre tal coordenao. Este artigo ser submetido a um peridico
sobre desenvolvimento formal de software.
7.3 Trabalhos Futuros
A realizao deste trabalho proporcionou uma experincia nica de pesquisa na rea de teste e
vericao de software. E embora os resultados obtidos sejam interessantes, muitas coisas podem
ser feitas para aprimor-los e permitir seu uso por um nmero maior de desenvolvedores. Por esta
razo, citamos os seguintes trabalhos que podem ser feitos futuramente:
Estudo da performance das ferramentas: fazer um estudo estatstico mostrando a per-
formance de OConGraX e JPF Exceptions em cdigo Java de aplicativos reais. Deste modo,
conseguiremos determinar as classes de programas em que elas poderiam ser utilizadas;
Estudo do ganho efetivo com a aplicao da abordagem V&V: fazer um estudo
estatstico que comprove a ecincia do uso desta abordagem nos testes de programas;
Implementar plugin para IDEs de Java: criar um plugin do aplicativo Java V&V, que
engloba a OConGraX e a JPF Exceptions, para sua utilizao no ambiente de desenvolvimento
de cdigo Java, como Netbeans e Eclipse. Isto permitiria que mais usurios utilizassem esta
ferramenta, e facilitaria a criao de testes e o processo de vericao de programas.
Implementar novas funcionalidades na Java V&V, OConGraX e JPF Exceptions:
implementar novas funcionalidades na OConGraX e na JPF Exceptions, e agreg-las poste-
riormete Java V&V permitiria fornecer uma gama mais completa de cobertura de testes e
propriedades a serem vericadas no cdigo. Mais especicamente, poderamos acrescentar nas
ferramentas:
114 CONCLUSES
OConGraX: alm de auxiliar a gerao de casos de teste em testes baseado nos critrios
de denies e usos, acrescentar funcionalidades que auxiliem na gerao de casos de
testes baseados em outros critrios;
JPF Exceptions: acrescentar novas propriedades a serem vericadas com o JPF e tornar
a gerao de propriedades a serem vericadas com a JPF Exceptions (semi) automtica.
Apndice A
Especicao do framework em CSPm
Neste apndice mostrada a especicao em CSPm do framework e das propriedades de
vericao desenvolvidos em [Per07, PdM10]. A especicao do framework, que descreve o protocolo
de coordenao excepcional de componentes, foi tomada como base para a implementao do modelo
de aes atmicas coordenadas desenvolvida neste trabalho (ver Seo 4.4).
A.1 Especicao do Framework
--
**********************************
--
*
Processo Execution(parj,aci,k)
*
--
**********************************
Execution(parj,aci,SINGLE) = RequestInit(parj,aci);
(Normal(parj,aci,SINGLE)/\Raise(parj,aci));
RequestNormalEnd(parj,aci)
Execution(parj,aci,FIRST) = RequestInit(parj,aci);
(Normal(parj,aci,FIRST)/\Raise(parj,aci))
Execution(parj,aci,LAST) = (Normal(parj,aci,LAST)/\Raise(parj,aci));
RequestNormalEnd(parj,aci)
Execution(parj,aci,index) = Normal(parj,aci,index)/\Raise(parj,aci)
RequestInit(parj,aci) = let aipj = fCoordCh(parj,aci)
within
aipj!requestInit -> Init(aci)
Init(aci) = let aci_syn = fSynCh(aci)
within
aci_syn?init -> SKIP
RequestNormalEnd(parj,aci) = let aipj = fCoordCh(parj,aci)
within
aipj!requestOk -> (EndNormal(aci) [] EndExceptional(aci))
EndNormal(aci) = let aci_syn = fSynCh(aci)
within
aci_syn?ok -> SKIP
EndExceptional(aci) = let aci_syn = fSynCh(aci)
within
aci_syn?signal.exp -> SKIP
Raise(parj,aci) = let aipj = fCoordCh(parj,aci)
Exp = fRaise(parj,aci)
115
116 APNDICE A
within
[]exp:Exp @ aipj!raise.exp -> STOP
--
*********************************
--
*
Processo Suspension(parj,aci)
*
--
*********************************
Suspension(parj,aci) = let aipj = fCoordCh(parj,aci)
within
(aipj?suspend -> ExcepExecution(parj,aci) [] ExcepExecution(parj,
aci)) /\ EndAbort(aci)
ExcepExecution(parj,aci) = let aci_syn = fSynCh(aci)
within
aci_syn?handle.exp -> Exceptional(parj,aci,exp) []
RequestExceptionalEnd(parj,aci)
EndAbort(aci) = let aci_syn = fSynCh(aci)
within
aci_syn?abort -> SKIP
RequestExceptionalEnd(parj,aci) = let aipj = fCoordCh(parj,aci)
within
aipj!requestSignal -> EndExceptional(aci)
--
****************************
--
*
Processos Update e Query
*
--
****************************
Update(parj,extj,state) = let piej = fStateCh(parj,extj)
within
piej!update.state -> SKIP
Query(parj,extj,aci) = let piej = fStateCh(parj,extj)
within
piej?query.state -> ResultQuery(parj,extj,aci,state)
--
**********************************
--
*
Processo ExternalObject(extj)
*
--
**********************************
ExternalObject(extj) = InitState(extj) /\ End
InitState(extj) = let initial = fInitialState(extj) within ControlState(initial,initial,extj)
ControlState(saved,current,extj) = BeginTransExt(saved,current,extj) []
ReadWrite(saved,current,extj) []
CommitTransExt(saved,current,extj) []
RollbackTransExt(saved,current,extj)
ReadWrite(saved,current,extj) = []piej:StateCh(extj) @
(piej!query.current -> ControlState(saved,current,extj) []
piej?update.new -> ControlState(saved,new,extj))
BeginTransExt(saved,current,extj) = []aiej:fTransCh(extj) @ aiej?begin ->
ControlState(saved,current,extj)
CommitTransExt(saved,current,extj) = []aiej:fTransCh(extj) @ aiej?commit ->
ControlState(current,current,extj)
RollbackTransExt(saved,current,extj) = []aiej:fTransCh(extj) @ aiej?rollback ->
ControlState(saved,saved,extj)
ESPECIFICAO DO FRAMEWORK 117
--
******************************
--
*
Processo Coordinator(aci)
*
--
******************************
Coordinator(aci) = if aci == ac1 then
RecInitRequest(CoordCh(aci),aci)
else
RecInitRequest(CoordCh(aci),aci) /\ RecAbortRequest(aci) /\ End
RecInitRequest(Ch,aci) = if empty(Ch) then
BeginTrans(TransCh(aci),aci)
else
[]aipj:Ch @ aipj?requestInit -> RecInitRequest(diff(Ch,{aipj}),aci)
BeginTrans(Ch,aci) = if empty(Ch) then
BeginAction(aci)
else
[]aiej:Ch @ aiej!begin -> BeginTrans(diff(Ch,{aiej}),aci)
BeginAction(aci) = let aci_syn = fSynCh(aci)
within aci_syn!init -> Monitor(CoordCh(aci),aci)
Monitor(Run,aci) = if empty(Run) then
CommitTrans(TransCh(aci),aci)
else
([]aipj:Run @ aipj?requestOk -> Monitor(diff(Run,{aipj}),aci)) []
([]aipj:Run @ aipj?raise.exp ->
Abort(AbortCh(aci), diff(CoordCh(aci),{aipj}),{exp},aci)) []
([]acj_syn:SynCh(aci) @ acj_syn?signal.exp ->
Abort(AbortCh(aci),CoordCh(aci),{exp},aci)) []
([]acj_syn:SynCh(aci) @ acj_syn?init -> Monitor(Run,aci)) []
([]acj_syn:SynCh(aci) @ acj_syn?ok -> Monitor(Run,aci)) []
([]acj_syn:SynCh(aci) @ acj_syn?handle.exp -> Monitor(Run,aci))
Abort(AbortCh,CoordCh,Exp,aci) = if empty(AbortCh) then
Suspend(CoordCh,Exp,aci)
else
([]acj_ab:AbortCh @ acj_ab!requestAbort ->
ResponseAbort(AbortCh,CoordCh,
Exp,acj_ab,aci)) []
([]aipj:CoordCh @ aipj?raise.exp ->
Abort(AbortCh,diff(CoordCh,{aipj}),
union(Exp,{exp}),aci))
ResponseAbort(AbortCh,CoordCh,Exp,acj_ab,aci) = let acj = fActionName(acj_ab)
acj_syn = fSynCh(acj)
within
acj_syn?abort -> Abort(diff(AbortCh,{acj_ab}),
CoordCh,Exp,aci) []
acj_ab?stopped -> Abort(diff(AbortCh,{acj_ab}),
CoordCh,Exp,aci) []
([]aipj:CoordCh @ aipj?raise.exp ->
ResponseAbort(AbortCh,diff(CoordCh,{aipj}),
union(Exp,{exp}),acj_ab,aci))
Suspend(Ch,Exp,aci) = if empty(Ch) then
Resolve(Exp,aci)
else
([]aipj:Ch @ aipj!suspend -> Suspend(diff(Ch,{aipj}),Exp,aci)) []
([]aipj:Ch @ aipj?raise.exp -> Suspend(diff(Ch,{aipj}),union(Exp,{exp}),aci))
Resolve(Exp,aci) = let exp = fExceptionTree(Exp,aci)
within
Choose(exp,aci)
118 APNDICE A
Choose(exp,aci) = if member(exp,fSignal(aci)) then
Signal(CoordCh(aci),exp,aci)
else
Handle(exp,aci)
Signal(Ch,exp,aci) = if empty(Ch) then
RollbackTransExcep(TransCh(aci),exp,aci)
else
[]aipj:Ch @ aipj!requestSignal -> Signal(diff(Ch,{aipj}),exp,aci)
Handle(exp,aci) = let aci_syn = fSynCh(aci)
within
aci_syn!handle.exp -> Verify(CoordCh(aci),{},aci)
Verify(Ch,Resp,aci) = if empty(Ch) then
Respond(Resp,aci)
else
[]aipj:Ch @ aipj?request.resp -> Verify(diff(Ch,{aipj}),
union(Resp,{resp}),aci)
Respond(Resp,aci) = if member(requestSignal,Resp) then
RollbackTransExcep(TransCh(aci),FAILURE,aci)
else
CommitTrans(TransCh(aci),aci)
CommitTrans(Ch,aci) = if empty(Ch) then
EndActionNormal(aci)
else
[]aiej:Ch @ aiej!commit -> CommitTrans(diff(Ch,{aiej}),aci)
EndActionNormal(aci) = let aci_syn = fSynCh(aci)
within
aci_syn!ok -> Finalize(aci)
RollbackTransExcep(Ch,exp,aci) = if empty(Ch) then
EndActionExceptional(exp,aci)
else
[]aiej:Ch @ aiej!rollback ->
RollbackTransExcep(diff(Ch,{aiej}),exp,aci)
EndActionExceptional(exp,aci) = let aci_syn = fSynCh(aci)
within
aci_syn!signal.exp -> Finalize(aci)
RollbackTransAbort(Ch,aci) = if empty(Ch) then
EndActionAbort(aci)
else
[]aiej:Ch @ aiej!rollback -> RollbackTransAbort(diff(Ch,{aiej}),aci)
EndActionAbort(aci) = let aci_syn = fSynCh(aci)
within
aci_syn!abort -> Finalize(aci)
Finalize(aci) = if aci == ac1 then
End
else
STOP
End = end -> SKIP
RecAbortRequest(aci) = let aci_ab = fAbortCh(aci)
aci_st = fStateCoordCh(aci)
ESPECIFICAO DAS PROPRIEDADES 119
within
aci_ab?requestAbort -> (aci_st?get.state ->
VerifyAbort(aci,state) /\ RecAbortRequest(aci))
VerifyAbort(aci,state) = if state == STOPPED then
(let aci_ab = fAbortCh(aci)
within
aci_ab!stopped -> RecAbortRequest(aci))
else
AbortNested(AbortCh(aci),aci)
AbortNested(AbortCh,aci) = if empty(AbortCh) then
RollbackTransAbort(TransCh(aci),aci)
else
[]acj_ab:AbortCh @ acj_ab!requestAbort ->
ResponseAbortNested(AbortCh,acj_ab,aci)
ResponseAbortNested(AbortCh,acj_ab,aci) = let acj = fActionName(acj_ab)
acj_syn = fSynCh(acj)
within
acj_syn?abort ->
AbortNested(diff(AbortCh,{acj_ab}),aci) []
acj_ab?stopped ->
AbortNested(diff(AbortCh,{acj_ab}),aci)
--
*****************************************
--
*
Processo CoordinatorState(aci,state)
*
--
*****************************************
CoordinatorState(aci,state) = let aci_syn = fSynCh(aci)
aci_st = fStateCoordCh(aci)
within
aci_syn?init -> CoordinatorState(aci,STARTED) []
aci_syn?ok -> CoordinatorState(aci,STOPPED) []
aci_syn?signal.exp -> CoordinatorState(aci,STOPPED) []
aci_syn?abort -> CoordinatorState(aci,STOPPED) []
aci_syn?handle.exp -> CoordinatorState(aci,state) []
aci_st!get.state -> CoordinatorState(aci,state) /\ End
A.2 Especicao das Propriedades
--
**********************************
--
*
Propriedades para Verificacao
*
--
**********************************
Prop_End(aci) = let aci_syn = fSynCh(aci)
within
(aci_syn.ok -> SKIP) []
(aci_syn.abort -> SKIP) []
([]exp:fSignal(aci) @ aci_syn.signal.exp -> SKIP)
Prop_Abort(aci) = if aci == ac1 then
SKIP
else
let aci_ab = fAbortCh(aci)
within
aci_ab.requestAbort -> SKIP
--
**************************************
--
*
Propriedade 1 - Demarcacao da Acao
*
--
**************************************
alpha_Prop1(aci,aci_syn) = {aci_syn.init,
120 APNDICE A
aci_syn.ok,
aci_syn.abort,
aci_syn.signal.exp | exp <- fSignal(aci)}
Prop1(aci) = Prop1_Def(aci);Prop1(aci)
Prop1_Def(aci) = let aci_syn = fSynCh(aci)
within
aci_syn.init -> Prop_End(aci)
--
****************************************
--
*
Propriedade 2 - Condicoes de Termino
*
--
****************************************
alpha_Prop2(aci,aci_syn) = {aci_syn.init,
aci_syn.ok,
aci_syn.abort,
aci_syn.signal.exp,
aipj.requestOk,
aipj.requestSignal,
aipj.raise.exp | aipj <- CoordCh(aci), exp <- Exp}
Prop2(aci) = Prop2_Def(aci);Prop2(aci)
Prop2_Def(aci) = let aci_syn = fSynCh(aci)
within
aci_syn.init -> (Prop2_Normal(aci) []
Prop2_HandleOk(aci) []
Prop2_HandleExp(aci) []
Prop2_Signal(aci) []
Prop2_Abort(aci))
Prop2_Normal(aci) = Prop2_RequestOk(aci,CoordCh(aci))
Prop2_HandleOk(aci) = Prop2_Raise(aci,CoordCh(aci));Prop2_RequestOk(aci,CoordCh(aci))
Prop2_HandleExp(aci) = Prop2_Raise(aci,CoordCh(aci));Prop2_RequestOkSig(aci,CoordCh(aci))
Prop2_Signal(aci) = Prop2_Raise(aci,CoordCh(aci));Prop2_RequestSignal(aci,CoordCh(aci))
Prop2_Abort(aci) = Prop2_Raise(aci,CoordCh(aci));Prop2_RequestOkSig2(aci,CoordCh(aci));
let aci_syn = fSynCh(aci)
within
aci_syn.abort -> SKIP
Prop2_Raise(aci,CoordCh) = if empty(CoordCh) then
SKIP
else
SKIP []
([]aipj:CoordCh @ []exp:Exp @ aipj.raise.exp ->
Prop2_Raise(aci,
diff(CoordCh,{aipj})))[]
([]aipj:CoordCh @ aipj.requestOk -> Prop2_Raise(aci,CoordCh))
Prop2_RequestOk(aci,CoordCh) = if empty(CoordCh) then
within
aci_syn.ok -> SKIP
else
[]aipj:CoordCh @ aipj.requestOk ->
Prop2_RequestOk(aci, diff(CoordCh,{aipj}))
Prop2_RequestSignal(aci,CoordCh) = if empty(CoordCh) then
within
[]exp:fSignal(aci) @ aci_syn.signal.exp -> SKIP
else
[]aipj:CoordCh @ aipj.requestSignal ->
Prop2_RequestSignal(aci, diff(CoordCh,{aipj}))
Prop2_RequestOkSig(aci,CoordCh) = if empty(CoordCh) then
within
[]exp:fSignal(aci) @ aci_syn.signal.exp -> SKIP
else
[]aipj:CoordCh @ (aipj.requestSignal ->
Prop2_RequestOkSig(aci,
diff(CoordCh,
{aipj})) []
ESPECIFICAO DAS PROPRIEDADES 121
aipj.requestOk ->
Prop2_RequestOkSig(aci,
diff(CoordCh,
{aipj})))
Prop2_RequestOkSig2(aci,CoordCh) = if empty(CoordCh) then
SKIP
else
SKIP [] ([]aipj:CoordCh @ (aipj.requestSignal ->
Prop2_RequestOkSig2(aci,
diff(CoordCh,
{aipj}))
[]
aipj.requestOk ->
Prop2_RequestOkSig2(aci,
diff(CoordCh,
{aipj}))))
--
******************************************
--
*
Propriedade 3 - Criao das Transaes
*
--
******************************************
alpha_Prop3_ac1 = {ac1_syn.init,
aiej.begin | aiej <- TransCh(ac1)}
alpha_Prop3(aci,aci_syn,aci_ab) = {aci_syn.init,
aiej.begin,
aci_ab.requestAbort | aiej <- TransCh(aci)}
Prop3(aci) = (Prop3_Def(aci,TransCh(aci)) /\ Prop_Abort(aci));Prop3(aci)
Prop3_Def(aci,TransCh) = if empty(TransCh) then
within
aci_syn.init -> SKIP
else
[]aiej:TransCh @ aiej.begin -> Prop3_Def(aci,diff(TransCh,{aiej}))
--
**********************************************
--
*
Propriedade 4 - Confirmao das Transaes
*
--
**********************************************
alpha_Prop4_ac1 = {ac1_syn.ok,
aiej.commit | aiej <- TransCh(ac1)}
alpha_Prop4(aci,aci_syn,aci_ab) = {aci_syn.ok,
aiej.commit,
aci_ab.requestAbort | aiej <- TransCh(aci)}
within
aci_syn.ok -> SKIP
else
[]aiej:TransCh @ aiej.commit -> Prop4_Def(aci,diff(TransCh,{aiej}))
--
***********************************************
--
*
Propriedade 5 - Desfazimento das Transaes
*
--
***********************************************
alpha_Prop5_ac1 = {ac1_syn.signal.exp,
ac1_syn.abort,
aiej.rollback | exp <- fSignal(ac1), aiej <- TransCh(ac1)}
alpha_Prop5(aci,aci_syn,aci_ab) = {aci_syn.signal.exp,
aci_syn.abort,
aiej.rollback,
aci_ab.requestAbort | exp <- fSignal(aci), aiej <- TransCh(aci)}
122 APNDICE A
within
([]exp:fSignal(aci) @ aci_syn.signal.exp -> SKIP) []
aci_syn.abort -> SKIP
else
[]aiej:TransCh @ aiej.rollback -> Prop5_Def(aci,diff(TransCh,{aiej}))
--
******************************************
--
*
Propriedade 6 - Tratamento de Excees
*
--
******************************************
alpha_Prop6_ac1 = {acj_syn.signal.exp,
aipj.raise.exp,
aipj.suspend | exp <- Exp, aipj <- CoordCh(ac1), acj_syn <- SynCh(ac1)}
alpha_Prop6(aci,aci_ab) = {acj_syn.signal.exp,
aipj.raise.exp,
aipj.suspend,
aci_ab.requestAbort | exp <- Exp, aipj <- CoordCh(aci),
acj_syn <- SynCh(aci)}
Prop6(aci) = (Prop6_Def(aci) /\ Prop_Abort(aci));Prop6(aci)
Prop6_Def(aci) = Prop6_Raise(aci) [] Prop6_Signal(aci)
Prop6_Raise(aci) = []aipj:CoordCh(aci) @ []exp:Exp @ aipj.raise.exp -> (Prop6_Suspend(aci,
diff(CoordCh(aci),
{aipj})) []
Prop6_Raise(aci))
Prop6_Signal(aci) = []acj_syn:SynCh(aci) @ []exp:Exp @ acj_syn.signal.exp -> Prop6_Suspend(aci,
CoordCh(aci))
Prop6_Suspend(aci,CoordCh) = if empty(CoordCh) then
SKIP
else
([]aipj:CoordCh @ aipj.suspend -> Prop6_Suspend(aci,
diff(CoordCh,
{aipj}))) []
([]aipj:CoordCh @ []exp:Exp @ aipj.raise.exp ->
Prop6_Suspend(aci,diff(CoordCh,{aipj})))
Apndice B
Cdigo do Exemplo de Instanciao do
Modelo de Aes Atmicas Coordenadas
Neste captulo vamos apresentar o cdigo fonte do exemplo apresentado na Seo 4.4.9.
B.1 Pacote exception
Contm as excees criadas para este exemplo.
B.1.1 Classe AccountAlreadyExistsException
1 package except i on ;
2
3 @SuppressWarnings ( " s e r i a l " )
4 public cl ass AccountAl readyExi stsExcepti on extends Excepti on {
5
6 }
B.1.2 Classe InvalidAccountNumberException
1 package except i on ;
2
3 @SuppressWarnings ( " s e r i a l " )
4 public cl ass Inval i dAccountNumberExcepti on extends Excepti on {
5
6 }
B.2 Pacote simulation.database
Contm as classes relacionadas representao de um banco de dados. Este banco de dados
armazena dados de uma conta bancria e realiza duas operaes: adio de conta e leitura de conta.
B.2.1 Classe BankAccount
1 package s i mul at i on . database ;
2
3 cl ass BankAccount {
4
5 i nt accountNumber ;
6 St r i ng name ;
7 double bal ance ;
8
9 public BankAccount ( i nt accountNumber , St r i ng name , double bal ance ) {
10 thi s . accountNumber = accountNumber ;
123
124 APNDICE B
11 thi s . name = name ;
12 thi s . bal ance = bal ance ;
13 }
14
15 public i nt getAccountNumber ( ) {
16 return accountNumber ;
17 }
18
19 public void setAccountNumber ( i nt accountNumber ) {
20 thi s . accountNumber = accountNumber ;
21 }
22
23 public double getBal ance ( ) {
24 return bal ance ;
25 }
26
27 public void s et Bal ance ( double bal ance ) {
28 thi s . bal ance = bal ance ;
29 }
30
31 public St r i ng getName ( ) {
32 return name ;
33 }
34
35 public void setName ( St r i ng name) {
36 thi s . name = name ;
37 }
38
39 @Override
40 public St r i ng t oSt r i ng ( ) {
41 St r i ng s t r = new St r i ng ( "Account Number : " + thi s . getAccountNumber ( )
42 + "\nName : " + thi s . getName ( )
43 + "\nBal ance : " + thi s . getBal ance ( ) + "\n" ) ;
44 return s t r ;
45 }
46 }
B.2.2 Classe BankDatabase
2
3 import except i on . AccountAl readyExi stsExcepti on ;
6
7 public cl ass BankDatabase {
8
9 private stati c BankDatabase i ns t anc e = nul l ;
10 Vector<BankAccount> accountData ;
11 Vector<BankAccount> tempAccountData ;
12 i nt i ndex ;
13
14 public BankDatabase ( ) {
15 accountData = new Vector<BankAccount >() ;
16 tempAccountData = new Vector<BankAccount >() ;
17 i ndex = 0;
18 }
19
20 public stati c BankDatabase ge t I ns t anc e ( ) {
21 i f ( i ns t anc e == nul l ) {
22 i ns t anc e = new BankDatabase ( ) ;
23 }
24 return i ns t anc e ;
25 }
26
27 public void addBankRecord( i nt accountNumber , St r i ng name , double bal ance ) throws
Inval i dAccountNumberExcepti on , AccountAl readyExi stsExcepti on {
28 i f ( accountNumber <= 0 | | accountNumber > 100) {
30 throw exc ;
31 } el se {
32 i f ( checkNewAccount ( accountNumber ) ) {
PACOTE SIMULATION.DATABASE 125
33 tempAccountData . add(new BankAccount ( accountNumber , name , bal ance ) ) ;
34 }
35 }
36 }
37
38 public void readBankRecord ( i nt accountNumber ) throws Inval i dAccountNumberExcepti on
{
39 i f ( accountNumber <= 0 | | accountNumber > 100) {
41 throw exc ;
42 } el se {
43 i f ( checkAccount ( accountNumber ) ) {
44 System . out . pr i nt l n ( tempAccountData . get ( i ndex ) . t oSt r i ng ( ) ) ;
45 } el se {
46 System . out . pr i nt l n ( "Account does not e x i s t . " ) ;
47 }
48 }
49 }
50
51 private boolean checkNewAccount ( i nt accountNumber ) {
52 for ( i nt i = 0; i < accountData . s i z e ( ) ; i ++) {
53 i f ( accountData . get ( i ) . getAccountNumber ( ) == accountNumber ) {
54 return f al se ;
55 }
56 }
57 for ( i nt i = 0; i < tempAccountData . s i z e ( ) ; i ++) {
58 i f ( tempAccountData . get ( i ) . getAccountNumber ( ) == accountNumber ) {
59 return f al se ;
60 }
61 }
62 return true ;
63 }
64
65 private boolean checkAccount ( i nt accountNumber ) {
66 for ( i nt i = 0; i < accountData . s i z e ( ) ; i ++) {
67 i f ( accountData . get ( i ) . getAccountNumber ( ) == accountNumber ) {
68 i ndex = i ;
69 return true ;
70 }
71 }
72 return f al se ;
73 }
74
75 public void commit ( ) {
76 for ( i nt i = 0; i < tempAccountData . s i z e ( ) ; i ++) {
77 accountData . add( tempAccountData . get ( i ) ) ;
78 }
79 }
80
81 public void r ol l bac k ( ) {
82 tempAccountData . removeAl l El ements ( ) ;
83 }
84 }
B.2.3 Classe Transaction
2
3 import s i mul at i on . framework . Tr ans ac t i onI nt e r f ac e ;
4
5 public cl ass Transacti on implements Tr ans ac t i onI nt e r f ac e {
6
7 BankDatabase bankDB;
8 boolean ac t i ve ;
9
10 public void begi n ( ) {
11 bankDB = BankDatabase . ge t I ns t anc e ( ) ;
12 ac t i ve = true ;
13 }
14
15 public void commit ( ) {
16 bankDB. commit ( ) ;
126 APNDICE B
17 ac t i ve = f al se ;
18 }
19
20 public void r ol l bac k ( ) {
21 bankDB. r ol l bac k ( ) ;
22 ac t i ve = f al se ;
23 }
24
25 public boolean i s Ac t i ve ( ) {
26 return ac t i ve ;
27 }
28
29 public BankDatabase get Ext er nal Obj ect ( ) {
30 return bankDB;
31 }
32
33 public void s et Ext er nal Obj ect ( Obj ect ext er nal Obj ) {
34 thi s . bankDB = ( BankDatabase ) ext er nal Obj ;
35 }
36 }
B.3 Pacote simulation.exceptionTree
Contm a classe com o mtodo para resoluo de excees lanadas concorrentemente.
B.3.1 Classe ExceptionTree
1 package s i mul at i on . except i onTr ee ;
2
4
6 import s i mul at i on . framework . Except i onTr eeI nt er f ace ;
7
8 public cl ass Excepti onTree implements Except i onTr eeI nt er f ace {
9
10 @Override
11 public void r es ol veExcept i on ( Vector<Excepti on> except i onTr ee ) {
12 // In t hi s s i mul at i on , the onl y except i on to be r e s ol ve d i s an
Inval i dAccountNumberExcepti on type .
13 Inval i dAccountNumberExcepti on e = new Inval i dAccountNumberExcepti on ( ) ;
14 except i onTr ee . removeAl l El ements ( ) ;
15 except i onTr ee . add( e ) ;
16 }
17 }
B.4 Pacote simulation.participants
Contm os participantes implementados para este exemplo.
B.4.1 Classe Participant0
1 package s i mul at i on . pa r t i c i pa nt s ;
2
4
7
8 public cl ass Par t i c i pant 0 extends Par t i c i pant {
9
10 public Par t i c i pant 0 ( Vector<Coordi natedAtomi cActi on> caa , i nt i d ) {
11 super ( caa , i d ) ;
12 }
13
PACOTE SIMULATION.HANDLERS 127
14 @Override
15 public void run ( ) {
16 begi nPar t i ci pant Act i on ( 0) ;
17 }
18 }
B.4.2 Classe Participant1
1 package s i mul at i on . pa r t i c i pa nt s ;
2
4
7
8 public cl ass Par t i c i pant 1 extends Par t i c i pant {
9
10 i nt number ;
11 boolean addOk = f al se ;
12
13 public Par t i c i pant 1 ( Vector<Coordi natedAtomi cActi on> caa , i nt i d ) {
14 super ( caa , i d ) ;
15 }
16
17 @Override
19 begi nPar t i ci pant Act i on ( 0) ;
20 }
21
22 public i nt getNumber ( ) {
23 return number ;
24 }
25
26 public void setNumber ( i nt number ) {
27 thi s . number = number ;
28 }
29
30 public boolean isAddOk ( ) {
31 return addOk ;
32 }
33
34 public void setAddOk( boolean addOk) {
35 thi s . addOk = addOk ;
36 }
37
38
39 }
B.5 Pacote simulation.handlers
Contm as threads responsveis por fazer o tratamento excepcional dos participantes deste
exemplo.
B.5.1 Classe Participant0Handler0
1 package s i mul at i on . pa r t i c i pa nt s . handl er s ;
2
7
8 public cl ass Par t i ci pant 0Handl er 0 extends Handl er {
9
10 public Par t i ci pant 0Handl er 0 ( Par t i c i pant par t i c i pant ,
11 Coordi natedAtomi cActi on caActi on ) {
12 super ( par t i c i pant , caActi on ) ;
128 APNDICE B
13 }
14
16 try {
17 System . out . pr i nt l n ( "\ nPar t i ci pant 0Handl er0 : s t a r t i ng . " ) ;
18 thi s . throwExcepti on ( ) ;
19 } catch ( Inval i dAccountNumberExcepti on e ) {
20 System . out . pr i nt l n ( " Excepti on handl i ng s uc c e s s f ul " ) ;
21 thi s . s e t St at us ( "NORMAL" ) ;
22 thi s . setEndOf Executi on ( true ) ;
25 }
26 }
27 }
B.5.2 Classe Participant1Handler0
1 package s i mul at i on . pa r t i c i pa nt s . handl er s ;
2
7
8 public cl ass Par t i ci pant 1Handl er 0 extends Handl er {
9
10 public Par t i ci pant 1Handl er 0 ( Par t i c i pant par t i c i pant ,
13 }
14
15 @Override
17 try {
18 System . out . pr i nt l n ( "\ nPar t i ci pant 1Handl er0 : s t a r t i ng . " ) ;
19 thi s . throwExcepti on ( ) ;
21 System . out . pr i nt l n ( " Excepti on handl i ng s uc c e s s f ul " ) ;
26 }
27 }
28 }
B.6 Pacote simulation.roles
Contm as threads responsveis pelas atividades do comportamento normal dos participantes
deste exemplo.
B.6.1 Classe Participant0Role0
1 package s i mul at i on . pa r t i c i pa nt s . r o l e s ;
2
3 import s i mul at i on . database . BankDatabase ;
8 import j ava . u t i l . l oggi ng . Level ;
9 import j ava . u t i l . l oggi ng . Logger ;
10 import s i mul at i on . pa r t i c i pa nt s . Par t i c i pant 1 ;
11
12 public cl ass Par t i ci pant 0Rol e0 extends Rol e {
13 i nt number ;
PACOTE SIMULATION.ROLES 129
14 boolean numberOk = f al se ;
15 boolean readOk = f al se ;
16
17 public Par t i ci pant 0Rol e0 ( Par t i c i pant par t i c i pant ,
18 Coordi natedAtomi cActi on caActi on , i nt number ) {
20 thi s . number = number ;
21 }
22
23 @Override
25 try {
26 System . out . pr i nt l n ( " Par t i ci pant 0 Rol e0 : s t a r t i ng . " ) ;
27 thi s . t r ans ac t i ons = ge t Par t i c i pant ( ) . getCaaVector ( ) . get ( 0) . getTrans ( ) ;
28 System . out . pr i nt l n ( "\ nPar t i ci pant 0Rol e0 : r eadi ng r ecor d 1" ) ;
29 ( ( BankDatabase ) thi s . t r ans ac t i ons . get ( 0) . get Ext er nal Obj ect ( ) ) .
readBankRecord ( 1) ;
30
31 Par t i c i pant 1 par t i c 2 = ( Par t i c i pant 1 ) thi s . getCaActi on ( ) . ge t Par t i c i pant s ( ) .
get ( 1) ;
32 Par t i ci pant 1Rol e0 r ol e 2 = ( Par t i ci pant 1Rol e0 ) par t i c 2 . get Rol es ( ) . get ( 0) ;
33
34 System . out . pr i nt l n ( " Par t i ci pant 0 Rol e0 : s e t t i ng number on Par t i c i pant 2. " ) ;
35 par t i c 2 . setNumber ( number ) ;
36 thi s . setNumberOk( true ) ;
37 System . out . pr i nt l n ( " Par t i ci pant 0 Rol e0 : number s e t t e d . " ) ;
38
39 while ( ! r ol e 2 . i sEndOf Executi on ( ) ) {
40 try {
41 Thread . s l e e p ( 1000) ;
42 } catch ( I nt er r upt edExcept i on e ) {
44 }
45 }
46 i f ( isReadOk ( ) ) {
47 System . out . pr i nt l n ( "\ nPar t i ci pant 1Rol e0 : r eadi ng r ecor d 1" ) ;
48 ( ( BankDatabase ) thi s . t r ans ac t i ons . get ( 0) . get Ext er nal Obj ect ( ) ) .
readBankRecord ( 1) ;
49 }
51 } catch ( Inval i dAccountNumberExcepti on ex ) {
52 Logger . getLogger ( Par t i ci pant 0Rol e0 . cl ass . getName ( ) ) . l og ( Level . SEVERE, null ,
ex ) ;
53 }
54
55 }
56
57 public boolean isNumberOk ( ) {
58 return numberOk ;
59 }
60
61 public void setNumberOk( boolean numberOk) {
62 thi s . numberOk = numberOk ;
63 }
64
65 public boolean isReadOk ( ) {
66 return readOk ;
67 }
68
69 public void setReadOk ( boolean readOk ) {
70 thi s . readOk = readOk ;
71 }
72 }
2
6 import j ava . u t i l . l oggi ng . Level ;
130 APNDICE B
7 import j ava . u t i l . l oggi ng . Logger ;
9
11
15 }
16
17 @Override
19
20 try {
21 System . out . pr i nt l n ( "\ nPar t i ci pant 1Rol e0 : s t a r t i ng . " ) ;
22 Par t i c i pant par t i c 1 = thi s . getCaActi on ( ) . ge t Par t i c i pant s ( ) . get ( 0) ;
23 Par t i ci pant 0Rol e0 r ol e 0 = ( Par t i ci pant 0Rol e0 ) par t i c 1 . get Rol es ( ) . get ( 0) ;
24 while ( ! r ol e 0 . isNumberOk ( ) ) {
25 Thread . s l e e p ( 1000) ;
26 }
27 System . out . pr i nt l n ( "\ nPar t i ci pant 1Rol e0 : number s e t t e d ok . " ) ;
28
29 System . out . pr i nt l n ( "\ nPar t i ci pant 1Rol e0 : nest ed act i on s t ar t e d . " ) ;
30 // begi n nest ed act i on
31 thi s . ge t Par t i c i pant ( ) . setNextNestedActi onI ndex ( 1) ;
32 thi s . ge t Par t i c i pant ( ) . s e t St at us ( "SUSPENDED" ) ;
33 thi s . setThreadSuspended ( true ) ;
34 while ( i sThreadSuspended ( ) ) {
35 synchronized ( thi s ) {
36 try {
37 thi s . wai t ( ) ;
38 } catch ( I nt er r upt edExcept i on ex ) {
39 Logger . getLogger ( Par t i ci pant 1Rol e0 . cl ass . getName ( ) ) . l og ( Level .
SEVERE, null , ex ) ;
40 }
41 }
42 }
43 Thread . s l e e p ( 1000) ;
44 System . out . pr i nt l n ( "\ nPar t i ci pant 1Rol e0 : nest ed act i on f i ni s he d . " ) ;
45
46 Par t i c i pant 1 p = ( Par t i c i pant 1 ) thi s . ge t Par t i c i pant ( ) ;
47 i f ( p . isAddOk ( ) ) {
48 r ol e 0 . setReadOk ( true ) ;
49 }
51
52
53 } catch ( I nt er r upt edExcept i on ex ) {
54 Logger . getLogger ( Par t i ci pant 1Rol e0 . cl ass . getName ( ) ) . l og ( Level . SEVERE, null ,
ex ) ;
55 }
56 }
57 }
2
3 import s i mul at i on . database . BankDatabase ;
4 import except i on . AccountAl readyExi stsExcepti on ;
10
12
16 }
PACOTE SIMULATION.ROLES 131
17
18 @Override
20 System . out . pr i nt l n ( " Par t i ci pant 1 Rol e1 : s t a r t i ng " ) ;
21 thi s . t r ans ac t i ons = ge t Par t i c i pant ( ) . getCaaVector ( ) . get ( 0) . getTrans ( ) ;
22 try {
23 System . out . pr i nt l n ( " Par t i ci pant 1 Rol e1 : addi ng r ecor d ( " + accountNumber
( ) + " , Simone , 900. 00) " ) ;
24 ( ( BankDatabase ) thi s . t r ans ac t i ons . get ( 0) . get Ext er nal Obj ect ( ) ) . addBankRecord
( accountNumber ( ) , "Simone" , 900. 00) ;
25 System . out . pr i nt l n ( " Par t i ci pant 1 Rol e1 : r ecor d added" ) ;
26 addi ti onOk ( ) ;
30 thi s . s e t St at us ( "EXCEPTIONAL" ) ;
31 thi s . getCaActi on ( ) . get Coor di nat or ( ) . getPropagatedExcepti ons ( ) . add( e ) ;
33 } catch ( AccountAl readyExi stsExcepti on e ) {
35 }
36 }
37
38 public i nt accountNumber ( ) {
40 return p . getNumber ( ) ;
41 }
42
43 public void addi ti onOk ( ) {
45 p . setAddOk( true ) ;
46
47 }
48 }
132 APNDICE B
Apndice C
Cdigo Fonte de Propriedade de
Tratamento de Exceo
Neste apndice mostrado o cdigo fonte da propriedade Bloco de Captura Vazio, descrita
em 6.3.2. Ela foi implementada no aplicativo JPF Exceptions [Xav08].
C.1 Propriedade: Bloco de Captura Vazio
1 package br . usp . j pf . property ;
2
4 import gov . nasa . j pf . jvm. BCELUtils ;
5 import gov . nasa . j pf . jvm. Excepti onHandl er ;
9 import gov . nasa . j pf . jvm. bytecode .ASTORE;
12
13 /
14 Thi s c l a s s i s used as a Property and Li s t e ne r . I t checks f o r a thrown
15 except i on i f the except i on handl er i s empty .
16
17 @author Kl eber
18
19 /
20 public cl ass EmptyCatchProperty extends Pr opert yLi st enerAdapter {
21
22 public boolean emptyCatch ;
23
24
25 @Override
27 ThreadInf o t i = vm. getCurrentThread ( ) ;
28 St r i ng exceptionName = t i . getPendi ngExcepti on ( ) . getExcepti onCl assname ( ) ;
29 MethodInfo mi = t i . getMethod ( ) ;
30 Excepti onHandl er [ ] except i onHandl er s = mi . get Except i ons ( ) ;
31 i f ( except i onHandl er s != null ) {
32 i nt startPC = 1;
33 for ( Excepti onHandl er handl er : except i onHandl er s ) {
34 St r i ng handl erType = handl er . getName ( ) ;
35 // s ki ps i f t hi s i s a f i n a l l y handl er ( excepti onType == nul l )
36 i f ( handl erType != null && Re f l e c t i o nUt i l s . i s As s i gnabl e (
exceptionName , handl erType ) ) {
37 startPC = handl er . getHandl er ( ) ;
38 System . out . pr i nt l n ( "Handl er found " + startPC) ;
133
134 APNDICE C
39 break ;
40 }
41 }
42 //Checks i f a handl er was found
43 i f ( startPC != 1) {
44 emptyCatch = ! BCELUtils . f i ndExcept i onLocal Var i abl e ( mi , startPC) ;
45 }
46 i f ( emptyCatch) {
47 t i . br eakTr ans i t i on ( ) ;
48 }
49 } //end i f except i onHandl er s != nul l
50 }
51
52 @Override
54 return ! emptyCatch ;
55 }
56
57 }
C.2 Sada da Vericao Feita pela JPF Exceptions
Nesta seo, apresentamos a sada obtida com a execuo, na JPF Exceptions, dos exemplos
mostrados na Seo 5.4. As sadas aqui apresentadas mostram o rastreamento resultante do veri-
cador de modo parcial, e so separadas de acordo com a propriedade.
C.2.1 Propriedade 1: Desfazimento de Transaes
====================================================== s ear ch s t ar t e d : 03/08/10 13: 24
s i mul at i on . framework . Coordi nator . respond ( Coordi nator . j ava : 358)
s i mul at i on . framework . Coordi nator . v e r i f y ( Coordi nator . j ava : 350)
s i mul at i on . framework . Coordi nator . handl e ( Coordi nator . j ava : 331)
====================================================== e r r or #1
br . usp . j pf . propert y . caa . Rol l backTransact i onProper t y
s i mul at i on . database . BankDatabase . r ol l bac k ( )V
====================================================== t r ac e #1
t r a ns i t i o n #0 thread : 0
gov . nasa . j pf . jvm. c hoi ce . ThreadChoiceFromSet {>main}
[ 282 i ns n w/o s our c e s ]
s i mul at i on \ Si mul ator . j ava : 50 : r o l e s 0 = new Vector<Role >() ;
s i mul at i on \ Si mul ator . j ava : 52 : handl er s 0 = new Vector<Handler >() ;
SADA DA VERIFICAO FEITA PELA JPF EXCEPTIONS 135
s i mul at i on \ Si mul ator . j ava : 54 : par t i c i pant s 0 = new Vector<Par t i ci pant >() ;
. . .
gov . nasa . j pf . jvm. c hoi ce . ThreadChoiceFromSet {>main , Thread0}
s i mul at i on \ Si mul ator . j ava : 136 : par t i c . s t a r t ( ) ;
s i mul at i on \ Si mul ator . j ava : 137 : }
s i mul at i on \ Si mul ator . j ava : 135 : for ( Par t i c i pant par t i c : par t i c i pant s 0 ) {
gov . nasa . j pf . jvm. c hoi ce . ThreadChoiceFromSet {>main , Thread0, Thread3}
. . . .
gov . nasa . j pf . jvm. c hoi ce . ThreadChoiceFromSet {>Thread7, Thread8}
s i mul at i on \framework\Coordi natedAtomi cActi on . j ava : 39 : return i ndex ;
s i mul at i on \framework\ Coordi nator . j ava : 379 : System . out . pr i nt l n ( "Coordinator " + caa .
getI ndex ( ) + ": action finished") ;
s i mul at i on \framework\ Coordi nator . j ava : 380 : }
. . .
s i mul at i on \framework\ Coordi nator . j ava : 207 : return ;
====================================================== snapshot #1
====================================================== r e s u l t s
e r r or #1: br . usp . j pf . propert y . caa . Rol l backTransact i onPr oper t y "simulation.database.
BankDatabase.rollback()V"
====================================================== s ear ch f i ni s he d : 03/08/10 13: 26
C.2.2 Propriedade 2: Tratamento das Excees
136 APNDICE C
====================================================== s ear ch s t ar t e d : 03/08/10 13: 28
s i mul at i on . framework . Coordi nator . anyMethod( Coordi nator . j ava : 321)
====================================================== e r r or #1
br . usp . j pf . propert y . caa . Handl i ngExcepti onProperty
====================================================== t r ac e #1
gov . nasa . j pf . jvm. c hoi ce . ThreadChoiceFromSet {>main}
. . .
. . .
gov . nasa . j pf . jvm. c hoi ce . ThreadChoiceFromSet {>Thread8}
s i mul at i on \framework\ Coordi nator . j ava : 199 : i f ( except i onPr opagat i on == true ) {
s i mul at i on \framework\ Coordi nator . j ava : 204 : i f ( except i onRai s ed == true ) {
s i mul at i on \framework\ Coordi nator . j ava : 205 : System . out . pr i nt l n ( "EXCEPTION - RAISE") ;
s i mul at i on \framework\ Coordi nator . j ava : 206 : abort ( ) ;
s i mul at i on \framework\ Coordi nator . j ava : 220 : for ( Coordi natedAtomi cActi on ac t i on :
nes t edAct i ons ) {
SADA DA VERIFICAO FEITA PELA JPF EXCEPTIONS 137
s i mul at i on \framework\ Coordi nator . j ava : 238 : s us pendPar t i ci pant s ( ) ;
s i mul at i on \framework\ Coordi nator . j ava : 242 : thi s . caa . s e t St at us ( "INTERRUPTED") ;
s i mul at i on \framework\Coordi natedAtomi cActi on . j ava : 99 : thi s . s t at us = s t at us ;
s i mul at i on \framework\Coordi natedAtomi cActi on . j ava : 100 : thi s . no t i f yAl l ( ) ;
s i mul at i on \framework\Coordi natedAtomi cActi on . j ava : 101 : }
s i mul at i on \framework\ Coordi nator . j ava : 244 : pHandl ers = new Vector<Par t i ci pant >() ;
. . .
s i mul at i on \framework\ Coordi nator . j ava : 207 : return ;
====================================================== snapshot #1
====================================================== r e s u l t s
e r r or #1: br . usp . j pf . propert y . caa . Handl i ngExcepti onProperty
====================================================== s ear ch f i ni s he d : 03/08/10 13: 29
138 APNDICE C
Apndice D
Cdigo Fonte para Integrao via XML
D.1 Gerao do XML pela OConGraX
D.1.1 XMLGenerator.java
1 package br . usp . ime . ocongrax . program . f i l e ;
2
3 /
5
6 /
7
8 import j ava . i o . ;
9 import j ava . u t i l . ;
10
11 import j avax . xml . par s e r s . ;
12
13 import org . w3c . dom. ;
14 import org . xml . sax . SAXException ;
15
16 import br . usp . ime . ocongrax . program . data . Def UseStructure ;
17 import br . usp . ime . ocongrax . program . data . Pai r ;
18
19 import com. sun . org . apache . xml . i nt e r na l . s e r i a l i z e . ;
20
21 public cl ass XMLGenerator {
22
23 /
24 Generate the XML
25
26 @param fileXML
27 f i l e path and name
28 @param hashmap
29 data s t r uc t ur e which cont ai ns a l l the de f s and us es of obj e c t s
30 @param hashmap2
31 data s t r uc t ur e which cont ai ns a l l the de f s and us es of
32 except i ons
33 @param def UsePai rExc
34 i f true , pr i nt to f i l e the def use pai r s of except i ons
35
36 @throws IOExcepti on
37 @throws Par s er Conf i gur at i onExcept i on
38 @throws SAXException
39 /
40 public void gener at e ( Fi l e fileXML ,
41 HashMap<Stri ng , Def UseStructure> hashmap ,
42 HashMap<Stri ng , Def UseStructure> hashmap2 , boolean obj ,
139
140 APNDICE D
43 boolean exc , boolean def UsePai rObj , boolean def UsePai rExc )
44 throws IOExcepti on , Par s er Conf i gur at i onExcept i on , SAXException {
45 DocumentBui l derFactory dbf = DocumentBui l derFactory . newInstance ( ) ;
46 DocumentBuilder docBui l der = dbf . newDocumentBuilder ( ) ;
47
48 Document doc = docBui l der . newDocument ( ) ;
49 Element el ements = doc . createEl ementNS ( null , " el ements " ) ;
50
51 i f ( obj ) {
52 Vector<Stri ng> orderedKeys = new Vector<Stri ng >() ;
53 orderedKeys . addAl l ( hashmap . keySet ( ) ) ;
54 Co l l e c t i o ns . s or t ( orderedKeys ) ;
55 buildXML( hashmap , doc , el ements , orderedKeys , true , def UsePai rObj ,
56 def UsePai rExc ) ;
57 }
58
59 i f ( exc ) {
60 Vector<Stri ng> orderedKeys2 = new Vector<Stri ng >() ;
61 orderedKeys2 . addAl l ( hashmap2 . keySet ( ) ) ;
62 Co l l e c t i o ns . s or t ( orderedKeys2 ) ;
63 buildXML( hashmap2 , doc , el ements , orderedKeys2 , f al se ,
64 def UsePai rObj , def UsePai rExc ) ;
65 }
66
67 doc . appendChi l d ( el ements ) ;
68
69 Fi l eOutputStream out = new Fi l eOutputStream ( fileXML) ;
70 XMLSeri al i zer s e r i a l i z e r = new XMLSeri al i zer ( out , new OutputFormat ( doc ,
71 " i s o 88591" , true ) ) ;
72 s e r i a l i z e r . s e r i a l i z e ( doc ) ;
73 out . c l o s e ( ) ;
74 }
75
76 private void buildXML(HashMap<Stri ng , Def UseStructure> hashmap ,
77 Document doc , Element el ements , Vector<Stri ng> keys ,
78 boolean i sObj ectEl ement , boolean def UsePai rObj ,
79 boolean def UsePai rExc ) {
80 Element e , tag = null ;
81 Node n = null ;
82
83 for ( i nt i = 0; i < keys . s i z e ( ) ; i ++) {
84 i f ( i sObj ectEl ement )
85 tag = doc . createEl ementNS ( null , " obj e c t " ) ;
86 el se
87 tag = doc . createEl ementNS ( null , " except i on " ) ;
88
89 Def UseStructure du ;
90 Vector vDefs , vUses = new Vector() ;
91 Vector<Pai r> vI nner Pai r = new Vector<Pai r >() ;
92 Vector<Pai r> vExt er nal Pai r = new Vector<Pai r >() ;
93 du = hashmap . get ( keys . el ementAt ( i ) ) ;
94 vDef s = du . g e t De f i ni t i o ns ( ) ;
95 vUses = du . getUses ( ) ;
96 vI nner Pai r = du . getI nnerDef Uses ( ) ;
97 vExt er nal Pai r = du . getExternal Def Uses ( ) ;
98
99 e = doc . createEl ementNS ( null , " cl assname " ) ;
100 n = doc . createTextNode ( du . getClassName ( ) ) ;
101 e . appendChi l d ( n) ;
102 tag . appendChi l d ( e ) ;
103
104 e = doc . createEl ementNS ( null , "methodname" ) ;
105 n = doc . createTextNode ( du . getMethodName ( ) ) ;
GERAO DO XML PELA OCONGRAX 141
108
109 e = doc . createEl ementNS ( null , "name" ) ;
110 n = doc . createTextNode ( keys . el ementAt ( i ) . r e pl ac e (
111 du . getClassName ( ) + " " + du . getMethodName ( ) + " " , "" ) ) ;
114
115 i f ( def UsePai rExc && ! i sObj ectEl ement ) {
116 printDUPairsXML( doc , tag , vI nnerPai r , vExt er nal Pai r ) ;
117 }
118 i f ( def UsePai rObj && i sObj ectEl ement ) {
119 printDUPairsXML( doc , tag , vI nnerPai r , vExt er nal Pai r ) ;
120 }
121
122 for ( i nt j = 0; j < vDef s . s i z e ( ) ; j ++) {
123 i nt aux = vDef s . el ementAt ( j ) ;
124 e = doc . createEl ementNS ( null , " def " ) ;
125 n = doc . createTextNode ( "" + aux ) ;
128 }
129 for ( i nt k = 0; k < vUses . s i z e ( ) ; k++) {
130 i nt aux = vUses . el ementAt ( k) ;
131
132 e = doc . createEl ementNS ( null , " use " ) ;
133 n = doc . createTextNode ( "" + aux ) ;
136 }
137 el ements . appendChi l d ( tag ) ;
138 }
139 }
140
141 private void printDUPairsXML( Document doc , Element tag , Vector<Pai r> vPai r ,
142 Vector<Pai r> vExt er nal Pai r ) {
143 Element i Pai rTag ;
144 Element ePai rTag ;
145
146 i f ( vPai r . s i z e ( ) != 0) {
147 i Pai rTag = doc . createEl ementNS ( null , " i nne r pa i r s " ) ;
148 printInnerDUPairsXML( doc , tag , i Pai rTag , vPai r ) ;
149 }
150
151 i f ( vExt er nal Pai r . s i z e ( ) != 0) {
152 ePai rTag = doc . createEl ementNS ( null , " e xt e r na l pa i r s " ) ;
153 printExternalDUPairsXML( doc , tag , ePairTag , vExt er nal Pai r ) ;
154 }
155
156 }
157
158 private void printInnerDUPairsXML( Document doc , Element tag ,
159 Element i Pai rTag , Vector<Pai r> vPai r ) {
160 Element p ;
161 Element e ;
162 Node n ;
163
164 for ( i nt l = 0; l < vPai r . s i z e ( ) ; l ++) {
165 Pai r pai r = vPai r . el ementAt ( l ) ;
166 p = doc . createEl ementNS ( null , " pai r " ) ;
168 n = doc . createTextNode ( "" + pai r . getLi neDef ( ) ) ;
170 p . appendChi l d ( e ) ;
171 i Pai rTag . appendChi l d ( p) ;
172 tag . appendChi l d ( i Pai rTag ) ;
142 APNDICE D
173 e = doc . createEl ementNS ( null , " use " ) ;
174 n = doc . createTextNode ( "" + pai r . getLi neUse ( ) ) ;
177 i Pai rTag . appendChi l d ( p) ;
178 tag . appendChi l d ( i Pai rTag ) ;
179 }
180 }
181
182 private void printExternalDUPairsXML( Document doc , Element tag ,
183 Element ePairTag , Vector<Pai r> vExt er nal Pai r ) {
184 Element p ;
185 Element e ;
186 Element t ;
187 Node n ;
188
189 for ( i nt l = 0; l < vExt er nal Pai r . s i z e ( ) ; l ++) {
190 Pai r pai r = vExt er nal Pai r . el ementAt ( l ) ;
191 p = doc . createEl ementNS ( null , " pai r " ) ;
193 n = doc . createTextNode ( "" + pai r . getLi neDef ( ) ) ;
196 ePai rTag . appendChi l d ( p) ;
197 tag . appendChi l d ( ePai rTag ) ;
198
199 t = doc . createEl ementNS ( null , " e xt e r nal us e " ) ;
200
201 e = doc . createEl ementNS ( null , " cl assname " ) ;
202 n = doc . createTextNode ( "" + pai r . getExternal Cl assName ( ) ) ;
204 t . appendChi l d ( e ) ;
205 p . appendChi l d ( t ) ;
208
209 e = doc . createEl ementNS ( null , "methodname" ) ;
210 n = doc . createTextNode ( "" + pai r . getExternalMethodName ( ) ) ;
216
217 e = doc . createEl ementNS ( null , "name" ) ;
218 n = doc . createTextNode ( "" + pai r . getExternal Vari abl eName ( ) ) ;
224
225 e = doc . createEl ementNS ( null , " l i nenumber " ) ;
226 n = doc . createTextNode ( "" + pai r . getLi neUse ( ) ) ;
232 }
233 }
234 }
LEITURA DO XML PELO JAVA PATHFINDER EXCEPTIONS 143
D.2 Leitura do XML pelo Java PathFinder Exceptions
D.2.1 Mtodo readOcongraXml, da classe ExecutedPath.java
1 /
2
3 Thi s method r eads an Xml f i l e that cont ai ns the output of the Ocongra
4 appl i c at i on and c r e at e s a l i s t wi th the OcongraElements de s cr i bed i n the
5 f i l e .
6
7
8 /
9 public Li s t readOcongraXml ( St r i ng f i l ename ) throws IOExcepti on ,
10 Par s er Conf i gur at i onExcept i on , SAXException {
11 St r i ng cl assname = "" ;
12 St r i ng methodname = "" ;
13 St r i ng name = "" ;
14 i nt d e f l i n e = 0;
15 i nt us e l i ne = 0;
16 i nt i ndex = 0;
17 i nt i ndexpai r = 0;
18
19 boolean i s I nne r Pai r ;
20
21 Li s t <OcongraElement> ocongraEl ements = new ArrayLi st <OcongraElement >() ;
22
23 Fi l e aux = new Fi l e ( f i l ename ) ;
24
25 i f ( aux . e x i s t s ( ) ) {
26 DocumentBui l derFactory dbf = DocumentBui l derFactory . newInstance ( ) ;
27 DocumentBuilder docBui l der = dbf . newDocumentBuilder ( ) ;
28 Document doc = docBui l der . par s e (new Fi l e ( f i l ename ) ) ;
29
30 Element el ementsTag = doc . getDocumentElement ( ) ;
31 Element obj ectTag = null ;
32 Node cl assnameTag = null ;
33 Node methodnameTag = null ;
34 Node nameTag = null ;
35 Element pai rTag = null ;
36 Node defTag = null ;
37 Node useTag = null ;
38
39 for ( i nt i = 0; i < 2; i ++) {
40 i ndex = 0;
41 i f ( i == 0) {
42 obj ectTag = ( Element ) el ementsTag . getElementsByTagName (
43 " obj e c t " ) . i tem( i ndex ) ;
44 } el se {
46 " except i on " ) . i tem( i ndex ) ;
47 }
48 while ( ! ( obj ectTag == null ) ) {
49 cl assnameTag = ( Node ) obj ectTag . getElementsByTagName (
50 " cl assname " ) . i tem ( 0) ;
51 cl assname = cl assnameTag . getTextContent ( ) ;
52 methodnameTag = ( Node ) obj ectTag . getElementsByTagName (
53 "methodname" ) . i tem ( 0) ;
54 methodname = methodnameTag . getTextContent ( ) ;
55 nameTag = ( Node ) obj ectTag . getElementsByTagName ( "name" )
56 . i tem ( 0) ;
57 name = nameTag . getTextContent ( ) ;
58
59 pai rTag = ( Element ) obj ectTag . getElementsByTagName ( " pai r " )
144 APNDICE D
60 . i tem( i ndexpai r ) ;
61 while ( ! ( pai rTag == null ) ) {
62 defTag = ( Node ) pai rTag . getElementsByTagName ( " def " )
63 . i tem ( 0) ;
64 d e f l i n e = I nt e ge r . par s e I nt ( defTag . getTextContent ( ) ) ;
65 useTag = ( Node ) pai rTag . getElementsByTagName ( " use " )
66 . i tem ( 0) ;
67 i f ( ! ( useTag == null ) ) {
68 us e l i ne = I nt e ge r . par s e I nt ( useTag . getTextContent ( ) ) ;
69 i s I nne r Pai r = true ;
70 } el se {
71 useTag = ( Node ) pai rTag . getElementsByTagName (
72 "l i nenumber " ) . i tem ( 0) ;
73 us e l i ne = I nt e ge r . par s e I nt ( useTag . getTextContent ( ) ) ;
74 i s I nne r Pai r = f al se ;
75 }
76 i f ( i == 0) {
77 ocongraEl ements . add( ocongraEl ements . s i z e ( ) ,
78 new OcongraElement ( cl assname , methodname ,
79 name , i s I nne r Pai r , true , de f l i ne ,
80 us e l i ne , f al se ) ) ;
81 } el se {
82 ocongraEl ements . add( ocongraEl ements . s i z e ( ) ,
83 new OcongraElement ( cl assname , methodname ,
84 name , i s I nne r Pai r , f al se , de f l i ne ,
85 us e l i ne , f al se ) ) ;
86 }
87 i ndexpai r = i ndexpai r + 1;
88 pai rTag = ( Element ) obj ectTag . getElementsByTagName (
89 " pai r " ) . i tem( i ndexpai r ) ;
90 }
91
92 i ndex = i ndex + 1;
93 i ndexpai r = 0;
94 i f ( i == 0) {
96 " obj e c t " ) . i tem( i ndex ) ;
97 } el se {
99 " except i on " ) . i tem( i ndex ) ;
100 }
101 }
102 }
103 }
104 return ocongraEl ements ;
105 }
Referncias Bibliogrcas
[ABM98] Paul E. Ammann, Paul E. Black, e William Majurski. Using model checking to generate
tests from specications. Em Proceedings of the Second IEEE International Conference
on Formal Engineering Methods (ICFEM98, pginas 4654. IEEE Computer Society,
1998. 80
[ACP05] N. Guel A. Capozucca e P. Pelliccione. The fault-tolerant insulin pump therapy. Em
Proceedings of FM2005 Workshop on Rigorous Engineering of Fault-Tolerant Systems,
pginas 3342, 2005. 39
[Avi82] A. Avizienis. The four-universe information system model for the study of fault-
tolerance. Em Digest 12th Int. Symposium on Fault-Tolerance Computing, pginas
613, 1982. xi, 5, 6
[BBC
+
02] Len Felix Bachmann, Len Bass, Paul Clements, David Garlan, James Ivers, Reed Little,
Robert Nord, e Judith Staord. Documenting software architecture: Documenting
interfaces. Relatrio tcnico, Carnegie Mellon University, 2002. 37
[Ber03] Antonia Bertolino. Software testing research and practice. Em 10th International
Workshop on Abstract State Machines, pginas 121, 2003. 6
[Bin00] Robert Binder. Testing Object-Oriented Systems: Models, patterns and tools. Addison-
Wesley, 2000. 5
[BK08] Christel Baier e Joost-Pieter Katoen. Principles of Model Checking (Representation
and Mind Series). The MIT Press, 2008. xi, 28, 29, 31, 32
[Blo01] Joshua Bloch. Eective Java: Programming Language Guide. Addison-Wesley, 2001.
89
[Boe81] Barry W. Boehm. Software Engineering Economics. Prentice Hall PTR, Upper Saddle
River, NJ, USA, 1981. 28, 79
[BRR
+
00] D. M. Beder, A. Romanovsky, B. Randell, C. R. Snow, e R. J. Stroud. An application
of fault tolerance patterns and coordinated atomic actions to a problem in railway
scheduling. SIGOPS Oper. Syst. Rev., 34(4):2131, 2000. 39
[CDH
+
00] James C. Corbett, Matthew B. Dwyer, John Hatcli, Shawn Laubach, Corina S. Pa-
sareanu, Robby, e Hongjun Zheng. Bandera : Extracting nite-state models from java
source code. Em Proceedings of the 22nd International Conference on Software Engi-
neering, June 2000. 34
[CFRR09] Fernando Castor Filho, Alexander Romanovsky, e Ceclia Mary F. Rubira. Improving
reliability of cooperative concurrent systems with exception ow analysis. J. Syst.
Softw., 82(5):874890, 2009. 63, 78
[CGP
+
06] A. Capozucca, N. Guel, P. Pelliccione, A. Romanovsky, e A. Zorzo. Caa-drip: a
framework for implementing coordinated atomic actions. Em ISSRE 06: Proceedings
145
146 REFERNCIAS BIBLIOGRFICAS
of the 17th International Symposium on Software Reliability Engineering, pginas 385
394, Washington, DC, USA, 2006. IEEE Computer Society. 60, 111
[Cha91] Marcos Lordello Chaim. Poke-tool uma ferramenta para suporte ao teste estrutu-
ral de programas baseados em anlise de uxo de dados. Dissertao de Mestrado,
DCA/FEE/UNICAMP, Campinas, Brasil, 1991. 23
[CK99] Mei-Hwa Chen e Howard M. Kao. Testing object-oriented programs an integrated
approach. Em ISSRE 99: Proceedings of the 10th International Symposium on Soft-
ware Reliability Engineering, pgina 73, Washington, DC, USA, 1999. IEEE Computer
Society. 1, 3, 14, 20, 24, 80, 83, 85
[Cod] CodeCover. Disponvel em: http://www.codecover.org/. Acesso em: Jan. 2010. 23
[Cov] Coverlipse. Disponvel em: http://coverlipse.sourceforge.net/. Acesso em: Jan. 2010.
22
[CR86] Roy H. Campbell e Brian Randell. Error recovery in asynchronous systems. IEEE
Trans. Softw. Eng., 12(8):811826, 1986. 41
[Crn02] Ivica Crnkovic. Building Reliable Component-Based Software Systems. Artech House,
Inc., Norwood, MA, USA, 2002. 1
[CSE96] John Callahan, Francis Schneider, e Steve Easterbrook. Automated software testing
using model-checking, 1996. 80
[DGP08] Giovanni Denaro, Alessandra Gorla, e Mauro Pezz. Contextual integration testing
of classes. Em Fundamental Approaches to Software Engineering, 11th International
Conference, FASE 2008, Held as Part of the Joint European Conferences on Theory
and Practice of Software, ETAPS 2008, Budapest, Hungary, March 29-April 6, 2008.
Proceedings, pginas 246260, 2008. 23
[DGP09] Giovanni Denaro, Alessandra Gorla, e Mauro Pezz. Datec: Contextual data ow
testing of java classes. Em 31st International Conference on Software Engineering,
ICSE 2009, May 16-24, 2009, Vancouver, Canada, Companion Volume, pginas 421
422, 2009. 23
[DHJ
+
01] Matthew B. Dwyer, John Hatcli, Roby Joehanes, Shawn Laubach, Corina S. Psre-
anu, e Hongjun Zheng. Tool-supported program abstraction for nite-state verication.
Em In Proceedings of the 23rd International Conference on Software Engineering, p-
ginas 177187, 2001. 2, 80
[Dij70] Edsger W. Dijkstra. Notes on Structured Programming. circulated privately, Abril
1970. 7, 27
[dMF01] Gisele Rodrigues de Mesquita Ferreira. Tratamento de excees no desenvolvimento
de sistemas conaveis baseados em componentes. Dissertao de Mestrado, Unicamp,
Dezembro 2001. xi, 38
[DMJ07] Mrcio Eduardo Delamaro, Jos Carlos Maldonado, e Mario Jino. Introduo ao Teste
de Software. Elsevier, 2007. 5, 8, 10, 11, 13, 23, 24
[DW99] Desmond F. DSouza e Alan Cameron Wills. Objects, components, and frameworks with
UML: the catalysis approach. Addison-Wesley Longman Publishing Co., Inc., Boston,
MA, USA, 1999. 38
[Eck02] Bruce Eckel. Thinking in Java. Prentice Hall Professional Technical Reference, 2002.
17, 89
REFERNCIAS BIBLIOGRFICAS 147
[Ecla] EclEmma. Disponvel em: http://www.eclemma.org/. Acesso em: Jan. 2010. 22
[Eclb] Eclipse. Disponvel em: http://www.eclipse.org/. Acesso em: Jan. 2010. 22
[EM04] Dawson Engler e Madanlal Musuvathi. Static analysis versus software model checking
for bug nding. pginas 405427, 2004. 2, 80
[EMM] EMMA. Disponvel em: http://emma.sourceforge.net/. Acesso em: Jan. 2010. 22
[Fea] FeaVer. Disponvel em: http://cm.bell-labs.com/cm/cs/what/feaver/index.html.
Acesso em: Jan. 2010. 34
[Fra92] Nissim Francez. Program Verication. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 1992. 28, 31
[FRR05] Fernando Castor Filho, Alexander Romanovsky, e Ceclia Mary F. Rubira. Verica-
tion of coordinated exception handling. Em Technical Report CS-TR-927. School of
Computing Science, University of Newcastle upon Tyne, 2005. 63, 78
[FWA09] Gordon Fraser, Franz Wotawa, e Paul E. Ammann. Testing with model checkers: a
survey. Softw. Test. Verif. Reliab., 19(3):215261, 2009. 80
[Gak07] Luciana Setsuko Gakiya. Classicao e busca de componentes com tratamento de
excees. Projeto de Dissertao de Mestrado, 2007. 17
[GAO95] David Garlan, Robert Allen, e John Ockerbloom. Architectural mismatch or why its
hard to build systems out of existing parts. Em ICSE 95: Proceedings of the 17th
international conference on Software engineering, pginas 179185, New York, NY,
USA, 1995. ACM. 1
[GH99] Angelo Gargantini e Constance Heitmeyer. Using model checking to generate tests
from requirements specications. SIGSOFT Softw. Eng. Notes, 24(6):146162, 1999.
80
[GHJV00] Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides. Padres de Projeto:
Solues Reutilizveis de Software Orientado a Objetos. Bookman, 2000. 89
[GJSB05a] James Gosling, Bill Joy, Guy Steele, e Gilad Bracha. The Java Language Specication.
Addison-Wesley, 3rd edio, 2005. 3
[GJSB05b] James Gosling, Bill Joy, Guy Steele, e Gilad Bracha. The Java Language Specication.
Addison-Wesley, 2005. 17
[GR92] Jim Gray e Andreas Reuter. Transaction Processing: Concepts and Techniques. Morgan
Kaufmann Publishers Inc., San Francisco, CA, USA, 1992. 39
[HD01] John Hatcli e Matthew B. Dwyer. Using the bandera tool set to model-check pro-
perties of concurrent java software. Em CONCUR 01: Proceedings of the 12th In-
ternational Conference on Concurrency Theory, pginas 3958, London, UK, 2001.
Springer-Verlag. 2, 33, 34, 80
[HDD
+
03] John Hatcli, Xinghua Deng, Matthew B. Dwyer, Georg Jung, e Venkatesh Prasad
Ranganath. Cadena: An integrated development, analysis, and verication environment
for component-based systems. Software Engineering, International Conference on,
0:160, 2003. Disponvel em: http://doi.ieeecomputersociety.org/10.1109/ICSE.2003.
1201197. Acesso em 08 out. 2009. 2, 80
[HM07] Simone Hanazumi e Ana Cristina Vieira de Melo. Ferramenta para anlise do tra-
tamento excepcional de objetos. Monograa, 2007. 3, 14, 24, 25, 35, 78, 79, 80, 81,
112
[Hoa69] C. A. R. Hoare. An axiomatic basis for computer programming. Commun. ACM,
12(10):576580, 1969. 29, 30
[Hoa85] C. A. R. Hoare. Communicating sequential processes. Prentice-Hall, Inc., Upper Saddle
River, NJ, USA, 1985. 27, 64
[Hol91] Gerard J. Holzmann. Design and validation of computer protocols. Prentice-Hall, Inc.,
Upper Saddle River, NJ, USA, 1991. 33, 34
[Hol97] Gerard J. Holzmann. The model checker spin. IEEE Trans. Softw. Eng., 23(5):279295,
1997. 32, 33, 34
[Inq96] Inquiry Board. Ariane 5 - ight 501 failure - full report, 1996. Disponvel em: http:
//sunnyday.mit.edu/accidents/Ariane5accidentreport.html. Acesso em: Jan. 2010. 6
[Int06] International Software Testing Qualications Board. Standard Glossary of terms used
in Software Testing, 2006. 5
[Jac02] Daniel Jackson. Alloy: a lightweight object modelling notation. ACM Trans. Softw.
Eng. Methodol., 11(2):256290, 2002. 63
[Jav] Java PathFinder Team. Java pathnder. Disponvel em: http://javapathnder.
sourceforge.net/. Acesso em: Jan. 2010. 3, 32, 34, 42, 78, 112
[JGr] JGraph. Disponvel em: http://www.jgraph.com/. Acesso em: Jan. 2010. 82
[Jon90] Cli B. Jones. Systematic software development using VDM (2nd ed.). Prentice-Hall,
Inc., Upper Saddle River, NJ, USA, 1990. 27, 29
[JSS00] Daniel Jackson, Ian Schechter, e Hya Shlyahter. Alcoa: the alloy constraint analyzer.
Em ICSE 00: Proceedings of the 22nd international conference on Software enginee-
ring, pginas 730733, New York, NY, USA, 2000. ACM. 63
[JUn] JUnit. Disponvel em: http://www.junit.org/. Acesso em: Jan. 2010. 22
[Kim82] K.H. Kim. Approaches to mechanization of the conversation scheme based on monitors.
IEEE Transactions on Software Engineering, 8:189197, 1982. 39
[KS06] Mike Keith e Merrick Schincariol. Pro EJB 3: Java Persistence API (Pro). Apress,
Berkely, CA, USA, 2006. 42, 111
[KSH
+
95] D. Kung, N. Suchak, P. Hsia, Y. Toyoshima, e C. Chen. Object state testing for
object-oriented programs. Em COMPSAC 95: Proceedings of the 19th International
Computer Software and Applications Conference, pgina 232, Washington, DC, USA,
1995. IEEE Computer Society. 1
[Lam94] Leslie Lamport. The temporal logic of actions. ACM Trans. Program. Lang. Syst.,
16(3):872923, 1994. 33, 34, 61
[LC02] Yi Liu e H. Conrad Cunningham. Software component specication using design by
contract. Em Proceeding of the SouthEast Software Engineering Conference, Tennessee
Valley Chapter, National Defense Industry Association, 2002. 37
[Mac00] Patrcia D. L. Machado. Testing from structured algebraic specications. Em AMAST
00: Proceedings of the 8th International Conference on Algebraic Methodology and
Software Technology, pginas 529544, London, UK, 2000. Springer-Verlag. 80
[Mal91] Jos Carlos Maldonado. Critrios Potencias Usos: Uma Contribuio ao Teste Es-
trutural de Software. Tese de Doutorado, DCA/FEEC/UNICAMP, Campinas, Brasil,
1991. 23
[Mar94] John J. Marciniak, editor. Encyclopedia of software engineering. Wiley-Interscience,
New York, NY, USA, 1994. 27
[McC] Tim McCune. Exception-handling antipatterns. http://today.java.net/pub/a/today/
2006/04/06/exception-handling-antipatterns.html, Jun. 2006. 90
[McC76] Thomas McCabe. A software complexity measure. IEEE Transactions on Software
Engineering, SE-2:308320, 1976. 13
[MCJ89] Jos Carlos Maldonado, Marcos Lordello Chaim, e Mario Jino. Arquitetura de uma
ferramenta de teste de apoio aos critrios potenciais usos. Em XXII Congresso Nacional
de Informtica, So Paulo, Brasil, 1989. 23
[Mey92] Bertrand Meyer. Applying design by contract. Computer, 25(10):4051, 1992. 37
[Mil89] R. Milner. Communication and concurrency. Prentice-Hall, Inc., Upper Saddle River,
NJ, USA, 1989. 27
[Mil99] Robin Milner. Communicating and mobile systems: the pi-calculus. Cambridge Uni-
versity Press, New York, NY, USA, 1999. 27
[MK94] John D. McGregor e Timothy D. Korson. Integrated object-oriented testing and deve-
lopment processes. Commun. ACM, 37(9):5977, 1994. 1
[MP92] Zohar Manna e Amir Pnueli. The temporal logic of reactive and concurrent systems.
Springer-Verlag New York, Inc., New York, NY, USA, 1992. 33, 34, 61
[MPI00] MPIAT. Mars program independent assessment team summary report, Mar 2000. 6
[MSF06] Ana Cristina Vieira De Melo, Flavio Soares Correa Da Silva, e Marcelo Finger. Lgica
para Computao. Thomson Learning, 2006. 28, 29, 30
[Mye79] Glenford J. Myers. Art of Software Testing. John Wiley & Sons, Inc., New York, NY,
USA, 1979. 9
[NdM04] Paulo Roberto de Arajo Frana Nunes e Ana Cristina Vieira de Melo. Ocongra - uma
ferramenta para gerao de grafos de controle de uxo de objetos. Em Anais do 18
o
Simpsio Brasileiro de Engenharia de Software, Braslia, Brasil, 2004. 18
o
SBES. 81
[NHdM09] Paulo R. F. Nunes, Simone Hanazumi, e Ana C. V. de Melo. Ocongrax - automatically
generating data-ow test cases for fault-tolerant systems. Em Manuel Nez, Paul
Baker, e Mercedes G. Merayo, editors, TESTCOM/FATES09: Joint Conference of
the 21st IFIP Int. Conference on Testing of Communicating Systems and the 9th Int.
Workshop on Formal Approaches to Testing of Software, Lecture Notes in Computer
Science, pginas 229234. Springer, 2009. 3, 14, 24, 25, 35, 78, 79, 80, 112
[PdM10] David P. Pereira e Ana C.V. de Melo. Formalization of an architectural model for
exception handling coordination based on ca action concepts. Science of Computer
Programming, 75(5):333 349, 2010. Coordination Models, Languages and Applicati-
ons (SAC08). 42, 60, 64, 78, 111, 115
[PDV01a] Corina S. Pasareanu, Matthew B. Dwyer, e Willem Visser. Finding feasible counter-
examples when model checking abstracted java programs. Em TACAS 2001: Procee-
dings of the 7th International Conference on Tools and Algorithms for the Construction
and Analysis of Systems, pginas 284298, London, UK, 2001. Springer-Verlag. 2
[PDV01b] Corina S. Pasareanu, Matthew B. Dwyer, e Willem Visser. Finding feasible counter-
examples when model checking abstracted java programs. Em TACAS 2001: Procee-
dings of the 7th International Conference on Tools and Algorithms for the Construction
and Analysis of Systems, pginas 284298, London, UK, 2001. Springer-Verlag. 80
[Per07] David Paulo Pereira. Um framework para coordenao do tratamento de excees em
sistemas tolerantes a falhas. Dissertao de Mestrado, Universidade de So Paulo, So
Paulo, Brasil, 2007. 5, 41, 42, 60, 64, 78, 111, 115
[Pnu77] Amir Pnueli. The temporal logic of programs. Em SFCS 77: Proceedings of the 18th
Annual Symposium on Foundations of Computer Science, pginas 4657, Washington,
DC, USA, 1977. IEEE Computer Society. 33, 34, 61
[Pre01] Roger S. Pressman. Software Engineering: A Practitioners Approach. McGraw-Hill
Higher Education, 2001. xi, 1, 6, 7, 8, 10, 11, 13, 14, 28, 32, 37, 38
[Pru04] Leandro Cesar Prudente. Um estudo sobre teste versus vericao formal de programas
java. Dissertao de Mestrado, IME-USP, Maro 2004. 15
[Ran75] B. Randell. System structure for software fault tolerance. Em Proceedings of the
international conference on Reliable software, pginas 437449, New York, NY, USA,
1975. ACM. 39
[RDH04] Edwin Rodrguez, Matthew B. Dwyer, e John Hatcli. Checking strong specications
using an extensible software model checking framework. Em In Proceedings of the
International Conference on Tools and Algorithms for the Construction and Analysis
of Systems, pginas 404420. Springer, 2004. 2
[Rec] Recoder. Disponvel em: http://recoder.sourceforge.net/. Acesso em: Jan. 2010. 82
[RHB97] A. W. Roscoe, C. A. R. Hoare, e Richard Bird. The Theory and Practice of Concur-
rency. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1997. 64
[Rom01] Alexander Romanovsky. Coordinated atomic actions: how to remain acid in the modern
world. SIGSOFT Softw. Eng. Notes, 26(2):6668, 2001. 39
[RRDH03] Robby, Edwin Rodrguez, Matthew B. Dwyer, e John Hatcli. Checking strong speci-
cations using an extensible software model checking framework. Em Proceedings of the
International Conference on Tools and Algorithms for the Construction and Analysis
of Systems, pginas 404420. Springer, 2003. 80
[RRS
+
98] B. Randell, A. Romanovsky, R. J. Stroud, J. Xu, A. F. Zorzo, D. Schwier, e F. von
Henke. Coordinated atomic actions: Formal model, case study and system implemen-
tation. Relatrio tcnico, 1998. 61, 78
[RS03] Darrel Reimer e Harini Srinivasan. Analyzing exception usage in large java appli-
cations. Em Proceedings of the ECOOP 2003 Workshop on Exception Handling in
Object-oriented Systems, 2003. 90
[RW82] Sandra Rapps e Elaine J. Weyuker. Data ow analysis techniques for test data selection.
Em ICSE 82: Proceedings of the 6th international conference on Software engineering,
pginas 272278, Los Alamitos, CA, USA, 1982. IEEE Computer Society Press. 23
[RW85] Sandra Rapps e Elaine J. Weyuker. Selecting software test data using data ow infor-
mation. IEEE Trans. Softw. Eng., 11(4):367375, 1985. 23
[RXR96] A. Romanovsky, Jie Xu, e B. Randell. Exception handling and resolution in distri-
buted object-oriented systems. Em ICDCS 96: Proceedings of the 16th International
Conference on Distributed Computing Systems (ICDCS 96), pgina 545, Washington,
DC, USA, 1996. IEEE Computer Society. 39
[SH98] Saurabh Sinha e Mary Jean Harrold. Analysis of programs with exception-handling
constructs. Em ICSM 98: Proceedings of the International Conference on Software
Maintenance, pgina 348, Washington, DC, USA, 1998. IEEE Computer Society. 3,
17, 18, 20, 25, 80, 84, 87
[SH99] Saurabh Sinha e Mary Jean Harrold. Criteria for testing exception-handling constructs
in java programs. Em ICSM 99: Proceedings of the IEEE International Conference
on Software Maintenance, pgina 265, Washington, DC, USA, 1999. IEEE Computer
Society. 3, 17, 19, 20, 24, 25, 80, 84, 85, 112
[Som06] Ian Sommerville. Software Engineering. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA, 8th edio, 2006. xi, 6, 7, 28, 38, 79
[SP03] Amie L. Souter e Lori L. Pollock. The construction of contextual def-use associations
for object-oriented systems. IEEE Trans. Softw. Eng., 29(11):10051018, 2003. 24
[SPI] SPIN. Disponvel em: http://spinroot.com. Acesso em: Jan. 2010. 32, 33, 34
[Suna] Sun Microsystems. The java tutorials. Disponvel em: http://java.sun.com/docs/
books/tutorial/. Acesso em: Jan. 2010. 17
[Sunb] Sun Microsystems. Jdc tech tips: June 27, 2000. Disponvel em: http://java.sun.com/
developer/TechTips/2000/tt0627.html. Acesso em: Jan. 2010. 84
[Szy02] Clemens Szyperski. Component Software: Beyond Object-Oriented Programming.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2002. 37
[Tra00] Hung Tran. Test generation using model checking. Em Automated Verication, Fall
2000: A Collection of Reports. University of Toronto, 2000. 80
[VHB
+
03] W. Visser, K. Havelund, G. Brat, S. Park, e F. Lerda. Model checking programs.
Automated Software Engineering Journal, 10(2), April 2003. 2, 3, 32, 34, 78, 112
[VMWD05] A. M. R. Vincenzi, J. C. Maldonado, W. E. Wong, e M. E. Delamaro. Coverage testing
of java programs and components. Sci. Comput. Program., 56(1-2):211230, 2005. 24
[Voa98] Jerey M. Voas. The challenges of using cots software in component-based develop-
ment. Computer, 31(6):4445, 1998. 1
[W3 ] W3 Schools. Xml tutorial. Disponvel em: http://www.w3schools.com/xml/default.
asp. Acesso em: Jan. 2010. 84
[WD96] Jim Woodcock e Jim Davies. Using Z: specication, renement, and proof. Prentice-
Hall, Inc., Upper Saddle River, NJ, USA, 1996. 27, 29
[Wey88] E. J. Weyuker. The evaluation of program-based software test data adequacy criteria.
Commun. ACM, 31(6):668675, 1988. 1
[WFW09] Martin Weiglhofer, Gordon Fraser, e Franz Wotawa. Using coverage to automate and
improve test purpose based testing. Inf. Softw. Technol., 51(11):16011617, 2009. 5
[Win93] Glynn Winskel. The formal semantics of programming languages: an introduction. MIT
Press, Cambridge, MA, USA, 1993. 30
[Wor96] J. B. Wordsworth. Software engineering with B. Addison-Wesley Longman Publishing
Co., Inc., Boston, MA, USA, 1996. 27, 29
[Xav08] Kleber da Silva Xavier. Estudo sobre reduo do custo de testes atravs da utilizao de
vericao de componentes java com tratamento de excees. Dissertao de Mestrado,
Universidade de So Paulo, So Paulo, Brasil, 2008. 2, 3, 5, 17, 18, 21, 32, 34, 35, 60,
65, 78, 79, 80, 82, 87, 92, 111, 133
[XHdM08] Kleber S. Xavier, Simone Hanazumi, e Ana C. V. de Melo. Using formal verication to
reduce test space of fault-tolerant programs. Em SEFM 08: Proceedings of the 2008
Sixth IEEE International Conference on Software Engineering and Formal Methods,
pginas 181190, Washington, DC, USA, 2008. IEEE Computer Society. xi, 2, 79, 80,
112
[XRR
+
95a] Jie Xu, B. Randell, A. Romanovsky, C.M.F. Rubira, R.J. Stroud, e Zhixue Wu. Fault
tolerance in concurrent object-oriented software through coordinated error recovery.
FTCS 95: Proceedings of the Twenty-Fifth International Symposium on Fault-Tolerant
Computing, 0:0499, 1995. 38, 39, 41
[XRR
+
95b] Jie Xu, Brian Randell, Alexander Romanovsky, C. M.F. Rubira-Calsavara, R. J.
Stroud, e Z. Wu. Fault tolerance in concurrent object-oriented software through co-
ordinated error recovery. Relatrio tcnico, 1995. 39

Dissertacao Setembro

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Dissertacao Setembro

Enviado por

Direitos autorais:

Formatos disponíveis

Ambiente integrado para vericao e teste

Você também pode gostar