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.)
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 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.
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:
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.
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.
|
|