The User Requirements Notation (URN) is a standard modeling language that includes two complementary views, one for goals with the Goaloriented Requirement Language (GRL) and one for scenarios/processes with Use Case Maps (UCM). The URN standard, however, does not provide means of checking consistency between the GRL and UCM views, leading to models that are potentially erroneous. This paper presents a preliminary set of rules for checking common consistency properties in URN models. These rules have been implemented as user-selectable OCL constraints in the jUCMNav tool. Future opportunity for research in that space are also identified.
The User Requirements Notation (URN) is a standard modeling language used to model and analyze requirements [1,2]. URN includes two complementary views, the Goal-oriented Requirement Language (GRL) for modeling goals, actors, indicators, and their relationships, and the Use Case Map (UCM) notation for modeling responsibilities, processes/scenarios, and their underlying components. GRL and UCM models can be connected using typed URN Links by specifying user-defined relationships between any pair of URN model elements. URN Links establish traceability and enable completeness and consistency analysis between GRL and UCM models.
Although the URN standard provides well-formedness rules to ensure some consistency within each of the GRL and UCM views, it does not provide means of checking consistency across these views, leading to models that are potentially erroneous.
To address this gap, we present a preliminary set of user-selectable rules for checking common consistency properties in URN models in a way that exploits URN Links as well as URN metadata (i.e., annotations on URN model elements). The rules were created using UML's Object Constraint Language (OCL) [3], and implemented in the jUCMNav tool. jUCMNav is a free plugin for Eclipse used to create and analyze URN models [4]. This paper is a first step towards user-selectable rules supporting automated consistency analysis between the GRL and UCM views of a URN model.
The remainder of the paper is as follows. Section 2 describes work related to consistency analysis in modeling languages. A modeling example is used to describe consistency problems in URN models in Section 3, while Section 4 highlights our proposed consistency rules. This paper concludes in Section 5 with a summary and a list of potential consistency issues we hope to address in the future.
Consistency analysis in modeling aims to detect contradictions when multiple views are used to specify different subsets of a model. Inconsistencies occur frequently if these views are provided by different modelers, or when a language includes different sub-notations. A good example is UML, where several challenges exist due to the presence of 14 diagram types. For instance, messages used in sequence diagrams and transition actions used in state machine diagrams must correspond to operations (and their signatures) in their respective classes in class diagrams. There is even a workshop focusing on such issues [5]. Resolving consistency issues often involves adding, deleting, or modifying model elements in one or many views to better align the latter with each other. Goal models have also been connected to other types of models, with consistency challenges. Alves et al. [6] have investigated bi-directional mappings between Business Process Model and Notation (BPMN) and i* models. Their mappings targeted transformations (instead of checking), but these mappings were not defined in a way amenable to automation. A similar informal and syntactic approach was explored by Guizzardi and Reis for BPMN and Tropos models [7]. In their GoalBPM approach, Koliadis and Ghose trace BPMN elements to KAOS goals through effect annotations [8]. Sousa and Leite proposed to merge BPMN, i* and indicators into a single language in their GPI approach, in order to simplify the alignment between goals and processes. However, they do not suggest consistency or completeness rules.
Our work is inspired from these related contributions, but also targets automated checking of inconsistencies in a standard multi-view language (URN) through userselectable rules formalized in OCL.
Consider the illustrative example described in Fig. 1. In the GRL view shown on the left, we have a Transportation System whose At Work goal is decomposed into two options described as tasks: By Bus or By Bike. The Worker actor wants to improve her health, and the first option hurts that softgoal whereas the second option helps it. The top UCM map shown in Fig. 1 describes the process involved in the worker getting to work. The choice of transportation mode is described using a dynamic stub (Transport) and two options are available, TakeCar and TakeBus, captured as submaps with one responsibility each (and plugged into that stub). We can observe potential inconsistencies across these GRL and UCM views. The GRL Transportation System should likely trace to the UCM System. The By Bike task has no corresponding map or responsibility, which can raise several questions (is this task spurious? Is a map or responsibility missing?). The By Bus task likely traces to the incorrect responsibility (should be to TakeBus instead of TakeCar), but then the TakeCar map might require a link from a new GRL task or be removed for consistency. Lastly, the Leave responsibility has no trace link, but maybe there is no reason to link it either; not all fine-grained operationalizations need to be justified, just like not all goals need to be operationalized (e.g., the color of the system shall be blue).
Given the current lack of support for consistency analysis in the URN standard, these types of inconsistencies (and others) could easily be overlooked in more complex models, leading to erroneous model analysis results. The resolution of such inconsistencies (e.g., adding/removing/modifying a GRL/UCM model element or URN Link, or tagging a model element as something that does not require traceability) requires human judgement and is outside the scope of this work. However, consistency rules can still be defined formally in order to detect violations automatically.
Consistency rules can be defined as constraints on a language's metamodel. OCL is a good choice in our context as URN has a unified metamodel covering both the GRL and UCM views. From an implementation perspective, jUCMNav supports the defini-tion, selection, and checking of OCL rules by modelers, and a library of predefined OCL functions for extracting information from URN models is also provided [10]. Such mechanisms enable the checking of rules, e.g., in a language profile [11].
Our consistency rules exploit two modeler-provided information elements: URN Links of type Traces from a GRL element to a UCM element (by convention), and metadata (name=Traces, value=No) used to annotate model elements for which we do not expect any consistency-related Traces link. Rules come in groups of multiple, fine-grained OCL invariants in order to report violations with precise error messages.
The first rule (#1, below) addresses the consistency between GRL actors and UCM components. Part #1a checks the existence of a Traces link sourced at the GRL actor and part #1b checks that the target of such links is indeed a UCM component. These invariants make use of OCL functions predefined in our library: invoking getMetadata(n:String):String returns the value of the first attached metadata object whose name is n, and getLinksToForType(t:String):Sequence(URNmodelElement) returns a collection of target model elements found at the end of URN Links of type t. The above invariants check this rule from the actors' perspective only. However, one must also check the presence of links from the UCM components' perspective (as there could be components without incoming Traces links). Hence, another pair of similar invariants is provided (#1c and #1d in Table 1). A violation of any of these invariants reported by jUCMNav on a URN model will indicate which model element is incorrect, and the description is returned as an error message. For the example in Fig. 1, jUCMNav reports violations of invariant #1a on the GRL actor Transportation System and of invariant #1c on the UCM component System.
The second rule in Table 1, composed of six invariants, checks the consistency between GRL intentional elements and UCM maps or responsibilities (in order to cover different levels of granularity). For example, in Fig. 1, the GRL goal At Work could have a Traces link to the top-level UCM map, and the Leave responsibility could be tagged with a Traces=No metadata. Rule 3 is an alternative to Rule 2 where only GRL tasks are used for consistency checking instead of any type of GRL intentional element (assuming that covering tasks is enough in some modeling context). The modeler would need to choose between Rule 2 and Rule 3 for the consistency analysis as these rules are mutually exclusive. Traces links to a UCM component (or one of its parents) must only be from a GRL *actor* Rule 4 is a recursive version of Rule 1 where #4a=#1a and #4b=#1b. From a UCM perspective, it suffices that the component or one of its containing components is the target of a Traces link from a GRL actor for the rule to be satisfied. For example, if component C2 is the target of a valid Traces link and C1 contains C2 and C2 contains C3, then C2 and C3 would be consistent (no violation) whereas C1 would not. Other such recursive rules, which minimize the need to manually create Traces URN links, could also be considered (e.g., for a structure of maps with stub containing sub-maps).
In this paper, using an example, we showed a preliminary set of consistency rules for automatically checking common consistency properties across the goal and process views in URN models. The 18 invariants in Table 1 have been implemented as userselectable OCL constraints in the jUCMNav tool, and tested for correctness. Other such rules are currently under development and are expected to be released as a catalogue of validated consistency rules, possibly integrated to the URN standard.
This work raises many new research questions on how best to achieve sound goalprocess consistency in URN models while maximizing usability through automation (as manually creating and checking URN links is much cumbersome). For example:
• Should there be different types of links connecting GRL and UCM elements?
• Can UCM variables (used in conditions and responsibilities) capturing the satisfaction levels of GRL intentional elements be used as traceability links? • What recursive rules exploiting containment structures are beneficial?
• Should different rules apply to different parts/elements of a URN model? • Can natural language processing (NLP) or other approaches be used for creating (some) URN links automatically? • How can jUCMNav's interface be made more usable? E.g., when we create a GRL actor, should a UCM component be created and linked automatically? • In addition to the "syntactic" rules proposed in this paper, should semantic rules and evolution rules (consistency across versions) be considered [5]? An empirical study on the application of such rules would also help observe what really helps or hurts in terms of consistency and overall quality of URN models.
Acknowledgments. OA and DX are supported by Discovery grants (of DA ad LL respectively) from the Natural Science and Engineering Research Council of Canada. OA is further supported by Interis Consulting/BDO, and AAA by a scholarship from the Government of Libya.