Autoren: Ralph Dittmar, TR-Electronic GmbH, Thomas Eisenbarth, Axivion GmbH<\/p>\n
Die Architektur als globale Struktur unserer Software ist das Fundament unserer t\u00e4glichen Arbeit. Daher ist es essentiell, dass wir uns mit unserer Architektur auseinandersetzen und nicht gegen sie arbeiten: Planen, Pr\u00fcfen und Bewerten k\u00f6nnen wir am besten mit Blick auf die Architektur. Entwickler arbeiten klassisch jedoch sehr detailliert an ihrer Software und verlieren so leicht den Blick f\u00fcr das Globale. Daher haben wir bei TR-Electronic eine Architekturpr\u00fcfung etabliert, die uns den Aufwand f\u00fcr diesbez\u00fcgliche manuelle und ungeliebte Reviews erspart und die Architektur im Tagesgesch\u00e4ft lebendig werden l\u00e4sst. Von diesem Weg und den erzielten Resultaten m\u00f6chten wir berichten, denn eingehaltene Architekturen sind f\u00fcr uns inzwischen eine Selbstverst\u00e4ndlichkeit in unserem Entwicklungsprozess geworden.<\/strong><\/p>\n Die Architekturbeschreibung eines Software-Systems erlaubt, auf abstraktem Niveau \u00fcber die Software zu sprechen und Erweiterungen an der Software zu analysieren, zu planen und zu bewerten. Damit dies gut funktioniert, muss die Architektur unter anderem zur Implementierung passen.<\/p>\n Eine Architektur im hier verwendeten Sinn beschreibt die statische Struktur des Systems: In welche Komponenten ist das System hierarchisch aufgeteilt? Die Beziehungen zwischen den Komponenten beschreiben die Regeln f\u00fcr die Verwendung von Schnittstellen einer Komponente durch die anderen Komponenten. (s.\u00a0PDF<\/a>, Abb. 1)<\/p>\n Im Beispiel in Abbildung 1 darf Komponente K11 auf Schnittstellen der Komponenten K03 und K10 zugreifen. K05 darf aber nicht auf K03 direkt zugreifen.<\/p>\n Eine nicht zur Implementierung passende Architekturbeschreibung f\u00fchrt zu folgenden Effekten:<\/p>\n Es zahlt sich also aus, die Architektur und die Implementierung zueinander passend zu halten. \u00dcbrigens hei\u00dft dies nicht, dass eine einmal erzeugte Architektur sklavisch eingehalten wird. Es kann durchaus vorkommen, dass die Idee hinter der Architektur sich \u00e4ndert und die Implementierung zu der ge\u00e4nderten Idee passt, aber vergessen wird, die Architekturbeschreibung entsprechend anzupassen. Dann ist die L\u00f6sung, die Architekturbeschreibung zu korrigieren. Man muss allerdings erkennen k\u00f6nnen, dass Implementierung und Architekturbeschreibung divergieren.<\/p>\n Die Software hat einen Umfang von \u00fcber 100 Modulen erreicht und w\u00e4chst weiter, wir stehen also vor einem Mengenproblem. Ein manueller Prozess zur Pr\u00fcfung ist immer fehlerbehaftet und zeitintensiv. Jede \u00c4nderung an der Implementierung oder an der Architekturbeschreibung erfordert eine wiederholte Pr\u00fcfung. Der manuell notwendige Aufwand ist schlicht nicht zu leisten.<\/p>\n Durch die eingesetzte automatische Architekturpr\u00fcfung, die entwicklungsbegleitend als Teil des Builds abl\u00e4uft, bekommen wir direktes Feedback. Die Mitglieder des Projektteams werden im Sinne der Wartbarkeit „erzogen“. Verletzungen der Architektur werden immer aufgezeigt. Insgesamt ergibt sich mehr Sicherheit f\u00fcr den Entwickler: Habe ich meine Aufgabe strukturell richtig erledigt? Au\u00dferdem steigt die Transparenz f\u00fcr den Projektleiter: Liegt mein Projekt strukturell im Ziel oder sind Nacharbeiten notwendig? Die M\u00f6glichkeit menschlicher Fehler wird generell verringert.<\/p>\n Au\u00dferdem setzen wir dieselben Komponenten und Module in unterschiedlichen Anwendungen ein, so dass manuell mehr als nur eine Anwendung gepr\u00fcft werden m\u00fcsste. Durch die automatische entwicklungsbegleitende Pr\u00fcfung wird nach einer Implementierungs\u00e4nderung f\u00fcr alle Anwendungen sichergestellt, dass die Implementierung weiterhin zur Architekturbeschreibung passt.<\/p>\n Die von uns eingesetzte automatische Architekturpr\u00fcfung mit der Axivion Bauhaus Suite basierend auf hierarchischen Reflexionsmodellen [1] hat folgende Voraussetzungen:<\/p>\n Aus der Implementierung werden durch eine statische Analyse automatisch die Abh\u00e4ngigkeiten zwischen den Funktionen, Variablen, Typen, usw. abgeleitet. F\u00fcr die Pr\u00fcfung einer dieser Abh\u00e4ngigkeiten in der Implementierung gegen die Architektur gibt es drei m\u00f6gliche Resultate: Konvergenz, Absenz und Divergenz. Im Falle einer Konvergenz stimmt die gefundene Abh\u00e4ngigkeit im Code mit der Forderung der Architektur \u00fcberein. Eine Absenz liegt vor, wenn in der Architektur eine Abh\u00e4ngigkeit gefordert wird, diese in der Implementierung aber gar nicht vorliegt. Eine Divergenz schlie\u00dflich liegt vor, wenn in der Implementierung eine Abh\u00e4ngigkeit gefunden wird, die durch die Architektur nicht erlaubt wird. (s.\u00a0PDF<\/a>\u00a0Abb.2)<\/p>\n In Abbildung 2 sind drei Komponenten A, B und C dargestellt, denen jeweils eine Funktion a, b und c als Implementierung zugeordnet ist. Da A eine Beziehung zu B haben darf und a(x) die Funktion b(y) aufruft, ergibt sich eine Konvergenz. Die Beziehung von B nach C hat keine Entsprechung in der Implementierung, so dass sich eine Absenz ergibt. Der Aufruf von c(z) nach b(y) schlie\u00dflich ist eine Divergenz, da ihn die Architektur nicht erlaubt (es m\u00fcsste daf\u00fcr eine Beziehung von C nach B geben).<\/p>\n Als Versto\u00df sind Divergenzen und Absenzen zu werten. Ein Versto\u00df kann durch ein Missverst\u00e4ndnis und daraus resultierend einer Abweichung in der Implementierung begr\u00fcndet sein. Au\u00dferdem kann ein Versto\u00df aus einer in der Architekturbeschreibung nicht nachgezogen Architektur\u00e4nderung resultieren, beispielsweise wenn es zu Plan\u00e4nderung w\u00e4hrend der Entwicklung kommt: Die Implementierung passt zur Architektur, diese ist aber nicht mehr korrekt in der Architekturbeschreibung dargestellt.<\/p>\n Die gefundenen Verst\u00f6\u00dfe werden dem Entwickler im Detail in einem Web-Dashboard der Axivion Bauhaus Suite angezeigt. F\u00fcr den Projektleiter\/Manager sind \u00dcbersichten vorhanden, aus denen der Verlauf der Verst\u00f6\u00dfe und ihre absolute Anzahl w\u00e4hrend der Entwicklung ersichtlich ist. Im Dashboard werden au\u00dferdem weitere Erosionsindikatoren dargestellt, z.B. Stilverst\u00f6\u00dfe, zyklische Abh\u00e4ngigkeiten und Toter Code, so dass ein \u00dcberblick \u00fcber alle Verst\u00f6\u00dfe in der zu entwickelnden Software verf\u00fcgbar ist.<\/p>\n Ein Entwickler kann, je nach Grund f\u00fcr die gefundene Abweichung, sofort auf den Versto\u00df reagieren, z.B. indem er die Architektur nachzieht (oder einen entsprechenden Hinweis an den Architekturen gibt) oder die Implementierung so umgestaltet, wie es laut Architektur geplant war. Dadurch kommt es zu einer verst\u00e4rkten Kommunikation \u00fcber die Architektur und zu Lerneffekten. Des Weiteren erleichtern uns die aus der Architektur geforderten und nun kontrollierten Schnittstellen die Verteilung von Arbeitspaketen auf mehrere Entwickler.<\/p>\n Projektleiter und Manager haben die M\u00f6glichkeit, die Gesamtmenge an technischen Schulden in der Software zu bewerten und betriebswirtschaftliche Argumente zusammen mit den technischen Argumenten, also Schulden der Vergangenheit und gesch\u00e4tzte Aufw\u00e4nde der zuk\u00fcnftigen Entwicklung, im Blick zu behalten.<\/p>\n Wenn man codezentriert arbeitet, ergeben sich durch die neue Betonung der Architektur und damit der globalen Zusammenh\u00e4nge und der Struktur der zu entwickelnden Software ganz neue Perspektiven. Langfristige Entwicklungen werden auf diese Weise vereinfacht, da nicht jeder Arbeitsschritt eine Lekt\u00fcre des Codes erzwingt. Da Entwickler sich im Vorfeld mit der Architektur besch\u00e4ftigen, entstehen weniger Verst\u00f6\u00dfe beim Entwickeln, unm\u00f6gliche Forderungen der Architektur werden fr\u00fcher aufgedeckt und diskutiert.<\/p>\n Durch die Architekturpr\u00fcfung sind wir zu einer eher architekturbetonten Arbeitsweise \u00fcbergegangen. Es entstehen gleich beim Entwickeln weniger Abweichungen zwischen Architekturbeschreibung und Implementierung. Die Entwickler werden entlastet, da es in der Implementierungsphase weniger \u00dcberraschungen gibt. Die automatisierte und entwicklungsbegleitende Architekturpr\u00fcfung spart manuelle Arbeit, die wir ansonsten nur stichprobenhaft leisten k\u00f6nnten.<\/p>\n [1] Koschke,\u00a0 Rainer;\u00a0 Simon,\u00a0 Daniel\u00a0 (2003):\u00a0 Hierarchical\u00a0 Reflexion\u00a0 Models. In:\u00a0 WCRE 03: Proceedings of the 10th Working Conference on Reverse Engineering. S. 36-45<\/p>\n Ralph Dittmar<\/strong>\u00a0ist Softwareentwickler bei der TR-Electronic GmbH und arbeitet seit 2013 an Software-Projekten f\u00fcr Produkte mit Zertifizierung bis SIL3\/Ple. Herr Dittmar ist seit 15 Jahren Software-Entwickler im embedded-Bereich. Email: ralph.dittmar@tr-electronic.de<\/p>\n Thomas Eisenbarth<\/strong>\u00a0ist Gr\u00fcnder und Gesch\u00e4ftsf\u00fchrer der Axivion GmbH, die Analysewerkzeuge rund um das Thema Erosionsschutz von Software entwickelt und vertreibt. Herr Eisenbarth besch\u00e4ftigt sich seit \u00fcber 20 Jahren mit der Analyse von Software und der Pr\u00fcfung von Software-Architekturen. Email: eisenbarth@axivion.com<\/p>\n Beitrag als PDF-Datei herunterladen<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Architektur & Design \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Architektur\u00a0& Design \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong><\/a>\u00a0f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinf\u00fchrung<\/h2>\n
Auswirkungen einer nicht zur Implementierung passenden Architekturbeschreibung<\/h2>\n
\n
Nachteile manueller Architekturpr\u00fcfung<\/h2>\n
Funktionsweise der automatischen Architekturpr\u00fcfung<\/h2>\n
\n
Darstellung und Nutzen der Ergebnisse<\/h2>\n
Folgen der Architekturpr\u00fcfung f\u00fcr Prozesse und Ergebnisse<\/h2>\n
Fazit<\/h2>\n
Literatur<\/h2>\n
Autoren<\/h2>\n
\nArchitektur & Design – MicroConsult Trainings & Coachings<\/h2>\n
\nArchitektur & Design – Fachwissen<\/h2>\n