Hilfe zur UML2.5 Klassendiagramm in Attribute und Eigenschaften

Bitte aktiviere JavaScript!
ich bin mir nicht sicher ob es richtig ist hier.

Ich behandele grade Klassen Diagramme durch genau Eigenschaften der Attribute und brauche 8 mal Hilfen.
1. wie sieht {subsets <Attributname>} im java code als Attribut aus und im Diagramm?
2. wie sieht {union} im java code als Attribut aus und im Diagramm?
3. wie sieht {redefines <Attributname>} im java code als Attribut aus und im Diagramm?
4. wie sieht {ordered} im java code als Attribut aus und im Diagramm?
5. wie sieht {seq} oder {sequence} im java code als Attribut aus und im Diagramm?
6. wie sieht {unique} im java code als Attribut aus und im Diagramm?
7. wie sieht {nonunique} im java code als Attribut aus und im Diagramm?
8. wie sieht {composition} im java code als Attribut aus und im Diagramm?

danke im voraus
 
Grundsätzlich ist es nicht so, dass man UML 1:1 auf Java abbilden kann (und umgekehrt).

1. Hier geht es um Teilmengen:
subsets.png
bedeutet, dass jedes Element von mainAddress (gibt hier höchstens eines) auch Element von addresses sein muss, also mainAddress ⊆ addresses gilt. Diese Beschränkung lässt sich in Java nicht unmittelbar ausdrücken. Vielmehr muss man durch Code dafür sorgen, dass sie eingehalten wird. Wie, bleibt dem Entwickler überlassen.

Java:
public void setMainAddress(int index) {
    mainAddress = addresses.get(index);
}
oder
Java:
public void setMainAddress(Address addr) {
    if (!addresses.contains(addr)) {
        throw new IllegalArgumentException("Given address doesn't belong to this company.");
    }
    mainAddress = addr;
}
2. union wird in der Regel mit einem derived attribute eingesetzt:
union.png

Die Aussage ist, dass addresses = mainAddress ∪ billingAddress gilt, also genau aus der Vereinung der Teilmengen besteht.

Zum Beispiel:
Java:
public void setMainAddress(Address addr) {
    mainAddress = addr;
}
public void setBillingAddress(Address addr) {
    billingAdress = addr;
}
public Set<Address> getAddresses() {
    return Set.of(mainAddress, billingAddress);
}
3. redefine ändert die Definition einer geerbten Eigenschaft.
redefines.png

Wenn wir mal davon ausgehen, dass Vegetarier auch nur Menschen sind, dann gilt die Aussage, dass Personen Lebensmittel zu sich nehmen, in ihrer Allgemeinheit nicht mehr. Das lässt sich nur Näherungsweise und ganz unterschiedlich in Java darstellen, denn die Redefinition einer einmal deklarierten Variablen ist nicht zulässig. Zum Beispiel könnte man folgendes machen:

Java:
class Vegetarian extends Person {
    @Override
    public void add(Food f) {
        if (f != null && VegetarianFood.class.isAssignableFrom(f.getClass())) {
            super.add(f);
        }
    }

    @SuppressWarnings("unchecked")
    public List<VegetarianFood> getVeggieFood() {
        return (List<VegeratianFood>)(List) getFood();
    }
}
Wobei sichergestellt sein muss, dass die von getFood() zurückgegebene Liste nicht modifizierbar ist. Letztlich ist es immer vom jeweiligen Fall abhängig, was man macht.

4. bis 7. kann man auf einen Schlag behandeln. Im Diagramm sieht es analog zu den bisherigen Beispielen aus. Sinn macht das ganze natürlich nur, wenn das Attribut mehr als ein Element aufnehmen kann. Ich nehme mal die Beziehung zwischen Person und Food aus Beispiel 3.

{ordered} - heißt, dass die Elemente in food geordnet sind, es also eine (wie auch immer geartete) Reihenfolge gibt. Das kann zum Beispiel eine List oder ein SortedSet sein.

{seq} bzw. {sequence} food - ist nichts anderes als {ordered, nonunique}

{unique} - bedeutet, dass es keine Duplikate gibt. In Java: Set

{nonunique} - bedeutet, dass Elemente mehrfach auftreten dürfen. In Java, z. B. List.

Bei ordered geht es also nur um die Reihenfolge, während es bei unique/nonunqiue nur um Duplikate geht. Die Kombination ist möglich (wie z. B. bei sequence}.

8. Kenne ich in der Form nicht. Komposition ist eine starke Aggregation (Ganzes-Teile-Beziehung). Im Diagramm wird sie durch eine gefüllte Raute dargestellt:

composition.png

Im Java-Code unterscheidet sich die Komposition nicht unmittelbar von einer gewöhnlichen Assoziation. Die Komposition sagt uns aber, dass ein Item-Objekt zu einem Zeitpunkt nur Teil einer Komposition (ggf. auch Aggregation, bin mir gerade nicht sicher) sein kann und zusammen mit dem Invoice-Objekt untergeht. Das Ganze und ihre Teile bilden sozusagen eine Einheit. In SQL würde man so etwas mit einem Fremdschlüssel und CASCADE DELETE umsetzen.
 
@mihe7 gibt es nicht Unterschiede bei den Attributen, Operation und Assoziationen ?
Wenn da Attributen stehen -> {subsets <Attributname>} , {union}, {redefines <Attributname>}... (siehe ersten Thread)
Wenn da Operatoren stehen -> {subsets <Attributname>} , {union}, {redefines <Attributname>}... (siehe ersten Thread)
Wenn da Assoziationen stehen -> {subsets <Attributname>} , {union}, {redefines <Attributname>}... (siehe ersten Thread)
 
@mihe7 wie sehen diese aus bitte ?

ich bringe mir das alleine bei alles und das UML2.5 Buch von Rheinwerk ist schlecht als recht es nur angekratzt und hänge in der Luft
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben