15.8. Designmuster

Kritiken über die Nutzung von Designmustern in ArgoUML.

Diese beziehen sich auf die Nutzung von Mustern, wie sie durch die sogenannte „Viererbande“ beschrieben wurden. ArgoUML nutzt diese Kategorie auch für Kritiken, die sich auf Verteilungs- und Sequenzdiagramme beziehen. Die aktuelle Version von ArgoUML hat die folgenden Kritiken in dieser Kategorie.

15.8.1. Ziehen Sie Nutzung des Singleton-Musters für eine <class> in Betracht.

Die Klasse hat keine nicht-statischen Attribute noch Assoziationen, die von der Instanz dieser Klasse abgehen. Das bedeutet, dass jede Instanz dieser Klasse identisch mit jeder anderen Instanz sein wird, da es nichts über die Instanz gibt, was sie voneinander unterscheidbar macht.

Unter diesen Umständen sollten sie in Betracht ziehen, dass Sie genau eine Instanz dieser Klsse haben, indem Sie das Singleton-Muster verwenden. Die Nutzung des Singleton-Musters kann Zeit und Speicherplatz einsparen. Innerhalb von ArgoUML kann dies durch Nutzung des Stereotyps «singleton» auf diese Klasse umgesetzt werden.

Wenn es nicht Ihre Absicht ist nur eine Instanz zu haben, sollten Sie Instanzvariablen definieren (z.B. nicht-statische Attribute) und/oder abgehende Assoziationen, welche die Unterschiede zwischen den Instanzen repräsentieren.

Wenn Sie eine Klasse als Singleton spezifiziert haben, müssen Sie die Klasse so definieren, dass sie nur eine Instanz haben kann. Dies wird die Informationsdarstellung Ihres Designs vervollständigen. Um dies zu erreichen, müssen Sie folgendes tun.

  1. Sie müssen ein statisches Attribut definieren (eine Klassenvariable), welche die Instanz aufnimmt. Diese muss aus diesem Grund den Typ Klasse aufweisen.

  2. Sie dürfen nur einen privaten Konstruktor haben, so dass keine neuen Instanzen durch anderen Code erzeugt werden kann. Das Erzeugen der einzigen Instanz kann durch eine passende Hilfsoperation erfolgen, die diesen privaten Konstruktor genau einmals aufruft.

  3. Sie müssen mindestens einen Konstruktor haben, um den Standardkonstruktor zu überschreiben, so dass der Standardkonstruktor nicht dazu verwendet wird mehrere Instanzen zu erzeugen.

Die Definition eines Konstruktors gemäß UML-Standard 1.4 und dessen Erweiterungen, so dass die Definition durch ArgoUML akzeptiert wird, siehe Abschnitt 15.5.3, „ Fügen Sie der Klasse einen Konstruktor hinzu .

15.8.2. Singleton Stereotyp-Verletzung in <Klasse>

Diese Klasse ist mit dem «singleton»-Stereotyp versehen, stimmt aber nicht mit den für Singletons geltenden Randbedingungen überein (ArgoUML akzeptiert auch den Stereotyp «Singleton » beim Definieren eines Singletons). Eine Singletonklasse kann maximal eine Instanz haben. Das bedeutet, dass die Klasse den Designkriterien für ein Singleton entsprechen muss (siehe Abschnitt 15.8.1, „ Ziehen Sie Nutzung des Singleton-Musters für eine <class> in Betracht. ).

Immer, wenn Sie eine Klasse mit einem Stereotypen kennzeichnen, sollte die Klasse allen Bedingungen dieses Stereotyps entsprechen. Die ist ein wichtiger Teil bei der Erstellung eines konsitenten und verständlichen Designs. Die Nutzung des Singletonmusters kann Zeit und Speicherplatz einsparen.

Wenn Sie diese Klasse nicht länger als Singleton benötigen, entfernen Sie den Stereotypen «singleton» indem Sie auf die Klasse klicken und die leere Auswahl im Stereotyp-Kombinationsfeld des Registers Eigenschaften auswählen.

Bei der Anwendung eines Singletonmusters sollten Sie den Anweisungen in Abschnitt 15.8.1, „ Ziehen Sie Nutzung des Singleton-Musters für eine <class> in Betracht. folgen.

15.8.3. Knoten haben normalerweise keine Hülle

Ein Hinweis, dass Knoten nicht innerhalb anderer Modellelemente im Verteilungsdiagramm eingezeichnet werden sollten, da sie ein autonomes physikalisches Objekt repräsentieren.

15.8.4. Knoteninstanzen haben normalerweise keine Hülle

Ein Hinweis, dass Knoteninstanzen nicht innerhalb anderer Modellelemente im Verteilungsdiagramm eingezeichnet werden sollten, da sie ein autonomes physikalisches Objekt repräsentieren.

15.8.5. Komponenten befinden sich normalerweise innerhalb von Knoten

Ein Hinweis, dass Komponenten logische Entitäten innerhalb physikalischer Knoten repräsentieren und innerhalb eines Knoten eingezeichnet werden sollten, wobei Knoten in einem Verteilungsdiagramm dargestellt werden.

15.8.6. Komponenteninstanzen befinden sich normalerweise innerhalb von Knoten

Ein Hinweis, dass Komponenteninstanzen logische Entitäten innerhalb physikalischer Knoten repräsentieren und innerhalb einer Knoteninstanz eingezeichnet werden sollten, wobei Knoteninstanzen in einem Verteilungsdiagramm dargestellt werden.

15.8.7. Klassen befinden sich normalerweise innerhalb von Komponenten

Ein Hinweis, dass Klassen als Modellelemente Komponenten bilden und innerhalb von Komponenten in Verteilungsdiagrammen eingezeichnet werden sollten.

15.8.8. Schnittstellen befinden sich normalerweise innerhalb von Komponenten

Ein Hinweis, dass Schnittstellen als Modellelemente Komponenten bilden und innerhalb von Komponenten in Verteilungsdiagrammen eingezeichnet werden sollten.

15.8.9. Objekte befinden sich normalerweise innerhalb von Komponenten

Ein Hinweis, dass Objekte als Instanzen von Modellelementen Komponenten bilden, die innerhalb von Komponenten oder Komponenteninstanzen in Verteilungsdiagrammen eingezeichnet werden sollten.

15.8.10. Verknüpfungsenden haben nicht die gleiche Ebene

Ein Hinweis, dass eine Verknüpfung (z.B. eine Assoziation), die Objekte in einem Verteilungsdiagramm verbindet, ein Ende in einer Komponente und das andere Ende in einer Komponenteninstanz (da Objekte in beiden auftreten können) hat. Dies macht keinen Sinn.

15.8.11. Klassifizierung einstellen (Verteilungsdiagramm)

Hinweis, dass es in einem Verteilungsdiagramm eine Instanz (Objekt) ohne eine verknüpfte Klassifizierung gibt (Klasse, Datentyp).

15.8.12. Return-Aktionen werden vermisst

Hinweis, dass ein Sequenzdiagramm eine Sende- oder Aufrufaktion ohne entsprechende Return-Aktion enthält.

15.8.13. Vermisse Aufruf(Sende)-Aktion

Hinweis, dass ein Sequenzdiagramm eine Return-Aktion enthält, aber keine vorhergehende Aufruf- oder Sende-Aktion.

15.8.14. Kein Auslöseimpuls bei diesen Verknüpfungen

Hinweis, dass ein Sequenzdiagramm eine Objekte verbindende Verknüpfung ohne verknüpften Auslöseimpuls aufweist (ohne den die Verknüpfung bedeutungslos ist).

[Warnung]Warnung

Das Auslösen dieser Kritik weist auf schwerwiegendes Probleme hin, da ArgoUML keine Mechanismen für das Erzeugen einer Verknüpfung ohne einen Auslöseimpuls enthält. Es weist wahrscheinlich darauf hin, dass das Diagramm durch Laden eines defekten Projektes mit einer XMI-Datei erzeugt wurde, welche eine Verknüpfung ohne Auslöseimpuls beschreibt. Diese wurde möglicherweise durch ein anderes Werkzeug erzeugt.

15.8.15. Klassifizierung einstellen (Sequenzdiagramm)

Hinweis, dass es in einem Sequenzdiagramm ein Objekt ohne eine damit verknüpfte Klassifizierung (Klasse, Datentyp) gibt.

15.8.16. Falsche Position dieses Auslöseimpulses

Hinweis, dass in einem Sequenzdiagramm die Initiierung eines Sende/Aufruf-Return-Nachrichtaustausches nicht richtig von links nach rechts initiiert wurde.