Sie sind hier
Continuous Architecture Management: Erkennen und Verhindern von Struktureller Erosion
Viele Software Projekte leiden darunter, dass die ursprünglich angedachte Architektur nach einigen Iterationen nicht mehr mit der Implementierungswirklichkeit übereinstimmt. Unbemerkt vom Software Architekten ist die Struktur der Software erodiert, sodass die Wartung und Weiterentwicklung zunehmend schwieriger wird.
Die Ursachen für diese Software-Entropie sind vielfältig: Z.B. Zeitdruck, unterschiedliche Kenntnisse und Fähigkeiten der Entwickler, mangelndes Qualitätsbewusstsein und fehlende Werkzeugunterstützung.
Als Symptome werden Starrheit, Zerbrechlichkeit, fehlende Modularisierung und mangelende Verständlichkeit wahrgenommen. Doch wie kann man diese Symptome struktureller Erosion messen und verhindern?
Eine Metrik sind Zyklen in der Software, die negativen Einfluss auf die Wiederverwendung, Erweiterbarkeit, das Testen und die Verständlichkeit haben und bekannte weitere Metriken wie z.B. den Kopplungsgrad (Average Component Dependency) negativ beeinflussen.
Um das Entstehen oder die Ausbreitung von Zyklen in der Software zu verhindern und die Einhaltung der Architektur zu gewährleisten, muss eine kontinuierliche Überprüfung von Soll- und Ist-Zustand stattfinden. Auf Makro-Ebene hilft hierbei eine Logische Architektur, auf Mikroebene die Definition von Schwellwerten auf Metriken: Code-Zeilen pro Klasse, Klassen pro Package, Zyklomatische Komplexität von Methoden, etc.
Mit einer geeignete Werkzeugunterstützung erfolgt nun eine Verbindung zwischen Logischer Architektur und Implementierung, sodass Verletzungen für den Architekten leicht erkennbar sind, und der Entwickler durch seine IDE gewarnt wird, falls er eine der Regeln unbewusst verletzen will.
Durch die kontinuierliche und automatisierte Überprüfung entfallen kosten- und zeitaufwändige subjektive Architektur-Reviews durch Berater und die Qualität der Software kann stattdessen an objektiven Messwerten festgemacht werden, wie z.B. der Anzahl von Architekturverletzungen oder Zyklen.
Liste von interessanten Referenzen zum Thema:
- Large-Scale C++ Software Design, John Lakos, Addison-Wesley 1996
- Applying UML And Patterns, Craig Larman, Prentice Hall 2000
- Agile Software Development, Robert C. Martin, Prentice Hall 2003
- Mythical Man Month, Frederick P. Brooks, Addison-Wesley, 1975, 1995
- The Pragmatic Programmer: From Journeyman to Master, Andrew Hunt, David Thomas, Addison-Wesley, 1999