6.2 Running Example: Ceiling Speed Monitor
7.1.1 System Structure and Behavior Metamodels
First, we focus on the software modeling domain affecting the resulting artifacts of the constructive phases of development. As usual, we distinguish between structure- and behavior-describing models. Depending on the use case and development context, there is a wide range of possible modeling languages that can be applied. The spectrum ranges from very formal modeling languages to languages that are primarily used for visualization purposes. In the context of the presented MCSTLC, the modeling lan- guages need concrete semantics to provide a sufficient basis for subsequent processing steps.
In the following, some modeling languages and the underlying metamodels are de- scribed in more detail. The languages presented are applied in the context of the run- ning example and the case studies considered in the evaluation chapter. The former is described in more detail and set about concrete model instances of the running exam- ple.
OMG Systems Modeling Language
The Systems Modeling Language (SYSML) of the OMG is a popular language in the field of systems engineering. The SYSML is based on UML and enables the structure and behavior of the respective SUD to be modeled by many different diagram types [1]. For the sake of clarity and demonstration purposes of the approach presented in this thesis, a simplified metamodel of SYSML is defined based on the SYSML model of theCeiling Speed Monitor(introduced in section 6.2). The metamodel is specified as an Ecore model since this technology offers the best integration within the prototypical implementation of the concept (see section 7.3). A complete mapping of the concepts covered in the SYSML specification is possible but is not intended in the context of this thesis.
In the following, the simplified metamodel of SYSML is introduced and the correspond- ing SYSML model of the running example is explained and set into relation with the metamodel. We start with the top-level concepts and packages, which form the basis for all further specific concepts (see figure 7.3). This excerpt shows the most general concept of the metamodel, identifying any model artifact. Furthermore, concepts are introduced which allow to specify attributes and parameters.
Figure 7.3: Simplified SYSML metamodel
Table 7.1: Metamodel element descriptions for figure 7.3 Concept Description
SYSElement The most abstract concept of the simplified SYSML metamodel with a uniqueidandnameattribute
SYSVariable Concept for the definition of block member variables SYSEnumeration Concept for the representation of enumeration datatypes
SYSDatatype Enumeration for the supported basic datatypes of a block member variable
Below this top-level of the SYSML Ecore metamodel, two additional packages are in- cluded: First, thestructurepackage (figure 7.4 and table 7.2) defining concepts to struc- ture the SUD by blocks, to define their interfaces, and to map the information flows between these structural elements.
Figure 7.4:Structurepackage of the simplified SYSML metamodel
Table 7.2: Metamodel element descriptions for figure 7.4
Concept Description
SYSStructureElement The most abstract concept of the structure package (for im- plementation purposes)
SYSBlock Concept reflecting the standard SYSML block
SYSSystem A special kind of SYSML block encapsulating the overall sys- tem
SYSPort Concept for the SYSML port which is attached to a block SYSConnector Abstract concept representing multiple types of connectors
in the SYSML context
SYSFlowDirection Enumeration for the specification of an information flow di- rection regarding the mentioned port concept
SYSItemFlow Concept contributing the specification of an item flow be- tween two ports
SYSFlowSpecification Concept encapsulating a specification for the items ex- changed through an item flow
SYSFlowProperty Concept encapsulating the valid direction and data struc- tures for the respective ports
The second package, namely thebehaviorpackage, is shown in figure 7.5 and table 7.3.
Not all behavior diagrams specified by UML and SYSML are shown here. The concepts defined in figure 7.5 allow the specification of hierarchical statemachines.
Figure 7.5:Behaviorpackage of the simplified SYSML metamodel
Table 7.3: Metamodel element descriptions for Figure 7.5
Concept Description
SYSBehaviourElement The most abstract concept of the behavior package (for imple- mentation purposes)
SYSStateNode Concept for a state of the statemachine not specifying any be- havioral details, e.g. initial or final nodes
SYSState Concept for a state including additional information like trig- gered operations
Table 7.3: Metamodel element descriptions for figure 7.5 (continued)
SYSTransition Concept for a transition between two state nodes withguard conditions and triggeredeffects
With this set of concepts, it is possible to completely model theCeiling Speed Monitor.
Thereby, models based on this metamodel can be used in the context of the Omni Model approach and thus applied in later process steps of the MCSTLC. Part VI (Supplemen- tary Material) shows the individual diagrams describing the entirety of theCeiling Speed Monitor.
OMG Unified Modeling Language
An alternative modeling language for the system model parts of the Omni Model is UML. This GPML, which covers many disciplines of development, offers a very wide range of concepts and diagram types for MDSD [3]. The modeling scope of UML is significantly larger than that of the SYSML, which is reflected in a high number of di- agram types for structural and behavioral modeling. However, a complete mapping would again exceed the scope of the work. Therefore, the metamodel used for UML represents a simplified variant created about the model artifacts of the case study (see section 12.2).
The metamodel is divided into several packages that group the concepts according to diagram types as well as responsibilities. Part VI (Supplementary Material) introduces and explains all concepts of the simplified metamodel and puts them into relation.
The radCase Modeling Approach
The last modeling language, which is used exemplary for the System Modeling do- main is given by the modeling toolradCaseof the company IMACS [75]. This language is used to model embedded systems and therefore offers specific concepts for this area.
Besides, the modeling language is implemented as a UML profile, i.e. any GPML mod- eling tool can be used to create radCase models. Due to the strong focus on the ap- plication domain, the underlying metamodel is not very elaborated. This metamodel is the basis of the System Models in sections 12.1 and 12.3. In part VI (Supplementary Material) this metamodel is considered more closely.
(Modeling) Guidelines & Best Practices
A set of guidelines and best practices are necessary to ensure the basic functioning of subsequent processing steps as well as the quality of resulting findings. It is important
to note that the overall structure in System Modeling has a significant influence on the subsequent modeling of the test cases. If a certain amount of preliminary work is already being carried out on the System Modeling side, then the Test Modeling can be carried out effectively. However, if important guidelines are disregarded, a system can hardly be tested resulting in remaining serious defects. Therefore, this section defines metamodel-independent modeling guidelines useful for the MCSTLC steps.
The testability of a system is affected by its transparency regarding connectors between components and the structuring of sub-components. These properties have proven to be particularly useful during validation of hardware-related components under the term “Design4Testability” [173]. In the context of System Modeling, these properties can be achieved by a wide variety of techniques. For instance, contract-based as well as component-based approaches represent techniques favoring the mentioned trans- parency and therefore have positive effects on the testability of the system.
Contract-Based Design reduces the complexity of a SUD by clearly exposing inter- faces of (sub-)systems and defining their interaction in form of contracts avoiding hid- den links and emergent effects. Sangiovanni-Vincentelli et al. refer to a horizontal reduction of complexity, whereas the structuring of the model represents a vertical re- duction of complexity [153]. In the context of our Omni Model approach, the Integra- tion Model explicitly defines a property element to specify contract information for the respective System Model parts.
Component-Based Design and Patterns have positive effects on the testability of the SUD, since especially the integration levels are explicitly expressed by the model arti- facts. Having a possible state space explosion in mind, Groote et al. have formulated some guidelines with positive effects on the testability of the system [81]. In partic- ular, guidelinesIII, VI, and VII explicitly address transparency concerning external behavior, the combination of components, and their interaction.
A mapping of classical design patterns from object-oriented software development promises a positive effect in the context of MDSD. For example, a strict application of structural patterns in the sense of theFacadepattern results in highly structured mod- els, which in turn enables fine-grained integration levels. Behavioral patterns such as the Strategy pattern further promote the definition of explicit interfaces of functional components and thus improve their testability. [72]