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 [
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) [
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. 2
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 [
Goal models have also been connected to other types of models, with consistency
challenges. Alves et al. [
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. 3
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). URN Links of type Traces are used to capture explicit traceability information used during consistency analysis, and links are visualized through outgoing (▶) and incoming (◀) link triangles. In this example, the Worker actor in the GRL view traces to the Worker component in the UCM view. In addition, the By Bus task in the GRL view traces (incorrectly) to the TakeCar responsibility in the UCM view. The connecting arrows were added for illustration but they are not part of the URN notation.
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. 4
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
definition, selection, and checking of OCL rules by modelers, and a library of predefined
OCL functions for extracting information from URN models is also provided [
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. context grl::Actor inv URNconsAllActorsToComponents: -- #1a: Each GRL actor must have a Traces link to a UCM component, -- unless tagged with Traces=No not(getMetadata('Traces')='No') implies
(getLinksToForType('Traces')->size() > 0) inv URNconsActorsToComponentsOnly: -- #1b: Traces links from a GRL actor must only be to a UCM *component* not(getMetadata('Traces')='No') implies ( getLinksToForType('Traces')-> forAll(me:urncore::URNmodelElement |
me.oclIsKindOf(urncore::Component) ) ) 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. ID 1a 1b 1c 1d 2a 2b 2c 2d 2e 2f 3a 3b 3c 3d 3e 3f 4c 4d 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). 5
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 [