Suchen

Von der impliziten zur expliziten Software-Architektur

| Autor / Redakteur: Michael Sturm, Christian Hock * / Franz Graser

Im Bereich der Unternehmenssoftware ist das Festlegen einer Software-Architektur heutzutage Standard, doch bei der Embedded-Entwicklung wird dieser Aspekt häufig noch vernachlässigt.

Firma zum Thema

Großes Vorbild: Softwaresysteme lassen sich hinsichtlich ihrer Komplexität mit Gebäuden wie Antoni Gaudís Kirche Sagrada Familia in Barcelona vergleichen. Eine in sich schlüssige Architektur ist deshalb auch im Softwarebereich unerlässlich.
Großes Vorbild: Softwaresysteme lassen sich hinsichtlich ihrer Komplexität mit Gebäuden wie Antoni Gaudís Kirche Sagrada Familia in Barcelona vergleichen. Eine in sich schlüssige Architektur ist deshalb auch im Softwarebereich unerlässlich.
(Bild: iStockphoto /Hamish Barrie)

Eine dokumentierte Software-Architektur hat klare Vorteile: Produkte sind anpassungsfähiger und zukunftssicherer. Außerdem erleichtert das Wissen um Schnittstellen, Kommunikationsbeziehungen und Ressourcen einzelner Komponenten deren Anpassung an neue Hardwarebedingungen und Funktionsanforderungen. Nicht nur bei Neuentwicklungen, sondern auch bei Modernisierungen bestehender Embedded-Lösungen lohnt es sich, einen Software-Architekten einzubinden, um Weiterentwicklungen auf ein zukunftssicheres Fundament zu stellen.

Begründete Technologieentscheidungen treffen

Unter Software-Architektur versteht man die strukturierte Anordnung der Komponenten eines Systems mit Informationen zur Kommunikation zwischen den Komponenten sowie deren Abbildung auf Hardware- oder Softwareressourcen. Eine frühzeitige und projektbegleitende Unterstützung durch einen den einzelnen Entwicklerteams möglichst neutral gegenüberstehenden Software-Architekten ist die ideale Lösung. Eine Reihe von Aufgaben kann man dieser Instanz zuordnen, in vielen Bereichen geht es aber auch einfach um Moderation.

Eine zentrale Aufgabe der Embedded Software-Architektur ist es, nicht nur die funktionalen Anforderungen an die Software zu berücksichtigen, sondern auch nichtfunktionale Anforderungen zu erfassen, und zwar vor dem Hintergrund einer Lifecycle-Prognose. Unter diese nichtfunktionalen Anforderungen fallen so komplexe Punkte wie: Wartbarkeit, Modifizierbarkeit, Skalierbarkeit, Portierbarkeit, Konnektivität, Benutzbarkeit, Zuverlässigkeit, Sicherheit, Performance, Effizienz oder Testbarkeit.

So vorteilhaft ein eingespieltes Entwicklerteam für die Kommunikation ist, so sehr kann es auch durch die Erfahrung aus Vorgängerprojekten oder ähnlichen Projekten in seiner Lösungsfindung eingeschränkt sein. Bewährte Lösungsansätze werden dann oft unhinterfragt wiederholt. Neue, möglicherweise besser geeignete und insbesondere flexiblere Technologien bleiben unberücksichtigt.

Zusammenhänge müssen nachvollziehbar bleiben

Daher kann es zum Beispiel zu den Aufgaben eines Software-Architekturteams oder externen Beraters gehören, neue Technologien zu evaluieren und auf Eignung für Projekte zu prüfen sowie neue Toolsets zur Verfügung zu stellen. Künftig benötigte Komponenten müssen identifiziert werden, und wenn es darum geht, für einzelne Komponenten optionale Technologien vorzuschlagen, bewährt sich häufig das Einschalten eines neutralen Architekturbeauftragten.

Es geht um die Diskussion von Design-Entscheidungen, die Definition von Schnittstellen und die Entwicklung von Coding Conventions. Unter der Moderation eines Software-Architekten erfolgen diese Entscheidungen bewusster und werden besser dokumentiert. Nur so bleiben die Zusammenhänge innerhalb eines Systems auch für Entwickler nachvollziehbar, die später einmal an ihm arbeiten müssen und nichts von den impliziten Annahmen und teaminternen Gepflogenheiten seiner Schöpfer wissen.

Implizite Architekturen sind immer vorhanden

In der täglichen Praxis der Embedded-Entwicklung sieht es leider meist anders aus. Zeit- und Kostendruck verhindern oft, dass Gedanken und Arbeit in eine systematisierte Software-Architektur fließen. Hier können Softwarearchitekten auch durch die Auswahl geeigneter Methoden und Tools weiter helfen. So kann die dynamische Entwicklung heutiger Industrieprodukte mit agilen Ansätzen unterstützt werden. Auch ein strikt modellbasierter Entwicklungsansatz, also die Modularisierung mit klar definierten Schnittstellen, ist ein Mittel, um einen hohen Reifegrad zu erreichen. Die Vorteile dieses Vorgehens haben sich in vielen Projekten bei Berner & Mattner in der Entwicklung von Funktionserweiterungen gezeigt: Dank des modellbasierten Ansatzes konnten diese mit minimalem Aufwand realisiert werden – und dies insbesondere auch von ursprünglich nicht beteiligten Entwicklern.

Aber Fakt ist: Jedes Softwaresystem hat eine Architektur, auch wenn diese nicht explizit modelliert wurde. Entstehen diese Strukturen ungeplant aus der Dynamik der Komponentenentwicklung heraus, tut dies der Funktionalität der Software zunächst keinen Abbruch. Probleme treten erst später auf, wenn es um Wartung, Skalierung oder Portierung geht.

Im Nachhinein rächt sich dann zum Beispiel die Wahl einer bestimmten Programmiersprache oder einer Schnittstelle, die unter dem Zeit- und Kostendruck im Entwicklungsprozess schnell und dazu noch undokumentiert getroffen wurde. Die Kommunikation zwischen einzelnen, nicht klar getrennten Komponenten war möglicherweise nur oberflächlich gelöst, anstatt schon bei der Wahl der Technologien und Sprachen darauf zu achten, Reibungspotenziale zu minimieren.

Zu enge Abhängigkeiten von der Hardware vermeiden

Zusammenhänge verstehen: Explizite Software-Architektur trägt maßgeblich dazu bei, die Wirkungszusammenhänge komplexer Systeme anschaulich und transparent zu machen.
Zusammenhänge verstehen: Explizite Software-Architektur trägt maßgeblich dazu bei, die Wirkungszusammenhänge komplexer Systeme anschaulich und transparent zu machen.
(Bild: iStockphoto / Sirgunhik)

Wird ein Softwareprojekt nicht in Bezug auf seinen gesamten Lebenszyklus gesehen, besteht bei Embedded-Projekten auch die Gefahr, dass ungewollte Abhängigkeiten zur Entwicklungs-Hardware entstehen. Die Anpassung an neue Hardwaregenerationen kann dadurch sehr aufwändig oder gar unmöglich werden.

Eine klar strukturierte und dokumentierte Software-Architektur wird erst dann vermisst, wenn es bei der notwendigen Weiterentwicklung Fragen und Schwierigkeiten gibt. Oft sollen wesentliche Teile der Software beibehalten, aber zum Beispiel an ein neues Benutzerinterface angeschlossen werden. Manchmal ist der Controller, für den sie geschrieben wurde, nicht mehr verfügbar und sein Nachfolger ist anders aufgebaut. Funktionen müssen erweitert, zusammengeführt oder auf geänderte externe Systeme angepasst werden. Die Pflege oder Weiterentwicklung eines solchen Systems wird für den Produktverantwortlichen zu einer schwer kalkulierbaren Kostenquelle vor allem dann, wenn er nicht mehr auf den Kern des ursprünglichen Entwicklerteams zurückgreifen kann.

Hilfestellung in solchen Situation bieten Spezialisten wie Berner & Mattner, die Altsysteme analysieren, bestehende Software-Architektur nachdokumentieren und mögliche Migrations- und Änderungspfade identifizieren. Als externe Architekturberater können sie unbelastet von der Softwarehistorie untersuchen, wo in der Struktur der Software Problemfelder liegen, und Lösungen vorschlagen. Der Aufwand für Pflege und Weiterentwicklung lässt sich auf Basis einer solchen Analyse besser beurteilen.

Regeln aufstellen – und sie richtig brechen

Besonders spannend wird das Thema bei zertifizierten Embedded Systemen. Eine häufige Herausforderung ist, dass die Software oder wesentliche Teile zertifiziert sind, um einem SIL (Safety Integrity Level) zu genügen. Selbstverständlich möchte niemand erneut eine IEC 61508-Zertifizierung durchlaufen, wenn sich dies vermeiden lässt. Glücklicherweise sind oft nur einzelne relevante Teile des Systems als sicherheitskritisch eingestuft. Die Kunst des Architekturberaters ist es, die Stellen in der Software zu finden, an denen die Schnitte angesetzt werden können – und zwar zwischen den sicherheitskritischen Teilen und den Teilen und Schnittstellen, die problemlos geändert werden können.

Hierzu nutzt der Berater gängige Design-Patterns wie etwa Schichten oder „pipes and filters“. Ironischerweise muss häufig das auf diese Weise entstandene Regelwerk, die abgeleitete Architektur für das eigentliche Entwicklungsprojekt, gleich wieder gebrochen werden, eben um zertifizierte Bestandteile unverändert zu erhalten. Der große Unterschied zu den „Regelverletzungen“ aus der Entstehungszeit der ursprünglichen Software liegt aber darin, dass sie nun ausführlich dokumentiert werden.

Es wäre ein Missverständnis, Software-Architektur als ein unveränderliches Dokument zu verstehen, das man nur selten wieder in die Hand nimmt. Es sollte bei jeder Arbeit an der Software gelesen und gepflegt werden. Ohne dieses lebendige Dokument werden Architekturverstöße oft gar nicht bemerkt. Vereinbarungen zu Architektur, Coding Conventions, Schnittstellen etc. werden dadurch für den Entwickler verbindlich.

Architektur muss als Prozess verstanden werden

Der Auftraggeber erhält so ein Embedded System, dessen Pflege er in die Hände eines neuen Teams geben kann. Die nun freigewordenen Spezialisten, die es erstellt haben, können getrost an anderer Stelle eingesetzt werden.

Dabei gilt: Software-Architektur endet nie! Denn auch von den Entwicklern einzusetzende Design-Methoden wie zum Beispiel Object Oriented Analysis and Design (OOAD) haben klare Strukturen und die Trennung von Zuständigkeiten zum Ziel - das ist eindeutig Architektur!

Ergänzendes zum Thema
Fehler lassen sich verhindern

Eine klar definierte und stringente Software-Architektur hilft, die Zusammenhänge innerhalb eines Systems besser zu verstehen. Dies verhindert Fehler und senkt nicht zuletzt den Aufwand bei der eventuell nötigen „Altbausanierung“ von Embedded-Systemen.

Nachträgliche Analyse nützt

Wurde die Software-Architektur in der Embedded-Entwicklung vernachlässigt, lohnt sich angesichts der zu erwartenden langen Einsatz- und Lebenszeiten vieler Embedded-Systeme auch eine nachträgliche Analyse und Dokumentation. Andernfalls drohen möglicherweise immer wieder unkalkulierbare Verzögerungen, wenn Wartungs- oder Weiterentwicklungsarbeiten eventuell auf undokumentierte Eigenheiten des Systems stoßen.

Eine klare Software-Architektur hilft, die Zusammenhänge innerhalb eines Systems besser zu verstehen. Dies verhindert Fehler und senkt den Aufwand bei der „Altbausanierung“ von Embedded Systemen. Wurde die Software-Architektur in der Embedded-Entwicklung vernachlässigt, lohnt sich angesichts langer Einsatz- und Lebenszeiten vieler Embedded Systeme auch die nachträgliche Analyse und Dokumentation. Andernfalls drohen immer wieder unkalkulierbare Verzögerungen, wenn Wartungs- oder Weiterentwicklungsarbeiten auf undokumentierte Eigenheiten des Systems stoßen. Bei stark eingefahrenen Teams bzw. zum Wissensaufbau bietet sich hier ein externer Softwarearchitekt an.

Die meisten Fehler durch menschliches Versagen entstehen dort, wo wir nicht verstehen, woran wir „schrauben“. Eine explizite Architektur trägt maßgeblich dazu bei, die Wirkketten innerhalb komplexer Systeme transparent zu machen. Mit diesem Wissen werden erforderliche Änderungen wesentlich schneller bewertet und zuverlässig realisiert.

* Dr. Michael Sturm leitet die Abteilung Softwareprodukte im Geschäftsbereich Industry bei der Berner & Mattner Systemtechnik in München.

* Dr. Christian Hock ist verantwortlich für die strategische Ausrichtung des Geschäftsbereiches Industry bei der Berner & Mattner Systemtechnik in München.

(ID:33431410)