Diskussion:Klassendiagramm

Warum besteht hier eine Weiterleitung von Assoziationsklasse zu Klassendiagramm? Das ist definitiv nicht das Gleiche!

Innere Klassen

Ich seh nirgends Innere Klassen (inner class(es)) (Beziehung? -> UML?). --Alien4 05:28, 17. Nov. 2006 (CET)

siehe Verschachtelte Klassen --Gubaer 14:54, 23. Dez. 2006 (CET)

Generische Datentypen

gibt es eine konvention wie generische datentypen dargestellt werden. bsp:

-namen : List<String>

-- Qopep 17:06, 10. Jun. 2007 (CEST)

Naja, List<String> ist ja nicht mehr generisch, sondern schon eine konkrete Ausprägung. :-) Ansonsten schau im Artikel, wo etwas über Schablonenklassen steht. Hilft dir das? --RokerHRO 19:01, 2. Jul. 2007 (CEST)

statische Variablen

Wie stellt man in UML statische Variablen dar, also Attribute, die pro Klasse existieren, nicht pro Instanz? --RokerHRO 18:58, 2. Jul. 2007 (CEST)

Ich glaube statische Attribute oder Methoden werden einfach unterstrichen. 217.234.248.220 17:58, 22. Dez. 2007 (CET)

das ist korrekt, vgl http://www.omg.org/spec/UML/2.5/Beta1/PDF (Seite 108) --Micdi2 (Diskussion) 13:04, 4. Jun. 2013 (CEST)

Konstruktoren?

Während Eigenschaften in der regel privat sind (oberer Kasten) und mit einem Minus gekennzeichnet werden, sind die meisten Methoden öffentlich (public) und werden mit einem Plus markiert. Frage: Gilt dies auch für den Konstruktor (z.B. in Java)? In den meisten Klassendiagrammen wird er weggelassen (zumindest, wenn es sich um den Standardkonstruktor ohne Argumente handelt) - ich habe aber auch Varianten gesehen, in denen der Constructor weder mit + noch -, sondern mit einem C gekennzeichnet war. Ist das UML-konformer Standard?

Rahmen

Fehlt im Beispieldiagramm unten nicht der Rahmen? Bei Anwendungsfalldiagrammen wird explizit erwähnt, dass alle Diagramme jetzt so einen Rahmen haben. --Admiral kay 09:02, 15. Mai 2008 (CEST)

Diskriminatoren fehlen

Mir ist gerade aufgefallen, dass die Diskriminatoren noch fehlen. --Admiral kay 16:39, 31. Mai 2008 (CEST)

Aggregation und Komposition vertauscht

Ich vermute es müsste heißen: Eine Komposition ist ein Spezialfall der Aggregation, siehe auch Komposition_(UML).

Komposition 0..1

Die Notwendigkeit einer existierenden Klasse schließt 0 definitiv aus. Dort darf nur 1 stehen (oder es muss wegelassen werden). Ebenfalls hat mein Vorredner Recht. Aber das liegt im Auge des Betrachters.

Generalisierung - Vererbung und Kardinalität

Hallo zusammen! „HAS A“-Beziehung und „IS A“-Beziehung fehlt hier. Normalerweise redet man bei einer Vererbung von einer „IS A“-Beziehung, da die spezielle Klasse auch immer die Elternklasse ist. Bei einer „HAS A“-Beziehung enthält (hat) eine Klasse eine andere. Der nächste Punkt ist, dass zwar die Kardinalität (Häufigkeit) angewandt wird, es wird aber nicht darauf eingegangen. 1..*, m..n, etc... Zwar gibt es einen Artikel zu Kardinalität, aber im Zusammenhang mit dem ERM. Das müsste eigendlich in dem Buch von Galileo Computing enthalten sein. -- Bkmzde 15:15, 1. Jun. 2009 (CEST)

Die Erwähnung von "HAS A" und "IS A" fehlt zwar, die Bedeutung ist aber vorhanden: Ein Vererbungs-Pfeil (bzw. die gestrichelte "implementiert Interface"-Variante) ist der "IS A"-Fall, die Komposition/Aggregation ist der "HAS A"-Fall. Auf die Kardinalität sowie Beziehungsfälle (1:n , m:n) gehen Klassendiagramme nicht ein, da sie im Gegensatz zu ERM kein Problem darstellen. Ich stimme aber zu, dass die Kardinalitäten im Artikel gerne noch etwas ausführlicher be-Beispiel-t werden dürften ;-)

--arilou 09:37, 28. Feb. 2011 (CET)

Beispiele Klassendiagramm

Guten Tag,

könnte ich die Klasse "Adresse" eigentlich auch direkt mit der Vaterklasse "Kunde" assoziieren? Also anstatt die Klasse "Adresse" mit den Subklassen "Privatkunde" und "Geschäftskunde" nur mit der Vaterklasse "Kunde" assoziieren. (nicht signierter Beitrag von 80.150.118.190 (Diskussion | Beiträge) 08:20, 30. Apr. 2010 (CEST))

Klar. Dann geht allerdings der Unterschied "postAnschrift"/"domizilAnschrift" verloren. Ist im Beispiel allerdings unerhelblich.--arilou 09:39, 28. Feb. 2011 (CET)

Zusätzlich müsste sich die Kardinalität ändern. Während eine Adresse entweder zu keinem Privatkunden oder zu keinem Geschäftskunden gehören kann (0..*) ist dies bei der Zuordnung zu Kunde anders: Eine Adresse muss zu irgendeinem Kunden gehören (1..*) sonst wäre sie ein Artefakt (es sei denn es gibt noch mehr 'player' aber dann wäre das Diagramm ohne jede Erläuterung unvollständig, was keinen Sinn macht). Man könnte auch mal erläutern, wieso dieselbe Adresse zu vielen Kunden gehören kann. Privatpersonen können im selben Haushalt wohnen (etwa eine WG oder Familie), verschiedene Firmen können sich die Räume eines Stockwerks teilen (das kommt häufiger vor). (nicht signierter Beitrag von 92.228.109.254 (Diskussion) 20:54, 14. Apr. 2018 (CEST))

Da müsste sich nichts an der Kardinalität ändern. Das Diagram sagt an keiner Stelle aus, dass "eine Adresse entweder zu keinem Privatkunden oder zu keinem Geschäftskunden gehören kann", sondern es sagt aus, dass eine Adresse zu keinem als auch zu vielen Privatkunden oder/und Geschäftskunden gehören kann; Das würde sich bei einer direkten Beziehung zur Vaterklasse nicht ändern. Und dass eine Adresse zu vielen Kunden oder/und Firmen gehören kann sollte eigentlich klar sein. Dazu muss nicht mal eine WG oder Teilung von Räumen im selben Stockwerk vorliegen. Ohne Angabe von Raum und Stockwerk, teilen sich mehrere Mietparteien in einem Mehrfamilienhaus oder Bürogebäude immer die selbe Adresse. Die Unterscheidung findet am Namen statt; und der ist Teil der spezialisierten Klassen "Privatkunde" und "Geschäftskunde". --MA-Maddin (Diskussion) 11:02, 17. Okt. 2024 (CEST)

Ich glaube das Student -> Vorlesung Beispiel ist falsch. Es handelt sich dabei um eine Assoziation aber um keine Aggregation. Den ein Student kann gleichzeitig an mehreren Vorlesungen teilnehmen. Entsprechend gehört er nicht immer nur genau zu 0 oder 1 Vorlesung. Im Artikel https://de.wikipedia.org/wiki/Aggregation_(Informatik) wird ein besseres Beispiel für eine Aggregation genannt: die ehe zwischen zwei Personen. Um wirklich eindeutig zu sein könnte man die Ehe sogar noch "MonogameEhe" nennen. (nicht signierter Beitrag von 185.124.195.42 (Diskussion) 13:59, 27. Feb. 2018 (CET))

Das Beispiel ist wirklich etwas ungünstig, vor allem in den Text-Formulierungen: Eine Vorlesung 'besteht' eben einfach nicht aus Studenten (es sei denn man meint das konkrete Ereignis am Tg X in Raum Y; dann kann ein Student aber nur genau eine, oder keine, Vorlesung besuchen). Eine Vorlesung besteht aus einem Kursprogramm und evtl. noch dem Dozenten und wird von einer variierenden Anzahl Studenten besucht ('HAS A' = hat Studenten). Das ist immer noch eine Aggregation; das Beispiel ist aber einfach zu schwammig. Besser wäre es, z.B. eine Schulklasse oder Fußballmannschaft zu nehmen. (nicht signierter Beitrag von 92.228.109.254 (Diskussion) 20:44, 14. Apr. 2018 (CEST))

orderd nur in einigen Sprachen implementierbar?

1.1. ordered -> funktioniert nicht in allen Sprachen

Womöglich liege ich falsch, aber warum sollte ein Sprache die Ausgabe nicht vorher sortieren können? (nicht signierter Beitrag von 141.30.208.64 (Diskussion) 10:07, 24. Mai 2012 (CEST))

Seh' ich auch so. Mir ist noch keine Sprache untergekommen, in der man nicht die Rückgabe zumindest selbst-programmiert sortieren könnte. Vielleicht bei irgendwelchen wirren Sprachen, die keine Arrays sondern nur Hashtables kennen o.ä. --arilou (Diskussion) 12:25, 24. Mai 2012 (CEST)

Abschnitt durch Bilder und Beispiele verständlicher machen

Liebes Wikipedia-Team, der Abschnitt Klassendiagramm#Klassen ist prima geschrieben, allerdings gibt es da beim Einarbeiten paar Hindernisse, so steht zwar da die genaue Notation, wie man Eigenschaften aufschreiben soll, aber es findet sich kein direktes Beispiel in Bezug auf diese Notation. Weiter unten in anderen Abschnitten sind zwar dann viele verschiedene Beispiele, aber diese besitzen nicht alle Angaben, die man in diesem Abschnitt aber von der Notation her vorgibt. Daher würde ich diejenigen bitten, die sich in diesem Gebiet auskennen, Beispiele in diesem Abschnitt hinzuzufügen. Denn das würde diesen Artikel stark verbessern. 92.212.5.157 23:02, 29. Jan. 2018 (CET)

Abschnitt Komposition und Aggregation

Der Abschnitt Komposition und Aggregation bedarf meiner Meinung nach dringend einer Überarbeitung.

Der Paragraph zur Aggregation steht im direkten Konflikt zur nebenstehenden Grafik, denn im Text heißt es "Im Fall der Aggregation ist es eine nicht ausgefüllte Raute mit einer Kardinalität von 0..1 ", während im Bild eine Aggregation mit einer Multiplizität von 0..* gezeigt wird.

Weiterhin ist die Unterscheidung zwischen Aggregation und Komposition im Bezug auf die Multiplizität inkorrekt.

Während die Aggregation in Wahrheit, wie auch im Bild beschrieben, eine Multiplizität von 0..* aufweisen darf, kann ein Teil der Komposition immer bloß maximal einem Ganzen angehören, jedoch auch alleine stehen.

Es sollte sich dringend an der Seite zur Assoziation sowie an der offiziellen Spezifikation orientiert werden.