Montag, 22. Juli 2013

Ordnung für Use Cases und User Stories durch Funktionsgruppen

These: Gut kommunizierte Software ist ein Segen für die Zukunft.

Artikelübersicht
1. Teil Ordnung für Use Cases und User Stories durch Funktionsgruppen.
2. Teil Von den Funktionsgruppen zu logischen Komponenten.
3. Teil Von der logischen Komponente zur technischen Komponente.


Das Ergebnis des Requirements Engineering ist eine systematische Dokumentation der Anforderungen eines zu erstellenden Softwaresystems. Je nachdem, wie die Anforderungen erhoben und mit welchen Mitteln sie dokumentiert wurden, liegen eine Menge von User Stories oder Use Cases vor. Im weiteren Verlauf werden User Stories oder Use Cases für den Entwurf einer Architektur verwendet.

Am Anfang bilden wir Bereiche gleicher oder ähnlicher Funktionalitäten und ordnen die passenden User Stories oder Use Cases in diese Bereiche ein. "Die Funktionsbereiche können sich gegenseitig verwenden, zwischen ihnen fließen Daten, und sie können sich hierarchisch enthalten." [S.347, REUS09]

Im Folgenden möchte ich diese Funktionsbereiche Funktionsgruppen nennen. Funktionsgruppen können ein hierarchisches System aufbauen, dass heißt, Funktionsgruppen können Funktionsgruppen enthalten. Am Beginn einer Funktionsgruppenanalyse werden alle User Stories bzw. Use Cases einer Funktionsgruppe SYSTEM zugeordnet. Durch Bottom-Up- oder Top-Down-Analyse wird nun ein hierarchischer Funktionsgruppenbaum gebildet.



Die obige Darstellung soll das Prinzip verdeutlichen. Die grünen Quadrate, als Anwendungsfall gekennzeichnet, sind die einzelnen User Stories oder Use Cases. Auf der linken Seite befindet sich die Funktionsgruppenanalyse im Anfangsstadium. Alle User Stories bzw. Use Cases gehören der Funktionsgruppe System. Rechts daneben sind bereits zwei neue Funktionsgruppen eingeschoben worden. Das hierarchische Funktionsgruppensystem kann mit beliebig vielen Ebenen aufgebaut werden.

Dieses Modell bildet den Ausgangspunkt für die Findung von funktionalen Komponenten. Die Funktionsgruppen einer Ebene können als funktionale Komponenten aufgefasst werden. Zwischen diesen Komponenten können einfache Kommunikationsbeziehungen in Form fließender Daten eingezeichnet werden. Diese Datenflüsse sind Nachrichten, die von der einer Komponente zur anderen Komponente gesendet werden. Diese Nachrichten bilden die erste Grundlage für spätere Schnittstellenüberlegungen. Es können auch Datenquellen und Datensenken Endpunkte der Nachrichtenströme sein. Wir schicken eine Nachricht an eine Datensenke und lesen eine Nachricht aus einer Datenquelle.



Die Funktionsgruppenanalyse setzt auf der Funktionalität des Requirements Engineering auf und bildet den direkten Übergang zur Softwarearchitektur. Durch die Visualisierungen ist das Ergebnis schnell zu kommunizieren und durch das Team zu diskutieren. An diese funktionale Architekturanalyse schließen sich die logische und die technische Architekturanalyse an. Diese werde ich in den nächsten Posts dieses Themenabschnittes behandeln.

  • [REUS09] Ralf Reussner, Wilhelm Hasselbring: "Handbuch der Software-Architektur", 2. überarbeitete und erweiterte Auflage, dpunkt.verlag GmbH, Heidelberg, 2009


folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Kleine Randnotiz:

    "Die obige Darstellung soll das Prinzip verdeutlichen. Die grünen Quadrate, als Anwendungsfall gekennzeichnet, sind die einzelnen User Stories oder Use Cases"

    Use Cases sind ein Artefakt der Systemanalyse. User Stories sind ein Projektmanagement-Artefakt.

    Ein kleiner, aber relevanter Unterschied.

    AntwortenLöschen
  2. Kleine nette Provokation :-) Ich würde gerne den Unterschied zwischen User Stories und Use Cases noch etwas verwischen. Dazu möchte ich in Zukunft eine Diskussionen führen. Ich gebe Dir /Ihnen ? natürlich an dieser Stelle recht!

    AntwortenLöschen
  3. ... und wie sieht es bei Systemen aus, wo das Ergebnis des Requirement Engineerings zugleich der Prototyp ist?

    Wie z.B. bei Systemen, die direkt über (Zustands-)Automaten dargestellt werden, wie z.B. Steuerungen?

    Wie z.B. bei Systemen zur Numerischen Berechnung?

    fragt Hans Adams

    AntwortenLöschen
  4. Vielen Dank für diesen Hinweis! Natürlich kann diese Methode nicht pauschal angewandt werden. Ich habe sie vor allem aus der Sicht von Enterprise Application-Architekturen betrachtet. Das ist mein hauptsächliches Betätigungsfeld.

    AntwortenLöschen
  5. Hallo Ralf,
    mach weiter !
    Gruß Thomas

    AntwortenLöschen