Bewertung der Qualität objektorientierter Entwürfe - Worte-Projekt

54 5 Ein Referenzmodell für den objektorientierten Entwurf
Relation zur Gesamtsumme hinzuzuzählen. Hier wird die Formalisierung am Beispiel
von uses* gezeigt.
uses*(x,y).weight = uses(x,y).weight + Σ z∈C∪I: extends*(x,z) uses(z,y).weight
Bei realizes* sollte das Gewicht immer maximal 1 sein, da faktisch eine Klasse ein
Interface nicht mehrfach realisieren kann. Es kann höchstens eine bereits vorhandene
Realisierung durch Redefinition der geerbten Realisierung geändert werden. Ein
Gewicht größer 1 dürfte immer auf einen Entwurfsfehler hinweisen.
5.4.4 Überlegungen zu Templates
Die Möglichkeit zur Bildung von parametrisierten Modellelementen ist in UML nicht
auf Klassen beschränkt. Beispielsweise lassen sich Entwurfsmuster als parametrisierte
Kollaborationen modellieren. Die hier betrachtete Erweiterung von ODEM
beschränkt sich aber auf Template-Klassen, da diese den üblichen Gebrauch von Templates
darstellen (z. B. in C++ oder Eiffel). Es werden auch nur vollständige Instantiierungen
von Templates betrachtet; außerdem wird die Möglichkeit zur Default-Belegung
von Parametern außer Acht gelassen.
Im UML-Metamodell werden Templates durch eine Assoziation der Klasse ModelElement
mit sich selbst modelliert (vgl. Abbildung 5-1). Ein ModelElement kann eine
Menge von Template-Parametern haben (Rolle templateParameter). Hat ein ModelElement
mindestens einen solchen Parameter, ist es ein Template, sonst nicht. Die Template-Parameter
sind formale Parameter und dürfen keine innere Struktur (Attribute,
Operationen, etc.) besitzen. Nur ihr Name und ihr Typ sind relevant. Die formalen
Parameter können Klassen sein, aber auch Datentypen und Operationen sind möglich.
Es können zusätzliche Einschränkungen für den Typ der Parameterbelegung
gemacht werden (z. B. der Parameter muss ein Interface implementieren oder eine
ganze Zahl sein). Außerdem können Beziehungen zwischen den Parametern untereinander
und mit dem Template selbst formuliert werden (z. B. Aggregation, Vererbung
etc.). Diese Beziehungen müssen dann auch bei den korrespondierenden Elementen
der Parameterbelegungen vorhanden sein. Das Template selbst kann zu
anderen Modellelementen nur ausgehende Beziehungen haben; diese werden auf die
Instanzen übertragen.
Eine Instantiierung eines Templates wird durch die Dependency-Unterklasse Binding
modelliert. Diese verbindet über die von Dependency geerbten Assoziationen das
Template (Rolle supplier) mit seiner Instanz (Rolle client). Die Parameterbelegung wird
durch eine zusätzliche, geordnete Aggregation modelliert; die Rolle arguments enthält
dabei die aktuellen Parameter.
Template-Klassen selbst sind keine echten Klassen, aber ihre Instanzen sind es. Daher
gehören Template-Instanzen zu C, Template-Klassen aber nicht. Für die Templates
wird daher eine neue Menge T eingeführt. Formale Parameter von Templates müssen
aussortiert werden, dürfen also keinesfalls zu C hinzugenommen werden.
Auf der Basis von Binding kann nun eine weitere Relation binds eingeführt werden:
binds: C × T
Eine Klasse ist Instanz eines Templates. binds(c,t) gilt genau dann, wenn es eine
Instanz von Binding gibt, bei der die Rollen client mit c und supplier mit t belegt sind.