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. L??se Assoziations-Namenskonflikt auf

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. 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.8. 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.9. 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.10. 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.11. 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.12. ??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.13. W??hlen Sie einen legalen 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.14. ??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.15. 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.16. 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.17. 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.18. Paketname ??berarbeiten

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