Autor: Martin Becker, Fraunhofer Institut f\u00fcr Experimentelles Software Engineering (IESE)<\/p>\n
Der Blick in die industrielle Praxis zeigt, dass die meisten Produkte und Dienstleistungen in mehreren Varianten angeboten werden und dass diese Variantenvielfalt steigt. Dies stellt gerade auch Firmen, die eingebettete Systeme herstellen, vor die Herausforderung, wie diese Variantenvielfalt effizient und effektiv beherrscht werden kann. Neben ad-hoc Ans\u00e4tzen, wie dem Klonen existierender L\u00f6sungen, werden dabei h\u00e4ufig auch strategischere Ans\u00e4tze, wie Plattformen, Bauk\u00e4sten oder Produktlinien verfolgt. Eine angemessene Produktstrukturierung ist beim Umgang mit varianten-reichen System von gr\u00f6\u00dfter Wichtigkeit und bringt weitreichende Konsequenzen mit sich. \u00a0Doch wodurch zeichnen sich gute Produktstrukturen aus? Gibt es Prinzipien und Muster, die sich auf der Architektur-, Design-, und Implementierungsebene bew\u00e4hrt haben? Wie machen es andere? Mit diesen Fragen besch\u00e4ftigt sich dieser Beitrag.<\/strong><\/p>\n Bevor man sich mit der Optimierung der Produktstruktur besch\u00e4ftigt, sollte zun\u00e4chst betrachtet werden, wodurch die Produktvarianten getrieben werden. Reis et al. [1] haben hierzu eine Studie zu Produktvielfalt und deren Beherrschung durchgef\u00fchrt. Anhand von 60 Studien in unterschiedlichen Fertigungs- und Dienstleistungsbereichen haben sie sowohl interne als auch externe Treiber f\u00fcr Varianten untersucht. Hauptfaktoren sind danach die unterschiedlichen Kundenbed\u00fcrfnisse, die sich \u00e4ndernde Vielfalt an technologischen Realisierungsm\u00f6glichkeiten und der Kostendruck. Diese Treiber lassen sich in der Regel nur begrenzt beeinflussen, wodurch die Vermeidung entsprechender Varianten oftmals schwer f\u00e4llt.<\/p>\n Gerade f\u00fcr den Software-Anteil der eingebetteten Systeme herrscht die Meinung vor, dass dieser schnell und kosteng\u00fcnstig an neue Gegebenheiten angepasst werden kann, was im Vergleich zur Hardware aufgrund der \u00e4u\u00dferst geringen Produktionskosten zun\u00e4chst auch richtig ist. Naheliegender weise versucht man die erforderlichen Anpassungen also in die Software zu verlagern. Dies f\u00fchrt dann im Laufe der Zeit recht schnell zur hochgradig anpassbaren, konfigurierbaren und parametrierbaren Softwarel\u00f6sungen, die immer schwerer zu warten und zu konfigurieren sind. Viele Embedded Software Entwickler haben diese Pr\u00e4prozessor- oder Makefile-H\u00f6lle in der einen oder anderen Form schon am eigenen Leib gesp\u00fcrt.<\/p>\n Am Beispiel der Evolution des recht kompakten Betriebssystems FreeRTOS zeigt sich recht gut, wie die initiale klare Produkturstruktur immer mehr durch die Einf\u00fchrungen von neuen Produktmerkmalen beeintr\u00e4chtigt wird und erodiert. Abbildung 1 (siehe\u00a0PDF<\/a>) zeigt drei Code-St\u00e4nde im Laufe der Zeit, bei denen die internen Features, die durch Pr\u00e4prozessordirektiven gesteuert werden, unterschiedlich eingef\u00e4rbt wurden. M\u00fcssen \u00c4nderungen in den bunten Bereichen durchgef\u00fchrt werden, in denen sich sehr viele Features auswirken, ist mit stark steigenden Implementierungs- und Qualit\u00e4tssicherungsaufw\u00e4nden und erh\u00f6htem Risiko von Fehlern zu rechnen.<\/p>\n Eine erste Empfehlung im Hinblick auf die Produktstrukturierung ist, dass die Variantentreiber \u2013 wenn sie nicht eliminiert werden k\u00f6nnen \u2013 doch zumindest m\u00f6glich fr\u00fchzeitig erkannt und bei der Planung ber\u00fccksichtigt werden sollten. Dann lassen sich in der Produktstruktur proaktiv geeignete Vorkehrungen treffen und die Evolution damit besser beherrschen. In der Praxis haben sich hier Scoping-Workshops bew\u00e4hrt, die von Zeit zu Zeit durchgef\u00fchrt werden, um ein einheitliches Verst\u00e4ndnis zwischen Vertrieb, Marketing und Technik aufrecht zu erhalten, welche neue Produktmerkmale zu welchen Kosten in den n\u00e4chsten Releases bereitzustellen sind. Dieses Verst\u00e4ndnis liegt oftmals nicht vor, was dann zu unn\u00f6tiger Erosion in der Produktlandschaft f\u00fchrt.<\/p>\n Generell gelten f\u00fcr die Strukturierung von variantenreichen Systemen die gleichen Architektur-Prinzipien, die auch f\u00fcr Einzelsysteme gelten. In [2] werden unter anderem folgende allgemeinen Prinzipien vorgestellt, die f\u00fcr die Softwaretechnik relevant sind: Prinzip der Abstraktion, der Strukturierung, der Bindung und Kopplung, der Hierarchisierung, und der Modularisierung. Sie f\u00fchren zu einer klareren Produktstruktur und erleichtern damit auch notwendige Anpassungen.<\/p>\n Beim Umgang mit vielen Varianten ist es zun\u00e4chst hilfreich, stets einen \u00dcberblick zu behalten, wo sich die Varianten hinsichtlich ihrer Struktur \u00e4hnlich sind und wo sie sich unterscheiden. Dies gelingt \u00fcber eine dokumentierte Referenz- oder Produktlinienarchitektur, die die Unterschiede klar aufzeigt. Dabei ist es wichtig die Stellen pr\u00e4zise zu identifizieren, wo sich \u00c4nderungen ergeben (die sogenannten Variationspunkte) und den Zusammenhang zwischen den Unterschieden und den zentralen Produktmerkmalen aufzuzeigen. Solch eine \u00dcbersicht sollte auf jeden Fall f\u00fcr den technischen Blickwinkel, d.h. aus welchen Teilen das Produkt besteht (Schlagwort Bill-Of-Material) und wie es gebaut wird, bestehen. Es ist aber auch sehr hilfreich, wenn diese \u00dcbersicht auch f\u00fcr den logischen und den funktionalen Blickwinkel vorliegt. Dies ist in der Praxis h\u00e4ufig nicht der Fall, und wird dann in der Regel mit erh\u00f6hten Entwicklungskosten im Falle der \u00c4nderung bezahlt, da die notwendigen \u00c4nderungen nicht richtig abgesch\u00e4tzt werden konnten.<\/p>\n Bei der Strukturierung des Produktes sollte darauf geachtet werden, dass der Einfluss eines variablen Merkmales auf die Struktur klar bekannt ist und die Struktur gegebenenfalls auch so optimiert ist, dass die vorab geplanten notwendigen \u00c4nderungen m\u00f6glichst einfach zu bewerkstelligen sind. Wurde zum Beispiel beim Scoping festgestellt, dass sich die erfassten Daten \u00fcber das Umfeld und damit auch die Sensorik des Embedded Systems im Laufe wahrscheinlich h\u00e4ufiger \u00e4ndern wird (dies ist in Abbildung 2 schematisch dargestellt, siehe\u00a0PDF<\/a>), dann sollte dies bei der Strukturierung dahingehend ber\u00fccksichtigt werden, dass die Produktstruktur f\u00fcr diese \u00c4nderung gezielt optimiert wird. Zum Beispiel sollten dann die Sensoranbindung und Datenverarbeitung in Module verlagert werden, die sich einfach austauschen lassen. Eine Strukturierung wo die einzelnen Aspekte der Datenerfassung und \u2013verarbeitung breit auf die Produktstruktur verteilt ist (in Abbildung 2, siehe\u00a0PDF<\/a>), w\u00fcrde dann jedes Mal zu erh\u00f6hten \u00c4nderungskosten f\u00fchren.<\/p>\n Im Hinblick auf verbesserte \u00c4nderbarkeit und damit Wartbarkeit von Quellcode haben sich die SOLID-Prinzipien, die von Robert C. Martin [3] gepr\u00e4gt wurden, als sehr hilfreich erwiesen. Diese Prinzipien lassen sich auch auf die Produktstruktur \u00fcbertragen. Das Akronym SOLID steht f\u00fcr:<\/p>\nIdentifikation von typischen Variantentreibern<\/h2>\n
Strukturierungsprinzipien<\/h2>\n