Property
Eine typisierte Eigenschaft, die einem Classifier oder einer Assoziation zugeordnet ist und Werte beziehungsweise Verknüpfungen repräsentiert.
Vom Gedanken zur präzisen Modelleigenschaft
In einem Klassendiagramm wirken Merkmale wie unscheinbare Zeilen. Hinter einer Zeile wie „titel: String“ stehen jedoch mehrere Entscheidungen: Wem gehört diese Eigenschaft, welche Werte kann sie aufnehmen, wie oft kommt sie vor, darf sie verändert werden und wird ihr Wert gespeichert oder berechnet? Gute Modelle machen nur die Entscheidungen sichtbar, die für das jeweilige Gespräch wichtig sind.
Die UML verwendet „Feature“ als Oberbegriff für Merkmale eines Classifiers. Ein strukturelles Merkmal beschreibt, welche Werte oder Beziehungen Instanzen tragen können. Eine Property kann als Attribut in einem Klassenkasten erscheinen oder als Ende einer Assoziation. Beide Darstellungen verweisen auf denselben Grundgedanken: Ein typisierter, benannter Platz gehört zum Kontext eines Classifiers.
Die Notation ist kompakt, aber nicht beliebig. Ein Pluszeichen bezeichnet öffentliche Sichtbarkeit, ein Minuszeichen private Sichtbarkeit. Ein Schrägstrich vor dem Namen markiert eine abgeleitete Eigenschaft. Unterstreichung steht in vielen Diagrammen für ein statisches, also classifierbezogenes Merkmal. Multiplizitäten grenzen ein, wie viele Werte zulässig sind.
Attributdarstellung
Die Property steht als Textzeile im Attributfach einer Klasse. Diese Form eignet sich für kompakte, lokal verständliche Aussagen.
Assoziationsende
Die Property steht am Ende einer Verbindung. Rollenname, Typ und Multiplizität werden dadurch räumlich mit der Beziehung verbunden.
Ableitung
Der Wert entsteht aus anderen Informationen. Der vorangestellte Schrägstrich erinnert daran, dass er nicht unabhängig gepflegt werden sollte.
Interaktion 1 · Notation zusammensetzen
Baue eine Merkmal-Signatur
Verändere Name, Typ, Multiplizität und Modifikatoren. Das Atelier setzt daraus eine UML-nahe Zeile zusammen und übersetzt sie anschließend in einen vollständigen deutschen Satz.
Klassenfach
Bibliothekskonto
- reservierungen: Reservierung [*] {unique}
In Worten
Ein Bibliothekskonto besitzt privat beliebig viele eindeutige Reservierungen vom Typ Reservierung.
Die Reihenfolge folgt Sichtbarkeit, Name, Typ, Multiplizität und Eigenschaften.
Nicht gesetzte optionale Bestandteile werden ausgelassen.
-Sichtbarkeit
reservierungenName
ReservierungTyp
*Multiplizität
uniqueEigenschaften
Lesereihenfolge
Fünf Entscheidungen in einer Zeile
Sichtbarkeit bewusst wählen
- kontostand: Geldbetrag
Die Sichtbarkeit beantwortet, aus welchem Modellkontext auf das Merkmal zugegriffen werden darf. Sie ist eine Aussage über die entworfene Struktur, nicht bloß typografische Dekoration.
Typ und Multiplizität trennen
+ autoren: Person [1..*]
Der Typ sagt, welche Art von Wert vorkommt. Die Multiplizität sagt, wie viele Werte zulässig sind. „Person“ und „mindestens eine Person“ sind zwei getrennte Modellentscheidungen.
Modifikatoren begründen
/ alter: Integer {readOnly}
Ein abgeleitetes Alter wird aus Geburtsdatum und Stichtag berechnet. Schreibschutz verhindert, dass eine unabhängige Eingabe dem Berechnungsergebnis widerspricht.
Interaktion 2 · Gültige Objektzahl prüfen
Erfüllt der Schnappschuss die Multiplizität?
Wähle eine Grenze und stelle ein, wie viele Werte eine Beispielinstanz gerade besitzt. Der Prüfer entscheidet nur für diesen Schnappschuss; er verändert weder Modell noch Daten.
Instanz-Schnappschuss
Gültiger Schnappschuss
Drei Werte erfüllen die Forderung nach mindestens einem Wert.
Modellierungsentscheidung
Attributzeile oder Assoziationsende?
Beide Darstellungen können eine Property ausdrücken. Die Wahl richtet sich danach, welche Zusammenhänge im Diagramm sichtbar werden sollen, nicht nach einer starren Regel für jeden Datentyp.
| Frage | Attributzeile | Assoziationsende |
|---|---|---|
| Was steht im Vordergrund? | Kompakte Eigenschaft des Classifiers. | Beziehung zwischen zwei Classifiern. |
| Typischer Eindruck | - farbe: Farbcode bleibt lokal im Kasten. |
Eine Linie macht Rollen, Navigierbarkeit und Gegenrichtung sichtbar. |
| Wann wird es unübersichtlich? | Wenn viele fachliche Beziehungen als lange Typnamen verborgen werden. | Wenn jede einfache Werteigenschaft eine zusätzliche Linie erhält. |
| Praktische Leitfrage | Genügt die lokale Aussage für das aktuelle Modellziel? | Muss das Publikum die Beziehung als eigenen Sachverhalt diskutieren? |
Interaktion 3 · Modellierungsfälle
Ziehe eine Fallkarte
Vier kurze Fälle wechseln in fester Reihenfolge. Formuliere zuerst selbst eine Property und decke dann die kommentierte Lösung auf.
Fall 1 von 4
Eine Rechnung kann noch unbezahlt sein oder genau ein Zahlungsdatum besitzen. Wie lautet eine knappe Property?
Lösungsvorschlag
- zahlungsdatum: Datum [0..1]
Die Multiplizität 0..1 erlaubt den fehlenden Wert vor der Zahlung und genau ein Datum danach.
Drei Prüffragen für das Review
Ist der Name fachlich?
Ein Merkmalname sollte im Wortschatz der Domäne verständlich sein. Technische Speicherformen gehören nur dann ins Diagramm, wenn sie Teil des Modellziels sind.
Ist die Grenze begründet?
Eine Multiplizität ist eine fachliche Behauptung. „Beliebig viele“ aus Bequemlichkeit kann ebenso falsch sein wie „genau eins“ ohne Umgang mit unvollständigen Fällen.
Ist die Darstellung sparsam?
Gute Diagramme zeigen genug für die aktuelle Entscheidung. Eigenschaften, die keinen Unterschied im Gespräch machen, können in einer anderen Sicht aufgehoben werden.