<< zurück

MBSE Home

weiter >>

2.4 Sicht und Repräsentation

Klassendiagramme haben im Allgemeinen das Ziel, die für eine bestimmte Aufgabe notwendige Struktur einschließlich ihrer Zusammenhänge zu beschreiben. Eine vollständige Liste aller Methoden und Attribute ist in diesem Fall meist hinderlich. Stattdessen sollten die Methoden und Attribute dargestellt werden, die für die Darstellung der „Story“ hilfreich sind. „Story“ ist eine Metapher, die gerne verwendet wird, um anzuzeigen, dass ein Diagramm einen Fokus hat, der wesentliche Information hervorhebt und unwesentliche Information weglässt. Diagramme können beispielsweise unterschiedliche Teilsysteme oder einzelne Systemfunktionen modellieren.

Ein Klassendiagramm stellt daher meist eine unvollständige Sicht des Gesamtsystems dar. So können einzelne Klassen oder Assoziationen fehlen. Innerhalb der Klassen können Attribute und Methoden weggelassen oder unvollständig dargestellt werden. Bei Methoden können beispielsweise die Argumentliste und der Ergebnistyp fehlen.

Leider ist einem UML-Diagramm im Allgemeinen nicht anzusehen, ob die darin enthaltene Information vollständig ist. Deshalb wurde neben dem von der UML bereits angebotenen Repräsentationsindikator „… “ zur Markierung unvollständiger Information auch „©“ zur Darstellung vollständiger Information aus [FPR01] übernommen.

Abbildung 2.13 zeigt, wie die beiden Indikatoren „… “ und „©“ eingesetzt werden können. Die Indikatoren „©“ und „… “ wirken nicht auf die Klasse selbst, sondern auf ihre Darstellung innerhalb des Klassendiagramms. Ein „©“ beim Klassennamen besagt, dass sowohl die Attribut- als auch die Methodenliste vollständig ist. Demgegenüber bedeutet der Unvollständigkeits-Indikator „… “, dass die Darstellung unvollständig sein kann. Aufgrund des nachfolgend diskutierten Dualismus zwischen Assoziationen und Attributen wird bei einer Vollständigkeit der Attributliste impliziert, dass gleichzeitig alle Assoziationen, die von dieser Klasse aus navigiert werden können, angezeigt sind.

Beide Indikatoren können auch einzeln auf die Liste der Attribute und die Liste der Methoden angewandt werden. Der Unvollständigkeits-Indikator „… “ wird bei Fehlen eines expliziten Indikators standardmäßig angenommen. Dies entspricht der oft üblichen Sichtweise, dass ein Diagramm eine Abstraktion des Systems darstellt.

Um die Verwendung dieser Indikatoren präzise zu erklären, sind die in Abbildung 2.14 illustrierten drei Modellebenen zu unterscheiden: das System selbst, das vollständige UML-Modell des Systems und eine graphische, unvollständige Repräsentation des Modells beispielsweise auf dem Bildschirm. Diese Repräsentation wird meist auch Sicht genannt, ist aber selbst ein Modell. Die beiden Indikatoren „©“ und „… “ beschreiben eine Beziehung zwischen der Sicht und dem vollständigen UML-Modell, auf dem die Sicht beruht. Wie Abbildung 2.13 zeigt, gibt es eine Reihe verschiedener Sichten für dieselbe Klasse. Die beiden Markierungen werden deshalb Repräsentationsindikatoren genannt.

Erreicht ein Softwaresystem eine bestimmte Größe, so kann ein vollständiges Klassendiagramm sehr überladen wirken. Aufgrund der vielen Details wird dann die Story eher verborgen als präsentiert. Deshalb ist es sinnvoll, bei der Softwareentwicklung mit mehreren kleineren Klassendiagrammen zu arbeiten. Notwendigerweise haben Klassendiagramme, die jeweils einen Ausschnitt des Systems zeigen, Überlappungen. Durch solche Überlappungen wird der Zusammenhang zwischen den einzelnen Modellen hergestellt. Abbildung 2.15 stellt zwei Ausschnitte des Auktionssystems dar, in der die Klasse Auction in unterschiedlicher Form repräsentiert ist. Der Indikator „… “ erlaubt hierbei explizit zu beschreiben, dass nur die für die jeweilige Story notwendige Information dargestellt wird.

Aus einer Sammlung einzelner Klassendiagramme kann ein vollständiges Klassendiagramm durch Verschmelzung gewonnen werden. Wie in Abschnitt 1.4.4 diskutiert, wird in einigen Werkzeugen intern immer ein ein vollständiges Klassendiagramm als Modell eingesetzt und dem Nutzer Ausschnitte in Form von Sichten dargestellt. Eine Verschmelzung von Klassendiagrammen ist im Wesentlichen eine Vereinigung aller Klassen-, Assoziationen- und Vererbungsbeziehungen, wobei bei einer mehrfach auftretenden Klasse Attribut- und Methodenlisten ebenfalls vereinigt werden. Natürlich gibt es eine Reihe von Konsistenzbedingungen, die zu beachten sind. Dazu gehören übereinstimmende Typisierungsangaben bei Attributen und Methoden, kompatible Navigationsrollen und Kapazitätsangaben bei Assoziationen sowie die Vermeidung zyklischer Vererbungsbeziehungen.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>