teste de programas orientados a aspectos: uma abordagem

Roteiro

Teste de Programas Orientados a Aspectos: UmaAbordagem Estrutural para AspectJ

Otavio Augusto Lazzarini Lemos

Instituto de Ciencias Matematicas e de ComputacaoUniversidade de Sao Paulo

Av. do Trabalhador Sao-Carlense, 400Sao Carlos, SP

Email: [email protected]

Teste Estrutural de Programas Orientados a Aspectos

II Workshop de Engenharia de Software

Roteiro

Roteiro

1 Introducao

2 Programacao Orientada a Aspectos & Teste de SoftwareProgramacao Orientada a AspectosTeste de Software

3 Abordagem de Teste Estrutural para Programas OATeste de UnidadeTeste de Integracao

4 Automatizacao do Teste Estrutural de Unidade – JaBUTi/AJExtensoesTelas

5 Conclusoes e Trabalhos FuturosConclusoesTrabalhos Futuros



Introducao POA & Teste Teste Estrutural de Programas OA Ferramenta JaBUTi/AJ Conclusoes e Trabalhos Futuros

Introducao

POA – nova tecnica – uso mais efetivo da separacao deinteresses no desenvolvimento

Maioria dos trabalhos: implementacoes, aplicacoes...

Novo momento: outros problemas – projeto, VV&T

POA – diz-se que ⇑ entendimento e ⇓ esforco na manutencao

Entretanto nao evita erros – aplicacao de tecnicas de VV&T

Teste estrutural – caixa branca → estrutura logica dosprogramas

Motivacao: “Nao se pode confiar ...”Exemplo de criterios: todos-nos, todas-arestas




POA

Programacao Orientada a Aspectos

Em um projeto de software – importante separar os interesses

Anos 90 – interesses transversais (crosscutting) –espalhamento e entrelacamento

POA – mecanismos para implementar tais interesses emmodulos separados

Linguagem OA:

1 Modelo de pontos de juncao;

2 Mecanismo de identificacao dos pontos de juncao;

3 Unidades que encapsulam especificacoes de pontos de juncaoe mudancas de comportamento desejados (os aspectos) e

4 Processo de combinacao.

C1

C

C2

3

A




POA

A Linguagem AspectJ

Construcoes novas: aspect, pointcut, before, after earound; declare warning, error e parents (e outrostipos de declaracao inter-tipos)

Aspectos: especificacao de pontos de juncao, comportamentoa ser adicionado, atributos, metodos e classes internas, alemdas declaracoes.




POA

Estrategia de Implementacao do AspectJ

Ideia principal:

aspectos ⇒ classes no bytecode (.classseparados)adendos ⇒ metodos no bytecode

ajc – insere chamadas nos possıveispontos de juncao

Com essa implementacao – identificam-seos pontos afetados pelos adendos –chamadas aos “metodos adendos”

a1

a2

m1

m2

m1

m2

WC AC

AC

am1

am2

compile/weave




Teste de Software

Caso de teste – (d ,S(d))|d ∈ D

Testar cada d ∈ D – impraticavelCriterios de teste – avaliar e auxiliar na construcao

Teste estrutural – logica interna

Grafo de fluxo de controle e de dadosExemplos de criterios – todos-nos, todos-usos




Teste de Software

Teste de Software

Execucao de um software com a intencao de revelar erros

Importante – outras atividades de GQS sao insuficientes

Fases – Unidade, Integracao e Sistema

Menor Unidade: OO – Metodo, OA – Metodo e Adendo

Fase OO OAUnidade Intra-metodo Intra-metodo e Intra-adendo

Integracao Inter-metodo, Intra-classe Inter-metodo, Metodo-adendo,e Inter-classe Adendo-metodo, Inter-adendo,

Inter-metodo-adendo, Intra-classe eInter-classe

Sistema Toda a aplicacao Toda a aplicacao




Teste de Software

Teste de Programas Orientados a Aspectos

Teste Estrutural

Zhao (2002, 2003) – Adaptacao da abordagem de Harrold &Rothermel (1994) – fluxo de dadosModulo – adendo-combinado e metodo-combinadoTeste intra-modulo, inter-modulo, aspecto/classe

s45

me32

framecall

ae43

s33

s44

s46

ae39

s41

me34

s35

me29

s30

s47

s50

ae48

s49

s51

s52

s40

s42

framereturn

frameexit

frameloop

frameentry

me2me9 me11

s3

s4

s10s12

s45

me5

framecall

ae43

s6

s44

s46

ae39

s41

me7

s8

s47

s50

ae48

s49

s51

s52

s40

s42

framereturn

frameexit

frameloop

frameentry

me2me9 me11

s3

s4

s10 s12

me13

s14

me15

s16

s17

s18

Figura: Framed Control Flow Graphs




Teste de Software


Teste Estrutural

Zhao (2002, 2003) – Adaptacao da abordagem de Harrold &Rothermel (1994) – fluxo de dadosModulo – adendo-combinado e metodo-combinadoTeste intra-modulo, inter-modulo, aspecto/classe

s45

me32

framecall

ae43

s33

s44

s46

ae39

s41

me34

s35

me29

s30

s47

s50

ae48

s49

s51

s52

s40

s42

framereturn

frameexit

frameloop

frameentry

me2me9 me11

s3

s4

s10s12

s45

me5

framecall

ae43

s6

s44

s46

ae39

s41

me7

s8

s47

s50

ae48

s49

s51

s52

s40

s42

framereturn

frameexit

frameloop

frameentry

me2me9 me11

s3

s4

s10 s12

me13

s14

me15

s16

s17

s18

Figura: Framed Control Flow GraphsTeste Estrutural de Programas Orientados a Aspectos



Teste de Software


Teste Baseado em EstadosXu (2004) – Adaptacao do modelo FREE – Binder (1999)Mescla com teste estrutural

balance

close

[currentY-lastY>5&&

b<MAX_INA_BALANCE]

proceed

[currentY-lastY>5]

[b<0]

balance

freeze

unfreeze

debit

open

credit

balance

Frozen

Closed

Open

[b<0]

Overdrawn

settle

Inactive

credit[b<0]

credit

[b>=0]




Teste de Software


c2c1

c3

c0

Open

a1

a0

Overdrawn

d1

d0

d2

Inactive

r2r1

r3

r0

Frozen

b2b1

b3

b0

f2f1

f3

f0

c2c1

c3

c0

Overdrawn Open

a2




Teste de Unidade

Teste Intra-metodo e Intra-adendo

Adaptar grafos de fluxo

Diferencas:

Pontos de interacao entre metodos e adendos – locais onde osadendos definem comportamentoParalelo com chamadas de metodosAdaptar CFG – nos transversais (crosscutting nodes)AODU = (N,E , s,C ,T )C ⊆ N e o conjunto (possivelmente vazio) de nos transversaisque representam um no no qual ocorre uma interacao com umadendo de um dado aspecto;

AODU para AspectJ – extensao do trabalho de Vincenzi(2004) para bytecode




Teste de Unidade

public class Point {

public int x, y; public AClass a;

public Point(int _x, int _y) {

x = _x; y = _y;

}

public void affectedMethod(Point p, int

_x, int _y) {

try {

if (p.x <= 10 && p.y <= 10) {

p.x = _x; p.y = _y;

p.a = new AClass(10, 20);

}

p.printPoint(p);

System.out.println(p.x);

} catch (AnException ae) {

System.out.println("Exception " +

"catched!");

}

}

...

}

public aspect AnAspect {

pointcut exec(Point p, int i, int j):

execution(void

Point.affectedMethod(Point, int, int))

&& args(p, i, j);

pointcut settingA(AClass a):

set(AClass Point.a) && args(a) &&

!within(aspects.*);

pointcut handlerPC(Point p) :

handler(Point.AnException) && this(p);

before(Point p, int i, int j):

exec(p, i, j) {

if (p.x >= 0) p.x = i + 3;

if (p.y >= 0) p.y = j + 4;

}

after (Point p, int i, int j) returning():

exec(p, i, j) {

System.out.println("after " +

"returning exec");

if (i > 10)

System.out.println("i > 10");

else

System.out.println("i <= 10");

if (p.x > 10)

System.out.println("p.x > 10");

else

System.out.println("p.x <= 10");

}

void around(AClass a) : settingA(a) {

System.out.println("around settingA");

a.a = 20; a.b = 30;

proceed(a);

}

before(Point p) : handlerPC(p) {

p.x = 40;

}

}




Teste de Unidade

pu={p.x, p}

pu={p.y,p}

pu={p.y,p}

pu={p.x, p}

d={p,p.x,p.y,_x,_y}

cu={p,_x,_y}

cu={p.x}

d={p.a,p.x, p.y}

cu={p.x,p} <<around−AnAspect>>

<<before−AnAspect>>

<<before−AnAspect>>

pu={p.x, p}

pu={p.y,p}

cu={p.x}

cu={p.x,p}

pu={p.y,p}

pu={p.x, p}

cu={p,_x,_y}d={p.x, p.y}

d={p,p.x,p.y,_x,_y}

cu={p, _x, _y}<<afterReturning−AnAspect>>

18

61

71

43

0

9

39

21

30

0

109

135

127

148

160

Figura: AODUs de um metodo sem e com a presenca de um aspectoque o afeta.




Teste de Unidade

Criterios de Teste

todos-nos-transversais (Todos-NosC )

Requer que cada no transversal, e portanto cada execucao deadendo que ocorre na unidade afetada, seja exercitado pelomenos uma vez por algum caso de teste.

todas-arestas-transversais (Todas-ArestasC )

Requer que cada aresta do grafo AODU que tem um notransversal como no inıcio ou destino seja exercitada pelomenos uma vez por algum caso de teste.

todos-usos-transversais (Todos-UsosC )

Requer que cada par def-uso no qual o uso esta em um notransversal seja exercitado pelo menos uma vez por algum casode teste.




Teste de Unidade

Tabela: Requisitos de teste para cada criterio OA definido, para ometodo affectedMethod.

Criterio Conjunto de Requisitos Conjunto de Casos de Teste

Todos-NosC Rn = {0, 39, 127, 148} Rn = {((0, 0), 7, 6),((0, 0),−3, 7)}

Todas-ArestasC Re = {(0, 21), (21, 127)∗, (30, 39), Rn(30, 127)∗, (39, 109), (39, 127)∗, (109, 148),(127, 135), (135, 148), (148, 160)}

Todos-UsosC Ru = {( y, 0, 39), ( x, 0, 39), (p, 0, 39), Rn(this, 0, 39), (this, 0, 127), (L@8, 0, 148),(L@9, 0, 148), (L@10, 0, 148)}

∗ Requisitos nao-executaveis




Teste de Unidade

Hierarquia de Inclusao

Todos-C a m in h os

Todos-Usos

Todos-Usosei Todos-Usosed Todos-U sosC

Toda s-Aresta s

Toda s-Aresta sei Toda s-Aresta sedTodas-ArestasC

Todos-Nos

Todos-Nosei Todos-Nosed Todos-N osC

Figura: Hierarquia dos criterios definidos no trabalho de Vincenzi (2004)e neste trabalho.




Teste de Integracao

Teste de Integracao

Teste Metodo-adendo

Fluxo de Dados

Grafo MADU – para o teste Metodo-adendo restringindo aprofundidade para um nıvel

Escopos de adendo e de metodo




Teste de Integracao

Criterios de Teste

Pares Def-Uso Aspectuais – componente-componente,componente-aspecto, aspecto-componente, aspecto-aspecto

Criterios de teste: todos-cc-usos, todos-ca-usos, todos-ac-usose todos-aa-usos

Ideia – exercitar pares Def-Uso que representam os diferentestipos de interacoes entre aspectos e componentes.




Teste de Integracao

Exemplo de MADU

39

0

0

method−scope

pu={p.x, p}

d={p.x}

d={p.y}

advice−scope 1

advice−scope 4

pu={p.x,p} pu={p.x,p}

cu={p}

pu={p.y,p} pu={p.y,p}

cu={p}


cu={p,_x,_y}pu={_x}pu={_x}


cu={p.x,p}

pu={p.x, p}

127

127

148

148

d={p,p.x,p.y,_x,_y}

advice−scope 2cu={a}d={a.a, a.b}

advice−scope 3

d={p.x}cu={p}

d={p.x, p.y}

21

30

ret

ret

ret

39

1.15

1.22

1.29

1.36

1.0

4.0

4.14 4.25

4.33

4.42 4.53

4.61

3.0

ret

109

2.0

enh

enh

enh

enh




Teste de Integracao

Tabela: Pares Def-Uso aspectuais coletados a partir do grafo MADU dometodo affectedMethod, e conjuntos de casos de teste adequados paracada criterio.

Criterio Conjunto de Requisitos Conjunto de Casos de Teste

todos-ac-usos Rac = {(1.15, (21, 30), p.x), (1.15, (21, 109), p.x), Tac = {((0, 1), 7, 4), ((0, 1), 8, 4),(1.15, 109, p.x), (1.29, (30, 109), p.y), ((0, 1), 7, 10)}(1.29, (30, 39 enh), p.y)}

todos-ca-usos Rca = {(0 enh, (4.0, 4.25), x), (0 enh, (4.0, 4.14), x), Tca = {((0, 1), 10, 4),(0 enh, (4.33, 4.42), p.x)∗, (0 enh, (4.33, 4.53), p.x), ((0, 1), 11, 4), ((−1, 1), 7, 10),(39 enh, (4.33, 4.42), p.x)∗, (39 enh, (4.33, 4.53), p.x)} ((0, 1), 7, 4)}

todos-aa-usos Raa = {(1.15, (4.33, 4.42), p.x), (1.15, (4.33, 4.53), p.x), Taa = {((0, 1), 8, 10),(3.0, (4.33, 4.42), p.x)∗, (3.0, (4.33, 4.53), p.x)∗} ((0, 1), 7, 10)}

todos-cc-usos Rcc = {(0 enh, (21, 30), p), (0 enh, (21, 30), p.x), Tcc = Tac ∪ {((0,−1), 7, 4),(0 enh, (21, 109), p), (0 enh, (21, 109), p.x)∗, ((−1, 1), 7, 4)}(0 enh, (30, 39 enh), p), (0 enh, (30, 39 enh), p.y),(0 enh, (30, 109), p), (0 enh, (30, 109), p.y)∗,(0 enh, 39 enh, p), (0 enh, 39 enh, x), (0 enh, 39 enh, y),(0 enh, 109, p), (0 enh, 109, p.x)∗}

todos-usos Rac ∪ Rca ∪ Raa ∪ Rcc Tac ∪ Tca ∪ Taa ∪ Tcc

* Requisitos nao-executaveis




Teste de Integracao

Exemplo de MADU – par def-uso aspecto-aspecto

39

0

0

method−scope

pu={p.x, p}

d={p.y}

advice−scope 1

advice−scope 4


cu={p}


cu={p}


cu={p,_x,_y}pu={_x}pu={_x}

pu={p.x,p}

pu={p.x, p}

127

127

148

148

d={p,p.x,p.y,_x,_y}

advice−scope 2cu={a}d={a.a, a.b}

advice−scope 3

d={p.x}cu={p}

d={p.x, p.y}

cu={p.x,p}

pu={p.x,p}

d={p.x}

21

30

ret

ret

ret

39

1.15

1.22

1.29

1.36

1.0

4.0

4.14 4.25

4.33

4.42 4.53

4.61

3.0

ret

109

2.0

enh

enh

enh

enh




Extensoes

Extensao da Ferramenta JaBUTi

JaBUTi (Java Bytecode Understanding and TestIng) –Vincenzi (2004)

Extensoes:

Grafo AODUCriterios de teste OA




Telas

Telas da Ferramenta JaBUTi/AJ

Figura: Janela do gerenciador de projetos da JaBUTi/AJ.




Telas

(a) Bytecode de um aspecto. (b) AODU .

Figura: Telas da JaBUTi/AJ.




Telas

(a) Todos-NosC (b) Todas-ArestasC




Telas

Figura: AODU do adendo anterior de um aspecto.




Telas

(a) Grafo AODU do construtor deuma classe.

(b) Grafo AODU de um metodo.




Conclusoes

Primeira abordagem de teste estrutural que tratametodos/adendos como menores unidades

Adaptacao do grafo – AODUCriterios especificamente OA – Todos-NosC , Todas-ArestasCe Todos-UsosC

Apoio ferramental – JaBUTi/AJ

Consideracoes teoricas – teste de integracao

Teste Metodo-adendo – Grafo MADU e pares Def-Usoaspectuais – quatro criterios




Trabalhos Futuros

Criterios mais fortes – Ex. Potenciais-Usos

Avaliacao dos criterios – erros especıficos de programas OA,experimentos, explorar modelo de falhas de Alexander (2004)

Teste de integracao – explorar as outras fases

Ferramenta JaBUTi/AJ – melhorias, teste de integracao,ambiente de teste




Publicacoes

LEMOS, O. A. L.; VINCENZI, A. M. R.; MALDONADO, J. C.;MASIERO, P. C. Teste de unidade de programas orientados a aspectos.In: Anais do 18o Simposio Brasileiro de Engenharia de Software (indicadopara melhor artigo), Brasılia, DF, Brasil, p. 55–70, Outubro, 2004.

LEMOS, O. A. L.; MALDONADO, J. C.; MASIERO, P. C. StructuralUnit Testing of AspectJ Programs. Aceito para publicacao no 1o

Workshop de Teste de Programas Orientados a Aspectos (WTAOP 2005)– realizado em conjunto com o AOSD 2005, Chicago, EUA, Marco, 2005.

LEMOS, O. A. L.; MALDONADO, J. C.; MASIERO, P. C. Data-flowintegration testing criteria for aspect-oriented programs. In: Anais do 1o

Workshop de Desenvolvimento de Software Orientado a Aspectos (WASP2004) – realizado em conjunto com o SBES 2004, Brasılia, DF, Brasil,Outubro, 2004.




Teste de Programas Orientados a Aspectos: UmaAbordagem Estrutural para AspectJ

Otavio Augusto Lazzarini Lemos

Instituto de Ciencias Matematicas e de ComputacaoUniversidade de Sao Paulo

Av. do Trabalhador Sao-Carlense, 400Sao Carlos, SP

Email: [email protected]



teste de programas orientados a aspectos: uma abordagem

Documents