Darstellung der Variabilität von Software-Produktfamilien durch Use Cases

Auch für die Darstellung der PF-Variabilität ist es, wie in Kapitel 3 erläutert, notwendig, Variabilität in nicht-funktionalen Anforderungen zu beachten (z.B. Dienstgüte). Hierzu ist es im Gegensatz zur Einzelapplikationsentwicklung erforderlich, dass zu einem Use Case mehrere nicht-funktionale Varianten (bzw. Anforderungen) betrachtet werden können (müssen). Da nicht-funktionale Anforderungen, wie in Abbildung 4-5 illustriert, am besten im Zusammenhang mit den dazugehörigen funktionalen Anforderungen betrachtet werden können, sollen an dieser Stelle UCTs genutzt werden, um die Variabilität in nicht-funktionalen Anforderungen textuell zu beschreiben. Um Variabilität zu beschreiben, sind wie bereits erwähnt Variationspunkte und Varianten notwendig. Für die Darstellung der Variabilität in nicht-funktionalen Anforderungen beschreiben Variationspunkte die allgemeinen Aspekte der nicht-funktionalen Anforderungen und Varianten sodann die speziellen Aspekte. Die folgenden beispielhaften Ausschnitte von Anwendungsfallbeschreibungen beschreiben zwei Varianten, die den Variationspunkt „Check-In“ erweitern. [...]

Darstellung der Variabilität von Software-Produktfamilien durch Use Cases Die Beschreibung nicht-funktionaler Anforderungen kann in UCTs allerdings sehr detailliert erfolgen, sodass alle zu einer Funktion gehörenden nicht-funktionalen Anforderungen beschrieben werden können. Problematisch ist allerdings eine Darstellung bzw. Prüfung von Abhängigkeiten unterhalb der nicht-funktionalen Anforderungen eines bzw. unterschiedlicher Use Cases. Um solche Abhängigkeiten überprüfbar zu machen, sind Abhängigkeits-Links erforderlich, wie sie z.B. von gängigen RE-Tools (z.B. Slate, Doors) angeboten werden, um sie durch eine Abhängigkeitsmatrix oder Abhängigkeitstabelle darstellen zu können. Eine andere Möglichkeit funktionale und nicht funktionale Anforderungen abzubilden, bietet die User Requirements Notation (URN) auf Basis von Use Case Maps (UCM), ein von der ITUT entwickelter Standard [IUT-T00]. Die NFRs (bzw. Softgoals, wie sie in diesem Ansatz genannt werden) lassen sich dabei in unterschiedlichen Modellen detaillieren. Dieser Ansatz soll an dieser Stelle jedoch nicht weiter verfolgt werden, da dies den Rahmen der Arbeit sprengen würde. [...]

Die Darstellung bzw. Beschreibung von Daten kann durch Use Case Templates nur unzureichend befriedigt werden, da weder Relationen noch Kardinalitäten dargestellt werden können. Allerdings sind Use Cases auch nicht dazu gedacht, Daten abzubilden, sondern vielmehr um Funktionalität aus abstrakter Sicht zu beschreiben. Für die Beschreibung von Daten und deren Relationen werden in der objekt-orientierten Modellierung oftmals Objektmodelle genutzt. Solche Objektmodelle können dann zusätzlich einem Use Case hinterlegt werden. An dieser Stelle soll allerdings nicht weiter darauf eingegangen werden, da es hier um die Darstellungsmöglichkeiten durch Use Cases selbst geht. Für die Beschreibung von Datenflüssen zwischen Benutzer (Akteur) und Anwendungsfall werden hingegen Sequenzdiagramme genutzt. Da Daten(-flüsse) und Abläufe i.d.R. durch Funktionen getrieben werden, erscheint es sinnvoll, variable Abläufe und Daten den dazugehörigen Use Cases zu hinterlegen. Das heißt, wenn ein Use Case Icon eine abstrakte Funktion des Systems beschreibt, dann beschreibt das 34 [...]