Beispielrichtlinien für die Erstellung von Anwendungsfallmodellen

 

Version <n.m>

Letztes Update <jjjjmmtt>

 

 


Revisionsprotokoll

Datum

Version

Beschreibung

Autor

 

 

 

 

 

 

 

 

 


Inhaltsverzeichnis

1.     Einführung

1.1   Verwendungszweck

1.2   Inhalt und Umfang

1.3   Definitionen, Akronyme und Abkürzungen 

1.4   Referenzen  

1.5   Übersicht

2.     Allgemeine Richtlinien für die Erstellung von Anwendungsfallmodellen

2.1   Allgemeiner Stil 

2.2   Kommunikationsbeziehungen verwenden  

2.3   Einschluss- und Erweiterungsbeziehungen verwenden    

2.3.1  Einschlussbeziehung verwenden 

2.3.2  Ausschlussbeziehung verwenden

2.4   Akteurgeneralisierung anwenden

2.5   Interaktionsdiagramme verwenden

2.6   Aktivitätsdiagramme verwenden

3.     Vorgehensweise beim Beschreiben eines Anwendungsfalls

3.1   Richtlinien für Akteure

3.1.1  An jedem konkreten Anwendungsfall ist mindestens ein Akteur beteiligt.

3.1.2  Intuitive und beschreibende Namen für Akteure 

3.1.3  Namen von Akteuren konsistent verwenden 

3.2   Name des Anwendungsfalls

3.3   Kurzbeschreibung des Anwendungsfalls 

3.3.1  Mindestens ein Absatz 

3.3.2  Ein Beispiel (optional)

3.4   Konsistente Verwendung des Imperativs 

3.5   Verwendung von Glossareinträgen

3.6   Verwendung von Begriffen für Aktionen

3.6.1  Definieren, an welcher Stelle das System Optionen für Aktionen anbieten muss 

3.6.2  Konsistente Verwendung des Begriffs im gesamten Anwendungsfall 

3.7   Gesonderte Absätze für das Verhalten von Akteur und System 

3.8   Alternative und untergeordnete Abläufe 

3.9   Vor- und Nachbedingungen

3.10 Platzhalter (NZE) für fehlende Details verwenden

3.11 Ergänzende Spezifikationen definieren und referenzieren

3.12 Abgleich mit dem Prototyp/Design der Benutzerschnittstelle

3.13 Ausnahmeabläufe (optional)

3.13.1 Wo können Fehler auftreten?


Richtlinien für die Erstellung von Anwendungsfallmodellen

 

1.                  Einführung  Zum Seitenanfang

1.1               Verwendungszweck Zum Seitenanfang

Diese Anleitung soll die Konsistenz des Anwendungsfallmodells sicherstellen. Sie enthält Richtlinien für die Dokumentation eines Anwendungsfalls und allgemeine Hinweise zu Themen, die von Systemanalysten und Personen, die Anforderungen spezifizieren sollen, oft als problematisch angesehen werden.

1.2               Inhalt und Umfang Zum Seitenanfang

Diese Anleitung kann so übernommen oder an die Anforderungen der Mehrheit der Projekte angepasst werden.

1.3               Definitionen, Akronyme und Abkürzungen Zum Seitenanfang

Siehe Glossar zu Rational Unified Process

1.4               Referenzen Zum Seitenanfang

Keine

1.5               Übersicht Zum Seitenanfang

Diese Richtlinien sind in zwei Abschnitte gegliedert. Der erste Abschnitt beschreibt die bevorzugte Art der Erstellung eines Anwendungsfallmodells und der zweite Teil enthält Richtlinien für den Inhalt des Anwendungsfallmodells und die Benennung der Elemente innerhalb des Modells.

2.                  Allgemeine Richtlinien für Anwendungsfallmodelle Zum Seitenanfang

2.1               Allgemeiner Stil Zum Seitenanfang

Für das Schreiben der Anwendungsfälle wird die von Rational Unified Process bereitgestellte Vorlage verwendet. Stil und Layout der Vorlage können teilweise modifiziert und an die für die Projektdokumentation geltenden Normen angepasst werden.

2.2               Kommunikationsbeziehungen verwenden Zum Seitenanfang

Die Beziehung zwischen einem Akteur und einem Anwendungsfall wird als Kommunikationsbeziehung bezeichnet. Diese Beziehung sollte unidirektional gestaltet werden. In dieser Modellierungsstrategie wird Folgendes unterschieden:

       Aktiver Akteur
Der Akteur eines Anwendungsfalls wird als aktiv angesehen, wenn er die Ausführung des Anwendungsfalls einleitet (auslöst). Der Pfeil für die Kommunikationsbeziehung zeigt auf den Anwendungsfall.

       Passiver Akteur
Der Akteur eines Anwendungsfalls wird als passiv angesehen, wenn die Kommunikation vom Anwendungsfall eingeleitet wird. Passive Akteure sind in der Regel externe Systeme oder Einheiten, mit denen unser System kommunizieren muss. Der Pfeil für die Kommunikationsbeziehung zeigt auf den Akteur.

Diese Unterscheidung zwischen aktiven und passiven Akteuren gestaltet das Anwendungsfall für den Leser übersichtlicher.

2.3               Einschluss- und der Erweiterungsbeziehungen verwenden Zum Seitenanfang

Als Erstes sei hier erwähnt, dass Sie diese Beziehungen nach Möglichkeit vermeiden sollten. Diese Beziehungen können das Anwendungsfallmodell bei falscher Verwendung unübersichtlicher machen, anstatt es zu vereinfachen. Am Anfang sollten Sie eine solche Unterteilung des Modells vermeiden. Wenn Sie im Prozess weiter fortgeschritten sind, können Sie entscheiden, ob die Verwendung dieser Beziehungen sinnvoll ist. Sie können diese Beziehungen für Folgendes verwenden:

1.       Ermitteln des gemeinsamen Verhaltens von zwei oder mehr Anwendungsfällen

2.       Ermitteln des Verhaltens des Basisanwendungsfalls, bei dem nur das Ergebnis und nicht das Verhalten selbst für das Verständnis des primären Zwecks dieses Anwendungsfalls erforderlich ist

3.       Verdeutlichen, dass es eine Reihe von Verhaltenssegmenten geben kann, von denen einige an einem Erweiterungspunkt in einen Basisanwendungsfall eingefügt werden können

Diese Beziehungen sollten nur verwendet werden, wenn sie dazu beitragen, das Anwendungsfallmodell und dessen Verwaltung zu vereinfachen.

2.3.1          Einschlussbeziehungen verwenden Zum Seitenanfang

Die Einschlussbeziehung beschreibt ein Verhaltenssegment, das in eine im Basisanwendungsfall ausgeführte Anwendungsfallinstanz aufgenommen wird. Dieser Mechanismus ist mit einer Unterroutine vergleichbar und wird häufig zum Aufschlüsseln allgemeiner Verhaltensweisen angewendet.  

Zusatzinformation hierzu können Sie den Richtlinien für Einschlussbeziehungen in Rational Unified Process entnehmen.

2.3.2          Erweiterungsbeziehungen verwenden Zum Seitenanfang

Die Vorzüge einer Erweiterungsbeziehung zu nutzen, ist etwas schwieriger, da der erweiternde Anwendungsfall dem Basisanwendungsfall nicht bekannt ist. In den meisten Geschäftssystemen gibt es im Allgemeinen nur wenige Stellen, an denen eine solche Beziehung sinnvoll ist. Allerdings gibt es hier wie überall Ausnahmen von der Regel. Unter bestimmten Umständen kann dieser Mechanismus sehr hilfreich sein.

Zusatzinformation hierzu können Sie den Richtlinien für Erweiterungsbeziehungen in Rational Unified Process entnehmen.

2.4               Akteurgeneralisierung anwenden Zum Seitenanfang

Mit Hilfe der Akteurgeneralisierung lassen sich die verschiedenen Rollen, die die Benutzer des zu entwickelnden Systems spielen, in der Regel besser definieren. In Anwendungen mit verschiedenen Kategorien von Endbenutzern ist dies hilfreich. Auf diese Weise wird sichergestellt, dass jeder Benutzerkategorie nur die für sie relevanten Funktionen angezeigt werden. Hinzu kommt, dass die Zugriffsrechte ausgehend von dieser Gruppierung gesteuert werden können.

Als Faustregel kann davon ausgegangen, dass jeder Anwendungsfall von einem Akteur eingeleitet wird. Wenn diese Regel nicht eingehalten wird, muss die Beschreibung des Anwendungsfalls eine entsprechende Rechtfertigung enthalten.

Beispiel aus dem Geschäftsbereich der Universität:  Bibliothekar und Dozent sind zwei vorhandene Rollen (Akteure im Geschäftsbereich der Universität. Einige Aufgaben sind für beide Rollen einheitlich, andere sind spezifisch für die jeweilige Rolle im Geschäft. Die bevorzugte Modellierungsmethode für diese Situation ist nachfolgend dargestellt.Details zur Abbildung im obigen Text

Zusatzinformation hierzu können Sie den Richtlinien für die Akteurgeneralisierung in Rational Unified Process entnehmen.

2.5               Interaktionsdiagramme verwenden Zum Seitenanfang

In einigen Fällen kann es von Vorteil sein, zusätzlich zur Textdarstellung des Ereignisablaufs ein Interaktionsdiagramm aufzunehmen, das den wesentlichen Ablauf der Ereignisse im Anwendungsfall darstellt. Es wird empfohlen, hierfür ein Ablaufdiagramm in Rational Rose zu zeichnen. Nehmen Sie nur die Kommunikation zwischen den Akteuren und den Grenzobjekten auf (Eingabe- und Ausgabenachrichten) und behandeln Sie das System wie eine Blackbox. Verwenden Sie Grenzobjekte mit logischen Namen, wie sie im Ereignisablauf des Anwendungsfalls definiert sind, ohne sie zu diesem Zeitpunkt bereits Klassen zuzuordnen.

Es muss nicht zu jedem Anwendungsfall ein Interaktionsdiagramm geben. Ein solches Diagramm ist ein optionales Arbeitsergebnis.

2.6              Aktivitätsdiagramme verwenden Zum Seitenanfang

Wenn ein Aktivitätsdiagramm helfen kann, den Ablauf der Ereignisse im Anwendungsfall zu definieren, zu verdeutlichen und zu vervollständigen, sollten Sie dieses Diagramm in Rational Rose erstellen. Füge komplexe Anwendungsfälle (mit verschiedenen alternativen Abläufen und/oder Ausnahmeabläufen) ist ein Aktivitätsdiagramm sehr zu empfehlen. Das Aktivitätsdiagramm zeigt eine Entscheidungsstruktur für die Abläufe im Anwendungsfall.

Es muss nicht zu jedem Anwendungsfall ein Aktivitätsdiagramm geben. Ein solches Diagramm ist ein optionales Arbeitsergebnis.

3.                  Vorgehensweise beim Beschreiben eines Anwendungsfalls Zum Seitenanfang

Allgemeine Informationen und zusätzliche Richtlinien für Anwendungsfälle finden Sie in Rational Unified Process.

3.1               Richtlinien für Akteure Zum Seitenanfang

Allgemeine Informationen und zusätzliche Richtlinien für Akteure finden Sie in Rational Unified Process.

3.1.1          An jedem konkreten Anwendungsfall ist mindestens ein Akteur beteiligt Zum Seitenanfang

Ist an jedem konkreten Anwendungsfall mindestens ein Akteur beteiligt? Wenn nicht, liegt ein Fehler vor. Ein Anwendungsfall ohne Interaktion mit einem Akteur ist überflüssig. Entfernen Si einen solchen Anwendungsfall oder bestimmen Sie den zugehörigen Akteur.

In einigen Fällen können mehrere Akteure an den Interaktionen eines Anwendungsfalls beteiligt sein. Vergewissern Sie sich im jeweiligen Fall, ob die Verwendung mehrerer Akteure gültig ist (siehe 'Akteurgeneralisierung').

3.1.2          Intuitive und beschreibende Namen für Akteure Zum Seitenanfang

Haben die Akteure intuitive und beschreibende Namen? Werden die Namen von Benutzern und Kunden verstanden? Es ist wichtig, dass die Namen von Akteuren den Rollen der Akteure entsprechen. Wenn das nicht der Fall ist, ändern Sie die Namen.

Überprüfen Sie anhand des Anwendungsfallmodells, dass für jeden Akteur in Ihrem Anwendungsfall der richtige Name verwendet wird.

3.1.3          Konsistente Verwendung von Namen für Akteure Zum Seitenanfang

In der Anwendungsfallspezifikation werden die Namen der Akteure konsistent angegeben. Es muss sichergestellt werden, dass die Namen der Akteure klar verständlich und eindeutig sind.

Verweisen Sie nicht allgemein auf "den Akteur". Verwenden Sie stattdessen den tatsächlichen Namen, der den jeweiligen Akteur eindeutig bezeichnet oder definiert. Stellen Sie sich den Namen des Akteurs als die Rolle vor, die er in einer Reihe von Systeminteraktionen spielt.

3.2               Name des Anwendungsfalls Zum Seitenanfang

Der Name des Anwendungsfalls ist eindeutig, intuitiv und beschreibend und definiert klar und eindeutig den sichtbaren Nutzen des Anwendungsfalls.

Der Name eines Anwendungsfalls ist geeignet, wenn Kunden, Ansprechpartner, Analytiker und Entwickler den Namen und die Beschreibung des Anwendungsfalls verstehen. Vergessen Sie nicht, dass Sie aus der Perspektive des Akteurs ein sichtbares Ergebnis mit eigenem Wert definieren.

Der Name jedes Anwendungsfalls beschreibt das vom Anwendungsfall unterstützte Verhalten. Der Name sollte sich aus der auszuführenden Aktion und dem zugehörigen Schlüsselelement zusammensetzen. Meistens wird es sich um eine Kombination aus Verb und Substantiv handeln. Der Anwendungsfall sollte aus der Sicht des Akteurs benannt werden, der den Anwendungsfall auslöst. Beispiele: "Registrierung für einen Kurs", "Zu haltenden Kurs auswählen" usw.

3.3               Kurzbeschreibung des Anwendungsfalls Zum Seitenanfang

3.3.1          Mindestens ein Absatz Zum Seitenanfang

Der Anwendungsfall enthält eine Kurzbeschreibung. Diese Beschreibung umfasst mindestens einen Absatz, jedoch nicht mehr als drei Absätze. Zur Beschreibung gehört eine Erläuterung des Hauptzwecks, des erwarteten Nutzens und der Konzepte des Anwendungsfalls.

3.3.2          Ein Beispiel (optional) Zum Seitenanfang

Sie können ein kleines Beispiel aufnehmen, wo dies von Nutzen ist, und eine kurze Beschreibung zum Kontext. Dieses Beispiel zeichnet in der Regel den Basisablauf nach und enthält Datenwerte, soweit es sinnvoll ist.

3.4               Konsistente Verwendung des Imperativs Zum Seitenanfang

Systemvoraussetzungen werden in Anwendungsfällen imperativisch angegeben. Für eine konsistente Beschreibung von Anforderungen ist bevorzugt das Wort "muss" an Stelle des Wortes "sollte" zu verwenden. Vermeiden Sie die Verwendung von Begriffen, die eine Anforderung als optional oder nicht genau definiert erscheinen lässt, wie "sollte", "möglicherweise", "usw.", "könnte", "vielleicht".

3.5               Verwendung von Glossareinträgen Zum Seitenanfang

Alle in einem Anwendungsfall verwendeten Geschäftstermini werden im Projektglossar definiert. Falls ein Anwendungsfall einen Geschäftsterminus enthält, der nicht im Glossar definiert ist, ist Folgendes erforderlich:

1.       Der Terminus muss mit einer Kurzbeschreibung (maximal ein Absatz) zum Glossar hinzugefügt werden.

2.       Der Terminus muss im Anwendungsfall geändert werden. Verwenden Sie den richtigen Geschäftsterminus, wie er im Glossar definiert ist.

3.6               Verwendung von Begriffen für Aktionen Zum Seitenanfang

3.6.1          Definieren, an welcher Stelle das System Optionen für Aktionen anbieten muss Zum Seitenanfang

Der Anwendungsfall gibt explizit an, an welcher Stelle das System dafür zuständig ist, dem Akteur eine Aktivität als verfügbare Option zur Auswahl anzuzeigen. In den meisten Fällen werden die verfügbaren Optionen im Rahmen des Basisablaufs angezeigt und in der ersten Anweisung des entsprechenden alternativen Ablaufs als Eingangspunkt referenziert.

3.6.2          Konsistente Verwendung von Begriffen im gesamten Anwendungsfall Zum Seitenanfang

Begriffe wie 'Neu', 'Modifizieren', 'Abbrechen', 'Löschen', 'OK' und 'Drucken' werden im gesamten Anwendungsfall konsistent verwendet. Eine logische Aktion darf nicht mit verschiedenen Begriffen bezeichnet werden. Es ist besonders darauf zu achten, dass die Bezeichnungen für Aktionen in den alternativen Abläufen mit denen für die entsprechenden Aktionen im Basisablauf übereinstimmen.

3.7               Gesonderte Absätze für das Verhalten von Akteur und System Zum Seitenanfang

Immer, wenn sich der Fokus in der Interaktion (zwischen Akteur und System) auf den jeweils anderen Beteiligten verlagert, beginnt ein neuer Absatz mit dem nächsten Verhaltenssegment. Beginnen Sie mit dem Akteur, gefolgt vom System.

Der Satz muss mit den Worten 'Der <Name des Akteurs> muss xxxxx' oder 'Das System muss xxxx' beginnen. Geben Sie den Namen des Akteurs immer korrekt und vollständig an. Vermeiden Sie Abkürzungen des Namens.

3.8               Alternative und untergeordnete Abläufe Zum Seitenanfang

Jeder alternative und untergeordnete Ablauf definiert explizit und deutlich alle möglichen Eingangspunkte in den Ablauf und endet mit allen möglichen Ausstiegspunkten aus dem Ablauf.

Der alternative Ablauf gibt außerdem explizit den Ausstiegspunkt an und den nächsten möglichen Schritt für den Akteur:   Rückkehr zu einem bestimmten Schritt im Basisablauf oder Ende des Ablaufs.

Wenn der Ablauf der Ereignisse durch die Komplexität des Verhaltens unübersichtlich wird oder ein einzelner Ablauf die Länge einer Druckseite überschreitet, können Sie durch das Einführen untergeordneter Abläufe mehr Klarheit schaffen und die Komplexität besser verwalten. Für das Schreiben untergeordneter Abläufe werden eigenständige logische Gruppen mit detaillierten Verhaltensdefinitionen in einen untergeordneten Ablauf verschoben. Diese Gruppe der Verhaltensdefinitionen wird dann in ihrer Gesamtheit im Ablauf der Ereignisse referenziert.

3.9               Vor- und Nachbedingungen Zum Seitenanfang

Die Spezifikation enthält eine Reihe von Bedingungen (bzw. Voraussetzungen), die erfüllt sein müssen (als erfüllt gelten), bevor der Anwendungsfall beginnt (Vorbedingungen) und nachdem der Anwendungsfall beendet ist (Nachbedingungen). Beachten Sie, dass ein Anwendungsfall unter Umständen auf verschiedene Weise beendet werden kann. Die Nachbedingungen müssen jeweils entsprechend beschrieben sein.

3.10           Platzhalter (NZE) für fehlende Details verwenden Zum Seitenanfang

Wenn bestimmte Informationen noch nicht definiert sind oder Entscheidungen noch ausstehen, enthält der Anwendungsfall einen Verweis auf das Problem oder Element und den Platzhalter NZE.

3.11            Ergänzende Spezifikationen definieren und referenzieren Zum Seitenanfang

Falls es zusätzliche Voraussetzungen gibt, die nicht im natürlichen Ablauf der Ereignisse beschrieben werden können, müssen sie als ergänzende Anforderungen definiert werden. Anforderungen, die für einen Anwendungsfall spezifisch sind, werden im Abschnitt 'Spezielle Anforderungen' der Anwendungsfallspezifikation definiert.

Anforderungen, die für das gesamte System gelten, werden in mindestens einem zusätzlichen Spezifikationsdokument definiert. Dies gilt insbesondere für nicht funktionale Anforderungen.

Beispiele:

Zuverlässigkeit:           - Das System muss 7 Tage die Woche rund um die Uhr verfügbar sein.

                          - Die Zeit zwischen zwei Fehlern muss bei mindestens 48 Stunden liegen.

Durchsatz:       - Unter normalen Ladebedingungen muss das System nach spätestens 5 Sekunden eine Onlinereaktion zeigen.

3.12            Abgleich mit dem Prototyp/Design der Benutzerschnittstelle

Der Inhalt des Anwendungsfalls wird unter verschiedenen Gesichtspunkten mit dem Prototyp/Design der Benutzerschnittstelle verglichen, um sicherzustellen, dass im Anwendungsfall bzw. im Prototyp/Design der Benutzerschnittstelle keine Systemvoraussetzungen fehlen. Wenn Änderungen am Anwendungsfall erforderlich sind, müssen diese vorgenommen werden. Änderungen am Prototyp der Benutzerschnittstelle werden für später notiert, da die entsprechenden Aktionen besprochen werden müssen.

3.13            Ausnahmeabläufe (optional)

Die folgenden Richtlinien sollen Sie bei der Feststellung von Ausnahmeabläufen unterstützen:

3.13.1      Wo können Fehler auftreten?

Überlegen Sie für jeden Schritt des Anwendungsfalls, welche Fehler möglich sind. Jede eindeutige Ausnahme kann als ein Ausnahmeablauf erfasst werden. In einigen Fällen wird für den gesamten Anwendungsfall ein einheitlicher Ausnahmedatenfluss verwendet, z. B. 'Zeitlimitüberschreitung'. Das wichtigste, was hier erfasst werden muss, ist die geschäftliche Anforderung beim Eintreten der Ausnahme. Über welche Erfahrungen müssen die Akteure verfügen?