Thought Leadership
Unser Alltag ist heute wie selbstverständlich von miteinander vernetzten Geräten und Systemen geprägt. Ob man mit dem Smartphone unterwegs den schnellsten Weg zum Ziel findet, auf dem Sofa mit dem Tablet die Zeitung liest oder die smarte Heizung über eine App auf dem Smartphone steuert, diese Systeme machen unser Leben komfortabler. Der Gewinn an Komfort erfordert jedoch auch strengere Security- und Safety-Anforderungen, mit denen die Entwickler solcher Systeme Schritt halten müssen. Dies gilt besonders für das autonome Fahren – hier haben schlüssige Safety- Konzepte oberste Priorität. Teil 2/2
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 bzw. 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:
Und nicht zu vergessen – die Sicht durch die Security-Brille:
Der Einsatz von Patterns kann eine Herausforderung bei der Software-Architekturentwicklung sein:
So kann eine Problemstellung z.B. 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 4 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 (z.B. 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.
Der 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-Architekt 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.
Teil 1 lesen Sie hier.
