UML (Unified Modeling Language): Abstrakte Klassen und Interfaces

avatar

Abstrakte Klasse

Die UML unterscheidet drei Arten von Klassen, die auch in den gebräuchlichen objektorientierten Programmiersprachen ausdrückbar sind:

  1. Reguläre Klassen, deren sämtliche Operationen implementiert sind
  2. Abstrakte Klassen, die mindestens eine abstrakte Operation besitzen, d.h. eine Operation, für die keine Implementierung angegeben ist
  3. Interfaces, die keine Attribute besitzen, keine ihrer Operationen implementieren und keine “Kenntnis“ von Assoziationen haben dürfen, d.h. sie dürfen höchstens Ziel einseitig navigierbarer Assoziationen sein. Interfaces sind in Java durch ein Sprachkonstrukt gleichen Namens realisiert, in anderen Programmiersprachen als spezielle abstrakte Klassen.

Von regulären Klassen können Instanzen erzeugt werden, nicht aber von abstrakten Klassen oder Interfaces (Stand 2020). In der UML werden die Namen von abstrakten Klassen und von abstrakten Operationen kursiv geschrieben oder es wird das Schlüsselwort abstract vorangestellt.

Beispiel
Die Klasse Kunde ist eine abstrakte Klasse mit der abstrakten Operation bonitaet(). Die beiden regulären Unterklassen Firmenkunde und Privatkunde müssen also jeweils eine Implementierung, d.h. eine Methode, für die Operation bonitaet() bereitstellen.


Abbildung 1: Eine Abstrakte Klasse mit seinen Kindsklassen

Interface

Interfaces werden in UML-Diagrammen als Klassen mit dem Stereotyp «interface» dargestellt oder einfach als ein kleiner, mit dem Namen des Interface unterschriebener Kreis.


Abbildung 2: Ein Interface, links ausführlich und rechts als einfache Darstellung

Abstrakte Klassen und Interfaces dienen primär der Strukturierung von Modellen und Software. Sie extrahieren Gemeinsamkeiten von Klassen und definieren Vorgaben für deren Schnittstellen, wobei in abstrakten Klassen nicht nur die Schnittstelle, sondern auch Teile der Implementierung zur Redundanzvermeidung vordefiniert werden können.

Quelle
Jacobson, I., Booch, G., Rumbaugh, J. The Unified Software Development Process Addison-Wesley/acm Press, Reading, Mass., 1999



0
0
0.000
0 comments