Autoren: Martin Becker und Bo Zhang, Fraunhofer Institut f\u00fcr Experimentelles Software Engineering (IESE)<\/p>\n
Bei der erfolgreichen Realisierung von wiederverwendbaren und konfigurierbaren Softwaremodulen ist einer der wichtigsten Schritte die Auswahl von geeigneten Variabilit\u00e4tsmechanismen. Prominente Vertreter sind hier die bedingte Kompilierung mit dem Pr\u00e4prozessor, die Modulauswahl oder die Parametrierung in Verbindung mit bedingter Ausf\u00fchrung. Der Blick in den Entwicklungsalltag zeigt, dass die Mechanismen oftmals leichtfertig ausgew\u00e4hlt und willk\u00fcrlich eingesetzt werden. Die Konsequenz sind dann oftmals schlecht verst\u00e4ndliche und wartbare Software-Unget\u00fcme. Der Beitrag gibt einen \u00dcberblick \u00fcber g\u00e4ngige Variabilit\u00e4tsmechanismen, zeigt Stolperfallen und Best-Practices anhand von Praxisbeispielen auf.<\/strong><\/p>\n Der Bedarf an kundenspezifischen Software-L\u00f6sungen steigt ungebremst. Haupttreiber hinter den angebotenen Produktvarianten sind dabei in erster Linie die unterschiedlichen Kundenbed\u00fcrfnisse, der technologische Wandel, z.B. neue Mehrkern-Prozessoren, 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 Die Unterschiede in den Produktvarianten lassen sich auf unterschiedliche Arten realisierten. Man spricht in diesem Zusammenhang von Variabilit\u00e4tsmechanismen. Prominente Vertreter sind hier die bedingte Kompilierung mit dem Pr\u00e4prozessor, die Modulauswahl oder die Parametrierung in Verbindung mit bedingter Ausf\u00fchrung. Mit den Variabilit\u00e4tsmechanismen lassen sich also die variablen Produktmerkmale im Quellcode und anderen Entwicklungsartefakten (z.B. Testf\u00e4lle, Anforderungen, Design-Modelle) umsetzen.<\/p>\n Um eine wohl\u00fcberlegte Auswahl der Variabilit\u00e4tsmechanismen zu f\u00f6rdern, stellen wir in der nachfolgenden \u00dcbersicht (siehe Tab. 1) typische Variabilit\u00e4tsmechanismen vor und charakterisieren diese entlang zentraler Eigenschaften. Der Vergleich basiert auf entsprechenden \u00dcbersichten [1][2][5][6], die in der Software Product Line Engineering Community \u00fcber die letzten beiden Jahrzehnte entstanden sind.<\/p>\n Gem\u00e4\u00df unserer industriellen Erfahrung und j\u00fcngsten Studien [3][4][7][8] werden im Kontext von Embedded Software insbesondere folgende Mechanismen zur Realisierung von Software-Varianten eingesetzt:<\/p>\n Weiterhin finden sich noch folgende Mechanismen in der industriellen Praxis:<\/p>\n Bei der Auswahl von Mechanismen sollten folgende generelle Aspekte ber\u00fccksichtigt werden:<\/p>\n Die obigen Mechanismen lassen sich bez\u00fcglich ihrer Eigenschaften wie folgt charakterisieren.<\/p>\n <\/p>\n Techniken<\/p>\n<\/td>\n Bindezeit<\/p>\n<\/td>\n Granularit\u00e4t<\/p>\n<\/td>\n Explizite Variationpunkte<\/p>\n<\/td>\n Varianten Isolation<\/p>\n<\/td>\n Offene Variation<\/p>\n<\/td>\n Nicht-Code-Artefakte<\/p>\n<\/td>\n Default-Werte<\/p>\n<\/td>\n<\/tr>\n Kopieren der Artefakte, Branches im Konfigurationsmanagement<\/p>\n<\/td>\n Build time<\/p>\n<\/td>\n alle<\/p>\n<\/td>\n Implizit<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n<\/tr>\n Pr\u00e4prozessor<\/p>\n<\/td>\n Build time<\/p>\n<\/td>\n alle<\/p>\n<\/td>\n Explizit<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n<\/tr>\n bedingte Anweisungen<\/p>\n<\/td>\n Run time<\/p>\n<\/td>\n begrenzt<\/p>\n<\/td>\n Implizit<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n<\/tr>\n Funktionszeiger, Overloading, usw.<\/p>\n<\/td>\n meistens Run time<\/p>\n<\/td>\n begrenzt<\/p>\n<\/td>\n Implizit<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n<\/tr>\n Build-System<\/p>\n<\/td>\n meistens Run time<\/p>\n<\/td>\n begrenzt<\/p>\n<\/td>\n Implizit<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n nein<\/p>\n<\/td>\n<\/tr>\n Aspect Weaver<\/p>\n<\/td>\n meistens Run time<\/p>\n<\/td>\n begrenzt<\/p>\n<\/td>\n Implizit<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n<\/tr>\n Frame-Anpassung<\/p>\n<\/td>\n Build time<\/p>\n<\/td>\n alle<\/p>\n<\/td>\n Explizit<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n ja<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Tab. 1: Charakterisierung der Variabilit\u00e4tsmechanismen<\/em><\/p>\n In diesem Abschnitt wird die Verwendung der Variabilit\u00e4tsmechanismen in der Praxis n\u00e4her beleuchtet sowie deren praktische Vorteile und Herausforderungen diskutiert und entsprechende Empfehlungen gegeben.<\/p>\n Vorteile, Herausforderungen und Empfehlungen sind in der folgenden Tabelle aufgelistet.<\/p>\n Analysieren und die unn\u00f6tige Komplexit\u00e4t des #ifdef Codes aktiv vermeiden \/ reduzieren. Umbau im Falle von Wartungsproblemen.<\/td>\n<\/tr>\n Ggf. anderen Mechanismus, z.B. Bedingte Kompilierung einsetzen.<\/td>\n<\/tr>\n Generell l\u00e4sst sich sagen, dass in der Vergangenheit aufgrund der Ressourcenbeschr\u00e4nkungen vermehrt auf Bedingte Kompilierung und Modulaustausch gesetzt wurde. Im zunehmenden Ma\u00dfe wird Variabilit\u00e4t aufgrund der h\u00f6heren Flexibilit\u00e4t, neuer Gesch\u00e4ftsmodelle und des geringeren Management-Aufwandes in die Laufzeit verlagert. Dabei kommen neben Polymorphismus und Bedingter Ausf\u00fchrung vor allem auch entsprechende Lifecycle-Management-Frameworks wie beispielsweise OSGI zum Einsatz. Egal welche Mechanismen zum Einsatz kommen, achten Sie darauf, dass die Variationspunkte einfach lokalisieren lassen und sich auf die zugrunde liegenden Variabilit\u00e4ten zur\u00fcckverfolgen lassen. Damit erleichtern Sie das Varianten-\/Variabilit\u00e4tsmanagement ungemein und erm\u00f6glichen toolgest\u00fctzte Analysen und Verbesserungen.<\/p>\n Unzul\u00e4ngliche Realisierung von Software-Varianten f\u00fchrt schnell zu unn\u00f6tiger Komplexit\u00e4t und sollte nach M\u00f6glichkeit fr\u00fchzeitig vermieden werden. In diesem Beitrag haben wir einen \u00dcberblick \u00fcber g\u00e4ngige Variabilit\u00e4tsmechanismen gegeben und Stolperfallen und Best-Practices aufgezeigt. Der Beitrag ist als Orientierungshilfe gedacht.<\/p>\n [1] S. Apel, D. Batory, C. K\u00e4stner, G. Saake, „Feature-Oriented Software Product Lines“, Springer, 2013. Beitrag als PDF downloaden<\/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 Implementierung \/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 Implementierung\/\u00a0Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nVariabilit\u00e4tstreiber in eingebetteten Systemen<\/h2>\n
Variabilit\u00e4tsmechanismen im Vergleich<\/h2>\n
\n
\n
\n
\n\n
\n Mechanismus<\/td>\n \n \n \n \n \n \n \n \n \n Cloning<\/td>\n \n \n \n \n \n \n \n \n \n Bedingte Kompilierung<\/td>\n \n \n \n \n \n \n \n \n \n Bedingte Ausf\u00fchrung<\/td>\n \n \n \n \n \n \n \n \n \n Poly\u00admorphismus<\/td>\n \n \n \n \n \n \n \n \n \n Modul\u00adaustausch<\/td>\n \n \n \n \n \n \n \n \n \n Aspekt-Orientierung<\/td>\n \n \n \n \n \n \n \n \n \n Frame Technology<\/td>\n \n \n \n \n \n \n \n \n Praktische Erfahrungen mit Variabilit\u00e4tsmechanismen<\/h2>\n
\n\n
\n Mechanismen<\/td>\n Praktische Vorteile<\/td>\n Praktische Herausforderungen<\/td>\n Empfehlungen<\/td>\n<\/tr>\n \n Cloning<\/td>\n Schnelle Einf\u00fchrung mit geringem Aufwand. Unabh\u00e4ngigkeit von anderen Varianten. Gilt f\u00fcr jede Artefakt-Art und -Gr\u00f6\u00dfe.<\/td>\n Hohe (Langzeit-) Wartungsaufwand .Unvollst\u00e4ndige Ausbreitung von \u00c4nderungen und Fehlerkorrekturen, was zu niedrigerer Codequalit\u00e4t f\u00fchrt.<\/td>\n Geringer Aufwand von kurzlebigen Klonen. \u00c4nderungen sollten klar lokalisiert sein und gemanagt werden. Periodische Klon-Analyse und Refactoring auf andere Mechanismen bei Wartungsproblemen.<\/td>\n<\/tr>\n \n Bedingte Kompilierung<\/td>\n Einfach einzuf\u00fchren. Alle Granularit\u00e4ten. Explizite Variationspunkte. Keine Laufzeit-Auswirkung (Ressourcen-Bedarf).<\/td>\n #ifdef Code ist schwer zu verstehen wegen #ifdef Verschachtelung, Vermischung, Streuung usw. #ifdef Code neigt zur Erosion und ist oftmals in der Evolution schwer zu warten.<\/td>\n Namensrichtlinien erm\u00f6glichen einfache Identifikation und Analyse von Variationspunkten.<\/p>\n \n Bedingte Ausf\u00fchrung<\/td>\n Einfach einzuf\u00fchren und zu verstehen. Unterst\u00fctzt Bindung zur Laufzeit. Hohe Flexibilit\u00e4t.<\/td>\n Begrenzt auf kleine Granularit\u00e4t. Schwer zu unterscheiden zwischen der Variationslogik und Code-Funktionalit\u00e4t. Laufzeit-Overhead.<\/td>\n Erw\u00e4gen Sie, ob die Bindung zur Laufzeit zwingend notwendig ist.<\/p>\n \n Poly\u00admorphismus<\/td>\n Die Trennung von gemeinsamen und varianten Elementen. Hohe Flexibilit\u00e4t. Jede Variante Element kann in Isolation entwickeln.<\/td>\n Geringere Effizienz aufgrund der Fragmentierung der varianten Elemente. Erh\u00f6htes Risiko von Softwarefehlern.<\/td>\n Falls sich Probleme ergeben, k\u00f6nnte Modulaustausch eine Alternative sein.<\/td>\n<\/tr>\n \n Modul\u00adaustausch<\/td>\n Vorteile von Polymorphismus. Keine Laufzeit-Auswirkung<\/td>\n Variationspunkte und variante Elemente sind schwer zu identifizieren und zu verstehen.<\/td>\n Verwalten von Variationspunkten und varianten Elemente mit dedizierten Modellen mit geeigneter Werkzeugunterst\u00fctzung, z.B. Generierung der entsprechenden Makefiles.<\/td>\n<\/tr>\n \n Aspekt Orientierung<\/td>\n Vorteile von Polymorphismus. Klare Separierung der \u00c4nderungen von den Gemeinsamkeiten. Default-Support.<\/td>\n Lernaufwand . Erh\u00f6ht die Codegr\u00f6\u00dfe. Effektiver Code wird erzeugt\/modifiziert. Erfordert erneute Validierung. Niedrige Codeverst\u00e4ndlichkeit.<\/td>\n Seien Sie vorsichtig bei der Verwendung. Im Falle von negativen Auswirkungen sollten Sie auf andere Mechanismen wechseln.<\/td>\n<\/tr>\n \n Frame Technology<\/td>\n Vorteile von Polymorphismus. Keine begrenzte Granularit\u00e4t. Keine Laufzeit-Auswirkung. Explizite Variationspunkte.<\/td>\n Kaum bekannt. Erfordert spezielle Werkzeuge. Erfordert erneute Validierung.<\/td>\n Seien Sie vorsichtig bei der Verwendung. Im Falle von negativen Auswirkungen sollten Sie auf andere Mechanismen wechseln.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
\nTab. 2: Praktische Erfahrungen mit Variabilit\u00e4tsmechanismen<\/em><\/p>\nZusammenfassung<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
\n[2] F. Bachmann and P. Clements, „Variability in software product lines“, Software Engineering Institute, Pittsburgh, USA, Tech. Rep. CMU\/SEI-2005-TR-012, Sep. 2005.
\n[3] Y. Dubinsky, J. Rubin, T. Berger, S. Duszynski, M. Becker, K. Czarnecki, „An Exploratory Study of Cloning in Industrial Software Product Lines“, Proceedings of the 17th<\/sup>\u00a0European Conference on Software Maintenance and Reengineering, 2013
\n[4] S. Duszynski, „Analyzing Similarity of Cloned Software Variants using Hierarchical Set Models“, Dissertation, Fraunhofer IESE, Kaiserslautern, Germany, 2015.
\n[5] C. Gacek and M. Anastasopoulos, „Implementing product line variabilities“, SIGSOFT Softw. Eng. Notes, vol. 26, no. 3, pp. 109-117, May 2001.
\n[6] T. Patzke, „Sustainable Evolution of Product Line Infrastructure Code“, Dissertation, Fraunhofer IESE, Kaiserslautern, Germany, 2011.
\n[7] B. Zhang, M. Becker, T. Patzke, K. Sierszecki, and J. E. Savolainen, „Variability evolution and erosion in industrial product lines: a case study“, 17th International Software Product Line Conference (SPLC 2013), pp. 168\u2014177.
\n[8] B. Zhang, „VITAL – reengineering variability specifications and realizations in software product lines“, Dissertation, Fraunhofer IESE, Kaiserslautern, Germany, 2015.<\/p>\n
\nImplementierung – unsere Trainings & Coachings<\/h2>\n
\nImplementierung – Fachwissen<\/h2>\n