Extracting Sequence Diagram from Execution Trace of Java Program

1Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Extracting Sequence Diagram from Execution Trace of Java Program

Koji Taniguchi *, Takashi Ishio*,Toshihiro Kamiya**, Shinji Kusumoto*, Katsuro Inoue*

*Osaka University, Japan

**Japan Science and Technology Agency, Japan

2Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Documents of Evolving Software

Software is being changed by fixing bugs, modifying functions or adding new functions

Owing to such changesNo documents may represent the behavior of the software correctly because the software is repeatedly changed but the documents are not updated

It makes understanding of program behavior difficult.Especially in object oriented programs

We need reverse engineering techniques to recover some documents from a program.

3Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Object Oriented Program Understanding

Features of Object Oriented ProgramMany objects are concerned with a function

Owing to dynamic binding and extending, dynamic behavior of a program differs from static description

Message exchanges become more compress as increases of objects

It is difficult to understand dynamic behavior of objects from source codes

We need some documents that show dynamic behavior of objects

4Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Visualizing Dynamic Behavior of Objects

UML: Sequence DiagramIt shows two kind of messages

Method CallObject Generation

Showing this diagram, we can understand dynamic behavior of objects

We try to extract sequence diagram by dynamic analysis of a program

1:A 2:B 3:C

4:D

5:D

Method Call

Object Generation

5Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

A Problem of Dynamic Analysis

The amount of information of an execution trace is very hugeBecause an execution trace is recorded all method calls which occurred in loop and recursive call structures.

If we show all of them in a diagram, we can not understand easily

We need a method to reduce informationWe propose a method that detects some repetition patterns from execution trace and abstracts them by replacing with a representative of a repetition

6Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

How to Extract Sequence Diagram

1. Get the execution trace

2. Compact the execution trace

3. Draw the Sequence Diagrams from the compacted execution trace

7Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Step1 ： Execution Traces

The execution trace records the two event “Enter Method” and “Exit Method”

we treat the constructor as the one kind of the method

Recorded informationWhen a “Enter Method” event occurred

Package name, Class name and Object-ID of a callee objectSignature of a method.

When a “Exit Method” event occurredThe method exit mark

8Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Step2 ： Compaction of Execution Trace

Since an execution trace records many information, we need a method to reduce it

Our method detects some repetitions from execution trace and abstracts them by replacing with a representative of repetition

To compact the execution trace, we propose four Compaction Rules

Rules that compact some repetition patternsR1 : Completely same repetition

R2 : Allowing different objects repetition

R3 : Lack of method calls repetition

Rule that compacts recursive callsR4 : Recursive call structure

9Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Rule R1 ： Completely Same Repetition

R1 compacts a repetition of completely same method call structure

void A.a()

1

int B.b()

2

first time of the repetition second time of the repetition

void C.c()

3

void A.a()

1

int B.b()

2

void C.c()

3

representative ofthe repetition

void A.a()

1

int B.b()

2

void C.c()

3

２

10Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Rule R2 ： Allowing Different Objects Repetition

R2 compacts a repetition of method call structure whose objects may be different

void A.a()

1

int B.b()

2

first time of the repetition second time of the repetition

void C.c()

3

void A.a()

4

int B.b()

5

void C.c()

6

representative ofthe repetition

void A.a()

1,4

int B.b()

2,5

void C.c()

3,6

２

11Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Rule R3 ： Lack of Method Calls Repetition

R3 compacts a repetition of method call structure some of whose method calls may be lacked

void A.a()

1

int B.b()

2

first time of the repetition second time of the repetition

void C.c()

3

void A.a()

4

void C.c()

6

representative ofthe repetition

void A.a()

1,4

int B.b()

2

void C.c()

3,6

２

?

12Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Rule R4 ： Recursive Call Structure

R4 compacts recursive call structure by reconstructing it to be simple

R4 also not considers object ID

void A.a()

1

int B.b()

6

void A.a()

2

void A.a()

3

int B.b()

5

int B.b()

4

void A.a()

1,2,3

void A.a()

1,2,3

int B.b()

4,5,6

R

13Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Step3 ： Drawing Sequence Diagram

Draw a sequence diagram from a compacted execution trace

We define annotation symbols for each compaction rule

Compacted parts are drawn with them in the sequence diagram

14Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

A:1 B:2

a()

b()

int

void A.a()

1

int B.b()

2

How to draw non-compacted parts

15Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

A:1 B:2

2

a()

b()

R1

void A.a()

1

int B.b()

2

int B.b()

2

void A.a()

1

int B.b()

2

２

Annotation for R1

16Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

A:1 B:2,3

2

a()

b()

R2

void A.a()

1

void A.a()

1

int B.b()

2,3

２

int B.b()

2

int B.b()

3

Annotation for R2

17Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

A:1 B:2,3

2

a()b()

C:4

? c()

R3

void A.a()

1

int B.b()

2

int B.b()

3

void A.a()

1

int B.b()

2,3

２

int C.c()

4 int C.c()

4

?

Annotation for R3

18Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

A:1,2 B:3,4

a()

b()

rec a()

rec a()

void A.a()

1

int B.b()

4

void A.a()

2

int B.b()

3

R4

void A.a()

1,2

void A.a()

1,2

int B.b()

3,4

R ?

Annotation for R4

19Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Case Study

Case study processes as followings

Get execution traces from four Java program

jEdit ： Text Editor

Gemini ： Code clone analyzer

Scheduler ： Schedule management tool

LogCompactor ： The module of our tool that compacts execution traces

Apply four rules to four execution traces.The order of applying rules is R4→R1→R2→R3

Generate Sequence Diagrams

20Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Result of Compaction

jEdit228,764

217,351

178,128

16,889 16,510

0

50,000

100,000

150,000

200,000

250,000

Raw Data R4 R１ R2 R3

Scheduler

4,398 4,3983,995

238 1470

5001,0001,5002,0002,5003,0003,5004,0004,5005,000

Raw Data R4 R１ R2 R3

LogCompactor

11,994

8,874 8,426

208 1050

2,000

4,000

6,000

8,000

10,000

12,000

14,000

Raw Data R4 R１ R2 R3

Gemini

208,360 205,483

57,365

1,954 1,7620

50,000

100,000

150,000

200,000

250,000

Raw Data R4 R１ R2 R3

21Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Sequence Diagram Over View of the Diagram

22Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Repetition

Unified objects

23Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Summary

For Object Oriented program understandingIt is necessary to understand dynamic behavior of objects.

We try to make sequence diagrams from execution traceThe amount of the program execution trace tends to be very largeWe proposed a method to reduce information by compacting repetition part of the execution trace.

Draw the sequence diagram from the compacted execution trace

We can extract the simple sequence diagram that shows dynamic behavior of objects

24Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

End

25Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Compaction (3)

Time

Method

The prot of the methods which recorded the compacted execution trace of Gemini

The execution trace of Gemini was most compacted one.

But we can see some repetition of the method calls remain.

We need the more effective compaction rules

26Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

27Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University

Objects which do not exist in the designMethod calls which do not exist in the design diagram