15.4. Benennung

Dies sind Kritiken, die sich auf die Benennung von Modellelementen beziehen. Die aktuelle Version von ArgoUML hat 18 Kritiken in dieser Kategorie.

15.4.1. Assoziations-Namenskonflikt auflösen

Hinweis, dass zwei Assoziationen im gleichen Namensraum den gleichen Namen haben. Dies ist in UML nicht erlaubt.

15.4.2. Überarbeite die Attributnamen, um einen Konflikt zu vermeiden

Hinweis, dass zwei Attribute einer Klasse den gleichen Namen haben. Dies ist in UML nicht erlaubt.

[Anmerkung]Anmerkung

Das Problem kann durch vererben eines Attributes über eine Vererbungsbeziehung verursacht werden.

15.4.3. Ändere Namen oder Signaturen in einem Modellelement

Zwei Operationen in einem <Modellelement> haben die gleiche Signatur. Das heißt, die Namen sind gleich und die Liste der Parameter hat den gleichen Typ.

Wo es Signaturkonflikte gibt, kann kein korrekter Code in den hauptsächlich verwendeten OO-Sprachen generiert werden. Es führt auch zu einer sehr unklaren Semantik des Designs.

Beim Vergleichen von Signaturen betrachtet die Kritik:

  1. den Namen;

  2. die Liste der Ein-, Aus- und Ein-Ausgabeparamtertypen in ihrer Reihenfolge;

Nur wenn diese sowohl in Typ und Reihenfolge übereinstimmen, wird die Signatur als gleich betrachtet.

Dies folgt der Linie von Java/C++, welche die Rückgabeparameter bei der Signatur ignorieren. Dies kann bei einigen funktionalen OO-Sprachen unvorteilhaft sein.

[Anmerkung]Anmerkung

Einige Puristen würden argumentieren, dass der Vergleich zwischen Ein-, Aus- und Ein-Ausgabeparametern differenzieren sollte. Jedoch kann keine praktische Programmiersprache so etwas tun, wenn sie einen überladenen Methodenaufruf auflöst. Aus diese Grund behandelt diese Kritik sie alle pauschal.

15.4.4. Doppelte End- (Rollen-) Namen in einer Assoziation

Die angegebene Assoziation hat zwei (oder mehrere) Enden (Rollen) mit dem gleichen Namen. Eine der wohlgeformten Regeln für Assoziationen in UML 1.4 ist, dass alle Enden (Rollen)-Namen eindeutig sein müssen.

Dies stellt sicher, dass es keine mehrdeutige Referenz auf die Enden einer Assoziation geben kann.

Um dies zu beheben, markieren Sie die Assoziation manuell und ändern die Namen von einer oder mehreren der betroffenen Enden (Rollen) mit Hilfe des Taste 2-Popup-Menüs oder der Eigenschaftstabelle.

15.4.5. Rollenname steht im Konflikt mit einem Element

Ein Hinweis, dass ein gutes Design Rollenname für Assoziationen verhindert, die mit Attributen oder Operationen der Quellklasse kollidieren. Rollen können im Code als Attribute oder Operationen realisiert werden, die dann Codegenerierungsprobleme auslösen.

15.4.6. Einen Namen auswählen (Klassen und Schnittstellen)

Der betrachteten Klasse oder Schnittstelle wurde kein Name gegeben (sie wird im Modell als Unbenannt erscheinen). Hinweis, dass gutes Design fordert, dass alle Schnittstellen und Klassen benannt werden.

15.4.7. Namenskonflikt in einem Namensraum

Der betrachtete Namensraum (z.B. Paket) enthält eine Klasse oder eine Schnittstelle mit dem gleichen Namen wie eine andere (im gleichen Namensraum). Dies ist schlechtes Design und verhindert das generieren gültigen Codes.

15.4.8. Wählen Sie einen eindeutigen Namen für ein Modellelement aus (Klassen und Schnittstellen)

Hinweis, dass die angegebene Klasse oder Schnittstelle den gleichen Namen wie eine andere (im Namensraum) aufweist. Dies ist schlechtes Design und wird eine gültige Codegenerierung verhindern.

15.4.9. Wählen Sie einen Namen aus (Attribute)

Das betrachtete Attribut hat keinen Namen erhalten (es wird im Modell als (Unbenanntes Attribute) erscheinen). Hinweis, dass gutes Design fordert, dass alle Attribute benannt werden.

15.4.10. Wählen Sie einen Namen aus (Operationen)

Die betrachtete Operation hat keinen Namen erhalten (sie wird im Modell als (Unbenannte Operation) erscheinen). Hinweis, dass gutes Design fordert, dass alle Operationen benannt werden.

15.4.11. Wählen Sie einen Namen aus (Zustände)

Das betrachtete Zustand hat keinen Namen erhalten (es wird im Modell als (Unbenannter Zustand) erscheinen). Hinweis, dass gutes Design fordert, dass alle Zustände benannt werden.

15.4.12. Wählen Sie einen eindeutigen Namen für ein (zustandsbehaftetes) Modellelement aus.

Hinweis, dass der angegebene Zustand den gleichen Namen wie ein anderer aufweist (im aktuellen Zustandsdiagramm). Dies ist schlechtes Design und wird die gültige Codegenerierung verhindern.

15.4.13. Ändern Sie den Namen, um eine Konfusion zu verhindern

Zwei Namen im gleichen Namensraum haben sehr ähnliche Namen (sie unterscheiden sich nur durch ein Zeichen voneinander). Hinweis, dass dies potentiell zu einer Konfusion führt.

[Achtung]Achtung

Diese Kritik kann manchmal störend sein, da es manchmal nützlich und gutes Design ist, eine Serie von Modellelemente var1, var2 usw. zu haben.

Es ist wichtig sich daran zu erinnern, dass Kritiken Anleitungen anbieten, die nicht immer korrekt sein müssen. ArgoUML läßt es zu, dass Sie die entsprechenden Zu-Bearbeiten-Elemente über den Zu-Bearbeiten-Bereich verlassen (siehe Kapitel 14, Der Bereich Zu-Bearbeiten ).

15.4.14. Wählen Sie einen gültigen Namen aus

Alle Modellelementnamen in ArgoUML dürfen nur aus Buchstaben, Ziffern und Unterstrichen bestehen. Diese Kritik weist Sie darauf hin, dass eine Entität nicht dieser Anforderung entspricht.

15.4.15. Ändern Sie den Namen des Modellelementes in ein nicht-reserviertes Wort

Hinweis, dass der Name dieses Modellelementes dem Namen eines in UML resevierten Wortes entspricht (or within one character of one). Dies ist nicht erlaubt.

15.4.16. Wählen Sie einen besseren Namen für die Operation aus

Hinweis, dass der Name einer Operation nicht der Namenskonvention entspricht, dass Namen von Operationen mit einem Kleinbuchstaben beginnen.

[Achtung]Achtung

Der Java und C++-Konvention folgend, geben die meisten Designer Ihren Konstruktoren den gleichen Namen wie der Klasse, die mit einem Grossbuchstaben gebinnt. In ArgoUML wird dies diese Kritik auslösen, es sei denn, der Konstruktor erhält den Stereotyp «create».

Es ist wichtig sich daran zu erinnern, dass Kritiken Anleitungen anbieten, die nicht immer korrekt sein müssen. ArgoUML läßt es zu, dass Sie die entsprechenden Zu-Bearbeiten-Elemente über den Zu-Bearbeiten-Bereich verlassen (siehe Kapitel 14, Der Bereich Zu-Bearbeiten ).

15.4.17. Wählen Sie einen besseren Attributnamen aus

Hinweis, dass ein Attribut nicht der Namenskonvention entspricht, dass Namen von Attributen mit einem Kleinbuchstaben beginnen.

15.4.18. Klassenname groß schreiben

Hinweis, dass eine Klasse nicht der Namenskonvention entspricht, dass Klassen mit einem Großbuchstaben beginnen.

[Anmerkung]Anmerkung

Obwohl sie diese Kritik nicht auslöst, sollte die gleiche Konvention auf Schnittstellen angewendet werden.

15.4.19. Paketname überarbeiten

Hinweis, dass ein Paket nicht der Namenskonvention entspricht, dass Kleinbuchstaben mit Punkten verwendet werden, um Subpakete zu kennzeichnen.