Richtlinie: Analyseklasse
Es gibt drei stereotype Analyseklassen: Grenzklassen, Steuerungsklassen und Entitätsklassen. Diese Richtlinie beschreibt Bedeutung und Verwendung dieser Klassen.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Stereotype Analyseklassen

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.

Grenzklasse Symbol für Grenzklasse

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.

Steuerungsklasse Symbol für Steuerungsklasse

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.

"Allzu komplexe" Klassen sollten in Klassen mit einheitlichen und zusammengehörigen Zuständigkeiten aufgeteilt werden

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.

Unterschiedliche Akteure, die an einem Anwendungsfall beteiligt sind, erfordern in der Regel separate Steuerungsklassen

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.

Entitätsklasse Symbol für Entitätsklasse

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

Einschränkungen bei der Verwendung von Assoziationsstereotypen

Einschränkungen für Grenzklassen

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.

Einschränkungen für Steuerungsklassen

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.

Einschränkungen für Entitätsklassen

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.

Zusammenfassung der Einschränkungen

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

Konsistenz durchsetzen

  • 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.