Use case diagrams appear in early steps of a UML-based development. They capture user requirements, structured by the concepts of use cases and actors. An admitted good modeling practice is to design simple, easy-to-read use case diagrams. That can be achieved by introducing relevant generalizations of actors and use cases. The paper proposes an approach based on Formal Concept Analysis and one of its variants, Relational Concept Analysis, to refactor a use case diagram as a whole in order to make it clearer. We developed a tool and studied the results on about twenty examples, concluding on the relevancy of the approach on our benchmark.
Within a UML-based development, the very first model to be designed is the
use case diagram, that is later used all over the modeling process. For example,
in the Rational Unified Process [
As mentioned in the UML user guide [
In this paper, we investigate an approach to make use case diagrams clearer by introducing generalized actors and use cases to factorize relations. Our approach is based on several refactoring patterns (e.g. when two use cases include the same third one, they can be generalized by a new use case including this third use case), that are globally combined using Formal Concept Analysis (FCA) and one of its variant Relational Concept Analysis (RCA). The approach is implemented in an Eclipse-integrated tool that takes as input a UML diagram, encodes it into FCA (or RCA) contexts, generates the corresponding concept lattices, and finally produces as output the refactored use case diagram. We studied the results of this approach on several examples, comparing the pairs of input diagram/output diagram, and FCA versus RCA.
The following of the paper is structured as follows. We first illustrate in Section 2 the use case diagram refactoring with an example that will later be used to illustrate our approach. Section 3 details the used refactoring patterns, and Section 4 explains how they are globally applied using FCA or RCA. Results of our experiments on examples are given in Section 5. Section 6 compares our approach w.r.t. related work. 2
This section presents a motivating example. We briefly recall the main elements involved in UML use case diagrams, and then illustrate the use case generalization defects. The application we are interested in should allow various users to buy products or apply for interships. Figure 1 shows a use case diagram for this application. Actors represent the role(s) played by external persons or systems that interact with the modelled system. They are depicted using a “stick man“ icon (or a box stereotyped <<actor>> with the name of the actor). Here, three roles are identified: a company, a registered client, and a registered company. Use cases, depicted by named ellipses, model large functionalities. In our example, we find the use case Apply for Multi-Period Internship, modelling the functionality corresponding to the possibility to apply for internships organized over several periods (for example a day per month). Use cases are associated (graphically by a continuous line) to the actors involved in them: actors to which the functionality is dedicated or secondary actors that interact with the system during the achievement of the functionality. In our example, the use case Apply for Multi-Period Internship is linked to the Registered Client and the Registered Company actors, since both of those actors can apply for such internships (whereas non-registered companies cannot). A use case may include another one. Graphically, it is shown by a dashed oriented arrow stereotyped by <<include>>. Semantically, that means that the including use case explicitly incorporates the behaviour of the included use case. For example, the use case Buy with Bank Transfer includes the use case Send Recapitulative Email. A use case may be extended by another one. Graphically, it is shown by a dashed oriented arrow stereotyped by <<extend>>. Semantically, that means that the extended use case may include the behaviour of the extending use case. In our example, a recapitulative email may be sent while realizing an appliance for a multi-period internship. Conditions for the extension and extension points can complete the extension relationship, as discussed later in the paper. UML provides two generalization mechanisms in use case diagrams: for actors and for use cases. Figure 2 shows a refactored use case diagram for the internship example, in which those two mechanisms appear. A use case may generalize another one: the child use case inherits the behaviour of the parent use case, as well as its meaning. It is graphically represented by an edge ended by a triangle, like for class inheritance. In the refactored example of Figure 2, the use case Buy generalizes the use cases Buy with Bank Transfer and Buy with Fidelity Card. An actor may generalize another one: the child actor inherits the roles of the parent actor, i.e. its interactions with use cases. In Figure 2, the actor RegisteredCompany specializes the actor Company.
The initial diagram of Figure 1 suffers from the large number of crossed links from actors to use cases, and to a lesser extent, from the large number of links from use cases to use cases. The actor RegisteredCompany is linked to four use cases. Introducing a generalization from this actor to the actors Company and RegisteredClient is semantically correct and factorizes the four links: in the refactored diagram proposed in Figure 2, the actor RegisteredCompany inherits its links to the use cases from its two parent actors. Similarly, the two inclusions of the use case Client Identification (resp. Send Recapitulative Email) by the use cases Buy with Fidelity Card and Buy with Bank Transfer can be factorized introducing the sound use case Buy. Last, the two extensions can be factorized introducing the sound Apply For Internship use case.
The approach we propose aims at detecting the possible relevant generalizations in a use case diagram, and introduces them in order to obtain a simpler use case diagram. For that, we first identify (in refactoring patterns) situations for which introducing a generalization may be useful. Then to automatically apply these patterns, we use Formal Concept Analysis (FCA) or one of its variants Relational Concept Analysis (RCA). The refactoring patterns are presented in the next section while the FCA/RCA application is detailed in Section 4. 3
To correct generalization defaults, we propose a systematic approach that introduces more general elements (actors or use cases) based on the detection of shared relations. However, this does not guarantee the relevance of factorizing the relations using more general use cases or actors. In this section, we study several refactoring proposals. We consider here a simple set-based semantics, associating to a use case diagram the set of its actors and for each actor the feasible sequences of leaf use cases. The use cases having specializations are supposed to be abstract, i.e. replaced by one of their specializations during a concrete usage of the system.
Refactorings between use cases. Table 1 presents the refactoring patterns for use cases. The pattern I considers the situation of two use cases A and B including the same use case C. In this situation, all the sequences that can be performed by an actor and that contain A (resp. B) will also contain C. We propose to refactor the two inclusions as seen in the refactored pattern: a sequence that can be performed by an actor and containing A will still contain C, since A specializes N that contains C. In situation II, when the two conditions of extension CA and CB are identical and that the extension points (that roughly specify when the extension should occur) are also identical, then a generalization can be introduced. It frequently occurs that extension points and conditions are not specified for the extensions, in this case we propose to apply the refactoring, whereas if the extension conditions or the extension points are different, this refactoring does not apply. The situation III introduces a specialization refactoring. The source pattern owns a use case A for which the sets of outgoing include relations and incoming extend relations are strictly included in those of another use case B. The proposed refactoring derives B from A and removes from B the inherited relations. Situations to factorize incoming include relations or outgoing extend relations were studied but rejected since they were not pertinent. Refactorings outgoing include «include»
«include» Condition : CA ExtensionPoint : EA «extend» «extend» Condition : CB
Extension Point : EB incoming extend between actors. Table 2 presents two refactoring patterns between use cases and actors. The first one (I) introduces a specialization relation between actors when the set of associations of one actor is strictly included in the associations of another actor, and then removes the inherited associations. The second one (II) adds an abstract actor when the sets of associations of two actors have a nonempty intersection but each actor has associations that the other one does not have.
The refactoring schemas presented in the previous section do not give a unique
solution to deal with a use case diagram as a whole. For that, we use Formal
Concept Analysis [
Refactoring with FCA. We build two formal contexts (Table 3). In one context, we associate an actor with a use case when the actor is involved in the use case. In the second context, use cases are described by inclusion of another use case, extension by another use case and names. Figures 3 and 4 present the lattices. In the lattice of actors (Fig. 3), a generalization relationship is introduced: C2, which represents RegisteredCompany, is indeed a subconcept of C1 (RegisteredClient) and C3 (Company). This is an application of the first actoruse case refactoring. The lattice of use cases (Fig. 4) highlights two refactorings. The outgoing-include refactoring appears on the left: C5 generalizes the concepts that introduce Buy with Fidelity Card (C8) and Buy with Bank Transfer (C11) because these two use cases include Send Recapitulative Email and Identify Client. C7 shows an opportunity to apply the incoming extend refactoring (II): it factorizes the characteristic of being extended by Send Recapitulative Email, which is shared by Apply for Multi-Period Internship (C10) and Apply for Customized Internship (C12). The final use case diagram (Fig. 2) is deduced from the two lattices. The (non-trivial) concepts are interpreted as actors or use cases and the lattice partial order as generalization/specialization as illustrated just before. In our example, no new actor is created, but it happens in other diagrams of our benchmark. Two new use case factorizations are introduced: Buy (from C5) and Apply for internship (from C7) that appear in the final diagram and increase its abstraction level and reusability.
C0 (S: 0)
C1 (S: 0) C3 (S: 0) (IsInvolvedIn,BFC) (IsInvolvedIn,BBT) (IsInvolvedIn,AMPI) (IsInvolvedIn,ACUI) RegisteredClient Company
C2 (S: 0)
RegisteredCompany
Refining the refactoring with rca For further refining of the result, we applied
Relational Concept Analysis (rca) [
C0 (S: 0) IsInvolvedIn : C1 IsInvolvedIn : C12
IsInvolvedIn : C13
C9 (S: 1) C11 (S: 1) IsInvolvedIn : C2 IsInvolvedIn : C6 IsInvolvedIn : C5 IsInvolvedIn : C7 RegisteredClient Company
C10 (S: 1)
RegisteredCompany corresponding object-object tables) and integration of the concepts discovered at the current iteration in the relational part (to be used at the next iteration). The integration of the concepts discovered at the current iteration uses scaling operators, here the existential operator has been used. For the integration, an object-object relation (e.g. Includes) is transformed by replacing the objects which are in the columns by the concepts of the lattice built at the current iteration on these objects. Then a relation is established in the new, existentially scaled, table, between an object and a concept, when the object is in relation with at least one object in the extent of the concept. For example, RegisteredClient IsInvolvedIn BFC in the original relation. Then, when at an iteration BFC is in the extent of a concept, say C12, in the scaled IsInvolvedIn relation, RegisteredClient is considered as participating in one of the use cases grouped by C12. A pair (RegisteredClient, C12) is added in the scaled table IsInvolvedIn. This pair enriches the description of the three actors and at the next fca step, it is factored out in C0, top of the actor lattice. That highlights the opportunity to define a more generalized actor, this opportunity did not appear in the one-step fca building.
At each step, new concepts can appear, as well as new pairs relating these new concepts. The process iterates until no new concept or description emerge. Figures 5 and 6 show the final lattices. Lattices are interpreted as in the fca analysis, adding an interpretation of the references between the two lattices. The result of rca improves the result of fca on this example by adding the new, more general actor (Fig. 7). Furthermore, the interpretation of the concepts is used to interpret the references between lattices. For example, the characteristic isInvolvedIn:C12 which appears in C0 of the actor lattice signals that the actor which will be created to interpret C0 will participate in the use case resulting from the interpretation of the use case C12, that is the general use case Buy. We present in this section the current implementation of our approach and the results obtained by running it on different kinds of data.
The Eclipse Modelling Framework (EMF) is a facility from the Eclipse IDE to implement modelling languages and generate tools to manipulate instances of those languages from programs. We use in our tool two Eclipse plugins based on EMF: UML21 and eRCA2. UML2 is an implementation of UML and therefore allows us to load, modify and save use case diagrams. eRCA is an implementation of FCA and RCA algorithms which uses EMF to implement contexts and lattices. We have developed a tool implementing both the FCA and RCA approaches for use case refactoring. For both of them we developed the same three steps described in Section 4: first the tool loads a use case diagram using UML2 plugin and encodes it as contexts in eRCA format; second it uses the eRCA tool 1 http://www.eclipse.org/uml2/ 2 http://code.google.com/p/erca/ to generate lattices in eRCA format; finally lattices are automatically analyzed to create back a use case diagram in the UML2 plugin format and to save it.
We present here the results obtained using data gathered from different sources such as student projects or UML courses taken from the internet3. We encoded these diagrams using the UML2 plugin in Eclipse. Then we applied our two processes in all of them and automatically processed the results to compare them with the original diagrams. We computed the density of the diagram which is, if we consider the diagram as a graph G = (V; E), the number of edges over the number of possible edges jEj=jV j2. We assume that the lower density we have the clearer the diagram is. Of course, this is just indicative. We present in Figure 8 how the density can be changed by our approach on all our data. The last five diagrams considered (test1 to test5) are used to test specific situations. We see that in most of the diagrams the density is lowered by using FCA and RCA, but with better results for FCA. Density goes down due to the creation of new use cases or actors and to the factorization of the relationships. An inverse situation can occur if the number of generalization links created is higher than the number of links removed by factorization. This is why FCA seems to be better here than RCA, because RCA creates more concepts. Nevertheless, the density for RCA usually remains better than the original density. We also see that density is not improved for the diagram Invoice. Indeed, we assume that each actor involved in a use case has the same role, so they can be factored into the same concept. But in the case of this diagram, many actors are involved in the same use cases but with different roles. This may be allowed depending on the interpretation of the UML specification, but results in the merging of many actors into one. By removing those actors and thus not adding new abstractions among actors, the density is then increased. This can be partly solved by adding an identifier for each actor when creating the contexts, but this prevents us to find new generalizations of actors since none of them would share in their intent the same identifiers. 6
Literature dealing with designing use cases is prolific, but usually concentrates
on textual use cases [
FCA has already been applied to use cases [
UML use case diagrams can be seen as the functional cornerstone of UML modeling. In this paper, we proposed an approach to refactor such use case diagrams in order to make them clearer. The principle is to use FCA or RCA in order to detect new abstractions that, when introduced in the diagram, can reduce its visual complexity. Using the tool we developed to implement this approach, we carried on experiments using a set of about 20 use case diagrams to measure its efficiency in terms of density of relations in the diagram. It results that both FCA and RCA processes decrease the density of realistic-size use case diagrams, the density obtained with FCA being lower than with RCA. However, RCA discovers more abstract use cases or actors that can be relevant. To go further in this study, we are studying accurately other metrics, both quantitative as average degree, and qualitative, as precision.
Acknowledgments. Authors would like to thank L. M. Hakik for a preliminary study, K. Bouzroud, I. Dagha, H. El Assam, M. El Asri, and J. Ruiz-Simari for their help in the implementation of the current tool, and the anonymous reviewers for their suggestions on evaluation metrics.