In seinem lesenswerten Buch
Java Application Architecture [Knoernschild 2012] beschreibt Kirk Knoernschild die Distanz zwischen Software-Architekt und Software-Entwickler durch die Metapher des Elfenbeinturms. Er macht anschaulich, warum die intellektuelle Distanz zwischen den architektonischen Entwürfen und dem Quellcode oftmals zu groß ist, um eine fruchtbare Kommunikation zu ermöglichen. Folge: Die Ideen des Architekten kommen im Quellcode nicht an, und die Niederungen des Quellcodes fließen nicht in die Ideen des Architekten ein.
Die Metapher funktioniert zwar nur dann, wenn man ein sehr stereotypes Architektenbild zulässt, aber die zu Grunde liegende Frage ist berechtigt: Wie soll es geschehen, dass übergeordnete mentale Konstrukte bei der Umsetzung untergeordneter Konstrukte berücksichtigt werden? In der Softwaretechnik sind dem Quellcode zahlreiche mentale Konstrukte übergeordnet:
- Programmierparadigmen (prozedurale Programmierung, Objektorientierung, ...)
- globale Strukturen (Komponenten, Schichten, ...)
- lokale Strukturen (Entwurfsmuster, Schnittstellen, ...)
Universale Programmiersprachen erlauben es in den meisten Fällen, übergeordnete Konstrukte zu ignorieren. Wer in einer objektorientierten Programmiersprache entwickelt, kann dennoch einen weitgehend prozeduralen Programmierstil pflegen. Wer eine Komponente entwickelt, findet dazu in vielen Programmiersprachen kein passendes syntaktisches Konstrukt. Wer ein Entwurfsmuster umsetzt, kann es für seine Zwecke jederzeit anpassen. Dies alles kann sogar mitunter wünschenswert sein.
Für Prinzipien gilt Ähnliches. Als vergleichsweise übergeordnete mentale Konstrukte besteht zwischen ihnen und dem Quellcode eine große Lücke. Es gibt eine gemeinsame Ursache für diesen Sachverhalt, welche durch die folgende Abbildung veranschaulicht wird:
Während funktionale Anforderungen in einer Software vergleichsweise direkt repräsentiert werden können, gilt dies für qualitative Anforderungen nicht. Qualitätsmerkmale werden meist durch übergeordnete strukturelle Eigenschaften der Software erreicht, die sich erst auf den zweiten Blick in der Software erkennen lassen. Die Architektur der Anwendung und die Einhaltung von Strukturprinzipien sind wesentliche Repräsentationsformen der Software-Qualität.
Wir können die oben angestellten Erwägungen wie folgt zusammenfassen:
- Qualitätsmerkmale lassen sich oft nur indirekt in einer Software repräsentieren.
- Durch die fehlende direkte Repräsentationsmöglichkeit entsteht eine große Distanz zwischen qualitativen Anforderungen und ihrer Realisierung.
- Die große Distanz resultiert (mindestens) in
- einem größeren Umfang an erforderlichem Wissen der Beteiligten
- erhöhten Aufwänden für die Konzeption sowie
- aufwändigeren Prozessen.
Wie sich all dies in der Praxis ausgestalten lässt, wird noch näher zu untersuchen sein.
Quellen
[Knoernschild 2012] -
Java Application Architecture, Kirk Knoernschild (2012)
