Single Underlying Models for Projectional, Multi-View Environments
Total Page：16
File Type：pdf, Size：1020Kb
Single Underlying Models for Projectional, Multi-View Environments Johannes Meier1, Heiko Klare2, Christian Tunjic3 Colin Atkinson3, Erik Burger2, Ralf Reussner2, Andreas Winter1 1Software Engineering Group, University of Oldenburg, Germany 2Software Design and Quality Group, Karlsruhe Institute of Technology, Germany 3Software Engineering Group, University of Mannheim, Germany 1fmeier,[email protected], 2fklare,burger,[email protected], 3ftunjic,[email protected] Keywords: projectional, SUM, model consistency, integration, metamodeling Abstract: Multi-view environments provide different views of software systems optimized for different stakeholders. One way of ensuring consistency of overlapping and inter-dependent information contained in such views is to project them “on demand” from a Single Underlying Model (SUM). However, there are various ways of building and evolving such SUMs. This paper presents criteria to distinguish them, describes three archetyp- ical approaches for building SUMs, and analyzes their advantages and disadvantages. From these criteria, guidelines for choosing which approach to use in specific application areas are derived. 1 Introduction erty of all projective approaches is that views are considered to be correct by construction and thus in- Due to the ever growing complexity of modern herently consistent with each other as long as they software-intensive systems single developers are no are consistent with the SUM. The problem of main- longer able to understand all aspects of a system as taining inter-view consistency therefore becomes the a whole. View-based development methods are there- problem of maintaining the internal consistency of fore needed to separate system descriptions into in- the SUM and the correctness of SUM-to-view pro- dividual parts that are relevant to the concerns and jections. To describe the different approaches in a responsibilities of single developers. However, the uniform way and analyze their pros and cons system- resulting fragmentation of system descriptions leads atically, this paper classifies the different fundamen- to redundancies and dependencies between the infor- tal strategies for constructing SUMs and their corre- mation shown in different views, which are difficult sponding SUMMs, and identifies criteria for evaluat- and time consuming to manage manually. Automated ing them. More specifically, three existing approaches approaches for ensuring the holistic consistency of for constructing SUM(M)s are compared in terms of multi-view system descriptions are therefore needed. how they fulfill the identified criteria. Finally, we View-based approaches can be synthetic or pro- analyze how the fulfillment of the identified criteria jective (ISO/IEC/IEEE, 2011), depending on where by the different approaches affects their suitability for information is stored. In synthetic approaches, the specific situations. description of the system is spread over all the in- The insights presented in this paper will allow dividual views, whereas in projective approaches, researchers to classify new approaches for SUM(M) the description is contained in a Single Underlying constructions and help developers to choose projec- Model (SUM) (Atkinson et al., 2010), and views are tional view-based approaches for their specific project projected from this central store of information as situations using the identified selection criteria. needed. As with all models in model-driven develop- After introducing a running example and termi- ment, a SUM conforms to its metamodel, the Single nology used in this paper in Section 2, classifica- Underlying MetaModel (SUMM). tion criteria for SUM approaches are described in The goal of this paper is to illuminate differ- Section 3. The three SUM approaches OSM (Sec- ent strategies for supporting projective approaches tion 4), VITRUVIUS (Section 5), and MOCONSEMI to view-based software engineering and to highlight (Section 6) are presented subsequently and are clas- their pros and cons. The common underlying prop- sified using the criteria in Section 7. From this clas- sification, guidelines for deciding which approach to tween instances of metamodels. choose when are derived in Section 8. After dis- We define two exemplary consistency rules for the cussing related work in Section 9, Section 10 sum- running example: While Consistency Rule 1 covers a marizes the findings of this paper. situation where existing redundant information needs to be kept consistent, Consistency Rule 2 addresses a different problem of introducing additional infor- mation depending on other information. We consider 2 Terminology & Running Example these consistency rules representative, since integrat- ing different views usually refers to merging concepts To motivate the use of several interconnected or introducing additional associations. views in the development of a system, we introduce a Consistency Rule 1: Classes can be defined in highly simplified running example describing the re- the architecture view and in the implementation view: quirements, architecture and implementation of a sys- One concrete class can be defined either only in the tem. These three views are expressed in languages implementation (Java.ClassType), or in both im- based on metamodels that define the elements (e.g., plementation and the architecture (UML.Class) if it classes, attributes etc.) that can appear in models. We represents a module. In the latter case, this class has depict those metamodels in Figure 1. This section to be kept consistent in the implementation and ar- also clarifies the terminology used in this paper. chitecture, e.g., in the case of renaming this class. Requirements are represented by natural language Therefore, the implementation and architecture are sentences (package Req). Each Requirement within only consistent if the architecture contains a subset a RequirementsSpecification is identified by a of the classes in the implementation. unique id, which contains the requirement’s sentence Consistency Rule 2: Since requirements define as simple text, and is written by an author. goals that the implementation should fulfill, the de- The architecture is described by simplified class velopment progress can be measured by counting the diagrams, which represent system modules as classes requirements that are supported by the current imple- (package UML). ClassDiagrams contain Classes with mentation. Therefore, Requirements must be linked their className and unidirectional Associations. to the implementing Methods. We thus require that The implementation realizing the architecture and each Method has to be automatically linked to those requirements is represented by source code devel- Requirements that contain the Method’s name in oped in simplified Java (package Java). The JavaASG their text. This additional information between re- contains ClassTypes, which in turn contain Methods quirements and implementation has to be stored and with their caller/callee relations. kept consistent. Since this is a simplified example for These three languages describe different (not nec- this paper, different rules can be specified instead. essarily all) facets of the system under development These two consistency rules and three languages and thus represent three overlapping viewtypes. Ac- are used to motivate criteria for SUM approaches in cording to Goldschmidt et al. (2012), a viewtype is Section 3. SUM approaches define how SUMs as well the metamodel of a view, while a view is a model as their SUMMs are constructed and are designed by that projects information from another model (here: platform specialists, who develop platforms that sup- the SUM) for a specific purpose. Since all views port SUM-based development. Three such platforms share information about the system under develop- are presented in Sections 4–6 and applied to this run- ment, they are semantically interconnected and con- ning example by a methodologist, who uses a SUM tain dependent information, which requires updates of platform to define a concrete SUMM to support a par- other views if one is changed. The interdependence of ticular view-based method (Atkinson et al., 2010). information can be explicitly defined in consistency Depending on the approach, to create the SUMM rules, which define the relations that have to hold be- the methodologist either reuses the existing metamod- Req UML RequirementsSpecification ClassDiagram Java JavaASG container [1] diagram [1] asg [1] content [∗] usedBy [∗] type [1] classes [∗] classes [∗] calledBy [∗] calling [∗] Requirement Association class [1] Class ClassType class [1] Method id : EString [0::1] name : EString [1] author : EString [0::1] lowerBound : EInt [0::1] associations [∗] className : EString [1] name : EString [1] methods [∗] name : EString [1] text : EString [0::1] upperBound : EInt [0::1] Figure 1: Simplified Metamodels for Requirements (left), Class Diagrams (middle), and Java Source Code (right) els in Figure 1 or defines a new metamodel for the consistency rules than equivalent essential SUMs. described concepts. After that, the developer instan- While C1 focuses on the starting point of the tiates that SUMM defined by the methodologist to SUM construction process, C2 focuses on the results. develop a software system through views projected Together they allow SUM approaches to be compared from the SUM. The methodologist can also specify at conceptual level. new viewtypes to provide new views corresponding to the specific concerns of the developer. 3.2 Selection Criteria