Tom Ritter

Model-based Toolchain for the Efficient Development of Safety-Relevant Automotive Embedded Systems

Advanced functionalities unthinkable a few decades ago are now being introduced into automotive vehicles through embedded systems for reasons like emission control, vehicle connectivity, safety and ...

Model-based testing in legacy software modernization: an experience report

With the advent of cloud computing more and more vendors strive to modernize legacy applications and deploy them into the cloud. In particular when the legacy system is still applied in the field, the vendor must ensure a seamless change to the modernized system to not lose any economical assets and to keep the business running. As with normal development processes, testing is also inevitable for a modernization process to gain confidence that the modernized system behaves correctly. This paper describes an experience report from the FP 7 research project REMICS that deals with model-driven modernization of legacy systems to the cloud. We employed a model-based testing process for safeguarding the correct migration of the modernized system’s functionality. As test modeling language, the UML Testing Profile was applied. The modernized system, called DOME, was one of the case studies contributed by one of the business partners of the project.

Integrating security policies via Container Portable Interceptors

Enforcing appropriate security policies in distributed, component-based applications is difficult. A generic framework to define and evaluate security policies is necessary, and that framework must be integrated with the middleware platform. The middleware must provide the necessary hooks to intercept calls and obtain the information required for security enforcement. We designed and developed a security framework, integrated it into the CORBA component model middleware platform, and evaluated it in a real-world project

Advanced Software Engineering

Software rules them all! In every industry now, software plays a dominant role in technical and business innovations, in improving functional safety, and also for increasing convenience. Nevertheless, software is not always designed, (re)developed, and/or secured with the necessary professionalism, and there are unnecessary interruptions in the development, maintenance, and operating chains that adversely affect reliable, secure, powerful, and trustworthy systems. Current surveys such as the annual World Quality Report put it bluntly, directly correlated with the now well-known failures of large-scale, important and/or safetycritical infrastructures caused by software. It is thus high time that software development be left to the experts and that space be created for the use of current methods and technologies. The present article sheds light on current and future software engineering approaches that can also and especially be found in the Fraunhofer portfolio.

Modelling Foundations and Applications

MBE (Model-Based Engineering) proposes to develop software by taking advantage of models, in contrast to traditional code-centric development approaches. If models play a central role in development, model properties must be formulated and checked early on the modeling level, not late on the implementation level. We discuss how to validate and verify model properties in the context of modeling languages like the UML (Unified Modeling Language) combined with textual restrictions formulated in the OCL (Object Constraint Language). Typical modeling and transformation languages like UML (Unified Modeling Language), EMF (Eclipse Modeling Framework), QVT (Queries, Views, and Transformations) or ATL (Atlan Transformation Language) are complemented by the textual OCL (Object Constraint Language) enriching graphical or textual models with necessary details. Models allow the developer to formulate essential system properties in an implementationand platform-independent way. Precise object-oriented development must take into account system structure and system behavior. The system structure is often captured by class diagrams and can be instantiated in terms of prototypical exemplars by object diagrams. The system behavior can be determined by statechart diagrams, and system execution traces can be demonstrated by sequence diagrams. OCL restricts the possible system states and transitions through the use of class invariants, operation preand postconditions, state invariants, and transition preand postconditions. OCL can also be used during model development as a query language. Modeling features and their analysis through validation and verification must be supported by tools like, for example, the tool USE (UML-based Specification Environment) [1]. Within USE, UML class, object, statechart, and sequence diagrams extended with OCL are available [2]. OCL has been extended with programming language features in SOIL (Simple Ocl-like Imperative Language) which allows the developer to build operation realizations on the modeling level without having to dig into implementation level details [3]. Thus models in USE are executable, but a prescriptive SOIL model for operations can be checked against descriptive plain OCL preand postconditions. Tools like USE assist the developer in order to validate and to verify model characteristics. Validation and verification can be realized, in USE for example, by employing a so-called model validator based on relational logic and SMT P. Van Gorp, T. Ritter, and L.M. Rose (Eds.): ECMFA 2013, LNCS 7949, pp. 1–2, 2013. c

Installation von Qedo

Vor der eigentlichen Entwicklung von CORBA-Komponenten mit Qedo steht die Installation des Qedo-Pakets selbst. Qedo wurde unter einer speziellen freien Benutzungslizenz veroffentlicht, der GNU General Public License. Dadurch sind die Quellen von Qedo fur jedermann erhaltlich und unter Umstanden an die eigenen Anforderungen anpassbar. Das folgende Kapitel diskutiert, wie man die Quellen von Qedo beziehen kann, welche Abhangigkeiten der Qedo-Software von fremden Softwarepaketen existieren und wie die Installation von Qedo zu erfolgen hat.

Ein Beispiel mit Qedo

Nachdem die Qedo-Laufzeitumgebung und das Generatorwerkzeug installiert sind, kann man daran gehen, eigene Komponenten zu entwickeln. Das folgende Kapitel erlautert die Entwicklung eines konkreten Beispiels und den Umgang mit dem Qedo-Codegenerator. Hierbei wird sich auf die Entwicklung unter Windows bezogen. Das Vorgehen unter Linux sieht genauso aus und unterscheidet sich nur in der Benutzung von generierten Makefiles statt der generierten Visual-Studio-.NET-Projekte.

Rollen und Entwicklungsprozesse

Komponentenorientierte Softwareentwicklung hilft bei der Entkopplung der verschiedenen Stufen des Softwareentwicklungsprozesses. Aus der bisherigen Diskussion des CORBA-Komponentenmodells ist ersichtlich, dass von der Spezifikation bis zum tatsachlichen Einsatz einer CORBA-Komponente als Teil einer Anwendung eine Vielzahl von Aufgaben im Entwicklungs- und Installationsprozess wahrzunehmen ist. Da die verschiedenen Aufgaben exakt voneinander trennbar sind, wurden im CORBA-Komponentenmodell so genannte Rollen definiert. Eine Rolle beschreibt eine spezifische Aufgabe im Softwareentwicklunsprozess mit CORBA-Komponenten. Diese Rollen sind relativ unabhangig voneinander und konnen von verschiedenen Personen verkorpert werden. Beim Prozess der Entwicklung von komponentenbasierten Anwendungen beginnend mit der Idee fur eine Komponente bis hin zur fertig installierten und konfigurierten Anwendung, nehmen die einzelnen Rollen unterschiedliche Aufgaben wahr. Das folgende Kapitel stellt sowohl diese Rollen als auch die mit Hilfe dieser Rollen formulierbaren Entwicklungsprozesse fur Komponenten und Anwendungen auf Basis des CORBA-Komponentenmodells vor.

Infrastruktur für die Inbetriebnahme

Komponentenbasierte Anwendungen liegen wie gezeigt in Form von Komponentenarchiven vor, die potentiell in verschiedensten Umgebungen eingesetzt werden konnen und auf deren Grundlage die Inbetriebnahme der Anwendung erfolgt. Diese Inbetriebnahme und der anschliesende Einsatz erfordern die Verfugbarkeit einer standardisierten Infrastruktur seitens der Komponentenplattform. Ohne entsprechende Interfaces ist es unmoglich, die in den Archiven enthaltenen Implementierungen auf ihren Zielrechnern zu installieren und die Struktur der Anwendung durch die Erzeugung und Verbindung von Komponenteninstanzen nachzubilden. Nur uber die Interfaces der Komponentenplattform kann auf die Funktionalitat der Plattform zugegriffen werden, die die Installation, die Instantiierung und die Verwaltung von Komponenten beziehungsweise komponentenbasierten Anwendungen umfasst. Diese Interfaces werden im folgenden Abschnitt vorgestellt und naher betrachtet.

Design der Implementierung

In Kapitel 8 wurde das Design von Komponententypen mit ihren auseren Strukturmerkmalen erklart. Nachdem ein Komponententyp spezifiziert wurde, kann er auf unterschiedliche Art und Weise implementiert werden. Bevor jedoch die eigentliche Implementierungsarbeit beginnt, muss ein Implementierungsdesign erstellt werden. Freiheiten beim Implementierungsdesign ergeben sich vor allem aus der Aufteilung der Implementierungen fur die verschiedenen strukturellen Merkmale der Komponente auf programmiersprachliche Artefakte. Durch den Einsatz entsprechender Softwarewerkzeuge kann aus dem Implementierungsdesign ein groser Teil des fur die Komponentenimplementierung benotigten Programmcodes generiert werden.