DSD und das Use-Case-Diagramm

Die Verwandlung von Use Cases – funktioniert auch ohne Vollmond

Im Folgenden möchten wir Ihnen unser DSD-Regelwerk für das Use-Case-Diagramm vorstellen. Das Use-Case-Diagramm stellt einen ersten Überblick über die Funktionen, die das System realisieren soll, dar. Ein Use-Case-Diagramm besteht aus einer Systemgrenze, den Anwendungsfällen des Systems, externen Akteuren und deren Interaktionen mit dem System bzw. mit den Use Cases. Zusätzlich betrachten wir die <<include>>- sowie die <<extend>>-Beziehung zur Verbindung einzelner Use Cases.

Die Transformation dieser Notationselemente in natürlichsprachliche Anforderungen beschreiben wir in unserem Regelwerk. In diesem Blogeintrag werden wir Ihnen anhand von 3 Beispielregeln das Konzept der Transformation von UML-Diagrammen vorstellen. Dabei zeigen wir Ihnen zu jeder abstrakten Regel jeweils ein natürlichsprachliches Beispiel.

Beginnen möchten wir mit unserer ersten Regel (Abbildung 1 – Transformation des Use-Case) für den Transformationsprozess. Diese bezieht sich auf das Use-Case-Diagramm unter der Bedingung, dass keine weiteren Verfeinerungen für den Anwendungsfall vorhanden sind. Die zweite Variante dieser Regel bezieht sich auf das Gegenteil – es sind Verfeinerungen vorhanden. Verfeinerungen sind Anforderungen, die einen übergeordneten Use Case genauer beschreiben, z. B. in Form eines Aktivitätsdiagrammes oder natürlichsprachlicher Anforderungen. Include-Beziehungen und/oder Extend-Beziehungen gelten nicht als Verfeinerung, da sich die inkludierten, beziehungsweise erweiterten Use Cases auf derselben Ebene befinden.

Weiterhin müssen bei der Transformation Beziehungen zwischen den Use Cases beschrieben werden.

An dieser Stelle hoffen wir, dass Sie einen Einblick in die Regeln für das Use-Case-Diagramm erhalten haben. Falls Sie Interesse an dem vollständigen Regelwerk haben, schreiben Sie uns einfach eine Mail an heureka@sophist.de.

Zusätzlich möchten wir Sie auch auf unser RE-Buch [1] hinweisen, indem wir auf das Thema DSD detaillierter eingegangen sind. Im nächsten Eintrag dieser Blogserie werden wir uns mit dem Aktivitätsdiagramm beschäftigen und zeigen, welche Regeln wir zur Transformation von Aktionen, Partitionen,  Entscheidungsknoten und Co. gefunden haben. Wenn Sie schon immer einmal wissen wollten, wie Sie die Informationen aus einem Aktivitätsdiagramm natürlichsprachlich dokumentieren, schauen Sie doch einfach wieder rein!

[1]       Rupp, C., SOPHIST GmbH: Requirements-Engineering und –Management
Hanser, München, Wien 2009