DTCTVE Geschrieben 18. Februar 2016 Geschrieben 18. Februar 2016 (bearbeitet) Hallo, frage mich grade wie man wohl List<T>, Properties und ähnliches korrekt in UML darstellt? Als stereotyp property z.B.? Beispiel List<T>: A.) +Operation(name : List<T>) : List<T> B.) <<List>> +Operation(name : List<T>) : List<T> Beispiel property: A.) +Attribute : string B.) <<property>> +Attribute : string Bei 1 würde ich A nehmen, bei 2 allerdings B, finde im Netz leider sehr viel unterschiedliches dazu.. Bearbeitet 18. Februar 2016 von Daniel.Koerner Zitieren
1 DTCTVE Geschrieben 9. März 2016 Autor Geschrieben 9. März 2016 Hab da was gefunden: http://stackoverflow.com/questions/27459257/how-to-represent-an-attributes-data-type-as-an-array-of-objects-on-class-diagra Quote Both are correct, but the second one, when multiplicity is set to more than one is used is more natural, and it is not necessary do define collection class as it is shown on the first picture of your example. Simply said, multiplicity defines how many instances of specific type can be stored by attribute. This set of instance can be ordered or duplicates in it may be allowed. Parameters of multiplicity element have impact on type of collection which should be used, Set, Vector, Array etc. But, if you need precise info about this issue, read UML Superstructure. Search for Property and Multiplicity Element. Hat sich also erledigt, trotzdem danke Zitieren
0 eddxter Geschrieben 1. März 2016 Geschrieben 1. März 2016 was genau soll das <<List>> ggf. <<property>> machen?... Ich denke die Klasse List<T> "könnte" zB. den Stereotyp <<collection>> angehören, was seine Attributen und Operationen betrifft sehe ich kein Gebrauch von Stereotypen nötig. bei beiden A... Zitieren
0 DTCTVE Geschrieben 9. März 2016 Autor Geschrieben 9. März 2016 Ich wollte auf die C#-Spezifischen Elemente "List<T>" (Collection) und die Properties abzielen. Ich hab' da ja nicht wirklich Getter oder Settermethoden sondern Properties. Hintergedanken war dabei, dass UML ja eher etwas allgemeines darstellen soll statt Programmiersprachentypische Elemente. Bei C# sind Properties ja eigentlich Attribute, allerdings werden diese ja im Endeffekt dazu verwendet, wofür man sonst Getter oder Setter-Methoden benötigen würde. Im übrigen geht es mir dann auch um {get; set;} - da man dort ja auch eine gewisse implementierung vornehmen kann. Ich denke ich bleibe erstmal dabei, ohne stereotypen zu arbeiten. Bis nächste Woche ist ja noch Zeit das Projekt abzugeben. Praxisbezogen habe ich etwa folgendes: public class Beispiel { public list<CopySet> CopySets { get; set; } = new List<CopySet>(); public string Test { get; private set; } } public class CopySet { // Konstruktor und Attribute etc. } Zitieren
Frage
DTCTVE
Hallo,
frage mich grade wie man wohl List<T>, Properties und ähnliches korrekt in UML darstellt? Als stereotyp property z.B.?
Beispiel List<T>:
A.) +Operation(name : List<T>) : List<T>
B.) <<List>> +Operation(name : List<T>) : List<T>
Beispiel property:
A.) +Attribute : string
B.) <<property>> +Attribute : string
Bei 1 würde ich A nehmen, bei 2 allerdings B, finde im Netz leider sehr viel unterschiedliches dazu..
3 Antworten auf diese Frage
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.