Aufgabe: Anwendungsfalldesign
Diese Aufgabe definiert, wie die Produkte der Anwendungsfallanalyse durch die Entwicklung von Anwendungsfallrealisierungen auf Designebene präzisiert werden.
Disziplinen: Analyse und Design
Zweck
  • Anwendungsfallrealisierungen mit Interaktionen konkretisieren
  • Anforderungen an Operationen von Designklassen präzisieren
  • Anforderungen an Operationen von Designsubsystemen und/oder ihren Schnittstellen präzisieren
  • Anforderungen an Operationen von Kapseln präzisieren
Beziehungen
Hauptbeschreibung

Das Verhalten eines Systems kann mit verschiedenen Techniken beschrieben werden - Kollaborationen oder Interaktionen. Diese Aufgabe beschreibt die Verwendung von Interaktionen, insbesondere Ablaufdiagrammen für die Beschreibung des Systemverhaltens. Ablaufdiagramme sind besonders hilfreich, wenn das Verhalten des Systems oder Subsystem primär durch synchrones Messaging beschrieben werden kann. Asynchrones Messaging, insbesondere in ereignisgesteuertes Systemen, lässt sich häufig besser mit Zustandsmaschinen und Kollaborationen beschreiben, die eine kompakte Definition der möglichen Interaktionen zwischen Objekt zulassen. Asynchrone Nachrichten spielen in Echtzeit- und reaktiven Systemen eine wichtige Rolle und werden für die Kommunikation zwischen Instanzen einer  Kapsel verwendet.

 UML-1.x-Darstellung

Sie können eine Proxy-Klasse verwenden, um das Subsystem in Ablaufdiagrammen darzustellen. Diese Proxy-Server ist im Subsystem enthalten und wird verwendet, um das Subsystem in Diagrammen darzustellen, die die direkte Verwendung von Paketen und Subsystemen als Verhaltenselemente nicht unterstützen. Verwenden Sie die Proxy-Klasse in den Fällen, in denen Sie zeigen möchten, dass ein bestimmtes Subsystem auf eine Nachricht reagiert. Damit können Sie zeigen, dass Nachrichten vom Subsystem-Proxy an andere Objekte gesendet werden.

Lesen Sie auch den Artikel Unterschiede zwischen UML 1.x und UML 2.0.

Schritte
Anwendungsfallrealisierungen erstellen

Die Anwendungsfallrealisierung für das Design ist ein Mitteln, um das Verhalten im Designmodell auf das Anwendungsfallmodell zurückzuverfolgen, und organisiert Kollaborationen im Designmodell für das Anwendungsfallkonzept.

Erstellen Sie für jeden zu entwerfenden Anwendungsfall eine Anwendungsfallrealisierung für das Design. Der Name für diese Anwendungsfallrealisierung muss identisch mit dem Namen des zugehörigen Anwendungsfall sein. Außerdem muss eine Realisierungsbeziehung ("realizes") von der Anwendungsfallrealisierung für Design zum zugehörigen Anwendungsfall eingerichtet werden.

Interaktionen zwischen Designobjekten beschreiben

Für jede Anwendungsfallrealisierung sollten Sie die Interaktionen zwischen den teilnehmenden Designobjekten in einem oder mehreren Ablaufdiagrammen veranschaulichen. Frühe Versionen hiervon wurden möglicherweise bereits während der Anwendungsfallanalyse erstellt. Diese Analyseversionen der Anwendungsfallrealisierungen beschreiben Interaktionen zwischen Analyseklassen. Diese müssen für die Beschreibung der Interaktionen zwischen Designelementen ausgearbeitet werden.

Gehen Sie zum Aktualisieren der Ablaufdiagramme wie folgt vor:

  • Identifizieren Sie jedes Objekt im Ablauf des Anwendungsfalls. Hierfür instanzieren Sie die Designklassen und Subsysteme, die in Designelemente identifizieren beschrieben sind. In Echtzeitsystemen müssen Sie auch die Kapselinstanzen identifizieren, die am Ablauf des Anwendungsfalls beteiligt sind.
  • Stellen Sie jedes teilnehmende Objekt in einem Ablaufdiagramm dar. Erstellen Sie im Ablaufdiagramm eine Lebenslinie für jedes teilnehmende Objekt. Für die Darstellung der Designsubsysteme können Sie zwischen den folgenden Optionen wählen:
    • Sie können Instanzen des Subsystems im Ablaufdiagramm darstellen.
    • Sie können die vom Subsystem realisierten Schnittstellen verwenden. Diese Methode bietet sich an, wenn Sie zeigen möchten, dass alle Modellelemente, die dieselbe Schnittstelle realisieren, anstelle der Schnittstelle verwendet werden können. Wenn Sie sich für die Anzeige von Schnittstellen im Ablaufdiagramm entscheiden, müssen Sie sicherstellen, dass keine Nachrichten von der Schnittstelle an andere Objekte gesendet werden. Der Grund hierfür ist, dass Schnittstellen die interne Realisierung ihrer Operationen vollständig kapseln. Daher kann nicht sichergestellt werden, dass alle Modellelemente, die die Schnittstelle realisieren, auf dieselbe Weise entworfen werden. Somit sollte in Ablaufdiagrammen nicht gezeigt werden, das Nachrichten von der Schnittstelle gesendet werden.
    • Sie können die Komponente verwenden, um das Subsystem in Ablaufdiagrammen darzustellen. Verwenden Sie die Komponente in den Fällen, in denen Sie zeigen möchten, dass ein bestimmtes Subsystem auf eine Nachricht reagiert. Damit können Sie zeigen, dass Nachrichten von der Komponente an andere Objekte gesendet werden.

    Dies sind Ablaufdiagramme auf Systemebene, die zeigen, wie Instanzen der übergeordneten Designelemente (normalerweise Subsysteme und Subsystemschnittstellen) interagieren. Ablaufdiagramme, die das interne Design von Subsystemen zeigen, werden gesondert im Rahmen des Subsystemdesigns erstellt.

  • Die Interaktionen aktiver Objekte werden normalerweise mit Spezifikationskollaborationen und Zustandsmaschinen beschrieben. Sie werden hier verwendet, um zu zeigen, wie Nachrichten von anderen Objekten im System in einer größeren Anwendungsfallrealisierung an aktive Objekte gesendet werden können. Normalerweise werden für diese Aufgabe aktive Objekte in Subsystemen gekapselt, so dass sich die Anwendungsfallrealisierung aus einer Gruppe interagierender Subsysteme zusammensetzt. Die Interaktionen definieren die Zuständigkeiten und Schnittstellen der Subsysteme. In den Subsystemen stellen aktive Objekte parallele Ausführungs-Threads dar. Die Subsysteme ermöglichen, Arbeit auf Entwicklungsteams zu verteilen, wobei die Schnittstellen als formale Verträge zwischen den Teams dienen. In Echtzeitsystemen verwenden Sie  Kapseln für die Darstellung der aktiven Objekte.

    Eine Randbemerkung zur Darstellung von Nachrichten, die von Subsystemen stammen: Wenn Sie Nachrichten nur auf die Schnittstellen einschränken, minimiert dies Kopplung von Modellelementen und verbessert die Flexibilität des Designs. Versuchen Sie, diese Technik so oft wie möglich anzuwenden. Wenn Nachrichten von Subsystemen an Modellelemente, die keine Schnittstellen sind, gesendet werden, sollten Sie nach Möglichkeiten suchen, diese Nachrichten an Schnittstellen zu senden, um die Entkopplung innerhalb des Modells zu fördern.

  • Stellen Sie die Interaktionen mit den Akteuren dar. Stellen Sie jede Akteurinstanz und jedes externe Objekt, mit dem die teilnehmenden Objekte interagieren, in Form einer Lebenslinie im Ablaufdiagramm dar.
  • Veranschaulichen Sie die Nachrichtenübertragung zwischen den teilnehmenden Objekten. Der Ereignisablauf beginnt oben im Diagramm und fließt in einer vertikalen, chronologischen Achse nach unten. Veranschaulichen Sie die Nachrichtenübertragung zwischen Objekten, indem Sie Nachrichten (Pfeile) zwischen den Lebenslinien erstellen. Der Name einer Nachricht muss der Name der Operation sein, die von der Nachricht aufgerufen wird. In den frühen Stadien des Designs sind den Objekten nicht viele Operationen zugeordnet. Deshalb können Sie die Information weglassen und der Nachricht einen vorläufigen Namen geben. Solche Nachrichten werden als "nicht zugeordnete" Nachrichten bezeichnet. Wenn Sie später weitere Operationen der teilnehmenden Objekte ermittelt haben, müssen Sie das Ablaufdiagramm aktualisieren und den Nachrichten diese Operationen zuordnen.
  • Beschreiben Sie, welche Aktion ein Objekt beim Empfang einer Nachricht ausführt. Ordnen Sie dazu der entsprechenden Nachricht ein Script zu. Platzieren Sie diese Scripts am Rand des Diagramms. Verwenden Sie strukturierten Text oder Pseudocode. Wenn Sie Pseudocode verwenden, müssen Sie Konstrukte aus der Implementierungssprache verwenden, so dass die Implementierung der entsprechenden Operationen einfacher wird. Wenn die Person, die für die Klasse eines Objekts zuständig ist Operationen zuordnet und definiert, bilden die Scripts des Objekts die Basis für diese Arbeit.

Im Begleittext beschriebenes Diagramm

Sie dokumentieren das Anwendungsfallverhalten der Objekte in einem Ablaufdiagramm.

Wenn Sie das Verhalten auf die Objekte verteilt haben, müssen Sie überlegen, wie der Ablauf kontrolliert wird. Sie haben die Objekte basierend auf der Annahme gefunden, dass sie auf irgendeine Weise in der Anwendungsfallrealisierung interagieren und eine bestimmte Rolle haben. Beim Verteilen des Verhaltens können Sie mit der Überprüfung dieser Annahmen beginnen. In einigen Teilen des Ablaufs können Sie eine dezentrale Struktur verwenden, in anderen eine zentrale. Definitionen dieser Varianten und Empfehlungen zur Verwendung dieser beiden Strukturtypen finden Sie in Ablaufdiagramme.

An diesem Punkt benötigen Sie möglicherweise neue Objekte, z. B., wenn Sie eine zentrale Struktur verwenden und ein neues Objekt benötigen, das den Ablauf steuert. Denken Sie daran, dass jedes Objekt, das Sie dem Designmodell hinzufügen, die Anforderungen an das Objektmodell erfüllen muss.

Geeignete Designmechanismen integrieren

Während der Architekturanalyse wurden Analysemechanismen identifiziert. Bei der Aufgabe Designmechanismen identifizieren werden Analysemechanismen zu Designmechanismen konkretisiert. Die Zuordnung von Analysemechanismen zu Designmechanismen wird im Softwarearchitekturdokument erfasst.  Projektspezifische Richtlinien dokumentieren die Designmechanismen.   

Mit der Aufgabe Anwendungsfalldesign werden alle geeigneten Designmechanismen in die Anwendungsfallrealisierungen integriert. Der Designer schaut sich die verfügbaren Designmechanismen an und bestimmt die, die sich für die zu entwickelnde Anwendungsfallrealisierung eignen. Hierbei hält er sich an die Empfehlungen und Richtlinien, die im Softwarearchitekturdokument und in den Designrichtlinien beschrieben sind.   
Anmerkung: Geeignete Designmechanismen wurden möglicherweise bei der Anwendungsfallanalyse identifiziert, wo die Analyseklassen unter Umständen mit einem bestimmten Analysemechanismus markiert wurden, um darauf hinzuweisen, dass eine bestimmte Funktionalität im Design berücksichtigt werden muss. In solchen Fällen sind die geeigneten Designmechanismen die, die den Analysemechanismen zugeordnet sind, mit denen die Analyseklassen, die an der Anwendungsfallrealisierung teilnehmen, gekennzeichnet wurden.

Der Designer integriert die geeigneten Designmechanismen in die Anwendungsfallrealisierungen, indem er die erforderlichen Designelemente und Designelementinteraktionen gemäß den in den Designrichtlinien dokumentierten Verwendungsregeln in die Anwendungsfallrealisierungen einfügt.

Varianten des Ereignisablaufs berücksichtigen

Sie müssen jede Ablaufvariante in einem eigenen Ablaufdiagramm beschreiben. Ablaufdiagramme sind im Allgemeinen Kommunikationsdiagrammen vorzuziehen, weil sie sich in der Regel einfacher lesen lassen, wenn das Diagramm den Detaillierungsgrad haben muss, der typischerweise beim Design des Systems erwünscht ist.

Beginnen Sie mit der Beschreibung des Basisablaufs, der der allgemeinste und wichtigste Ereignisablauf ist. Anschließend beschreiben Sie Varianten wie außergewöhnliche Abläufe. Sie müssen nicht alle Ereignisabläufe beschreiben, solange Sie alle Operationen der teilnehmenden Objekte verwenden und veranschaulichen. Besonders triviale Abläufe, z. B. solche, die nur ein Objekt betreffen, können weggelassen werden.

Studieren Sie den Anwendungsfall, um festzustellen, ob es noch andere Ablaufvarianten gibt als die, die bereits bei der Erfassung der Anforderungen und bei der Analyse beschrieben wurden, z. B. solche, die von der Implementierung abhängig sind. Wenn Sie neue Abläufe finden, beschreiben Sie sie in einem Ablaufdiagramm. Im Folgenden finden Sie Beispiele für außergewöhnliche Abläufe:

  • Fehlerbehandlung. Wenn eine Schnittstelle meldet, dass bei der Kommunikation mit einem externen System ein Fehler aufgetreten ist, muss dies im Anwendungsfall berücksichtigt werden. Eine mögliche Lösung ist, einen neuen Kommunikationsweg zu öffnen.
  • Behandlung von Zeitlimitüberschreitungen. Wenn der Benutzer nicht innerhalb eines bestimmten Zeitraums antwortet, muss der Anwendungsfall spezielle Maßnahmen vorsehen.
  • Behandlung von fehlerhaften Eingaben für Objekte, die am Anwendungsfall teilnehmen. Fehler wie diese können auf eine ungültige Eingabe des Benutzers zurückzuführen sein.

Optionale Teile des Anwendungsfalls berücksichtigen

Sie können einen alternativen Pfad eines Ablaufs als optionalen Ablauf anstelle einer Variante beschreiben. Die folgende Liste enthält zwei Beispiele für optionale Abläufe.

  • Wenn ein Signal gesendet wird, wählt der Akteur aus einer Reihe von Optionen aus, welche Aktion der Anwendungsfall als nächstes ausführen muss. Der Anwendungsfall hat den Akteur beispielsweise aufgefordert, mit ja oder nein auf eine Frage zu antworten, oder dem Akteur mehrere Funktionen angeboten, die das System im aktuellen Zustand des Anwendungsfalls ausführen kann.
  • Der Ablaufpfad richtet sich nach dem Wert der gespeicherten Attribute oder Beziehungen. Der nachfolgende Ereignisablauf richtet sich nach dem Typ der zu verarbeitenden Daten.

Wenn Sie einen optionalen Ablauf oder einen komplexen untergeordneten Ablauf besonders hervorheben möchten, verwenden Sie ein gesondertes Ablaufdiagramm. Jedes separate Ablaufdiagramm muss in dem Ablaufdiagramm für den Hauptereignisablauf durch Scripts, Randnotizen oder Anmerkungen referenziert werden, um anzuzeigen, wo dieser auftreten soll.

Wenn das optionale oder außergewöhnliche Ablaufverhalten an beliebiger Stelle stattfinden kann, z. B. Verhalten bei einem bestimmten Ereignis, sollte das Ablaufdiagramm für den Hauptereignisablauf mit einem Kommentar versehen werden, in dem festgehalten wird, dass das im optionalen/außergewöhnlichen Ablaufdiagramm beschriebene Verhalten ausgeführt werden soll, wenn ein bestimmtes Ereignis eintritt. Wenn ein signifikanter Teil des Verhaltens ereignisgesteuert ist, können Sie alternativ Zustandsdiagramme verwenden, um das Verhalten des Systems zu beschreiben. Weitere Informationen finden Sie in Zustandsdiagramm.

Ablaufdiagramme mit Subsystemen vereinfachen (optional)

Bei der Realisierung eines Anwendungsfalls wird der Ereignisablauf normalerweise mit den ausführenden Objekten beschrieben, d. h. als Interaktion zwischen Designobjekten. Zur Vereinfachung von Diagrammen und zur Identifizierung wiederverwendbaren Verhaltens müssen Sie unter Umständen einen untergeordneten Ereignisablauf in einem Subsystem kapseln. In diesem Fall werden große Unterabschnitte des Ablaufdiagramms durch eine einzige Nachricht an das Subsystem ersetzt. Im Subsystem kann ein gesondertes Ablaufdiagramm die internen Interaktionen innerhalb des Subsystems veranschaulichen, die das erforderliche Verwalten erbringen. (Weitere Informationen finden Sie in Subsystemdesign).

Untergeordnete Nachrichtenfolgen in Ablaufdiagrammen müssen in einem Subsystem gekapselt werden, wenn

  • die untergeordnete Nachrichtenfolge wiederholt in unterschiedlichen Anwendungsfallrealisierungen auftritt, d. h. dieselben (oder ähnliche) Nachrichten werden an dieselben (oder ähnliche) Objekte gesendet und liefern dasselbe Endergebnis. Das Wort 'ähnlich' wird verwendet, weil unter Umständen bestimmte Designarbeiten vorgenommen werden müssen, um das Verhalten wiederverwendbar zu machen.
  • die untergeordnete Nachrichtenfolge nur in einer Anwendungsfallrealisierung vorkommt, aber geplant ist, sie mehrfach in künftigen Iterationen oder in ähnlichen Systemen auszuführen. Dieses Verhalten sich als wiederverwendbare Komponente eignen.
  • Der untergeordnete Ablauf findet nur in einer Anwendungsfallrealisierung statt, er ist zwar komplex, aber leicht zu kapseln, er muss in der Zuständigkeit einer Person oder eines Teams liegen und er liefert ein klar definiertes Ergebnis. In solchen Situationen erfordert das komplexe Verhalten in der Regel spezielles technisches Wissen oder Wissen in der speziellen Domäne und eignet sich deshalb gut für die Kapselung in einem Subsystem.
  • Der untergeordnete Ablauf wird in einer austauschbaren Komponente gekapselt (siehe Komponente). In diesem Fall ist ein Subsystem die geeignete Darstellung für die Komponente im Designmodell.

Im Begleittext beschriebenes Diagramm

Eine Anwendungsfallrealisierung kann bei Bedarf auf verschiedenen Ebenen in der Subsystemhierarchie beschrieben werden. Die Lebenslinien im mittleren Diagramm stellen Subsysteme dar. Die Interaktionen in den Kreisen stellen die interne Interaktionen der Subsystem-Members als Reaktion auf die Nachricht dar.

Dieser Ansatz hat die folgenden Vorteile:

  • Anwendungsfallrealisierungen werden übersichtlicher, insbesondere wenn das interne Design einiger Subsysteme sehr komplex ist.
  • Anwendungsfallrealisierungen können erstellt werden, bevor die internen Designs der Subsysteme erstellt sind. Dies ist beispielsweise in parallelen Entwicklungsumgebungen hilfreich (siehe "Parallel arbeiten").
  • Anwendungsfallrealisierungen werden generischer und lassen sich einfacher ändern, insbesondere wenn ein Subsystem durch ein anderes Subsystem ersetzt werden muss.

Beispiel:

Schauen Sie sich das folgende Ablaufdiagramm an, das zur Realisierung des Anwendungsfalls Ortsgespräch gehört:

Im Begleittext beschriebenes Diagramm

In diesem Diagramm gehören die grauen Klassen zu einem Subsystem "Netzverwaltung". Die anderen Klassen gehören zu einem Subsystem "Teilnehmerverwaltung". Dies weist darauf hin, dass es sich um ein Ablaufdiagramm mit mehreren Subsystemen handelt, d. h. ein Diagramm, in dem alle Objekte, die am Ereignisablauf beteiligt sind, enthalten sind, unabhängig davon, ob ihre Klassen zu verschiedenen Subsystemen gehören oder nicht.

Alternativ kann der Aufruf von Verhalten im Subsystem "Netzverwaltung" und die Ausführung einer bestimmten Schnittstelle in diesem Subsystem gezeigt werden. Angenommen, das Subsystem "Netzverwaltung" enthält eine Schnittstelle ICoordinator, die vom Subsystem "Teilnehmerverwaltung" verwendet wird:

Im Begleittext beschriebenes Diagramm

Die Schnittstelle ICoordinator wird von der Klasse Koordinator im Subsystem "Netzverwaltung" realisiert. In Anbetracht dessen können das Subsystem "Netzverwaltung" selbst und die Schnittstelle "ICoordinator" anstelle von Instanzen der Klassen im Subsystem "Netzverwaltung" im Ablaufdiagramm verwendet werden:

Im Begleittext beschriebenes Diagramm

Beachten Sie, dass die Klasseninstanzen "Koordinator", "Zifferninformation" und "Netz" durch das übergeordnete Subsystem ersetzt werden. Alle Aufrufe an das Subsystem werden stattdessen über die Schnittstelle ICoordinator ausgeführt.

Schnittstellen in Lebenslinien anzeigen

Um eine echte Substitutionsfähigkeit von Subsystemen, die dieselbe Schnittstelle realisieren, zu erreichen, darf nur ihre Schnittstelle in Interaktionen (und in Diagrammen im Allgemeinen) sichtbar sein. Andernfalls müssen die Interaktionen (oder Diagramme) geändert werden, wenn die Subsysteme ersetzt werden.

Beispiel:

In ein Ablaufdiagramm kann nur die Schnittstelle ICoordinator und nicht das bereitstellende Subsystem aufgenommen werden:

Im Begleittext beschriebenes Diagramm

Das Senden einer Nachricht an eine Schnittstellenlebenslinie bedeutet, dass jedes Subsystem, das die Schnittstelle realisiert, für die Schnittstelle im Diagramm eingesetzt werden kann. Von der Lebenslinie der Schnittstelle ICoordinator gehen keine Nachrichten aus, da unterschiedliche Subsysteme, die die Schnittstelle realisieren, unterschiedliche Nachrichten senden können. Wenn Sie jedoch beschreiben möchten, welche Nachrichten von jedem Subsystem, das die Schnittstelle realisiert, gesendet werden sollen (oder gesendet werden dürfen), können solche Nachrichten von der Schnittstellenlebenslinie ausgehen.

Parallel arbeiten

Manchmal kann es angebracht sein, ein Subsystem mehr oder weniger unabhängig und parallel zur Entwicklung anderer Subsysteme zu entwickeln. Für diesen Ansatz müssen jedoch erst die Subsystemabhängigkeiten durch Identifizierung der Schnittstellen zwischen den Subsystemen festgestellt werden.

Diese Arbeiten können wie folgt ausgeführt werden:

  1. Konzentrieren Sie sich auf die Anforderungen, die die Schnittstellen zwischen den Subsystemen betreffen.
  2. Erstellen Sie Entwürfe der erforderlichen Schnittstellen und zeigen Sie die Nachrichten an, die die Grenzen der Subsysteme überschreiten.
  3. Zeichnen Sie Ablaufdiagramme mit den Subsystemen für jeden Anwendungsfall.
  4. Präzisieren Sie die für die Nachrichten erforderlichen Schnittstellen.
  5. Entwickeln Sie die Subsysteme parallel und verwenden Sie die Schnittstellen als Synchronisationsinstrumente zwischen den Entwicklungsteams.

Sie können die Ablaufdiagramme auch nur mit Subsystemen oder nur mit ihren Schnittstellen aufbauen. In einigen Projekten kann es sogar erforderlich ein, die Klassen mit den Schnittstellen zu implementieren, damit Sie mit den Rest der Modellierung fortfahren können.

Persistenzbezogenes Verhalten beschreiben

Das ganze Ziel des objektorientierten Konzepts ist die Kapselung von Implementierungsdetails. Deshalb wäre es im Hinblick auf die Persistenz wünschenswert, ein persistentes Objekt zu haben, das wie ein transientes Objekt aussieht, nicht darauf achten zu müssen, dass das Objekt persistent ist, oder es anders behandeln zu müssen als andere Objekte. Das ist zumindest das Ziel.

In der Praxis kann es Situationen geben, in denen die Anwendung verschiedene Persistenzaspekte steuern muss:

  • wann persistente Objekt geschrieben und gelesen werden
  • wann persistente Objekt gelöscht werden
  • wie Transaktionen verwaltet werden
  • wie Sperrungen und Steuerung des gemeinsamen Zugriffs (Parallelität) erreicht werden

Persistente Objekte schreiben

Hierbei gibt es zwei Fälle zu berücksichtigen: das erste Mal, wenn das Objekt in den persistenten Objektspeicher geschrieben wird, und die nachfolgenden Male, wenn die Anwendung den persistenten Objektspeicher mit einer Objektänderung aktualisieren möchte.

In beiden Fällen richtet sich der zu verwendende Mechanismus nach den Operationen, die vom Persistenz-Framework unterstützt werden. Im Allgemeinen wird eine Nachricht an das Persistenz-Framework gesendet, das das persistente Objekt erstellen soll. Nachdem ein Objekt persistent festgeschrieben wurde, ist das Persistenz-Framework intelligent genug, um nachfolgende Änderungen an dem persistenten Objekt zu erkennen und diese in den persistenten Objektspeicher zu schreiben (normalerweise, wenn eine Transaktion festgeschrieben wird).

Im Folgenden sehen Sie ein Beispiel für die Erstellung eines persistenten Objekts:

Im Begleittext beschriebene Abbildung

Das Objekt PersistenceMgr ist eine Instanz von VBOS, einem Persistenz-Framework. OrderCoordinator erstellt einen persistenten Auftrag, indem er ihn als Argument mit einer Nachricht 'createPersistentObject' an den PersistenceMgr sendet.

Es ist im Allgemeinen nicht erforderlich, dies explizit zu modellieren, sofern es nicht wichtig ist zu wissen, dass das Objekt explizit an einem bestimmten Punkt in einem Ereignisablauf gespeichert wird. Wenn nachfolgende Operationen das Objekt abfragen müssen, muss das Objekt in der Datenbank vorhanden sein. Deshalb ist es wichtig zu wissen, dass das Objekt dort existiert.

Persistente Objekte lesen

Der Abruf von Objekten aus dem persistenten Objektspeicher ist erforderlich, damit die Anwendung Nachrichten an dieses Objekt senden kann. Denken Sie daran, dass Arbeiten in einem objektorientierten System durch Senden von Nachrichten an Objekte durchgeführt werden. Wenn das Objekt, dem Sie eine Nachrichten senden möchten, zwar in der Datenbank, aber noch nicht im Hauptspeicher ist, haben Sie ein Problem. Sie können keine Nachricht an etwas senden, das nicht existiert.

Kurz gesagt, Sie müssen eine Nachricht an ein Objekt senden, das weiß, wie die Datenbank abgefragt wird, das korrekte Objekt abruft und es instanziert. Nur dann können Sie die ursprüngliche Nachricht senden. Das Objekt, das ein persistentes Objekt instanziert, wird manchmal auch Factory-Objekt genannt. Ein Factory-Objekt ist für das Erstellen von Instanzen von Objekten, einschließlich persistenter Objekte verantwortlich. Mit einer Abfrage kann das Factory-Objekt so entworfen werden, dass es eine Gruppe von Objekten zurückgibt, die der Abfrage entsprechen.

Objekte sind generell durch ihre Assoziationen eng miteinander verbunden, deshalb ist es normalerweise nur erforderlich, das Stammobjekt in einem Objektgraphen abzurufen. Der Rest wird im Wesentlichen transparent über die die Assoziationen mit dem Stammobjekt aus der Datenbank 'extrahiert'. (Ein guter Persistenzmechanismus weis dies intelligent zu tun: Er ruft Objekte nur ab, wenn sie benötigt werden. Andernfalls werden unnötigerweise zu viele Objekte instanziert. Das Abrufen von Objekten, bevor sie benötigt werden, ist eines der Hauptleistungsprobleme allzu simpler Persistenzmechanismen.)

Das folgende Beispiel zeigt, wie das Abrufen von Objekten aus dem persistenten Objektspeicher modelliert werden kann. In einem echten Ablaufdiagramm wird das DBMS nicht gezeigt, da es im Factory-Objekt gekapselt ist.

Im Begleittext beschriebene Abbildung

Persistente Objekte löschen

Das Problem mit persistenten Objekten ist, dass sie persistent sind! Anders als transiente Objekte, die einfach "verschwinden", wenn der Prozess, der sie erstellt hat, beendet wird, existieren persistente Objekte so lange, bis sie explizit gelöscht werden. Es ist also wichtig, das Objekt zu löschen, wenn es nicht mehr benötigt wird.

Dies lässt sich jedoch nur schwer feststellen. Nur weil eine Anwendung ein Objekt nicht mehr benötigt, heißt dies noch lange nicht, dass alle anderen - aktuellen oder künftigen - Anwendungen das Objekt nicht mehr brauchen. Da Objekte Assoziationen haben (können), von denen sie selbst nicht unbedingt wissen, ist es nicht immer leicht herauszufinden, ob es in Ordnung ist, ein Objekt zu löschen.

Im Design kann dies semantisch mit Zustandsdiagrammen dargestellt werden. Wenn das Objekt den Endzustand erreicht, kann es freigegeben werden. Entwickler, die für die Implementierung persistenter Klassen verantwortlich sind, können die Informationen aus dem Zustandsdiagramm verwenden, um das entsprechende Verhalten des Persistenzmechanismus für die Freigabe des Objekts aufzurufen. Der Designer der Anwendungsfallrealisierung ist dafür verantwortlich, die entsprechenden Operationen aufzurufen, damit das Objekt seinen Endzustand erreicht, wenn das Objekt gelöscht werden kann.

Wenn ein Objekt eng mit anderen Objekten verbunden ist, kann es schwierig sein festzustellen, ob das Objekt gelöscht werden kann. Da ein Factory-Objekt die Struktur des Objekts und die Objekte kennt, mit denen es verbunden ist, kann es hilfreich sein, dem Factory-Objekt eine Klasse zuzuordnen, die bestimmen soll, ob eine bestimmte Instanz gelöscht werden kann. Das Persistenz-Framework kann diese Funktionalität auch bereitstellen.

Transaktionen modellieren

Transaktionen definieren eine Gruppe von Operationsaufrufen, die atomar ist, d. h. entweder werden alle Operationsaufrufe oder keiner ausgeführt. Im Kontext von Persistenz definiert eine Transaktion eine Gruppe von Änderungen für eine Gruppe von Objekten, die alle ausgeführt oder alle nicht ausgeführt werden. Transaktionen unterstützten Konsistenz, indem sie sicherstellen, dass Gruppen von Objekten von einem konsistenten Zustand in einen anderen versetzt werden.

Es gibt verschiedene Optionen, um Transaktionen in Anwendungsfallrealisierungen zu zeigen:

  • Als Text. Mit Scripts am Rande des Ablaufdiagramms können Transaktionsgrenzen wie gezeigt dokumentiert werden. Diese Methode ist einfach und lässt eine Reihe von Mechanismen für die Implementierung der Transaktion zu.

Im Begleittext beschriebenes Diagramm

Transaktionsgrenzen mit Textkommentaren darstellen

  • Mit expliziten Nachrichten. Wenn der verwendete Transaktionsmanagementmechanismus explizite Nachrichten verwendet, um Transaktionen zu beginnen und zu beenden, können diese Nachrichten wie gezeigt explizit im Ablaufdiagramm dargestellt werden:

Im Begleittext beschriebene Abbildung

Ablaufdiagramm, das explizite Nachrichten zum Starten und Stoppen von Transaktionen zeigt.

Behandlung von Fehlerbedingungen

Wenn nicht alle Operationen, die in einer Transaktion angegeben sind, durchgeführt werden können (normalerweise, weil ein Fehler aufgetreten ist), wird die Transaktion abgebrochen, und alle in der Transaktion vorgenommenen Änderungen werden rückgängig gemacht. Antizipierte Fehlerbedingungen stellen häufig außergewöhnliche Ereignisabläufe in Anwendungsfällen dar. In anderen Fällen treten Fehlerbedingungen ein, weil ein Fehler im System vorliegt. Fehlerbedingungen sollten auch in Interaktionen dokumentiert werden. Einfache Fehler und Ausnahmen können in der Interaktion angezeigt werden, wenn sie auftreten. Komplexe Fehler und Ausnahmen erfordern unter Umständen eigene Interaktionen.

Fehlermodi bestimmter Objekte können in Zustandsdiagrammen angezeigt werden. Ein bedingter Steuerungsablauf, der diese Fehlermodi behandelt, kann in der Interaktion angezeigt werden, in der der Fehler bzw. die Ausnahme auftritt.

Handhabung der Parallelität

Parallelität beschreibt die Steuerung des Zugriffs auf kritische Systemressourcen im Verlauf einer Transaktion. Um den konsistenten Zustand des Systems aufrecht zu erhalten, kann eine Transaktionen exklusiven Zugriff auf bestimmte Schlüsselressourcen im System erfordern. Die Exklusivität kann sich auf die Fähigkeit beziehen, eine Gruppe von Objekten zu lesen, zu schreiben bzw. lesen und zu schreiben.

Im Folgenden wird anhand eines einfachen Beispiels erläutert, warum es erforderlich sein kann, den Zugriff auf eine Gruppe von Objekten einzuschränken. Angenommen, Sie führen ein einfaches Auftragserfassungssystem aus. Leute rufen an, um Bestellungen aufzugeben, die dann verarbeitet und geliefert werden. Diese Bestellungen können Sie sich als Art Transaktion vorstellen.

Zur Veranschaulichung der erforderlichen Parallelitätssteuerung stellen Sie sich vor, jemand ruft an, um ein Paar neue Wanderstiefel zu bestellen. Wenn die Bestellung im System erfasst wird, wird geprüft, ob die gewünschten Wanderstiefel in der gewünschten Größe am Lager sind. Wenn diese Prüfung ein positives Ergebnis hat, wird dieses Paar reserviert, so dass niemand anderes es kaufen kann, bevor die Bestellung ausgeliefert werden kann. Nach der Auslieferung der Bestellung werden die Stiefel aus dem Bestand entfernt.

Zwischen Bestelleingang und Auslieferung befinden sich die Stiefel in einem speziellen Zustand (—). Sie sind zwar im Bestand, aber der Bestellung "fest zugeschrieben". Wenn die Bestellung aus irgendeinem Grund storniert wird (der Kunde ändert seine Meinung oder seine Kreditkarte ist abgelaufen), gehen die Stiefel in den Bestand zurück. Nach der Auslieferung der Bestellung wird davon ausgegangen, dass die kleine Firma keine Aufzeichnung darüber behalten muss, dass diese Stiefel einmal in ihrem Bestand war.

Das Ziel der Parallelität ist wie bei Transaktionen sicherzustellen, dass das System von einem konsistenten Zustand in einen anderen wechselt. Außerdem wird versucht zu gewährleisten, dass eine Transaktion alle Ressourcen zur Verfügung hat, die sie benötigt, um ihre Arbeit auszuführen. Die Parallelitätssteuerung kann auf verschiedene Arten implementiert werden, dazu gehören Ressourcensperren, Semaphore und Shared-Memory-Blockierungen und private Arbeitsbereiche.

In einem objektorientierten System ist es schwierig, nur auf der Basis der Nachrichtenmuster zu entscheiden, ob eine bestimmte Nachricht eine Zustandsänderung für ein Objekt bewirken kann. Es ist auch möglich, dass Implementierungen den Bedarf an Einschränkung des Zugriffs auf bestimmte Typen von Ressourcen umgehen, indem sie für jede Transaktion eine eigene Sicht mit dem Zustand des Systems am Anfang der Transaktion bereitstellen. In diesem Fall können andere Prozesse den Zustand eines Objekts ändern, ohne die "Sicht" anderer ausgeführter Transaktionen zu beeinflussen.

Damit die Implementierung nicht eingeschränkt wird, sollen im Design nur die Ressourcen genannt werden, auf die die Transaktion exklusiven Zugriff haben muss. Um das vorherige Beispiel noch einmal zu bemühen, es muss gezeigt werden, dass ein exklusiver Zugriff auf die bestellten Stiefel erforderlich ist. Eine einfache Alternative ist, die Beschreibung der gesendeten Nachricht als Kommentar einzufügen, in dem darauf hingewiesen wird, dass die Anwendung exklusiven Zugriff auf das Objekt haben muss. Der Implementierer kann diese Informationen dann verwenden, um festzustelle, wie diese Parallelitätsanforderung am besten implementiert wird. Ein Beispielablaufdiagramm, dass die Annotation der Nachrichten, die exklusiven Zugriff benötigen, zeigt, sehen Sie im Folgenden. Die Voraussetzung ist, dass alle Sperren freigegeben werden, wenn die Transaktion abgeschlossen wird.

Im Begleittext beschriebenes Diagramm

Ein Beispiel, dass kommentierte Zugriffssteuerung in einem Ablaufdiagramm zeigt.

Warum nicht der Zugriff auf alle in einer Transaktion benötigten Objekte beschränkt wird, hat den Grund, dass häufig nur einige wenige Objekte Zugriffsbeschränkungen haben dürfen. Wenn Sie den Zugriff auf alle Objekte einschränken, die an einer Transaktion teilnehmen, verschwenden Sie wertvolle Ressourcen und können Leistungsengpässe erzeugen anstatt verhindern.

Beschreibung des Ereignisablaufs präzisieren

Im Ereignisablauf der Anwendungsfallrealisierung müssen Sie möglicherweise zusätzliche Beschreibungen zu den Ablaufdiagrammen hinzufügen, wenn der Ereignisablauf aus der alleinigen Untersuchung der Nachrichten, die zwischen den teilnehmenden Objekten gesendet werden, nicht klar hervorgeht. Dies ist beispielsweise der Fall, wenn Kommentare zur Ablaufsteuerung, Anmerkungen zu bedingtem Verhalten oder eine Klärung des Operationsverhaltens erforderlich ist, um externen Beobachtern das Lesen des Diagramms einfache zu machen.

Der Ereignisablauf wird zunächst in der Anwendungsfallanalyse skizziert. In diesem Schritt präzisieren Sie den Ereignisablauf bei Bedarf, um die Ablaufdiagramme verständlicher zu machen.

Häufig ist am Namen der Operation allein nicht erkennbar, warum die Operation durchgeführt wird. Anmerkungen oder Scripts am Rand des Diagramms können erforderlich sein, um das Ablaufdiagramm transparenter zu gestalten. Anmerkungen und Scripts können auch erforderlich sein, um den Steuerungsablauf, z. B. Entscheidungsschritte, Schleifen und Verzweigungen, darzustellen. Auch für die Korrelation von Erweiterungspunkten im Anwendungsfall mit speziellen Positionen in Ablaufdiagrammen können Textanweisungen erforderlich sein.

Die vorherigen Beispiele in dieser Aufgabe haben verschiedene Möglichkeiten zur Annotation von Ablaufdiagrammen veranschaulicht.



Designklassen und Subsysteme vereinheitlichen

Wenn Sie Anwendungsfälle realisieren, müssen Sie die identifizierten Designklassen und Subsysteme vereinheitlichen, um Homogenität und Konsistenz im Designmodell sicherzustellen.

Beachten Sie die folgenden Punkte:

  • Die Namen der Modellelemente müssen ihre Funktion beschreiben.
  • Vermeiden Sie die Verwendung ähnlich klingender Namen und von Synonymen, da sie eine Unterscheidung zwischen den Modellelementen erschweren.
  • Führen Sie Modellelemente, die ähnliches Verhalten definieren oder dasselbe Phänomen darstellen, zusammen.
  • Führen Sie Entitätsklassen zusammen, die dasselbe Konzept darstellen oder dieselben Attribute haben, selbst wenn ihr definiertes Verhalten anders ist.
  • Verwenden Sie Vererbung für die Abstraktion von Modellelementen, was das Modell in Regel stabiler macht.
  • Wenn Sie ein Modellelement aktualisieren, aktualisieren Sie auch die entsprechende Beschreibung des Ereignisablaufs der Anwendungsfallrealisierungen.
Ergebnisse auswerten

In diesem Stadium sollten Sie das Designmodell prüfen, um sicherzustellen, dass Sie mit der Arbeit auf dem richtigen Weg sind. Es ist nicht erforderlich, das Modell im Detail zu prüfen, aber Sie sollten sich das Designmodell ansehen, während Sie damit arbeiten.

Schauen Sie sich insbesondere die Anwendungsfallrealisierung im Abschnitt Design prüfen an.

Weitere Informationen