Transcript 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.

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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
1
Documents of Evolving Software
Software is being changed by fixing bugs, modifying
functions or adding new functions
Owing to such changes
No 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.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
2
Object Oriented Program Understanding
Features of Object Oriented Program
Many 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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
3
Visualizing Dynamic Behavior of Objects
UML: Sequence Diagram
It shows two kind of messages
Method Call
Object Generation
Showing this diagram, we can understand dynamic behavior of
objects
We try to extract sequence diagram by dynamic analysis
of a program
Method Call
1:A
2:B
3:C
Object Generation
4:D
5:D
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
4
A Problem of Dynamic Analysis
The amount of information of an execution trace is very huge
Because 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 information
We propose a method that detects some repetition patterns from
execution trace and abstracts them by replacing with a representative
of a repetition
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
5
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
6
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 information
When a “Enter Method” event occurred
Package name, Class name and Object-ID of a callee object
Signature of a method.
When a “Exit Method” event occurred
The method exit mark
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
7
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 patterns
R1 : Completely same repetition
R2 : Allowing different objects repetition
R3 : Lack of method calls repetition
Rule that compacts recursive calls
R4 : Recursive call structure
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
8
Rule R1： Completely Same Repetition
R1 compacts a repetition of completely same method call
structure
void A.a()
1
void C.c()
3
int B.b()
2
void A.a()
1
void C.c()
3
int B.b()
2
void A.a()
1
void C.c()
3
int B.b()
2
２
first time of the repetition
second time of the repetition
representative of
the repetition
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
9
Rule R2： Allowing Different Objects Repetition
R2 compacts a repetition of method call structure whose
objects may be different
void A.a()
1
void C.c()
3
int B.b()
2
void A.a()
4
void C.c()
6
int B.b()
5
void A.a()
1,4
void C.c()
3,6
int B.b()
2,5
２
first time of the repetition
second time of the repetition
representative of
the repetition
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
10
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
void C.c()
3
void A.a()
4
void C.c()
6
void A.a()
1,4
void C.c()
3,6
?
int B.b()
2
int B.b()
2
２
first time of the repetition
second time of the repetition
representative of
the repetition
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
11
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
void A.a()
2
void A.a()
3
int B.b()
5
int B.b()
6
void A.a()
1,2,3
R
void A.a()
1,2,3
int B.b()
4,5,6
int B.b()
4
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
12
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
13
How to draw non-compacted parts
void A.a()
1
int B.b()
2
A:1
B:2
a()
b()
int
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
14
Annotation for R1
void A.a()
1
void A.a()
1
int B.b()
int B.b()
2
2
R1
２
int B.b()
2
A:1
B:2
a()
b()
2
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
15
Annotation for R2
void A.a()
1
void A.a()
1
int B.b()
int B.b()
2
3
R2
２
int B.b()
2,3
A:1
B:2,3
a()
b()
2
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
16
Annotation for R3
void A.a()
1
void A.a()
1
２
int B.b()
int B.b()
2
3
R3
int B.b()
2,3
?
int C.c()
4
int C.c()
4
A:1
B:2,3
C:4
a()
b()
? c()
2
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
17
Annotation for R4
void A.a()
1
void A.a()
2
void A.a()
1,2
int B.b()
4
R4
int B.b()
3
A:1,2
a()
R
?
void A.a()
1,2
int B.b()
3,4
B:3,4
rec a()
rec a()
b()
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
18
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
19
Result of Compaction
Gemini
jEdit
250,000
228,764
250,000
217,351
200,000
208,360
205,483
200,000
178,128
150,000
150,000
100,000
100,000
50,000
50,000
57,365
16,889
16,510
0
0
Raw Data
R4
R１
R2
Raw Data
R3
Scheduler
5,000
4,500
4,000
3,500
3,000
2,500
2,000
1,500
1,000
500
0
4,398
R4
R１
1,954
1,762
R2
R3
LogCompactor
14,000
4,398
3,995
12,000
11,994
10,000
8,874
8,426
8,000
6,000
4,000
238
147
2,000
208
105
R2
R3
0
Raw Data
R4
R１
R2
R3
Raw Data
R4
R１
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
20
Sequence Diagram
Over View of the Diagram
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
21
Unified objects
Repetition
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
22
Summary
For Object Oriented program understanding
It is necessary to understand dynamic behavior of objects.
We try to make sequence diagrams from execution trace
The amount of the program execution trace tends to be very large
We 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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
23
End
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
24
Compaction (3)
Method
Time
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
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
25
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
26
Method calls which do not exist in the design diagram
Objects which do not exist in the design
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University
27