UIML Class Diagram Property Attribute

[MB]

moin,

wie sind die folgenden Attribute des Property aus dem weltweit anerkannten UML 2 Class Diagram zu verstehen? Aufjedenfall stehen da bei mit seeehr viele Fragezeichen. Wie ist subsets gemeint???

so unspezifiziert?

herbstmonat = {subsets Monat}

…oder vielleicht eine Elternklasse Herbstmonat unspezifiziert?

irgendwas:Herbstmonat = {subsets Monat}

…oder zumindest die anzahl spezifiziert?

irgendwas:Herbstmonat[3] = {subsets Monat}

…vielleicht ausgeschrieben richtig?

irgendwas:Herbstmonat[3] = [Septeber, Oktober, Novbember]{subsets Monat}

Ich steh auf m Schlauch. Desweiteren…

• {union} und {subsets <attribut>}
• {redifines <attribut>}
• {composit}

Wie habe ich diese Jungs zu verstehen?

Ich hab gegoogelt und mehrere Dinge gefunden mit gleichem - für mich - unverständlichen Wortlaut übersetzt und nicht. Ein sehr kompakter Satz im DE wie auch im EN. Ich kappiere es nicht 😕.

lgmb

[pl]

hi MB,

OOP ist eine praktische Angelegenheit. Demgegenüber gibt es Theoretiker die noch nie mit OOP was Praktisches gemacht haben und OOP als etwas wahnisinnig kompliziertes hinstellen. Dabei werden Begriffe eingebracht, die überhaupt keinen Bezug zur Praxis haben.

Aber wie sieht nun die Realität aus? Praktisch kommen Mehrfachvererbung und komplizierte Klassenhierarchien höchst selten zur Anwendung. Vielmehr wird man auch für eine größere Geschichte eine Basisklasse schreiben und die Vererbung nur einmal anwenden wenn es darum geht die Aufgabe zu spezialisieren. Für einen solchen Entwurf braucht man kein UML.

Des Weiteren: Klassenvariablen und Klassenfunktionen verhalten sich statisch genauso wie globale Variablen unf Funktionen. Deren Verwendung kann zu Problemn führen wenn Code im Speicher verbleibt (mod_php, fast_cgi) so daß man immer aufpassen muss daß richtige Daten nicht in falschen Händen landen.

Idealerweise werden von daher sämtliche Daten die vom Request bis zur Response anfallen in einer Instanz gekapselt die am Ende zerstört wird. Kapselung ist ein wesentlicher Bestandteil von OOP und macht statische Symbole praktisch überflüssig. Und jetzt guck mal in Deine Klassen wie oft Du den Destruktor verwendest.

Lass Dich nicht beirren. Und ja, Festhalten ist besser als Loslassen. MFG

[MB]

moin,

OOP ist eine praktische Angelegenheit. Demgegenüber gibt es Theoretiker die noch nie mit OOP was Praktisches gemacht haben und OOP als etwas wahnisinnig kompliziertes hinstellen.

Wenn mans richtig anstellt ist es das auch für einen Sofwarearchitekten. Er hat 's studiert.

Dabei werden Begriffe eingebracht, die überhaupt keinen Bezug zur Praxis haben.

Meines wissens nach stimmt das nicht oder ich hab dich fals verstanden, wie e so häufig vorkommt 😀.

CD ist konzeptbezogen die Abbildung eines zu programmierendes Systems & dient zur Übersicht eines vorhandenden ausprogrammierten Systems. UML versteht jeder Programmierer. Es wird in der Analyse- & Designphase bei - ich betone - großen Projekten entwickelt. Bei Kleinen Projekten lohnt es sich weniger denke ich.

lgmb

[pl]

Nun, wenn ich mir Deinen Code zum TableConstructor anschaue sehe ich, daß Du den Sinn von OOP nicht wirklich verstanden hast. Solch eine Klassenflut ist nicht der Sinn von OOP! Vielmehr gehts in OOP darum, Sachverhalte und praktische Aufgaben möglichst einfach zu modellieren.

MFG

[dedlfix]

Tach!

Nun, wenn ich mir Deinen Code zum TableConstructor anschaue sehe ich, daß Du den Sinn von OOP nicht wirklich verstanden hast. Solch eine Klassenflut ist nicht der Sinn von OOP!

OOP ist ein Programmierprinzip. Eine quantitative Aussage steckt da nicht drin. Vielleicht hast du einfach nicht das Single Responsibility Prinzip verstanden?

Vielmehr gehts in OOP darum, Sachverhalte und praktische Aufgaben möglichst einfach zu modellieren.

Komplexe Sachverhalte lassen sich üblicherweise nicht wesentlich vereinfachen. Es ist nun eine Frage der Organisation und Abwägung der Vor- und Nachteile. Man kann zwar eine große Klasse mit schlanker API erstellen, aber Aufteilung in viele kleine, dafür aber einfacher zu testende Klassen ist das, was sich in der Praxis mehr bewährt hat.

Wie auch immer, deine Antwort hat das Thema verfehlt. Die Frage war nicht, wie mal seine Klassen strukturiert, sondern wie man bestimmte konkrete Sachverhalte in UML abbildet.

dedlfix.

[pl]

Nun, wenn ich mir Deinen Code zum TableConstructor anschaue sehe ich, daß Du den Sinn von OOP nicht wirklich verstanden hast. Solch eine Klassenflut ist nicht der Sinn von OOP! Vielmehr gehts in OOP darum, Sachverhalte und praktische Aufgaben möglichst einfach zu modellieren.

MFG

PS: Und dann sollte man Instanzen nicht einfach dem Konstruktor einer fremden Klasse übergben. Sowas ist schwer zu debuggen. Wenn man die Funktionaliät einer fremden Klasse benötigt, ist zu überlegen ob man:

1. Vererbung nutzt und alle Methoden/Eigenschaften erbet
2. oder nur einzelne Methoden delegiert

Was (1) betrifft, man sollte eine Klasse sehr gut kennen bevor man sie als Basisklasse einsetzt (also deren Erbe antritt).

MFG

[1unitedpower]

PS: Und dann sollte man Instanzen nicht einfach dem Konstruktor einer fremden Klasse übergben. Sowas ist schwer zu debuggen. Wenn man die Funktionaliät einer fremden Klasse benötigt, ist zu überlegen ob man:

1. Vererbung nutzt und alle Methoden/Eigenschaften erbet
2. oder nur einzelne Methoden delegiert

Genau das Gegenteil ist der Fall. Vererbung und Methoden-Delegation sorgen für eine enge Kopplung zwischen den Klassen. Komposition hingegen sorgt für lose Kopplung. So kann man die Klassen dann auch getrennt voneinander testen. Außerdem kommt bei Vererbung das Diamant Problem hinzu.

[Rolf B]

Hallo MB,

ich habe auch mal gegoogelt. Demnach bezieht sich subsets auf Relationen und ist schon eine relativ spezielle Angelegenheit. Du solltest dich fragen, ob Du das wirklich brauchst. Subset bedeutet Teilmenge, du brauchst also Mengen (=Relationen). Ob es Ähnliches auch für enum-Attribute gibt, könnte ich mir vorstellen, habe es aber nicht gefunden. Bei Relationen spielen folgende Komponenten mit:

• eine Beziehung zwischen Klasse A und Klasse B (1:1, 1:N, N:1 oder M:N dürfte egal sein)
• eine von A abgeleitete Klasse C
• eine von B abgeleitete Klasse D
• eine 1:N Beziehung zwischen Klasse C und D

Unklar ist mir hier noch, ob es hierbei um eine zusätzliche Beziehung geht, die in C und D modelliert ist, oder um die von C und D geerbte Beziehung.

Jedenfalls habe ich daraus das Folgende verstanden, was aber auch völlig falsch sein kann:

Mit subsets soll ausgedrückt werden, dass die Einträge in der Beziehungsrelation C-D eine Teilmenge der Einträge in der Beziehungsrelation A-B darstellen. Dieser Satz ergibt am meisten Sinn dann, wenn C-D die geerbte Relation A-B ist, denn nur dann ist eine solche Zusatzangabe überhaupt nötig. Eine explizte Angabe in C (hat Relation zu D) bedeutet ja, dass ich da nur Objekte vom Typ D hineinbekomme. Wenn C dagegen von A die Angabe (hat Relation zu B) erbt, dann kann ich einem C auch eine Relation zu B anhängen, womit es vielleicht nichts anfangen kann.

Ob dein Herbstmonat dafür ein gutes Beispiel ist, weiß ich nicht. Wenn Du eine Klasse "Monat" hast und davon den "Herbstmonat" ableitest, dann müsste man zum einen überlegen, was mit September und Dezember ist - das sind ja nicht nur Herbstmonate. Aber nehmen wir einfach den größeren Anteil, dann wären das Okt, Nov und Dez.

Nun nehmen wir noch eine Klasse Ferien. Ferien finden in bestimmten Monaten statt. Wir könnten also eine M:N Beziehung Ferien zu Monate vorsehen. Diese Beziehung wird von Herbstferien und Herbstmonat geerbt, rein technisch könnte ich also den Herbstferien den März zuordnen. Fachlich ist das aber falsch, darum modelliere ich ein Subset und sage: Herbstferien passen zur zu Herbstmonaten.

Ich stelle hier nicht die Frage nach der Sinnhaftigkeit einer solchen Detaillierung von Ferien und Monaten, sondern setze einfach voraus, dass es einen Usecase gibt, der das benötigt. Sonst hätte ich mich von deinem Beispiel komplett entfernen müssen. Statt Ferien und Monaten könnte man auch Fahrzeuge (PKW und LKW) und Bremsen (PKWBremsen und LKWBremsen) nehmen - ich kann in einen PKW keine LKW-Bremse einbauen und mutmaßlich haben diese Bremsentypen auch unterschiedliche Attribute.

Rolf

[MB]

moin,

WOW!!! klingt super logisch. Ich danke dir für deine sehr große Hilfe!!!

lgmb

P.S.: Ich bin eben leider nicht mächtig genug um im Internet Chaos top-, bullshit- und wirrwar-Infos zu unterscheiden, zu filter und heraus zu ziehen 😕. Daher wendew ich michj vertrauensvoll an dieses großartige Forum mit hilfsbereiten Profie(s) 😉.