Konstruktion eines einfachen Systems

Ausgehend von diesem einfachen Beispiel betrachten wir jetzt einen Fall, bei dem wir ein erstes kleines Realzeitsystem 'bauen'. Wir berücksichtigen dabei, dass ein Realzeotsystem in der Regel das Produkte eines Engineeringprozesses ist, der vereinbarten Regeln des Engineerings folgt. Wir setzen hier also Vorlesungen zum Softwareengineering voraus. Hier sollen nur solche Aspekte angesprochen werden, die für das Engineering von Realzeitsystemen typisch sind.Dabei unterstellen wir als grobe Phasen eines Engineeringprozesses die folgenden (vgl. auch das Schaubild 13.1):

Figure 2.5: Engineering Kontext für Realzeitsysteme

In diesem Bild werden fünf Phasen im Engineeringprozess unterschieden (in einem vollen Prozess gibt es natürlich noch mehr mit zusätzlichen Analysedimensionen).

Problem and Vision:

Ausgangspunkt jedes Engineering Prozesses ist die Vision einer verbesserten neuen Situation (:= SOLL, NORM...) gegenüber einer als unbefriedigend erkannten Ausgangssituation (:= IST). Unbefriedigend kann vieles heissen: Es gibt überhaupt noch keine Lösung; eine vorhandene Lösung ist zu teuer, hat zu viele Fehler, ist zu kompliziert, erzeugt zu viele Unfälle, .... Verbessert kann bezogen auf die Ausgangslage dann heissen: Überhaupt eine Lösung, preisgünstiger, weniger Fehler, einfacher, weniger Unfälle....

Requirements with Behavior Modeling:

Sobald die Vision der neuen Lösung hinreichend klar ist, muss man versuchen, diese erste Vision soweit zu präzisieren, dass man auf der Basis dieser Beschreibung ein konkretes System entwerfen, implementieren und gegen die Anforderungen testen (:= Validierung) kann. Diese Präzisierung erfolgt innerhalb der Anforderungsmodellierung (Requirememnts Engineering). Mindestens als natürlichsprachlicher Text, dann aber auch in Form von visuellen Modellen, die sich eineindeutig auf formale Strukturen abbilden lassen, mit denen sich computergestützte Verifikationen vornehmen lassen. Der Inhalt dieser Anforderungsmodellierung wird gebildet durch die angezielten neuen Aufgaben (Tasks), die in Form von beobachtbaren Aktionen/Handlungen zwischen der Oberfläche (Surface, Interface (I)) des intendierten Benutzers (Mensch (M), User (U), des intendierten Systems (S) und der unterstellten Umgebung (U)(Environment (E)). Diese Beschreibungen müssen so präzise sein, dass sich auf deren Basis zweifelsfrei sowohl die Systemfunktion modellieren lässt wie auch später die Validierung vorgenommen werden kann.

System Modeling:

Liegt durch die Anforderungsmodellierung eine präzise Beschreibung der Systemoberfläche samt dem gewünschten Systemverhalten im Kontext von definierten Aufgaben vor, dann muss eine Systemfunktion modelliert werden, die diese Anforderungen erfüllt. Auch hier wird heute nach Möglichkeit mit formalen Darstellungsmitteln gearbeitet, die automatische Verifikation zulassen.

Implementation:

Das Modell der Systemfunktion muss implementiert werden. Dafür gibt es eine breite Palette von Möglichkeiten. Der Trend geht dahin, das Modell der Systemfunktionen automatisch in ein konkretes System zu konvertieren (dies setzt ein vollständig formalisiertes Systemmodell voraus).

Validation:

Liegt ein konkretes System vor, dann muss es auf der Basis der Anforderungsmodellierung bzgl. seines konkreten Verhaltens getestet werden (bei komplexen Systemen werden dazu weitgehend auch Simulatoren hinzugezogen).

In dieser Vorlesung liegt der Schwerpunkt auf der Modellierung der Systemfunktion. Verhaltensmodellierung, Implementierung und Validierung werden als 'Add on' gesehen. Damit ist gemeint, dass dies auch geschehen soll, dass dies aber aufgrund der sehr knappen Zeit nur ansatzweise, exemplarisch vorgenommen werden kann. Hier ist jeder aufgerufen, seine eigenen darüberhinausgehenden Experimente zu machen.