Modellbasierte Softwareentwicklung für eingebettete Systeme verstehen und anwenden E-Book

Tim Weilkiens

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2018

Seitenzahl: 408

Beschreibung

Die Beherrschung von Komplexität ist eine der größten Engineering-Herausforderungen des 21. Jahrhunderts. Themen wie das "Internet der Dinge" (IoT) und "Industrie 4.0" beschleunigen diesen Trend. Die modellgetriebene Entwicklung leistet einen entscheidenden Beitrag, um diesen Herausforderungen erfolgreich begegnen zu können.  Die Autoren geben einen fundierten Einstieg und praxisorientierten Überblick über die Modellierung von Software für eingebettete Systeme von den Anforderungen über die Architektur bis zum Design, der Codegenerierung und dem Testen. Für jede Phase werden Paradigmen, Methoden, Techniken und Werkzeuge beschrieben und ihre praktische Anwendung in den Vordergrund gestellt. Darüber hinaus wird auf die Integration von Werkzeugen, funktionale Sicherheit und Metamodellierung eingegangen sowie die Einführung eines modellbasierten Ansatzes in einer Organisation und die Notwendigkeit zum lebenslangen Lernen erläutert. Der Leser erfährt in diesem Buch, wie ein modellbasiertes Vorgehen nutzbringend in der Praxis für die Softwareentwicklung eingesetzt wird. Das Vorgehen wird unabhängig von Modellierungswerkzeugen vorgestellt. Zahlreiche Beispiele – exemplarisch auch auf Basis konkreter Werkzeuge – helfen bei der praktischen Umsetzung. Der Anhang bietet ausgehend von den Thesen des Manifests "Modeling of Embedded Systems" eine Skizze eines Reifegradmodells für modellbasierte Softwareentwicklung, eine Kurzreferenz zu UML und SysML sowie ein Glossar. Auf der Buch-Website mdese.de finden sich Werkzeuge, Beispiele, Tutorials sowie weitere vertiefende Informationen zum Thema.

Leseprobe

Bild: v.l.n.r. Andreas Willert, Alexander Huwaldt, Stephan Roth, Tim Weilkiens und Jürgen Mottok

Tim Weilkiens ist Vorstand und Trainer der oose Innovative Informatik eG. Seine thematischen Schwerpunkte sind die Modellierung von Systemen, Software und Unternehmen. Er ist für oose Repräsentant bei der OMG und u.a. Koentwickler des Zertifizierungsprogramms OCEB und OCEB2.

Alexander Huwaldt ist Geschäftsführer der SiSy Solutions GmbH, seit 2007 als UML Professional nach OMG-Standards zertifiziert und in der Softwareentwicklung tätig. Er ist Hochschuldozent für Mikrocontrollerprogrammierung, Software Engineering, UML, SysML und BPMN.

Prof. Dr. Jürgen Mottok lehrt Informatik an der Hochschule Regensburg. Seine Lehrgebiete sind Embedded Software Engineering, Real-Time Systems, Functional Safety und IT-Security. Er ist in Programmkomitees zahlreicher wiss. Konferenzen vertreten.

Stephan Roth ist Trainer und Berater bei der oose Innovative Informatik eG. Seine Schwerpunkte sind modellbasiertes Systems und Software Engineering, Softwaredesign und Softwarearchitektur sowie Software Craftsmanship und Clean Code Development.

Andreas Willert ist Geschäftsführer der Willert Software Tools GmbH und als Trainer, Berater und Coach für Software und Systems Engineering tätig.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Tim Weilkiens • Alexander Huwaldt • Jürgen Mottok • Stephan Roth • Andreas Willert

Modellbasierte Softwareentwicklung für eingebettete Systeme verstehen und anwenden

Tim Weilkiens

[email protected]

Alexander [email protected]

Jürgen [email protected]

Stephan [email protected]

Andreas [email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Frank Heidt

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print978-3-86490-524-7

PDF978-3-96088-593-1

ePub978-3-96088-594-8

mobi978-3-96088-595-5

1. Auflage 2018

Copyright © 2018 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

»Grau, teurer Freund, ist alle Theorieund grün des Lebens goldner Baum.«

Faust – Der Tragödie erster Teil(Johann Wolfgang von Goethe, 1749 – 1832)

Wir, die Autoren dieses Buches, sind überzeugt davon, dass die Modellierung von eingebetteten Systemen zu erfolgreichen Projekten führt und viele Probleme, die wir in Projekten beobachten, lösen kann. Gleichzeitig sehen wir, dass Modellierung häufig nicht oder ungünstig eingesetzt wird. Vor etlichen Jahren haben wir uns vorgenommen, dem entgegenzuwirken. Aus dem Impuls heraus ist das Manifest »Modeling of Embedded Systems« (www.mdse-manifest.org) sowie die nicht kommerzielle Konferenz »Modeling of Embedded Systems Conference« (MESCONF, www.mesconf.de) entstanden.

Schnell waren wir uns einig, dass wir unser Wissen und unsere Erfahrung in einem Referenzwerk zu Verfügung stellen wollen. Wir haben aus unserer langjährigen Projekterfahrung mit kleinen, mittleren und großen Projekten in diesem Buch wesentliche Aspekte der methodischen und systematischen Anwendung von Konzepten, Methoden, Techniken und Werkzeugen des Software Engineering von eingebetteten Systemen zusammengefasst. Wir wenden uns damit an Leser, die bereits über Kenntnisse in der Softwareentwicklung und Programmierung verfügen.

Der Inhalt bezieht sich speziell auf den Entwurf und die Realisierung von Mikrocontrollerlösungen und orientiert sich damit an den Bedürfnissen der Entwicklung von eingebetteten Systemen. Wir erörtern somit wichtige Aspekte der Softwareseite des Embedded Systems Engineering.

In den Inhalt dieses Buches flossen ebenfalls die Anforderungen und Erfahrungen aus unserer Lehrtätigkeit an Berufsakademien, Fachhochschulen und Universitäten ein. Gerade hier liegt ein Spannungsfeld: Die Ausbildung von Informatikern über Elektrotechniker bis zu Mechatronikern wird mehr und mehr zur Herausforderung. Dem Informatiker wird viel Softwaretechnik in einer zunehmend von der Hardware abstrahierten Welt und faktisch keine Elektrotechnik vermittelt. Dem Elektrotechniker wird naturgemäß viel Wissen über Elektrotechnik und Elektronik mit auf den Weg gegeben, aber für die besonderen Belange der Softwareentwicklung, obwohl oft hardwarenah vermittelt, fehlt die Zeit zur notwendigen Vertiefung. Mechatroniker klagen sowieso über die ungeheure Stofffülle zwischen Mechanik, Hydraulik, Pneumatik, Elektrotechnik und Informatik.

Oft wird Software Engineering und die in diesem Diskurs angebotenen Techniken und Werkzeuge der Modellierung als nett, aber in dem Bedürfnis, endlich seine Ideen in Quellcode umzuwandeln, als hinderlich angesehen. Das »Rush to Code«-Syndrom ist weit verbreitet (und auch allzu menschlich). Gleichzeitig vertreten wir den Standpunkt, dass eine Technik nur dann von praktischem Nutzen ist, wenn die Arbeitsergebnisse des einen Schritts in geeigneter Form im nächsten Arbeitsschritt möglichst direkt weiterverwendet werden können und von geeigneten Werkzeugen unterstützt werden. Das wird in theoretischen Abhandlungen nicht erlebbar. Deshalb basieren dieses Buch und der Lernerfolg auf der praktischen Anwendung des Vorgestellten und einer konsequenten Werkzeugnutzung.

Wir haben das Buch gemeinschaftlich geschrieben und dazu viele spannende Workshops und Diskussionen durchgeführt. Obwohl es im Autorenteam unterschiedliche Schwerpunkte und Sichtweisen gibt, konnten wir mit diesem Buch die verschiedenen Puzzleteile zu einem gemeinsamen Bild zusammensetzen.

Wir sehen es als einen kontinuierlichen Prozess, die Methoden, Techniken und Werkzeuge immer weiterzuentwickeln, zu optimieren und an die sich stetig ändernde Welt anzupassen. Dieses Buch ist allerdings naturbedingt statisch. Zukünftige Auflagen werden diese Entwicklung widerspiegeln und Sie können dem Prozess beispielsweise auf der MESCONF oder anderen Veranstaltungen der Community folgen.

»Wir lernen, was wir tun.«John Dewey

Mai 2018

Tim WeilkiensAlexander HuwaldtJürgen MottokStephan RothAndreas Willert

Inhaltsübersicht

1Einleitung

2Basiswissen

3Modellbasierte Softwareprozesse und Toollandschaften

4Modellbasiertes Requirements Engineering

5Modellbasierte Architekturbeschreibung

6Modellbasiertes Softwaredesign

7Modellbasiertes Testen

8Integration von Werkzeugen

9Modellbasierte funktionale Sicherheit

10Metamodellierung

11Einführung eines modellbasierten Ansatzes in einer Organisation

12Lebenslanges Lernen

13Fazit

Anhang

AAusblick: Skizze eines Reifegradmodells für MDSE

BKurzreferenz UML und SysML

CGlossar

DLiteraturverzeichnis

Stichwortverzeichnis

Inhaltsverzeichnis

1Einleitung

1.1Warum gerade jetzt dieses Buch?

1.2Wie sollte man dieses Buch lesen?

1.3Was ist an eingebetteten Systemen so besonders?

1.4Wie sieht das typische Zielsystem aus?

1.5Fallbeispiele

1.5.1Die Anlagensteuerung

1.5.2Die Baumaschine

1.5.3Das Energie-Monitoring-System

1.5.4Das Beispielsystem SimLine

1.6Das Manifest

2Basiswissen

2.1Was sind eingebettete Systeme?

2.2Software Engineering für eingebettete Systeme

2.3Der Qualitätsbegriff

2.3.1Externe Qualität

2.3.2Interne Qualität

2.3.3Qualitätskriterien nach ISO/IEC 25010

2.4Einführung in Model-Driven Software Engineering

2.5Komplexität

2.6Unser Gehirn als Engpass

2.7Vorgehensweisen und Techniken, um einer steigenden Komplexität zu begegnen

2.8Komplexen Systemen lässt sich nicht mit simplen Methoden begegnen

2.9Verstehbarkeit und Redundanz

2.10Was ist ein Modell?

2.11Modelle helfen, die Zukunft vorwegzunehmen?

2.12Modelle helfen zu abstrahieren?

2.13Resümee: Nutzen von MDSE?

3Modellbasierte Softwareprozesse und Toollandschaften

3.1Klassifikation von Modellierungswerkzeugen

3.1.1Modellierungswerkzeuge der Kategorie A (universelle Malwerkzeuge)

3.1.2Modellierungswerkzeuge der Kategorie B (spezialisierte Malwerkzeuge)

3.1.3Modellierungswerkzeuge der Kategorie C (einfache Modellierungswerkzeuge mit Modelldatenbank)

3.1.4Modellierungswerkzeuge der Kategorie D (vollständiger Zyklus einer Embedded-Software-Engineering-Werkzeugkette)

3.2Vorgehensmodelle

3.2.1SYSMOD Zickzack trifft auf IBM Rational Harmony

3.2.2Spezifikation oder Lösung?

3.2.3Wiederverwendung

3.3Best Practice für kleine Teams

4Modellbasiertes Requirements Engineering

4.1Requirements Engineering

4.2Anforderungen in der Modellierung

4.3Anforderungen und Architektur im Zickzack

4.4Szenario: Modellbasierte Spezifikation mit UML erstellen

4.4.1Überblick über Methode

4.4.2Problemanalyse

4.4.3Basisarchitektur

4.4.4Systemidee und Systemziele

4.4.5Stakeholder und Anforderungen

4.4.6Systemkontext

4.4.7Anwendungsfälle und Aktivitäten

4.4.8Fachwissen

4.4.9Szenarien

4.5Mehr Modellierung: Ausführbare Spezifikation

4.6Weniger Modellierung: Diagramme für Anforderungsdokumente

4.7Neuentwicklung versus Weiterentwicklung

4.7.1Basisarchitektur

4.7.2Anwendungsfälle

4.7.3Szenarien

5Modellbasierte Architekturbeschreibung

5.1Architektur – Was ist das eigentlich?

5.2Die technische Softwarearchitektur

5.3Architekturmuster und deren Bedeutung

5.4Das Laufzeitsystem als Basismuster in eingebetteten Applikationen

5.5Referenzmuster für eine Laufzeitarchitektur

5.5.1Sensorik, Einlesen, Filtern, Bewerten

5.5.2Transformation der Sensorik in Aktivitäten (Verarbeitung)

5.5.3Ausgabe der Daten und Ansteuerung der Aktoren

5.6Fachliche Architektur

5.7Architektur-Assessment

6Modellbasiertes Softwaredesign

6.1Gesichtspunkte der fachlichen Architektur und des Designs

6.2Hierarchische Dekomposition

6.3Diskretisierungs- und Laufzeiteffekte im Design

6.4Softwaredesignprinzipien

6.4.1Was ist ein Prinzip?

6.4.2Grundlegende Designprinzipien

6.4.3Designprinzipien in der Modellierung

6.5Hardwareabstraktion

6.5.1Ausgangssituation

6.5.2Evolution der Mikrocontrollerprogrammierung in C

6.5.3Die klassische Vorgehensweise mit der UML

6.5.4Die graue Theorie

6.5.5Lösungsansätze für die Modellierung

6.5.6Lösungsansätze für die Codegenerierung

7Modellbasiertes Testen

7.1Warum eigentlich testen?

7.2Nicht nur sicherstellen, dass es funktioniert

7.2.1Ein angstfreies Refactoring ermöglichen

7.2.2Besseres Softwaredesign

7.2.3Ausführbare Dokumentation

7.2.4Tests helfen, Entwicklungskosten zu sparen

7.3Die Testpyramide

7.4Test-Driven Development (TDD)

7.4.1Viel älter als vermutet: Test First!

7.4.2TDD: Red – Green – Refactor

7.5Model-Based Testing (MBT)

7.6UML Testing Profile (UTP)

7.7Ein praktisches Beispiel

7.8Werkzeuge, die dieses Vorgehen unterstützen

8Integration von Werkzeugen

8.1Anforderungen an Schnittstellen zu Werkzeugen unterschiedlicher Disziplinen

8.1.1Digital Twin

8.1.2Traceability aus Safety-Gesichtspunkten

8.1.3Projekt- und Workload-Management

8.2Synchronisation der Daten zwischen Repositories

8.3Zentrales Repository

8.4Ein Werkzeug für alles

8.5OSLC – Open Services for Lifecycle Collaboration

8.6XMI – Austausch von Daten innerhalb der Fachdomäne MDSE

8.7ReqIF zum Austausch von Anforderungen

8.8FMI (Functional Mock-up Interface)

8.9SysML Extension for Physical Interaction and Signal Flow Simulation (SysPhS)

8.10AUTOSAR

8.11Stand der Praxis

9Modellbasierte funktionale Sicherheit

9.1Funktionale Sicherheit

9.2Entwurfsmuster der funktionalen Sicherheit

9.2.1Zufällige und systematische Fehler

9.2.2Symmetrische und diversitäre Redundanz

9.2.3Architekturmuster

9.2.4Monitor-Actuator Pattern (MAP)

9.2.5Homogenous Redundancy Pattern (HRP)

9.2.6Triple Modular Redundancy Pattern (TMR)

9.2.7SIL-Empfehlung für die Safety and Reliability Design Patterns

9.3Vom Modell zum sicheren Quellcode: Coding-Standards für die sichere Programmierung

9.3.1Normativer Hintergrund

9.3.2MISRA-C und MISRA-C++

9.3.3Prüfwerkzeuge

9.3.4Codegenerierung

9.4Das Safety and Reliability Profile der UML

9.5Praktische Anwendung der Modellierung im Kontext sicherheitskritischer Systeme

9.5.1Beweis der Korrektheit der Transformation

9.5.2Verifikation der Qualität des Werkzeugs

9.5.3Zertifiziertes Framework

9.6Vorteile der modellgetriebenen Entwicklung im Safety-Kontext

9.6.1Traceability

9.6.2Semiformale Spezifikation

9.6.3Normen empfehlen den Einsatz von formalen und/oder semiformalen Methoden und Notationen

9.6.4Automatisierte Transformationen

9.6.5Modellierungsrichtlinien (Guidelines)

9.6.6Dokumentation

9.7Modellgetriebene Entwicklung mit der UML

10Metamodellierung

10.1Modell und Metamodell

10.2UML-Metamodelle

10.3EAST-ADL

10.4AADL

10.5Vergleich EAST-ADL und AADL

11Einführung eines modellbasierten Ansatzes in einer Organisation

11.1Ausgangslage

11.2Vorgehen

11.2.1Problem analysieren

11.2.2Idee und Ziele des Vorgehens

11.2.3Stakeholder und Anforderungen

11.2.4Methodikkontext

11.2.5Anwendungsfälle

11.2.6Fachwissenmodell

11.2.7Verifikation und Validierung

11.3Auswahl der Modellierungssprachen

11.4Auswahl der Modellierungswerkzeuge

11.5Typische Fehler

11.5.1Schnellstart

11.5.2Übergewicht

11.5.3Einsame Insel

11.5.4Elfenbeinturm

11.5.5Aus der Lernkurve fliegen

12Lebenslanges Lernen

12.1Lernen – die Sicht des Konstruktivismus

12.2Kompetenzen – der Blick auf die modellbasierte Softwareentwicklung

12.3Agilität – Lernen mit Methoden und Praktiken

12.4Psychologische Grundlagen von Fehlern

12.4.1Denkfallen als Fehlerursache

12.5Software Craftsmanship – ein Beispiel

12.6Modellierungskultur – ein Kodex

12.6.1Manifest – Modeling of Embedded Systems

12.6.2Big Picture – der Blick auf den Kodex einer Modellierungskultur

12.6.3Moderation – die konstruktive Kommunikation

12.6.4Reflexion – Lernen durch Reflektieren

12.6.5Selbstverpflichtung – selbstgesteuertes Lernen als Entwickler und als Team

12.6.6Teamradar – ein Feedbackbarometer

12.6.7Experten als Teamcoach – Agenten der Veränderung

12.6.8Funktionale Sicherheit – ein Beitrag der normativen Sicherheitskultur

13Fazit

Anhang

AAusblick: Skizze eines Reifegradmodells für MDSE

A.1Hintergrund und Motivation

A.2Die Skizze als ein Start – Diskussionsforum

A.3Ausgangslage Manifest – Ziele kompakt

A.4Die Reifegrade – der Weg in die Modellierungskultur

A.5Evaluation und Fragenkatalog

BKurzreferenz UML und SysML

B.1Eine kurze Geschichte der UML

B.2Aufbau und Architektur der UML

B.3Anwendungsfalldiagramm

B.3.1Akteur

B.3.2Anwendungsfall

B.3.3Anwendungsfallbeziehungen

B.4Aktivitätsdiagramm

B.4.1Aktivität und Aktivitätsparameter

B.4.2Aktion und Pin

B.4.3Kontroll- und Objektfluss

B.4.4Start- und Endknoten

B.4.5Entscheidung und Zusammenführung

B.4.6Splitting und Synchronisation

B.5Klassendiagramm

B.5.1Klasse und Objekt

B.5.2Attribut

B.5.3Operation

B.5.4Assoziation

B.5.5Komposition

B.5.6Generalisierung

B.5.7Signal

B.5.8Datentyp

B.5.9Templates

B.6Kompositionsstrukturdiagramm

B.6.1Konnektor

B.6.2Port

B.7Sequenzdiagramm

B.7.1Interaktion

B.7.2Lebenslinie

B.7.3Nachricht

B.7.4Kombiniertes Fragment

B.7.5Zeitliche Zusicherungen

B.8Zustandsdiagramm

B.8.1Zustandsautomat

B.8.2Zustand

B.8.3Transition

B.8.4Start- und Endzustand

B.8.5Pseudozustand

B.9Paketdiagramm

B.9.1Paket und Modell

B.9.2Pakete importieren

B.9.3Modellbibliothek

B.10Querschnittselemente

B.10.1Kommentar

B.10.2Zusicherung

B.10.3Trace-Beziehung

B.11Profil

B.11.1SysML

B.11.2MARTE

B.11.3UML Testing Profile (UTP)

B.11.4MDESE-Profil (basierend auf SYSMOD-Profil)

CGlossar

DLiteraturverzeichnis

Stichwortverzeichnis

1Einleitung

»Aus kleinem Anfang entspringen alle Dinge.«

(Marcus Tullius Cicero, 106 – 43 v. Chr.,römischer Redner und Staatsmann)

1.1Warum gerade jetzt dieses Buch?

Die Beherrschung von Komplexität ist wohl die größte Engineering-Herausforderung des 21. Jahrhunderts. Software wird der Rohstoff sein, aus dem zukunftsfähige, smarte Systeme erschaffen werden. Software ist schon jetzt ein zentraler Bestandteil unserer Infrastruktur. Täglich kommen wir Menschen – mehr oder weniger bewusst – mit vielen Systemen in Kontakt, in denen Software zentrale Aufgaben übernimmt: Sei es der Fahrstuhl, die Klimaanlage, der Fahrkartenautomat oder das Auto.

Mit dem Internet der Dinge (Internet of Things, IoT) und der vierten industriellen Revolution, sprich: der Zukunftsvision »Industrie 4.0« der deutschen Bundesregierung, wird der Anteil und somit auch der Einfluss von Software auf alle Lebensbereiche des Menschen noch weiter zunehmen.

So wie die Metallverarbeitung eine Schlüsseltechnologie in der industriellen Revolution war, wird Software und Systems Engineering die Schlüsseltechnologie des Informationszeitalters sein.

Im Kontext von Embedded Systems werden sich obige Anforderungen besonders auswirken und modellgetriebene Entwicklung wird hier eine zentrale Rolle im Software und Systems Engineering für eingebettete Systeme einnehmen.

Eingebettete Systeme unterliegen wie jedes IT-System ständigen Innovationen. Moore's Law lässt grüßen. Es gibt jedoch innerhalb der Genesis solcher Systeme immer wieder Umwälzungen, die der scheinbar stetigen Entwicklung sprunghaften Charakter verleihen. Für den Betrachter scheint sich innerhalb kurzer Zeit alles zu ändern. Neue Programmiersprachen, mit denen die Entwickler konfrontiert werden, sind nur die Spitze des Eisbergs. Schaut man aus der heutigen Perspektive auf das Themengebiet Software Engineering zurück (siehe Abb. 1–1), kann die Entwicklung auf drei Umbrüche verdichtet werden.

Abb. 1–1Entwicklung von Software-Engineering-Paradigmen

1950er- bis 1960er-Jahre:

Initialzustand, maschinennahe Programmierung, dominierende Programmiersprache ist Assembler und es gibt erste Hochsprachen, Programmierparadigma ist die Sprunganweisung, Visualisierung erfolgt mit Flussdiagrammen.

1970er-Jahre:

Paradigmenwechsel zur Strukturierung (Funktionsorientierung), dominierende Programmiersprachen verzichten weitestgehend auf die Sprunganweisung, z. B. Pascal und C, Modularisierung, Funktionsbausteine sind zustandslos, Software Engineering erlebt Blütezeit und wird von vielfältigen strukturierten Darstellungstechniken wie strukturierter Analyse (SA), strukturiertem Design (SD), Nassi-Schneiderman-Diagrammen usw. dominiert, definierte Softwareprozesse orientieren sich am Wasserfallmodell.

Ab 1990er-Jahre:

Paradigmenwechsel zur Objektorientierung, dominierende Programmiersprachen sind z. B. C++ und Java, Softwarebausteine besitzen Zustände, Software Engineering erlebt einen Vereinheitlichungsprozess der objektorientierten Darstellungstechniken zur Unified Modeling Language (UML), definierte Softwareprozesse orientieren sich am Spiralmodell und werden agil.

Dieser stark verdichtete historische Abriss zeigt, dass der zunehmende Komplexitätsgrad an ausgewählten Punkten zu Paradigmenwechseln geführt hat. Es stellt sich die Frage, ob sich das auf eingebettete Systeme übertragen lässt?

Schaut man sich die dominierende Programmiersprache für eingebettete Systeme an, so stellen wir fest, dass sich C seit geraumer Zeit durchgesetzt hat. Nur noch wenige ausgewählte Aufgabenstellungen werden in Assembler realisiert.

Offensichtlich folgte man hier dem Paradigmenwechsel zur Strukturierung. Es lässt sich sogar eine Kenngröße ausmachen, an der man diesen Wechsel festmachen kann. Es ist die Programmgröße für eingebettete Systeme, die Größe des Programmspeichers. Ab 1 bis 16 Kilobyte Programmgröße wird es zunehmend schwieriger, die Aufgabenstellung in Assembler zu lösen. C wurde, obwohl hungriger nach Ressourcen, die adäquatere Programmiersprache für eingebettete Systeme.

Oberhalb der 16 Kilobyte wird nicht mehr ernsthaft darüber diskutiert, das System in Maschinensprache zu programmieren. Für den Paradigmenwechsel zur Objektorientierung lässt sich ebenfalls diese Kennzahl heranziehen. Dieser wurde vollzogen, als die typische Programmgröße deutlich die 1-Megabyte-Grenze überschritten hatte. Spätestens ab 4 Megabyte Hauptspeicher waren alle Diskussionen, ob PC-Programme in C programmiert werden sollen, erledigt. Objektorientierte Programmiersprachen wie C++ und Java haben sich innerhalb kurzer Zeit, zwischen 1990 und 1995, durchgesetzt. Heute verfügen selbst kleine Mikrocontroller wie die ARM-Cortex-M-Familie über mehr als 1 Megabyte Programmspeicher.

1.2Wie sollte man dieses Buch lesen?

Das Buch spannt einen weiten Bogen über das Fachgebiet der Entwicklung eingebetteter Systeme. Die Modellierung ist die Klammer, die die einzelnen Aspekte zusammenhält. Um das Fachgebiet als Ganzes zu verstehen, sollte das Buch kursorisch gelesen werden. Dabei können Details einzelner Aspekte auch übersprungen werden. Die Abschnitte sind in sich so weit abgeschlossen, dass eine zwingende Reihenfolge für die Bearbeitung nicht vorliegt. Für ausgewählte Leser sind einzelne Abschnitte von besonderem Interesse. Diese sollten intensiver studiert werden. Dafür sind im Anhang wichtige Erklärungen zu finden. Für die praktische Anwendung des Gelernten bietet die Webseite zum Buch unter www.mdese.de Werkzeuge, Beispiele und Tutorials an.

Studenten lernen das Fachgebiet Stück für Stück im Überblick kennen und werden für wichtige Aspekte sensibilisiert, deren Inhalte im Studium zu vertiefen sind. Zusammenhänge einzelner Disziplinen werden verstanden und die Möglichkeiten modellgetriebener Technologien können abgeschätzt werden. Dieses Buch ist auch als Nachschlagewerk geeignet.

Entscheider vertiefen ihr Beurteilungsvermögen und werden in die Lage versetzt, moderne modellgetriebene Technologien zu analysieren sowie qualifiziert zu bewerten.

Projektleiter erhalten wichtige Impulse zur Einführung von Modellierungstechniken. Das Verständnis der vorgestellten Technologien ist die Voraussetzung für deren Anwendung. In Kombination mit gesammelter Projekterfahrung gelingt es, für zukünftige Projekte eine neue Synthese mit modellgetriebenen Technologien zu erarbeiten.

Softwareentwickler verstehen den gesamten Prozess der modellgetriebenen Entwicklung und werden in die Lage versetzt, die für sie relevanten Technologien zu beurteilen und anzuwenden. Besonders modellgetriebene Realisierung und Test werden im Detail verstanden.

Hardwareentwickler lernen die Arbeitstechniken der Softwareentwickler kennen und sind in der Lage, mit diesen eine gemeinsame Sprache zu finden.

1.3Was ist an eingebetteten Systemen so besonders?

Eingebettete Systeme haben im Vergleich zu konventionellen Computern, wie unseren Desktop-PCs oder unseren Notebooks, geringe Ressourcen an Speicher und Rechengeschwindigkeit. Es gibt vielfältige Hardwarearchitekturen von 4 bis 64 Bit. Die verfügbaren Systeme bieten Single- und Multicore sowie sehr unterschiedliche Softwarearchitekturen von Bare-Metal-Programmierung über Real-Time Operation Systems bis Multitask/Multiuser-Betriebssysteme an.

Abb. 1–2Programmieradapter und Zielsystem

Der sinnliche Zugang wird für den Neueinsteiger dadurch erschwert, dass diese eingebetteten Digitalrechner als solche meist nicht zu erkennen, also quasi »unsichtbar« sind. Sie verfügen oft weder über gebräuchliche Eingabegeräte wie Maus und Tastatur noch über grafische Displays. Ein Taster und wenige LEDs bilden in vielen Fällen die einzige Mensch-Maschine-Schnittstelle.

Daher erfordert es auch ein spezielles Equipment für die Programmierung. Der Einsteiger muss sich ein Programmiergerät und wenn möglich Debugger-Hardware für das Zielsystem zulegen.

Zusätzlich sind eine spezielle Entwicklungsumgebung und Compiler nötig, die die gewünschte Hardware auch unterstützen. Die verfügbare Literatur ist entweder proprietär auf die Hardware- und Softwarearchitektur sowie die Entwicklungsumgebung des Chipherstellers fokussiert oder so allgemein gehalten, dass die konkrete Anwendung des Gelernten nur schwer möglich ist.

Von der breit angewendeten Softwaretechnologie im Mikrorechnerbereich ist der Biotop der eingebetteten Systeme eher abgeschnitten.

Abb. 1–3Hallo Welt, zwei Welten

So viel zu den Schwierigkeiten bei der Annäherung an eingebettete Systeme. Es gibt auch Erfreuliches zu berichten: Die Komplexität der Hardware eines eingebetteten Systems ist im Vergleich zu den großen Verwandten PCs, Notebooks und Co. oft noch bis auf die Registerebene durch- und überschaubar. Die gegebene Hardware ist in vielen Fällen bis ins Detail durch den Entwickler selbst determiniert. Es bestehen zahlreiche Alternativen zu einer Architektur, die damit eine entsprechende Vielfalt von Lösungsmöglichkeiten konkreter Aufgabenstellungen eröffnen. Die erlangte Kompetenz ist nicht so einfach nachzubilden und kann dadurch für längere Zeit einen Marktvorsprung darstellen.

1.4Wie sieht das typische Zielsystem aus?

Dieses Buch fokussiert auf Systeme, die aus softwaretechnologischer Sicht an einem Kipppunkt zu verorten sind. Diese Systeme sind nicht mehr klein, aber auch noch nicht wirklich groß. Sie sind so leistungsfähig und komplex, dass die klassische Entwicklung mit einem Zeileneditor in einer strukturierten Sprache wie C an ihre Grenzen stößt. Es ist sinnvoll, die anstehenden Herausforderungen mit einer modellgetriebenen Entwicklung und in einer höheren Programmiersprache wie z. B. dem objektorientierten C++ zu bewältigen.

Als kleine eingebettete Systeme bezeichnen wir in diesem Kontext Mikrocontroller, meist mit 8-Bit-Verarbeitungsbreite, mit wenigen Kilobyte Programmspeicher und vielleicht maximal 30-MHz-Taktfrequenz.

Abb. 1–48-Bit-Controller im Vergleich zu einer 1-Cent-Münze

Abb. 1–532 Bit ARM Cortex A8 Singleboard Computer

Als große eingebettete Systeme bezeichnen wir 32- bis 64-Bit-Multicore-Architekturen, oft mit grafischem Display, einem entsprechenden Betriebssystem, mehreren Gigabyte Speicher und Taktraten im Gigahertz-Bereich. Letztere sind vielleicht noch eingebettete Systeme, aber keine Mikrocontroller mehr, sondern gehören schon zur Klasse der Mikrorechner.

Die kleinen Systeme sind mit den klassischen Mitteln, also hardwarenah in Assembler oder C, beherrschbar. Für die großen Systeme stehen etablierte Betriebssysteme und standardisierte Plattformen zur Abstraktion von der komplexen Hardware zur Verfügung. Zwischen diesen öffnet sich jedoch zurzeit ein großes Feld von Mikrocontrollern, die zum einen zu komplex sind für die althergebrachte Vorgehensweise und zum anderen zu diversifiziert für standardisierte Betriebssysteme.

Da die Übergänge nicht scharf abgrenzbar sind, soll eine Bandbreite von Systemen angesprochen werden, für die eine modellgetriebene Entwicklung, wie sie in diesem Buch beschrieben wird, praktikabel und kommerziell sinnvoll ist (siehe Abb. 1–6). Die untere Grenze bilden leistungsfähige 8- und 16-Bit-Architekturen mit 16 bis 32 KByte Programmspeicher und 1 bis 30 MHz Taktfrequenz. Als typisches Zielsystem sind 32-Bit-Single-Core-Architekturen mit 32 KByte bis 4 MByte Programmspeicher und bis zu 300 MHz Taktfrequenz anzusehen. Die Obergrenze sollten wir bei 32-Bit-Multicore-Systemen mit vielleicht 1 GByte Speicher ziehen.

Abb. 1–6Bandbreite der Zielsysteme

In dieser Bandbreite können die hier vorgestellten modellgetriebenen Technologien wertvolle Beiträge zur Qualitätsverbesserung und zum betriebswirtschaftlichen Erfolg leisten. Die zur Vertiefung der Buchinhalte angesprochenen und auf der Webseite verfügbaren Beispiele sind für ein Referenzsystem auf der Basis eines 32 Bit ARM Cortex M4 von Infineon konzipiert. Mit 1 MByte Programmspeicher und 120 MHz Taktfrequenz liegt dieses System genau an der kritischen Schwelle, die den Einsatz modellgetriebener Technologien besonders wirksam werden lässt.

1.5Fallbeispiele

Die hier kurz charakterisierten Fallbeispiele beziehen sich auf Projekte, die von den Autoren durchgeführt oder begleitet wurden.

1.5.1Die Anlagensteuerung

Das Projekt »Anlagensteuerung« ist bei einem mittelständischen Unternehmen mit ca. 100 Mitarbeitern zu verorten. Es werden Lüftungsanlagen in Kleinserien und nach Kundenspezifikation gefertigt. Die Entwicklungsabteilung der Firma besteht aus zwei Elektrotechnikingenieuren.

Für die Steuerung der Anlagen haben die Ingenieure im Laufe der Zeit eine kleine, modulare Hardwareplattform entwickelt. Die Ausstattung der Hardware bietet den Grundbedarf an Sensorik, Aktorik und einfachen Benutzerschnittstellen, die für jede Anlage benötigt werden. Zusätzlich kann die Steuerung mit weiteren Sensoren und Aktoren, grafischem Display, Netzwerkanschluss usw. ausgestattet werden.

Vor der Einführung modellgetriebener Technologien bestand das Hauptproblem darin, dass neue oder kundenspezifische Anlagenvarianten von der mechanischen und elektrotechnischen Seite her innerhalb weniger Tage realisierbar waren. Die Steuerungssoftware aber, sobald die neuen Anforderungen über eine einfache Parametrisierung hinausgingen, war erst nach Wochen oder gar Monaten verfügbar. Die Auslieferung der Anlagen verzögerte sich und Ressourcen (Kapital, Material, Fertigungs- und Lagerplätze) waren unnötig gebunden.

Mit der Einführung modellgetriebener Technologien wurde die Entwicklungszeit der Software so weit beschleunigt, dass diese jetzt in der Regel mit der Fertigstellung der Hardware zeitgleich zur Verfügung steht. Die Wettbewerbsfähigkeit der Firma wurde mit einer deutlich verkürzten Entwicklungszeit (Time-to-Market) entscheidend verbessert.

1.5.2Die Baumaschine

Ein traditionsreicher Hersteller von robusten Baumaschinen im unteren und mittleren Preissegment sah sich am Markt zunehmendem Wettbewerbsdruck ausgesetzt. Der Verkauf über den Preis konnte nur für begrenzte Zeit die Wettbewerbsfähigkeit erhalten. Als Alternative kam nur eine deutliche Verbesserung der Funktionalität der Baumaschinen infrage.

Die Herausforderung bestand jedoch darin, auf teure Zukaufkomponenten zu verzichten und trotzdem bessere Funktionalität anzubieten. Es wurde die Entscheidung getroffen, in Begleitung durch ein Beratungsunternehmen eine eigene Kompetenz zur Entwicklung von Hydrauliksteuerungen aufzubauen. Dabei wurde von Anfang an auf modellgetriebene Entwicklung gesetzt.

Innerhalb eines Jahres ist es gelungen, eine hauseigene Plattform für Steuergeräte zu entwickeln und vor allem durch modellgetriebene Tests die Konformität mit Normen und Sicherheitsanforderungen begleitend zur Hardwareentwicklung sicherzustellen.

Das Entwicklerteam konnte einen definierten und modellgetriebenen Entwicklungsprozess etablieren. Dabei herrscht ein hoher Grad an Arbeitsteilung. UML-Modelle dienen nicht nur zur Systemgenerierung, sondern auch als normierendes Element in der Kommunikation zwischen den beteiligten Entwicklerteams.

Heute wird ein wesentlicher Anteil der Wertschöpfung des Unternehmens über die Softwareentwicklung erbracht. Verifikation und Validierung neuer Entwicklungen erfolgen bereits auf Modellebene. Nicht nur die Quellcodes und automatisierte Tests, sondern auch weite Teile der Projektdokumentation werden aus den Modellen generiert.

1.5.3Das Energie-Monitoring-System

Für die wissenschaftliche Untersuchung von besonders energiesparenden Gebäuden (Passivhäusern) wird eine Vielzahl unterschiedlicher Messwerte benötigt. Es müssen Hunderte Sensoren im und am Baukörper verbaut und vernetzt werden. Dabei kommen über verschiedene Kommunikationsmedien sehr unterschiedliche Protokolle und Datenformate zur Anwendung.

Herstellerspezifische Lösungen für moderne Zählersysteme (Smart Meter) erschweren die Integration. Das System besteht aus zahlreichen einzelnen Controllern zur Datenerfassung, -übertragung und -aufbereitung.

Die Komplexität der Gesamtlösung lässt sich mit folgenden Parametern umreißen: Individuelle, auf mehrere Hundert unterschiedliche Controller verteilte Softwarelösung, die mehr als zwei Millionen Messwerte am Tag erfasst, verarbeitet und an einen Server überträgt.

Die Lösung wurde innerhalb von weniger als drei Monaten durch ein kleines in der modellgetriebenen Entwicklung erfahrenes Team erstellt und automatisiert auf das Zielsystem übertragen. Späte und nachträgliche Anforderungen des Auftraggebers konnten zuverlässig und zügig implementiert werden. Das System wurde und wird in der Einsatzphase ständig an neue Anforderungen angepasst. Die Anforderungen an das System werden durch Akteure, die an der wissenschaftlichen Auswertung der Daten beteiligt sind, immer wieder erweitert.

Es hat sich herausgestellt, dass modellgetriebene Anpassungen zuverlässiger und um ein Vielfaches schneller sind als vergleichbare Lösungen.

Die Liste der Fallbeispiele lässt sich noch wesentlich länger gestalten. Eines ist allen Erfolgsbeispielen gemeinsam: Der zunächst nicht unerhebliche Aufwand für die Einführung modellgetriebener Technologien hat nicht nur zu moderaten Verbesserungen geführt, sondern zu völlig neuen Dimensionen. Die Auswirkungen sind vor allem in der Softwarequalität, der Prozessqualität, der Entwicklungsgeschwindigkeit und der Wartbarkeit der Systeme festzustellen.

1.5.4Das Beispielsystem SimLine

Im Buch werden Anwendungsbeispiele anhand eines Referenzsystems erläutert. Dieses Referenzsystem wurde speziell für dieses Buch zusammengestellt und besitzt wichtige Merkmale, die für die genannten Fallbeispiele relevant sind. Zum Beispiel ein grafisches Display wie bei der Anlagensteuerung, ein Fahrzeugbussystem wie in der Baumaschine und Sensorik und Aktorik sowie eine Ethernet-Schnittstelle wie beim Energie-Monitoring-System.

Das Referenzsystem ist das Smart-Home-System SimLine. Es besteht aus einer Plattform, die die Kerninfrastruktur zur Verfügung stellt, um Sensoren und Aktuatoren anzuschließen, die Sensoren auszulesen und über definierbare Regeln die Aktuatoren entsprechend anzusteuern.

Zusätzlich gibt es einzelne SimLine-Sensoren und -Aktuatoren sowie spezielle SimLine-Module mit vordefinierten Regeln, beispielsweise für Einbruch- oder Sturmschutz.

Vertiefende Informationen, Beispielmodelle und Beschaffungsquellen für das SimLine-System finden Sie auf der Webseite zum Buch.

1.6Das Manifest

Das Manifest Modeling of Embedded Systems wurde 2015 von mehreren Personen erarbeitet, die überzeugt sind, dass Projekte den steigenden Anforderungen an die Entwicklung eingebetteter Systeme nur gerecht werden können, wenn sie modellbasierte Methoden verwenden. Gleichzeitig sahen die Autoren, dass trotzdem die Modellierung noch sehr verbreitet eingesetzt wird.

Unter den Autoren und Unterzeichnern des Manifests waren auch Autoren dieses Buches. Das Manifest ist somit auch ein Leitfaden für dieses Buch und Sie werden die einzelnen Thesen des Manifests im gesamten Buch wiederfinden.

Das Manifest postuliert 7 Thesen:

1.

Beteilige Stakeholder

durch geeignete domänenspezifische Abstraktionen, Notationen und Sichten.

2.

Strebe nach langlebigen Modellen

durch angemessene Abstraktionen, Trennung von Aspekten und Modellierungsrichtlinien.

3.

Mache Modelle überprüfbar, transformierbar und ausführbar

durch semantisch klar definierte Sprachen für funktionale und nicht funktionale Aspekte.

4.

Lerne rechtzeitig

durch Modelle, die in einer frühen Entwicklungsphase Anforderungen und Spezifikationen überprüfen und Fehler aufzeigen.

5.

Vermeide Redundanzen und wiederkehrende Arbeiten

durch Automatisierung und Integration von Modellen für verschiedene Aspekte.

6.

Mache Modelle zugänglich

durch eine skalierbare Infrastruktur und benutzerfreundliche und leicht erlernbare Werkzeuge.

7.

Etabliere eine Modellierungskultur

durch Ausbildung und Harmonisierung der Modellierungsaktivitäten mit den Entwicklungsprozessen.

Das Manifest wurde erstmals 2015 auf der Konferenz MESCONF (www.mesconf.de) in München vorgestellt. Es ist auf einer eigenen Internetseite www.mdsemanifest.org publiziert und kann von jedem als Zeichen der Unterstützung unterzeichnet werden.

In Anhang A werden die Thesen des Manifests zur Entwicklung der Skizze eines Reifegradmodells für modellbasierte Softwareentwicklung herangezogen.

Legende

Am Ende der meisten Kapitel gibt es eine Zusammenfassung, die in kurzen Stichpunkten eine Art Essenz bildet. Dabei gibt es folgende Kategorien an Stichpunkten, die entsprechend dem Charakter des jeweiligen Kapitels mehr oder weniger ausgeprägt oder nicht vorhanden sind (z.B. hat Anhang B »Kurzreferenz UML und SysML« keine Zusammenfassung).

Checklisten: Die so gekennzeichneten Aussagen sind als Checkliste zu sehen. Sie helfen Ihnen, zu überprüfen, ob Sie die essenziellen Konzepte dieses Kapitels berücksichtigt haben.

Hinweise: Die so gekennzeichneten Aussagen weisen noch einmal auf wichtige Aussagen des Kapitels hin.

Warnungen: Die so gekennzeichneten Aussagen weisen explizit auf Fehlentscheidungen/Fehlannahmen hin, die in der Praxis immer wieder anzutreffen sind und deren Auswirkungen erfahrungsgemäß besonders aufwands- oder kostenintensiv ausfallen.

2Basiswissen

»Die Wahrheit und Einfachheit der Natur sind immer die letztenGrundlagen einer bedeutenden Kunst.«

(Paul Ernst, 1866 – 1933, deutscher Essayist, Novellist,Dramaturg, Versepiker)

2.1Was sind eingebettete Systeme?

Als eingebettete Systeme werden Digitalrechner bezeichnet, die für die Steuerung, Überwachung, Regelung oder für andere Aufgaben, wie z. B. eine Signalverarbeitung, in den räumlich-technischen Kontext der zu erfüllenden Aufgabe integriert sind. Das System stellt mit dem möglichen Benutzer die Umgebung des eingebetteten Systems dar. Die Integration in das System bewirkt, dass der meist recht kleine Digitalrechner (Mikrocontroller) als solcher von außen oft nicht wahrgenommen werden kann. Für die zu erfüllende Aufgabe werden Informationen aus der Umgebung über Sensoren erfasst und verarbeitet, die dann wiederum über Aktuatoren auf das System einwirken. Die Benutzerschnittstellen solcher Systeme sind oft sehr schmal und bestehen mitunter nur aus einzelnen LEDs und wenigen Tastern. Da sich dieses Buch mit modellgetriebener Entwicklung eingebetteter Systeme beschäftigt, soll ein solches auch gleich modellhaft dargestellt werden (siehe Abb. 2–1).

Abb. 2–1Ein vereinfachtes Modell eingebetteter Systeme in ihrer Umgebung

Für ein tieferes Verständnis reicht dieses einfache Modell jedoch nicht aus. Das System selbst verfügt neben dem Mikrocontroller und den Sensoren und Aktuatoren noch über weitere physische Komponenten und steht mit der übergeordneten Umgebung in Wechselwirkung. Solche weiteren physischen Komponenten können z. B. hydraulische oder mechanische Teilsysteme sein. Die physikalischen Größen dieser Wechselwirkungen des Gesamtsystems mit seiner Umwelt sind unter anderem Temperatur, Feuchtigkeit und nicht zu vergessen die elektromagnetische Strahlung. Sensoren und Aktuatoren können nicht nur auf das System, sondern auch auf die Systemumgebung gerichtet sein. Für eingebettete Systeme ist inzwischen die Vernetzung mit anderen Systemen eine Selbstverständlichkeit.

Dieses Buch beschäftigt sich mit der Entwicklung solcher Systeme. Der Softwareentwickler hat seinen ganz eigenen Zugang zum System. Dazu nutzt er Werkzeuge und muss sich an Vorgaben halten. Fassen wir all diese Aspekte zusammen, erhalten wir das folgende Modell (siehe Abb. 2–2).

Abb. 2–2Ein detaillierterer Kontext eines eingebetteten Systems

Dieses Modell soll im Rahmen dieses Buches als Referenzmodell für eingebettete Systeme dienen. Das vollständige Modell finden Sie auf der buchbegleitenden Internetseite. Die einzelnen Modellelemente sind weiter verfeinert. Für das Verständnis der speziellen Problematik eingebetteter Systeme ist es wichtig, zu beachten, dass Embedded Software meistens nicht losgelöst von einer konkreten elektronischen Schaltung im direkten Umfeld des Mikrocontrollers betrachtet werden kann. Software und die zugehörige elektronische Schaltung bilden nur zusammen ein funktionierendes System.

Die Zuordnung von Softwarekomponenten zu bestimmten Hardwarekomponenten ist oft nicht physisch determiniert, sondern durch die übergeordnete Gesamtarchitektur aus Hardware und Software beeinflusst. Dieser Umstand, dass die Embedded Software und die Embedded Hardware abhängige Teilsysteme des Gesamtsystems sind, soll hier am Beispiel der Modellverfeinerung der Benutzerschnittstelle aufgezeigt werden (siehe Abb. 2–3).

Abb. 2–3Fragmentierung der Komponenten in Hardware und Software

Diese Fragmentierung einer Komponente kann man noch besser als Arbeitsteilung zwischen Hardware und Software bei der Erfüllung der gestellten Anforderungen betrachten. In der Folge sind Entwurfsentscheidungen zu treffen, welche Teilaufgabe in Hardware und welche in Software realisiert werden soll. Diese Fragestellung erhält mit der Möglichkeit, dass ein eingebettetes System auch anwendungsspezifische Hardwarekomponenten (z.B. ASIC (Application-Specific Integrated Circuit) und FPGA (Field Programmable Gate Array)) auf der Chipfläche des Controllers enthalten kann, noch eine zusätzliche Dimension.

2.2Software Engineering für eingebettete Systeme

Im vorangegangenen Abschnitt wurde dargelegt, in welchem Spannungsfeld die Softwareentwicklung für eingebettete Systeme zu verorten ist. Software Engineering ist ein seit Langem etablierter Begriff. So definiert das Institute of Electrical and Electronics Engineers, IEEE, Software Engineering wie folgt: »The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software« (IEEE Standard Glossary of Software Engineering Terminology, 610.12-1990).

Frei übersetzt bedeutet das also, eine systematische, disziplinierte und kontrollierbare Vorgehensweise zur Entwicklung, Nutzung und Wartung von Software anzuwenden. Grundsätzlich geht es beim Software Engineering also um eine ingenieurmäßige Arbeitsweise bei der Herstellung von Software. Das impliziert, dass man sich vielleicht einmal andere Ingenieurdisziplinen anschauen sollte, um zu verstehen, was ingenieurmäßig bedeutet.

Stellen wir uns einen Elektroingenieur vor, der in einer mehr oder weniger ungeeigneten Form, im schlimmsten Fall nicht einmal textuell dargelegt, sondern nur auf Zuruf, ein komplexes System herstellen soll. Er wird jetzt nicht die Werkzeuge zur Realisierung und Fehlersuchmittel hervorholen, also Lötkolben, Multimeter und Oszilloskop, und mit einer Lösungsidee im Kopf und seinem reichen Erfahrungsschatz schauen, wo er mit dem Löten beginnt, sondern er wird eher mehrstufig vorgehen. Zuerst wird er die hoffentlich vorhandene textuelle Aufgabenstellung systematisch durcharbeiten und die darin enthaltenen Anforderungen identifizieren. Eine erste grobe Lösungsidee oder auch mehrere Lösungsvarianten wird er als Blockschaltbild zur Diskussion stellen. Er nutzt dabei bestimmte Basiskonzepte – sogenannte Paradigmen –, wie man nach dem aktuellen Stand der Technik die Aufgabe lösen sollte. Kein Elektrotechniker wird heutzutage den Digitalteil seiner Schaltung noch mit 5 Volt TTL (Transistor-Transistor-Logik), einer Schaltungstechnik aus den 1960er-Jahren, konzipieren. Er wird sich aktueller CMOS-Logik (Complementary Metal-Oxide-Semiconductor) mit 3 Volt und weniger bedienen. Die favorisierte Lösungsvariante kann er dann im Detail konstruieren. Dabei benutzt er einen normierten Symbolvorrat und ein CAD-System als Werkzeug.

Nachdem er den Schaltplan fertiggestellt hat, wird er diesen vielleicht simulieren und auf Fehler testen, bevor er anfängt, das Leiterplattenlayout im selben CAD-System als eine andere Perspektive zu konstruieren. Die eigentliche Fertigung der Elektronik ist oft hochgradig automatisiert. Leiterplattenherstellung und Bestückung erfolgen aus den CAD-Daten heraus auf entsprechenden Automaten. Selbst wichtige Tests, wie z. B. auf Kurzschlüsse der Leiterbahnen aufgrund fehlerhafter Fertigung, werden automatisiert ausgeführt.

Neben den Fertigungsdaten liefert das Konstruktionswerkzeug auch wichtige betriebswirtschaftliche und organisatorische Informationen, z. B. Stücklisten der benötigten Bauteile für den Einkauf. Wir können übrigens dasselbe Gedankenexperiment auf einen Maschinenbauingenieur übertragen und kommen zum gleichen Ergebnis:

Top-down-Ansatz: Strukturierte Vorgehensweise vom Allgemeinen (Groben, Abstrakten) zum Speziellen (Konkreten).

Konstruktion mit standardisierten Konstruktionssprachen (oft mit grafischen Notationen) und Nutzung hochentwickelter computergestützter Werkzeuge (CAD).

Simulation/Test der Konstruktion im Modell.

Automatisierte Realisierung aus den Computermodellen heraus.

Automatisierte Tests, Computermodelle werden bereits getestet.

Was ist nun im Kontext der Entwicklung eingebetteter Systeme unter dem Begriff Software Engineering zu verstehen? Wagen wir den Versuch einer Definition, was eine ingenieurmäßige Vorgehensweise bei der Softwareentwicklung für eingebettete Systeme bedeutet:

Software Engineering für eingebettete Systeme

Software Engineering für eingebettete Systeme ist eine Teildisziplin der technischen Informatik, die sich mit der systematischen Anwendung von Paradigmen, Methoden, Techniken, Normen, Werkzeugen und Sprachen zur Herstellung von Software für eingebettete Systeme beschäftigt.

Unter Paradigmen der Softwareentwicklung verstehen wir Basiskonzepte, wie z. B. die Strukturierung bzw. Funktionsorientierung oder die Objektorientierung. Methoden beschreiben konkrete Vorgehensweisen und spiegeln sich in Vorgehensmodellen, oder etwas aktueller ausgedrückt, in Softwareprozessen wider. Techniken wie die Darstellungstechniken Programmablaufplan oder UML-Klassendiagramm unterstützen den Entwickler bei der Anwendung von konkreten Paradigmen und Methoden. Normen legen verbindlich fest, wie etwas, z. B. ein UML-Klassendiagramm nach dem internationalen Standard ISO/IEC 19505-2:2012, ordnungsgemäß ausgeführt wird. Werkzeuge unterstützen die Anwendung der Techniken. So ist es sehr viel einfacher, die ISO/IEC 19505-2 bei der Erstellung eines Klassenmodells einzuhalten, wenn man ein richtiges UML-Werkzeug nutzt, anstatt sich eines Grafikprogramms oder einer Office-Software zu bedienen. Außerdem können Werkzeuge die Realisierung automatisieren, indem Sie z. B. aus einem UML-Modell den Quellcode der Anwendung generieren. Die konkreten Programmiersprachen folgen Paradigmen. So unterscheidet sich ein strukturierter C-Quelltext erheblich von einem objektorientierten C++-Code. Bei all diesen Dimensionen des Software Engineering dreht sich letztendlich alles um die Optimierung dreier miteinander konkurrierender oder sogar kannibalisierender Ziele der Softwareentwicklung: Es geht um maximale Funktionalität und Qualität bei minimalem Zeit- und Kostenaufwand.

Schauen wir als Nächstes auf den Begriff der Softwarequalität.

2.3Der Qualitätsbegriff

2.3.1Externe Qualität

Die externe Qualität ist die Qualität, die man bei Software am ehesten mit dem Qualitätsbegriff in Verbindung bringt. Es ist die nach außen sichtbare bzw. in den meisten Fällen auch messbare Qualität. Sie kann von den Benutzern der Software während ihrer Ausführung (Verwendung) erlebt, d. h. bewusst wahrgenommen, werden. Dazu zählt natürlich vor allem die Funktionalität der Software, ihre Korrektheit (Fehlerfreiheit), Zuverlässigkeit sowie die Effizienz, mit der die Funktionalität bereitgestellt wird (beispielsweise Antwortzeitverhalten bzw. Performance). Verfügt die Software über eine direkte Benutzerschnittstelle (User Interface), so zählen auch Benutzbarkeit (Ergonomie), Erlernbarkeit und Attraktivität zu ihren externen Qualitäten.

2.3.2Interne Qualität

Die interne Qualität bezeichnet hingegen die innere, strukturelle Qualität einer Software. Es ist die Qualität, die am ehesten von den Softwareentwicklern wahrgenommen wird. So zählt beispielsweise die Struktur, Beschaffenheit und Verständlichkeit des Quellcodes zur internen Qualität. Zentrale Begriffe der internen Qualität sind Wartbarkeit (Evolvierbarkeit) und Erweiterbarkeit, aber auch die Übertragbarkeit einer Software, beispielsweise ihre Portierbarkeit auf eine andere Betriebssystem- oder Prozessorplattform.

Evolvierbarkeit

Der Begriff Evolvierbarkeit stammt ursprünglich aus der Biologie. Er bezeichnet die Fähigkeit eines Organismus, sich an veränderte Umweltbedingungen anpassen (evolvieren) zu können.

Evolvierbarkeit ist bezogen auf Software eigentlich die bessere Metapher für den weitverbreiteten Begriff Wartung. Unter Wartung versteht die DIN 31051 alle vorbeugenden Maßnahmen, die einen zukünftigen Ausfall oder die Fehlfunktion eines Systems präventiv verhindern sollen. Das heißt, dass beispielsweise die verschleißbedingte Erneuerung von Bremsbelägen an einem Kraftfahrzeug eine Wartungsmaßnahme ist.

In der Software hingegen gibt es streng genommen keine Wartung. Es gibt dort nichts, was verschleißen kann. Ein Fehler (engl. bug) war immer da, und ist nicht erst langsam während des Betriebs entstanden. Gute Evolvierbarkeit drückt aus, dass eine Software über ihren gesamten Lebenszyklus leicht und schnell an neue Anforderungen und veränderte Rahmenbedingungen angepasst werden kann.

Die interne Qualität einer Software entscheidet auch darüber, wie viel Energie aufgebracht werden muss bzw. welcher Aufwand notwendig ist, um neue Anforderungen umzusetzen oder die Software an veränderte Rahmenbedingungen anzupassen. Ist die interne Qualität einer Software gering, so vermindert sich auch die Fähigkeit einer Entwicklungsorganisation, neue Anforderungen schnell und kostengünstig umzusetzen. Damit sinkt nicht nur die betriebliche Wertschöpfung, sondern auch die Kompetenz der Organisation, rechtzeitig auf die Dynamik des Marktes zu reagieren.

Komplexe Softwaresysteme tendieren mit der Zeit dazu, an interner Qualität zu verlieren. Dieses Phänomen bezeichnet man auch als Softwareentropie, d.h., es entsteht immer mehr Unordnung in dem System. Gelegentlich hört man in dem Zusammenhang auch, dass die Software förmlich verrottet, oder man spricht vom »Spaghetticode«. Nicht selten endet eine derart schädliche Fortentwicklung, sofern nicht rechtzeitig gegengesteuert wird, in einem sehr teuren Wartungsalbtraum, oder das Projekt muss sogar vorzeitig abgebrochen werden.

2.3.3Qualitätskriterien nach ISO/IEC 25010

Qualitätsmodelle für Software wurden schon zu Anfang der 1970er-Jahre entwickelt. Einer der ersten Vorläufer heutiger Qualitätsmodelle ist McCall's Software Quality Model[McCall et al. 1977] aus dem Jahr 1977, das auch unter dem Namen General Electrics Model bekannt ist. McCall et al. identifizierten drei Hauptperspektiven für die Charakterisierung der Qualitätsmerkmale eines Softwareprodukts:

Produktrevision (Änderungsfähigkeit),

Produktübergang (Anpassungsfähigkeit an neue Umgebungen) und

Produkteinsatz (grundlegende Betriebsmerkmale).

Ein weiteres bekanntes Modell ist das des US-amerikanischen Softwareentwicklers Barry W. Boehm. Das aus dem Jahr 1978 stammende Boehm’s Quality Model definiert eine Hierarchie von Softwarequalitätsmerkmalen, um Softwarequalität als ein Satz von Attributen und Metriken (Messungen) ausdrücken zu können.

Natürlich können Entwicklungsorganisationen auch ihre eigenen, proprietären Qualitätsmodelle definieren, die sie für die Bewertung von Softwarequalität heranziehen. Es bietet sich aus guten Gründen allerdings an, sich an internationalen Standards zu orientieren. Derartige Standards und Normen entstehen im Konsens unter Mitwirkung vieler Unternehmen und schaffen somit Klarheit und ein gemeinsames Verständnis. Und letztendlich kann sich auch ein Kunde bzw. Auftraggeber auf diese Standards beziehen, das Arbeiten nach selbigen im Entwicklungsauftrag sogar explizit einfordern.

Der für Softwarequalität relevante Standard ist die ISO/IEC 25010:2011 [ISO 25010], Nachfolger der nunmehr obsoleten ISO/IEC 9126. Die ISO/IEC 25010:2011 definiert gleich zwei Modelle für die qualitative Bewertung von Softwareprodukten:

Ein Modell für die Nutzungsqualität (

Quality in Use Model

)

Ein Modell für die externe und interne Produktqualität (

Product Quality Model

)

Wie der Name schon nahelegt, wird beim Modell für die Nutzungsqualität die Perspektive eines Anwenders (Nutzers) der Software in einem bestimmten Kontext (Einsatzumfeld) eingenommen. Dazu gehören u.a. Charakteristiken wie die Benutzerzufriedenheit, Effektivität/Wirkungsgrad (d.h. die Genauigkeit und Vollständigkeit, mit denen Anwender der Software ihre Ziele erreichen) oder die Effizienz (z.B. der Ressourcenverbrauch).

Besonders die im Embedded-Umfeld häufig anzutreffenden Qualitäten hinsichtlich der funktionalen Sicherheit (Functional Safety) sind im Modell für die Nutzungsqualität (siehe Abb. 2–4) unter der Kategorie »Risikofreiheit« enthalten.

Abb. 2–4Modell für die Nutzungsqualität

Demgegenüber führt das Product Quality Model (siehe Abb. 2–5 und 2–6) des ISO-Standards die Eigenschaften des Produkts selbst auf. Dieses ist auch das bekanntere und umfangreichere der beiden Modelle.

Abb. 2–5Modell für die Produktqualität (Teil 1)

Abb. 2–6Modell für die Produktqualität (Teil 2)

Diese Modelle können auch wie eine Checkliste benutzt werden. Man kann die einzelnen Kategorien durchgehen und, sofern eine Kategorie für das zu entwickelnde System relevant ist, die entsprechenden Qualitätsanforderungen dazu erheben.

Beim modellbasierten Requirements Engineering (siehe Kap. 4) kann dieses Modell auch zur Einführung von Anforderungskategorien verwendet werden, beispielsweise indem man das SysML-Standardstereotyp «requirement» in einem Profil um spezifischere Stereotype erweitert, die den Kategorien des Qualitätsmodells entsprechen: «PerformanceRequirement», «ReliabilityRequirement», «UsabilityRequirement» usw.

Darüber hinaus kann das Modell für die Produktqualität als Grundlage für einen sogenannten Quality Attribute Utility Tree im Rahmen der Softwarearchitektur-Assessment-Methode ATAM (siehe Abschnitt 5.7) verwendet werden.

2.4Einführung in Model-Driven Software Engineering

Was genau ist eigentlich Model-Driven Software Engineering (MDSE)? Anders gefragt, was ist die Voraussetzung für erfolgreiches MDSE?

Um diese Frage zu beantworten, ist es hilfreich, zu verstehen, welcher Mechanismen (Abstraktion, Contract-Based Design, Korrelation, Simulation, Validation) sich MDSE bedient und wie diese wirken.

Häufig wird der Schwerpunkt der Modellierung auf manuell erstellte grafische Darstellungen des Systems gelegt. Sollen grafische Repräsentationen die Verständlichkeit der Systeme verbessern, dann müssen sie verschiedene Gesichtspunkte des Systems darstellen. Das geht nicht ohne redundante Repräsentanz von Artefakten, die zusätzlich zu pflegen sind. Das folgende Beispiel soll das verdeutlichen.

In ANSI-C-Code ist auch das Laufzeitverhalten einer Applikation implizit enthalten. Aber für unser Gehirn grenzt es an Höchstleistung, das Laufzeitverhalten aus dem Code zu abstrahieren. Eine grafische Darstellung, z. B. in Form eines UML-Zeitdiagramms, wird helfen, den Aspekt des zeitlichen Verhalten zu abstrahieren und verständlicher darzustellen. Aber nun müssen bei Änderungen zwei Repräsentationen angepasst werden: der C-Code und das zugehörige UML-Zeitdiagramm. Soll auch die Kommunikation auf Basis eines UML-Sequenzdiagramms abstrahiert werden, müssen ab diesem Zeitpunkt drei Repräsentationen gepflegt werden.

Abstraktion erhöht die Verständlichkeit von komplexen Systemen auf Kosten von zusätzlicher Arbeit für die Pflege der abstrakten Sichten. Mit per Hand erstellten abstrakten Sichten kann die Qualität verbessert werden, jedoch zulasten der Effizienz.

Das spürt jeder, der über einen längeren Zeitraum UML-Diagramme parallel zum Code erstellt und gepflegt hat. Die Verständlichkeit des Systems, und somit auch die Kommunikation im Entwicklungsteam und mit Stakeholdern, wird damit in der Regel verbessert, Fehler nehmen ab, die Einarbeitung neuer Mitarbeiter ist schneller möglich, aber im Tagesgeschäft reicht die Zeit nicht aus, um alle Diagramme bei Änderungen konsistent zum Code zu halten. Entweder steigt der Pflegeaufwand kontinuierlich an und die Effizienz geht in die Knie oder – und das ist wahrscheinlicher – der steigende Aufwand zur Pflege der grafischen Repräsentationen kann in der Praxis zunehmend weniger geleistet werden. Die Modelle werden unpräzise, weichen zunehmend voneinander ab (Inkonsistenz) und verlieren ihre Aussagekraft, der Nutzen schwindet.

Langfristig erfolgreiches MDSE geht weit über die rein grafische Repräsentanz hinaus. Es ermöglicht die automatische Transformation der vorhandenen Daten in repräsentative Sichtweisen, ohne dabei die von Hand zu pflegende Redundanz zu erhöhen. Das entstehende Modell basiert auf Taxonomien und Metastrukturen, die Regeln beinhalten. Auf deren Basis können durch Änderungen entstandene emergente Zustände des Gesamtsystems (Basis für Dysfunktion) durch die Analyse des Modells automatisch erkannt werden, bevor das System real existent wird. Der dafür notwendige Aufwand ist um ein Vielfaches geringer als die reale Implementation. Fehler lassen sich am Modell früher und mit weniger Aufwand finden und beseitigen als im realen System. Hier liegt der Hauptnutzen eines Modells.

Der folgende Abschnitt gibt eine praxisorientierte Einführung in die wichtigsten Voraussetzungen dafür, dass sich modellgetriebenes Engineering sowohl auf die Qualität als auch auf die Effizienz auswirkt.

2.5Komplexität

Wachsende Komplexität ist im Engineering von intelligenten Systemen (Smart Systems) unvermeidbar. Sie repräsentiert die gestiegenen Funktionsumfänge, die die Marktfähigkeit innovativer Produkte stärken. Dem gegenüber stehen immer kürzer werdende »Time-to-Market«-Anforderungen. Es gilt mehr Funktionalität in möglichst kurzer Zeit auf hohem Qualitätsniveau zu erreichen.

Wie in allen Bereichen des Lebens gibt es Grundgesetze, sogenannte Basis-Paradigmen. In der Vergangenheit war das Engineering eher mit komplizierten Systemen konfrontiert und das Prinzip Teile und herrsche (hierarchische Dekomposition und Aggregation) diente als erfolgreiches Basis-Paradigma.

Aber mit jeder Teilung wächst die Anzahl der Schnittstellen polynomiell zur Anzahl der Elemente (siehe Abb. 2–7). Erschwerend kommt hinzu, dass die Schnittstellen heutiger Systeme auf immer mehr Ebenen ausgeprägt sind. So gibt es neben zeitlichem Verhalten, Datenfluss, logisches Verhalten, Varianten, Versionen, überlagerte Kontrollflüsse (z.B. Not-Aus, Firmware-Updates, …), kundenindividuelle Eigenschaften u.v.m.

Hinzu kommt, dass Entwicklungen wie Industrie 4.0, Internet of Things, Cyber-Physical-Systems über den hohen Grad der Vernetzung die Anzahl der Schnittstellen in Zukunft noch einmal um Potenzen steigern werden.

Unter obigen Rahmenbedingungen sprechen wir von komplexen Systemen. Was ist der Unterschied? Konnte man früher bei der Änderung einer Komponente bei sorgfältigem Vorgehen die Auswirkungen umfassend vorhersehen, so ist das heute oftmals nicht mehr möglich. So hilfreich das Paradigma Teile und herrsche bei komplizierten Systemen war, stößt es bei komplexen Systemen zunehmend an seine Grenzen. Es verschiebt die Komplexität von den Elementen auf die Beziehungen (siehe Abb. 2–7).

Abb. 2–7Teile und herrsche führt zu einem polynomiellen Anstieg der Schnittstellen.

Bei Änderungen eines Elements reicht die Zeit nicht aus, um alle möglichen Auswirkungen über die explodierte Anzahl potenzieller Schnittstellen zu überblicken, mögliche Auswirkungen werden dadurch übersehen. Es entstehen sogenannte »Hidden Links«, die zu undefinierten Reaktionen des Systems führen (Emergenz) und die Wahrscheinlichkeit für Fehlverhalten (Dysfunktion) kontinuierlich erhöhen. Wird auf eine wachsende Komplexität nicht probat im Engineering reagiert, wird die Wirkkette Hidden Links -> Emergenz -> Dysfunktion in Gang gesetzt. Kostspielige Nachbesserungen nach Inbetriebnahmen, Rückrufaktionen und Co. sind die Folge.

In diesem Bewusstsein explodieren die Testaufwände, und doch bleibt das Gefühl, nicht ausreichend getestet zu haben. So spüren wir heute die Komplexität in vollem Umfang.

Um einem Gedankengang grundsätzlich vorzubeugen: »Teile und herrsche« ist immer noch unverzichtbare Grundlage zum Managen von Kompliziertheit und auch für Komplexität. Aber für Letzteres benötigen wir darüber hinaus Mechanismen, um die steigende Komplexität der Schnittstellen wieder zu beherrschen.

Abb. 2–8Wachsende Komplexität führt über eine potenziell steigende Anzahl an Hidden Links zu Emergenz und letztendlich zu steigendem Potenzial an Dysfunktion von Systemen.

2.6Unser Gehirn als Engpass

Die Neurobiologie besagt, dass unser Gehirn auf der bewussten Ebene ca. 7 +/- 2 Artefakte und/oder Beziehungen in einem Augenblick überblicken (begreifen) kann. Verglichen mit der Anzahl an potenziellen Artefakten und Schnittstellen komplexer Systeme ist das nicht sehr viel. Stellen Sie sich vor, Sie haben gerade sieben Artefakte parat und deren Zusammenhänge logisch durchdacht, dann fällt Ihnen ein achtes Artefakt ein. Im selben Moment verschwindet eines der vorherigen Artefakte, wie bei einem Schieberegister, aus Ihrem Fokus und das geschieht, ohne dass unser Bewusstsein uns darauf aufmerksam macht. Wir merken für gewöhnlich nicht, dass wir in diesem Moment gerade etwas vergessen. Stattdessen befinden wir uns in dem Irrglauben, alles berücksichtigt zu haben. Gibt es nun einen logischen Zusammenhang zwischen dem achten neuen Artefakt und dem gerade herausgefallenen, haben wir eine potenzielle Situation für die Entstehung eines »Hidden Link«.

Wenn wir nun bedenken, dass heutige komplexe Systeme Tausende an Artefakten haben, die über deutlich mehr als sieben Ebenen potenziell in Beziehung stehen können, ist es naheliegend, dass es ein Trugschluss ist, dass unser Gehirn in der Lage ist, die möglichen Auswirkungen von Änderungen vollständig zu durchdringen.

Abgesehen davon versagt unser Gedächtnis bereits, wenn es die möglichen Zusammenhänge einer begrenzten Auswahl an Artefakten aus dem Stegreif auflisten sollte. Und jetzt stellen Sie sich noch die Entwicklung eines komplexen Systems auf Basis von vielen Gehirnen vor, in denen keines der Gehirne das Gesamtsystem mit all seinen potenziellen Zusammenhängen kennt, sondern immer nur Anteile des Systems.

Wenn also ein einzelnes Gehirn (selbst, wenn es ein optimales Gedächtnis hätte) nicht mehr alle Zusammenhänge kennt, bleibt die spannende Frage: Welche anderen Gehirne des Teams soll es zurate ziehen, um mit Sicherheit alle Abhängigkeiten herauszufinden?

Noch eines zeigt die Neurobiologie. Wahrscheinlich könnte unser Unterbewusstsein uns aus dem Dilemma heraus helfen, denn unser Unterbewusstsein scheint einem optimalen Gedächtnis sehr nahe zu kommen. Nur ist die Menschheit noch nicht in der Lage, deterministisch mit dem Unterbewusstsein zu arbeiten, und so lange müssen wir andere Wege gehen, wenn wir komplexe Systeme entwickeln möchten, die sich am Ende deterministisch verhalten sollen.

2.7Vorgehensweisen und Techniken, um einer steigenden Komplexität zu begegnen

Um einer steigenden Komplexität effizient zu begegnen, haben sich folgende Techniken als grundlegend hilfreich herausgestellt:

1. Strukturierung und Elimination von Ebenen und Beziehungen auf Basis von Architekturdesign. Diese Maßnahmen soll das Beziehungsgeflecht einfach und verstehbar halten.

2. Einschränkung der Ausprägung von Schnittstellen auf Basis von Contract-Based Design (CBD; auch

Design by Contract

(DbC) – Entwurf gemäß Vertrag). Dazu gehört auch die genaue Spezifikation von Schnittstellen, um diese automatisiert zu prüfen. Obwohl erste Ansätze bereits 1985 in der Programmiersprache »Eiffel« durch Bertrand Meyer eingeführt wurden, konnte sich CBD noch nicht breitflächig durchsetzen. Notationen, wie UML in Verbindung mit Stereotypen, bieten sehr gute Voraussetzungen zur Anwendung von Contract-Based Design und damit die Basis für eine weitere Verbreitung.