1. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 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

2. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 2 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.

3. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 3 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

4. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 4 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 1:A2:B3:C 4:D 5:D Method Call Object Generation

5. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 5 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

6. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 6 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

7. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 7 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

8. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 8 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

9. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 9 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 repetitionsecond time of the repetition void C.c() 3 void A.a() 1 int B.b() 2 void C.c() 3 representative of the repetition void A.a() 1 int B.b() 2 void C.c() 3 ２

10. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 10 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 repetitionsecond time of the repetition void C.c() 3 void A.a() 4 int B.b() 5 void C.c() 6 representative of the repetition void A.a() 1,4 int B.b() 2,5 void C.c() 3,6 ２

11. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 11 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 repetitionsecond time of the repetition void C.c() 3 void A.a() 4 void C.c() 6 representative of the repetition void A.a() 1,4 int B.b() 2 void C.c() 3,6 ２ ?

12. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 12 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 3 int B.b() 5 4 void A.a() 1,2,3 void A.a() 1,2,3 int B.b() 4,5,6 R

13. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 13 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

14. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 14 A:1B:2 a() b() int void A.a() 1 int B.b() 2 How to draw non-compacted parts

15. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 15 A:1B:2 2 a() b() R1 void A.a() 1 int B.b() 2 2 void A.a() 1 int B.b() 2 ２ Annotation for R1

16. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 16 A:1B:2,3 2 a() b() R2 void A.a() 1 1 int B.b() 2,3 ２ int B.b() 2 3 Annotation for R2

17. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 17 A:1B:2,3 2 a() b() C:4 ? c() R3 void A.a() 1 int B.b() 2 3 void A.a() 1 int B.b() 2,3 ２ int C.c() 4 4 ? Annotation for R3

18. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 18 A:1,2B:3,4 a() b() 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

19. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 19 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

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

21. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 21 Sequence DiagramOver View of the Diagram

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

23. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 23 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

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

25. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 25 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

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

27. Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 27 Objects which do not exist in the design Method calls which do not exist in the design diagram