- Email: [email protected]
A New Approach for Recovering High-Level Sequence Diagrams from Object-Oriented Applications Using Petri Nets
Available online at www.sciencedirect.com Available online at www.sciencedirect.com
ScienceDirect ScienceDirect
Procedia online Computer 00 (2019) 000–000 Available at Science www.sciencedirect.com Procedia Computer Science 00 (2019) 000–000
ScienceDirect
www.elsevier.com/locate/procedia www.elsevier.com/locate/procedia
Procedia Computer Science 148 (2019) 323–332
Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018) Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018)
A New Approach for Recovering High-Level Sequence Diagrams A Newfrom Approach for Recovering High-Level Sequence Diagrams Object-Oriented Applications Using Petri Nets from Object-Oriented Applicationsa Using Petri Nets a a Chafik BAIDADA *, El Mahi BOUZIANE , Abdeslam JAKIMI Chafik BAIDADAa*, El Mahi BOUZIANEa, Abdeslam JAKIMIa a a
Software Engineering & Information Systems Engineering Team, Faculty of Sciences and Technics, Errachidia, MoroccoTeam, Faculty of Sciences and Technics, Software Engineering & Information Systems Engineering Errachidia, Morocco
Abstract Abstract Software development starts with sound documentation and design, but during the course of time, design document or other software are neither nor well maintained.and It is design, very essential to understand theofexisting systemdocument to maintain to Software artifacts development startsupdated with sound documentation but during the course time, design orand other evolve it artifacts with neware requirements. To better understand theseIt legacy need to extract dynamicsystem behavior and represent it software neither updated nor well maintained. is verysystems, essentialwe to understand the existing to maintain and to graphically in new models. Reverse engineering UML sequence diagrams is a very way todynamic understand the behavior of these evolve it with requirements. To better understand these legacy systems, we efficient need to extract behavior and represent it systems. Most approaches dealing with this subject, in addition to rarely way to filter code information, theyofdo not graphically in models. Reverse engineering UML sequence diagrams is offer a verya efficient waysource to understand the behavior these cover all Most UML approaches control operators thesubject, operatorin"par" which veryoffer important context ofcode parallelism. In thisthey paper, we systems. dealingsuch withasthis addition to is rarely a wayintothe filter source information, do not propose newcontrol approach to extract UML2 sequence diagrams multiple execution traces. This approach of cover all aUML operators such as the operator "par" which isfrom very important in the context of parallelism. In thisconsists paper, we generating of different use cases, analyzing them This using approach Colored Petri Nets of to propose a and newcollecting approachthe to corresponding extract UML2traces sequence diagrams from filtering multipleand execution traces. consists finally extract high-levelthe sequence diagram.traces of different use cases, filtering and analyzing them using Colored Petri Nets to generating andacollecting corresponding finally extract a high-level sequence diagram. © 2019 The Authors. Published by Elsevier B.V. © 2019 The Authors. by Elsevier B.V. This is an open accessPublished article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/) © 2019 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) Peer-review under responsibility of the the CC scientific committee of (http://creativecommons.org/licenses/by-nc-nd/3.0/) the Second International Conference on Intelligent Computing in This is an open access article under BY-NC-ND license Peer-review under responsibility of the scientific committee of the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). Peer-review under responsibility of the scientific committee of the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). Data Sciences (ICDS 2018). Keywords: reverse engineering; UML sequence diagrams; Petri nets; dynamic analysis. Keywords: reverse engineering; UML sequence diagrams; Petri nets; dynamic analysis.
1. Introduction 1. Introduction The understanding of legacy systems is an essential part of maintenance, reuse, validation and other activities of The understanding legacy systems an essential of of maintenance, reuse,isvalidation andunderstanding other activities of software engineering. of According to someis studies, up topart 60% the maintenance devoted to their softwarecode engineering. According to some studies, up to 60%and of techniques the maintenance is devoted understanding their source [1]. Therefore, it is important to develop tools that facilitate the to task of understanding source code [1]. Therefore, it is important to develop tools and techniques that facilitate the task of understanding
* Corresponding author. Tel.: +212619598527. E-mail address:[email protected] * Corresponding author. Tel.: +212619598527. E-mail address:[email protected] 1877-0509 © 2019 The Authors. Published by Elsevier B.V. This is an open access under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/) 1877-0509 © 2019 Thearticle Authors. Published by Elsevier B.V. Peer-review underaccess responsibility of the scientific committee oflicense the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). This is an open article under the CC BY-NC-ND (http://creativecommons.org/licenses/by-nc-nd/3.0/) Peer-review under responsibility of the scientific committee of the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). 1877-0509 © 2019 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) Peer-review under responsibility of the scientific committee of the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). 10.1016/j.procs.2019.01.040
324 2
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
such systems because the documentation is often absent, outdated or incomplete. An effective comprehension technique to understand these systems is reverse engineering. Reverse engineering consists of retrieving models from a program in order to understand its structure and behavior. In the object-oriented world, the target modeling language most used for reverse engineering is UML (Unified Modeling Language) [2] due to its significant presence in the industry. The reverse engineering of UML static diagram has been studied and is now implemented in several tools. Static diagrams help engineers to understand the structure of systems, but they do not allow understanding its behavior. To do this, dynamic models are needed, such as sequence diagrams or state machine diagrams. This paper presents the results of our first investigation in reverse engineering for extracting UML sequence diagrams from the source code of legacy systems. The rest of this paper is organized as follows: Section 2 outlines some related work in terms of existing approaches. Section 3 introduces a background in reverse engineering of UML2 sequence diagrams using Colored Petri Nets (CPN). Section 4 describes our approach. A case study is presented in Section 5. Finally, section 6 concludes our work and give directions for future research. 2. RELATED WORK In this section, we present an overview of existing work in reverse engineering of sequence diagrams. Chikofsky and Cross [3] define reverse engineering as the process for identifying and analysis of software system components, their interrelationships and the representation of their entities at a higher level of abstraction. Reverse engineering by itself involves only analysis; it does not involve changing the subject system or not create any new system. Recently, many works have been done on the reverse engineering of sequence diagrams. We distinguish two categories of existing approaches: static and dynamic. Static analysis is to use the code structure to generate the sequence diagrams. Various approaches have been developed to capture a system’s behavior through static analysis [4, 5, 6, 7]. One of the main of them is that of Rountev et al. [7]. They proposed an approach for the extraction of UML sequence diagrams from the source code of a system through building control flow graphs. In this study, the nodes represent the basic blocks of a program and the links represent all kinds of interactions between these blocks. The dynamic analysis, on the other hand, is to analyze a software system under execution. As such, runtime objects can be detected, thus making it possible to expose occurrences of polymorphism and late binding in contrast to static analysis. The produced execution traces contain very detailed information on how a system operates. Several studies have tried to generate sequence diagrams by analyzing the execution traces. Taniguchi et al. [8] propose an automatic approach for the reverse engineering of sequence diagrams from the execution traces of an object-oriented program. They present these traces in the form of a tree where each node represents a method call. They present four compaction rules, including compaction of repetitions and compaction of recursive calls, in order for the traces to be reduced in size, thereby producing compact sequence diagrams. In [9], they try to build a highlevel sequence diagram from combined fragments using the state vector describing the system. The approach presented consists of two phases. During the first phase, a simple sequence diagram is generated containing just the method calls. The second phase makes it possible to draw high-level sequence diagrams by combining the diagrams generated in the first step. This is done by analyzing the different states of the system. In [10], it proposes an approach based on dynamic analysis. The authors use LTS (Labeled Transition System) for modeling execution traces. Then they generate a high-level sequence diagram from this LTS. These approaches have succeeded in generating representative sequence diagrams. However, they recognize some limitations. Since our approach is based on dynamic analysis, we focus on comparing it with approaches that use execution traces to extract sequence diagram. Differences between these approaches are summarized in Table1. Though not exhaustive, this table does illustrate the differences relevant to our work. The strategies reported in Table 1 [8, 9, 10] are compared according to five criteria: - Multiple execution trace: The behavior of a system is often described by multiple execution traces that correspond to different scenarios. - Use of filtering technics: As mentioned in [11] Cornelissen et al. defines several filtering technics in the context of trace execution collection. For example, traces corresponding to simple getters and setters methods are not generated. The approaches mentioned above do not use like this filtering technics. Thus, the resulting execution traces contains a lot of useless information. - Programming language: This to show how many languages the approach support.
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./Procedia Computer Science 00 (2019) 000–000
325 3
- UML2 Combined fragment Supported: which operators can the approach extracts by analyzing the execution traces? - Thread information: if the approach provides information to detect the threads execution. Table 1. Related work for dynamic analysis Multiple execution Programming language traces
UML2 Combined fragment Supported
Thread information
Use filtering technics
[8]
No
Java
No
No
Yes
[9]
No
Java
seq, alt, loop
No
No
[10]
Yes
All POO languages
seq, alt, loop
No
Yes
As mentioned in table 1, none of the approaches covers all the above criteria. That is why; we propose to revisit the problem of the reverse engineering of UML sequence diagrams by a new approach. Our approach uses the dynamic analysis to build UML2 sequence diagrams with a consideration of all the criteria mentioned before.
3. UML2 AND COLORED PETRI NETS In this section, we discuss the dynamic reverse engineering of High-level Sequence Diagrams (HLSD) from multiple execution traces and we give some definitions that help us to explain clearly our approach. 3.1. UML2 sequence diagrams Sequence diagrams are the more commonly used diagram for capturing inter-object behavior. Sequence diagrams are typically associated with use case realizations in the logical view of the system under development. Sequence Diagrams (SD) have been significantly changed in UML 2.0 [2]. A (HLSD) is a sequence diagram that refers to a set of Basic Sequence Diagram (BSD) and composes them using a set of interaction operators. The main operators are: seq for sequence, alt for alternatives, loop for iterative actions, and par for parallelism. 3.2. Execution Traces To build HLSD diagrams using dynamic analyses, we have to generate traces of program executions describing the behavior of each thread of a program. Each trace corresponds to a scenario of a given use case. In what follows, we introduce a set of definitions relatives to execution traces, which are necessary to understand the approach. Definition 1: A trace line is a triplet T = where: - Sender is the caller object, expressed in the form threadNumber:package:classe:object. - Message is the invoked method of the receiver object, expressed in the form methodName(param1, param2, …). - Receiver is the called object, expressed in the form package:classe:object. Definition 2: An execution trace is a set of trace lines. Definition 3: (Equivalence between method invocations): The method invocations l1 = (sender1; message1; receiver1) and l2 = (sender2; message2; receiver2) are equivalent if
and only if: - Two objects are equivalent if they are instances of the same class and are created in the same thread (using the constructor Invocation) with the same values of parameters. - The messages message1 and message2 concern the same method and have the same signature.
326 4
-
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
The receivers reciver1 and receiver2 are two equivalent objects.
3.3. Colored Petri networks Petri nets [12] are a well-known and developed formalism with a rich theory, practical applications ranging from communication networks to healthcare systems and are supported by a wide range of commercial and noncommercial tools. Colored Petri nets (CPNs) are a backward compatible extension of Petri nets. CPNs preserve useful properties of Petri nets and at the same time extend the initial formalism to allow the distinction between tokens. CPNs allow tokens to have a data value attached to them. This attached data value is called token color.
Fig 1. A HLSD mapped onto CPN with operators loop and alt
From the many existing variants of Petri nets, CPNs are used in composing and integrating scenarios that are represented in the form of sequence diagrams [13, 14]. Four operators for composing scenarios have been implemented: sequential, conditional, iterative and concurrent. CPNs suit our approach as they can map a HLSD efficiently. Places represent BSD and transitions represent operators such as alt, loop, seq, and par. Colors are used to distinguish between places. All places from the same trace have the same color. That is very helpful to distinguish between scenarios in a HLSD. Fig. 1 shows how a HLSD can be mapped easily into a CPN. P1 represents the BSD which describes that the object a of the class A sends the message m1 to the object b of the class B. P2 represents the BSD which describes that the object b sends the message m2 to the object a. P3 represents the BSD which describes that the object b sends the message m3 to the object a. T1 represents the operator alt with the condition C2. T2 represents the operator alt with the condition C3. T3 represents the operator loop with the condition C1.The operators par and seq can be mapped also as it is shown in Fig. 2. In Fig. 2, P1 represents the BSD which describes that the object a sends the message m1 to the object b. P2 represents the BSD which describes that the object b sends the message m2 to the object a. P3 represents the BSD which describes that the object a sends the message m3 to the object b. P4 represents the BSD which describes that the object a sends the message m4 to the object b. T1 represents the operator seq. T2 represents the operator par. From what precedes, we can conclude that, for a HLSD, we can generate a CPN that can represent all major UML sequence diagram operators.
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./Procedia Computer Science 00 (2019) 000–000
327 5
Fig. 2. A HLSD mapped onto CPN with operators par and seq.
In this section, we discussed the reverse engineering of sequence diagram and gave definitions that are necessary for better comprehension of our approach. The problem that arises is how we can reverse this process. I.e.: how, from execution traces, can we generate a CPN that can be mapped onto a HLSD? (1) 4. 4. Approach overview The proposed approach for reverse engineering of UML sequence diagrams is illustrated in Fig. 3. Our work is inspired by [15]. The approach is defined in five main steps: (i) System analysis, (ii) Trace generation, (iii) Trace collection and filtering, (iv) Abstraction building and (v) HLSD extraction. In the following subsections, each step is detailed. Consulting functional expert
User interface analysis
Specification documents …etc.
System entry values identification
Real world systems
6\VWHP $QDO\VLV
7UDFHV JHQHUDWLRQ
+/6'([WUDFWLRQ
7UDFHV &ROOHFWLRQ)LOWHULQJ
$EVWUDFWLRQ %XLOGLQJ
CPNs Extraction CPNs Integration
Fig 3. Approach overview
4.1. System Analysis In the System analysis activity, the analyst tries to analyze and understanding the system. The objective is to identify the system entry values corresponding to different scenarios describing the system behavior. For this, the system must be run several times (one execution for each possible scenario). Indeed, one execution session is not enough to have the general behavior of the system. However running the system to cover all possible entries of the system is
328 6
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
not always possible because the range of data values is often infinite. To avoid this, the analyst must identify relevant system entries to cover all possible system functionalities. To do this, the analyst has three possibilities. He can consult a functional expert who knows the different input values of the system. He can use the available system documentation. Finally, he can analyze the user interfaces to deduce how the system works. 4.2. Trace generation To extract HLSD diagrams from an oriented-object program, we concentrate on reverse engineering relying on dynamic analysis. As mentioned in [16], dynamic analysis is more suited to the reverse engineering of sequence diagrams of object-oriented systems because of inheritance, polymorphism and dynamic binding. This dynamic analysis is usually performed using execution traces. There are multiple ways to generate execution traces [1]. We choose to use bytes code instrumentation. In some legacy systems, the source code may not be available. Among several trace collection tools for Java software systems, we chose MoDec [17]. This one provides a very interesting option where the user can choose among the classes of the system those he wants to follow and instrument. This is very helpful in the next step. 4.3. Trace collection and filtering The system behavior is related to the environment entry data, in particular, values introduced by the user to initialize specific system variables. Thus, one execution session is not enough to identify all system behaviors. Therefore, we chose to run the system several times to generate different execution traces. Each execution trace corresponds to a particular scenario of a given use case of the system. Using MoDec, a filtering process is applied to the system when it is running. This process is based on two filtering rules: distinction between domain classes and implementation specific classes or the exclusion of certain packages. No lines that contain a package that is not interesting will appear in traces. For example, all objects on the package relatives of the GUI of the system such as Swing for Java can be ignored. This process enables us to concentrate on the main behavior of the system. We developed an adapter in order to restructure the output trace in the form as defined in definitions 1 and 2 and therefore appropriate to the processing of the diagram construction stage. 4.4. Abstraction building The abstraction building activity consists of deriving CPN from the acquired traces. CPNs corresponding to the same use case (scenarios) are iteratively merged to obtain an integrated CPN of the use case. The color aspect of CPNs is used to keep track of input scenarios in the resulting Abstraction. The algorithm CPN_IncrementalExtraction (see below) describes the process of this step. It takes several execution traces as input and generate incrementally a CPN that represents the system behavior. First, the algorithm scans the execution traces line by line. Each line is analyzed if it is a new one, a new place is created. All places that represent lines of a trace have the same color. These colors allow us to distinguish between the scenarios as a trace represents the execution of a scenario. This gives the possibility of subdividing an HLSD into several HLSDs to facilitate the task of understanding the system. The algorithm also creates transitions. It associates for each place the corresponding transition by analyzing previous and current lines. The algorithm focuses on the ID of threads to distinguish between threads. If the lines belong to the same thread, the operators seq and alt can be identified easily by simple comparison between previous and current lines in different traces. The operator par is detected by analyzing the main thread and his sub-threads. The transition corresponding to the current line is marked temporarily “loop” if it already exists and belongs to the same trace (same scenario).The final operator loop is obtained if a transition is already marked as a loop.
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./Procedia Computer Science 00 (2019) 000–000
329 7
CPN_IncrementalExtraction(IN trace trace_set) Place N_place ; Color N_color ; CPN N_cpn ; For each trace T in trace_set /* a CPN COLOR is created for each trace*/ N_color = createNewCPNColor()); For each line l in T N_place =creatPlaceWithColor(l,N_c) ; If (isCPNImpty()) Add_Place_To_CPN(N_place); else If(isNotNew(l)) if ( isInSameTrace(l))/* the same line in the same trace*/ if(isLoopMarked(N_cpn)) change_pervious_Transition(“loop”,N_cpn) ; else maark_pervious_Transition(“loop”,N_cpn) ; Endif else If(isTheSamethread()) if (previous_place_haveTransition(N_cpn)) /* change all transition of previuos place to “alt”*/ change_Transition_To_CPN(“alt”, N_cpn ) ; Add_Place_To_CPN(N_place, N_cpn ) ; else Add_Place_To_CPN(N_place, N_cpn ) ; Add_Transition_To_CPN(“seq”, N_cpn ) ; ENdif /*if the ID of the previous thread is the main thread */ else If ( is_previous_MainThreadID()) Add_Transition_To_CPN(“par”, N_cpn ) ; /*add place to the previous transition par*/ Add_Place_To_CPN(N_place, N_cpn ) ; else /*no need to add transition it already exists*/ Add_Place_To_CPN(N_place, N_cpn ) ; ENdif EndIf Endif Endif EndForeach EndForeach END CPN_IncrementalExtraction
4.5. HLSD extraction In this step, we can easily build HLSD by mapping the resulting CPN using transformation rules as is it shown in Fig. 1 and Fig. 2. 5. Case study In this section, we chose the example of a calculate application. The application takes a complex calculation to be resolved as input. The application makes an estimate of the complexity of the calculation. If it is quite simple, the main thread of the system makes it (Scenario 1), otherwise the calculation is divided into two parts where each one is solved by a different thread (Scenario 2). After the result is sent to the main thread which displays the final result for the user (Scenario 1 and Scenario 2). Here is the source code of the application. It includes four classes: MainThread.java, ClientObject.java, ThObject2.java, ThObject1.java, and Calculator.java. In listing Listing 1 and Listing 2, the class MainThread.java and ClientObject.java are given.
330 8
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
Listing 1: MainThread.java
package pack1; import java.util.Scanner; public class MainThread { private ClientObject clientObj; private ThObject1 ThObj1; private ThObject2 ThObj2; private int [] terms; public void display() { System.out.println("enter the number of terms of the multiplication "); Scanner sc = new Scanner(System.in); int numberTerms = sc.nextInt(); clientObj= new ClientObject(this); terms= new int[numberTerms]; for (int i = 0; i < numberTerms; i++) { System.out.print("enter the number: "+i+" "); terms[i]= sc.nextInt();} clientObj.giveCompute(terms); } public int getRestult(){ int res=1; for (int i = 0; i < terms.length; i++) { res=res*terms[i];} return res; } public int getRestultTh(){ return ThObj1.getResult1()* ThObj2.getResult2(); } public void orderCompute(){ ThObj1 = new ThObject1(this.terms);ThObj1.start(); synchronized(ThObj1){ try{ System.out.println("Waiting for thread 1 ThObj1.wait();}catch(InterruptedException e){ e.printStackTrace();} ThObj2 = new ThObject2(this.terms); ThObj2.start(); synchronized(ThObj2){try{ System.out.println("Waiting for thread 2 ThObj2.wait();}catch(InterruptedException e){ e.printStackTrace(); }} }} }
..."); ...");
Listing 2: ClientObject.java
package pack1; public class ClientObject { public void giveCompute(int []n) {terms=n; } public void estimate() {if(terms.length >10 ){ MainTh.orderCompute(); System.out.println(MainTh.getRestultTh()); } else System.out.println( MainTh.getRestult()); } public ClientObject(MainThread M){MainTh=M; } private MainThread MainTh; int [] terms;}
After the instrumentation of bytes code by MoDec and the execution of the instrumented program, a trace file is generated. This file contains all the events of construction and destruction of the objects of the instrumented classes. The invocation and return events of its invoked methods are also recorded. To organize the execution log files according to the form proposed by our approach, we use the adapter that we developed for this purpose. The final execution traces generated as illustrated in Table 2 can provide different types of behavioral interactions. Table 2: Generated traces of the system Trace 1(Scenario 1) L0. 0:pack1:MainThread:MainTh |display() | pack1:ClientOject:ClientObj L1. 0:pack1:ClientOject:ClientObj|giveCalcul(int[] n ) |pack1:MainThread:MainTh L2. 0:pack1:MainThread:MainTh |estimate() |pack1:MainThread:MainTh L3. 0:pack1:MainThread:MainTh |getResult() |pack1:ClientOject:ClientObj L0. 0:pack1:MainThread:MainTh |display() |pack1:ClientOject:ClientObj Trace 2 (scenario 2) L0. 0:pack1:MainThread:MainTh |display() |pack1:ClientOject:ClientObj L1. 0:pack1:ClientOject:ClientObj |giveCalcul(int[] n) |pack1:MainThread:MainTh L2. 0:pack1:MainThread:MainTh |estimate() |pack1:MainThread:MainTh L4. 0:pack1:MainThread:MainTh |order() |pack:ThObectj1:ThObj1 L5. 0:pack1:MainThread:MainTh |order() |pack:ThObectj2:ThObj2 L6. 1:pack1:ThObectj1:ThObj1 |getResult1() |pack1:MainThread:MainTh L7. 2:pack1:ThObectj2:ThObj2 |getResult2() |pack1:MainThread:MainTh L3. 0:pack1:MainThread:MainTh |getResultTh() |pack1:ClientOject:ClientObj L0. 0:pack1:MainThread:MainTh |display() |pack1:ClientOject:ClientObj
Scenario 1
Scenario 2
Table 2 shows that each trace refers to a scenario for a use case of the application: Trace 1 corresponds to Scenario 1 when the given calculation is easy. The main thread does the calculus and show the result for the user.
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./Procedia Computer Science 00 (2019) 000–000
331 9
In Trace 2, the scenario is when the calculation is complex. One part of the calculation is given to the thread ThObj1 and the other to the thread ThObj2. The first thread gives to the main thread the result before the second thread. When the two threads have finished, the application display the result to the user and ask him to give new calculation (Scenario 2). After applying our algorithm to these traces, the CPN below is obtained (Fig 4).
Fig 4. The extracted CPN.
Fig. 4 shows the CPN extracted has 8 places and 8 transitions. Each place refers to a BSD and each transition corresponds to an operator. The places of the CPN contain colors. These colors are used to differentiate places of a trace from another. In this CPN, Trace 1 has the red color and Trace 2 has a green color. The places L0, L1, L2 and L3 belong to all traces. L4, L5, L6 and L7 belong to Trace 2. Now it is simple to extract a HLSD from the above CPN. The HLSD extracted is shown in Fig 5. Our approach, as shown in this example, is able to generate a comprehensive HLSD with the main UML2 operators (seq, alt, par, and loop). This gives developers and maintainers studying the system an efficient way to visualize the sequence of messages between objects during an interaction in order to understand the system behavior. The hypothesis that we use to detect the "loop" operator is based on the presence of a repetition of the line trace in the same execution traces (same scenario). It is important to note that this hypothesis is not always true. For the moment, it is accepted as a heuristic. Our approach is also independent from programming languages. The tracer tool can be changed to support any object-oriented programming language.
Fig 5. The extracted HLSD
332 10
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
As we can see in Fig. 5, our approach does not allow the extraction of the conditions in the operators alt and loop. This comes from the fact that our format for traces does not contain any information about the conditions. This can be remedied in two ways. Either by modifying the form that we have chosen for the traces in order to add information about structure control or by adding a new step of which a static analysis is performed. 6. Conclusion In this paper, we presented an overview on our approach, which enables the reverse engineering of sequence diagrams of an object-oriented software system. Our approach uses a colored petri nets to deal with the problem of the execution trace analysis. In addition, our approach filter traces in order to concentrate on the main behavior of the system. The approach detects UML interaction operators such as alt, seq and loop. It also enables the detection of the interaction operator par, which helps to describe the behavior of each single thread running in the system. As future works, we will evaluate our approach on more complex systems. We will study the possibility of changing the trace format in order to add structure control information. This is very important to have a more accurate UML sequence diagram. We will also try to handle the problem of extracting state diagrams and activity diagrams of UML2. Acknowledgements We would like to thank the FST Errachidia for providing us with assist us in the development part of our research. Our sincere thanks also go to Moulay Ismail University for its financial support of the project "Algorithmic and software support for transformational approaches to UML" References [1] B. Cornelissen, A. Zaidman, et A. Deursen. (2011) “A Controlled Experiment for Program Comprehension through Trace Visualization.” IEEE Trans. on Software Engineering: 1-2. [2] OMG. (2007) Unified Modeling Language (OMG UML), Superstructure. V2.1.2. [3] E. J. Chikofsky and J. H. Cross, II. (1990) “Reverse Engineering and Design Recovery: A Taxonomy.” IEEE Software7 (1):13-17 [4] P. Tonella, A. Potrich. (2003) “Reverse engineering of the interaction diagrams from C++ code.” Conf. Software Maintenance: 159-168. [5] M. L´opez, A. Alfonzo, J. P´erez, J.G. Gonz´alez, and A. Montes. “AMetamodel to Carry Out Reverse Engineering of C++ Code into UML Sequence Diagrams.” (2006) In Proceedings of the Conference on Electronics, Robotics and Automotiv Mechanics . IEEE Computer Society: 331-336. [6] A.Rountev, O. Volgin, and M. Reddoch (2005) “Static Control-Flow Analysis for Reverse Engineering of UML Sequence Diagrams.” In ACM SIGSOFT Software Engineering Notes, ACM31 (1):96-102. [7] A. Rountev and B.H. Connell. (2005) “Object Naming Analysis for Reverse-Engineered Sequence Diagrams.” In Proceedings of the 27th International Conference on Software Engineering (ICSE’05), ACM: 254-263. [8] Taniguchi, T. Ishio, T. Kamiya, S. Kusumoto, et K. Inoue. (2005) “Extracting Sequence Diagram from Execution Trace of Java Program.” International Workshop on Principles of Software Evolution (IWPSE’2005):148-151. [9] Romain Delamare, Benoit Baudry, Yves Le Traon. (2006) “Reverse-engineering of UML 2.0 Sequence Diagrams from Execution Traces.” .In Proceedings of the workshop on Object-Oriented Reengineering, ECOOP 06:1-10. [10] Tewfik Ziadi, Marcos Aur´elio Almeida da Silva, Lom Messan Hillah, Mikal Ziane. (2011) “A Fully Dynamic Approach to the Reverse Engineering of UML Sequence Diagrams.” 16th IEEE International Conference on Engineering of Complex Computer Systems, ICECCS: 1-14. [11] B. Cornelissen, A. van Deursen, L. Moonen, and A. Zaidman. (2007) “Visualizing Test suites to Aid in Software Understanding,” In Proceedings of the 11th European Conference on Software Maintenance and Reengineering (CSMR’07), IEEE Computer Society: 213-222. [12] K. Jensen, “A brief introduction to coloured Petri nets.” (1997) in Proceeding of the Tools and Algorithms for the Construction and Analysis of Systems (TACAS’97) Workshop, LNCS, Springer-Verlag12 (17): 203–208. [13] A. Jakimi, A. Sabraoui, E. Badidi, A. Salah and M. El Koutbi. (2010) “Using Uml Scenarios in B2b Systems.” IIUM Engineering Journal: 112. [14] Mohammed Elkoutbi, Ismaıl Khriss, and Rudolf Keller. (2006) “Automated prototyping of user interfaces based on uml scenarios.” Automated Software Engineering13 (1): 5–40. [15] Y.-G. Guéhéneuc et T. Ziadi. (2005) “Automated reverse-engineering of UML v2. 0 dynamic models.” in proceedings of the 6th ECOOP Workshop on Object-Oriented Reengineering: 1-10. [16] L. C. Briand, Y. Labiche, J. Leduc. (2006) “Towards the Reverse Engineering of UML Sequence Diagrams for Distributed Java Software.” IEEE Transactions on Software Engineering32 (9):642-663. [17] Ka-Yee Ng, (2007) “Identification of Behavioral and Creational Design Patterns through Dynamic Analysis.” in Proceedings of the 3rd International Workshop on Program Comprehension through Dynamic Analysis (PCODA):34-42.
ScienceDirect ScienceDirect
Procedia online Computer 00 (2019) 000–000 Available at Science www.sciencedirect.com Procedia Computer Science 00 (2019) 000–000
ScienceDirect
www.elsevier.com/locate/procedia www.elsevier.com/locate/procedia
Procedia Computer Science 148 (2019) 323–332
Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018) Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018)
A New Approach for Recovering High-Level Sequence Diagrams A Newfrom Approach for Recovering High-Level Sequence Diagrams Object-Oriented Applications Using Petri Nets from Object-Oriented Applicationsa Using Petri Nets a a Chafik BAIDADA *, El Mahi BOUZIANE , Abdeslam JAKIMI Chafik BAIDADAa*, El Mahi BOUZIANEa, Abdeslam JAKIMIa a a
Software Engineering & Information Systems Engineering Team, Faculty of Sciences and Technics, Errachidia, MoroccoTeam, Faculty of Sciences and Technics, Software Engineering & Information Systems Engineering Errachidia, Morocco
Abstract Abstract Software development starts with sound documentation and design, but during the course of time, design document or other software are neither nor well maintained.and It is design, very essential to understand theofexisting systemdocument to maintain to Software artifacts development startsupdated with sound documentation but during the course time, design orand other evolve it artifacts with neware requirements. To better understand theseIt legacy need to extract dynamicsystem behavior and represent it software neither updated nor well maintained. is verysystems, essentialwe to understand the existing to maintain and to graphically in new models. Reverse engineering UML sequence diagrams is a very way todynamic understand the behavior of these evolve it with requirements. To better understand these legacy systems, we efficient need to extract behavior and represent it systems. Most approaches dealing with this subject, in addition to rarely way to filter code information, theyofdo not graphically in models. Reverse engineering UML sequence diagrams is offer a verya efficient waysource to understand the behavior these cover all Most UML approaches control operators thesubject, operatorin"par" which veryoffer important context ofcode parallelism. In thisthey paper, we systems. dealingsuch withasthis addition to is rarely a wayintothe filter source information, do not propose newcontrol approach to extract UML2 sequence diagrams multiple execution traces. This approach of cover all aUML operators such as the operator "par" which isfrom very important in the context of parallelism. In thisconsists paper, we generating of different use cases, analyzing them This using approach Colored Petri Nets of to propose a and newcollecting approachthe to corresponding extract UML2traces sequence diagrams from filtering multipleand execution traces. consists finally extract high-levelthe sequence diagram.traces of different use cases, filtering and analyzing them using Colored Petri Nets to generating andacollecting corresponding finally extract a high-level sequence diagram. © 2019 The Authors. Published by Elsevier B.V. © 2019 The Authors. by Elsevier B.V. This is an open accessPublished article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/) © 2019 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) Peer-review under responsibility of the the CC scientific committee of (http://creativecommons.org/licenses/by-nc-nd/3.0/) the Second International Conference on Intelligent Computing in This is an open access article under BY-NC-ND license Peer-review under responsibility of the scientific committee of the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). Peer-review under responsibility of the scientific committee of the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). Data Sciences (ICDS 2018). Keywords: reverse engineering; UML sequence diagrams; Petri nets; dynamic analysis. Keywords: reverse engineering; UML sequence diagrams; Petri nets; dynamic analysis.
1. Introduction 1. Introduction The understanding of legacy systems is an essential part of maintenance, reuse, validation and other activities of The understanding legacy systems an essential of of maintenance, reuse,isvalidation andunderstanding other activities of software engineering. of According to someis studies, up topart 60% the maintenance devoted to their softwarecode engineering. According to some studies, up to 60%and of techniques the maintenance is devoted understanding their source [1]. Therefore, it is important to develop tools that facilitate the to task of understanding source code [1]. Therefore, it is important to develop tools and techniques that facilitate the task of understanding
* Corresponding author. Tel.: +212619598527. E-mail address:[email protected] * Corresponding author. Tel.: +212619598527. E-mail address:[email protected] 1877-0509 © 2019 The Authors. Published by Elsevier B.V. This is an open access under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/) 1877-0509 © 2019 Thearticle Authors. Published by Elsevier B.V. Peer-review underaccess responsibility of the scientific committee oflicense the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). This is an open article under the CC BY-NC-ND (http://creativecommons.org/licenses/by-nc-nd/3.0/) Peer-review under responsibility of the scientific committee of the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). 1877-0509 © 2019 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0/) Peer-review under responsibility of the scientific committee of the Second International Conference on Intelligent Computing in Data Sciences (ICDS 2018). 10.1016/j.procs.2019.01.040
324 2
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
such systems because the documentation is often absent, outdated or incomplete. An effective comprehension technique to understand these systems is reverse engineering. Reverse engineering consists of retrieving models from a program in order to understand its structure and behavior. In the object-oriented world, the target modeling language most used for reverse engineering is UML (Unified Modeling Language) [2] due to its significant presence in the industry. The reverse engineering of UML static diagram has been studied and is now implemented in several tools. Static diagrams help engineers to understand the structure of systems, but they do not allow understanding its behavior. To do this, dynamic models are needed, such as sequence diagrams or state machine diagrams. This paper presents the results of our first investigation in reverse engineering for extracting UML sequence diagrams from the source code of legacy systems. The rest of this paper is organized as follows: Section 2 outlines some related work in terms of existing approaches. Section 3 introduces a background in reverse engineering of UML2 sequence diagrams using Colored Petri Nets (CPN). Section 4 describes our approach. A case study is presented in Section 5. Finally, section 6 concludes our work and give directions for future research. 2. RELATED WORK In this section, we present an overview of existing work in reverse engineering of sequence diagrams. Chikofsky and Cross [3] define reverse engineering as the process for identifying and analysis of software system components, their interrelationships and the representation of their entities at a higher level of abstraction. Reverse engineering by itself involves only analysis; it does not involve changing the subject system or not create any new system. Recently, many works have been done on the reverse engineering of sequence diagrams. We distinguish two categories of existing approaches: static and dynamic. Static analysis is to use the code structure to generate the sequence diagrams. Various approaches have been developed to capture a system’s behavior through static analysis [4, 5, 6, 7]. One of the main of them is that of Rountev et al. [7]. They proposed an approach for the extraction of UML sequence diagrams from the source code of a system through building control flow graphs. In this study, the nodes represent the basic blocks of a program and the links represent all kinds of interactions between these blocks. The dynamic analysis, on the other hand, is to analyze a software system under execution. As such, runtime objects can be detected, thus making it possible to expose occurrences of polymorphism and late binding in contrast to static analysis. The produced execution traces contain very detailed information on how a system operates. Several studies have tried to generate sequence diagrams by analyzing the execution traces. Taniguchi et al. [8] propose an automatic approach for the reverse engineering of sequence diagrams from the execution traces of an object-oriented program. They present these traces in the form of a tree where each node represents a method call. They present four compaction rules, including compaction of repetitions and compaction of recursive calls, in order for the traces to be reduced in size, thereby producing compact sequence diagrams. In [9], they try to build a highlevel sequence diagram from combined fragments using the state vector describing the system. The approach presented consists of two phases. During the first phase, a simple sequence diagram is generated containing just the method calls. The second phase makes it possible to draw high-level sequence diagrams by combining the diagrams generated in the first step. This is done by analyzing the different states of the system. In [10], it proposes an approach based on dynamic analysis. The authors use LTS (Labeled Transition System) for modeling execution traces. Then they generate a high-level sequence diagram from this LTS. These approaches have succeeded in generating representative sequence diagrams. However, they recognize some limitations. Since our approach is based on dynamic analysis, we focus on comparing it with approaches that use execution traces to extract sequence diagram. Differences between these approaches are summarized in Table1. Though not exhaustive, this table does illustrate the differences relevant to our work. The strategies reported in Table 1 [8, 9, 10] are compared according to five criteria: - Multiple execution trace: The behavior of a system is often described by multiple execution traces that correspond to different scenarios. - Use of filtering technics: As mentioned in [11] Cornelissen et al. defines several filtering technics in the context of trace execution collection. For example, traces corresponding to simple getters and setters methods are not generated. The approaches mentioned above do not use like this filtering technics. Thus, the resulting execution traces contains a lot of useless information. - Programming language: This to show how many languages the approach support.
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./Procedia Computer Science 00 (2019) 000–000
325 3
- UML2 Combined fragment Supported: which operators can the approach extracts by analyzing the execution traces? - Thread information: if the approach provides information to detect the threads execution. Table 1. Related work for dynamic analysis Multiple execution Programming language traces
UML2 Combined fragment Supported
Thread information
Use filtering technics
[8]
No
Java
No
No
Yes
[9]
No
Java
seq, alt, loop
No
No
[10]
Yes
All POO languages
seq, alt, loop
No
Yes
As mentioned in table 1, none of the approaches covers all the above criteria. That is why; we propose to revisit the problem of the reverse engineering of UML sequence diagrams by a new approach. Our approach uses the dynamic analysis to build UML2 sequence diagrams with a consideration of all the criteria mentioned before.
3. UML2 AND COLORED PETRI NETS In this section, we discuss the dynamic reverse engineering of High-level Sequence Diagrams (HLSD) from multiple execution traces and we give some definitions that help us to explain clearly our approach. 3.1. UML2 sequence diagrams Sequence diagrams are the more commonly used diagram for capturing inter-object behavior. Sequence diagrams are typically associated with use case realizations in the logical view of the system under development. Sequence Diagrams (SD) have been significantly changed in UML 2.0 [2]. A (HLSD) is a sequence diagram that refers to a set of Basic Sequence Diagram (BSD) and composes them using a set of interaction operators. The main operators are: seq for sequence, alt for alternatives, loop for iterative actions, and par for parallelism. 3.2. Execution Traces To build HLSD diagrams using dynamic analyses, we have to generate traces of program executions describing the behavior of each thread of a program. Each trace corresponds to a scenario of a given use case. In what follows, we introduce a set of definitions relatives to execution traces, which are necessary to understand the approach. Definition 1: A trace line is a triplet T =
and only if: - Two objects are equivalent if they are instances of the same class and are created in the same thread (using the constructor Invocation) with the same values of parameters. - The messages message1 and message2 concern the same method and have the same signature.
326 4
-
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
The receivers reciver1 and receiver2 are two equivalent objects.
3.3. Colored Petri networks Petri nets [12] are a well-known and developed formalism with a rich theory, practical applications ranging from communication networks to healthcare systems and are supported by a wide range of commercial and noncommercial tools. Colored Petri nets (CPNs) are a backward compatible extension of Petri nets. CPNs preserve useful properties of Petri nets and at the same time extend the initial formalism to allow the distinction between tokens. CPNs allow tokens to have a data value attached to them. This attached data value is called token color.
Fig 1. A HLSD mapped onto CPN with operators loop and alt
From the many existing variants of Petri nets, CPNs are used in composing and integrating scenarios that are represented in the form of sequence diagrams [13, 14]. Four operators for composing scenarios have been implemented: sequential, conditional, iterative and concurrent. CPNs suit our approach as they can map a HLSD efficiently. Places represent BSD and transitions represent operators such as alt, loop, seq, and par. Colors are used to distinguish between places. All places from the same trace have the same color. That is very helpful to distinguish between scenarios in a HLSD. Fig. 1 shows how a HLSD can be mapped easily into a CPN. P1 represents the BSD which describes that the object a of the class A sends the message m1 to the object b of the class B. P2 represents the BSD which describes that the object b sends the message m2 to the object a. P3 represents the BSD which describes that the object b sends the message m3 to the object a. T1 represents the operator alt with the condition C2. T2 represents the operator alt with the condition C3. T3 represents the operator loop with the condition C1.The operators par and seq can be mapped also as it is shown in Fig. 2. In Fig. 2, P1 represents the BSD which describes that the object a sends the message m1 to the object b. P2 represents the BSD which describes that the object b sends the message m2 to the object a. P3 represents the BSD which describes that the object a sends the message m3 to the object b. P4 represents the BSD which describes that the object a sends the message m4 to the object b. T1 represents the operator seq. T2 represents the operator par. From what precedes, we can conclude that, for a HLSD, we can generate a CPN that can represent all major UML sequence diagram operators.
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./Procedia Computer Science 00 (2019) 000–000
327 5
Fig. 2. A HLSD mapped onto CPN with operators par and seq.
In this section, we discussed the reverse engineering of sequence diagram and gave definitions that are necessary for better comprehension of our approach. The problem that arises is how we can reverse this process. I.e.: how, from execution traces, can we generate a CPN that can be mapped onto a HLSD? (1) 4. 4. Approach overview The proposed approach for reverse engineering of UML sequence diagrams is illustrated in Fig. 3. Our work is inspired by [15]. The approach is defined in five main steps: (i) System analysis, (ii) Trace generation, (iii) Trace collection and filtering, (iv) Abstraction building and (v) HLSD extraction. In the following subsections, each step is detailed. Consulting functional expert
User interface analysis
Specification documents …etc.
System entry values identification
Real world systems
6\VWHP $QDO\VLV
7UDFHV JHQHUDWLRQ
+/6'([WUDFWLRQ
7UDFHV &ROOHFWLRQ)LOWHULQJ
$EVWUDFWLRQ %XLOGLQJ
CPNs Extraction CPNs Integration
Fig 3. Approach overview
4.1. System Analysis In the System analysis activity, the analyst tries to analyze and understanding the system. The objective is to identify the system entry values corresponding to different scenarios describing the system behavior. For this, the system must be run several times (one execution for each possible scenario). Indeed, one execution session is not enough to have the general behavior of the system. However running the system to cover all possible entries of the system is
328 6
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
not always possible because the range of data values is often infinite. To avoid this, the analyst must identify relevant system entries to cover all possible system functionalities. To do this, the analyst has three possibilities. He can consult a functional expert who knows the different input values of the system. He can use the available system documentation. Finally, he can analyze the user interfaces to deduce how the system works. 4.2. Trace generation To extract HLSD diagrams from an oriented-object program, we concentrate on reverse engineering relying on dynamic analysis. As mentioned in [16], dynamic analysis is more suited to the reverse engineering of sequence diagrams of object-oriented systems because of inheritance, polymorphism and dynamic binding. This dynamic analysis is usually performed using execution traces. There are multiple ways to generate execution traces [1]. We choose to use bytes code instrumentation. In some legacy systems, the source code may not be available. Among several trace collection tools for Java software systems, we chose MoDec [17]. This one provides a very interesting option where the user can choose among the classes of the system those he wants to follow and instrument. This is very helpful in the next step. 4.3. Trace collection and filtering The system behavior is related to the environment entry data, in particular, values introduced by the user to initialize specific system variables. Thus, one execution session is not enough to identify all system behaviors. Therefore, we chose to run the system several times to generate different execution traces. Each execution trace corresponds to a particular scenario of a given use case of the system. Using MoDec, a filtering process is applied to the system when it is running. This process is based on two filtering rules: distinction between domain classes and implementation specific classes or the exclusion of certain packages. No lines that contain a package that is not interesting will appear in traces. For example, all objects on the package relatives of the GUI of the system such as Swing for Java can be ignored. This process enables us to concentrate on the main behavior of the system. We developed an adapter in order to restructure the output trace in the form as defined in definitions 1 and 2 and therefore appropriate to the processing of the diagram construction stage. 4.4. Abstraction building The abstraction building activity consists of deriving CPN from the acquired traces. CPNs corresponding to the same use case (scenarios) are iteratively merged to obtain an integrated CPN of the use case. The color aspect of CPNs is used to keep track of input scenarios in the resulting Abstraction. The algorithm CPN_IncrementalExtraction (see below) describes the process of this step. It takes several execution traces as input and generate incrementally a CPN that represents the system behavior. First, the algorithm scans the execution traces line by line. Each line is analyzed if it is a new one, a new place is created. All places that represent lines of a trace have the same color. These colors allow us to distinguish between the scenarios as a trace represents the execution of a scenario. This gives the possibility of subdividing an HLSD into several HLSDs to facilitate the task of understanding the system. The algorithm also creates transitions. It associates for each place the corresponding transition by analyzing previous and current lines. The algorithm focuses on the ID of threads to distinguish between threads. If the lines belong to the same thread, the operators seq and alt can be identified easily by simple comparison between previous and current lines in different traces. The operator par is detected by analyzing the main thread and his sub-threads. The transition corresponding to the current line is marked temporarily “loop” if it already exists and belongs to the same trace (same scenario).The final operator loop is obtained if a transition is already marked as a loop.
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./Procedia Computer Science 00 (2019) 000–000
329 7
CPN_IncrementalExtraction(IN trace trace_set) Place N_place ; Color N_color ; CPN N_cpn ; For each trace T in trace_set /* a CPN COLOR is created for each trace*/ N_color = createNewCPNColor()); For each line l in T N_place =creatPlaceWithColor(l,N_c) ; If (isCPNImpty()) Add_Place_To_CPN(N_place); else If(isNotNew(l)) if ( isInSameTrace(l))/* the same line in the same trace*/ if(isLoopMarked(N_cpn)) change_pervious_Transition(“loop”,N_cpn) ; else maark_pervious_Transition(“loop”,N_cpn) ; Endif else If(isTheSamethread()) if (previous_place_haveTransition(N_cpn)) /* change all transition of previuos place to “alt”*/ change_Transition_To_CPN(“alt”, N_cpn ) ; Add_Place_To_CPN(N_place, N_cpn ) ; else Add_Place_To_CPN(N_place, N_cpn ) ; Add_Transition_To_CPN(“seq”, N_cpn ) ; ENdif /*if the ID of the previous thread is the main thread */ else If ( is_previous_MainThreadID()) Add_Transition_To_CPN(“par”, N_cpn ) ; /*add place to the previous transition par*/ Add_Place_To_CPN(N_place, N_cpn ) ; else /*no need to add transition it already exists*/ Add_Place_To_CPN(N_place, N_cpn ) ; ENdif EndIf Endif Endif EndForeach EndForeach END CPN_IncrementalExtraction
4.5. HLSD extraction In this step, we can easily build HLSD by mapping the resulting CPN using transformation rules as is it shown in Fig. 1 and Fig. 2. 5. Case study In this section, we chose the example of a calculate application. The application takes a complex calculation to be resolved as input. The application makes an estimate of the complexity of the calculation. If it is quite simple, the main thread of the system makes it (Scenario 1), otherwise the calculation is divided into two parts where each one is solved by a different thread (Scenario 2). After the result is sent to the main thread which displays the final result for the user (Scenario 1 and Scenario 2). Here is the source code of the application. It includes four classes: MainThread.java, ClientObject.java, ThObject2.java, ThObject1.java, and Calculator.java. In listing Listing 1 and Listing 2, the class MainThread.java and ClientObject.java are given.
330 8
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
Listing 1: MainThread.java
package pack1; import java.util.Scanner; public class MainThread { private ClientObject clientObj; private ThObject1 ThObj1; private ThObject2 ThObj2; private int [] terms; public void display() { System.out.println("enter the number of terms of the multiplication "); Scanner sc = new Scanner(System.in); int numberTerms = sc.nextInt(); clientObj= new ClientObject(this); terms= new int[numberTerms]; for (int i = 0; i < numberTerms; i++) { System.out.print("enter the number: "+i+" "); terms[i]= sc.nextInt();} clientObj.giveCompute(terms); } public int getRestult(){ int res=1; for (int i = 0; i < terms.length; i++) { res=res*terms[i];} return res; } public int getRestultTh(){ return ThObj1.getResult1()* ThObj2.getResult2(); } public void orderCompute(){ ThObj1 = new ThObject1(this.terms);ThObj1.start(); synchronized(ThObj1){ try{ System.out.println("Waiting for thread 1 ThObj1.wait();}catch(InterruptedException e){ e.printStackTrace();} ThObj2 = new ThObject2(this.terms); ThObj2.start(); synchronized(ThObj2){try{ System.out.println("Waiting for thread 2 ThObj2.wait();}catch(InterruptedException e){ e.printStackTrace(); }} }} }
..."); ...");
Listing 2: ClientObject.java
package pack1; public class ClientObject { public void giveCompute(int []n) {terms=n; } public void estimate() {if(terms.length >10 ){ MainTh.orderCompute(); System.out.println(MainTh.getRestultTh()); } else System.out.println( MainTh.getRestult()); } public ClientObject(MainThread M){MainTh=M; } private MainThread MainTh; int [] terms;}
After the instrumentation of bytes code by MoDec and the execution of the instrumented program, a trace file is generated. This file contains all the events of construction and destruction of the objects of the instrumented classes. The invocation and return events of its invoked methods are also recorded. To organize the execution log files according to the form proposed by our approach, we use the adapter that we developed for this purpose. The final execution traces generated as illustrated in Table 2 can provide different types of behavioral interactions. Table 2: Generated traces of the system Trace 1(Scenario 1) L0. 0:pack1:MainThread:MainTh |display() | pack1:ClientOject:ClientObj L1. 0:pack1:ClientOject:ClientObj|giveCalcul(int[] n ) |pack1:MainThread:MainTh L2. 0:pack1:MainThread:MainTh |estimate() |pack1:MainThread:MainTh L3. 0:pack1:MainThread:MainTh |getResult() |pack1:ClientOject:ClientObj L0. 0:pack1:MainThread:MainTh |display() |pack1:ClientOject:ClientObj Trace 2 (scenario 2) L0. 0:pack1:MainThread:MainTh |display() |pack1:ClientOject:ClientObj L1. 0:pack1:ClientOject:ClientObj |giveCalcul(int[] n) |pack1:MainThread:MainTh L2. 0:pack1:MainThread:MainTh |estimate() |pack1:MainThread:MainTh L4. 0:pack1:MainThread:MainTh |order() |pack:ThObectj1:ThObj1 L5. 0:pack1:MainThread:MainTh |order() |pack:ThObectj2:ThObj2 L6. 1:pack1:ThObectj1:ThObj1 |getResult1() |pack1:MainThread:MainTh L7. 2:pack1:ThObectj2:ThObj2 |getResult2() |pack1:MainThread:MainTh L3. 0:pack1:MainThread:MainTh |getResultTh() |pack1:ClientOject:ClientObj L0. 0:pack1:MainThread:MainTh |display() |pack1:ClientOject:ClientObj
Scenario 1
Scenario 2
Table 2 shows that each trace refers to a scenario for a use case of the application: Trace 1 corresponds to Scenario 1 when the given calculation is easy. The main thread does the calculus and show the result for the user.
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./Procedia Computer Science 00 (2019) 000–000
331 9
In Trace 2, the scenario is when the calculation is complex. One part of the calculation is given to the thread ThObj1 and the other to the thread ThObj2. The first thread gives to the main thread the result before the second thread. When the two threads have finished, the application display the result to the user and ask him to give new calculation (Scenario 2). After applying our algorithm to these traces, the CPN below is obtained (Fig 4).
Fig 4. The extracted CPN.
Fig. 4 shows the CPN extracted has 8 places and 8 transitions. Each place refers to a BSD and each transition corresponds to an operator. The places of the CPN contain colors. These colors are used to differentiate places of a trace from another. In this CPN, Trace 1 has the red color and Trace 2 has a green color. The places L0, L1, L2 and L3 belong to all traces. L4, L5, L6 and L7 belong to Trace 2. Now it is simple to extract a HLSD from the above CPN. The HLSD extracted is shown in Fig 5. Our approach, as shown in this example, is able to generate a comprehensive HLSD with the main UML2 operators (seq, alt, par, and loop). This gives developers and maintainers studying the system an efficient way to visualize the sequence of messages between objects during an interaction in order to understand the system behavior. The hypothesis that we use to detect the "loop" operator is based on the presence of a repetition of the line trace in the same execution traces (same scenario). It is important to note that this hypothesis is not always true. For the moment, it is accepted as a heuristic. Our approach is also independent from programming languages. The tracer tool can be changed to support any object-oriented programming language.
Fig 5. The extracted HLSD
332 10
Chafik BAIDADA et al. / Procedia Computer Science 148 (2019) 323–332 Chafik B. , El Mahi B. and Abdeslam J./ Procedia Computer Science 00 (2019) 000–000
As we can see in Fig. 5, our approach does not allow the extraction of the conditions in the operators alt and loop. This comes from the fact that our format for traces does not contain any information about the conditions. This can be remedied in two ways. Either by modifying the form that we have chosen for the traces in order to add information about structure control or by adding a new step of which a static analysis is performed. 6. Conclusion In this paper, we presented an overview on our approach, which enables the reverse engineering of sequence diagrams of an object-oriented software system. Our approach uses a colored petri nets to deal with the problem of the execution trace analysis. In addition, our approach filter traces in order to concentrate on the main behavior of the system. The approach detects UML interaction operators such as alt, seq and loop. It also enables the detection of the interaction operator par, which helps to describe the behavior of each single thread running in the system. As future works, we will evaluate our approach on more complex systems. We will study the possibility of changing the trace format in order to add structure control information. This is very important to have a more accurate UML sequence diagram. We will also try to handle the problem of extracting state diagrams and activity diagrams of UML2. Acknowledgements We would like to thank the FST Errachidia for providing us with assist us in the development part of our research. Our sincere thanks also go to Moulay Ismail University for its financial support of the project "Algorithmic and software support for transformational approaches to UML" References [1] B. Cornelissen, A. Zaidman, et A. Deursen. (2011) “A Controlled Experiment for Program Comprehension through Trace Visualization.” IEEE Trans. on Software Engineering: 1-2. [2] OMG. (2007) Unified Modeling Language (OMG UML), Superstructure. V2.1.2. [3] E. J. Chikofsky and J. H. Cross, II. (1990) “Reverse Engineering and Design Recovery: A Taxonomy.” IEEE Software7 (1):13-17 [4] P. Tonella, A. Potrich. (2003) “Reverse engineering of the interaction diagrams from C++ code.” Conf. Software Maintenance: 159-168. [5] M. L´opez, A. Alfonzo, J. P´erez, J.G. Gonz´alez, and A. Montes. “AMetamodel to Carry Out Reverse Engineering of C++ Code into UML Sequence Diagrams.” (2006) In Proceedings of the Conference on Electronics, Robotics and Automotiv Mechanics . IEEE Computer Society: 331-336. [6] A.Rountev, O. Volgin, and M. Reddoch (2005) “Static Control-Flow Analysis for Reverse Engineering of UML Sequence Diagrams.” In ACM SIGSOFT Software Engineering Notes, ACM31 (1):96-102. [7] A. Rountev and B.H. Connell. (2005) “Object Naming Analysis for Reverse-Engineered Sequence Diagrams.” In Proceedings of the 27th International Conference on Software Engineering (ICSE’05), ACM: 254-263. [8] Taniguchi, T. Ishio, T. Kamiya, S. Kusumoto, et K. Inoue. (2005) “Extracting Sequence Diagram from Execution Trace of Java Program.” International Workshop on Principles of Software Evolution (IWPSE’2005):148-151. [9] Romain Delamare, Benoit Baudry, Yves Le Traon. (2006) “Reverse-engineering of UML 2.0 Sequence Diagrams from Execution Traces.” .In Proceedings of the workshop on Object-Oriented Reengineering, ECOOP 06:1-10. [10] Tewfik Ziadi, Marcos Aur´elio Almeida da Silva, Lom Messan Hillah, Mikal Ziane. (2011) “A Fully Dynamic Approach to the Reverse Engineering of UML Sequence Diagrams.” 16th IEEE International Conference on Engineering of Complex Computer Systems, ICECCS: 1-14. [11] B. Cornelissen, A. van Deursen, L. Moonen, and A. Zaidman. (2007) “Visualizing Test suites to Aid in Software Understanding,” In Proceedings of the 11th European Conference on Software Maintenance and Reengineering (CSMR’07), IEEE Computer Society: 213-222. [12] K. Jensen, “A brief introduction to coloured Petri nets.” (1997) in Proceeding of the Tools and Algorithms for the Construction and Analysis of Systems (TACAS’97) Workshop, LNCS, Springer-Verlag12 (17): 203–208. [13] A. Jakimi, A. Sabraoui, E. Badidi, A. Salah and M. El Koutbi. (2010) “Using Uml Scenarios in B2b Systems.” IIUM Engineering Journal: 112. [14] Mohammed Elkoutbi, Ismaıl Khriss, and Rudolf Keller. (2006) “Automated prototyping of user interfaces based on uml scenarios.” Automated Software Engineering13 (1): 5–40. [15] Y.-G. Guéhéneuc et T. Ziadi. (2005) “Automated reverse-engineering of UML v2. 0 dynamic models.” in proceedings of the 6th ECOOP Workshop on Object-Oriented Reengineering: 1-10. [16] L. C. Briand, Y. Labiche, J. Leduc. (2006) “Towards the Reverse Engineering of UML Sequence Diagrams for Distributed Java Software.” IEEE Transactions on Software Engineering32 (9):642-663. [17] Ka-Yee Ng, (2007) “Identification of Behavioral and Creational Design Patterns through Dynamic Analysis.” in Proceedings of the 3rd International Workshop on Program Comprehension through Dynamic Analysis (PCODA):34-42.