UML-Anwendungsfalldiagramme

Ein Anwendungsfalldiagramm ist eine Karte des Umfangs. Es benennt die Menschen und Systeme, die mit dem interagieren, was Sie bauen, die Ziele, mit denen sie kommen, und die Linie zwischen innen und außen. Mehr tut es nicht, und seine Zurückhaltung ist der Punkt.

Es sagt nichts über Reihenfolge. Nichts über Bildschirme, Felder oder Algorithmen. Nichts darüber, wie irgendetwas funktioniert. Jedes davon ist ein anderes Diagramm, und die Versuchung, sie hier hineinzuschmuggeln, erzeugt die wuchernden, nutzlosen Anwendungsfalldiagramme, die dieser Notation ihren Ruf eingebracht haben.

Niemand reicht Ihnen eine Liste. Das Diagramm oben wirkt fertig gezeichnet selbstverständlich und war es vorher überhaupt nicht; die Lücke zwischen leerem Blatt und diesem Bild füllen vier Fragen, die man in zwanzig Minuten im Raum stellen kann.

1. Wer stößt hier etwas an? Jede dieser Personen ist ein möglicher primärer Akteur. Fragen Sie nach der Rolle statt nach dem Namen - wer „das mache ich“ gesagt hat, ist ein Träger einer Rolle, die ihn überdauert.
2. Wer oder was bekommt etwas, ohne danach zu fragen? Berichte, Dateien, Benachrichtigungen, Abrechnungsläufe. Das sind die unterstützenden Akteure rechts von der Grenze, und sie sind die Hälfte des Diagramms, die den meisten ersten Entwürfen fehlt.
3. Was muss da sein, damit das funktioniert? Zahlungsdienstleister, Identitätsdienste, das Mainframe, eine Betrugserkennung. Alles, wofür Sie bei einem anderen Team ein Ticket aufmachen würden, liegt außerhalb der Grenze und gehört auf das Diagramm - es zu zeichnen ist oft der Moment, in dem jemand merkt, dass die Abhängigkeit nie vereinbart wurde.
4. Was passiert, weil Zeit vergangen ist? Ein nächtlicher Abgleich, eine Frist von vierzehn Tagen, ein monatlicher Rechnungslauf. Zeit ist ein Akteur, gezeichnet als Strichmännchen mit der Beschriftung Clock oder Scheduler, und Prozesse, die sie weglassen, enden mit Anwendungsfällen, die scheinbar niemand anstößt.

Benennen Sie dann jedes Ziel von der Seite des Akteurs aus, Verb zuerst, in dessen Vokabular: Submit payment, nicht Payment submission handling und ganz sicher nicht PaymentController. Ergibt der Name nur für jemanden Sinn, der den Code gesehen hat, ist es ein Schritt in einem Anwendungsfall statt einer.

Diese beiden sind der Grund, warum Anwendungsfalldiagramme falsch gezeichnet werden. Beide sind gestrichelte Pfeile mit einem Schlüsselwort, und sie zeigen in entgegengesetzte Richtungen.

«include» zeigt vom Basisfall zu dem, was er immer tut. Lesen Sie es als „ruft auf“. Im Diagramm oben bindet Submit payment den Fall Authorize payment ein: einreichen ohne autorisieren geht nicht. Es existiert, um Verhalten herauszuziehen, das mehrere Fälle teilen - genau deshalb bindet Refund payment es ebenfalls ein.

«extend» zeigt von der optionalen Ergänzung zurück zum Basisfall. Lesen Sie es als „kann unterbrechen“. Log audit trail erweitert Refund payment: Rückerstattungen funktionieren auch ohne, und es passiert unter einer Bedingung. Der Basisfall weiß nichts von seinen Erweiterungen.

Das Diagramm ist das Inhaltsverzeichnis. Woraus tatsächlich gebaut wird, ist die Anwendungsfallbeschreibung hinter jeder Ellipse - und ein Projekt, das das Diagramm zeichnet und die Beschreibungen nie schreibt, hat ein Bild von Arbeit statt einer Spezifikation davon erzeugt. Genau dazu sagt die Notation nichts, weshalb so viele Teams beim Bild aufhören.

Es gibt drei brauchbare Tiefen, und die Wahl ist eine Projekt-, keine Modellierungsentscheidung. Eine knappe Beschreibung sind zwei Sätze im Backlog. Eine lockere ist ein Absatz je Szenario. Eine voll ausgearbeitete hat die Felder unten und lohnt sich für die Handvoll Fälle, an denen echtes Geld oder echtes Risiko hängt.

• Name. Die Beschriftung der Ellipse, Verb zuerst: Authorize payment.
• Primärer Akteur. Wer das Ergebnis will. Merchant.
• Stakeholder und Interessen. Wen es sonst betrifft und was er daraus braucht. Der Acquirer will einen gültigen Autorisierungscode; das Betrugsteam will den Versuch protokolliert haben, ob er gelingt oder nicht. In diesem Feld tauchen die meisten übersehenen Anforderungen auf.
• Vorbedingungen. Was vor dem Start bereits gilt - der Händler ist authentifiziert, die Bestellung existiert. Keine Liste von Schritten, eine Liste von Zusicherungen.
• Hauptszenario. Der nummerierte Erfolgspfad, Akteurschritt, dann Systemschritt, in der Sprache des Fachbereichs. Irgendwo zwischen fünf und zwölf Schritten; mehr, und der Anwendungsfall sind in Wahrheit zwei.
• Erweiterungen. Nummeriert nach dem Schritt, von dem sie abzweigen - 4a, 4b, 7a - jeweils mit Bedingung und Folge. Dieses Feld rechtfertigt das Format, denn es ist eine systematische Aufforderung für jede Art, wie der Erfolgspfad scheitert.
• Nachbedingungen. Was danach gilt, bei Erfolg und bei jedem Fehlschlag. „Eine Autorisierung ist erfasst und der Betrag ist reserviert“ lässt sich prüfen, „die Zahlung ist verarbeitet“ nicht.

Klein ausgearbeitet für Authorize payment: das Hauptszenario ist (1) der Händler reicht die Zahlung ein, (2) das System prüft die Bestellsumme, (3) das System fordert die Autorisierung beim Acquirer an, (4) der Acquirer gibt frei, (5) das System erfasst die Reservierung und bestätigt. Die Arbeit steckt in den Erweiterungen - 3a der Acquirer antwortet nicht, 4a der Acquirer lehnt ab, 4b der Acquirer verlangt eine zusätzliche Prüfung - und jede davon ist ein Gespräch, das sonst sechs Wochen später in einer Fehlertriage geführt worden wäre.

Ein brauchbares Anwendungsfalldiagramm passt auf eine Seite und hat zwischen drei und zehn Ellipsen. Es ist ein Inhaltsverzeichnis, nicht das Buch. Das Detail gehört in Anwendungsfallbeschreibungen - den nummerierten Hauptablauf und seine Alternativen - oder, wenn der Ablauf verzweigt genug ist, in ein Aktivitätsdiagramm je Anwendungsfall.

1. Funktionale Zerlegung. Zwanzig Ellipsen, benannt nach Schaltflächen. Anwendungsfälle sind Ziele; was kein Akteur will, gehört nicht hin.
2. Akteure nach Personen oder Stellenbezeichnungen benannt. Modellieren Sie die Rolle. Eine Person kann mehrere Akteure sein, und ein Akteur kann ein Batchjob sein.
3. «include»- und «extend»-Pfeile vertauscht. Sie zeigen entgegengesetzt. Wenden Sie den Entfernungstest oben an.
4. Akteure innerhalb der Grenze. Die Grenze ist das, was Sie bauen. Ein Akteur liegt per Definition außerhalb.
5. Reihenfolge durch vertikale Position suggeriert. Ein Anwendungsfalldiagramm hat keine Zeitachse. Nichts am Layout sagt, was zuerst passiert.