Autoren: Professor Dr. Rainer Koschke, Universit\u00e4t Bremen & Thomas Eisenbarth, Axivion GmbH Wenn man sehr variantenintensive Software-Produkte zu betreuen hat, bietet sich eine Entwicklung in einer sogenannten\u00a0Software-Produktlinie (SPL)<\/em>\u00a0an. Eine Produktlinie ist eine Familie von Programmen, die eine gro\u00dfe Anzahl gleicher Anforderungen erf\u00fcllt, von denen aber jedes einzelne Programm nicht genau das Gleiche tut wie die anderen \u2013 sei es weil es etwas andere funktionale Anforderungen hat oder weil es etwas andere nicht-funktionale Eigenschaften aufweist (z.B. andere Algorithmen mit unterschiedlichem Ressourcenbedarf implementiert). Manche Autoren bezeichnen SPL deshalb auch als\u00a0Software-Produktfamilien<\/em>.<\/strong><\/p>\n In der Praxis wird bei der Entwicklung eines neuen Produkts h\u00e4ufig ein Ansatz favorisiert, der ein bestehendes Produkt der Software-Produktlinie komplett kopiert und so ab\u00e4ndert und anpasst, dass das konkrete Problem gel\u00f6st wird. Diesen Ansatz nennt man „Clone-and-Own<\/em>-Vorgehen“.<\/p>\n Der Vorteil des Clone-and-Own-Vorgehens in der Praxis ist die h\u00f6here Entwicklungseffizienz. Man hat einen schnelleren Start, mehr Unabh\u00e4ngigkeit und der Ansatz ist auch recht einfach anzuwenden.<\/p>\n Die Nachteile des Clone-and-Own-Vorgehens sind jedoch betr\u00e4chtlich. Es entsteht zus\u00e4tzlicher Aufwand bei der \u00c4nderung. Weil der Code durch das Kopieren hochgradig redundant ist, m\u00fcssen f\u00fcr eine konsistente \u00c4nderung gleichartige \u00c4nderungen an vielen Stellen des Codes gemacht werden. Inkonsistente \u00c4nderungen k\u00f6nnen zu Fehlern und Integrationsproblemen f\u00fchren. Der logisch gleiche Code muss unter Umst\u00e4nden mehrfach getestet werden.<\/p>\n Der Clone-and-Own-Ansatz stellt ein kurzfristiges Denken dar. Es ist eine mangelhafte Form von Wiederverwendung, die nicht selten aus der Unkenntnis und dem Mangel an Ressourcen f\u00fcr bessere SPL-Praktiken resultiert. Der Clone-and-Own-Ansatz ist nicht selten auch ein Indiz f\u00fcr die mangelhafte F\u00fchrung von Software-Entwicklungsprojekten. Es gibt keine Infrastruktur f\u00fcr Wiederverwendung und auch keine definierten Prozesse und Rollen daf\u00fcr. Auch der Grad der Wiederwendung und ihre Wirkung auf Kosten, Entwicklungsgeschwindigkeit und Korrektheit werden nicht gemessen und somit vernachl\u00e4ssigt.<\/p>\n Der Clone-and-Own-Ansatz f\u00fchrt zu einer Menge sehr \u00e4hnlicher Implementierungen, die man alle parallel warten muss. Die Nachteile, die daraus erwachsen, m\u00fcssen kompensiert werden, um noch Herr der Lage bleiben zu k\u00f6nnen. In dieser Situation bietet sich eine Klonanalyse an, um gleiche Teile, Variationspunkte und optionale Anteile zu identifizieren. Eine Klonanalyse sucht automatisiert nach gleichen Code-Teilen. Sie kann verwendet werden, um kopierte Dateien zueinander in Beziehung zu setzen und deren Unterschiede und Gemeinsamkeiten zu quantifizieren. Folgende Funktionen f\u00fcr jeweils zwei Dateien\u00a0f<\/em>1<\/sub>\u00a0und\u00a0f<\/em>2<\/sub>\u00a0lassen sich hierzu definieren (dabei sei\u00a0tokens<\/em>\u00a0eine Funktion, die die Tokens einer Datei wiedergibt und\u00a0hash<\/em>\u00a0eine Funktion, die einen Hash-Wert f\u00fcr eine Datei \u00fcber ihre Tokens berechnet, z.B. mittels MD5; ein\u00a0Token<\/em>\u00a0ist die kleinste semantische Einheit einer Programmiersprache, wie zum Beispiel ein Schl\u00fcsselwort, ein Operator oder ein Bezeichner; die Funktion\u00a0clone<\/em>\u00a0im Folgenden liefert die Menge geklonter Code-Fragmente zwischen zwei Dateien und\u00a0parameters<\/em>\u00a0die Menge der Parameter einer Datei oder eines Code-Fragments; als Parameter werden solche Tokens betrachtet, die man eins-zu-eins substituieren kann, zum Beispiel werden im geklonten Code h\u00e4ufig Bezeichner oder Literale ausgetauscht):<\/p>\n path-identical<\/em>(f<\/em>1<\/sub>,\u00a0f<\/em>2<\/sub>): zwei Dateien haben denselben relativen Pfad und Dateinamen im Quellcode-Verzeichnis<\/p>\n t-identical<\/em>(f<\/em>1<\/sub>,\u00a0f<\/em>2<\/sub>) \u21d4\u00a0hash<\/em>(tokens<\/em>(f<\/em>1<\/sub>)) =\u00a0hash<\/em>(tokens<\/em>(f<\/em>2<\/sub>))<\/p>\n tsim<\/em>(f<\/em>1<\/sub>,\u00a0f<\/em>2<\/sub>) = |{t<\/em>|t<\/em>\u00a0\u2208\u00a0f<\/em>1<\/sub>\u00a0\u2227\u00a0f<\/em>\u00a0\u2208\u00a0clone<\/em>(f<\/em>1<\/sub>,\u00a0f<\/em>2<\/sub>)}| \/ |f<\/em>1<\/sub>|<\/p>\n psim<\/em>(f<\/em>1<\/sub>,\u00a0f<\/em>2<\/sub>) = |parameters<\/em>(f<\/em>1<\/sub>) \u2229\u00a0parameters<\/em>(f<\/em>2<\/sub>)| similar<\/em>(f<\/em>1<\/sub>,\u00a0f<\/em>2<\/sub>) \u21d4 (tsim<\/em>(f<\/em>1<\/sub>,\u00a0f<\/em>2<\/sub>) \u2265 0.7 \u2228\u00a0tsim<\/em>(f<\/em>2<\/sub>,\u00a0f<\/em>1<\/sub>) \u2265 0.7) \u2227\u00a0psim<\/em>(f<\/em>1<\/sub>,\u00a0f<\/em>2<\/sub>) \u2265 0.75<\/p>\n Die f\u00fcr die Funktion\u00a0similar<\/em>\u00a0gew\u00e4hlten Schwellenwerte wurden von uns in einer empirischen Untersuchung ermittelt.<\/p>\n Anhand dieser Funktionen l\u00e4sst sich der Code im Stammbaum der Produktlinie dateiweise in folgende Kategorien einteilen (siehe auch\u00a0Abb. 1, PDF<\/a>):<\/p>\n Je nachdem, wie sich die geklonten Produkte entwickelt haben, kann es zu sehr \u00e4hnlichen oder auch sehr un\u00e4hnlichen Variationen gekommen sein. Dadurch wird eine schrittweise Transformation in eine Produktlinie mehr oder weniger erschwert. Die Analyse dieses Gesichtspunkts kann ebenfalls durch die Klonanalyse unterst\u00fctzt werden.<\/p>\n Der zweite Schritt nach der Identifikation der Gemeinsamkeiten und Unterschiede ist die Konsolidierung der Software-Varianten. Das dabei zu l\u00f6sende Problem ist die Beseitigung der Redundanz in den Softwarevarianten. Dazu braucht man einen Katalog an Vorgehensweisen zur Konsolidierung der Varianten, beispielsweise durch eine oder mehrere der folgenden Formen von Refactorings:<\/p>\n Die Grundvoraussetzung f\u00fcr alle diese Konsolidierungsma\u00dfnahmen genauso wie f\u00fcr die Sicherstellung der konsistenten \u00c4nderung, wenn die Klone nicht beseitigt werden sollen, ist, dass Gemeinsamkeiten und Variabilit\u00e4ten zwischen Varianten auf allen Abstraktionsebenen der Software bekannt sind:<\/p>\n Auf Quellcode-Ebene k\u00f6nnen \u00e4hnliche Funktionen zweier Varianten durch folgendes Vorgehen identifiziert werden:<\/p>\n Auf der Architekurebene kann die Architektur einer Variante mit Hilfe des hypothesengetriebenen Ansatzes zur Architekturwiedergewinnung ermittelt werden, siehe [2]:<\/p>\n F\u00fcr die Produktlinienarchitektur muss dieses Vorgehen erweitert werden, um aus den individuellen Produktarchitekturen eine \u00fcbergeordnete Produktlinienarchitektur zu ermitteln. Dazu wird eine Hypothese f\u00fcr die Produktlinienarchitektur aufgestellt, die dann in der Folge mit den verschiedenen Produkten abgeglichen wird; siehe\u00a0Abb. 2 (PDF)<\/a>.<\/p>\n Im Wesentlichen werden bei diesem Prozess den Komponenten und ggf. ihren Abh\u00e4ngigkeiten in der Produktlinienarchitektur \u00fcber UML-Stereotypen Attribute wie <<optional>>, <<kernel>> und <<variant>> mitgegeben. Das Attribut <<kernel>> beschreibt Komponenten und Abh\u00e4ngigkeiten, die in allen Produkten identisch enthalten sind, <<optional>> solche, die nicht in allen auftauchen, und <<variant>> solche, die zwar in allen Produktarchitekturen auftreten, jedoch in unterschiedlicher Form.<\/p>\n In der Praxis haben wir mit dieser Herangehensweise eine Reihe von Systemen im Rahmen industrieller Fallstudien analysiert. Dabei stellten sich folgende Erkenntnisse ein:<\/p>\n Gerade im Bereich eingebetteter Systeme, die sich nicht selten durch eine Vielfalt der zugrunde liegenden Hardware auszeichnen, wird h\u00e4ufig Wiederverwendung durch Copy & Paste im gro\u00dfen Stil betrieben. Wird dies wiederholt praktiziert, f\u00fchrt dies zu einer enormen Redundanz im Code. \u00c4nderungen werden damit erschwert. In diesen F\u00e4llen kann die Redundanz wieder durch geeignete Refactorings oder andere Ma\u00dfnahmen wie die Code-Generierung beseitigt werden. Ist dies nicht m\u00f6glich oder gew\u00fcnscht, dann m\u00fcssen die negativen Folgen der Redundanz zumindest durch eine Analyse der Redundanz kompensiert werden. Mit unserem Ansatz lassen sich Redundanzen und somit Gemeinsamkeiten und Unterschiede sowohl auf Code- als auch Architekturebene identifizieren. Das damit gewonnene Wissen kann dann benutzt werden, um geeignete Ma\u00dfnahmen zu ergreifen, seien dies die Konsolidierung oder die geplante konsistente Wartung mehrerer \u00e4hnlicher Code-Teile. Dies senkt die Kosten in der Entwicklung und erh\u00f6ht die Planbarkeit und die Fehlerfreiheit.<\/p>\n [1] Koschke, Rainer; Simon, Daniel:\u00a0Hierarchical Reflexion Models<\/em>. In: Working Conference on Reverse Engineering, IEEE Computer Society Press, November 2003, S. 36\u201345<\/p>\n [2] R. Koschke, P. Frenzel, A. Breu, K. Angstmann.\u00a0Extending the reflexion method for consolidating software variants into product lines<\/em>. Software Quality Journal December 2009; 17(4):331\u2013366.<\/p>\n 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 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>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2016<\/h3>\n
\n\/ |parameters<\/em>(f<\/em>1<\/sub>) \u222a\u00a0parameters<\/em>(f<\/em>2<\/sub>)|<\/p>\n\n
\n
\n
\n
\n
\n
Fazit<\/h2>\n
Quellen<\/h2>\n
\nArchitektur – MicroConsult Trainings & Coachings<\/h2>\n
\nArchitektur\u00a0– Fachwissen<\/h2>\n