2. Mod - 2.4 OOA: Use-Case-Diagramme Flashcards
Nenne 3 Prinzipien und erkläre was damit gemeint ist
encapsulate what varies: alles kapseln, was sich verändern kann
understand requirements: Verantwortung des Entwicklers, das System zu verstehen
code to interface rather that to an implementation: Code einer Klasse soll so unabhängig wie möglich vom Code der anderen Klassen sein
In welcher Sprache sollte Diagramm geschrieben sein?
Sprache des Anwenders
Wer kann Informationsquelle sein?
Kunden und zukünftige Anwender (Mitarbeiter Kunden oder Kunden unserer Kunden)
Was ergibt sich aus Kundengesprächen und was kann daraus abgeleitet werden?
Was System können soll
Darauf werden dann Anforderungen abgeleitet
Was machen use-Case-Diagramme?
- auf sehr hoher Ebene Auskunft geben über Funktion eines Systems
- abstrahieren von Details
- geben nur Auskunft darüber, WAS das System tut, nicht WIE
- definieren keine Reihenfolge der Use-Case
Was beschreiben Use-Cases?
Interaktion zwischen einem Akteur und einem System
also die Funktionalität
Was stellt das enthaltene Rechteck dar?
die Systemgrenzen
- damit ist klar worauf sich das Diagramm bezieht
Aus welchen Elementen besteht ein Use-Case-Diagramm unter anderem, beschreibe sie
Akteur (Actor): Rolle, die externer Benutzer oder externes System einnimmt, wenn er mit System interagiert
Akteur steht immer außerhalb des betrachteten Systems
Akteur generische Einheit (Kunde, nicht “Herr MaierGotschalkPeter”)
Anwendungsfall (Use Case): Funktionalität des betrachteten Systems, die ein Akteur nutzt.
Use Case entsteht aus einer Menge von Aktionen, bringt Akteur in irgendeiner Form einen Nutzen
Assoziation: Beziehungen zwischen Akteur und Anwendungsfall, den er nutzt.
gerichtete Assoziation (mit Pfeilspitze) zeigt an, ob Akteur den Use-Case initiieren kann, ungerichtete Assoziation lässt dies offen
Multiplizitäten können wir zwischen Klassen angegeben werden
Geben an, wie viele Objekte bei Aufruf des Use-Cases von wie vielen Akteuren bearbeitet werden kann
Beziehungen zwischen Anwendungsfällen: Anwendungsfall wird immer (<>) oder unter bestimmten Bedingungen (<>) in einen anderen eingebunden
Sinnvoll wenn ein Use-Case einen anderen erweitert oder wenn gemeinsame Funktionalität in mehreren Use-Cases verwendet wird,
keinen Zyklus bilden
Generalisierungen: können sinnvoll sein und werden mit Generalisierungspfeilen wie bei Klassen gezeichnet
Generalisierungen zwischen Use Cases möglich, aber eher unüblich
Granularität von Anwendungsfällen. Worauf muss geachtet werden
Für jedes ovale Symbol im Use-Case-Diagramm wird ein Use-Case-Dokument erstellt
Sollte abwägen:
Übersichtlichkeit des Diagramms
Überschaubarkeit des Use-Case-Dokument
Überschneidungsfreiheit der Use-Case-Dokuemente
Was hat bedeutet Alistair Cockburns Coffe Break Test “After I get done with this, I can take a coffee break”
Ein Use-Case ist zu umfangreich wenn ein Akteur während des Use-Cases eine Kaffeepause machen würde
Aus welchen Elementen besteht ein Use-Case-Diagramm unter anderem
Akteur Anwendungsfall Assoziation Beziehungen zwischen Anwendungsfällen Generalisierungen (unüblich)
Mögliche Fragen zum Erstellen von Use Case Diagrammen
Akteure:
Welche Personen und externe Systeme sind die Akteure?
Akteure stehen außerhalb des zu modellierenden Systems
Anwendungsfälle: WElche Anwendungsfälle gibt es?
Anwendungsfälle haben eun Ergebnis für den Akteur: Sie werden von ihm initiiert
Assoziationen:
Welche Akteuren stehen welche Anwendungsfälle zur Verfügung?
include/extend: In welcher Beziehung stehen die Anwendungsfälle zueinander?
Können externe Systeme als Akteure auftreten? Falls ja, wie kommunizieren Sie mit dem zu modellierenden System?
Ja,
über eine Schnittstelle
Kann das zu modellierende System selbst ein Akteur in seinem eigenen Use-Case-Diagramm sein?
NIEMALS
Wie sollten nicht menschliche Akteure dargestellt werden?
Sind eigene Symbole bei der Verwendung von nicht menschlichen Akteuren okay?
Als Rechteck statt als Strichmännchen
Ja, sie müssen aber aussagekräftig sein oder einfach als Rechteck
