In this section, we present a set of supervised work in the context of this thesis, which means that the topics, as well as the major conceptual decisions, were developed by the
author of this doctoral thesis. In order to point out the role in the context of my thesis, each of the supervised work items is introduced by a brief summarizing paragraph.
Finally, we directly address the related sections of the thesis.
Funktionale Absicherung auf dem Weg zum autonomen Fahren am Beispiel eines Autobahnpiloten[59]
Summary:The master thesis elaborated a holistic concept for functional safety analyses in the context of automotive driver assistance systems. Again, the foundations in the ar- eas of automotive development methodologies, safety-related analysis methodologies, as well as hardware-specific safety concerns were presented. The conceptual work on the structured analysis of a automotive assistance system on the basis of a functional as well as a technical safety concept revealed potential for future research in the area of integrated analysis of so far disjoint domains. Finally, a recent case study from the automotive industrial context gave evidence for the adequacy of the work done.
Related Parts in Thesis:Chapter 7 show case for a model artifact which may participate in the Omni Model (fault modeling)
Abstract Execution of Graph-Based Test Descriptions in Model-Driven Software Development[118]
Summary: Due to the economical need to detect errors in software development pro- cesses as quickly as possible, the master thesis worked on testing in early stages of model driven software development. In this thesis, a novel approach for abstract exe- cution of test descriptions was presented and prototypically implemented in the archi- tecture and analysis framework. Instead of processing contained instructions, the ab- stract structure of model artifacts is brought to execution. By comparing model graphs of system and test, structural differences can be identified that indicate discrepancies between actual behavior and intended behavior of the System Under Test (SUT). These indicators can be processed and classified to give the tester feedback for early test set assessment and an indication for potential problems.
Related Parts in Thesis:chapter 10, section 10.2.1
Datenfluss-basierte abstrakte Testausführung in der Modell-basierten Softwareentwicklung[131]
Summary: Continuing the work on the problem domain of the work about “Abstract Execution of Graph-Based Test Descriptions in Model-Driven Software Development”, this master thesis elaborates an approach taking into account the data flow of system
and test models. Based on integrated sets of system and test model artifacts a method- ology for the systematic evaluation of abstract test case specifications has been devel- oped. A combined view on the graph-based specifications of data flow allows us to draw conclusions about the discrepancies between the modeled system and its respec- tive test model. Along an industrial case study from the automotive domain, a proof of concept as well as the potential for future applications has been illustrated.
Related Parts in Thesis: Chapter 10, Section 10.2.2
Model-to-Model Transformationen im Kontext modell-basierter Software- und System-Analysen[101]
Summary: In this thesis, model transformations in the context of model-based soft- ware and system analyses were investigated. The focus was on the Systems Modeling Language (SYSML) which was integrated into the A3F within the scope of the work.
In particular, model transformations for the internal analysis-specific metamodels were realized. Starting from a modeling tool specific input representation, the first trans- formation towards an internal and simplified version of the SYSML metamodel were conducted. In a second step, the simplified SYSML model was transformed to the inter- nal analysis-specific version, which is used to elaborate structure as well as data related aspects of the system model. The developed functionality was examined alongside a running example, namely the Ceiling Speed Monitor (CSM), from a former research group. A final discussion about the newly integrated concepts closes the conducted work.
Related Parts in Thesis: Chapter 7, Section 7.3, Chapter 10
Model-to-Model Transformationen zur Adaption Modellzentrischer Testmechanismen am Beispiel U2TP[102]
Summary: Model-based testing provides an approach to extend the test process of a system with models. In this context, the Object Management Group (OMG) defines the modeling language UML Testing Profile 2 (UTP2) which is used for describing and vi- sualizing test artifacts. This thesis gives an overview of model-based testing, metamod- eling and model transformations with a special focus on the OMG standards. After a short introduction of the Eclipse Modeling Framework and the UTP2, three metamod- els are presented. Based on these metamodels, two model-to-model transformations are proposed, which convert a UTP2-conform visual model to a model used for further analysis. The thesis concludes with possible concepts to extend the metamodels and model transformations.
Related Parts in Thesis: Chapter 7, Section 7.3, Chapter 10
3
Outline
In this section, an overview of the contents of this thesis is given. The general structure and coherence of the parent chapters can be seen in figure 3.1.
In the first part of the thesis (part I) first, a motivation for the topic is given, the problem as well as the research questions/objectives are presented, and finally relevant research projects and works are discussed.
In the second part of the thesis (part II), the necessary foundations for the concepts pre- sented in the main part are explained. First, general concepts and terms from the mod- eling environment are discussed (chapter 4). Furthermore, some central approaches of verification and validation of systems are shown (chapter 5), whereby the focus is on testing (section 5.1) considering the interaction with the modeling world (section 5.2).
The third part represents the main part of the thesis, with the components and funda- mentals of the MCSTLC (part III). Thus, an overview of the developed concept and its components is given (chapter 6), before a running example is introduced, used through- out the thesis to illustrate the concepts (section 6.2). Thus, as the first substantive part of the MCSTLC, the model basis and the concept of linking different modeling domains are discussed (chapter 7). On the one hand, possible modeling languages, a representa- tive selection of modeling domains, and the metamodel used for information integra- tion are presented (section 7.1). On the other hand, the internal model representation developed specifically for processing the available model information and the concepts for model transformation are explained (section 7.2). As a counterpart to the presented theoretical foundations of the MCSTLC, the prototypical realization is discussed in sec- tion 7.3. The final section presents related work, a summary, and an outlook (section 7.4 and section 7.5).
Building on the investigated fundamentals, the remaining chapters of the main part deal with the individual process steps and the concepts developed for this purpose.
In chapter 8, the concept for Test Case Management is presented at the model-level, starting with a classification in the overall process including necessary preconditions.
Afterward, in section 8.2, the algorithmic implementation is explained before the proto- typical realization is discussed (section 8.3). In section 8.4 research work in the context of the approach is elaborated before a summary including an outlook is given (sec- tion 8.5).
II. Foundations and Related Areas
V. Conclusions and Outlook IV. Applications and Evaluation
I. Motivation, Problem Statement, Objectives, Research Items
III. Towards a Model-Centric Software Testing Life Cycle The Omni Model Approach
Omni Model-Based Test Case Management
Adaptive and Efficient Model-Based Abstract Test Suite Generation
Omni Model-Based Abstract Test Execution
Omni Model-Based Mutation Analysis
Architecture And Analysis Framework
Figure 3.1: Overall structure of the thesis
Chapter 9 has an analogous structure, where the Test Case Generation based on the presented Omni Model is considered. As an introduction, the context and necessary preconditions of the approach are discussed (section 9.1). After the comprehensive introduction of the concept in section 9.2, section 9.3 deals with the implementation in the context of the prototypical Architecture And Analysis Framework. This section concludes with a review of related approaches in section 9.4, as well as a summary and outlook for further topics in this area (section 9.5).
In the context of chapter 10, our concept for Abstract Test Execution is presented. After the introductory part has dealt with the boundary conditions (section 10.1), the pre- sentation of the concepts defines two different approaches to the problem. On the one hand, in section 10.2.1 a concept is presented that works on structural information and is thus suitable for the early stages of development. On the other hand, section 10.2.2 presents a data flow-based concept that processes more detailed information in addi- tion to structural information and is thus designed for advanced phases of model-based development. Further on, the implementation of the two concepts in A3F is discussed (section 10.3), before concluding again with alternative approaches (section 10.4).
The last chapter of the main part represents the concepts for Mutation Analysis (chap- ter 11). First, as in all sections of the main part, the embedding of the process step in the context of MCSTLC is presented and the interfaces are discussed (section 11.1). In the course of section 11.2, the implementation of Mutation Analysis in the given modeling
concepts including an outlook on further topics is given, section 11.4 highlights similar research projects.
The following part IV comprehensively presents and evaluates some application sce- narios of the MCSTLC based on an Omni Model. First, the case studies considered are discussed and how they are realized in the context of the Omni Model (chapter 12). In the following chapters, the individual process steps are first evaluated separately with respect to the presented functional scope (section 13.1 to section 13.4, before the entire MCSTLC is evaluated again in chapter 14.
In part V, a summary of the presented components of the approach is drawn, which is supplemented by future application scenarios in the overall context.
FOUNDATIONS AND RELATED
AREAS
4
Model-Driven Software Development
MDSD represents a style of software development, which is an alternative to classi- cal development by incrementally transforming specifications to code. Here, models represent major artifacts during development. Depending on the type of MDSD ap- proach, however, the role of the models varies considerably. Brown et al. draw the scale from models for more intuitive visualization of code to model-only MDSD se- tups, where modeling fully replaces classical code-based engineering [33]. A central aspect here is the shift in focus from code-based development of the SUD to develop- ment in the modeling tool, which consequently generates the application code. This change to a modeling notation increases the level of abstraction, which ultimately im- proves productivity due to better understandability and the automation of error-prone steps [155]. However, one should always have in mind the fundamental characteristics of models identified by Stachowiak. [159]
• A model is a mapping from a concrete original to an abstract format
• A model serves a context-specific purpose
• A model represents a simplification, by omitting irrelevant information for the current context
Through different uses of models in MDSD, a number of variants have emerged, which differ in their varying degrees of a strict interpretation of the original idea. The weakest interpretation of the MDSD idea is represented by Model-Based Software Development (MBSD), whereby the models are used as a basis for discussion or for visual support of specification documents. However, the application code is still derived manually from the specification. [37]
Today’s use of MDSD in the context of the modeling community corresponds in large parts to the original idea of this development approach. Models replace parts of the classical specification and are used for automated processing. However, model-driven approaches are limited to a specific aspect of development, such as testing. Often, the two concepts MBSD and MDSD are not distinguished clearly. [37]
The strictest interpretation of the original MDSD idea is the Model-Centric Software De- velopment (MCSD). Here, the model artifacts created during development are regarded as the central knowledge base and are linked across the various aspects of development.
Furthermore, knowledge gained during development or an automated processing step is usually reflected back into the model(s). [29]
This results in different characteristics of how modeling is used in the development process. Either in sense of visualization of design and architecture decisions or for the purpose of automated translation towards the target platform. Depending on this, the requirements on syntax and semantics as well as the modeling domain guide the de- cision process on which modeling language fits best. The application domain often decides whether a Domain-Specific Modeling Language (DSML) or a General Purpose Modeling Language (GPML) is used. While DSMLs have limited expressiveness and a strong focus on the particular domain, GPMLs offer a great range of customization op- tions and are widely known [68]. For example, the Unified Modeling Language (UML) is often applied in semi-formal development contexts because of its popularity.
4.1 Meta-Object Facility
Being able to specify a modeling language, the Metamodel (MM) is essential. Clark et al. [44] gives the following definition.
Definition 1(Metamodel)
A metamodel is a model of a language that captures its essential properties and features. These include the language concepts it supports, its textual and/or graphical syntax, and its semantics (what the models and programs written in the language mean and how they behave).
Extending the idea of a MM, the Meta Object Facility (MOF) standard developed by the OMG tries to establish a common modeling layer above different languages, the Metametamodel (MMM). Among others, UML plays a central role, since its modeling concepts are partially used in the context of the MOF MM definitions. The specification bases on a layered architecture which further impacts the field of transformations be- tween different MMs, defined in conformity with the MOF, by Model-to-Model Trans- formations (M2MTs) (see section 4.2). [129]
The number of layers depends on the problem domain, but usually, four layers are defined. Figure 4.1 shows the subdivision of a MOF-compliant specification into four layers, with the UML and Interface Definition Language (IDL) being placed in the lay- ers here as examples.
M3is the highest level of the hierarchy and contains the MOF MM. This MM defines the selection of modeling elements for the next lower level. I.e. all MM components of anM2model represent instances of the MOF MM elements at theM3level. As shown in the figure, the components of the MMs of the UML and IDL represent instances of the MOF MM.
The same applies to the lower levels. For example, the model artifacts on theM1level conform to the respective language definition given on the M2 level. Again talking about the UML example, the models specify the parts of a concrete SUD. Consequently,
Meta Object Facility (MOF)
UML Models
UML Model Instances M3 Level
(Meta-Metamodel)
M2 Level (Metamodel)
M1 Level (Model)
M0 Level (Instance)
Unified Modeling Language (UML) Metamodel
Interface Definition Language (IDL) Metamodel
IDL Models
IDL Model Instances
Figure 4.1: Hierarchy of metamodeling in MOF
the artifacts on the lowest level of the hierarchy, namely the M0level, represent the objects or instances of the SUD at runtime.
Altogether, the MOF standard and its layer model provide a uniform basis for the defi- nition of modeling languages. Depending on the application, only a subset of the MOF, the so-called Essential MOF (EMOF), can be used for the specification of MMs. How- ever, if the entire language scope is required, it is usually referred to as the Complete MOF (CMOF).