Autor: Peter Schedl, IBM Deutschland GmbH<\/p>\n
Es wird die industrieerprobte Harmony Methode zur Erstellung von Architekturen f\u00fcr embedded Produkte vorgestellt. Im Vortrag wird das Zusammenspiel von Anforderungen, funktionalen Architekturen und dem Design beschrieben. Besonderes Augenmerk liegt auf der Bedeutung permanent begleitender Verfifikation der Entwicklungsschritte<\/strong><\/p>\n Jahrelang wurde die Entwicklung von Produkten \u00fcber die Mechanik- und Elektronikkomponenten bestimmt. Die eingebettete Software hatte nur einen kleinen Anteil, der \u00fcblicherweise von einem einzigen Entwickler programmiert wurde. Entsprechend gering war auch die Bedeutung der Software, besonders im Hinblick auf die Qualit\u00e4t. Mittlerweile hat sich dies dramatisch gewandelt – die Software \u00fcbernimmt immer gr\u00f6\u00dfere Anteile der gesamten Produktfunktionalit\u00e4t und somit auch immer \u00f6fter sicherheitskritische Funktionen. Vor diesem Hintergrund bekommen auch die Techniken der Softwareentwicklung sowie die Integration in den Produktentwicklungsyzyklus eine v\u00f6llig neue Bedeutung. Typische Fragestellungen sind dann: „Wie komme ich zu einer Produkt- oder Systemarchitektur und wie stelle ich die Nachverfolgbarkeit \u00fcber die verschiedenen Ebenen sicher?“. Letzteres wird gerade bei der Entwicklung sicherheitskritischer Systeme wichtig, da die entsprechenden Standards genau dies aus gutem Grund einfordern.<\/p>\n Zum Thema der Nachverfolgbarkeit oder Traceability sei hier nur gesagt, dass es prim\u00e4r eine Frage der Werkzeugunterst\u00fctzung darstellt und es mit OSLC (Open Services for Lifecycle Collaboration) [1] einen herstellerunabh\u00e4ngigen, werkzeug\u00fcbergreifenden Standard gibt, der unter anderem auch genau dies leistet.<\/p>\n Bleibt die Frage: „Wie komme ich zu einer Architektur?“. IBM hat mit der Harmony Methodik [2] eine erprobte Vorgehensweise, die genau diese beantwortet. Harmony wird seit \u00fcber 10 Jahren in der Industrie eingesetzt und laufend angepasst. Somit kann von einer ausgereiften Vorgehensweise gesprochen werden. Harmony setzt auf modellbasierte Entwicklung und auf fr\u00fchzeitige Absicherung durch Ausf\u00fchrung der Modelle. Es besteht aus zwei Teilen, die sowohl einzeln als auch in Kombination in Projekten eingesetzt werden k\u00f6nnen. Der eine (Harmony ESW) verfolgt einen agilen Ansatz mit sehr kleinen Iterationen, welcher f\u00fcr die Softwareentwicklung gerade auch im eingebetteten Umfeld entwickelt wurde. Der andere (Harmony SE) verfolgt einen parallelisierten Ansatz mit gr\u00f6\u00dferen Iterationen, der urspr\u00fcnglich f\u00fcr System Engineering gedacht war. In Kombination ergibt sich somit eine erste Phase zur Definition einer ersten Systemarchitektur gefolgt von kleinen Iterationen innerhalb der einzelnen Dom\u00e4nen (wie z.B. Softwareentwicklung). Auch neue Methoden, wie z.B. SAFE (Scaled Agile Framework) [3], folgen einem vergleichbaren Ansatz. Es hat sich aber gezeigt, dass gerade in der Produktentwicklung, insb. vor dem Hintergrund der Entwicklung nach dem V-Modell, Harmony SE auch zur Erstellung der Softwarearchitektur verwendet wird, um anschlie\u00dfend in eine abgesicherte Implementierung zu gehen.<\/p>\n Harmony besteht aus den 3 Phasen Anforderungsanalyse, Funktionale Analyse und Design-Synthese (siehe Bild 1,\u00a0PDF-Datei<\/a>).<\/p>\n Ausgangsbasis f\u00fcr das weitere Vorgehen ist ein Anforderungsdokument, z.B. in Form eines Kunden- bzw. Auftraggeberspezifikationsdokuments. Dies wird in ein Anforderungsmanagement-Werkzeug wie DOORS zur weiteren Analyse importiert und in eine Systemspezifikation \u00fcberf\u00fchrt, und die System Use Cases werden identifiziert. Harmony verwendet als Notation neben textuellen Requirements eine sehr vereinfachte SysML-Notation mit reduziertem Umfang an Diagrammen und auch Elementen, wie beispielsweise den Use Cases. Durch den Einsatz in zahlreichen Projekten hat sich dieses Subset bew\u00e4hrt und kann als Profil im Tool eingestellt durch die reduzierte Auswahl den Einstieg erleichtern.<\/p>\n Die Use Cases sind die Ausgangsbasis f\u00fcr die Erstellung der funktionalen Architektur. Jeder Use Case wird in ein simulierbares funktionales Modell \u00fcberf\u00fchrt und die Anforderungen werden \u00fcber Modellausf\u00fchrung verifiziert. Eine zentrale Rolle spielt hierbei das Identifizieren sowie das Zusammenspiel der Systemfunktionen in Form eines Aktivit\u00e4tsdiagramms. Dieses bildet die Basis f\u00fcr alle weiteren Schritte, sei es das Ableiten von Testsequenzen f\u00fcr den sp\u00e4tren Integrationstest, die Generierung der Systemschnittstellen oder die Verifikation mittels Modellausf\u00fchrung. Beispielsweise bietet das Werkzeug Rhapsody eine gro\u00dfe Anzahl solcher Automatismen, wie das Generieren der Testsequenzen aus den Aktivit\u00e4tsdiagrammen. Das Ergebnis dieser Phase stellt eine \u00fcberpr\u00fcfte Black-Box-Sicht des Systems mit seinen Schnittstellen inkl. Nachverfolgbarkeit zu den Systemanforderungen f\u00fcr die einzelnen Use Cases dar.<\/p>\n In dieser Phase wird nun basierend auf den gefundenen Funktionen und Schnittstellen eine Architektur des Systems erstellt, und die Elemente werden entsprechend auf diese gemappt. Aufgrund der geleisteten Vorarbeit und unter Einsatz von typischen Best Practices, wie z.B. eine m\u00f6glichst geringe Zahl von Schnittstellen zwischen den Komponenten, bildet sich hier schnell eine erste Architektur, die \u00fcber die weiteren Iterationen konkretisiert wird. Je Iteration werden die Use Case Modelle in die Architektur integriert. Das Mapping erfolgt wieder automatisiert.<\/p>\n Um die Korrektheit des integrierten Modells sicherzustellen, wird es wieder ausgef\u00fchrt und die Konsistenz, vergleichbar einem Regressionstest, zur vorherigen Phase sichergestellt. Das Ergebnis dieser Phase ist eine stabile Architektur des Systems in Form eines \u00fcberpr\u00fcfbaren Modells und der verlinkten Anforderungen von der Komponenten \u00fcber die Systemspezifikation bis zur\u00fcck zu den Kundenanforderungen.<\/p>\n Verifikation der einzelnen Schritte hat eine nicht zu untersch\u00e4tzende Bedeutung – gerade in den fr\u00fchen Phasen eines Projekts, wo typischerweise die Unsicherheit noch am gr\u00f6\u00dften ist und gleichzeitig die Auswirkungen von Fehlern am dramatischsten.<\/p>\n Nat\u00fcrlich bedeutet Verfifikation Aufwand, sei es das Verlinken der Anforderungen untereinander sowie mit dem Modell, sei es \u00fcber Metriken und Reviews bis hin zur Simulation. Nicht umsonst fordern dies viele Standards, insbesondere solche zur Entwicklung sicherheitskritischer Produkte. Gerade die fr\u00fche Modellausf\u00fchrung bringt immer wieder Fehler zutage, die in sp\u00e4teren Phasen nur schwer aufzudecken und somit mit hoher Wahrscheinlichkeit, wenn \u00fcberhaupt, erst ganz am Ende der Entwicklung entdeckt w\u00fcrden.<\/p>\n Aber bereits der Einsatz innerhalb von Harmony zur automatisierten \u00dcberpr\u00fcfung der Architekturerstellung ist effizienter und in Summe mit weniger Aufwand verbunden als eine manuelle \u00dcberpr\u00fcfung.<\/p>\n [1]\u00a0 Open Services for Lifecycle Collaboration (OSLC):\u00a0open-services.net<\/a><\/p>\n [2]\u00a0 Harmony Community:\u00a0https:\/\/www.ibm.com\/developerworks\/community\/groups\/service\/html\/communityview?communityUuid=dbc39547-3619-4c31-9535-0b583a4e6190<\/a><\/p>\n [3]\u00a0 SAFE:\u00a0www.scaledagileframework.com<\/a><\/p>\n Beitrag als PDF-Datei herunterladen<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Architektur \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Architektur \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong><\/a>\u00a0f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nHerausforderung Architekturerstellung<\/h2>\n
Vorstellung der Harmony Methode<\/h2>\n
Inside Harmony: 1. Anforderungsanalyse<\/h2>\n
Inside Harmony: 2. Funktionale Analyse<\/h2>\n
\nEs hat sich gezeigt, dass Modellierungswerkzeuge dem Anwender hier viel Arbeit abnehmen k\u00f6nnen, da etliche Schritte (teil-)automatisiert werden k\u00f6nnen.<\/p>\nInside Harmony: 3. Design-Synthese<\/h2>\n
Bedeutung der Verifikation<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
\nArchitektur – MicroConsult Trainings & Coachings<\/h2>\n
\nArchitektur\u00a0– Fachwissen<\/h2>\n