Aufgabe: Anwendungsfallanalyse
Diese Aufgabe beschreibt, wie Sie aus einem Anwendungsfall eine Anwendungsfallrealisierung auf Analyseebene entwickeln.
Zweck
  • Die Klassen identifizieren, die den Ablauf von Ereignissen in einem Anwendungsfall steuern.
  • Das Verhalten des Anwendungsfalls unter Verwendung von Anwendungsfallrealisierungen auf diese Klassen verteilen.
  • Die Zuständigkeiten, Attribute und Assoziationen der Klassen identifizieren.
  • Die Verwendung der Architekturmechanismen notieren.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Schritte
Anwendungsfallrealisierung für Analyse erstellen
Zweck Modellierungselement erstellen, mit dem das Verhalten des Anwendungsfalls beschrieben wird.  

Anwendungsfälle sind der zentrale Bestandteil der meisten frühen Analyse- und Designarbeiten. Um den Übergang zwischen anforderungszentrierten Aufgaben und analyse-/designzentrischen Aufgaben zu aktivieren, dient die Anwendungsfallrealisierung als Brücke, um das Verhalten in den Analyse- und Designmodellen zum Anwendungsfall zurückverfolgen zu können und Kollaborationen auf der Basis des Anwendungsfallkonzepts zu organisieren.

Sofern noch keine Anwendungsfallrealisierung für die Analyse im Analysemodell für den Anwendungsfall existiert, erstellen Sie eine. 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 Analyse zum zugehörigen Anwendungsfall eingerichtet werden.

Weitere Informationen zu Anwendungsfallrealisierungen finden Sie im Abschnitt Technik: Anwendungsfallrealisierung.

Anwendungsfallbeschreibung ergänzen
Zweck Zusätzliche Informationen erfassen, die erforderlich sind, um das geforderte interne Verhalten des Systems zu verstehen, das möglicherweise in der Anwendungsfallbeschreibung für den Kunden des Systems fehlt.  

Die Beschreibung der einzelnen Anwendungsfälle sind nicht immer ausreichend, um Analyseklassen und ihre Objekte zu finden. Der Kunde findet Informationen zu den internen Vorgängen im System normalerweise uninteressant, so dass solche Informationen in den Anwendungsfallbeschreibungen weggelassen werden können. In diesen Fällen liest sich die Anwendungsfallbeschreibung wie eine 'Blackbox-Beschreibung', in der interne Details zu den Aktionen, die das System als Reaktion auf die Aktionen eines Akteurs ausführt, fehlen oder nur zusammenfassend beschrieben sind. Um die Objekte zu finden, die den Anwendungsfall ausführen, benötigen Sie die 'Whitebox-Beschreibung' mit den Erläuterungen zu den Systemaktionen aus interner Perspektive.

Beispiel

Für einen Geldautomaten (GA) könnte der Kunde des Systems den folgenden Satz vorziehen, der das Verhalten des Systems für die Benutzerauthentifizierung beschreibt:

"Der GA prüft die Karte des Bankkunden."

Obwohl diese Beschreibung für den Kunden ausreichen mag, gibt sie nicht wirklich Aufschluss über die Vorgänge, die im Geldautomaten ablaufen, wenn die Karte geprüft wird.

Zur Abbildung der internen Funktionsweise des Systems auf einer Detaillierungsebene, die eine Identifizierung der Objekte ermöglicht, werden zusätzliche Informationen benötigt. Die erweiterte Beschreibung zur Überprüfung von Karten im Geldautomaten könnte wie folgt lauten:

"Der GA sendet die Kontonummer und die PIN des Kunden zur Prüfung an das GA-Netz. Das GA-Netz gibt eine Erfolgsnachricht zurück, wenn die Kontonummer und die PIN des Kunden korrekt sind und der Kunde berechtigt ist, Transaktionen durchzuführen. Andernfalls gibt das ATM-Netz eine Fehlernachricht zurück."

Diese Detaillierungsebene vermittelt eine klare Idee davon, welche Informationen erforderlich sind (Kontonummer und PIN) und wer für die Authentifizierung verantwortlich ist (das GA-Netz, ein Akteur im Anwendungsfallmodell). Aufgrund dieser Informationen können zwei potenzielle Objekte (ein Objekt Kunde mit den Attributen Kontonummer und PIN und eine GA-Netzschnittstelle) und ihre Zuständigkeiten identifiziert werden.

Schauen Sie sich die Anwendungsfallbeschreibung an, um festzustellen, ob das interne Verhalten des Systems klar definiert ist. Das interne Verhalten des Systems darf keine Mehrdeutigkeiten aufweisen, so dass klar ist, was das System zu leisten hat. Es ist nicht erforderlich, die Elemente im System (Objekte) zu definieren, die für die Umsetzung dieses Verhalten verantwortlich sind. Alles, was benötigt wird, ist eine klare Definition, was getan werden muss.

Zu den Informationsquellen für solche Details gehören Fachmänner, die bei der Definition der Systemaktivitäten helfen können. Eine gute Frage, die Sie stellen sollten, wenn Sie über ein bestimmtes Systemverhalten nachdenken, ist die folgende: "Was bedeutet es für das System, diese Aktivität auszuführen?". Wenn das, was das System tut, um das Verhalten zu erbringen, nicht klar genug definiert ist, um diese Frage zu beantworten, müssen wahrscheinlich noch mehr Informationen beschafft werden.

Zur Ergänzung des Ablaufs von Ereignissen können Sie zwischen den folgenden Alternativen wählen:

  • Gar keine Beschreibung. Diese Alternative bietet sich an, wenn Sie der Meinung sind, dass die Interaktionsdiagramme selbsterklärend sind, oder wenn der Ablauf der Ereignisse des entsprechenden Anwendungsfalls eine ausreichende Beschreibung liefert.
  • Vorhandene Beschreibung des Ereignisablaufs ergänzen. Fügen Sie dem Ablauf der Ereignisse in den Bereichen, in denen der vorhandene Test Fragen bezüglich der vom System auszuführenden Aktionen offen lässt, ergänzende Beschreibungen hinzu.
  • Beschreiben Sie den Ereignisablauf als vollständigen inhaltlichen Ablauf gesondert von der "externen" Beschreibung des Ereignisablaufs im Anwendungsfall. Diese Alternative ist angemessen, wenn das interne Verhalten des Systems nur wenig Ähnlichkeit mit dem externen Verhalten des Systems aufweist. In diesem Fall ist eine vollständig gesonderte Beschreibung, die der Anwendungsfallrealisierung für Analyse und nicht dem Anwendungsfall zugeordnet wird, gerechtfertigt.
Analyseklassen aus dem Anwendungsfallverhalten ableiten
Zweck Geeignete Modellelemente (Analyseklassen) identifizieren, die in der Lage sind, das in den Anwendungsfällen beschriebene Verhalten zu erbringen.  

Das Suchen geeigneter Analyseklassen ist der erste Schritt bei der Umsetzung des Systems aus einer reinen Darstellung des geforderten Verhaltens in eine Beschreibung der detaillierten Funktionsweise des Systems. Dabei werden Analyseklassen verwendet, um die Rollen der Modellelemente darzustellen, die das erforderliche Verhalten erbringen, um die in den Anwendungsfällen angegebenen funktionalen Anforderungen und die in den ergänzenden Anforderungen genannten nicht funktionalen Anforderungen zu erfüllen. Mit der Verlagerung des Projektfokus auf das Design entwickeln diese Rollen eine Reihe von Designelementen, die die Anwendungsfälle realisieren.

Die in der Anwendungsfallanalyse angegebenen Rollen, beschreiben primär das Verhalten der obersten Schichten des Systems - das anwendungsspezifische Verhalten und das domänenspezifische Verhalten. Grenzklassen und Steuerungsklassen entwickeln sich normalerweise zu Designelementen der Anwendungsschicht, Entitätsklassen hingegen zu domänenspezifischen Designelementen. Designelemente der unteren Schichten werden in der Regel aus den Analysemechanismen entwickelt, die von den hier identifizierten Analyseklassen verwendet werden.

Die hier beschriebene Technik verwendet drei unterschiedliche Perspektiven des Systems, um die geeigneten Klassen zu ermitteln. Die drei Perspektiven sind die der Schnittstelle zwischen dem System und seinen Akteuren, der vom System verwendeten Informationen und der Steuerlogik des Systems. Die entsprechenden Klassenstereotypen Grenzklasse, Entitätsklasse und Steuerungsklasse sind Hilfsmittel, die während der Analyse verwendet werden, während des Design jedoch "verschwinden".

Identifikation von Klassen bedeutet lediglich, dass die Klassen identifiziert, benannt und in wenigen Sätzen beschrieben werden müssen.

Weitere Informationen zur Identifikation von Analyseklassen finden Sie unter Analyseklasse. Weitere Informationen zu Anwendungsfallrealisierungen für die Analyse finden Sie unter Anwendungsfallrealisierung.

Wenn besondere Analysemechanismen und/oder Analysemuster in den projektspezifischen Richtlinien dokumentiert wurden, sollten diese als weitere Quelle der "Inspiration" für die Analyseklassen verwendet werden.

Verhalten auf Analyseklassen verteilen
Zweck Anwendungsverhalten mit Hilfe von kollaborierenden Analyseklassen beschreiben und die Zuständigkeiten von Analyseklassen bestimmen.  

Führen Sie für jeden unabhängigen untergeordneten Ablauf (Szenario) die folgenden Schritte aus:

  • Erstellen Sie mindestens ein Interaktionsdiagramm (Kommunikation oder Ablauf). In der Regel wird mindestens ein Diagramm für den Hauptereignisablauf des Anwendungsfalls und mindestens ein Diagramm für jeden alternativen/außergewöhnlichen Ablauf benötigt. Gesonderte Diagramme werden normalerweise für die untergeordneten Abläufe mit komplexer Ablaufsteuerung oder Entscheidungspunkten oder für die Vereinfachung von Abläufen benötigt, die zu komplex sind, um sie in einem Diagramm übersichtlich erfassen zu können.
  • Identifizieren Sie die Analyseklassen, die für das geforderte Verhalten verantwortlich sind, indem Sie sich durch den Ablauf der Ereignisse des Szenarios arbeiten und sicherstellen, dass das gesamte für den Anwendungsfall erforderliche Verhalten in der Anwendungsfallrealisierung abgedeckt ist.
  • Veranschaulichen Sie die Interaktionen zwischen Analyseklassen im Interaktionsdiagramm. Das Interaktionsdiagramm sollte außerdem die Interaktionen des Systems mit seinen Akteuren zeigen. (Die Interaktionen sollten von einem Akteur ausgehen, da der Anwendungsfall immer von einem Akteur aufgerufen wird.)
  • Schließen Sie die Klassen ein, die die Steuerungsklassen verwendeter Anwendungsfälle darstellen. (Verwenden Sie für jeden Erweiterungsanwendungsfall ein separates Interaktionsdiagramm, das nur das abweichende Verhalten des Erweiterungsanwendungsfalls zeigt.)

Beispiel für Kommunikationsdiagramm

Ein Kommunikationsdiagramm für den Anwendungsfall Pfandartikel entgegennehmen.

Wenn besondere Analysemechanismen und/oder Analysemuster in den projektspezifischen Richtlinien dokumentiert wurden, sollten diese in der Zuordnung der Zuständigkeiten und den Interaktionsdiagrammen berücksichtigt werden.

Zuständigkeiten beschreiben
Zweck Die Zuständigkeiten einer Klasse von Objekten beschreiben, die sich aus dem Anwendungsfallverhalten ermitteln lassen.  

Eine Zuständigkeit beschreibt etwas, was von einem Objekt verlangt werden kann. Zuständigkeiten entwickeln sich zu einer (aber in der Regel mehr) Operation für Klassen im Design. Sie lassen sich wie folgt charakterisieren:

  • Die Aktionen, die das Objekt ausführen kann.
  • Das Wissen, das das Objekt verwaltet und anderen Objekten zur Verfügung stellt.

Jede Analyseklasse muss mehrere Zuständigkeiten haben. Eine Klasse, die nur eine Zuständigkeit hat, ist wahrscheinlich zu einfach, wohingegen eine Klasse mit Dutzenden von Zuständigkeiten das vernünftige Maß überschreitet und deshalb in mehrere Klassen aufteilt werden sollte.

Dass alle Objekte erstellt und gelöscht werden können, versteht sich von selbst. Formulieren Sie Offensichtliches nicht erneut, sofern das Objekt keine speziellen Verhaltensweisen aufweist, wenn es erstellt oder gelöscht wird. (Einige Objekte können nicht entfernt werden, wenn bestimmte Beziehungen existieren.)

Zuständigkeiten finden

Zuständigkeiten werden aus Nachrichten in Interaktionsdiagrammen abgeleitet. Schauen Sie sich für jede Nachricht die Klasse des Objekts an, an das die Nachricht gesendet wird. Falls die Zuständigkeit noch nicht existiert, erstellen Sie eine neue Zuständigkeit, die das geforderte Verhalten erbringt.

Weitere Zuständigkeiten werden von nicht funktionalen Anforderungen abgeleitet. Wenn Sie eine neue Zuständigkeit erstellen, überprüfen Sie die nicht funktionalen Anforderungen, um festzustellen, ob zugehörige Anforderungen h existieren. Erweitern Sie daraufhin die Beschreibung der Zuständigkeit oder erstellen Sie eine neue Zuständigkeit, um diese Anforderungen darzustellen.

Zuständigkeiten dokumentieren

Zuständigkeiten werden mit einem kurzen Namen (wenige Wörter) und einer kurzen Beschreibung (mehrere Sätze) dokumentiert. Die Beschreibung gibt Aufschluss darüber, was das Objekt tut, um die Zuständigkeit zu erfüllen, und welches Ergebnis zurückgegeben wird, wenn die Zuständigkeit aufgerufen wird.

Attribute und Assoziationen beschreiben
Zweck Die anderen Klassen definieren, von denen die Analyseklasse abhängig ist.
Die Ereignisse in anderen Analyseklassen definieren, die die Klasse kennen muss.
Die Informationen definieren, die die Analyseklassen verwalten muss.  

Bei der Erfüllung ihrer Zuständigkeiten sind Klassen häufig auf andere Klassen angewiesen, die ein bestimmtes Verhalten erbringen. Assoziationen dokumentieren die Beziehungen zwischen Klassen und machen die Koppelung von Klassen verständlicher. Ein besseres Verständnis der Klassenkoppelung und die Reduzierung von Klassenkoppelungen auf ein Minimum können dabei helfen, bessere und widerstandsfähigere Systeme zu erstellen.

Die folgenden Schritte definieren die Attribute von Klassen und die Assoziationen zwischen Klassen:

Attribute definieren

Attribute werden verwendet, um Informationen nach Klasse zu speichern. Attribute werden im Speziellen verwendet, wenn die Information

  • "nach Wert" referenziert wird, d. h. es ist nur der Wert der Information, nicht ihre Position oder ihre Objekt-ID von Bedeutung,
  • das Objekt, zu dem die Information gehören, eindeutiger "Eigner" ist, d. h. keine anderen Objekte auf die Information verweisen,
  • von Operationen aufgerufen werden, die sie nur abrufen, setzen oder einfache Konvertierungen durchführen, d. h. die Information außer der Bereitstellung kein "eigentliches" Verhalten aufweist.

Falls die Information jedoch ein komplexes Verhalten hat, von zwei oder mehr Objekten gemeinsam verwendet wird oder "nach Referenz" zwischen zwei oder mehr Objekten übergeben wird, sollte die Information in einer separaten Klasse modelliert werden.

Der Attributname muss ein Substantiv sein, das Aufschluss darüber gibt, welche Information das Attribut enthält.

Die Beschreibung des Attributs muss beschreiben, welche Information im Attribut gespeichert wird. Die Beschreibung kann optional sein, wenn die gespeicherte Information eindeutig aus dem Attributnamen hervorgeht.

Der Attributtyp ist der einfache Datentyp des Attributs. Beispiele sind string, integer, number.

Assoziationen zwischen Analyseklassen einrichten

Studieren Sie zunächst die Verbindungen in den Interaktionsdiagrammen, die Sie im Schritt Verhalten auf Analyseklassen verteilen erstellt haben. Verbindungen zwischen Klassen zeigen an, dass Objekte der beiden Klassen miteinander kommunizieren müssen, um den Anwendungsfall auszuführen. Wenn mit dem Design des Systems begonnen wird, können diese Verbindungen auf mehrere Arten realisiert werden:

  • Das Objekt kann einen "globalen" Geltungsbereich haben. In diesem Fall kann jedes Objekt im System Nachrichten an dieses Objekt senden.
  • Einem Objekt kann das zweite Objekt als Parameter übergeben werden, woraufhin das Objekt Nachrichten an das übergebene Objekt senden kann.
  • Das Objekt kann eine permanente Assoziation zu dem Objekt haben, an das Nachrichten gesendet werden.
  • Das Objekt kann im Rahmen der Operation erstellt und gelöscht worden sein (d. h. es ist ein 'temporäres' Objekt). Solche Objekte werden als 'lokale' Objekte der Operation betrachtet.

Zu diesem frühen Zeitpunkt im "Leben" der Klasse ist es jedoch zu früh, diese Entscheidungen zu treffen. Es sind noch nicht genügend Informationen vorhanden, um fundierte Entscheidungen treffen zu können. Deshalb werden in der Analyse Assoziationen und Aggregationen erstellt, um Nachrichten darzustellen (und zu "transportieren"), die zwischen Objekten von zwei Klassen gesendet werden müssen. (Aggregation, eine spezielle Form der Assoziation, zeigt an, dass die Objekte an einer Teil-Ganz-Beziehung teilnehmen (siehe Technik: Assoziation und Technik: Aggregation).

Diese Assoziationen und Aggregationen werden im Klassendesign präzisiert.

Zeichnen Sie für jede Klasse ein Klassendiagramm, das die Assoziationen der Klasse zu anderen Klassen zeigt:

Beispielklassendiagramm mit Assoziationen und Aggregationen

Beispiel für ein Analyseklassendiagram für einen Teil eines Auftragserfassungssystems

Konzentrieren Sie sich ausschließlich auf die Assoziationen, die erforderlich sind, um die Anwendungsfälle zu realisieren. Fügen Sie keine Assoziation hinzu, von der Sie lediglich vermuten, dass sie vorhanden sein könnte, sondern nur Assoziationen, die nach den Interaktionsdiagrammen erforderlich sind.

Weisen Sie den Assoziationen Rollennamen und Multiplizitäten zu.

  • Ein Rollenname muss ein Substantiv sein, dass Aufschluss darüber gibt, welche Rolle das zugehörige Objekt in Bezug auf das zuordnende Objekt einnimmt.
  • Gehen Sie von der Multiplizität 0..* (0:N) aus, sofern Sie nichts Genaueres wissen. Eine Multiplizität von null bedeutet, dass die Assoziation optional ist. Vergewissern Sie sich, dass Sie dies wirklich beabsichtigen. Wenn ein Objekt nicht vorhanden ist, müssen Operationen, die die Assoziation verwenden, entsprechend angepasst werden.
  • Es können engere Grenzen für die Multiplizität definiert werden (z. B. 3..8).
  • Innerhalb der Multiplizitätsbereiche können Wahrscheinlichkeiten angegeben werden. Wenn Sie bei einer Multiplizität von 0..* in 85 % der Fälle Werte zwischen 10 und 20 erwarten, halten Sie dies schriftlich fest. Diese Information ist für das Design von entscheidender Bedeutung. Wenn der persistente Speicher beispielsweise mit einer relationalen Datenbank implementiert werden soll, können die Datenbanktabellen mit engeren Grenzen besser organisiert werden.

Beschreiben Sie kurz, wie die Assoziation verwendet wird oder welche Beziehungen die Assoziation darstellt.

Ereignisabhängigkeiten zwischen Analyseklassen beschreiben

Objekt müssen manchmal wissen, wenn ein Ereignis in einem "Zielobjekt" eintritt, aber das Zielobjekt muss nicht alle Objekte kennen, die beim Eintreten des Ereignisses benachrichtigt werden müssen. Zur Kurzdarstellung dieser Abhängigkeit von der Ereignisbenachrichtigung kann eine Subskriptionsassoziation verwendet werden, die diese Abhängigkeit in einer kompakten und präzisen Weise darstellt.

Eine Subskriptionsassoziation zwischen zwei Objekten zeigt an, dass das subskribierende Objekt informiert wird, wenn ein bestimmtes Ereignis im subskribierten Objekt eingetreten ist. Eine Subskriptionsassoziation hat eine Bedingung, die das Ereignis definiert, das die Benachrichtigung des Subskribenten auslöst. Weitere Informationen hierzu finden Sie unter Subskriptionsassoziation.

Die Bedingungen der Subskriptionsassoziationmüssen mit abstrakten Merkmalen und nicht mit speziellen Attributen oder Operationen ausgedrückt werden. Auf diese Weise bleibt das zuordnende Objekt vom Inhalt des zugeordneten Entitätsobjekts unabhängig, das sich durchaus ändern kann.

Eine Subskriptionsassoziation ist erforderlich,

  • wenn ein Objekt durch etwas beeinflusst wird, das in einem anderen Objekt eintritt,
  • wenn ein neues Objekt erstellt werden muss, um ein Ereignis zu behandeln (wenn beispielsweise ein Fehler auftritt, muss ein neues Fenster erstellt werden, um den Benutzer zu benachrichtigen),
  • wenn ein Objekt wissen muss, wenn ein anderes Objekt instanziert, geändert oder gelöscht wird.

Die subskribierten Objekte sind normalerweise Entitätsobjekte. Entitätsobjekte sind in der Regel passive Datenspeicher, deren gesamtes Verhalten sich im Allgemeinen auf ihre Zuständigkeiten für die Datenspeicherung beziehen. Viele andere Objekte müssen häufig wissen, wenn sich die Entitätsobjekte ändern. Die Subskriptionsassoziation verhindert, dass das Entitätsobjekt diese anderen Objekte kennen muss. Sie 'registrieren' einfach ihr Interesse am Entitätsobjekt und werden benachrichtigt, wenn sich das Entitätsobjekt ändert.

Dies ist jedoch alles nur 'Geschicklichkeit bei der Analyse'. Im Design muss exakt definiert werden, wie diese Benachrichtigung funktioniert. Man könnte beispielsweise ein Framework für Benachrichtigungen kaufen oder ein solches Framework selbst entwerfen und erstellen. Für den Moment reicht es jedoch aus zu erwähnen, dass Benachrichtigung existiert.

Die Richtung der Assoziation zeigt an, dass nur das subskribierende Objekt von der Verbindung zwischen den beiden Objekten weiß. Die Subskription wird nur im subskribierenden Objekt beschrieben. Das zugeordnete Entitätsobjekt wird wie gewöhnlich definiert, ohne die anderen Objekte zu berücksichtigen, die möglicherweise an seinen Aktivitäten interessiert sind. Dies impliziert auch, dass ein subskribierendes Objekt dem Modell hinzugefügt oder aus diesem entfernt werden kann, ohne das subskribierte Objekte ändern zu müssen.

Anwendungsfallrealisierungen abgleichen
Zweck Die einzelnen Anwendungsfallrealisierungen für die Analyse abgleichen und eine Gruppe von Analyseklassen mit konsistenten Beziehungen identifizieren. 

Die Anwendungsfallrealisierungen für die Analyse werden als Ergebnis der Analyse eines bestimmten Anwendungsfalls entwickelt. Danach müssen die einzelnen Anwendungsfallrealisierungen für die Analyse abgeglichen werden. Schauen Sie sich die Analyseklassen und die unterstützenden Assoziationen an, die für jede der Anwendungsfallrealisierungen für die Analyse definiert sind. Identifizieren und korrigieren Sie Inkonsistenzen und entfernen Sie alle Duplikate. Zwei unterschiedliche Anwendungsfallrealisierungen für die Analyse können beispielsweise eine Analyseklasse enthalten, die zwar konzeptionell dieselbe ist, aber da die Analyseklassen von unterschiedlichen Designern identifiziert wurden, wurde ein jeweils anderer Name verwendet.  
Anmerkungen: Die Duplizierung von Analyseklassen in Anwendungsfallrealisierungen für die Analyse kann drastisch reduziert werden, wenn der Softwarearchitekt seinen Job gut macht und eine Ausgangsarchitektur definiert (siehe Architekturanalyse).

Wenn Sie die Modellelemente abgleichen, müssen unbedingt ihre Beziehungen berücksichtigt werden. Wenn zwei Klassen zusammengeführt werden oder eine Klasse eine andere ersetzt, müssen Sie die Beziehungen der ursprünglichen Klasse an die neue Klasse weitergeben.

Der Softwarearchitekt muss an dem Abgleich der Anwendungsfallrealisierungen für die Analyse teilnehmen, da diese Aufgabe ein Verständnis des geschäftlichen Kontextes und Voraussicht in Bezug auf die Softwarearchitektur voraussetzt, damit die Analyseklassen, die das Problem und die Lösungen am Besten schildern, ausgewählt werden können.

Weitere Informationen zu Klassen finden Sie unter Analyseklasse.

Analysemechanismen qualifizieren
Zweck Die von den Analyseklassen verwendeten Analysemechanismen identifizieren und zusätzliche Informationen dazu liefern, wie die Analyseklassen die Analysemechanismen anwenden.  

In diesem Schritt werden die Analysemechanismen für jede der identifizierten Analyseklassen untersucht.

Wenn eine Analyseklasse einen oder mehrere Analysemechanismen verwendet, helfen die Informationen, die jetzt zusammengestellt werden, dem Softwarearchitekten und den Designern, die Fähigkeiten zu bestimmen, die von den Architekturdesignmechanismen verlangt werden. Die Anzahl der Instanzen der Analyseklasse, ihre Größe, ihre Zugriffsrate und ihre erwartete Lebensdauer gehören mit zu den wichtigsten Merkmalen, die den Designern bei der Auswahl der richtigen Mechanismen helfen.

Qualifizieren Sie für jeden von einer Analyseklasse verwendeten Analysemechanismus die relevanten Merkmale, die bei der Auswahl der entsprechenden Design- und Implementierungsmechanismen berücksichtigt werden müssen. Diese richten sich nach dem Typ des Mechanismus. Geben Sie Bereiche an, sofern dies erforderlich ist oder falls immer noch viel Unsicherheit herrscht. Unterschiedliche Architekturmechanismen haben unterschiedliche Merkmale. Deshalb sind diese Informationen rein beschreibend und müssen nur insoweit strukturiert sein, dass eine Erfassung und Vermittlung der Informationen möglich ist. Während der Analyse sind diese Informationen im Allgemeinen spekulativ, aber die Erfassung hat trotzdem einen Sinn, da auf Vermutungen beruhende Schätzungen überarbeitet werden können, wenn mehr Informationen vorliegen.

Die von einer Klasse verwendeten Analysemechanismen und ihre Merkmale müssen nicht formal erfasst werden. Eine Anmerkung, die einem Diagramm hinzugefügt wird, oder ein Zusatz zur Beschreibung der Klasse reicht völlig aus, um diese Informationen zu vermitteln. Die Informationen zu den Merkmalen sind zu diesem Zeitpunkt der Klassenentwicklung ziemlich dünn und spekulativ, deshalb liegt das Hauptaugenmerk auf der Erfassung erwarteter Werte und nicht auf der formalen Definition der Mechanismen.

Beispiel

Die Merkmale des Persistenzmechanismus, der von einer Klasse Flug verwendet wird, könnte wie folgt qualifiziert werden:

Granularität: 2 bis 24 KB pro Flug

Größe: Bis zu 100.000

Zugriffsrate:

  • Erstellen/Löschen: 100 pro Stunde
  • Aktualisierung: 3.000 Aktualisierungen pro Stunde
  • Lesen: 9.000 Zugriffe pro Stunde

Beispiel

Die Merkmale des Persistenzmechanismus, der von einer Klasse Auftrag verwendet wird, könnte wie folgt qualifiziert werden:

Granularität: 2 bis 3 MB pro Auftrag

Größe: 4

Zugriffsrate:

  • Erstellen/Löschen: 1 pro Tag
  • Aktualisierung: 10 pro Tag
  • Lesen: 100 pro Stunde
Rückverfolgbarkeit einrichten
Zweck Die Rückverfolgbarkeitsbeziehungen zwischen dem Analysemodell und anderen Modellen verwalten. 

Die projektspezifischen Richtlinien legen fest, welche Rückverfolgbarkeit für Analysemodellelemente erforderlich ist.

Wenn es beispielsweise ein gesondertes Modell der Benutzerschnittstelle gibt, kann es hilfreich sein, Anzeigen oder andere Elemente der Benutzerschnittstelle in diesem Modell zu Grenzklassen im Analysemodell zurückzuverfolgen.

Ergebnisse prüfen
Zweck Sicherstellen, dass die Analyseobjekte den funktionale Anforderungen an das System entsprechen.
Sicherstellen, dass die Analyseobjekte und Interaktionen konsistent sind. 

Führen Sie zur Synchronisation und zum Abschluss der Anwendungsfallanalyse am Ende des Workshop eine formlose Prüfung durch.

Verwenden Sie die Prüflisten für die Arbeitergebnisse, die mit dieser Aufgabe erstellt wurden.



Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen