Die Projekterfahrung zeigt, dass wichtige Aufgaben am effektivsten umgesetzt werden, wenn die Verantwortung dafür eindeutig definiert ist. Ein Softwarearchitekt veranlasst und steuert alle fachlichen Massnahmen zur Entwicklung einer Softwarearchitektur und trifft die fachlichen Entscheidungen. In kleineren Firmen wird die Rolle des Softwarearchitekten oft von wechselnden Personen besetzt, die diese Rolle durchaus mit anderen Rollen, wie der des Projektleiters oder Entwicklers, kombinieren. In grösseren Firmen und Projektteams ist die Rolle einem oder mehreren Mitarbeitern fest zugeordnet. Erfolgreiche Softwarearchitekten sollten neben ihrem fachlichen Wissen über soziale Kompetenzen verfügen. Softskills wie offene Kommunikation, Konfliktmanagement und Team-Building helfen, ein Embedded-Softwareprojekt termin- und budgetgerecht zum Abschluss zu bringen.
Mehr Flexibilität durch Softwareschichten
Architekturen, ob Haus oder Software, werden durch funktionale und nichtfunktionale Anforderungen bestimmt. Funktionale Anforderungen beschreiben, was genau das Produkt für den Nutzer tun soll. So wie ein Bad dem Benutzer die Möglichkeit bietet, zu duschen, zu baden und sich die Hände zu waschen. Nichtfunktionale 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 nichtfunktionale Anforderungen. Die Liste ist beliebig erweiterbar. Weil Software in der Regel in ihrem Lebenszyklus regelmässig und oft erheblich angepasst werden muss, spielt auch die Flexibilität bzw. Änderbarkeit eine sehr grosse Rolle. Als nichtfunktionale Anforderung wirkt sie sich mitunter stärker auf das Architekturdesign aus als die bekannten konkreten Funktionen. Mit der Einführung von Softwareschichten ist eine Softwarearchitektur möglich, die zu einem hohen Grad eine Entkopplung zwischen hardwarenaher Software und dem Rest der Software erlaubt.
Softwarearchitekturprinzipien entwickeln und nutzen
Setzen Sie einen genauen Style Guide für die Softwarearchitektur auf und entwickeln Sie diesen evolutionär weiter. Solch ein Style Guide enthält grundlegende Regeln (Prinzipien), die man bei der Softwarearchitekturentwicklung einhalten und überprüfen sollte. Es gibt bereits viele bekannte und veröffentlichte Prinzipien, die Sie auf Ihre Embedded- und Echtzeitsoftwarearchitektur anwenden 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 Softwarearchitekturelementen. Dieses Prinzip erleichtert den Austausch und das Wiederverwenden von Softwarearchitekturelementen. 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 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.
Implementieren von Softwarearchitektur-Pattern
In der Embedded- und Echtzeitentwicklung wird oft für jedes Projekt das Rad (in der Softwarearchitektur) neu erfunden. Zwar fehlt es einerseits 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 man diese Softwarearchitektur-Patterns in die entwickelte Architektur implementiert, ist eine Prüfung angeraten, ob die Patterns die Anforderungen positiv unterstützen.
Verifizieren mit Hilfe von Anwendungsszenarien
Die Softwarearchitektur ist die Grundlage für die Verteilung der Aufgabenpakete im Projektteam und damit auch für die Softwareimplementierung. Änderungen an der Softwarearchitektur werden umso aufwendiger, je später sie im Projekt vorgenommen werden. Daher sollte die Softwarearchitektur schon in einer sehr frühen Phase der Entwicklung möglichst stabil sein. Hier sind qualitätssichernde Massnahmen wie Reviews insbesondere auch durch szenarienbasierte Verifikation wichtig. Dazu werden basierend auf den funktionalen und nichtfunktionalen Anforderungen architekturrelevante Szenarien entwickelt und mit der Architektur durchgespielt, entweder manuell oder Tool-gestützt, durch eine Ausführung oder Simulation der Softwarearchitektur.
Mit Konsistenz gegen Softwareerosion
Der Programmcode muss auch bei Änderungen und Erweiterungen die Softwarearchitektur 1:1 abbilden. Bleibt der Code nicht konsistent, kommt es zu einer «Softwareerosion»: In der Software treten vermehrt unvorhersehbare und schwer oder nicht nachvollziehbare Ereignisse ein. Um hier konsistent zu bleiben, empfiehlt es sich, aus der Softwarearchitektur und dem darunter angeordneten Softwaredesign (beispielsweise auf Basis eines UML-Modells) automatisch den Programmcode zu generieren. Je nach Tool ist hier ergänzend eine manuelle Codierung erforderlich.
Man sollte bei Änderungen im Programmcode unbedingt überprüfen, inwieweit sich dadurch die Architektur verändert und falls notwendig, die Architektur an die neuen Gegebenheiten anpassen. Diese Entscheidung trifft der Softwarearchitekt. Entweder pflegt er vor einer erneuten Programmcodegenerierung die Änderungen in das Modell ein, oder er synchronisiert den geänderten Programmcode in das Modell zurück.
Dokumentieren schafft bessere Kommunikation
Eine vollständige Dokumentation spart viel Zeit und Ressourcen im Projekt. Mit ihr lässt sich Wissen zur Softwarearchitektur konservieren und kommunizieren. Für die Dokumentation bietet sich der Standard der UML (Unified Modeling Language) 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.
Fazit
Wenn Sie eine Softwarearchitektur entwickeln wollen, die eine tragfähige Basis für eine langfristig wartungsfreundliche und erweiterbare Software darstellt, sollten Sie die oben genannten Punkte berücksichtigen. Die Rolle des Softwarearchitekten ist dabei von grundlegender Bedeutung. Er trägt wesentlich dazu bei, dass Entwickler, Projektleiter, Führungskräfte und andere Stakeholder ihre Projektziele termin- und budgetgerecht erreichen. Nur eine Architektur, die auf Basis klarer Anforderungen errichtet ist, spart schon bei der Planung, über den Bau bis hin zur Nutzung viel Geld, Zeit und Nerven.
Infoservice
MicroConsult GmbH
Charles-de-Gaulle-Straße 6, DE-81737 München
Tel. 0049 89 450 617 71, Fax 0049 89 450 617 17
