Fußnoten Kap. 1

Fußnoten Kap. 2

Fußnoten Kap. 3

Fußnoten Kap. 4

Fußnoten Kap. 5

Fußnoten Kap. 6

Fußnoten Kap. 7

Fußnoten Kap. 8

Fußnoten Kap. 9

Fußnoten Kap. 10

Fußnoten Kap. 11

Fußnoten zu Kapitel 5

1 Die Bidirektionalität ist notwendig, weil die Berechnung nicht dem Kontrollfluss folgt, sondern eine Form der Change-Propagation (Publisher-Subscriber-Pattern) und damit eine Umkehrung der Berechnungsabhängigkeiten realisiert wird. Eine Datenflussanalyse kann prüfen, ob dieses Pattern mit all seiner Infrastruktur eingebaut werden muss oder eine bidirektionale Assoziation vorhanden ist. Bei einem geeigneten Generator kann auch durch den Anwender eingegriffen werden, um eine optimale Umsetzung zu sichern.

2 „Round Trip Engineering“ erlaubt es, sowohl in der abstrakten Diagrammsicht als auch in der Implementierung Veränderungen vorzunehmen, die dann in der jeweils anderen Sicht nachgezogen werden. Diese Vorgehensweise ist jedoch fragil, da nach heutigem Stand der Technik nur Kommentare verwendet werden, um die Verbindung zwischen beiden Sichten aufrecht zu erhalten. Hier wird eine weitere Alternative vorgeschlagen, die einige Vorteile des Aspect Oriented Programming mit einer kompakten Aufschreibung vereint. Grundidee ist es, Methodenimplementierungen nicht notwendigerweise nur nach der Klassenzugehörigkeit, sondern auch nach funktionalen Kriterien zusammenzufassen. So können beispielsweise die protocol-Methoden aller Klassen, die Methoden zum Durchlauf einer Teilehierarchie oder die Serialisierungsmethoden mehrerer Klassen jeweils in eine Datei zusammengefasst werden, die dann diesen Aspekt des Programms beinhaltet.

3 Die Ausführbarkeit besteht im Wesentlichen darin, dass die Nachbedingungen aus einer Konjunktion von Gleichungen besteht, deren linke Seiten veränderbare Attribute beziehungsweise das Ergebnis darstellen und die rechten Seiten diese Attribute in nur eingeschränkter Form benutzen. Zum Beispiel dürfen keine zirkulären Abhängigkeiten zwischen Attributen bestehen, um eine sequentielle Berechnung zu ermöglichen. Jede Gleichung darf zusätzlich mit einer Bedingung versehen sein.

4 Die Methode unmodifiableSet der Klasse java.util.Collections produziert aus einer beliebigen eine unveränderbare Menge, ohne allerdings die Signatur zu verändern.

5 Dies kann einerseits durch geeignete Kontextprüfungen bei den Coderümpfen gesichert, andererseits aber auch durch Verwendung außerhalb des Generators nicht bekannter Methodennamen erreicht werden.

6 Meistens wird den generierten Methoden ein anderer, nur intern bekannter Name gegeben und damit auch eine zufällige Namensübereinstimmung verhindert. Dadurch kann der Entwickler eine beliebige Methode addLocalRoleB definieren, die mit der generierten Methode nicht in Zusammenhang steht.

7Wie in Abschnitt 2.3.7, Band 1 beschrieben, bedeutet die Kardinalität 1“, dass der qualifizierte Zugriff genau ein Objekt liefert.

7 Der angegebene Qualifikator qualifier ist ein Attribut der gegenüberliegenden Klasse. Der Qualifikatorwert ist deshalb identisch zu dem Attributwert.

  roleB=factory.newClassB(arguments)

  roleB=new ClassB(arguments).

8Bei bestimmten Klassen, zum Beispiel Applets, ist die Initialisierung in eine Methode init() ausgelagert, die dann zur Initialisierungsphase zählt.

8 Eine statische Analyse sichert, dass die einmalige Besetzung des Attributs in jedem Fall stattfindet.

9 Dabei wird angenommen, dass eine gegebenenfalls verwendete Factory tatsächlich neue Objekte erzeugt.

10 Dummies simulieren ein Objekt, ohne die Funktionalität tatsächlich zu implementieren. Dies ist für die Simulation einer Interaktion mit der Systemumgebung genauso geeignet wie für Komponentengrenzen. Dieses Verfahren basiert auf dem Entwurfsmuster Abstract Factory aus [GHJV94].

11 Das ist zum Beispiel dann der Fall, wenn der Konstruktor wie in Abschnitt 5.1 beschrieben ebenfalls generiert wurde.

12 Wenn kein geeigneter Konstruktor existiert, dann kann ein Codegenerator einen solchen Konstruktor generieren. Die Links werden durch set-Methoden besetzt, die auch die korrekte Besetzung der Rückrichtung sichern.

13 Siehe Abschnitt 3.4.1, Band 1 über die Objekterzeugung in Queries. .

14 Um aussagekräftige Testresultate zu erhalten, empfiehlt es sich, anstatt der von Java zu Verfügung gestellten assert-Anweisung das in Abschnitt 6.2.3 diskutierte Test-Framework zu verwenden. Abbildung 5.29 zeigt eine entsprechend modifizierte Umsetzung.

15 Der Automat dient zur Erkennung von Eingabesequenzen und hat mit den in Kapitel 5, Band 1 beschriebenen Statecharts formal nichts zu tun. realisiert, der es erlaubt, diesen regulären Ausdruck zu erkennen. Abbildung 5.36 demonstriert dies an einem Beispiel.


Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012