Seit Jahrzehnten werden Anforderungen hauptsächlich in natürlicher Sprache verfasst. Dafür gibt es viele gute Gründe, wie wir bereits in dieser Serie erläutert haben. Auch Modellierungsverfahren zur Anforderungserhebung wurden in der Vergangenheit eingesetzt, jedoch nicht auf standardisierte Weise.
Modellieren in den alten Tagen
Bevor Systemmodellierung standardisiert wurde, wurden dennoch Modelle verwendet. Zu den Modellen gehören physische Modelle, wie der Rumpf eines Schiffes. Prototypen und Mock-ups sind weitere Beispiele für physische Modelle. Und seit Menschengedenken wurden Modelle auf Papier in Form von Skizzen, Flussdiagrammen und Ähnlichem erstellt. Einige dieser Modelle waren informell und dazu bestimmt, weggeworfen zu werden, andere verwendeten eine formellere Notation und wurden während des gesamten Systementwicklungszyklus beibehalten.
Vereinheitlichte Modellierungssprache
Aber der eigentliche Durchbruch gelang mit der Entwicklung der Unified Modeling Language (UML). Für diejenigen, die sie nicht kennen: UML ist eine grafische Modellierungssprache für allgemeine Zwecke, die die strukturellen und verhaltensbezogenen Aspekte eines Systems abdeckt. Kurz gesagt, formalisiert sie die Verwendung von “Kästen und Pfeilen”, um ihnen eine klar definierte Syntax und Semantik zu geben. Es gibt viele Grundlagen der UML online.
Wikipedia hat ein schönes Bild, das die Konvergenz verschiedener proprietärer Modellierungssprachen in einer öffentlich standardisierten vereinheitlichten Modellierungssprache zeigt. Durch die Standardisierung und das Fehlen von Einschränkungen konnte UML schnell eine breite Akzeptanz finden.
Bevor sich jemand über die Formalität von UML (oder das Fehlen davon) beschwert, möchte ich zwei Dinge anmerken: Erstens kann UML so formell oder informell verwendet werden, wie man möchte (manche würden sogar die Verwendung von UML zur reinen “Malerei” missbilligen); Zweitens werde ich später in dieser Reihe über “echte” formale Sprachen sprechen und wie weit UML in diese Richtung getrieben werden kann.
Methoden für UML-Anforderungsmodellierung
Der Erfolg von UML hat auch eine Kehrseite: Im Laufe der Zeit entwickelte sie sich zu einem riesigen Ungetüm, und die Größe des Standards (und die Dicke der UML-Bücher im Buchladen) einschüchternd sein können. Daher sollte für jede anstehende Aufgabe die relevante Teilmenge der UML identifiziert werden. Außerdem ist UML ein Sprache. Wie die Sprache, die wir sprechen, kann sie auf viele verschiedene Arten verwendet werden, gut oder schlecht, und sogar falsch. Methode beschreibt, wie die Sprache angewendet werden soll. Dies adressiert typischerweise auch die Problematik, die zu verwendenden UML-Elemente einzugrenzen.
Viele Organisationen entwickeln oder passen ihre eigenen Methoden an. Wenn noch nichts vorhanden ist, ist es immer eine gute Idee, mit einer Methode zu beginnen, die dem Benötigten so nahe wie möglich kommt. Diese Methode kann dann für die betreffende Organisation oder das Projekt angepasst werden.
Die meisten Methoden verwenden UML-Anwendungsfälle (UC) zur Beschreibung der übergeordneten Anforderungen und UML-Klassendiagramme zur Beschreibung der Domäne. Von dort aus wird das Modell verfeinert, um weitere Details hinzuzufügen. Wie dies in der Praxis aussieht, wird im Folgenden beschrieben. Zunächst werden hier zwei Methoden (von vielen anderen verfügbaren) vorgestellt, die einen guten Ausgangspunkt für die UML-Anforderungsmodellierung bieten:
- Ikonix ist eine leichtgewichtige Methode aus den 90er Jahren. Sie versprach, mit nur vier UML-Diagrammen von den Anforderungen zum Code zu gelangen. Aus welchem Grund auch immer, ist sie nicht sehr bekannt. Ich halte sie für sehr nützlich für kleine und mittlere Softwareprojekte, die nicht sicherheitskritisch sind. Ich habe darüber geschrieben ICONIX in SE-Trends, mein deutscher Blog.
- SYSMOD ist eher eine Toolbox als eine Methode, aber sie enthält eine Reihe nützlicher Taktiken für das Anforderungsmodellierung. Eine auf SYSMOD basierende Methode wurde von Tim Weilkiens in verschiedenen Büchern beschrieben. Für eine gute Einführung empfehle ich das (etwas ältere) Systems Engineering mit SysML/UML.
UML-Anforderungen mit Anwendungsfalldiagrammen und Klassendiagrammen
In UML werden Anforderungen typischerweise in Use Cases (UC) erfasst. Ein Anwendungsfall beschreibt die Interaktion eines Benutzers mit dem System und kann normalerweise in einem einzigen Satz erfasst werden. Z.B. “Als Benutzer möchte ich mich vom System abmelden, damit niemand von dieser Browser-Sitzung aus auf mein Konto zugreifen kann”. Ein Anwendungsfall sollte eine ID haben (z.B. “Abmelden”). Es ist möglich, ein Bild des Anwendungsfalls zu zeichnen, wie unten gezeigt.
Entsprechend wird die Domäne modelliert und ersetzt ein traditionelles Glossar. Hierfür werden UML-Klassen verwendet. Diese sind wesentlich präziser als ein Glossar und zeigen klar definierte Beziehungen zwischen Klassen, die mit Attributen und Operationen angereichert werden können.
Bitte: Benutzen Sie es richtig!
Auf dieselbe Weise, wie die englische Sprache missbraucht werden kann, kann auch UML falsch angewendet werden. Es ist sehr einfach, etwas zu “malen”, das richtig aussieht, aber die falsche Bedeutung hat. Lassen Sie mich daher hier appellieren: Nehmen Sie sich Zeit, die Bedeutung hinter den von Ihnen verwendeten Elementen zu verstehen. Ob eine Linie durchgezogen oder gestrichelt ist, kann einen großen semantischen Unterschied machen.
Erfahrene Anwender runzeln oft die Stirn, wenn UML “nur” als Zeichnung verwendet wird. Also, wenn das Modell nicht weiterverarbeitet wird. Ich habe damit kein Problem, wenn es die Kommunikation verbessert. Das größte Problem, das ich hier sehe, ist, dass der Autor keine Rückmeldung über die korrekte Verwendung der Sprache erhält.
Das Diagramm ist nicht das Modell
Auf den ersten Blick scheint es, als ginge es bei UML nur um Diagramme. Aber wenn es richtig gemacht wird, ist es ein Nebenprodukt des Modellierungsprozesses, wenn auch ein nützliches. Das Diagramm hilft, das “große Ganze” zu erfassen. Es dient als Karte und hilft dem Leser, sich im Modell zurechtzufinden. Aber jedes Symbol im Diagramm liefert viele zusätzliche Informationen, die oft keine Entsprechung im Bild haben. Um dies zu demonstrieren, betrachten wir den Anwendungsfall. Das Bild zeigt nur die Kennung und die Beziehung zum Akteur. Die folgende Tabelle zeigt einige der Informationen, die ebenfalls Teil des Modells sein können:
| UC-Name | Abmelden |
| Schauspieler | Jeder angemeldete Benutzer |
| Beschreibung | Als Benutzer möchte ich mich vom System abmelden, damit niemand von dieser Browsersitzung aus auf mein Konto zugreifen kann. |
| Vorbedingungen | Benutzer ist im System angemeldet |
| Aktivität | [Benutzer] initiiert Abmeldung [System] meldet den Benutzer vom System ab und zeigt eine entsprechende Meldung an |
| Nachbedingungen | Benutzer wurde vom System abgemeldet |
Entsprechend könnte das Modell der Klasse Attribute, Operationen, Constraints und vieles mehr enthalten.
Formeller werden
Im Beispiel sind wiederum große Teile des Modells informell. Die Vor- und Nachbedingungen des Use Cases sind zum Beispiel in einfachem Text formuliert. Allein durch die Kennzeichnung als Constraints wird jedoch ein Mehrwert geschaffen. Aus dem Modell können zum Beispiel eine große Anzahl von Testfällen abgeleitet werden, indem einfach geeignete Testszenarien für alle Constraints entwickelt werden.
Darüber hinaus bietet UML eine Reihe von Mechanismen zur Formalisierung der Spezifikation. Dies wird von ICONIX gut gemacht: Das Endprodukt der ICONIX-Methode ist Softwarecode. Und Code ist wohl ein formales Modell, das ausgeführt werden kann, um die gewünschte Funktionalität zu liefern. ICONIX erreicht dies, indem Use Cases (über Robustness Diagrams) in Sequenzdiagramme verfeinert und auf jeder Ebene Details hinzugefügt werden. Aktivitätsdiagramme und Zustandsdiagramme sind weitere UML-Modellelemente, die Details und Formalität hinzufügen.
Zuletzt gibt es das Objektbeschränkungsprache (OCL), eine textuelle Sprache, die es ermöglicht, einige der informellen Elemente formal und maschinenlesbar darzustellen.
Wo sind die Anforderungen?
Eine Sache scheint zu fehlen: Wo sind die Anforderungen? Sie sind immer noch da, aber sie haben eine andere Form angenommen. Insbesondere können viele Modellelemente als Anforderungen interpretiert werden. Sie sind beispielsweise in den Constraints (Vor-, Nachbedingungen und Invarianten) leicht zu erkennen, machen aber nur im Kontext des Modells Sinn, in das sie eingebettet sind. Daher entsprechen die Modellelemente der obersten Ebene, wie Klassen und Anwendungsfälle, nicht direkt einzelnen Anforderungen, sondern bilden den Kontext vieler eingebetteter Anforderungen. Das ist eigentlich ein großer Vorteil: In einer textuellen Spezifikation kann der Kontext der Anforderungen schwer zu erfassen sein, z.B. indem man ihn aus der Kapitelstruktur ableitet. In einem Modell hingegen ist der Kontext klar definiert. Wiederum am Beispiel des Anwendungsfalls betrachtet, ist die Vorbedingung nur im Kontext des Anwendungsfalls “Abmelden” relevant. Das bedeutet auch, dass alle Änderungen an der Spezifikation außerhalb des Anwendungsfalls keine Auswirkungen auf diese Vorbedingung haben. Auf diese Weise lassen sich Abhängigkeiten leicht beseitigen und das Problem in kleinere Teile aufgliedern, die unabhängig voneinander bearbeitet werden können.
Was kommt als Nächstes?
Es ist verlockend, alle Vorteile von UML zu nutzen, vielleicht sogar bis hin zur Codegenerierung. Obwohl dies möglich ist, ist es ratsam, UML für die Anforderungsmodellierung in kleinen Schritten einzuführen. Es gibt viele Fallstricke auf dem Weg, und zu viel auf einmal in den ersten Schritten zu versuchen, kann zu Misserfolgen und Ablehnung durch die Stakeholder führen.
Daher ist die UML-Anforderungsmodellierung großartig für agile Umgebungen, da sie es erheblich erleichtert, die Auswirkungen von Änderungen zu verstehen und zu begrenzen. Daher kann ich es nur empfehlen, es auszuprobieren.
Für Gruppen, die bereits mit der UML-Anforderungsmodellierung vertraut sind, kann die Erhöhung der Formalität einige Vorteile bringen. Es könnte auch interessant sein, den Formalitätsgrad insbesondere in sicherheitskritischen Umgebungen zu erhöhen. Wir werden in naher Zukunft über eine formellere Anforderungsmodellierung sprechen.
Bildquelle (bearbeitet): Joone via Flickr
