enum in Klassendiagramm?

[Guest]

Hallo,

wie gibt man in Klassendiagrammen enums an

Habe eine Klasse state, die nur enums speichert, also init, run, canceled und noch ein paar andere, weiß aber nicht so recht als was ich die angebe. Verwende visual paradigm und da gibt es nur attribute und methoden für eine klasse , aber sind das denn richtig attribut oder muss man dann noch was ankreuzen oder ändern?

Den Stereotyp enum habe ich ausgewähl nur wie ich die einzelnen Statis angebe weiß ich nicht.

 

[Jaffa]

die selbse frage habe ich mir auch gestellt und noch keine eindeutige antwort bekommen. eine variante habe ich hier gefunden:

http://www.sparxsystems.com/EAUserGuide/index.html?stereotypedlg.htm

 

[byte]

Dito. Habs dann in meiner Diplomarbeit auch mit Stereotypen gelöst.

 

[SnooP]

Was auch am Sinnvollsten ist... man muss ja Enums auch nicht künstlich aufwerten

 

[byte]

Wenn Du komplexe Enums hast, die in einer eigenen Datei liegen, ist das ja ok so. Aber was ist, wenn Du einfach nur eine simple kleine Enum in einer Klasse hast, die ne handvoll Konstanten definiert? Dann müsstest Du diese Enum umständlich im Klassendiagramm als Inner Class mit entsprechendem Stereotyp deklarieren. Das bläht das Klassendiagramm imo nur umständlich auf. Da wärs schon schöner, wenns ne Möglichkeit gäbe, Konstanten typsicher direkt in der Klasse definieren zu können.

 

[SnooP]

joah sischer... aber wird die Struktur einer Anwendung durch das Vorhandensein eines enums definiert? Wäre es nicht hinreichend, wenn man nen Attribut vom Typ Enum in einer Klasse definiert und feddich is?
Falls man normale Java-Konstanten hat, schreibt man die ja meist auch nich hin, zumal die eh alle static sind und damit nix für das Klassendesign zu beschicken haben...

also nicht zuu kompliziert machen... - bin ja auch der Meinung, dass Klassendiagramme nicht immer wirklich viel aussagen können ... also sollte man sich bei den Dingern auf das Wesentliche beschränken - und wenn das Wesentliche einer Anwendung oder eines Klassendesigns das Vorhandenseins oder die Struktur von Enums ist, puh - dann weiß ich auch nich ... und wenn man wirklich mal sowas braucht -> Enum-Klasse malen...

 

[byte]

Wie würdest Du das Klassendiagramm zu dieser Klassse entwerfen?

public class Foo {
  enum Bar {
    ABC, DEF, GHJ
  }

  private Bar bar;

  public void doSomething (Bar bar) {
    // ...
  }
}

Die enum einfach wegzulassen, würde sicherlich nicht zum Verständnis beitragen. Sie als Inner Class mit <<enum>> zu stereotypen, verkompliziert hingegen das Ganze das Modell.
Da fehlt einfach ein Sprachkonstrukt für typsichere Konstanten.

 

[SnooP]

das isses ja was ich meine... ich denke schon, dass es weggelassen werden könnte, ein:

Foo
------------------------------
-bar : Bar <<Enum>>
+doSomething(Bar) : void


würde mir völlig reichen... - denn ein Klassendiagramm soll die statische Struktur von Klassen, sprich vor allem deren Zusammenhänge zueinander darstellen.
Das Vorhanden oder Nichtvorhandensein von Enums hat auf die Aussagekraft des CDs keine Auswirkung... im Gegenteil, wenn man jetzt anfangen würde da irgendwie Klassen als Enums reinzufrckeln würde genau das entstehen was du gesagt hast - Übersichtlichkeit wäre weg... für mich ist die Absicht eines Enums prinzipiell Verhaltens-bestimmend... in einem Statechart oder meinetwegen auch in einem Objektdiagramm kann man also auf diese Konstanten zugreifen... - aber in einem Klassendiagramm bringt das doch überhaupt gar nix

 

[byte]

Ist das denn UML-Syntax, auf diese Weise Felder mit Stereotypen zu kennzeichnen? War mir nicht bekannt, dass man das so machen kann.

 

[SnooP]

Ich hab's zumindest so schon gesehn... - kein Plan ob das so in der Spec steht... aber da man an Klassen das genauso dranschreiben kann, sollte man das auch an den Typ innerhalb einer Klasse dranschreiben können... ich glaube Stereotypen kann man einfach überall dranklatschen

 

[byte]

Ansich isses ja auch wurscht. Entweder man hat ein Tool, dass es automatisch macht oder man schreibts hin, wie man lustig is. Hauptsache der Kollege checkts nachher.

 

[SnooP]

ebend