Der vorliegende Beitrag beschreibt ein Vorgehensmodell und die erzielten Ergebnisse im Umfeld der Bewertung von Softwarearchitekturen von Automotive Embedded Software. Softwarearchitektur stellt im Allgemeinen ein entscheidendes Instrument zur Beeinflussung nicht-funktionaler Eigenschaften (z.B. Skalierbarkeit, Erweiterbarkeit, Portierbarkeit) von Software dar, bis heute gibt es jedoch keinen geeigneten Ansatz, die Qualität solcher Architekturen objektiv und quantitativ zu ermitteln und zu bewerten. Zunächst wird ein Qualitätsmodell mit einer Vielzahl unterschiedlicher Kriterien aufgestellt, welches auf die Bedürfnisse von Automotive Embedded Software angepasst ist. Für die relevanten Kriterien werden auf dieser Basis insgesamt acht Metriken zur quantitativen Beurteilung von Automotive Softwarearchitekturen erarbeitet. Zur automatisierten Anwendung dieser Metriken ist eine Einbettung in den aktuellen Entwicklungsprozess notwendig. Diese Anpassungen und die daraus resultierende und eingesetzte Infrastruktur für den Bewertungsablauf wird ebenso vorgestellt wie der schlussendlich implementierte Softwareprototyp auf Java-Basis. Mit diesem Entwicklungswerkzeug ist eine automatisierte, schnelle, komfortable und individuell konfigurierbare Bewertung von vorhandenen Softwarearchitekturent- würfen möglich. Abgerundet wird der Beitrag durch ausgewählte Anwendungsbeispiele und den Ausblick auf die weiteren anstehenden Arbeiten in diesem Umfeld. 201 Die Entwicklung von Automotive Embedded Software steht momentan vor großen He- rausforderungen. Einerseits ist sie längst als wichtigster Schlüssel und Motor für kommende wettbewerbsentscheidende Innovationen identifiziert, andererseits muss die Entwicklung, Umsetzung und Absicherung in immer kürzeren Zeitabständen unter Einsatz von knapper werdenden (menschlichen und finanziellen) Ressourcen für gleichzeitig immer mehr Baureihen, Fahrzeugtypen und Derivate (kurz: Varianten) geschehen. Es gilt somit zwangsläufig einen unvermeidbaren Konflikt zwischen steigender Funktionali- tät, Komplexität sowie Vernetzung und wesentlichen nicht-funktionalen Anforderungen wie Skalierbarkeit, Erweiterbarkeit, Portierbarkeit und effizienter Ressourcenausnutzung so gut wie möglich zu lösen. Durch den Entwurf einer Softwarearchitektur, welcher üblicherweise sehr früh (s. Abb. 1 rechts) im Entwicklungsprozess entsteht, werden die obigen Eigenschaften der Software entscheidend - positiv wie negativ - beeinflusst. Nachträgliche Änderungen an der Architektur sind zu einem späteren Zeitpunkt nicht mehr oder nur durch enormen Aufwand durchführbar. Einem guten und reifen Architekturentwurf vor der Implementierung kommt somit eine entscheidende Bedeutung zu. In der heute gängigen Praxis bei der Entwicklung von Softwarearchitekturen stellt sich erst am Ende der Entwicklung heraus, ob und wie gut die nicht-funktionalen Anforderungen von der $Software(-architektur)$ erreicht werden. Unzulänglichkeiten können dann kaum noch korrigiert werden. Alle Entwurfsentscheidungen hängen stark von bewährten Mustern (allgemeinen oder firmenspezifischen) ab und sind auf subjektive und intuitive Entscheidungen von Experten und deren persönlicher Erfahrung angewiesen. Dieses individuelle Wissen ist in den Köpfen weniger Mitarbeiter gebunden und kann nur schwer dokumentiert oder an neue Mitarbeiter weiter gegeben werden. Sind neue Personen an der Entwicklung beteiligt, muss also aufgrund mangelnder Erfahrung bei \?Null“ angefangen werden. Gleichzeitig bedeutet die Tatsache, dass gewisse Muster oder Praktiken seit längerer Zeit angewendet werden, nicht automatisch, dass diese auch wirklich gut in Hinblick auf die spezifischen Anforderungen sind. Es bleibt unklar, wie viel Po- tential zu Verbesserungen noch besteht. Gänzlich fehlend sind also Möglichkeiten die \?Güte“ einer Softwarearchitektur zuverlässig, reproduzierbar und vor allem objektiv feststellen und mit anderen Entwürfen vergleichen zu können, um dadurch eine zielgerichtete Weiterentwicklung und iterative Evolution der Architektur zu ermöglichen. Ziel der vorliegenden Arbeit ist es einen Ansatz zu entwickeln, mit dem geeignete Kriterien zur Softwarearchitektur-Bewertung gefunden, definiert, formalisiert und quantifiziert messbar gemacht werden können, um im Anschluss als objektive Metriken automatisiert auf eine in einem definierten, noch festzulegenden Datenformat gegebene Softwarearchitektur angewendet zu werden. Bisherige Ansätze [Bo78][ED96][ISO01][Oe06] beschäftigen sich bisher ausschließlich mit der Bewertung von bereits implementierter Software und nicht mit den im Entwicklungsprozess deutlich früher zu entwerfenden Architekturen oder sie beschäftigen sich zu oberfläch mit den Möglichkeiten zur Bewertung von Softwarearchitekturen. Es werden meist nur allgemeine Kriterien, Empfehlungen und Ideen geschildert ohne objektivierte oder formalisierte Hilfsmittel anzubieten [Ab96][EHM08][Lo03][PBG07][RH06]. 202 Der hier vorgestellte Ansatz schließt diese Lücke und bietet dem Anwender erstmals ein echtes Hilfsmittel zur objektiven und quantifizierten Bewertung von Softwarearchitekturen, welches einen entscheidenden Beitrag zur Verbesserung von Softwarequalität be- züglich nicht-funktionaler Anforderungen leisten kann. Dazu werden die Kriterien aus den bestehenden Ansätzen gesammelt, kombiniert und an die speziellen Bedürfnisse der Automotive Softwareentwicklung am Beispiel von Fahrerassistenzsystemen angepasst. Für das daraus entstandene Qualitätsmodell wird untersucht, welche Kriterien besonders relevant für die Domäne und welche davon überhaupt quantitativ erfassbar sind. Die erarbeiteten Metriken werden gesamthaft und an einigen Beispielen auch im Detail vorgestellt. Darüber hinaus wird zum besseren Verständnis ebenfalls der umgebende Entwicklungsprozess als notwendige Infrastruktur sowie der implementierte Software- Prototyp, welcher eine automatisierte Anwendung der Metriken auf gegebene Softwarearchitekturen ermöglicht, präsentiert. Aktuelle Erkenntnisse aus der Anwendung der gesamten Wirkkette sowie der Ausblick auf weitere Arbeiten runden den Beitrag ab. 2 Einbettung in den Entwicklungsprozess Wichtig zum weiteren Verständnis des Bewertungsverfahrens ist die Kenntnis der Randbedingungen zu seinem Einsatz. Es wurde im Vorfeld ein Entwicklungsprozess (Abb. 1) ausgearbeitet, welcher eine hohe Durchgängigkeit, Formalismen sowie automatisierte (teilund vollautomatisierte) Übergänge zwischen Prozessschritten ermöglicht und somit als Ergänzung beziehungsweise Erweiterung der bisher in der Praxis üblichen Entwicklungsschritte eingesetzt werden kann und soll. Features / USE-Cases (Requirements Engineering) DOORS ?\%/A$-#!,0!3\&*+"8#\&B\%/8,6 Funktionsanforderungsanalyse semi-formale Empfehlungen !"#$\%!\& Kriterien \?Best Practices` $(#)!\%"\%*+,#!-#$\% 4!\%-5"6! 7,0!3\&*+"8#!3 UML Funktionsarchitektur $3-#,/3\&6,\&#! semi-formale teilautomatisiert ./0,\&*+! ./0,\&*+! 9,03"6! Kriterien erzeugt 1\%*+,#!-#\% 3-#,/3\&"\%*+,#!-#\% 3-#,/3\&"\%*+,#!-#$\% Abstrakte Softwarearchitektur regeneriert (optional) 1:\&#\%"-#! 9;<1\%*+,#!-#$\% UML 1:\&#\%"-#! 9;<1\%*+,#!-#$\% (plattform- \& partitionierungsunabh.) C/\%A3!#) formal Objektive 2!*+3,\&*+! 2!6!0\%"55! Übergang zur Variante \& vollautomatisiert Metriken 1\%*+,#!-#$\% 9/8#="\%! >!\%#!,6$30 Realisierung Plattform ?6"##8/\%5":+@30,0! 9; 1\%*+,#!-#$\% ?6"##8/\%5":+@30,0! 9;1 Daten- D$!66*/A! startet \& konfiguriert Konkrete Softwarearchitektur Modell UML (plattform- \& partitionierungsabh.) formal Modell- XML vollautomatisiert Transformation ASCET / Implementierung / Quellcode Simulink Abbildung 1: Rahmen bildendender Softwareentwicklungsprozess Details zum umgebenden Prozessrahmen (Abb. 1 links), den detaillierten Prozessschritten (Abb. 1 rechts) sowie den entwickelten Konzepten und Übergängen können [Ah08] [Ah10][APB08] entnommen werden. Für das Verständnis der vorliegenden Arbeit wesentlich sind die auf der rechten Seite der Abbildung hervorgehobenen beiden Prozessschritte. Dabei handelt es sich zum einen um die abstrakte Softwarearchitektur, eine auf einem UML Metamodell [OMG05] basierende Darstellung speziell erstellt für Automotive Softwarearchitekturen [Ah08][Ah09][APB08] und zum anderen um das Konzept der automatisierten Modelltransformation, welche die bidirektionale Überführung zwischen der UML-Darstellung und den Implementierungswerkzeugen ermöglicht. 203 Zu diesem Zweck wird als Zwischenschritt ein formales konsistenzwahrendes Datenmo- dell auf XML-Basis [W3C98], beschrieben durch ein XML-Schema, verwendet. Die Anwendung der Metriken selbst soll auf Basis dieser Datenbank erfolgen, so dass sowohl ein Top-Down-Vorgehen für in der UML erstellte Entwürfe als auch ein Bottom- Up-Vorgehen zur Bewertung und Neustrukturierung bereits bestehender Architekturen (kommend von den Implementierungs-Tools) möglich ist. Details zum Datenmodell sowie der konkreten Umsetzung und Anwendung der Metriken finden sich in Kapitel 4. 3 Qualitätsmodell und die erarbeiteten Bewertungsmetriken Bisher wurde der Begriff \?Softwarearchitektur“ bereits mehrfach verwendet. Da sowohl in der Literatur als auch im fachlichen Sprachgebrauch keine allgemeingültige Definition zu finden ist, auch wenn sich der Grundgedanke meist sehr ähnelt, soll kurz vorgestellt werden, was im Rahmen dieser Arbeit unter einer Softwarearchitektur verstanden wird. \?Eine Softwarearchitektur beschreibt die Struktur eines Softwaresystems. Diese umfasst die statischen Strukturelemente (z.B. Komponenten, Module), ihre extern sichtbaren Eigenschaften (z.B. Attribute, Methoden) sowie ihre nach außen sichtund nutzbaren Schnittstellen und Interaktionen.“ Aus dieser Definition wird klar erkennbar, welche Elemente und Informationen für eine Bewertung der Softwarearchitektur überhaupt zur Verfügung stehen. Somit sind die Grenzen der objektiven Bewertung klar absteckbar. Gleichwohl bestand im Rahmen der Untersuchungen ebenfalls die Möglichkeit bestimmte Informationen für die Darstellung (UML-Profil) und Datenablage (formales Datenmodell) zusätzlich zu fordern und als dauerhafte Erweiterung der beiden genannten Dokumentationsformen fest zu etablieren. 3.1 Das Qualitätsmodell Basis für die konkreten zu entwickelnden und zu implementierenden Metriken bildet zunächst eine Übersicht über die Gesamtheit aller grundsätzlich möglichen Qualitätskriterien. Darin sind zunächst sowohl funktionale als auch nicht-funktionale Kriterien enthalten, wobei im Folgenden der Fokus klar auf die nicht-funktionalen gelenkt werden soll. Bei der Sammlung der Kriterien konnte auf bestehende Ansätze zur Bewertung von Softwarequalität zurückgegriffen werden [Bo78][Lo03][Mc94][ISO01][Oe06][Ra93]. Ergebnis ist das in Abb. 2 dargestellte, so genannte Qualitätsmodell, welches sieben Oberkriterien mit jeweils mehreren (mit Ausnahme der Konformität) Unterkriterien enthält. Oberkriterien, von jetzt an auch als Qualitätskriterien bezeichnet, sind nicht direkt messbar sondern fassen vielmehr ein oder mehrere direkt messbare Kriterien, von jetzt an auch als Qualitätsattribute bezeichnet, zu einer Obergattung zusammen. Die obigen Ansätze schlagen die Kriterien wie erwähnt primär für den Einsatz zur Bewertung von Software vor, die Bewertung einer Softwarearchitektur kann in diesem Falle jedoch als Spezialfall einer Software-Bewertung aufgefasst werden, so dass die Kriterien grundsätzlich kompatibel sind. 204 Das hier vorgestellte Qualitätsmodell kombiniert, erweitert und ergänzt die aus den un- terschiedlichen Ansätzen entnehmbaren Kriterien und spezialisiert diese im Anschluss daran an die speziellen Bedürfnisse des vorliegenden Anwendungsfalls. Dabei handelt es sich um Softwarearchitekturen von Automotive Embedded Software, so dass eine zweifache Spezialisierung vorgenommen wird. Dies ist für alle Kriterien und Attribute notwendig, weil diese je nach Anwendungsbereich (Domäne) stark unterschiedlichen Charakter aufweisen können und somit nicht direkt miteinander vergleichbar bzw. übertragbar sind. Ein Beispiel hierfür ist die Skalierbarkeit, welche in Softwareprodukten vieler Anwendungsbereiche ein wesentliches Qualitätsmerkmal darstellt, aber aufgrund der stark unterschiedlichen Eigenarten dieser Domänen ganz unterschiedlich ausgeprägt ist. Während beispielsweise in webbasierten Datenbankanwendungen Zugriffszeiten und Datendurchsätze sich entsprechend der Skalierung der Datenbank verhalten sollten, steht im Automobilbereich das ressourceneffiziente Hinzufügen und Entfernen von Funktionalität für unterschiedliche Kundenoder Plattformausprägungen von bestimmten Funktionen/Systemen im Vordergrund, um je nach Ausprägung mit unterschiedlich leistungsstarken Plattformen (Steuergeräten) auszukommen und somit Kosten zu sparen. Die Skalierbarkeit äußert sich somit in der einfachen Entfernund Hinzufügbarkeit von Funktionalität und baut somit auf einen modularen Aufbau von Software. Solche speziellen Randbedingungen gilt es für alle Kriterien zu berücksichtigen. Konformität Funktionserfüllung Zuverlässigkeit Interoperabilität Integrität Korrektheit Sicherheit Verfügbarkeit Wiederherstellbarkeit Robustheit Effizienz Portabilität Skalierbarkeit Laufzeiteffizienz Speichereffizienz Anpassungsfähigkeit Ersetzbarkeit Installationsfähigkeit Wandlungsfähigkeit Wiederverwendbarkeit Verständlichkeit Testbarkeit Erweiterbarkeit Stabilität Änderbarkeit Allgemeingültigkeit Modularität Abbildung 2: Qualitätsmodell zur Klassifizierung und Bewertung von Softwarearchitektur Neben der Definition und Anpassung ist ein weiterer wesentlicher Schritt die Relevanz und Bedeutung der Kriterien und Attribute für die Automobildomäne zu ermitteln, um so eine Priorisierung in Hinblick auf die Entwicklung der Metriken vornehmen zu können. 205 Eine Einteilung der Qualitätskriterien kann entsprechend der drei Faktoren Einsatzbe- dingung, Produktionskosten und Entwicklungskosten vorgenommen werden (Abb. 3). Konformität Funktionserfüllung Einsatzbedingung Zuverlässigkeit Effizienz Produktionskosten Portabilität Wandlungsfähigkeit Entwicklungskosten Wiederverwendbarkeit Abbildung 3: Relevante Qualitätskriterien für den Automotive-Bereich In der BMW Group existieren bereits verschiedene Verfahren und Prozesse, um die drei Qualitätskriterien Konformität, Funktionserfüllung und Zuverlässigkeit sicherzustellen. In der vorliegenden Arbeit wird daher der Fokus zur Entwicklung von Metriken auf die zwei Schwerpunkte Produktionsund Entwicklungskosten gelegt. Eine objektive Bewertung unterschiedlicher Architekturentwürfe soll, wenn möglich, nach den Kriterien Effizienz, Wandlungsfähigkeit und Wiederverwendbarkeit vorgenommen werden. 3.2 Die objektiven Bewertungsmetriken Ziel aller Architekturmetriken ist das messbare beziehungsweise formale \?greifbar machen“ von vormals subjektiven Designentscheidungen, Architekturmustern und Best Practices. Es galt somit das subjektive und schwer zugängliche Wissen erfahrener Softwarearchitekten \?anzuzapfen“ und in eine reproduzierbare, objektive und quantifizierte Form zu überführen. Dadurch wird eine Korrelation zwischen subjektiven und objektiven Kriterien und Entwurfsmustern geschaffen. Die Basis für die Metriken waren somit intensive Fachgespräche und Diskussionen mit entsprechenden Mitarbeitern des Unternehmens. Über standardisierte Fragebögen und das Durchgehen konkreter (für alle Interviews identischer) Fallbeispiele wurde die Grundlage zur Messbarkeit geschaffen. Durch die Gespräche hat sich gezeigt, dass grundsätzlich für nahezu alle der relevanten Attribute der drei Kriterien eine Möglichkeit besteht mit Hilfe der in der Softwarearchitektur zur Verfügung stehenden Informationen eine quantitative Metrik herzuleiten. Lediglich für die Kriterien Erweiterbarkeit und Allgemeingültigkeit ließ sich zum jetzigen Zeitpunkt kein geeignetes Verfahren finden. Dies liegt in beiden Fällen daran, dass reines Strukturwissen nicht ausreichend ist, um eine zuverlässige Aussage zu treffen. Jede Architektur ist grundsätzlich erweiterbar, wie \?gut“ oder einfach allerdings eine solche Erweiterung vorgenommen werden kann, liegt ganz konkret an der Funktionalität, die hinzugefügt werden soll. Somit ist Kontextinformation, mit anderen Worten Detailwissen über mögliche künftige Erweiterungen, zwingend erforderlich. Ähnlich verhält es sich mit der Allgemeingültigkeit, die ebenso nicht ausschließlich auf Strukturinformationen fußend bewertet werden kann. 206 Die im Rahmen dieser Arbeit entwickelten, objektiven Softwarearchitektur-Metriken finden sich in Abb. 4. Auf zwei ausgewählte Metriken, Strukturverständlichkeit sowie Modularität, soll im Folgenden kurz eingegangen werden, um einen Eindruck über Um- fang und Charakter der Metriken zu vermitteln. !"#$\%!\& '(# )*+",-#!-#./$"!\%"(#0!,!#"(\&1 2-\&34(\&15+6/$1\%!$" 7++'!\&' 2$!3!#8!#9 ,!\&30-#\%!$" )"#(\%"(#8!#5"6\&34./\%!" :-(5"!$\&8!#5"6\&34./\%!" ;\&3!#0-#\%!$" )\%-4$!#0-#\%!$" )"-04"6" )=!$./!#9 14 10 207 i = aktuelle Komponente n = Anzahl aller Subkomponenten von i CCFi = Component Complexity Factor von Komponente i M1i = Strukturverständlichkeit der aktuell untersuchten Komponente i M1j = Strukturverständlichkeit von Subkomponente j Erläuterungen: Die Metrik arbeitet rekursiv über alle Hierarchieebenen hinweg. In der aktuellen Hierarchieebene wird ein Wert für die Strukturverständlichkeit des jeweiligen Strukturelements gebildet und zur Ebene darüber hochgegeben, um dort mit den Werten der übrigen Bausteine des gleichen Levels gemittelt zu einem Gesamtwert des umgebenden Strukturelements verarbeitet zu werden. Der Wertebereich dieser Metrik liegt zwischen 0 und 10. Aus Platzgründen kann an dieser Stelle leider nicht eingehender auf die Metrikanwendung eingegangen werden. Metrik zur Modularität: Idee: Eine gute Modularität zeichnet sich durch eine starke Kohäsion und schwache Kopplung aus [BC99]. Logisch zusammenhängende Softwaremodule, welche viele Informationen austauschen, sollten demnach zu einer Komponente zusammengefasst werden. Eine starke Zusammengehörigkeit und schwache äußere Abhängigkeit kann in der modellbasierten Entwicklung vor allem über das Verhältnis interner zu externer Kommunikation überprüft werden. Dies gilt für alle Strukturelemente auf beliebigen Ebenen. Metrik und Erläuterungen: Für die Modularitäts-Metrik wird kein zusätzlicher Faktor benötigt, maßgeblich ist für jeden Baustein allein das Verhältnis zwischen Botschaften, die auf derselben Hierarchieebene ausgetauscht werden, zu der Gesamtzahl aller (internen und externen) Botschaften. Zunächst ermittelt die Formel das Verhältnis zwischen interner und externer Kommunikation einer Komponente. Mit einer Gewichtsverteilung von 50:50 fließen die Mo- dularitätswerte der gegebenenfalls vorhandenen untergeordneten Komponenten - ebenso durch ein rekursives Verfahren - in die Berechnung ein. Der Wertebereich liegt zwischen 0 und 1. 208 i = aktuelle Komponente n = Anzahl aller Subkomponenten von i Messext,i = einoder ausgehende Schnittstelle der Komponente i zu einer anderen Komp. Messint,i = Schnittstelle zwischen Subkomponenten der Komponente i M7i = Modularität der aktuell untersuchten Komponente i M7j = Modularität von Subkomponente j 3.3 Anwendung der Metriken Alle Metriken können grundsätzlich unabhängig voneinander eingesetzt werden. Dies ermöglicht einen flexiblen und individuellen Einsatz je nach den Bedürfnissen des bewertenden Entwicklers. Für eine gesamthafte Architekturbewertung werden alle einzelnen Metriken berechnet und in einer bestimmten Gewichtung ins Verhältnis gesetzt. Auch diese Gewichtung ist im Tool (Kapitel 4) individuell einstellbar, als Ausgangsgewichtung wurde die in Tabelle 2 dargestellte Gewichtung vorgenommen, welche aus den subjektiven Einschätzungen der befragten Entwickler zur Wichtigkeit abgeleitet wurde. Tabelle 2: Initiale Gewichtung aller Kriterien und Attribute Kriterium Gewicht Metrik Gewicht Wandlungsfähigkeit 2 Strukturverständlichkeit