Die Ist-Architektur von Softwaresystemen muss bekannt sein, um die Systeme kontrolliert ändern zu können. Nur, wenn die Ist-Architektur bekannt ist, kann sichergestellt werden, dass Änderungen sich an die geplante Architektur halten. Und nur, wenn die Ist-Architektur bekannt ist, können Entwicklungsteams ihre Systeme auf der abstrakteren Ebene der Architektur verstehen, kommunizieren und planen, ohne die Details des Quelltextes betrachten zu müssen. Doch die Ist-Architektur ist nicht eindeutig im Quelltext zu finden [RH09]. Das Problem lässt sich anhand eines Beispiels verdeutlichen. • Wir zeigen auf, welche Anteile der Ist-Architektur aus dem Quelltext entnommen werden können und welche zusätzlichen Informationen benötigt werden (siehe Abschnitt 3).
• Da Architekturstile für langlebige Softwaresysteme besonders relevant sind (siehe Abschnitt 2), diskutieren wir darüber hinaus, welche zusätzlichen Informationen für stilbasierte Ist-Architekturen notwendig sind (siehe Abschnitt 3).
• Wir zeigen, an welchen Stellen im Quelltext welche Architekturinformationen ein-gefügt werden müssen. (Abschnitt 4).
• Abschnitt 5 präsentiert eine beispielhafte Umsetzung mit Java-Annotations. Mit Hilfe eines Prototyps, der die stilbasierte Ist-Architektur von Softwaresystemen ermittelt, konnten wir die Machbarkeit unseres Ansatzes zeigen.
Um den fachlichen Hintergrund zu verdeutlichen, diskutiert dieser Abschnitt die Bedeutung von Architekturstilen für langlebige Softwaresysteme und gibt einen kurzen Überblick über die grundlegenden Begriffe.
Architekturstile machen Aussagen darüber, wie Software-Architekturen prinzipiell strukturiert werden sollen [RH09]. • die Menge der Architekturelemente E,
• eine Relation B I ⊆ E × E, die die bestehende Abhängigkeitsbeziehung zwischen diesen Architekturelementen beschreibt (kurz "Ist-Beziehungen"),
• die Relation Z A ⊆ E ×A, mit der die Architekturelemente den Architekturelementarten zugeordnet werden. Diese Relation ist rechtseindeutig.
Darüber hinaus wird die Menge A der Architekturelementarten benötigt, um Z A definieren zu können. Die Architekturelementarten ergeben sich aus dem gewählten Architekturstil. Im oben genannten WAM-Stil beispielsweise stehen unter anderem die Architekturelementarten Werkzeug und Material zur Verfügung.
Stilbasierte Ist-Architekturen werden soweit möglich direkt aus dem Quelltext berechnet. Dafür wird die Quelltextstruktur benötigt. Diese umfasst Folgendes:
Die stilbasierte Ist-Architektur und die Quelltextstruktur hängen zusammen, indem die Quelltextelemente den Architekturelementen in der folgenden Relation zugeordnet werden:
Das heißt, wenn zwei Quelltextelemente p und q in Beziehung stehen, gibt es eine Beziehung in der Ist-Architektur zwischen den Architekturelementen e und f, sofern p und e sowie q und f einander zugeordnet sind.
Die Zuordnungen Z Q und Z A sowie die Menge der Architekturelemente E müssen zusätzlich beschrieben werden, sie sind dem reinen Quelltext nicht zu entnehmen.
Dieser Abschnitt behandelt die Frage, wie Z Q , Z A und E durch Quelltextannotation beschrieben werden können. Betrachten wir unser Beispiel in Abbildung 3. Es gilt für das Architekturelement namens Patientenaufnehmer:
• (P atientenAuf nahmeT oolGui, P atientenauf nehmer) ∈ Z Q
• (P atientenAuf nahmeT ool, P atientenauf nehmer) ∈ Z Q
• (P atientenauf nehmer, W erkzeug) ∈ Z A Damit die Annotationen mit dem Quelltext einfach konsistent gehalten werden können, sollten sie in dem jeweils betroffenen Quelltextelement festgehalten werden. Das heißt in unserem Beispiel: in den beiden Klassen PatientenAufnahmeToolGui und PatientenAufnahmeTool wird die Information benötigt "diese Klasse gehört zu dem Werkzeug namens Patientenaufnehmer". Quelltextelemente werden annotiert mit dem zugehörigen Architekturelement und dessen Elementart. Formal dargestellt heißt das:
• annotiert werden alle Quelltextelemente q, für die gilt: ∃(q, e) ∈ Z Q .
• Die Annotation umfasst erstens das Architekturelement e, für das gilt: (q, e) ∈ Z Q ,
• und zweitens die Elementart a, für die gilt: (e, a) ∈ Z A .
In • Wir betrachten Architekturen, die auf Architekturstilen beruhen. Solche stilbasierten Architekturen spielen insbesondere für langlebige Softwaresysteme eine große Rolle.
• Wir nutzen die bestehenden Annotationsmöglichkeiten der Programmiersprache Java, um zusätzliche Informationen über die statische Architektur in den Quelltext zu bringen. Dadurch können bestehende Systeme von unserem Ansatz profitieren, ohne auf eine andere Sprache umsteigen zu müssen.
Der Ansatz, den Quelltext mit Architekturinformationen anzureichern, bietet verschiedene Vorteile:
• Entwicklungsteams können auf diese Weise ihre Intention bezüglich der Architektur direkt bei der Entwicklung festhalten.
• Es ist ein pragmatischer Ansatz. Dadurch, dass die Architekturinformationen direkt im Quelltext festgehalten werden, wird es einfacher, die Konsistenz dieser Informationen zum Quelltext zu wahren.
• Entwicklungsumgebungen können erweitert werden, so dass dem Entwicklungsteam während der Programmierung eine Architektursicht auf den Quelltext gegeben wird.
Wir zeigen eine beispielhafte Umsetzung mit Java-Annotations. Wir haben einen Prototyp erstellt, den ArchitectureExtractor. Mit ihm wurden mehrere annotierte Quelltexte untersucht und erfolgreich die stilbasierten Ist-Architekturen extrahiert. Unser Prototyp beinhaltet bisher nur eine sehr einfache Darstellung der extrahierten Architektur, wir planen, einen entsprechenden ArchitectureViewer zu ergänzen und zu evaluieren, um eine gute Architektursicht direkt zum Programmierzeitpunkt zu bieten.
Unser Ansatz ist für statisch getypte Sprachen geeignet, da die Abhängigkeitsbeziehungen der Ist-Architektur durch statische Analyse aus dem Quelltext gewonnen werden. Wie andere Ansätze zur Quelltextannotation ist auch unser Ansatz darauf angewiesen, dass korrekt annotiert wird. Dass Entwickler tatsächlich ihre Intention in den Quelltext schreiben, lässt sich selbstverständlich nicht sicherstellen. Die im Abschnitt 6 vorgestellten verwandten Arbeiten diskutieren dieses Thema nicht. Wir vermuten jedoch, dass durch Werkzeugunterstützung fehlerhafte Annotationen reduziert werden könnten. Wird beispielsweise eine annotierte Klasse umbenannt oder durch Kopieren erzeugt, so könnte ein "Dirty-Flag" den Entwickler darauf hinweisen, dass die zugehörige Annotation möglicherweise überarbeitet werden muss. Hierfür planen wir, den ArchitectureExtractor in laufenden Projekten einzusetzen, um mögliche Fehlerquellen zu identifizieren und unterstützende Ansätze wie das Dirty-Flag zu evaluieren.
Die praktischen Untersuchungen haben gezeigt, dass nur einige Klassen als architekturrelevant eingestuft werden und annotiert werden müssen. Da die Annotationen die Intention der Entwickler beschreiben, liegt es bei ihnen, zu entscheiden, ob sie ein Quelltextelement annotieren, genauso, wie sie vorher entscheiden mußten, welche Kommentare sie schreiben. Fehlerhafte Annotationen können -genauso wie fehlerhafte Kommentare -nur durch zustätzliche Maßnahmen, wie beispielsweise Code-Reviews, aufgedeckt werden. Unser Ansatz bietet den Vorteil, dass die Architektur nicht manuell anhand der Quelltextkommentare verstanden werden muss, sondern automatisiert extrahiert werden kann.
Wir haben den hier präsentierten Ansatz bereits erweitert, um auch hierarchische Architekturen behandeln zu können. Wir planen, diesen erweiterten Ansatz weiter zu evaluieren und zu veröffentlichen.
[AAA09] Marwan Abi-Antoun und Jonathan Aldrich. Static extraction of sound hierarchical runtime object graphs. In TLDI '09: Proceedings of the 4th international workshop on Types in language design and implementation, Seiten 51-64, New York, NY, USA, 2009. ACM.