Die 7 wichtigsten Tipps für Ihre Embedded-Software-Architektur

Worauf kommt es an, wenn Sie Architekturen für Embedded-Software entwickeln? Eine Frage, die wir in unseren Seminaren ausführlich behandeln. In diesem Artikel haben wir für Sie die wichtigsten Aspekte kurz zusammengefasst. Auch wenn Sie selbst kein Software-Architekt sind, ist es wichtig, dass Sie die Bedeutung dieser Rolle im Projekt erkennen. Denn der Software-Architekt trägt wesentlich dazu bei, dass Entwickler, Projektleiter, Führungskräfte und viele andere Stakeholder ihre Projektziele erreichen.

Anforderungen sind die Basis der Architektur

Wie in allen Bereichen der Entwicklung gilt auch für die Software-Architekturentwicklung der Grundsatz: Kümmere Dich erst um das WAS und dann um das WIE. Das Was sind die Anforderungen, die an eine Software gestellt werden. Das Wie ist die konkrete Umsetzung dieser Anforderungen. Die Entwicklung der Architektur stellt einen wichtigen ersten Schritt dar, wenn es um die Transformation des Was in das Wie geht. Doch ohne Anforderungen keine Architektur.

Betrachten wir diesen Zusammenhang am besten anhand einer Analogie: Hausbau. Wer beispielsweise nicht weiß, welche Zimmer in welcher Größe für welche Nutzung erforderlich sind, wird schwerlich ein Haus planen können. Wer über den Hausbau nachdenkt, stellt schnell fest, wie sehr sich die Anforderungen der Nutzer auf die Architektur des Hauses auswirken.

Anforderungen lassen sich grundsätzlich in die Kategorien funktional und nicht-funktional unterteilen. Funktionale Anforderungen beschreiben, welche Funktionen der Nutzer erwartet. Ein Bad z.B. muss dem Benutzer die Möglichkeit bieten, zu duschen, zu baden und Hände zu waschen. Nicht-funktionale Anforderungen bestimmen, welche Eigenschaften über die reine Funktionalität hinaus erwartet werden – z.B. wenn ein Niedrigenergie-Haus gewünscht ist. Schnell wird klar, dass diese nicht-funktionale Anforderung erheblichen Einfluss auf die Architektur des Hauses haben wird.

Bei der Softwareentwicklung werden durch funktionale Anforderungen z.B. alle Anwendungsmöglichkeiten durch die User beschrieben, während die Portierbarkeit auf eine konkrete Hardware oder die Einhaltung einer Sicherheitsnorm eine nicht-funktionale Anforderung darstellt. Auch hier wird die nicht-funktionale Anforderung der Portierbarkeit die Software-Architektur erheblich beeinflussen. Architekturen, ob Haus oder Software, werden durch die funktionalen und nicht-funktionalen Anforderungen bestimmt.

Im Gegensatz zu den meisten Häusern spielen bei der Software die Flexibilität bzw. Änderbarkeit eine sehr große Rolle, weil Software in der Regel in ihrem Lebenszyklus ständig und oft erheblich angepasst werden muss. Die nicht-funktionalen Anforderungen hoher Flexibilität für künftige Funktionen wirken sich deshalb möglicherweise stärker auf das Architekturdesign aus als die derzeit bekannten konkreten Funktionen.

Fazit

Für eine tragfähige Software-Architektur ist es sehr wichtig, dass der Software-Architekt die funktionalen und nicht-funktionalen Anforderungen sorgfältig analysiert. Dabei sollte den nicht-funktionalen Anforderungen in Hinblick auf Erweiterbarkeit und Änderbarkeit besondere Aufmerksamkeit geschenkt werden. Die Konsequenz ist eine Software-Architektur, die einen hohen Grad an Entkopplung zwischen hardwarenaher Software und dem Rest der Software erreicht. Der Software-Architekt erzielt dies z.B. durch die Einführung von Softwareschichten.

Für die nachhaltige Entwicklung einer Software-Architektur empfehlen wir sechs weitere Maßnahmen, die wir im Folgenden kurz erläutern:

1. Etablieren Sie die Rolle des Software-Architekten.
2. Entwickeln und nutzen Sie Architekturprinzipien.
3. Entwickeln und nutzen Sie Architektur-Pattern.
4. Verifizieren Sie die Architektur mithilfe von Anwendungsszenarien.
5. Sichern Sie die Konsistenz von Architektur und Implementierung.
6. Dokumentieren Sie Ihre Architektur.

 

Wir beschäftigen uns zunächst mit der verantwortlichen Person.

Software-Architekt m/w

Die Projekterfahrung zeigt, dass wichtige Aufgaben am effektivsten umgesetzt werden, wenn die Verantwortung dafür eindeutig definiert ist. Deshalb empfehlen wir, die Rolle des Software-Architekten einzuführen, der alle Maßnahmen zur Entwicklung einer Software-Architektur veranlasst und steuert. In kleineren Unternehmen und Projektteams wird die Rolle des Software-Architekten oft von wechselnden Personen besetzt, die diese Rolle durchaus mit anderen Rollen, wie der des Projektleiters oder Entwicklers, kombinieren. In größeren Unternehmen und Projektteams ist die Rolle des Software-Architekten einem bzw. mehreren Mitarbeitern fest zugeordnet.

Da ihre Aufgabe häufig mit der Integration unterschiedlicher Interessen und Fachdisziplinen einhergeht, benötigen erfolgreiche Software-Architekten neben dem fachlichen Wissen auch soziale Kompetenzen. Softskills wie Kommunikation, Konfliktmanagement und Team-Building sind sehr wichtig.

Bild 1: Vom Entwickler zum Software-Architekten: Engineering-Erfahrung und Menschenkenntnis sind gefragt!

 

Der Anspruch an Qualifikation und Erfahrung sowie die große Verantwortung macht die Rolle des Software-Architekten nicht nur interessant und herausfordernd, sondern auch vom Gehalt her sehr attraktiv. Mitunter ist der Software-Architekt eine der mit am besten bezahlten Rollen in der Entwicklung.

Eine sehr wichtige Aufgabe des Software-Architekten ist es, Architekturprinzipien zu etablieren.

Software-Architekturprinzipien entwickeln und nutzen

Es ist ratsam einen Style Guide für die Software-Architektur aufzusetzen und evolutionär weiterzuentwickeln. Dieser könnte u.a. grundlegende Regeln (Prinzipien) enthalten, die bei der Software-Architekturentwicklung einzuhalten und zu überprüfen sind. Es gibt bereits viele publizierte Prinzipien, die für Embedded- und Echtzeit-Softwarearchitekturen anwendbar sind. Andere Prinzipien sind firmen- oder produktspezifisch und werden nicht veröffentlicht.

Ein Beispiel ist das Prinzip der losen Bindung oder losen Kopplung zwischen Software-Architekturelementen. Dieses Prinzip erleichtert die Austauschbarkeit und Wiederverwendbarkeit von Software-Architekturelementen. Über die Abstraktion mittels Interfacebildung ist dieses Prinzip realisierbar.

Um beispielsweise konkrete Treiber der verschiedenen Mikrocontroller austauschbar zu machen, sind eine Reihe generischer Interfaces (I_GPIO, I_PWM, I_ExternalInterrupt) und Callback-Interfaces (ICB_ExternalInterrupt) erforderlich. Diese generischen Interfaces werden individuell für jeden Mikrocontroller implementiert. Damit lässt sich die die einfache Austauschbarkeit des Mikrocontrollers softwaretechnisch gewährleisten. Mit dem CMSIS Standard (Cortex® Microcontroller Software Interface Standard) hat die Firma Arm diesem Prinzip folgend u.a. Treiber- und Betriebssystemaufrufe für Arm®-basierende Mikrocontroller standardisiert.

Die Realisierung von Prinzipien wird durch die Entwicklung und Anwendung von Patterns erleichtert.

Wenden Sie Software-Architektur-Patterns an

Gerade in der Embedded- und Echtzeitentwicklung wird das Rad (Software-Architektur) in jeder Firma und manchmal auch für jedes neue Projekt immer wieder neu erfunden. Das ist auch dem Mangel an ausreichend hochwertigen und stabilen Standards für Embedded- und Echtzeitsoftware-Architekturen zuzuschreiben. Dennoch besteht die Möglichkeit, publizierte Lösungen für wiederkehrende Herausforderungen in der Softwareentwicklung in Form von Patterns zu nutzen. Diese sind auf die individuellen Gegebenheiten anpassbar. In dem Bereich der Software-Architektur sind dies Software-Architektur-Patterns.

Ein Beispiel für ein Software-Architektur-Pattern ist das sogenannte Layer-Pattern. Es beschreibt strikte und nicht strikte Schichtenarchitekturen. Bei der nicht strikten Architektur dürfen Schichten beim Zugriff übersprungen werden; dies ist bei der strikten Schichtenarchitektur nicht erlaubt. Um das Qualitätsmerkmal Performance zu erfüllen, entscheidet sich der Software-Architekt im Embedded-Software-Bereich meist für eine nicht strikte Schichtenarchitektur.

Zusätzlich sind neben den klassischen horizontalen Schichten auch vertikale Schichten vorstellbar. Benötigt eine Softwareschicht beispielsweise den Zugriff auf alle anderen Schichten oder umgekehrt, dann kann diese Schicht vertikal angeordnet werden, um die Darstellung und Dokumentation zu vereinfachen.

Bild 2: Beispiel Layer-Pattern - nicht strikt, mit horizontalen Schichten und einer vertikalen Schicht

 

Für die Anforderung der Portierbarkeit auf verschiedene Mikrocontroller könnte sich die im Bild 2 dargestellte Softwareschichten-Architektur ergeben. Die Hardware-Driver-Schicht enthält einen Anteil für den STM32xx Mikrocontroller und einen anderen für den LPC17xx Mikrocontroller.

Bevor wir nun die mithilfe von Prinzipien und Patterns entwickelte Architektur implementieren, ist eine Prüfung angeraten, ob die Architektur die Anforderungen erfüllt.

Software-Architektur durch Szenarien verifizieren

Die Software-Architektur repräsentiert die Grundlage für die Verteilung der Aufgabenpakete im Projektteam und damit auch für die Software-Implementierung. Änderungen an der Software-Architektur werden umso aufwändiger, je später im Projekt sie vorgenommen werden. Daher sollte die Software-Architektur schon in einer sehr frühen Phase der Entwicklung möglichst stabil sein. Dies lässt sich durch qualitätssichernde Maßnahmen wie Reviews insbesondere auch durch szenarienbasierte Verifikation erreichen. Dazu werden basierend auf den funktionalen und nicht-funktionalen Anforderungen architekturrelevante Szenarien entwickelt und mit der Architektur durchgespielt (manuell oder toolgestützt durch die Ausführung oder Simulation der Software-Architektur).

Für die Portierbarkeit der Software auf verschiedene Mikrocontroller muss die Softwarearchitektur einem Szenario standhalten, in dem Mikrocontroller austauschbar sind.

Konsistenz zwischen Architektur und Implementierung sichern

Der Programmcode muss auch bei Änderungen und Erweiterungen die Software-Architektur 1:1 abbilden. Wenn diese Konsistenz nicht erhalten bleibt, kommt es zum Phänomen der Softwareerosion. In diesem Fall treten in der Software vermehrt unvorhersehbare und schwer oder nicht nachvollziehbare Ereignisse ein.

Um die Konsistenz einzuhalten, ist es besonders günstig, wenn aus der Software-Architektur und dem darunter angeordneten Softwaredesign (beispielsweise auf Basis eines UML-Modells) automatisch der Programmcode generiert werden kann. Toolabhängig kann hier ergänzend eine manuelle Codierung erforderlich sein. Wird direkt im Programmcode geändert, ist es notwendig zu prüfen, inwieweit sich dadurch die Architektur verändert. Gegebenenfalls ist die Architektur an die neuen Gegebenheiten anzupassen. Diese Entscheidung trifft der Software-Architekt. Entweder pflegt er vor einer erneuten Programmcode-Generierung die Änderungen in das Modell ein, oder er synchronisiert den geänderten Programmcode in das Modell zurück.

Bild 3: Abgleich von Architektur und Quellcode - modellbasierte Programmcode-Generierung und Rücksynchronisation
 

Wie auch immer die Architektur entsteht und sich verändert, sie muss nicht nur konsistent zum Programmcode sein, sondern auch der aktuelle Stand muss dokumentiert sein.

Dokumentieren Sie die Software-Architektur

Um das Wissen zur Software-Architektur zu konservieren sowie auch zu kommunizieren, ist ihre Dokumentation äußerst wichtig. Dazu bietet sich aktuell der Standard der UML (Unified Modeling Language) an. Dieser beschreibt grafische Notationen zur Visualisierung u.a. von Software, aufgeteilt in mehrere Diagramme.

Zur Visualisierung und Dokumentation von Softwareschichten kann z.B. das Paketdiagramm (alternativ auch das Komponentendiagramm) zum Einsatz kommen. Dass das Paket eine Softwareschicht abbildet, ist über einen <<Stereotype>> mit einer eindeutigen Benennung möglich.

Die Abhängigkeiten zwischen den Schichten lassen sich durch die Abhängigkeitsrelation (Dependency) darstellen. Realisierungen von Software-Schnittstellen über Softwareschichten hinweg lassen sich mit der Interface- bzw. Realisierungsrelation darstellen.

Der Einsatz der UML bietet zahlreiche Vorteile. Zum einen ist die Notation weitgehend vereinheitlicht. Zum anderen existieren am Markt leistungsfähige Tools von mehreren Anbietern, die zum Teil sehr preiswerte Einstiegslösungen ermöglichen. Von der Verwendung einfacher grafisch orientierter Zeichenwerkzeuge ist abzuraten, da hier die hilfreichen Prüfmechanismen und Automatismen fehlen, die professionelle UML-Tools bieten.

Bild 4: Dokumentation der Software-Architektur – Paketdiagramm zur Darstellung von Softwareschichten

Resümee

Wenn Sie eine Software-Architektur entwickeln wollen, die eine tragfähige Basis für eine langfristig wartungsfreundliche und erweiterbare Software ist, sollten Sie die folgenden Punkte berücksichtigen:

Sorgen Sie für klare Verantwortlichkeit, indem Sie die Rolle des Software-Architekten etablieren. Diese Person stellt sicher, dass geeignete Prinzipien z.B. in Form von Patterns in das Architekturdesign einfließen. Vor der Implementierung sollte die Architektur anhand relevanter Einsatzszenarien auf die voraussichtliche Praxistauglichkeit überprüft werden. Bei der Implementierung ist darauf zu achten, dass Architektur und Code immer konsistent bleiben.

Die Entwicklung der Architektur erfolgt am besten mit einem Tool, das eine weitgehend standardisierte Modellierung erlaubt und über eine möglichst automatisierte Codegenerierung die Konsistenz mit dem Programmcode sicherstellt.

Wie beim Hausbau gilt: Eine gute Architektur auf Basis klarer Anforderungen spart bei Bau, Umbau und Nutzung viel Geld, Zeit und Nerven.

MicroConsult unterstützt Sie mit Training & Coaching rund um Embedded-Software-Architekturen:

• Software-Architekturen für Embedded-Systeme und Echtzeitsysteme
• Embedded-Software-Design und Patterns mit C
• Design Patterns (nicht nur) für Embedded-Systeme
• Design Patterns mit Python

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.

Darüber hinaus besteht die Möglichkeit, das Themenfeld Embedded-Software-Architekturen auch in maßgeschneiderten Workshops zu behandeln. Sie werden auf die speziellen Bedürfnisse von Aufgaben, Projekten, Teams und Rollen zugeschnitten.

Senden Sie uns Ihre Fragen, Wünsche und Anforderungen! Zum Kontaktforumular

Autor

Dipl.-Ing. (FH) Thomas Batt ist gebürtiger Freiburger. Nach seiner Ausbildung als Radio- und Fernsehtechniker studierte er Nachrichtentechnik in Offenburg. Seit 1994 arbeitet er kontinuierlich in verschiedenen Branchen im Bereich Embedded- und Real-Time Systementwicklung. 1999 wechselt Thomas Batt zur MicroConsult GmbH. Dort verantwortet er heute als zertifizierter Trainer und Coach die Themenbereiche Systems-/Software Engineering für Embedded-/Realtime-Systeme sowie Entwicklungsprozess-Beratung.