In the following, requirements for a modeling method, capturing the specifics of multi-view modeling methods and the practical aspects of tool development are identified. The require- ments are built on several pillars: i) requirements found in a comprehensive literature review on multi-view modeling methods and corresponding tools; ii) requirements originating from the experience of developing multi-view modeling tools; iii) requirements from the experience of using several multi-view modeling tools, targeting at usability, and iv) requirements for model- ing languages in general.
It must be stated, that general requirements for the development of modeling methods are not considered in depth now. The focus is on the specific requirements for a modeling method targeting at the specification of a conceptual design for multi-view modeling tools. Generic modeling method requirements are discussed thoroughly by e.g., FRANK (2011c,d) or the re- search of BRINKKEMPER(1996) on method engineering.
6.2.1 Requirements from Relevant Literature
The missing formalization on the specification of the RM-ODP motivated Akehurst already 2004 to point to the research gap between a multiple-viewpoint method (RM-ODP) on the one
hand and the specification of an accordingly designed modeling tools on the other (AKEHURST, 2004). The author argues for at least three inevitable constituents of a multi-view method spec- ification: (1) Precise definitions of the viewpoint language concepts, (2) precise specification of the correspondences between concepts in each viewpoint, and (3) precise specification of example notationsfor each viewpoint.
Akehurst and Bobrik et al. moreover emphasized on the importance of visualization in multi- view environments (AKEHURST, 2004; BOBRIK ET AL., 2007). The specification of viewpoint- dependent visualizations should therefore be supported. This would allow the alignment of the visualization of common aspects to the characteristics (e.g., audience, abstraction level, con- tent, intention) of specific viewpoints. GRUNDY ET AL. (2013) (based on initial work by (SUT- CLIFFE, 2002)) identify key requirements for domain-specific visual language specifications.
LIT-1 A specification should consider the modeling language of the viewpoints by means of
syntax, semantics, and notation.
LIT-2 A specification should comprise the relationships between modeling language concepts
of multiple viewpoints.
LIT-3 A specification should emphasize on the notation of the modeling language concepts.
More precisely, it should be possible to specify a viewpoint-dependent visualization of a concept.
LIT-4 The modeling languages should be comprised of concepts in an appropriate abstraction
level, originating from the domains of multi-view modeling and conceptual tool design.
LIT-5 Appropriate and intuitive understandable visualizations should be provided for each ele-
ment of the modeling languages.
LIT-6 Whenever appropriate, multiple visualizations, e.g., graphical model visualizations com-
plemented by tabular visualizations, should be supported in order to increase expressive- ness and readability with respect to different model users and model processing scenarios (cf. (VESSEY, 1991)).
LIT-7 The modeling languages should be specified in a formalized manner. Whenever possible,
at least the syntax, at best also the semantics of the modeling method should be specified in an unambiguous way (cf. section 4).
According to BORK AND SINZ (2013) the way multi-view modeling is actually applied is not considered in method specifications, yet. In section 5.4 multi-view by design has been distinguished from multi-view by-generation. In the former case, all views are kept consistent by transition translations (cf. Definition 5), transforming the modeling operations performed
by the modeler on one view into semantically equivalent modeling operations that need to be applied to other views. By contrast, the latter case allows temporary inconsistencies between views. Views are only consistent at the time the modeler triggers a transformation, referred to as state translation (cf. Definition 6). Grundy et al. emphasize also on the behavioral aspects including “dynamic and interactive tool effects such as event and constraint handling for both model and view manipulations and automated operations or processes“ (GRUNDY ET AL., 2013, p. 489).
LIT-8 Different ways of carrying out multi-view modeling should be supported. Therefore, es-
tablishing the way modelers should interact with the multiple views and how interactions with one view are semantically transformed and applied to other views.
LIT-9 Accordingly to the former requirement, synchronization mechanisms need to be speci-
fied in order to keep the views consistent.
Several authors have emphasized on supporting method engineers in defining viewpoints (GRUNDY ET AL., 2008, 2013) and an optional navigation between viewpoints, realized by specifying hierarchical relationships between the viewpoints (ATKINSON ET AL., 2013a,b) (cf. section 3.3). This navigation hierarchy should foster understanding of the relationships between the views.
LIT-10 It should be possible to define hierarchical relationships between viewpoints, hence
enabling navigation functionality.
Following (BUNGE, 1977), WEBER (1997) emphasized on ontological completeness and ontological clarityas major requirements for modeling methods by contrasting it to the formal- ized definitions of those terms adopted by requirements engineers in the software engineering domain (cf. FRANK (2011c)). Based on the mapping between an ontological model of the application domain and the syntax of the modeling language, the following anomalies might occur (cf. (WAND AND WEBER, 2002, p. 365))26: Construct deficit, an ontological concept is not mapped to a language construct; Construct overload, one language construct represents multiple ontological concepts; Construct redundancy, multiple language constructs represent one ontological concept; and Construct excess, a language construct has no counterpart in the ontology. If a construct deficit exists, the modeling language is considered to violate onto- logical completeness; if one (or more) of the other anomalies occur, the modeling language is considered to violate ontological clarity.
LIT-11 The modeling language should emphasize on ontological completeness and ontological
clarity.
26 WAND AND WEBER(2002) refer to the modeling language concepts as construct and to the concepts of the
6.2.2 Requirements from Implementation Experience
The experience gained during the development of several modeling tools based on the ADOxx meta modeling platform serves also as a basis for practical tool development requirements. Although not scientifically valid, the experience contributes a practical perspective to the set of requirements.
EXP-1 Specification of temporal dependencies between views, i.e., viewpoint B is transformed
automatically from an already modeled viewpoint A. The transformation specification should be in a formalized manner, as experience showed that often only a semi-formal or ontological specification of the transformation is given, leaving space for interpretations to the developer.
EXP-2 Specification of a mapping between modeling operations and viewpoints, they can be
executed in. Experience showed that even if the modeling methods have specified the modeling operations thoroughly, the tool developer still has problems to constrain the operations to the viewpoints.
EXP-3 The effects of executing modeling operations in one view on all other viewpoints should
be defined accurately. Experience showed that it is likely that modeling operators are only applicable in certain viewpoints, whereas their execution may have (conditional) effects on other viewpoints.
EXP-4 Mechanisms and algorithms should be considered in the context of multi-viewing.
Specifically, view transformation, analysis, validity checks, and consistency checks should be specified.
6.2.3 Requirements aiming at Usability
In order to be applicable in an intuitive and efficient manner, usability requirements also need to be considered.
USE-1 In order to cope with the complexity and the huge amount of information that needs
to be considered, decomposing the method into a procedure of several steps should be supported.
USE-2 The method should define clear backtracks enabling the modeler to move to an earlier
step in the modeling procedure, perform changes in this earlier step and proceed from this updated models.
USE-3 The modeling languages should be intuitively usable. This requirements covers all
order to prohibit models exceeding the cognitive capabilities of the modeler (VESSEY, 1991), and Moody’s principles for designing visual notations (MOODY, 2009)).
6.2.4 Modeling Language Requirements
General requirements for modeling methods and modeling languages are summarized here. Although some of them seem obvious, they contribute to a comprehensive requirements speci- fication.
LINDLAND ET AL. (1994) introduced a systematic framework for evaluating the quality of conceptual modeling languages. The authors propose three quality criteria: syntactic quality, semantic quality, and pragmatic quality. In (TEEUW ANDVAN DENBERG, 1997), the seman- tics and pragmatics criteria of this framework have been further decomposed into the following six quality criteria (based on work of BLAAUW AND BROOKS JR. (1997) and SINDEREN (1995)): Completeness, Inherence, Clarity, Consistency, Orthogonality, Generality.
LANG-1 If the relevant aspects of the domain are still too complex, and the resulting overarch-
ing models would overwhelm the modeler, decomposition of the method (and the model) into several steps (and models) should be provided. Each step is supported by a modeling language that only captures a sub-set of the overarching model.
LANG-2 The steps followed during the application of the method should be precisely defined,
i.e., the tasks involved in a step, the objectives of the step, and the dependencies to the preceding and succeeding steps.
LANG-3 The different steps should be semantically integrated. Hence, reuse of already defined
aspects should be supported.
LANG-4 Completeness: The modeling language should provide concepts to capture all rele-
vant aspects of the real world.
LANG-5 Inherence: The languages’ concepts should precisely describe what is in its focus,
everything else should be omitted.
LANG-6 Clarity: The languages’ concepts should be intuitively distinguishable by the mod-
eler.
LANG-7 Consistency: The provided concepts should have a clear, unique semantics i.e., there
should be no ambiguous interpretation of the model.
LANG-8 Orthogonality: Orthogonality of aspects of the reality should be reflected by different
LANG-9 Generality: The concepts should be on a general level, i.e., not dependent on a certain
application domain.