-Though UML is rather commonly used for modelling various software systems, if not properly maintained, UML models could lose their practical value. Fixing the mismatch between documentation and the current state of software, requires significant effort from development team. This also applies to systems that have no documentation at all or legacy systems, which documentation is not available. Reverse engineering can be used for generating UML diagrams for existing systems. In this paper we present a method for reverse engineering UML Use Case model from websites. This method enables generating UML Use Case and Activity diagrams from the recorded user activity in the website.
Unified Modelling Language (UML) is rather commonly
used for modelling various software systems [
Websites more than any other type of software demand
constant updates and fixes to meet changing user demand and
to beat harsh competition [
Reverse engineering is the process of analyzing a system to
identify its structure and behavior in order to create its visual
representation [
Reverse engineering can also be used for generating UML
diagrams [
The rest of the paper is organized as follows. The second section presents related work in the field of reverse engineering UML diagrams. The third section is dedicated to describing our proposed method for generating UML diagrams from registered user actions. Section four describes the prototype developed for our proposed method. The fifth section presents the results of evaluation of the prototype by applying it for a particular website. The last section summarizes the findings of our research and discusses the future work.
Reverse engineering of UML models is rather common in
the field of software engineering. Reverse engineering can
greatly reduce the effort required to construct UML diagrams.
UML diagrams can be divided into two categories, one
describes structure of the software system, and the other defines
its behavior [
Structural UML diagrams can be reverse engineered from
code or other static structure. Class diagrams can be easily
transformed from static code [
On the other hand, reverse engineering of behavioral
diagrams, like Use Case and Activity diagrams, is not so
commonly implemented and used. Nevertheless, there have
been significant effort to create a working method for reverse
engineering of UML behavioral diagrams [
El-Attar and Miller proposed a method to reverse engineer
Use Case models from structured Use Case descriptions [
Another method for reverse engineering UML diagrams has
been proposed by Muhairat [
Much can be learned not only form reverse engineering Use
Case diagrams, but also from reverse engineering other
behavioral diagrams. An excellent example of reverse
engineering behavioral diagrams is presented in research by
Ziadi, da Silva, Hillah, and Ziane [
Di Lucca, Fasolino and Tramontana proposed a specialized
tool specifically intended for website reverse engineering,
called WARE [
Most of the research conducted in the area of reverse engineering Use Case model is not intended particularly for websites. Our approach focuses on reverse engineering UML behavioral diagrams from websites, specifically from the information recorded during website usage. Our proposal is based on the idea that websites use a common architecture which can be used to extract information about user activities. III. PROPOSED METHOD FOR REVERSE ENGINEERING UML USE
CASE MODEL
As UML Use Case model provides detailed overview of
systems functionality, it is one of the main components of high
quality system documentation [
The proposed method consists of two main steps for reverse engineering UML Use Case model from the selected website (Fig. 1): 1) registering usage of the analyzed system; 2) transforming registration results into XMI file.
During the first phase of reverse engineering UML Use Case model, user opens the system that will be analyzed. He inputs his role in the system and activity that he will be performing. User then continues to use system while his activity is being recorded by reverse engineering system in the background. User can input as many roles and activities as it is required to completely represent his usage of the system. Registering of user actions should be performed by a number of users that is required to cover all functionality of system. After all users register their activities, they should be able to export result files and send them to the system analyst. System analyst then should be able to merge all the result recordings together, into one full structure that represents actions performed in the analyzed system.
The component that will be used for registering system usage should not interfere with system functionality by any way. The recording component should be able to read HTML files that user is interacting with. It should work as a background process that captures user input events, such as clicks and form submits. To describe these events correctly, recording component should also store information about HTML elements that user interacts with. These elements should be uniquely described with an identifying element. Registration component should allow user to define what kind of role he is performing in the system and to define what kind of activity he will be performing. The process of registration consists of initialization and recording steps as can be seen in Fig. 2
Registration results are then provided as an input for the component that transforms user actions into UML Use Case model. This input should be stored in a structure that has elements described in Fig. 3. This structure should store all Website URLs that user interacted with during time of recording. In addition, user should provide the name of the Role, which exists in given Website. Each Role will be performing some kind of Activity. Each Activity should be defined by Webpage that it was performed on and events that were performed in that same Webpage. Each event is described with detailed information about type of Action, and information about HTML element that was in use during that event.
Transformation process is defined in Fig. 4. In order to create a detailed UML model, transformation step should be performed. During this step, registration input is being analyzed for detecting relations between actors and use cases, also between use cases themselves.
Activity diagram defining the transformation (presented in Fig. 4) specifies what actions are required to transform registered results to XMI. The first action removes duplicate actors, to keep the model concise. The second action is required to detect and create generalization relations between actors. The third action performs grouping operations with the registered data. These grouping operations consist of detecting extend and include relations between use cases. The final step takes the results from all relation detection steps and creates XMI file basing on the structure of metamodels of UML Use Case and Activity diagrams.
Generalization relation detection starts by scanning all registered use cases and searching for two or more actors which have matching use cases. Algorithm also checks whether it needs to create a new user, in order to display a generalization correctly. If the user creation is required, the system analyst should be prompted to input actor name for new actor. After these steps, the system creates generalization relations between the actors. As a last step, the system maps all required use cases to required actors. Generalization relation detection step is the only step that changes configuration with actors in the model, so after this step we will have the final number of actors in the model. The activity diagram describing generalization detection process is defined in Fig 5. data that user provides during the recording. The higher amount of recorded data should transform into a model that is more detailed and thus more informative.
To enhance the Use Case model, our proposed approach detects extend relations. All the actions required to detect extend relations are represented in Fig. 6. These extend relations are important in describing alternative scenarios in the model. Extend relation detection starts with checking all recorded action sequences and finding partially repeating actions. From these sequences, the matching parts are extracted, by comparing them to each other. At the beginning and end of the extracted sequence, decision and merge points are created respectively. Afterwards the extracted, remaining and newly created elements are merged together to create the complete activity diagram. For each path that is now separated from the main path of the activity flow by a decision point, a new use case can be created. User provides the names for these use cases and the algorithm creates them in a model. The next step in extension relation detection is creating extension relation between newly created use cases and the use case they originated from. Finally the extension points are created for the use case, which has incoming extend relations.
Detection of use case relations like extend and include, depends on a data set provided by the user of proposed method. Our method does not detect generalization between Use Cases, only include and extend relationship. To detect extend relations, the user of a system should record the same activity on a website twice or more. If these data sets of the same activity will provide exactly the same information, detection would just discard it. Otherwise, if some differences would be found in these data sets, the proposed algorithm can create a more detailed use case model. Success of relation detection depends on an amount of
Fig. 6 The process of detecting extend relations
In order to decrease redundancy in use case model, include relations can be used between use cases. As in our method the amount of recorded data should be quite big, include relations help to reduce the number of repeated actions in the model. Include relation detection starts with finding all repeating action sequences where repeated sequence length is higher than user defined number N. For each sequence found, the algorithm starts use case creation by prompting the user to input a use case name and creating use case element with that name. These found sequences are then removed form use cases where they originated. To finalize, include type relations are created by joining newly created use cases and use cases that the sequences originated from. The process of include relation detection is presented in Fig. 7
During the transformation to XMI step, all the information gathered in previous steps is transformed into Use Case and Activity diagrams. Transformation starts by creating a Use Case diagram. For each role that the user defined, an actor is created. For each activity, that the user defined, the use case is created. Moreover, the use cases that were found during detection of extension and include relationships are added to the model. All use cases and actors are joined using the detected relationship. For each use case, an Activity diagram is created. In this diagram, the algorithm creates two swimlanes, the first one for the actor that is interacting with the given use case, and the second for the system under analysis. For each recorded action our algorithm creates the action in activity diagram. Actions are named referring to the action naming rules, selecting the verb corresponding to the action performed on a HTML element as well as a noun extracted from HTML element attributes. These rules define how each action on HTML element should transform into semantically correct action name. In a systems swimlane, actions are created describing the opening of new webpages. Initial and final activity nodes are also created and all nodes and activities are joined together in a continuous flow.
Results after generation are stored in XMI file. This file
consists of Use Case diagram with elements that are described
by UML Use Case metamodel [
IV. THE IMPLEMENTED PROTOTYPE OF THE PROPOSED METHOD
To test whether the proposed method could be utilized in practice, a prototype has been implemented. Prototype was realized as a Chrome plugin using JavaScript. It enables users to submit information about their role in the website activity they will be performing. As user continues to use the system that is being analyzed, his actions are recorded. Recorded actions are then stored in JSON file. After user indicates that he has ended registration process, he can start transformation process. The system transforms registered JSON structure to Use Case and Activity diagrams. Example of this JSON structure is presented in Fig. 8.
Afterwards this JSON file is transformed into XMI file, which can be imported into MagicDraw CASE tool as a model. This model can later be viewed, analyzed and modified by the analyst.
V. EXAMPLE OF UML DIAGRAMS GENERATED USING THE
IMPLEMENTED PROTOTYPE
An experiment was conducted to verify whether the created prototype is capable of reverse engineering UML Use Case model. Website selected for this experiment was a virtual learning environment Moodle, customized for Kaunas University of Technology. The roles of student and teacher were analyzed.
In order to create Use Case model, student and teacher were asked to perform actions in the analyzed website. Student performed actions for uploading a file into the system. Teacher recorded a process in which he downloaded the students’ submitted assignment. Fig. 9 displays the generated Use Case diagram. For this diagram, users provided two roles but the system identified one additional actor. In total three use cases were detected. The first actor was discovered by generalization relation detection step during registration result transformation. As both of the actors had to log into the system a new user named “Guest” was created. This user, as mentioned before, provides the ability to subtract the amount of excess use cases. For each of these use cases, the algorithm created an activity diagram as expected.
Activity diagram describing Use Case “Login” is presented in Fig. 10. In this diagram we can see that each nonauthenticated user had to click login button styled by CSS class named “btn-login”. After the button is clicked, the system transfers all non-authenticated users to unified authentication system where user fills out login fields and submits the form. To finish login use case, the user clicks Login button and is transferred to the virtual learning environment. The generated Activity diagram demonstrates the prototypes ability to specify common actions, like login and registration.
An example of generated activity diagram for use case “Submit assignments” is displayed in Fig. 11. This diagram displays interactions the user performed and webpages he opened. The diagram describes algorithms’ ability to record actions, and to transform them correctly. The action naming conventions do not convey the performed action information clearly, it heavily depends on the systems configuration. Most of the students’ actions in this use case were navigation through the website. One downside of using just URL changes to describe the opening of new windows in the system, is that it cannot record the opening of a modal window. The algorithms’ ability to detect modal windows should be improved in the future.
The example use case “Download assignment” is described in activity diagram presented in Fig. 12. This activity provides visual feedback, demonstrating that some of the URL naming rules should be improved. On the other hand, this activity still provides enough detail to cover all the most important actions of the use case.
The results of experiment indicate that created prototype is capable of creating UML Use Case model. Both Use Case and Activity diagrams were created describing system usage in great detail. As current prototype is only capable of detecting generalization relations, further iterations of this prototype will only increase the expressivity of generated models. Generation of activity diagrams describing each use case provide even more depth to generated UML Use Case model. As semantic value of these Activity diagrams can still be improved in future releases, generated Activity diagrams still provide enough information about system usage.
Reverse engineering of UML diagrams is utilized in various areas of software engineering. There are many applications of reverse engineering, but most of them are for structural UML diagrams. Behavioral UML diagrams can also be reversed and in our work we have proposed the methodology for reversing UML Use Case model from the data recorded during website usage. Our algorithm analyses recorded user activity and transforms it into UML Use Case and Activity diagrams. The prototype of the proposed algorithm was implemented as a Chrome extension. As this prototype is just the first of its kind, it generates use case and activity diagrams, but is not yet capable of detecting extend and include relations.
The results of experiment indicate that the implemented prototype is capable of generating UML Use Case model. Both Use Case and Activity diagrams were successfully generated using the prototype. The experiment results indicated that our method could be successfully utilized in practice. The experiment also provided valuable feedback about required improvements on action naming rules.
In the future, we are planning to implement the extended capability to support other UML modeling tools. The set of supported tools should include at least one open source tool that is free to use, so that the proposed method could be more accessible to wider audience.