Autor: Dr. Konrad Wieland, LieberLieber Software<\/p>\n
Sowohl die zunehmende Komplexit\u00e4t als auch immer k\u00fcrzere Release-Zyklen moderner eingebetteter Softwaresysteme machen es notwendig, verschiedene Versionen parallel zu entwickeln. Dazu addiert sich die Herausforderung, dass diese Systeme in immer gr\u00f6\u00dferen und verteilten Teams entwickelt werden. Bei Verwendung eines modellgetriebenen Ansatzes m\u00fcssen solche Teams die M\u00f6glichkeit erhalten, an paralleln Versionen eines Modells effizient zu arbeiten. Bei der Generierung von Source Code werden die Vorteile von Versionierungssystemen seit Jahren erfolgreich genutzt. Die wichtigste Funktion ist hier der Vergleich und die Zusammenf\u00fchrung von verschiedenen Versionen. Herk\u00f6mmliche Ans\u00e4tze verwenden daf\u00fcr zeilen- und textbasierte Anwendungen, die jedoch bei grafischen Modellen nicht ausreichend sind. In diesem Betrag wird aufgezeigt, wie Modelle praxistauglich verglichen und zusammengef\u00fchrt werden k\u00f6nnen, um so eine effiziente Versionierung zu erm\u00f6glichen.<\/strong><\/p>\n W\u00e4hrend des gesamten Softwareentwicklungsprozesses werden die unterschiedlichsten Software-Artefakte zahlreichen Ver\u00e4nderungen unterzogen. Werkzeuge, die diese Evolution der Artefakte unterst\u00fctzen, sind unverzichtbar [2] [3]. Daher wurden und werden unter dem Begriff des Software Configuration Managements (SCM) Techniken entwickelt, die diese \u00c4nderungsprozesse unterst\u00fctzen oder gar erst erm\u00f6glichen. Versionierungssysteme (VCS) fallen in diese Gruppe und haben ihren Ursprung bereits in den 1970er Jahren.<\/p>\n Versionierungssysteme verfolgen folgende drei Ziele:<\/p>\n Bei allen drei Punkten sind der Vergleich und\/oder die Zusammenf\u00fchrung von Versionen von zentraler Bedeutung. Beim letzten Punkt wachsen die Anzahl der Anforderungen und die Komplexit\u00e4t durch die native Integration in ein Versionierungssystem. Dabei lassen sich grunds\u00e4tzlich zwei Ans\u00e4tze unterscheiden, die ich im n\u00e4chsten Absatz kurz vorstelle.<\/p>\n Beim sogenannten\u00a0pessimistischen Versionieren<\/em>\u00a0sperrt man die einzelnen Artefakte, damit sie parallel nicht ver\u00e4ndert werden k\u00f6nnen. Konflikte werden so vollst\u00e4ndig umgangen, Wartezeiten sind allerdings kaum zu vermeiden.<\/p>\n Beim\u00a0optimistischen Versionieren\u00a0<\/em>dagegen wird dasselbe Artefakt zeitgleich bzw. parallel bearbeitet (siehe Abbildung 1,\u00a0PDF<\/a>). Beide Entwickler f\u00fchren ein sogenanntes „Check Out“ durch und arbeiten parallel an einer Kopie. Bevor auch der Zweite seine \u00c4nderungen speichern kann, m\u00fcssen diese \u00c4nderungen mit den bereits \u00fcbernommenen vom ersten Entwickler zusammengef\u00fchrt werden (merge). Dieser Prozess wird in vier Schritte aufgeteilt:<\/p>\n Durch das Aufkommen der Modellierung und der modellgetriebenen Softwareentwicklung in den letzten Jahren werden Modelle nicht nur f\u00fcr Brainstorming und Analyse verwendert, sondern sind integraler Bestandteil in allen Stadien des Entwicklungsprozesses. Diese Modelle setzt man meist unter Versionskontrolle ein, sie werden von einem Entwicklerteam parallel weiterentwickelt. Da dies mit herk\u00f6mmlichen Werkzeugen ein sehr aufwendiger und m\u00fchsamer Prozess ist, wurde der Ruf der Industrie nach Werkzeugen f\u00fcr die Versionierung und parallele Entwicklung von Modellen immer lauter [1] [4].<\/p>\n Allerdings erwiesen sich die zeilen- und textbasierenden Ans\u00e4tze, die sich f\u00fcr Source Code durchgesetzt haben, als nicht ausreichend. Vielmehr erm\u00f6glicht erst ein freingranularer\u00a03-Wege-Vergleichsalgorithmus<\/em>, der die Graphenstruktur der Modelle ber\u00fccksichtigt, einen genauen Vergleich zwischen zwei Modellen. Erst dieser 3-Wege-Vergleich f\u00fcr Modelle, der die Basisversion ber\u00fccksichtigt, erlaubt es, die \u00c4nderungen der jeweiligen Modellversionen so zu berechnen, dass sie der Benutzer nachvollziehen kann. F\u00fcr jede Version ist dabei zu berechnen, welche Eigenschaft eines Modellelements sich ver\u00e4ndert hat (Update), welches Element verschoben wurde (Move), welche hinzugekommen ist (Insert), referenziert wird (Use) oder gel\u00f6scht wurde (Delete).<\/p>\n Die Berechnung und Darstellung m\u00f6glicher Konflikte zwischen zwei Versionen ist integraler Bestandteil eines Merge-Werkzeugs. Eine Kategorisierung der m\u00f6glichen Konflikte ist in Abbildung 2 (siehe\u00a0PDF<\/a>) dargestellt [5].<\/p>\n Konflikte zwischen zwei Versionen sind zur Erreichung einer konsolidierten Version aufzul\u00f6sen. Um diesen Vorgang zu automatisieren, entstanden zwar die unterschiedlichsten Strategien, jedoch ist die manuelle Aufl\u00f6sung durch einen Benutzer oft unumg\u00e4nglich. Dazu m\u00fcssen \u00c4nderungen und Konflikte allerdings f\u00fcr den Benutzer leicht verst\u00e4ndlich dargestellt werden. Da \u00c4nderungen an grafischen Modellen meist auch auf Diagramm-Ebene erfolgen, ist es hier besonders wichtig, \u00c4nderungen auch im Diagramm darzustellen. Abbildung 3 (siehe\u00a0PDF<\/a>) zeigt einen Screenshot des\u00a0LieberLieber Model Versioner<\/em>, der die berechneten Unterschiede zweier Enterprise Architect1<\/sup>\u00a0Modelle fein-granular nebeneinander auflistet und diese auch im jeweiligen Diagramm visualisiert.<\/p>\n Eine der gr\u00f6\u00dften Herausforderungen bei diesem Vorgang ist die Performance (Geschwindigkeit und Ressourcenverbrauch), wenn etwa Modelle mit vielen 100.00en Modellelementen und Konnektoren zu vergleichen sind. Gerade auch bei der Kombination mit einem Versionierungssystem wie Subversion oder Git ist daher zu gew\u00e4hrleisten, dass der Entwickler, der seine \u00c4nderungen in das Repository einchecken m\u00f6chte, nicht in seiner t\u00e4glichen Arbeit aufgehalten wird.<\/p>\n Dar\u00fcber hinaus ist auf die Korrektheit des Modells bei der Zusammenf\u00fchrung paralleler \u00c4nderungen zu achten, damit es bei diesem komplexen Vorgang nicht zu Verf\u00e4lschungen kommt. Unter allen Umst\u00e4nden ist zu vermeiden, dass sich das Modell nach der Zusammenf\u00fchrung im Modellierungseditor nicht mehr \u00f6ffnen l\u00e4sst. Obwohl semantische Inkonsistenzen oder optische Unsch\u00f6nheiten beim Layout zusammengef\u00fchrter Diagramme auch ein wichtiges Thema darstellen, sollten sie in diesem Stadium nicht vorrangig behandelt werden.<\/p>\n Versionierungssysteme sind heute bei der Entwicklung von Systemen oder auch Software nicht mehr wegzudenken. Jedoch reichen traditionelle zeilen- bzw. textbasierte Ans\u00e4tze nicht aus, um auch f\u00fcr Modelle eine Unterst\u00fctzung zu bieten. Vielmehr bedarf es eines Werkzeugs, das einen pr\u00e4zisen Vergleich zwischen (graphischen) Modellen zur Verf\u00fcgung stellt und Konflikte fein-granular berechnet, um verschiedene Versionen von Modellen effizient und nutzerfreundlich zu verwalten. Dar\u00fcber hinaus ist eine native Integration in bestehende Versionierungssysteme unabdingbar, um Modellierer in ihrer t\u00e4glichen Arbeit zu unterst\u00fctzen. Neben der Performance ist die nutzerfreundliche Darstellung von Diagramm\u00e4nderungen sowie die Wahrnehmung der Validit\u00e4t der Modelle ein wichtiger Bestandteil eines zeitgem\u00e4\u00dfen Modellversionierungssystems.<\/p>\n _____________________________________________<\/p>\n 1<\/sup>\u00a0Enterprise Architect ist ein Modellierungswerkzeug von SparxSystems, mit dem sich u.a. UML, SysML oder BPMN Modelle erstellen lassen. Die Integration eines VCS ist m\u00f6glich, jedoch kann auf von XML Export nur pessimistisch versioniert werden.<\/p>\n [1] L. Bendix, P. Emanuelsson: Requirements for Practical Model Merge – An Industrial Perspective. MoDELS 2009: pp.167-180, 2009.<\/p>\n [2] J. Estublier, D. Leblang, A. Hoek, R. Conradi, G. Clemm, W. Tichy, and D. Wiborg-Weber. Impact of software engineering research on the practice of software con\ufb01guration management. ACM Transactions on Software Engineering and Methodology, vol. 14, no. 4, pp. 383-430, 2005.<\/p>\n [3] Mens, Tom: A State-of-the-Art Survey on Software Merging. IEEE Transactions on Software Engineering, vol. 28, no. 5, pp. 449-462, 2002.<\/p>\n [4] K. Wieland, G. Fitzpatrick, G. Kappel, M. Seidl, M. Wimmer: „Towards an Understanding of Requirements for Model Versioning Support“; International Journal of People-Oriented Programming (IJPOP), 2; 1 \u2013 23, 2011.<\/p>\n [5] K. Wieland, P. Langer, M. Seidl, M. Wimmer, G. Kappel: „Turning Conflicts into Collaboration – Concurrent Modeling in the Early Phases of Software Development“; Computer Supported Cooperative Work: The Journal of Collaborative Computing, 22 (2013), 2-3; 181 – 240.<\/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 Modellierung \/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 Modellierung \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n\n
Pessimistisches und optimistisches Versionieren<\/h2>\n
\n
Vergleichen von Modellen<\/h2>\n
Darstellung von \u00c4nderungen und Konflikten<\/h2>\n
Zusammenfassung<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
\nModellierung – MicroConsult Trainings & Coachings<\/h2>\n
\nModellierung – Fachwissen<\/h2>\n