Es gibt die folgenden stereotypen Analyseklassen:
-
Grenzklassen
-
Steuerungsklasse
-
Entitätsklassen
Die Anwendung von Stereotypen gibt Ihnen nicht nur spezifischere Prozessrichtlinien beim Suchen von Klassen, sondern
führt auch zu einem stabilen Objektmodell, da Änderungen am Modell eher nur einen bestimmten Bereich betreffen.
Änderungen in der Benutzerschnittstelle wirken sich beispielsweise nur auf Grenzklassen aus. Änderungen im
Steuerungsablauf wirken sich nur auf Steuerungsklassen aus und Änderungen an Langzeitinformationen nur auf
Entitätsklassen. Diese Stereotypen sind jedoch besonders hilfreich, um während Analyse und frühem Design Klassen zu
identifizieren. In späteren Phasen des Designs sollten Sie wahrscheinlich geringfügig andere Stereotypen verwenden, die
besser mit der Implementierungsumgebung, dem Anwendungstyp usw. korrelieren.
Eine Grenzklasse ist eine Klasse, die verwendet wird, um die Interaktion zwischen der Umgebung des Systems und
den systeminternen Vorgängen zu modellieren. Zu solchen Interaktionen gehören das Umsetzen und Übersetzen von
Ereignissen und das Festhalten von Änderungen in der Systempräsentation n (z. B. der Schnittstelle).
Grenzklassen modellieren Teile des Systems, die von ihrer Umgebung abhängig sind. Entitätsklassen und Steuerungsklassen
modellieren die Teile des Systems, die von der Umgebung des Systems unabhängig sind. Wenn Sie also die grafische
Benutzerschnittstelle oder das Kommunikationsprotokoll ändern müssen, betrifft diese Änderung nur die Grenzklassen,
nicht die Entitäts- und Steuerungsklassen.
Grenzklassen erleichtern außerdem das Verständnis des Systems, weil sie die Grenzen des Systems transparenter
gestalten. Sie sind hilfreich im Design, weil sie einen tauglichen Ausgangspunkt für die Identifizierung zugehöriger
Services darstellen. Wenn Sie beispielsweise eine Druckerschnittstelle in einer frühen Phase des Designs
identifizieren, stellen Sie frühzeitig fest, dass Sie auch die Formatierung von Druckausgaben modellieren müssen.
Zu allgemeinen Grenzklassen gehören Fenster, Kommunikationsprotokolle, Druckerschnittstellen, Sensoren und Terminals.
Es ist nicht erforderlich, Komponenten der Schnittstelle wie Schaltflächen als gesonderte Grenzklassen zu modellieren.
Im Allgemeinen ist ein vollständiges Fenster das differenzierteste Grenzobjekt. Außerdem sind Grenzklassen hilfreich,
um Schnittstellen zu möglicherweise nicht objektorientierten APIs (z. B. aus früheren Versionen übernommener Code) zu
erfassen.
Sie müssen Grenzklassen danach modellieren, welche Art von von Schnittstelle sie darstellen. Die Kommunikation mit
anderen Systemen und die Kommunikation mit einem menschlichen Akteur (über eine Benutzerschnittstelle) haben
unterschiedliche Zielsetzungen. Für die Kommunikation mit einem menschlichen Akteur ist der wichtigste Aspekt, wie die
Schnittstelle dem Benutzer dargestellt wird. Für die Kommunikation mit einem anderen System ist der wichtigste Aspekt
das Kommunikationsprotokoll.
Ein Grenzobjekt (eine Instanz einer Grenzklasse) kann eine Anwendungsfallinstanz überleben, wenn es beispielsweise
zwischen der Ausführung von zwei Anwendungsfällen in einer Anzeige erscheinen muss. Normalerweise leben Grenzobjekte
nur so lang wie die Anwendungsfallinstanz.
Grenzklassen ermitteln
Eine Grenzklasse bildet die Schnittstelle zwischen System und Außenwelt. Grenzobjekte isolieren das System von
Änderungen in der Umgebung (Änderung in Schnittstellen zu anderen Systemen, Änderungen in Benutzeranforderungen usw.)
und sorgen dafür, dass diese Änderungen keine Auswirkungen auf den Rest des Systems haben.
Ein System kann mehrere Typen von Grenzklassen haben:
-
Benutzerschnittstellenklassen - Klassen für die Kommunikation mit Benutzern des Systems.
-
Systemschnittstellenklassen - Klassen für die Kommunikation mit anderen Systemen.
-
Einheitenschnittstellenklassen - Klassen, die die Schnittstelle zu Einheiten (z. B. Sensoren) bereitstellen,
die externe Ereignisse erkennen.
Benutzerschnittstellenklassen ermitteln
Definieren Sie für jedes Anwendungsfall/Akteur-Paar eine Grenzklasse. Diese Klasse ist für die Koordination der
Interaktion mit dem Akteur zuständig. Sie können weitere Grenzklassen definieren, um untergeordnete Klassen
darzustellen, an die die primäre Grenzklasse einige ihrer Zuständigkeiten delegiert. Dies gilt insbesondere für
fensterbasierte GUI-Anwendungen, bei denen Sie für jedes Fenster oder jedes Formular ein Grenzobjekt modellieren
können. Modellieren Sie nur die wichtigsten Abstraktionen des Systems und nicht jede einzelne Schaltfläche, Liste oder
jedes Fensterobjekt in der GUI. Das Ziel der Analyse ist, ein taugliches Bild von der Zusammensetzung des Systems zu
erstellen und nicht, alles bis ins letzte Detail zu entwerfen. Anders ausgedrückt, identifizieren Sie Grenzklassen nur
für die Phänomene im System und für Dinge, die im Ereignisablauf der Anwendungsfallrealisierung für die Analyse
erwähnt sind.
Erstellen Sie Skizzen oder Speichern Sie Anzeigen für einen Benutzerschnittstellenprototyp in einer Datei, die das Verhalten und
die Darstellung der Grenzklassen veranschaulichen.
Systemschnittstellenklassen ermitteln
Eine Grenzklasse, die mit einem externen System kommuniziert, ist für die Verwaltung des Dialogs mit dem externen
System verantwortlich. Sie ist die Schnittstelle zwischen diesem System und dem zu erstellenden System.
Beispiel
In einem Geldautomaten muss die Auszahlung durch das GA-Netz, einen Akteur (der die Auszahlung mit dem Bankkontensystem
prüft) geprüft werden. Ein Objekt GA-Netzschnittstelle kann für die Kommunikation mit dem GA-Netz verwendet werden.
Die Schnittstelle zu einem vorhandenen System kann bereits klar definiert sein. In diesem Fall müssen die
Zuständigkeiten direkt aus der Schnittstellendefinition abgeleitet werden. Wenn eine formale Schnittstellendefinition
vorhanden ist, kann diese rückentwickelt (Reverse-Engineering) und muss nicht erneut formal definiert werden. Notieren
Sie einfach für das spätere Design, dass die vorhandene Schnittstelle wiederverwendet wird.
Einheitenschnittstellenklassen ermitteln
Das System kann Elemente enthalten, die so agieren, als wären sie extern (ändern ihren Wert spontan ohne Beeinflussung
durch ein anderes Objekt im System), wie z. B. Sensoren. Obwohl dieser Typ externer Einheit mit Akteuren dargestellt
werden kann, könnte dies die Benutzer des Systems verwirren, weil damit Einheiten und menschliche Akteure auf dieselbe
"Stufe" gestellt werden. Sobald der Schwerpunkt nicht mehr auf der Erfassung der Anforderungen liegt, muss jedoch die
Quelle aller externen Ereignisse berücksichtigt und sichergestellt werden, dass das System Mittel und Wege hat, diese
Ereignisse zu erkennen.
Wenn die Einheit als Akteur im Anwendungsfallmodell dargestellt wird, ist die Verwendung einer Grenzklasse zur
Vermittlung der Kommunikation zwischen der Einheit und dem System leicht zu rechtfertigen. Wenn das
Anwendungsfallmodell diese "Einheitenakteure" nicht enthält, ist jetzt der richtige Zeitpunkt, sie hinzuzufügen und
gegebenenfalls die ergänzenden Beschreibungen der Anwendungsfälle zu aktualisieren.
Erstellen Sie für jeden "Einheitenakteur" eine Grenzklasse, um die Zuständigkeiten der Einheit bzw. des Sensors zu
erfassen. Wenn bereits eine klar definierte Schnittstelle für die Einheit existiert, notieren Sie sich diese als
spätere Referenz während des Designs.
Eine Steuerungsklasse ist eine Klasse, mit der Verhalten gesteuert werden kann, dass für eine oder einige
Anwendungsfälle spezifisch ist. Steuerungsobjekte (Instanzen von Steuerungsklassen) steuern häufig andere Objekte, so
dass ihr Verhalten koordinierenden Charakter hat. Steuerungsklassen kapseln anwendungsfallspezifisches Verhalten.
Das Verhalten eines Steuerobjekts steht in engem Verhältnis zur Realisierung eines speziellen Anwendungsfalls. In
vielen Szenarios könnte man sogar sagen, dass die Steuerungsobjekte die Anwendungsfallrealisierungen für die Analyse
"ausführen". Einige Steuerobjekte können jedoch an mehreren Anwendungsfallrealisierungen für die Analyse teilnehmen,
wenn die Anwendungsfallaufgaben in engem Verhältnis zueinander stehen. Außerdem können mehrere Steuerungsobjekte
unterschiedlicher Steuerungsklassen an einem Anwendungsfall teilnehmen. Nicht alle Anwendungsfälle erfordern ein
Steuerungsobjekt. Wenn der Ereignisablauf in einem Anwendungsfall beispielsweise mit einem Entitätsobjekt in Verhältnis
steht, kann ein Grenzobjekt den Anwendungsfall zusammen mit dem Entitätsobjekt realisieren. Sie können damit beginnen,
eine Steuerungsklasse pro Anwendungsfallrealisierung für die Analyse zu ermitteln, und diese anschließend präzisieren,
wenn mehr Anwendungsfallrealisierungen für die Analyse ermittelt und mehr Gemeinsamkeiten aufgedeckt werden.
Steuerungsklassen können zum Verständnis des Systems beitragen, weil sie die Dynamik des Systems darstellen und die
wichtigsten Aufgaben und Steuerungsabläufe steuern.
Wenn das System den Anwendungsfall ausführt, wird ein Steuerungsobjekt erstellt. Steuerungsobjekte "sterben" in der
Regeln, wenn der zugehörige Anwendungsfall ausgeführt wurde.
Beachten Sie bitte, dass eine Steuerungsklasse nicht alles Erforderliche in einem Anwendungsfall regelt.
Vielmehr koordiniert sie die Aufgaben der anderen Objekte, die die Funktionalität implementieren. Die Steuerungsklasse
delegiert Arbeit an die Objekte, denen die Zuständigkeit für die Funktionalität zugeordnet wurde.
Steuerungsklassen ermitteln
Steuerungsklassen koordinieren das Verhalten im System. Das System kann einige Anwendungsfälle ohne Steuerungsobjekte
ausführen (nur mit Entitäts- und Grenzobjekten). Dies gilt insbesondere für Anwendungsfälle, in denen einfach nur
gespeicherte Informationen geändert werden.
Komplexere Anwendungsfälle erfordern im Allgemeinen mindestens eine Steuerungsklasse, um das Verhalten der anderen
Objekte im System zu koordinieren. Beispiele für Steuerungsobjekte sind Programme wie Transaktionsmanager,
Ressourcenkoordinatoren und Fehlerbehandlungsprogramme.
Steuerungsklassen entkoppeln Schnittstellen- und Entitätsobjekte effektiv voneinander und machen das System damit
toleranter gegenüber Änderungen an den Systemschnittstellen. Außerdem entkoppeln sie das anwendungsfallspezifische
Verhalten von den Entitätsobjekten und erhöhen damit ihre Wiederverwendbarkeit in Anwendungsfällen und Systemen.
Steuerungsklassen unterstützen Verhalten, das
-
von der Umgebung unabhängig ist (sich nicht ändert, wenn sich die Umgebung ändert),
-
Steuerungslogik (Reihenfolge von Ereignissen) und Transaktionen in einem Anwendungsfall definiert,
-
sich nur geringfügig ändert, wenn sich die interne Struktur oder das Verhalten der Entitätsklassen ändert,
-
den Inhalt mehrerer Entitätsklassen verwendet oder festlegt und deshalb das Verhalten dieser Entitätsklassen
koordinieren muss,
-
nicht bei jeder Aktivierung dasselbe ist (Ereignisablauf beschreibt mehrere Zustände).
Bestimmen, ob eine Steuerungsklasse erforderlich ist
Der Ereignisablauf eines Anwendungsfalls definiert die Reihenfolge, in der bestimmte Aufgaben ausgeführt werden.
Untersuchen Sie zunächst, ob der Ablauf von bereits vorhandenen Schnittstellen- und Entitätsklassen behandelt werden
kann. Für einen einfachen Ereignisablauf, bei dem Informationen primär eingegeben, abgerufen und angezeigt oder
geändert werden, rechtfertigt sich eine gesonderte Steuerungsklasse normalerweise nicht. Die Grenzklassen sind für die
Koordination des Anwendungsfalls verantwortlich.
Der Ereignisablauf sollte in eine separate Steuerungsklasse gekapselt werden, wenn er komplex ist und sich aus
dynamischem Verhalten zusammensetzt, das sich unabhängig von den Schnittstellen (Grenzklassen) oder
Informationsspeichern (Entitätsklassen) des Systems ändern kann. Durch Kapseln von Ereignisabläufen können
dieselben Steuerungsklassen potenziell für eine Vielzahl von Systemen mit anderen Schnittstellen und anderen
Informationsspeichern (oder zumindest zugrunde liegenden Datenstrukturen) wiederverwendet werden.
Beispiel: Warteschlange mit Aufgaben verwalten
Sie können eine Steuerungsklasse aus dem Anwendungsfall "Aufgabe ausführen" im Lagerverwaltungssystem ermitteln. Diese
Steuerungsklasse bearbeitet eine Warteschlange mit Aufgaben und stellt sicher, dass die Aufgaben in der richtigen
Reihenfolge ausgeführt werden. Sie führt die nächste Aufgabe in der Warteschlange aus, sobald ein geeignetes
Transportmitteln zugeordnet ist. Das System kann somit mehrere Aufgaben gleichzeitig ausführen.
Das durch das zugehörige Steuerungsobjekte definierte Verhalten lässt sich einfacher beschreiben, wenn Sie es in die
beiden Steuerungsklassen "Aufgabenausführender" und "Warteschlangen-Handler" aufteilen. Das Objekt
Warteschlangen-Handler ist nur für die Reihenfolge in der Warteschlange und die Zuordnung des Transportmittels
zuständig. Es wird ein Warteschlangen-Handler für die gesamte Warteschlange benötigt. Sobald das System eine Aufgabe
ausführt, erstellt es ein neues Objekt "Aufgabenausführender", das die Aufgabe ausführt. Somit wird ein Objekt
"Aufgabenausführender" für jede vom System ausgeführte Aufgabe benötigt.
Komplexe Klassen sollten auf der Basis ähnlicher Zuständigkeiten aufgeteilt werden
Der Hauptvorteil dieser Aufteilung besteht darin, dass die Zuständigkeiten für die Warteschlangenverwaltung (etwas, das
in vielen Anwendungsfällen verwendet wird) von den speziellen Aufgaben des Aufgabenmanagements, die für diesen
Anwendungsfall spezifisch sind, getrennt werden. Das macht die Klassen mit zunehmender Reife des Designs verständlicher
und einfacher anzupassen. Außerdem kann die Arbeitslast des Systems gleichmäßig verteilt werden, weil so viele
Aufgabenausführende erstellt werden können, wie für die Verarbeitung der Arbeitslast erforderlich sind.
Hauptereignisablauf und alternative/außergewöhnliche Ereignisabläufe in separaten Steuerungsklassen kapseln
Zur Vereinfachung von Änderungen sollten Sie den Hauptereignisablauf und alternative Ereignisabläufe in
unterschiedlichen Steuerungsklassen kapseln. Wenn die alternativen und außergewöhnlichen Abläufe vollständig unabhängig
sind, trennen Sie diese ebenfalls. Auf diese Weise lässt sich das System auf lange Sicht einfacher erweitern und
verwalten.
Steuerungsklassen aufteilen, wenn zwei Akteure dieselbe Steuerungsklasse verwenden
Steuerungsklassen müssen unter Umständen auch aufgeteilt werden, wenn mehrere Akteure dieselbe Steuerungsklasse
verwenden. Auf diese Weise werden Änderungen in den Anforderungen eines Akteurs vom Rest des Systems isoliert. In den
Fällen, in denen die Kosten der Änderung hoch oder die Auswirkungen massiv sind, sollten Sie alle Steuerungsklassen
ermitteln, die mit mehreren Akteuren in Verbindung stehen, und diese aufteilen. Im Idealfall sollte jede
Steuerungsklasse (über ein Grenzobjekt) mit nur einem oder gar keinem Akteur interagieren.
Beispiel: Anrufverwaltung
Schauen Sie sich den Anwendungsfall Ortsgespräch an. Zunächst lässt sich eine Steuerungsklasse identifizieren,
die den Anruf selbst verwaltet.
Die Steuerungsklasse, die Ortsgespräche im Telefonsystem bearbeitet, kann schnell auf zwei Steuerungsklassen aufgeteilt
werden, Verhalten A und Verhalten B, eine für jeden beteiligten Akteur.
An einem Ortsgespräch sind zwei Akteure beteiligt: Teilnehmer A, der den Anruf tätigt, und Teilnehmer B,
der den Anruf entgegen nimmt. Teilnehmer A hebt den Hörer ab, hört einen Wählton und wählt dann eine Reihe von
Rufziffern, die das System speichert und analysiert. Wenn das System alle Ziffern empfangen hat, sendet er einen
Freiton an Teilnehmer A und ein Rufsignal an Teilnehmer B. Wenn Teilnehmer B antwortet, hören
Freiton und Rufsignal auf, und das Gespräch zwischen den beiden Teilnehmern kann beginnen. Der Anruf ist beendet, wenn
die beiden Teilnehmer auflegen.
Es müssen zwei Verhalten gesteuert werden: Was passiert am Standort von Teilnehmer A und was am Standort von Teilnehmer
B. Aus diesem Grund wird das ursprüngliche Steuerungsobjekt in zwei Steuerungsobjekte aufgeteilt: Verhalten A
und Verhalten B.
Eine Steuerungsklasse muss nicht aufgeteilt werden, wenn
-
Sie relativ sicher sein können, dass sich das Verhalten der Akteure in Bezug auf die Objekte der Steuerungsklasse
nicht oder nur geringfügig ändert,
-
das Verhalten eines Objekts der Steuerungsklasse gegenüber einem Akteur im Vergleich mit dem Verhalten gegenüber
einem anderen Akteur bedeutungslos ist und ein einzelnes Objekt das gesamte Verhalten enthalten kann. Eine
derartige Kombination von Verhalten hat nur geringfügige Auswirkungen auf die Änderbarkeit.
Eine Entitätsklasse ist eine Klasse, mit der Informationen und das zugehörige Verhalten, das gespeichert werden
muss, modelliert werden kann. Entitätsobjekte (Instanzen von Entitätsklassen) werden verwendet, um Informationen zu
Phänomenen, z. B. einem Ereignis, einer Person oder einem Objekt im echten Leben, zu speichern und zu aktualisieren.
Sie sind normalerweise persistent, haben Attribute und Beziehungen, die über einen längeren Zeitraum, manchmal sogar
für den gesamten Lebenszyklus des Systems benötigt werden.
Ein Entitätsobjekt ist normalerweise nicht für ein Anwendungsfallrealisierung für die Analyse spezifisch. Manchmal ist
ein Entitätsobjekt nicht einmal für das System selbst spezifisch. Die Werte seiner Attribute und Beziehungen werden
häufig von einem Akteur vergeben. Ein Entitätsobjekt kann auch für die Ausführung interner Systemaufgaben erforderlich
sein. Entitätsobjekte können ein so komplexes Verhalten wie das anderer Objektstereotypen haben. Anders als andere
Objekte ist dieses Verhalten jedoch eng mit dem Phänomenen verbunden, das vom Entitätsobjekt dargestellt wird.
Entitätsobjekte sind unabhängig von der Umgebung (den Akteuren).
Entitätsobjekte sind die Schlüsselkonzepte des zu entwickelnden Systems. Typische Beispiele für Entitätsklassen in
einem Banksystem sind Konto und Kunde. In einem Netzverwaltungssystem sind Knoten und
Verbindung Beispiele für Entitätsklassen.
Wenn das Phänomen, das Sie modellieren möchten, von keiner anderen Klasse verwendet wird, können Sie es als Attribut
einer Entitätsklasse oder sogar als Beziehung zwischen Entitätsklassen modellieren. Wird das Phänomen von einer anderen
Klasse im Designmodell verwendet, müssen Sie es als Klasse modellieren.
Mit Entitätsklassen lässt sich das System von einem anderen Blickwinkel erfassen, weil sie die logische Datenstruktur
zeigen. Damit ist möglicherweise einfacher zu verstehen, was das System seinen Benutzern bieten soll.
Entitätsklassen ermitteln
Entitätsklassen sind Informationsspeicher im System. Sie werden normalerweise verwendet, um die Schlüsselkonzepte
darzustellen, die das System verwaltet. Entitätsobjekte sind häufig passiv und persistent. Primär sind sie dafür
verantwortlich, Informationen im System zu speichern und zu verwalten.
Eine Quelle der Inspiration für Entitätsklassen sind das Glossar (entwickelt für Anforderungen) und ein
Geschäftsdomänenmodell (entwickelt für die Geschäftsmodellierung).
Folgendes ist zulässig:
-
Kommunikationsbeziehungen zwischen zwei Grenzklassen, die beschreiben, wie ein spezielles Fenster mit anderen
Grenzobjekten in Beziehung steht.
-
Kommunikations- oder Subskriptionsassoziationen von einer Grenzklasse zu einer Entitätsklasse, weil Grenzobjekte
bestimmte Entitätsobjekte zwischen Aktionen im Grenzobjekt verfolgen oder über Zustandsänderungen im Entitätsobjekt
informiert werden müssen.
-
Kommunikationsassoziationen von einer Grenzklasse zu einer Steuerungsklasse, so dass ein Grenzobjekt ein bestimmtes
Verhalten auslösen kann.
Folgendes ist zulässig:
-
Kommunikations- oder Subskriptionsassoziationen zwischen Steuerungsklassen und Entitätsklassen, da
Steuerungsobjekte bestimmte Entitätsobjekte zwischen Aktionen im Steuerungsobjekt verfolgen oder über
Zustandsänderungen im Entitätsobjekt informiert werden müssen.
-
Kommunikationsbeziehungen zwischen Steuerungs- und Grenzklassen, damit die Ergebnisse des aufgerufenen Verhaltens
an die Umgebung kommuniziert werden kann.
-
Kommunikationsassoziationen zwischen Steuerungsklassen, um das Erstellen komplexer Verhaltensmuster zu ermöglichen.
Entitätsklassen dürfen nur die Quelle für Assoziationen (Kommunikations- oder Subskriptionsassoziationen) zu anderen
Entitätsklassen sein. Entitätsklassenobjekte haben in der Regel eine lange Lebensdauer, Steuerungs- und
Grenzklassenobjekte eher eine kurze Lebensdauer. Vom architektonischen Blickpunkt aus ist es vernünftig, die
Transparenz der Umgebung für ein Entitätsobjekt so einzuschränken. Auf diese Weise bleibt das System toleranter in
Bezug auf Änderungen.
Richtung
(Navigierbarkeit)
|
Grenzklassen
|
Entitätsklassen
|
Steuerungsklassen
|
Grenzklassen
|
Kommunikation
|
Kommunikation
Subskription
|
Kommunikation
|
Entitätsklassen
|
|
Kommunikation
Subskription
|
|
Steuerungsklassen
|
Kommunikation
|
Kommunikation
Subskription
|
Kommunikation
|
Gültige Kombinationen von Assoziationsstereotypen
-
Wenn ein neues Verhalten erkannt wird, prüfen Sie, oh es eine vorhandene Klasse mit ähnlichen Zuständigkeiten gibt.
Klassen sollten so oft wie möglich wiederverwendet werden. Nur, wenn sicher ist, dass kein vorhandenes Objekt das
Verhalten erbringen kann, sollten neue Klassen erstellt werden.
-
Wenn Sie Klassen finden, untersuchen Sie sie, um sicherzustellen, dass die Zuständigkeiten übereinstimmen. Wenn
Klassenzuständigkeiten disjunkt sind, teilen Sie das Objekt auf zwei oder mehr Klassen auf. Aktualisieren Sie die
Interaktionsdiagramme entsprechend.
-
Wenn eine Klasse aufgeteilt wird, weil disjunkte Zuständigkeiten gefunden wurden, untersuchen Sie die
Kollaborationen, in denen die Klasse eine Rolle spielt, um festzustellen, ob die Kollaboration aktualisiert werden
muss. Aktualisieren Sie gegebenenfalls die Kollaboration.
-
Eine Klasse mit nur einer Zuständigkeit ist an sich kein Problem, sollte aber die Frage aufwerfen, warum sie
benötigt wird. Sie müssen darauf vorbereitet sein, die Existenz aller Klassen in Frage stellen und rechtfertigen zu
müssen.
|