Von der Anforderung zum Modell
Eine wichtige Disziplin des Systems Engineering ist die Analyse der Anforderungen. Es gibt genug Studien, die belegen, dass die Behebung eines Problems in der Anforderungsphase um Größenordnungen günstiger ist als in späteren. Daher hat die Anforderungsanalyse eine ganz besondere Bedeutung. In diesem Artikel stelle ich eine Methode vor, um von Anforderungen zu einem soliden Modell zu kommen.
Die Methode von Cimatti
Das hier vorgestellte Basiert auf der wissenschaftlichen Arbeit von Alessandro Cimatti et al., aber das sollte niemanden abschrecken. In seinem Paper From Informal Requirements to Property-Driven Formal Validation hat Cimatti zum Ziel, die Anforderungen vollständig zu formalisieren. Ich beschränke mich hier nur auf den ersten Schritt einer praxisgerechten Anforderungsanalyse, die eine hervorragende Vorbereitung auf eine anschließende Modellierung ist – egal, welche Modellierungssprache gewählt wird.
Die Methode wird von einer Kette von Werkzeugen realisiert, die auf de-fakto Industriestandards basieren (wie Rational RequisitePro und Software Architekt), zusammen mit einer erweiterten Version des NuSMV Model Checkers. (Cimatti et. al.)
Cimatti beschäftigt sich mit vier Herausforderungen: Erstens ist natürliche Sprache von Natur aus schwammig. Zweitens gibt es oft Anforderungen, die für das gesamte System gelten und daher nicht einfach zu modellieren sind. Drittens fehlen bei der Validierung oft klare Kriterien zur Bewertung. Weniger relevant für diesen Artikel ist die vierte Herausforderung: Formale Modellierungssprachen sind nicht unbedingt für formale Verifizierung geeignet.
Cimatti teilt die Arbeit in drei Phasen: In der ersten Phase werden die Anforderungen in Satzfragmente aufgebrochen und klassifiziert. Das werde ich hier beschreiben.
In der zweiten Phase werden die Fragmente formalisiert, und zwar auf unterschiedliche Weise, je nach Klassifizierung. In der dritten Phase wird eine formale Analyse durchgeführt, die Probleme wie Inkonsistenzen und anderes entdeckt.
Klassifizierung von Anforderungs-Fragmenten
Es ist nicht ungewöhnlich, Anforderungen zu klassifizieren. Ein Klassiker ist die Unterteilung in funktionale und nicht-funktionale Anforderungen. Aber die Klassifizierung von Cimatti ist besonders geeignet für eine anschließende Modellierung. Bevor wir uns das Aufbrechen der Anforderungen in Fragmente vornehmen, sehen wir uns mal die Kategorien an. Die dazugehörigen Fragen helfen, die Kategorisierung vorzunehmen:
| Bedingung für Fragment | Kategorie |
| Definiert das Fragment ein Konzept der Domäne? | Glossar |
| Beschreibt das Fragment ein Systemmodul, und beschreibt es, wie Module interagieren? | Architektur |
| Beschreibt das Fragment die Schritte, die ein Modul durchführt, oder die Zustände, die ein Modul annehmen kann? | Funktional |
| Beschreibt das Fragment Nachrichten, die zwischen Modulen ausgetauscht werden? | Kommunikation |
| Beschreibt das Fragment Bedingungen oder Einschränkungen des zukünftigen Systems? | Verhalten |
| Beschreibt das Fragment Einschränkungen bezüglich der Umwelt oder Betriebsumgebung? | Betriebsumgebung |
| Beschreibt das Fragment ein mögliches Scenario der Domäne? | Scenario |
| Beschreibt das Fragment eine erwartete Eigenschaft der Domäne? | Eigenschaft |
| Ist das Fragment eine Anmerkung in der Spezifikation, welche keine Information über Ontologie oder Verhalten des spezifierten Systems beschreibt? | Anmerkung |
Als Beispiel wurde der altbewährte Fahrstuhl herangezogen und folgende Anforderung betrachtet (ob dies eine gute „Anforderung“ ist, sei dahingestellt“:
Anforderung: Zu einem typischen Aufzug gehören Ruftasten zum Auswählen eines Stockwerks.
Aus dieser Anforderungen lassen sich eine Anzahl von Fragmenten extrahieren. Zunächst sind da die drei Glossar-Fragmente „Aufzug“, „Ruftaste“ und „Stockwerk“. Das Fragment „Auswählen eines Stockwerks“ ist funktional. Im Fachartikel befinden sich weitere Beispiele.
Beziehungen zwischen Fragmenten
Cimatti stellt im nächsten Schritt Beziehungen zwischen den Fragmenten her. Da er ein rigoroses Vorgehen anstrebt, macht das Sinn. Wenn es um Systeme geht, die nicht sicherheitskritisch sind, so ist dies sicherlich nicht unbedingt notwendig. Cimatti kennt die Beziehungen „starke Abhängigkeit“, „schwache Abhängigkeit“ und „Verfeinerung“.
Modellierung der Fragmente
Cimatti geht es um eine vollständige Modellierung. Um das zu erreichen, greift er, wenn möglich, auf populäre Modellierungssprachen wie UML zurück. Das Klassendiagramm im Bild oben zeigt bspw. den Glossar. Das ist aber nicht für alle Fragmente ausreichend, daher bedient er sich auch sprachen, die eher akademisch angehaucht sind, wie CNL (Controlled Natural Language) und LTL (Linear Time temporal Logic).
Wie man nun vorgeht, hängt vom konkreten Projekt und den Zielen ab. Meiner Erfahrung nach ist es schon schwer genug, Akzeptanz für UML in der Praxis zu bekommen. Insofern würde ich empfehlen, mit einer Mischung aus UML und Text auszukommen. Schon die sauber klassifizierten Fragmente sind eine hervorragende Grundlage für jede weitere Entwicklung.
Hier ist meine Empfehlung für eine UML-basierte Entwicklung. Letzten Endes hat jedes Projekt andere Bedürfnisse, die für beim konkreten Modellierungsansatz berücksichtigt werden müssen.
| Kategorie | Empfohlenes UML-Modellelement | Cimatti |
| Glossar | Klassendiagramm. Dies ist auch die Empfehlung von Cimatti | UML Klassen |
| Architektur | Je nach System kann hier mit Komponentendiagramm oder Verteilungsdiagramm eingesetzt werden. Möglicherweise reicht auch einfach eine textuelle Beschreibung. | -/- |
| Funktional | Cimatti empfiehlt Zustandsdiagramme, allerdings können hier auch Aktivitätsdiagramme eingesetzt werden, manchmal reichen auch die Operationen von Klassen. | UML Zustandsdiagramme |
| Kommunikation | Hier kann mit Kommunikationsdiagramm oder Sequenzdiagramm gearbeitet werden. | -/- |
| Verhalten | Hier empfehle ich den Einsatz von Constraints, die von vielen UML-Elementen unterstützt werden. | CNL |
| Betriebsumgebung | Diese können ebenfalls mit Constraints festgehalten werden, oder auch zentral in natürlicher Sprache. | CNL |
| Scenario | Während Cimatti Sequenzdiagramme empfielt, können hier auch Anwendungsdiagramme zum Einsatz kommen. | Sequenzdiagramme |
| Eigenschaft | Eigenschaften werden klassisch als Constraints modelliert | CNL |
| Anmerkung | Das klassische Werkzeug für Anmerkungen sind UML-Notizen. Allerdings passen diese oft auch in die Beschreibung von Elementen, oder auch in die Package-Beschreibung. | -/- |
Fazit
Eigentlich wurden hier nur zwei „Werkzeuge“ für die Anforderungsanalyse vorgestellt: Das Aufbrechen der Anforderungen in Fragmente und deren Klassifizierung. Neu hier ist, dass die Klassifizierung hervorragend für eine anschließende Modellierung geeignet ist.
Ich kann die Lektüre des ganzen Papers von Cimatti et al. empfehlen. Für wirklich sicherheitskritische System kann sich der Aufwand vielleicht sogar lohnen. Für alles andere muss man sich die Rosinen heraussuchen – zum Beispiel die eben vorgestellten.
Bildquelle: Alessandro Cimatti
