Anbieter zum Thema
Mit anwendungsfallgetriebenem Design von der Breite in die Tiefe
Im Rahmen des Vorgehens versuchen wir zunächst, möglichst viele relevante Systemanwendungsfälle zu ermitteln – um anschließend iterativ-inkrementell jeden Anwendungsfall für sich fachlich zu detaillieren. Dieses anwendungsfall-getriebene Vorgehen gibt uns die Chance, funktionale Abläufe von einander separiert zu verstehen und mit dem Auftraggeber zu klären. Wir können früh Analyseergebnisse vorlegen und in kurzen Iterationszyklen regelmäßig mit dem Kunden abstimmen. So bekommen wir schnell wertvolles Feedback.
Für ein schnelleres Verständnis einer Systemanwendung ist es sehr hilfreich, sich bei der Beschreibung jedes Anwendungsfalls nicht gleich in Details zu verlieren sondern mit den elementaren Schritten zu beginnen. Dies ist die essenzielle Anwendungsfallbeschreibung, das Sunshine-Szenario der Dienstleistung. Welche Schritte muss das System auf jeden Fall für einen Anwendungsfall ausführen, um das Ergebnis zu erhalten, worauf kann nicht verzichtet werden? Dieses Szenario wird zuerst geklärt.
Die essenziellen Beschreibungen führen zu einem einheitlichen Abstraktionsniveau in der Beschreibung der Abläufe, ermitteln gemeinsame Schritte von Anwendungfällen und sind die Basis für weitere Detaillierungen. Sie sollten eng mit dem Auftraggeber oder Fachexperten abgestimmt werden.
Die weitere Detaillierung geschieht dann mit einfach lesbaren UML oder SysML Aktivitätsdiagrammen. Formuliert pro Anwendungsfall beschreiben sie den exakten Ablauf der essenziellen Schritte und auch alle möglichen Ausnahmen, Fehlerfälle und Variationen im Ablauf. Aktivitätsdiagramme der UML und SysML ähneln ein wenig Petri-Netzen, sind aber völlig eigenständig definiert. Aktivitätsdiagramme beschreiben einen möglichen Systemablauf auf Basis elementarer Schritte und können beliebig detailliert formuliert werden.

Die Abläufe können seriell oder parallel sein, sie können synchronisiert werden, Aufteilung und Zusammenführung von Abläufen ist darstellbar. Sie lassen sich auch ineinander schachteln. So ist es möglich, alle relevanten Informationen in einem Diagramm mit einheitlichem Abstraktionsniveau so zu formulieren, dass sie für den Leser leicht verständlich und nachvollziehbar sind. Für Details oder die Beschreibung von gemeinsamen Schritten von Anwendungsfällen verweisen wir auf andere Aktivitätsdiagramme (siehe Abbildung 4).
Wie sage ich es den anderen? Werkzeuge für den Austausch
Modellierungswerkzeuge unterstützen uns darin, die Informationen über die Anforderungsdetaillierung zu erstellen und strukturiert abzulegen. Mit ihnen können wir Modellelemente (beispielsweise ein Requirement, ein Anwendungsfall, einen Akteur) in verschiedenen Diagrammen und in unterschiedlichen Kontexten darstellen – modellieren müssen wir den jeweiligen Systemteil nur ein einziges Mal. So können wir mehrere Diagramme schnell erstellen und ein Diagramm in seiner Detaillierung ganz den Bedürfnissen des Lesers anpassen. Einfachere, abstraktere Darstellungen erstellen wir für Leser, die einen schnellen Überblick erhalten möchten - verwirrende DIN-A0-Tapeten (wer kann sich solche Drucker überhaupt leisten?) bleiben ihm so erspart. Exaktere Detaillierungen sind notwendig für die spätere Realisierung und werden in weiteren Diagrammen erläutert.
Modellierungswerkzeuge ermöglichen es uns auch, Systeminformationen durch Dokumentationsgenerierung schnell auszutauschen. HTML-Dokumentation über ein System, beispielsweise in einem Intranet oder Wiki verlinkt, sind ein gutes, leicht navigierbares Nachschlagewerk. Und für geforderte Anforderungsdokumente werden dann Word- oder PDF- Dokumente erzeugt.
Mit Hilfe des umrissenen Vorgehens lassen sich einzelne Systemdienstleistungen getrennt voneinander mit dem Auftraggeber abstimmen. Wir erhalten so schnelle, kürzere Iterationszyklen, und bekommen früh Feedback. Realisierungsaufwände lassen sich auf Basis von Systemanwendungsfällen abschätzen und so in eine Planung integrieren. Und auch die Realisierung der Systemfunktionalität kann anwendungsfall-getrieben geschehen: so ist eine schrittweise Erweiterung der Systemfunktionalität möglich. Auch in der Realisierungsphase kann dann noch flexibel und agil auf Anforderungsänderungen eingegangen werden.
*Christel Sohnemann (christel.sohnemann@oose.de) ist Trainerin und Beraterin der oose Innovative Informatik GmbH (www.oose.de). Sie leitet Seminare und coacht Projekte, u. a. zu Themen der objektorientierten Softwareentwicklung, des Requirements Engineering und im Bereich des Systems Engineering. Ihr Schwerpunkt sind die Methodik und die Entwicklung technischer Systeme; sie hat langjährige Erfahrungen in der Entwicklung von Echtzeitsystemen, u. a. im Bereich der Medizintechnik.
(ID:283092)