Prüfliste: Designklasse
Mit dieser Prüfliste können Sie sicherstellen, dass eine Designklasse korrekt modelliert wurde.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung


Prüflisteneinträge
Allgemein
  • Der Name der Klasse spiegelt eindeutig die Rolle der Klasse wider.
  • Die Beschreibung der Klasse vermittelt eindeutig den Zweck der Klasse.
  • Die Klasse stellt ist eine einzelne, klar strukturierte Abstraktion.
  • Die Attribute und Operationen der Klasse sind alle erforderlich, um die Zuständigkeiten der Klasse zu erfüllen.
  • Jedes Klasse stellt eine kleine, konsistente und eindeutige Gruppe von Zuständigkeiten dar.
  • Die Zuständigkeiten der Klasse sind klar definiert, klar formuliert und klar mit dem Zweck der Klasse verbunden.
  • Jede Klasse ist relativ in sich geschlossen und lose mit anderen Klassen verbunden.
  • Die Zuständigkeiten der Klasse haben eine konsistente Abstraktionsebene (d. h. Zuständigkeiten auf hoher Ebene (Anwendungsebene) und Zuständigkeiten auf niedriger Ebene (Implementierungsebene) werden nicht vermischt).
  • Klassen in derselben Vererbungshierarchie besitzen eindeutige Klassenattribute, -operationen und -beziehungen (d. h. sie übernehmen alle allgemeinen Attribute, Operationen und Beziehungen).
  • Der vollständige Lebenszyklus einer Instanz der Klasse wurde berücksichtigt. Jedes Objekt wurde von einer oder mehreren Anwendungsfallrealisierungen erstellt, verwendet und entfernt.
  • Die Klasse erfüllt die Verhaltensanforderungen, die von den Anwendungsfallrealisierungen aufgestellt wurden.
  • Alle Anforderungen an die Klasse, die in der Anforderungsspezifikation definiert sind, wurden berücksichtigt.
  • Die Erwartungen an die Klasse (die in der Klassenbeschreibung und von den Objekten in Ablaufdiagrammen formuliert werden) sind mit der Zustandsmaschine der Klasse konsistent.
  • Alle Zuständigkeiten der Klasse stehen miteinander in Beziehung, so dass es nicht möglich ist, dass die Klasse im System existiert, wenn einige ihrer Zuständigkeiten verwendet werden, andere hingegen nicht.
  • Es gibt nicht zwei Klassen, die im Wesentlichen denselben Zweck haben.
Generalisierung/Spezialisierung
  • Die Generalisierungshierarchie ist ausgeglichen, d. h. es sind keine Klassen vorhanden, für die die Hierarchie gewöhnlich flach oder tief ist.
  • Offensichtliche Gemeinsamkeiten sind in der Vererbungshierarchie wiedergegeben.
  • Es sind keine Superklassen vorhanden, die aus den Attributen der Unterklassen zusammengesetzt zu sein scheinen.
  • Es sind keine temporären abstrakten Klassen in der Vererbungshierarchie mit orthogonalen Eigenschaften vorhanden, die duplizierte Unterklassen auf beiden Seiten einer Vererbungsstruktur enthalten.
  • Vererbung wird verwendet, um allgemeine Designabstraktionen zu erfassen, nicht in erster Linie für die Implementierung, sondern um Teile der Code- und Klassenstruktur wiederzuverwenden.
Namenskonventionen
  • Klassennamen geben Aufschluss über den Zweck der Klasse.
  • Klassennamen folgen den Namenskonventionen, die in den Richtlinien für das Projektdesign spezifiziert sind.
Operationen
  • Die Name der einzelnen Operationen sind beschreibend und verständlich.
  • Die Zustandsmaschine und die Operationen sind konsistent.
  • Die Zustandsmaschine und die Operationen beschreiben das Verhalten der Klasse vollständig.
  • Die Parameter der einzelnen Operationen sind in Bezug auf Anzahl, Name und Typ korrekt.
  • Definierte Implementierungsspezifikationen für die einzelnen Operationen sind korrekt.
  • Operationssignaturen entsprechen den Standards der Zielprogrammiersprache.
  • Jede Operation wird in mindestens einer Anwendungsfallrealisierung verwendet.
Attribute
  • Alle Beziehungen der Klasse sind erforderlich, um eine Operation der Klasse zu unterstützen.
  • Jedes Attribut stellt einen konzeptionellen Aspekt dar.
  • Die Namen der Attribute sind beschreibend und vermitteln die im Attribut gespeicherten Informationen korrekt.
Beziehungen
  • Die Rollennamen der Aggregationen und Assoziationen beschreiben die Beziehung zwischen den zuordnenden und zugeordneten Klassen.
  • Die Multiplizitäten der Beziehungen sind korrekt.
Zustandsmaschinen
  • Die Zustandsmaschine ist so einfach wie möglich, drückt aber trotzdem das erforderliche Verhalten aus.
  • Die Zustandsmaschine enthält keine überflüssigen Zustände oder Übergänge.
  • Die Zustandsmaschine hat einen klaren Kontext.
  • Alle Referenzobjekte sind für das übergeordnete Objekt sichtbar.
  • Die Zustandsmaschine ist effizient und erbringt ihr Verhalten mit eine optimalen Ausgewogenheit in Bezug auf Zeit und Ressourcen, die durch die Aktionen, die die Zustandsmaschine verteilt, definiert werden.
  • Die Zustandsmaschine ist verständlich.
    • Die Zustands- und Übergangsnamen sind im Kontext der Systemdomäne verständlich.
    • Die Zustandsnamen geben Aufschluss darüber, worauf gewartet wird oder was geschehen wird, und nicht, was geschehen ist.
    • Die Zustands- und Übergangsnamen sind innerhalb der Zustandsmaschine eindeutig (obwohl dies keine strikte Anforderung ist, hilft es beim Debugging).
    • Logische Gruppierungen von Zuständen sind in zusammengesetzten Zuständen enthalten.
    • Zusammengesetzte Zustände wurden effektiv eingesetzt, um die Komplexität zu verringern.
    • Übergangsbezeichnungen spiegeln die eigentliche Ursache für den Übergang wider.
    • Es sind keine Codefragmente für Zustandsübergänge mit mehr als 25 Zeilen Detailcode vorhanden. Stattdessen wurden Funktionen verwendet, um die Komplexität des Übergangscodes zu verringern.
    • Die Verschachtelung von Zustandsmaschinen wurde untersucht, um sicherzustellen, dass die Verschachtelungstiefe das Verständnis nicht erschwert. Eine oder zwei Ebenen von Unterzuständen reichen in der Regel für die meisten komplexen Verhalten aus.
  • Es wurden aktive Klassen anstelle von parallelen Unterzuständen verwendet. Aktive Klassen sind in nahezu allen Fällen die bessere Alternative und leichter verständlich als parallele Unterzustände.
  • In Echtzeitsystemen wurden Kapseln für die Darstellung logischer Steuerungs-Threads verwendet.
  • Fehler- und Wartungszustände wurden berücksichtigt.
  • Es wurden Unterzustände anstelle erweiterter Zustandsvariablen verwendet. Es gibt keine Anzeigen für Übergangswächterbedingungen, die mehrere Variablen prüfen, um den Zielzustand für den Übergang festzustellen.
  • Die Zustandsmaschine hat keine Ähnlichkeit mit einem Ablaufdiagramm.
  • Die Zustandsmaschine scheint nicht übermäßig zersetzt zu sein und aus verschachtelten Zustandsmaschinen mit jeweils einzelnen Unterzuständen zu bestehen. In Fällen, in denen der verschachtelte Unterzustand ein Platzhalte für künftige Designarbeiten oder Subclassing ist, kann dies vorübergehende akzeptabel sein, sofern diese Entscheidung bewusst getroffen wurde.