Modifying and maintaining the source code of existing software products take the majority of time in the software development lifecycle. The same problem appears when the software is designed in a modeling environment with UML. Therefore, providing the same toolchain that already exists in the area of source code based development is required for UML modeling as well. This toolchain includes not just editors, but debugging tools, version controlling systems, static analysers and refactoring tools as well. In this paper we introduce a refactoring tool for UML models built within the Papyrus framework. Beside the transformations, the tool is able to measure the complexity of UML models and propose transformations to reduce the complexity.
1:2 We chose our product to be an Eclipse extension due to several decisions. Therefore it can build upon two other extensions: EMF Refactor and Papyrus. Since EMF Refactor is open source we can contribute our improvements when we reach a bigger milestone in this project.
[
Model explorer and GUI editor work synchronously, meaning: - clicking on an element on GUI should select the same element in model explorer, - selecting an element in model explorer should select the same element on GUI, - the appearing context menu should equal for elements in both views.
Modifying the underlying model programatically can cause differences in the separate views that must be handled manually.
[
There are many predefined metrics, refactorings and smells for class diagrams [Arend
The result of the selected metrics appears in a view named Metric Result View. This view does not follow the model changes, in order to have up to date measurements users need to re-run metrics on the changed model. Users can run metrics from the context menu of a selected element: in this case a subset of the selected metrics (based on the type of the selected element) will be evaluated. The result is a list which contains the name and value of the metrics.
New metrics, refactorings and smells can be added using the proper extension points.
It is hard to decide whether the quality of a model is adequate. Although we can estimate the understandibility and maintainability by looking at it, metrics are essential tools of quality measurement. For a UML model, we can define numbers that describe it in details, such as number of elements, number of connections, etc., and have conclusions by examining the connections between them. This may be a very exhaustive process, thus it seems to be a good idea to use a tool for that. The tool we have been developing is an extension of EMF Refactor. By using our tool, the user can use predefined metrics that may contain information about the quality and complexity of a model. Metrics may show us bad design if the number is too large: by defining a threshold, besides detecting smells in the model, we also can eliminate them as they are in connection with specific refactorings, this way we can improve the quality of the model.
This tool also gives us proof that we improved the quality as the predefined metrics may show lower numbers and smells may disappear.
To demonstrate our tool we use the example presented in [Sunye´ et al. 2001]. A phone state diagram was described where the user can start a call by dialing a number, the callee can answer it if not busy and the two participants can talk until hanging up the phone. In the example, we got a flat state machine, therefore after we created the diagram that can be seen on Figure 3, we noticed that its quality can be improved: there are a lot of transitions with the same trigger that all goes into state Idle. This problem can also be detected by using smells. If we select the project and open Properties window, we can set the proper thresholds of smells in EMF Quality Assurance/Smells configuration (Figure 1). A suitable smell is Hot State (Incoming Transitions), that marks those states that have more incoming transitions than the threshold. If we set up the configuration as in Figure 1, then calculate all smells (right click on the model, EMF Quality Assurance/Find Configured Model Smells), it finds Idle as a smelly state (Figure 2). We can eliminate it in two refactoring steps: group the belonging states into a composite one and fold their transitions into a single one. You can see the result of these steps in Figure 4. By eliminating the similar transitions, we have got a simpler, clearer diagram. Moreover, the result can be measured: although the deepness of the state chart has increased, less transitions means less cyclomatic complexity, which is a good approximation for the minimum number of test cases needed.
Refactorings are operations that restructure models as follows: they modify the internal structure of the models, though the functionalities of the models remain the same. Models before and after refactoring are functionally equivalent since solely nonfunctional attributes change.
A fully defined refactoring consists of preconditions, postconditions, main-scenario (changes of the model) and a window for additional parameters.
Many refactorings are provided by EMF Refactor. All of them can be used on class diagrams, e.g. add parameter, create subclass, create superclass, move attribute, move operation, pull up attribute, pull up operation, push down attribute, push down operation, remove empty associated class, remove empty subclass, remove empty superclass, remove parameter, rename class, rename operation and several compositional refactorings. One of our goals was to extend these and visualize them properly.
The existing class diagram refactorings modify only the EMF model, the result is not visible in the Papyrus diagram, therefore our first goal was to add this feature. This involved programmatically creating and deleting views of model elements simultaneously with the EMF model changes. The main aspects were not only to refresh the Papyrus model, but also to support undoing in a way that every change can be reverted in one step. To achieve that, transactions are supported in EMF Refactor which means that it detects the changes during the refactoring process and stores them in a stack, providing an undoable composite command. Unfortunately, EMF and Papyrus changes cannot be made in the same transaction due to multithreading problems, thus we implemented a solution where atomic actions (add, remove) are caught, and we modify the diagram by handling these. We try to keep the consistency of the model and the corresponding diagram.
Since EMF Refactor defines refactorings only for class diagrams, our other goal was to create refactorings for state machines. State machines provide many opportunities to refactor model elements causing small and consistent changes. Most of the refactorings we implemented may be found in [Sunye´ et al. 2001], that contains the pre- and postconditions of all refactorings. In the article, postconditions differ from the ones defined in EMF Refactor, they must be checked after the refactoring process to guarantee that the refactoring made the specific changes.
In order to refactor successfully, our refactorings first check the preconditions, then pop up a window, that contains a short description of the selected refactoring and the input fields for the parameters – some of the refactorings needs additional parameters, e.g. name of the composite state which will be created. After that, it checks the conditions that refer to the parameters, then executes the proper changes. If any of the conditions fails, the execution is aborted and the error list is shown. The added state machine refactorings are: - Group States: it can be used by selecting many states to put them into a composite state instead of moving them and their transitions manually, - Fold Entry Action: to replace a set of incoming actions to an entry action, - Unfold Entry Action: to replace an entry action by a set of actions attached to all incoming transitions, - Fold Exit Action: to replace a set of outgoing actions to an exit action, - Unfold Exit Action: to replace an exit action by a set of actions attached to all outgoing transitions, - Fold Outgoing Transitions: to replace all transitions leaving from the states of a composite to a transition leaving from the composite state, - Unfold Outgoing Transitions: the opposite of the Fold Outgoing Transitions, - Move State into Composite: to move a state into a composite state, - Move State out of Composite: to move a state out of a composite state, - Same Label: copy the effect, trigger and guard of a selected transition.
The refactorings are executed regarding the predefined conditions to keep semantics and they also modify the Papyrus diagram.
We also implemented two new important class diagram refactorings: - Merge Associations: associations of class A may be merged if they are of the same type and they are connected to all subclasses of class B, - Split Associations: the opposite of the Merge Associations refactoring. 1:6
Metrics are able to increase the quality of the system and save development costs as they might find faults earlier in the development process. Metrics return numbers based on the properties of a model from which we may deduce the quality of the model. For example, a state machine with numerous transitions may be hard to understand as the transitions may have many osculations. On the other hand, states embedded in each other, with a deep hierarchy, might also be confusing. According to this, by calculating the metrics we get an other advantage: we can detect model smells, furthermore, some of them can be repaired automatically. We describe this in Section 6.
In EMF Refactor there are many class, model, operation and package metrics defined. Our goal was to create state and state machine metrics. State metrics measure the state and the properties of its transitions, while state machine metrics calculate numbers of the whole state machine. We added 10 state (Table I.) and 16 state machine (Table II.) well-known metrics, all of them measure the complexity of the model. These metrics can be easily calculated as they have simple definitions: they describe the model by the number of items and connections in the model.
Name st entryActivity st exitActivity st NTS st NDEIT
As mentioned earlier, model quality is hard to measure, but with simple heuristics – smells – we can detect poorly designed parts. Moreover, in some cases we can offer solutions to improve them using specific refactorings.
Useful smells consist of a checker part and a modification part. Checker part may contain metrics and conditions: we can define semantics for the values of the metrics. Categorizing the values means that we can decide whether or not a model is good or smelly. The modification part may contain refactorings to eliminate the specified smells.
EMF Refactor defines 27 smells for class diagrams, about half of them is rather a well-formedness constraint than a real smell: unnamed or equally named elements. Most of them provides useful refactorings to eliminate the bad smells.
In our extension, we implemented four important metric-based smells for state machines: - Hot State (Incoming): a threshold for the number of incoming transitions, - Hot State (Outgoing): a threshold for the number of outgoing transitions, - Deep-nesting: a threshold for the average nesting of states, - Action chaining: a threshold for transitions, its main responsibility is to recognize whether too many entry and exit actions would be executed in a row.
We can also detect unnamed or unreachable states and unused events.
Defining the thresholds of the smells is not easy
It is not always obvious which refactorings can help to eliminate bad smells. As we presented in Section 3, a state with a large number of incoming transitions can be simplified in two steps: group the states where the transitions come from, then fold the outgoing transitions of the new composite state. Having a large number of outgoing transitions is more complex. An idea is to describe the smelly state more precisely, this way the substates and details may explain the different scenarios, but unfortunately it also increases the complexity. In this topic further research is needed.
Deep-nesting can be improved by using specific Move State out of Composite refactorings. A further step could be to detect ”unnecessary” composite states which increase the complexity more by nesting than decrease it by folding transitions. In connection with that, an important aspect is that by using composite states, code duplication is reduced as common entry and exit actions do not have to be duplicated in substates.
Finally, action chaining is a very complex problem. It depends on the specific actions if it can be reduced or fully eliminated. Though detection is useful and shows a possible bad design, it may be better to be handled manually.
The literature regarding the metrics and refactorings of UML models is extensive. Since our interest is tool developments for executable UML models, our review of the related work is focused on the toolrelated topics.
The most well-known model measurement tool is [
The recent developments show an increased interest in the combination of metrics evaluation and
refactoring services in a single toolchain. A good starting point for the review is the survey published
by [
Compared to these researches our tool aims to support model driven development in the Eclipse framework based on Papyrus and EMF Refactor. We want to provide a tool that is built into the daily used modeling environment of the users, and there is no need to use a separate tool: the users can develop, maintain, refactor, measure and analyse their models in the same environment. One more reason that made us to choose EMF Refactor is the txtUML toolchain developed by our research group. In the txtUML toolchain executable UML models can be defined textually and the framework is able to generate executable code and Papyrus diagrams as well [De´vai et al. 2014]. Naturally, we can use our tool with the generated diagrams, nevertheless it would be a great advancement to measure and refactor them before the generation, using only the textual definition of state machines. We want our tool to be an important part of the txtUML toolchain as well.
We presented a tool that is able to measure the complexity of state charts and execute transformations to reduce their complexity. Besides implementing metrics, smells and refactorings in connection with state machines, we extended the original functionality of the EMF Refactor tool with the feature of Papyrus visualization.
We plan to implement more refactorings and smells in order to improve automation of model quality assurance. An important point of view is that we defined only metric-based smells, but in EMF Refactor, graph-based smells are also supported. Our plan is also to validate these refactorings to ensure the consistency of the model.