Mit steigender Produktkomplexität und immer leistungsfähigerer Hardware erhöhen sich auch der Umfang und die Komplexität der Software von Embedded-Systemen. In vielen Produkten setzt die Software den wesentlichen Teil der Funktionalität um. Die Abteilungen, die Embedded-Software entwickeln, wachsen kontinuierlich.
Dies ist insbesondere in der Automobilindustrie zu sehen und spiegelt sich auch auf dem aktuellen Arbeitsmarkt wider. So plant Mercedes-Benz beispielsweise, ab 2030 den überwiegenden Anteil am Umsatz durch softwarebasierte Systeme zu erzielen. Es wird nicht mehr in einer „One-Man-Show“ entwickelt, sondern in großen Teams, verteilt auf unterschiedliche Standorte auf der ganzen Welt. Der Stellenwert von Embedded-Software hat sich in den vergangenen Jahren in den meisten Unternehmen, sogar im Produktbereich der Mechatronik, der Embedded-Branche drastisch erhöht. Doch dies ist erst der Anfang.
Agile Software-Entwicklungsmethoden stehen verstärkt im Rampenlicht
In agilen Softwareprojekten wird die Software-Architektur evolutionär entwickelt, unter anderem basierend auf testgetriebenen Software-Entwicklungsmethoden. Dabei herrschen zwei unterschiedliche Entwicklungsansätze vor:
Funktionsarchitektur: Das Softwaresystem wird in Funktionen beziehungsweise Features und deren Abhängigkeiten dargestellt.
Komponentenarchitektur: Entwickelt einen Grobentwurf sowie mehrere Feinentwürfe, die eine feingranulare Struktur der Software enthalten.
Software-Architektur spielt eine tragende Rolle für den Projekterfolg
Damit der Software-Architekt seiner verantwortungsvollen Tätigkeit gerecht werden kann, benötigt er fundiertes Knowhow zu folgenden maßgeblichen Aspekten:
1. Grundverständnis der Software-Architektur
Auf abstrakter Ebene stellt die Software-Architektur eine Brücke zwischen den Anforderungen und der Implementierung der Software dar. In der Software beschreibt die Architektur die grobe Struktur (nur in Ausnahmefällen auch Module und Klassen), zum Beispiel bestehend aus Software-Komponenten, Software-Schichten, Software-Subsystemen, Interfaces und deren Abhängigkeiten. Für diese Architekturelemente lassen sich aber auch ein interaktives und ein individuelles Verhalten beschreiben. Ein wesentlicher Bestandteil der Software-Architektur ist auch die Laufzeitarchitektur.
2. Die Rolle des Software-Architekten
Jeder mit dem notwendigen Knowhow kann im Unternehmen die Rolle des Software-Architekten in einem Projekt einnehmen. Doch um das Thema wirklich professionell zu betreiben, sollte man aus meiner Sicht die personengebundene Rolle bevorzugen. Abhängig von der Projektgröße sind einer oder mehrere Software-Architekten an einem Projekt beteiligt.
3. Der Chef-Architekt leitet Software-Architektenteams an
Der Software-Architekt stimmt sich mit mehreren Rollen im Projekt ab und benötigt dafür fachliches und nicht-fachliches Wissen - je mehr Erfahrung er hat, desto besser. So sollte die Rolle des Software-Architekten idealerweise nicht mit einem Absolventen direkt von der Hochschule besetzt werden. Hier sind extrovertierte, innovationsfreudige, entscheidungsfreudige und erfahrene Mitarbeiter gefragt.
Entwurfsvorgehen: so entsteht eine Software-Architektur
Das Entwurfsvorgehen beschreibt den Entstehungsprozess der Software (-Architektur). Jedes Unternehmen muss das für sich am besten geeignete Vorgehen finden und implementieren. An dieser Definition ist der Software-Architekt wesentlich beteiligt.
Basierend auf einer V-Modell-artigen Darstellung kann das Entwurfsvorgehen für die Entwicklung eines kompletten Embedded-Systems eingesetzt werden, also nicht nur für die Software-Entwicklung.
Anforderungen (WAS) und entsprechende Anforderungen (WIE)
In den Analyseaktivitäten identifizieren und dokumentieren die Analysten (real betrachtet meist auch die Architekten) der einzelnen Ebenen die entsprechenden Anforderungen (das WAS). Darauf basierend entstehen die Architekturen (das WIE). Auf den Subsystem-Architekturen aufbauend entwickelt der Software-Architekt die Software-Architektur für ein Subsystem - in Abstimmung mit den anderen Entwicklungsdomänen auf gleicher Ebene (zum Beispiel Hardware-Entwicklung).
Parallel zu den Anforderungen entwickelt das Testteam die Testfälle, um später die korrekte Umsetzung nachzuweisen. Dies erfolgt ebenfalls auf den unterschiedlichen Ebenen. „Design for Test“ und neu „Design for Safety“ sind dabei grundlegende Software-Architekturthemen.
Entwurfsbasis und Einflussfaktoren
Aus der in Bild 1 dargestellten X-Analyse (hier Software-Analyse) entstehen die Software-Anforderungen (funktional und nicht-funktional).
Während einer Einflussfaktorenanalyse entscheidet der Software-Architekt über die
Relevanz der Anforderung für die Software-Architektur
Veränderbarkeit der Anforderung in der Zukunft
Ableitung der Konsequenzen für die Software-Architektur
Teil der nicht-funktionalen Software-Anforderungen sind die Software-Qualitätsmerkmale, die die Software erbringen muss, wie zum Beispiel:
Portierbarkeit
Wartbarkeit
Zuverlässigkeit
Sicherheit
Ressourcenverbrauch
Performance
Echtzeitfähigkeit
Bei den Qualitätsmerkmalen ist zu beachten, dass manche mitläufig, andere aber auch gegenläufig sind. Stellen wir uns mit diesem Wissen die folgende Frage: Welche Anforderungen beeinflussen die Architektur mehr – funktionale oder nicht-funktionale? Richtige Antwort: die nicht-funktionalen Anforderungen! Somit bilden die Software-Anforderungen und die daraus resultierenden Einflussfaktoren neben der Subsystem-Architektur die wichtigste Entwurfsbasis für die Software-Architektur.
Kommunikation und Dokumentation
Der Software-Architekt schafft mit einer verständlichen Dokumentation der Software-Architektur für alle Stakeholder die Basis für jedes Projekt und damit eine lückenlose Nachvollziehbarkeit für alle Projektbeteiligten. Damit sichert er den Fortbestand des Unternehmens.
Die Dokumentation bildet gleichzeitig die Kommunikationsbasis, die kontinuierlich mit den Stakeholdern abzugleichen ist.
Wichtigster Stakeholder ist dabei der Software-Entwickler, der die Software-Architektur im Design verfeinert und final in der Zielprogrammiersprache implementiert. Neben dem Software-Entwickler haben weitere Rollen, wie beispielsweise das Software-Testteam, ein berechtigtes Interesse an der Software-Architektur. Nur wenn ich weiß, was gewollt ist, kann ich prüfen, ob dies auch wirklich so umgesetzt wurde.
UML (Unified Modeling Language) ist die Notation, mit der sich verschiedenste Sichten und Aspekte der Software-Architektur dokumentieren und im Design verfeinern lassen - bis hin zur automatischen Codegenerierung. Mit dem Paketdiagramm sind in Bild 2 die unterschiedlichen Software-Schichten modelliert.
Software-Entwurfsprinzipien verbessern die Softwarequalität
Unser gesamtes Leben ist bestimmt von Regeln, auch wenn manche meinen, sich nicht daran halten zu müssen. Jeder hat sicher eigene Erfahrungen mit dem Thema Corona und dem „Einhalten“ von Vorschriften und Regeln gemacht. Bestimmt haben Sie früher selbst als Kind Lego gespielt oder tun dies heute mit Ihren Kindern. Auch hier gibt es Regeln, wie die Steine zusammenpassen.
Der Software-Architekt entwickelt mit immer neuem Wissen den Styleguide der Software-Entwicklung. Darin werden die Regeln beschrieben, nach denen die Software-Architekturen entwickelt werden soll. Nicht für alle Architekturen können alle Regeln angewendet werden beziehungsweise gelten diese. Die Anwendung ist abhängig von den jeweils benötigten Anforderungen. Die Anwendung der Regeln auf eine Software-Architektur verbessert in jedem Fall die Softwarequalität.
Ein Architektur-Entwurfsprinzip ist beispielsweise das der hohen Kohäsion. Ziel hierbei ist es, zur Vermeidung von Redundanzen logisch Zusammengehöriges in einem Architekturelement zu bearbeiten und gleichartige Aufgaben nicht auf mehrere Architekturelemente zu verteilen. Inzwischen existieren Veröffentlichungen zu speziellen Entwurfsprinzipien, die für Embedded-Software-Architekturen anwendbar sind. Mit Software-Architekturpatterns kann der Software-Architekt die Entwurfsprinzipien in der Praxis umsetzen.
Architekturentwicklung und Architekturpatterns müssen Safety-Anforderungen erfüllen
Basierend auf seinem fachlichen Wissen entwickelt der Software-Architekt die Software-Architektur. Dabei greift der Architekt auf seinen Pattern-Katalog zurück. Allgemein sind Patterns bekannte, bewährte, bewertete und anpassbare Lösungen zu immer wiederkehrenden Problemstellungen (Herausforderungen). Für Safety-relevante Systeme müssen hier Aspekte wie funktionale Sicherheit und Zuverlässigkeit berücksichtigt und erfüllt werden.
Bei Systemen, die uns vollautomatisiert unterstützen sollen (denken wir an das automatisierte Fahren), sind die Aspekte Safety und Reliability maßgeblich für den Erfolg des Produktes.
Der Einsatz von Patterns kann eine Herausforderung bei der Software-Architekturentwicklung sein:
So kann eine Problemstellung zum Beispiel runde Konturenverläufe erfordern, auch wenn nur rechteckige Bausteine zur Verfügung stehen. Eine Lösung wäre, die Steine – nach dem Lego-Prinzip – jeweils um eine oder mehrere Reihen abgestuft zu setzen. Da wir nicht die erste Generation sind, die Software entwickelt, existieren heute für fast alle Bereiche der Softwareentwicklung Patterns, so auch für die Software-Architekturentwicklung.
Ein Beispiel ist hier das Software Layer Pattern (strikt oder nicht strikt). In Bild 2 ist eine nicht strikte Software-Schichtenarchitektur dargestellt. Nicht strikt bedeutet dabei, dass darin schichtübergreifende Zugriffe enthalten sind. Das ist gerade bei Embedded-Software sinnvoll, um die geforderte Performance einzuhalten. In diesem Beispiel sind neben den klassischen horizontalen Schichten auch vertikale enthalten.
Qualitätssicherung und Qualitätsbewertung
Der Software-Architekt ist für die Software-Qualität verantwortlich sowie für die Qualitätssicherung mitverantwortlich. Bevor der Software-Architekt eine Architektur entwickelt, müssen die Qualitätsmerkmale definiert sein. Der Architekt kennt den Einfluss dieser Merkmale auf seine Software-Architektur, und das Software-Testteam weiß, wie sie nachzuweisen sind. Übrigens lässt sich Qualität nicht erst am Ende der Entwicklung in ein Produkt hineintesten!
Bei der Qualität ist zu unterscheiden zwischen
interner Qualität (zum Beispiel Software-Architektur) und
externer Qualität (das sieht der Kunde).
Die Prozessqualität beeinflusst maßgeblich auch die Produktqualität. Um auch hier die Analogie zu Lego nochmals zu strapazieren – alle Legobausteine müssen so zusammengebaut sein, dass sie die Konstruktion tragen, sonst fällt diese spätestens bei zusätzlichen Erweiterungen in sich zusammen. Übertragen gilt das auch für die Software-Architektur. Sie muss sämtliche zuvor definierten Qualitätsmerkmale und Funktionalitäten erfüllen.
In der Vergangenheit musste eine Software-Architektur oft 20 Jahre und länger tragfähig bleiben. Heute wird sie ständig erweitert und verbessert. Das liegt an immer neuen Anforderungen, Vorschriften und Gesetzen. Ein Entwicklungsprozess, der dies zulässt, ist deshalb enorm wichtig für die Fortentwicklung der Produkte.
Die einfachste qualitätssichernde Maßnahme
Reviews mit anderen Architekten und Stakeholdern stellen die einfachste qualitätssichernde Maßnahme bei Entwicklung der Software-Architektur dar. Hier wird bewertet, ob die Architektur den geforderten Qualitätsmerkmalen gerecht wird oder nicht. Als Basis für ein Review eignet sich die Software-Architekturdokumentation basierend auf einem UML-Modell.
Im szenarienbasierten Review spielen die Teilnehmer mit der Architektur zuvor definierte Fälle durch. Muss eine Architektur beispielsweise portierbar in Bezug auf die Hardware sein, wird in einem Gedankenspiel die Hardware getauscht und so nachgewiesen, dass die Software-Architektur dem gerecht wird. Eine sehr umfangreiche Methode dazu hat das SEI (Software Engineering Institute der Carnegie Mellon University) entwickelt. Sie trägt die Bezeichnung ATAM (Architecture Tradeoff Analysis Method).
Andere qualitätssichernde Maßnahmen sind beispielsweise das Erstellen von Prototypen oder mathematischen Modellen, die Ausführung einer Simulation und das Ermitteln von Metriken.
Tool-Einsatz erleichtert die Entwicklung der Software-Architektur
Der Software-Architekt ist für die Toolwelt rund um die Softwareentwicklung verantwortlich oder zumindest mitverantwortlich.
Er kennt den Toolmarkt, identifiziert den Bedarf, entwickelt Toolanforderungen, evaluiert Tools und wählt sie letztendlich fachlich aus. Gibt es im Unternehmen keine Toolgruppe, ist er auch für die Toolintegration verantwortlich. Die Tools sollen allen Mitwirkenden in der Softwareentwicklung die Arbeit erleichtern. Ein wenig Egoismus schadet nicht, davon profitiert (in erster Linie) der Software-Architekt.
Toolthemen, die die Arbeit des Software-Architekten erleichtern:
Anforderungsmanagement
Versions- und Konfigurationsmanagement
Modellierung
Generierung von Dokumentation und Programmcode
Buildsysteme
Statische Analyse
Dynamische Analyse
Implementierung der Software-Architektur
Der Software-Architekt übergibt Teile oder die gesamte Architektur zur weiteren Verfeinerung (Design und Implementierung) an einen oder mehrere Software-Entwickler. Im Coding Styleguide, den der Software-Architekt zusammen mit den Software-Entwicklern verfasst, ist unter anderem ersichtlich, wie sich die Software-Architektur in der Zielprogrammiersprache widerspiegelt. Typische Zielprogrammiersprachen für die Programmierung von Embedded-Systemen sind aktuell C und C++.
Mit C++ ist die Software-Architektur sehr gut über Namespaces im Programmcode abbildbar.
Software-Architekten und Software-Entwickler müssen unbedingt dafür sorgen, dass die vorgegebene Software-Architektur während ihres gesamten Lebenszyklus erhalten bleibt und nicht „kaputt“ programmiert wird – ein auch als Software-Erosion bekannter Vorgang.
Erkennt der Software-Entwickler Änderungsbedarf an der Architektur, so laufen unbedingt alle Änderungsentscheidungen und die Architekturänderung selbst über den verantwortlichen Software-Architekten.
Je höher die Anforderungen an Safety, Security und Modularität der Produkte werden, desto wichtiger und erfolgsentscheidender wird die Funktion des Software-Architekten im gesamten Entwicklungsprozess.
