As emphasized already, specifying the modeling procedure for multi-view modeling methods is vital for the efficient implementation of a corresponding modeling tool (cf. (LANKHORST, 2009, p. 164f.)). However, “relations between domains (views) is poorly defined, and the mod- els created in different views are not further integrated“ (LANKHORST, 2009, p. 43). The aim of this step of the MUVIEMOT method is therefore to specify multi-view modeling use cases (cf. (BORK AND SINZ, 2013, p. 29ff.)). These special kind of UML use cases specify inter- actions between the modeler and viewpoints. Conventional UML use case diagrams (OBJECT MANAGEMENT GROUP (OMG), 2011d, p. 597ff.) are adopted by omitting the actor (as the actor is always the modeler) and relating all use cases to viewpoints. The method engineer distinguishes for each use case, whether it can be triggered in a certain viewpoint and whether executing the use case has an effect or a conditionally effect on a viewpoint. This needs to be decided for each viewpoint independently. Conventional use case relationships, e.g., include, extend, and uses, can be also modeled in order to capture relationships between functionality of the modeling tool.
The decision of the Modeling Scenario step according to the multi-view modeling principle has a significant influence on the effort of specifying the modeling procedure. If the multi-view by generationprinciple should be utilized, no propagation of modeling actions, performed in one view, must be specified. In this case, only transformations between complete viewpoints must be considered (i.e., State Translations, cf. section 5.4.2). By contrast, following the multi- view by designprinciple, dependencies between the views are already defined on the meta model level. These dependencies need to be transformed into corresponding consistency mechanisms (i.e., Transition Translations, cf. section 5.4.1).
6.3.3.2 Modeling Language: A UML profile for Multi-View Modeling Use Cases
In the Modeling Procedure step of MUVIEMOT, Multi-View Modeling Use Cases (MVMUCs) are constructed. MVMUCs are introduced by means of an extension of UML Use Case di- agrams (OBJECT MANAGEMENT GROUP (OMG), 2011d), i.e., a UML Profile. Manifold UML extensions have been published recently, in order to combine the benefits of a standard-
conforming modeling language (e.g., experienced users, available tools) with the potential of a domain-specific modeling language (cf. (FONTOURA ET AL., 2001; SELIC, 2007; SCHAMAI ET AL., 2009).
UML use cases are defined as “a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do“ (OBJECT MANAGEMENT GROUP (OMG), 2011d, p. 597). Central elements of use case diagrams are actors, use cases, and relationships between use cases. Actors are used to model entities outside the modeled system, interacting with the system by means of use cases. Actors can be used to model human beings, but also computer systems or roles, realized by an entity. A use case, “is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system“(OBJECTMANAGEMENTGROUP(OMG), 2011d, p. 606). The OMG standard defines four central relationships between use cases, the extend relationship the include relationship, and the association and generalization relationship inherited from UML class diagrams. Using the extend relationship, enables the specification of how the behavior of an extended use case may be included into the behavior of an extending use case. The extended use case should be independently form the extending use case. Hence, the extending use case may define some optional behavior, e.g., an extended use case pay purchase at the pay desk and an extending use case request receipt. The include relationship defines a direct dependency between two use cases. An including use case includes the behavior defined in an included use case, e.g., an including use case pay by credit card and an included use case check credibility status.
The conventional UML use cases have proven to be useful for the specification of the be- havior of a system. Because of the manageable set of modeling concepts and their semantics, creating use case diagrams for a system is straightforward. However, in the complex setting of a multi-view modeling method, these conventional use case diagrams are not suitable. Therefore, extensions to UML use cases are introduced in the following. The UML provides a predefined set of mechanisms, one can use in order to extend and/or customize the syntax and the semantics of the UML modeling language. Such UML Profiles, have been created in a large number of projects27 (ALDAWUD ET AL., 2003; FUENTES-FERNANDEZ AND´ VALLECILLO-MORENO, 2004; LUJAN´ -MORA ET AL., 2006). In the following, a UML Profile is introduced that incor- porates the benefits of intuitive use case diagrams with the specifics of the multi-view modeling domain. This aim is achieved by extending the UML meta model using the defined extension points, specifying the syntax and semantics for the extensions (cf. FUENTES ET AL. (2002)). A Multi-View Modeling Use Case compromises the following constituents (cf. (BORK AND SINZ, 2013)):
27 see http://www.omg.org/spec/, last checked: 2013-08-22, for a selection of UML Profile specifi-
Actor In multi-view modeling use case diagrams, there is only one actor, the modeler. For
readability reasons, we therefore suggest to omit the actor in the models.
Use Case A unique identifier (e.g., a number or name) followed by a meaningful and short
description for the use case, depicting a certain system behavior.
Triggered In A set of viewpoints (zero to many), the related use cases can be triggered in.
Zero viewpoints, if a certain use case can be triggered without being assigned to a certain view, e.g., directly on the multi-view model like a create new multi-view model function- ality. By contrast, most use cases must be constrained to one or several viewpoints they can be triggered in.
Effect On For each viewpoint it must be decided, whether the execution of an use case has
always (value “Yes“), conditionally (value “Cond“) or never an effect on that viewpoint. Conditionally effects on viewpoints are of particular interest as they challenge for both, identification and implementation.
References A list of references to use cases by means of the include, extend or generalization
relationship. The references are defined by the relationship type and the identifier or number of the related use case.
Multi-View Modeling Use Cases, as introduced above, can be visualized using a tabular ap- proach with all constituents as columns and the use cases as rows (see Table 14).
Table 14: Tabular specification of Mutli-View Modeling Use Cases (cf. (BORK AND SINZ, 2013) Use Case Triggered In Effect On References VP 1 VP 2 VP 3 VP 1 VP 2 VP 3
1. Use Case 1 Yes Yes Cond. Yes include(3)
2. Use Case 2 Cond. extend(1)
3. Use Case 3 Yes include(2)
However, using graphical representations fosters structuring of information in a more appro- priate way and intuitive understanding by human beings. Therefore, a graphical visualization of
MVMUCs is emphasized. The alignment of the elements is as follows: On the left border are all viewpoints depicted that can be related to use cases by means of triggered-in relationships. On the right border, all viewpoints are visualized again, but now only those related to use cases by means of effect-on or conditionally effect-on relationships. In the center, conventional use cases together with conventional use case relationships are visualized. Figure 36 illustrates a sketch of a graphical representation of multi-view modeling use cases (for a better comparison, the same data is used as in Table 14).
Legend:
Triggered-In
Conditional Effect
Effect
Viewpoint 1
Viewpoint 2
Viewpoint 3
Use Case 1 Use Case 2 Use Case 3Viewpoint 1
Viewpoint 2
Trigger
Multi-View Modeling Tool
Use Cases
Effect
extend include
include
Figure 36: Sketch for a graphical specification of Multi-View Modeling Use Cases
The goal of the Modeling Procedure step of MUVIEMOT is to capture the interactions be- tween the modeler and the multi-view modeling tool in an intuitive and efficient but also for- malized way. The proposed language combines the benefits of a commonly used standard for system’s behavior specification with specifically designed concepts from the multi-view mod- eling domain.
6.3.4 Step IV: Viewpoint Dependencies