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.
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.
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.
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.
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.
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:
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:
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:
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:
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.
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:
-
Konzentrieren Sie sich auf die Anforderungen, die die Schnittstellen zwischen den Subsystemen betreffen.
-
Erstellen Sie Entwürfe der erforderlichen Schnittstellen und zeigen Sie die Nachrichten an, die die Grenzen der
Subsysteme überschreiten.
-
Zeichnen Sie Ablaufdiagramme mit den Subsystemen für jeden Anwendungsfall.
-
Präzisieren Sie die für die Nachrichten erforderlichen Schnittstellen.
-
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
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:
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.
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.
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 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.
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:
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.
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.
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.
|
|