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
2
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
2
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
2
?
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
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
2
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
2
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 R1 R2 R3
Scheduler
4,398 4,3983,995
238 1470
5001,0001,5002,0002,5003,0003,5004,0004,5005,000
Raw Data R4 R1 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 R1 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 R1 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