|
Auszug aus dem ForschungsForum Paderborn (Autoren: Prof. Dr. Gregor Engels, Dipl.-Inform. Jens Gaulke und Dipl.-Inform. Stefan Sauer)
In jeder wissenschaftlichen Disziplin werden Modelle der Realität entwickelt, um für den jeweiligen Bereich ein besseres Verständnis und einen tieferen Einblick zu entwickeln. Modelle werden zum systematischen Entwurf, zur Überprüfung und Analyse, zur Bewertung und zur Optimierung eines Systems eingesetzt. Außerdem können sie zum einen als Vertragsgrundlage zwischen einem Auftraggeber und einem Entwickler dienen, zum anderen auch als Dokumentation eines Systems im Verlauf seiner Erstellung und späteren Wartung. In jedem Fall ist es hierbei wichtig, wenn alle Leser der Modellbeschreibung dasselbe Verständnis von dem Modell haben.
Warum wird ein Modell angefertigt?
Ein solches Modell, in dem die Anforderungen an das System präzisiert werden, wird häufig in enger Zusammenarbeit zwischen einem Auftraggeber und dem für die Realisierung verantwortlichen Softwareentwicklungsteam angefertigt. Die Modellbeschreibung wird dazu in einer Sprache erstellt, die sowohl vom Auftraggeber als auch von Softwareentwicklern
verstanden werden muss. Da man im Allgemeinen nicht davon ausgehen kann, dass der Auftraggeber (künstliche) Programmiersprachen versteht, muss die Modellierungssprache entweder eine (natürliche) Umgangssprache sein oder eine leicht verständliche Kunstsprache. Da Beschreibungen in natürlicher Sprache häufig verschiedene Interpretationen zulassen und deshalb nicht präzise. In diesem Sinne kann das Modell als Vertragsgrundlage zwischen Auftraggeber und Softwareentwicklungsteam dienen.
Bei der Entwicklung technischer Systeme ist es heutzutage üblich, dass Teile des Systems von externen Partnern, so genannten Zulieferern, erstellt werden. Hierbei wird dem Zulieferer ein Lastenheft, in der Regel eine textuelle Form einer Modellbeschreibung, übergeben. Der Zulieferer entwickelt dann einen entsprechenden Prototypen bzw. letztendlich ein Produkt (vgl. hierzu Abbildung 1). Auf Grund der angesprochenen möglichen Fehlinterpretationen können dann allerdings mehrfache (vermeidbare und zeitraubende) Rücksprachen mit dem Auftraggeber notwendig werden oder sogar fehlerhafte Produkte erstellt werden. Die Benutzung einer präzise definierten Modellierungssprache hat den weiteren Vorteil, dass die erstellten Modelle analysiert und dadurch Fehler und Missverständnisse frühzeitig erkannt werden können.
Wie wird ein Modell in UML angefertigt?
Das Erstellen eines Modells geschieht in mehreren Schritten. Zunächst wird grob an die Aufgabenstellung herangegangen: Welche Strukturen können identifiziert werden? Welche (Teil-) Objekte sind enthalten? In welcher Beziehung stehen die Objekte zueinander? Zu diesem Zweck stellt die UML das Klassendiagramm zur Verfügung.
Der nächste Schritt bei der Modellierung besteht daher in der Identifizierung und Strukturierung der ausführbaren Systemfunktionen. Diese Systemfunktionen, auch Anwendungsfälle (engl.: use cases) genannt, werden mithilfe eines UML Use-Case-Diagramms beschrieben. Es wird dargestellt, welche Funktionen es gibt und wie diese untereinander wechselwirken. Dabei wird nur die Funktion – also das, was sie leisten soll – beschrieben, aber noch nicht, wie sie dies leisten soll. Letzteres wird im dritten Schritt der Modellierung durch UML Statechart-Diagramme dargestellt. In Statecharts wird die Abfolge von Zuständen (States), die ein Objekt im Laufe seiner Existenz einnehmen kann, dargestellt. Statecharts sind bereits sehr implementierungsnah und können direkt als Grundlage zur Realisierung eines Simulationsprototypen oder des eigentlichen Softwaresystems dienen.
Die UML bietet darüber hinaus noch eine Reihe weiterer Diagramme an, um insbesondere das dynamische Verhalten eines Systems zu beschreiben. Hierzu zählen Sequenzdiagramme, Kollaborationsdiagramme oder Aktivitätendiagramme. Jede dieser Diagrammarten betont einen anderen Aspekt des dynamischen Verhaltens wie z.B. den zeitliche Ablauf oder das Kommunikationsverhalten zwischen Objekten eines Systems. Diese Diagrammarten werden deshalb alternativ oder ergänzend zu Statechart-Diagrammen bei der Modellierung eingesetzt.
Entstehung des Klassendiagramms
Für die Modellierung der Sitzsteuerung ist es wichtig, zunächst die einzelnen Teile der Steuerung zu identifizieren. Dies geschieht durch ein Klassendiagramm (vgl. Abbildung 3). Der Sitz besteht aus den Einzelteilen Kopfstütze, Lehne und Sitzkissen. Diese kann der Fahrer über Motoren positionieren, die in diesen Sitzteilen eingebaut sind. Der gesamte Sitz kann in der Höhe und der Länge verstellt werden, wozu drei weitere Motoren in den Sitz eingebaut sind. Desweiteren gibt es eine Sitzheizung und die Möglichkeit, den Sitz zu belüften. Die identifizierten Sitzteile wurden im Diagramm als Klassen dargestellt. Klassen beschreiben die grundlegende Struktur eines Objekts. Daher kann von den verschiedenen Motoren im Sitz auf „den Motor“ verallgemeinert (abstrahiert) werden. Jeder Motor hat die gleiche Funktionalität: Er kann links herum oder rechts herum laufen.
Entstehung des Use-Case-Diagramms
Im Use-Case-Diagramm werden die durch den Benutzer aufrufbaren Funktionen der Sitzsteuerung identifiziert. Dabei ist zu diesem Zeitpunkt nur wichtig, welche Funktionen es gibt. Wie die Funktionen das ihnen zugedachte Verhalten realisieren, wird getrennt modelliert. Grafisch wird eine Funktion, Use-Case genannt, durch eine Ellipse dargestellt. Zu jeder Ellipse existiert ein Text, der den Use-Case genauer beschreibt. Bei diesem Text kann es sich um stichwortartige Beschreibungen oder um ausführliche Darstellungen handeln. Wie beim Klassendiagramm gibt es Beziehungen unter den einzelnen Use-Cases.
Was ist ein Statechart?
Im Klassendiagramm wird die Struktur des zu entwickelnden Systems festgelegt; das Use-Case-Diagramm dient dazu, die Funktionalität des Gesamtsystems festzulegen, das der Außenwelt an der Schnittstelle angeboten werden muss. Um die Komponenten und Funktionen mit Leben zu erfüllen, reichen die bisher verwendeten Diagramme allerdings noch nicht aus. Statecharts können diese Aufgabe übernehmen, da sie das in den bisher eingesetzten Diagrammen beschriebene Modell verfeinern und Verhalten hinzufügen. Ein Statechart des Modells ist immer einer Klasse zugeordnet. In Abbildung 5 wird das zur Klasse Heizung gehörende Statechart beschrieben. Ein Statechart besteht aus Zuständen, von denen einer als Startzustand und mehrere als Endzustände ausgezeichnet werden können, und Transitionen zwischen diesen Zuständen, die durch bestimmte Ereignisse (Signale) ausgelöst werden. Zustände können im Sinne einer weiteren Verfeinerung hierarchisch komponiert werden, dann können Start- und Endzustände auf jeder Ebene verwendet werden.
Das im Statechart modellierte Verhalten wird nun den im Use- Case-Diagramm spezifizierten Funktionen zugeordnet. Die Transitionen zur Änderung der Heizstufe können auf entsprechende Use-Cases abgebildet werden.
Von UML zu Automotive UML
In einem gemeinsamen Forschungsprojekt mit der DaimlerChrysler AG in Stuttgart wird derzeit an einer solchen Entwicklung einer Automotive UML, einer Erweiterung der UML für den automobilspezifischen Kontext, gearbeitet. Hierbei steht insbesondere die Modellierung der interaktiven grafischen Bedienoberfläche im Vordergrund. Aufbauend auf früheren Arbeiten zur Entwicklung einer UML-basierten Modellierungssprache für Multimedia-Anwendungen wird UML um eine zusätzliche Diagrammart zur Modellierung der Bedienoberf läche erweitert. Durch dieses Präsentationsdiagramm (siehe Abbildung 7) können dann nicht nur die Struktur und das Verhalten einer automobilen Software modelliert werden, sondern auch deren Anzeige und interaktive Bedienung.
Weiterführende Informationen
Erfahrungen mit der UML beim Entwurf von Kfz-Steuerungen beschreiben Marco Götze und Wolfram Kattanek.
|
