<< zurück

MBSE Home

weiter >>

2.1 Bedeutung der Klassendiagramme

Objektorientierte Systeme beinhalten eine hohe Dynamik. Dadurch wird die Modellierung der Strukturen eines Systems zu einer komplexen Aufgabe in der objektorientierten Softwareentwicklung. Klassendiagramme beschreiben diese Struktur beziehungsweise Architektur eines Systems, auf der nahezu alle anderen Beschreibungstechniken basieren. Klassendiagramme und die darin modellierten Klassen haben jedoch eine Vielfalt von Aufgaben.

Modellierung von Struktur

In einer objektorientierten Implementierung wird der Code in Form von Klassen organisiert. Ein Klassendiagramm stellt daher eine Übersicht über die Code-Struktur und seine inneren Zusammenhänge dar. Weil Programmierern das Konzept Klasse aus der Programmierung bekannt ist, sind die in der Modellierung genutzten Klassendiagramme auch leicht verständlich und kommunizierbar. Klassendiagramme werden zur Darstellung der strukturellen Zusammenhänge eines Systems eingesetzt und bilden so das Skelett für fast alle weiteren Notationen und Diagrammarten, da diese sich jeweils auf die in Klassendiagrammen definierten Klassen und Methoden abstützen. Auch deshalb bilden Klassendiagramme ein essentielles – wenn auch nicht einziges – Beschreibungsmittel zur Modellierung von Softwarearchitekturen und Frameworks.

Klassen in Analyse, Design und Implementierung

In der Analyse werden Klassendiagramme genutzt, um Konzepte der realen Welt zu strukturieren. Demgegenüber werden Klassendiagramme bei der Erstellung von Entwurfsdokumenten und in der Implementierung vor allem zur Darstellung einer strukturellen Sicht des Softwaresystems genutzt. Die in der Implementierungssicht dargestellten Klassen sind tatsächlich im implementierten System wieder zu finden. Klassen der Analyse werden dafür oft signifikant modifiziert, durch technische Aspekte ergänzt oder ganz weggelassen, weil sie z.B. nur zum Systemkontext gehören.

Eines der Defizite der UML entsteht aus der nicht optimalen Möglichkeit, den Diagrammen explizit einen Verwendungszweck zuzuordnen. Wird der Standpunkt eingenommen, dass ein Klassendiagramm eine Implementierung widerspiegelt, so kann die Semantik eines Klassendiagramms relativ einfach und verständlich erklärt werden. Diesen Standpunkt nehmen eine Reihe von Einführungsbüchern in die Modellierung mit Klassen beziehungsweise der UML ein [Mey97, Fow00]. Außerdem wird dieser Standpunkt oft auch durch Werkzeuge impliziert. Fusion [CAB⁺94] stellt demgegenüber eine explizite Abgrenzung zwischen zum System gehörigen und externen Klassen zur Verfügung und demonstriert so, dass die Modellierung von nicht-softwaretechnischen Konzepten mit Klassendiagrammen möglich und sinnvoll ist.

Das Sprachprofil UML/P ist implementierungsorientiert. Deshalb ist die nachfolgende Bedeutungserklärung von Klassendiagrammen auf Basis des dadurch modellierten Java-Codes für diesen Einsatz ideal.

Aufgabenvielfalt einer Klasse

In der objektorientierten Programmierung und stärker noch der Modellierung haben Klassen eine Vielzahl von Aufgaben. Primär dienen sie zur Gruppierung und Kapselung von Attributen und dazugehörigen Methoden zu einer konzeptuellen Einheit. Durch Vergabe eines Klassennamens können Instanzen der Klasse an beliebigen Stellen im Code erzeugt, gespeichert und weitergereicht werden. Klassendefinitionen dienen daher gleichzeitig als Typsystem und als Implementierungsbeschreibung. Sie können (im Allgemeinen) beliebig oft in Form von Objekten instanziiert werden.

In der Modellierung wird eine Klasse auch als Extension, also als die Menge aller zu einem bestimmten Zeitpunkt existierenden Objekte, verstanden. Durch die explizite Verfügbarkeit der Extension in der Modellierung kann zum Beispiel die Einhaltung einer Invariante für jedes existierende Objekt einer Klasse beschrieben werden.

Weil die Anzahl der Objekte in einem System potentiell unbeschränkt ist, ist die Katalogisierung der Objekte in endlich viele Klassen notwendig. Dadurch wird eine endliche Aufschreibung eines objektorientierten Systems erst ermöglicht. Klassen stellen damit eine Charakterisierung der möglichen Strukturen eines Systems dar. Diese Charakterisierung beschreibt gleichzeitig auch notwendige Strukturformen, ohne jedoch eine konkrete Objektstruktur festzulegen. Deshalb gibt es normalerweise unbeschränkt viele unterschiedliche Objektstrukturen, die einem Klassendiagramm genügen. In der Tat entspricht jedes korrekt laufende System einer sich weiterentwickelnden Sequenz von Objektstrukturen, bei der zu jedem Zeitpunkt die aktuelle Objektstruktur dem Klassendiagramm genügt.

Im Gegensatz zu den Objekten haben Klassen jedoch während der Laufzeit eines Systems in vielen Programmiersprachen keine direkt manipulierbare Repräsentation. Ausnahmen hierzu bilden etwa Smalltalk, das Klassen ebenfalls als Objekte repräsentiert und dadurch uneingeschränkte reflektive Programmierung erlaubt.1

Metamodellierung

Für die Beschreibung einer diagrammatischen Sprache hat sich aufgrund ihrer zweidimensionalen Darstellungsform die Metamodellierung [CEK⁺00, RA01, CEK01, Béz05, GPHS08, JJM09, AK03] als Präsentationsform durchgesetzt und damit die für Text üblichen Grammatiken abgelöst. Ein Metamodell definiert die abstrakte Syntax einer graphischen Notation. Spätestens seit der UML-Standardisierung ist es üblich, als Metamodell-Sprache selbst eine einfache Form von Klassendiagrammen einzusetzen. Dieser Ansatz hat den Vorteil, dass nur eine Sprache erlernt werden muss. Wir diskutieren Metamodellierung im Anhang A und nutzen eine Variante der Klassendiagramme um die graphischen Anteile der UML/P darzustellen.

Weiterführende Konzepte für Klassendiagramme

In der UML werden weiterführende Konzepte angeboten, die hier der Vollständigkeit halber erwähnt sein sollen. Assoziationsklassen sind zum Beispiel Klassen, die an die nachfolgend noch eingeführten Assoziationen angefügt werden, um Information abzulegen, die keiner der an der Assoziation beteiligten Klassen, sondern nur der Beziehung selbst zugeordnet werden können. Es gibt aber Standardverfahren, solche Daten ohne Assoziationsklassen darzustellen.

Moderne Programmiersprachen wie C++ und Java [GJSB05] sowie auch die UML ab Version 2.3 [OMG10a] bieten mittlerweile die zunächst von funktionalen Sprachen wie Haskell [Hut07] eingeführten generischen Typen an. In Java ist diese Einführung gut gelungen [Bra04]. Dies muss mit Sorgfalt erfolgen, da Typisierungen in fast allen Diagrammtypen vorkommen. Da Generics bei der Modellierung keine ganz so wichtige Rolle einnehmen, sondern vor allem in der Implementierung für die Wiederverwendung generischer Komponenten genutzt werden, wird auf die volle Allgemeinheit generischer Klassen mit Wildcards, gebundener Typisierungen etc. in der UML/P verzichtet und nur die wichtigen Container-Klassen als generisch also mit Typparametern realisiert angeboten. Die Klassendiagramme der UML/P bieten daher keine Mechanismen zur Definition von Generizität, die OCL/P sowie die Codegenerierung gehen aber darauf ein.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>