Wer bei einem Hausbau im Voraus nicht genau weiß, welche Zimmer er in welcher Größe für welche Nutzung braucht, wird kein funktionierendes Haus bauen können. Auch für die Entwicklung einer Software-Architektur gilt der Grundsatz: Kümmere Dich erst um das Was und dann um das Wie.
Software-Architekt etablieren
Die Projekterfahrung zeigt, dass wichtige Aufgaben am effektivsten umgesetzt werden, wenn die Verantwortung dafür eindeutig definiert ist. Ein Software-Architekt veranlasst und steuert alle fachlichen Maßnahmen zur Entwicklung einer Software-Architektur und trifft die fachlichen Entscheidungen. Erfolgreiche Software-Architekten sollten neben ihrem fachlichen Wissen über soziale Kompetenzen verfügen. Softskills wie offene Kommunikation, Konfliktmanagement und Teambuilding helfen, ein Embedded-Software-Projekt termin- und budgetgerecht zum Abschluss zu bringen.
Flexibilität durch Softwareschichten
Architekturen werden durch funktionale und nicht-funktionale Anforderungen bestimmt. Funktionale Anforderungen beschreiben, was genau das Produkt für den Nutzer tun soll. Nicht-funktionale Anforderungen bestimmen, was ein Produkt über die reine Funktionalität hinaus bieten soll. Dazu gehören Eigenschaften wie Usability, Effizienz, Performance, Wartbarkeit oder Wiederverwendbarkeit als typische nicht-funktionale Anforderungen.
Weil Software in ihrem Lebenszyklus regelmäßig und oft angepasst werden muss, spielt auch die Flexibilität beziehungsweise Änderbarkeit eine Rolle. Nicht-funktionale Anforderungen wirken sich mitunter stärker auf das Architekturdesign aus als die bekannten konkreten Funktionen. Die Einführung von Softwareschichten erlaubt es, eine Software-Architektur aufzubauen, die zu einem hohen Grad eine Entkopplung zwischen hardwarenaher Software und dem Rest der Software ermöglicht.
Software-Architekturprinzipien nutzen
Planer sollten einen genauen Style Guide für die Software-Architektur aufsetzen und diesen evolutionär weiterentwickeln. Solch ein Style Guide enthält grundlegende Regeln oder Prinzipien, die sie bei der Software-Architekturentwicklung einhalten und überprüfen sollten. Es gibt bereits viele bekannte und veröffentlichte Prinzipien, die auf Embedded- und Echtzeit-Software-Architektur angewendet werden können. Andere Prinzipien sind firmen- oder produktspezifisch und werden für gewöhnlich nicht veröffentlicht.
Ein Beispiel ist das Prinzip der losen Bindung oder losen Kopplung zwischen den Software-Architekturelementen. Dieses Prinzip erleichtert den Austausch und das Wiederverwenden von Software-Architektur-Elementen. Um beispielsweise konkrete Treiber der verschiedenen Mikrocontroller austauschbar zu machen, sind eine Reihe generischer Interfaces, wie GPIO oder ExternalInterrupt und Callback-Interfaces erforderlich.
Diese generischen Interfaces werden individuell für jeden Mikrocontroller implementiert. Damit lässt sich ein einfacher Austausch des Mikrocontrollers softwaretechnisch gewährleisten. Mit dem CMSIS-Standard (Cortex Microcontroller Software Interface Standard) hat die Firma ARM diesem Prinzip folgend unter anderem Treiber- und Betriebssystemaufrufe für ARM-basierende Mikrocontroller standardisiert.
Software-Architektur-Pattern implementieren
In der Embedded- und Echtzeitentwicklung wird oft für jedes Projekt das Rad der Software-Architektur neu erfunden. Zwar fehlt es an ausreichend hochwertigen und stabilen Standards. Dennoch besteht die Möglichkeit, publizierte Lösungen für wiederkehrende Herausforderungen in der Softwareentwicklung in Form von Patterns zu nutzen, die an die individuellen Gegebenheiten leicht anpassbar sind. Bevor ein Ingenieur diese Software-Architektur-Pattern in die entwickelte Architektur implementiert, ist eine Prüfung angeraten, ob die Pattern die Anforderungen positiv unterstützen.
Verifizieren mit Hilfe von Anwendungsszenarien
Die Software-Architektur ist 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 sie im Projekt vorgenommen werden. Daher sollte die Software-Architektur schon in einer sehr frühen Phase der Entwicklung möglichst stabil sein. Hier sind qualitätssichernde Maßnahmen wie Reviews insbesondere auch durch szenarienbasierte Verifikation wichtig. Dazu werden basierend auf den funktionalen und nicht-funktionalen Anforderungen architekturrelevante Szenarien entwickelt und mit der Architektur durchgespielt, entweder manuell oder toolgestützt, durch eine Ausführung oder Simulation der Software-Architektur.
Mit Konsistenz gegen Softwareerosion
Der Programmcode muss auch bei Änderungen und Erweiterungen die Software-Architektur 1:1 abbilden. Bleibt der Code nicht konsistent, kommt es zu einer sogenannten Softwareerosion: In der Software treten vermehrt unvorhersehbare und schwer oder nicht nachvollziehbare Ereignisse ein. Um hier konsistent zu bleiben, empfiehlt es sich, aus der Software-Architektur und dem darunter angeordneten Softwaredesign, beispielsweise auf Basis eines UML-Modells (Unified Modeling Language), automatisch den Programmcode zu generieren. Je nach Tool ist hier ergänzend eine manuelle Codierung erforderlich. Bei Änderungen im Programmcode ist unbedingt zu prüfen, inwieweit sich dadurch die Architektur verändert. Falls notwendig, muss die Architektur an die neuen Gegebenheiten angepasst werden.
Dokumentation schafft bessere Kommunikation
Viel Zeit und Ressourcen im Projekt spart eine vollständige Dokumentation, da sie Wissen zur Software-Architektur konservieren und kommunizieren kann. Für die Dokumentation bietet sich der Standard der UML an, der grafische Notationen zur Visualisierung zum Beispiel von Software, aufgeteilt in mehrere Diagramme, anschaulich beschreibt. Zur Visualisierung und Dokumentation von Softwareschichten kommt zum Beispiel das Paketdiagramm, alternativ auch das Komponentendiagramm, zum Einsatz. In der UML ist die Notation vereinheitlicht. Es existieren leistungsfähige Tools von unterschiedlichen Anbietern am Markt, darunter preiswerte Einstiegslösungen. Bei Zeichenwerkzeugen, die sich lediglich für Grafiken eignen, fehlen die hilfreichen Prüfmechanismen und Automatismen, die professionelle UML-Tools bieten.
Zusammenfassung
Soll eine Software-Architektur entwickelt werden, die eine tragfähige Basis für eine langfristig wartungsfreundliche und erweiterbare Software darstellt, sollten die Entwickler diese sieben Grundsätze beachten. Die Rolle des Software-Architekten ist dabei von grundlegender Bedeutung. Er trägt wesentlich dazu bei, dass sowohl Entwickler als auch Projektleiter, Führungskräfte und andere Stakeholder ihre Projektziele termin- und budgetgerecht erreichen.
