 |
| | | | | Beschreibung | | Murphy et al. diskutieren in [ MNS01] mit den sogenannten Reflexionsmodellen eine Methode, welche die Konsistenz verschiedener Dokumente untereinander untersucht. Die Entwicklung eines Software-Produkts durchläuft normalerweise mehrere Phasen, bei dem zunehmend feinere Beschreibungen des Produkts entstehen: Anforderungsbeschreibungen, Architekturen, Entwürfe, Quellcode und letztlich ausführbarer Code. Einige dieser Artefakte werden automatisch aus vorhergehenden Artfakten generiert (z.B. ausführbarer Code aus dem Quellcode). Die meisten Transformationen erfolgen jedoch händisch und die einzelnen Artefakte werden unabhängig voneinander manipuliert.
Dies führt dazu, dass die einzelnen Dokumente über längere Zeit auseinanderdriften, weil deren Konsistenzhaltung aufwändig und schwierig ist und dieser Tätigkeit selten hohe Priorität zugewiesen wird.
Die Idee der Software-Reflexionsmodelle liegt darin, diese Unterschiede aufzudecken. Ein Reflexionsmodell liefert eine genügend abstrakte Sichtweise auf eine Software, so dass typische Wartungstätigkeiten anhand eines solchen Modells durchgeführt werden können. Diese Modelle sind zum einen genauer als eventuell vorhandene Entwurfsdokumente, weil sie stets mit dem Quellcode korrespondieren. Sie sind andererseits abstrakter als Quellcode selbst, so dass es leichter fällt, einen Überblick zu erlangen.
Kurzgesagt, stellt ein Reflexionsmodell eine Zusammenfassung der in einem Quellcode bestehenden Entitäten und Beziehungen von einem höheren Standpunkt dar und vergleicht diese mit einer vorliegenden abstrakten Beschreibung.
Beispiel eines Reflexionsmodells
Die Erstellung eines Reflexionsmodells erfolgt in mehreren Schritten:
- Zunächst wird eine grobe Beschreibung der geplanten (Soll-) Architektur des Systems benötigt. Diese stellt die geplante Architektur des Systems mit gewissen Entitäten und gewissen Beziehungen zwischen den Entitäten dar.
- Die tatsächliche (Ist-)Architektur wird aus dem Quellcode gewonnen. Dazu ist es notwendig, jedes im Quellcode definierte Artefakt (also Module, Klassen, Funktionen usw.) einer der im ersten Schritt definierten Entitäten zuzuordnen. Dies kann beispielsweise erfolgen, indem anhand der Verzeichnisstruktur des Quellcodes oder anhand der Namensgebung zugleich mehrere Dateien jeweils zu einer Entität zusammengefasst werden. Die Relationen der Ist-Architektur ergeben sich dadurch, dass jegliche Beziehungen, die zwischen den ursprünglichen Quellcodeelementen bestehen (z.B. Methodenaufrufe, Vererbung etc.), bis auf die gleiche hohe Ebene hinauf aggregiert werden.
- Im dritten Schritt wird schließlich überprüft, welche Abweichungen bezüglich der geplanten und tatsächlich vorhandenen Beziehungen zwischen den Entitäten bestehen. Dabei können drei Fälle eintreten:
- Übereinstimmung: Eine geplante Abhängigkeit tritt tatsächlich auf. Dies ist der gewünschte Fall.
- Überspezifikation: In der Soll-Architektur wurde eine Abhängigkeit spezifiziert, die nicht vorhanden ist. Diese Abweichung ist aus Sicht der Wartbarkeit des Quellcodes nicht tragisch, erschwert aber Versuche, das System anhand der Soll-Architektur zu verstehen.
- Architekturverletzung: Es treten Abhängigkeiten auf, die zuvor nicht spezifiziert wurden. Dies ist eine tatsächliche Verletzung des ursprünglichen Architekturmodells und kann Ursache für vielfältige Probleme sein. Wenn zum Beispiel unbeabsichtigt zyklische Abhängigkeiten implementiert wurden, führt dies in der Regel zu Schwierigkeiten im Build-Prozess. Nicht geplante Abhängigkeiten führen zu Fehlannahmen, wenn einzelne Module an Hand der Entwurfsdokumentation verstanden, getestet oder wiederverwendet werden sollen.
| |
| | | | | | | | | | | | | Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben. |
|
| | | | |  | Übergeordnet | | | | | | | | | | | Reflexionsmodelle | | | | | | Erfahrungen | | | | | | | | Literaturhinweise | | | | | | | | | | Weitere Themen | | | | | | | | | | |
|
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights 
Eintrag kommentieren
