| Inhaltsübersicht |
|---|
| Modellierung der Wirklichkeit » |
| Modellierung von Systemen » |
| Lollipop-Notation » |
| Sonderfall Hardware » |
Verwendung von UML-Diagrammen in verschiedenen Entwicklungsphasen
Wie kritisch ich viele der Dokumente betrachte, die ich im Rahmen meiner Beratungstätigkeit zu sehen bekomme, wissen Sie: Zu sehr vermischen die Autoren Aspekte von Systemanforderung, Systemarchitektur, Zweckbestimmung, Projektplanung und Markterwartungen.
Nun bin ich auf einen weiteren Grund für diese Vermischung gestoßen: Die Firmen setzen UML-Diagramme in verschiedenen Phasen des Entwicklungsprozesses ein. Das ist auch gut so. Es ist auch gut, dass sogar ein einzelner Diagrammtyp wie ein Klassendiagramm in mehreren Entwicklungsphasen genutzt wird. Nur darf das nicht dazu führen, dass ein und die selbe Person diese Modellierung durchführt und dabei alle Ziele durcheinanderwirft.
UML Klassendiagramme zum Modellieren der „Wirklichkeit“
Lassen Sie mich das an einem Beispiel erläutern: Die Modellierung mit Klassendiagrammen ergibt ebenso bei der Beschreibung des Kontexts wie bei dem technischen Entwurf des Systems Sinn. Doch die Ziele sind völlig unterschiedlich: Im ersten Fall wollen Sie beispielsweise ausdrücken, dass ein Patient mehrere Diagnosen haben kann. Sie modellieren hier die „Wirklichkeit“.
Dieses Klassendiagramm könnten Sie beispielsweise während der Analyse der Stakeholder-Anforderungen einsetzen.
UML Klassendiagramme zum Modellieren eines Software-Systems
Im anderen Fall modellieren Sie ein Softwaresystem. Dieses Modell enthält technische Aspekte wie Datentypen, Aggregations- und Kompositionsbeziehungen, Managerklassen und Pattern.
Auch wenn das zweite Modell eine Evolutionsstufe des ersten sein wird, gehören dennoch beide Diagramme in unterschiedliche Dokumente. Es darf zudem nicht die Aufgabe der Entwicklung sein – wie ich das ständig beobachte – dass man eine allgemeine Beschreibung in der sehr beschränkten Konkretheit des ersten Diagramms der Entwicklungsabteilung zur Umsetzung gibt. Natürlich muss ein Produkt (Medizinprodukt, Softwaresystem) die Aufgaben in der „Realität“ unterstützen. Aber das erste Modell ist eines der Realität, das zweite Modell eines des Softwaresystems. Wenn Sie das verwechseln, haben Sie das Chaos in den Dokumenten.
Dieses zweite Klassendiagramm würde sich somit in einer Software-Architektur, d.h. in einem ganz anderen Dokument als das erste finden.
Lollipop-Notation bei UML-Komponenten- und Klassendiagrammen
Beschreibung von Schnittstellen in der Software-Architektur
Die IEC 62304 verlangt nicht nur, dass Sie die Komponenten identifizieren, sondern auch die Schnittstellen dazwischen. Besonders elegant (in Modell und Code – zumindest bei „Hochsprachen“) sind dabei Interfaces.
Es genügt nicht, die Interfaces nur zu benennen. Die IEC 62304 fordert eine Beschreibung der Schnittstellen
Doch mit dem Interface – wie oben in der Lollipop-Notation, die es ab UML 2.0 gibt – ist das Interface noch nicht vollständig beschrieben. Die Methoden, bestenfalls deren komplette Signatur mit Übergabe und Rückgabetypen, sollten Sie ebenfalls benennen.
Sie haben die Befürchtung, dass Sie damit zu viele Methoden spezifizieren müssten? Dann habe ich die Befürchtung, dass Sie zu „breite“ Schnittstellen und damit nicht wirklich lose gekoppelte Komponenten entwerfen.
Lollipop-Notation auch bei der System-Architektur d.h. bei Hardware
Wenn ich in einem Komponentendiagramm ausdrücken will, dass ein Mikroprozessor eine LED ansteuert, auf welche Seite kommt dann der Lollipop?
Das klingt nach einer eher akademischen Fragestellung, die ich dennoch sehr spannend finde. Die Antwort lautet: Beides ist möglich. Es hängt davon ab, was man ausdrücken will.
Wenn man den Lollipop zur LED zeichnet (unteres Bild), sagt man damit, dass die LED eine Schnittstelle anbietet, nämlich eine zum Ein- und Ausschalten, sprich einen Schalter. Diese Schnittstelle kann der Mikroprozessor nutzen. Wenn man hingegen ausdrücken will, dass der Mikroprozessor ein „Spannungsschnittstelle“ anbietet, die beispielsweise eine LED nutzen will, dann gehört der Lolliop auf die Seite des Microcontrollers (oberes Bild). Bei Software ist diese Unterscheidung meist einfacher.
Das oben geschilderte Problem tritt auch deshalb auf, weil hier die UML ausserhalb des Bereiches genutzt wird, für den die UML-Spezifikation gedacht ist. Es handelt sich nicht um eine Sprache zur Spezifikation von Systemen, sondern um eine zur Spezifikation von Software bzw. Software-Systemen.
Zum zweiten sollte man eine „Spannungsschnittstelle“ nicht in UML modellieren, weil die OMG UML Superstructure Specification schreibt:
„There are two fundamental premises regarding the nature of UML semantics. The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called “active” objects (see “Class (from Communications)” on page 453). This includes behaviors, which are objects in UML 2, which can be active and coordinate other behaviors. The second is that UML behavioral semantics only deal with event-driven, or discrete, behaviors. However, UML does not dictate the amount of time between events, which can be as small as needed by the application, for example, when simulating continuous behaviors.“
„Wirklich“ kontinuierliche Schnittstellen, wie eine „Spannungsschnittstelle“ wären somit nicht innerhalb der UML-Spezifikation. Die Sprache, die genau das leistet ist die SysML!
Mit Dank an Bernhard Fischer
