Autoren: Ingo Battis, Sennheiser electronic GmbH & Co. KG und Thomas Eisenbarth, Axivion GmbH<\/p>\n
Die Versprechungen der UML-Modellierung mit anschlie\u00dfender Codegenerierung sind signifikant h\u00f6here Wartbarkeit, Fehlerfreiheit und Flexibilit\u00e4t im Vergleich zur manuellen Codierung. In diesem Szenario \u00fcbernimmt das UML-Modell als Implementierungsmodell Aufgaben aus der Codierung. Damit muss man das UML-Modell so behandeln, als ob es die Stelle von Code einn\u00e4hme und es entsprechend vor Software-Erosion und Implementierungsfehlern sch\u00fctzen. Eine Implementierung muss immer einer Architektur folgen, die folglich nicht im Implementierungsmodell selbst enthalten sein kann. Erst dadurch kann das Modell auf verschiedene Arten von Korrektheit gepr\u00fcft werden.<\/strong><\/p>\n F\u00fcr die Entwicklung eines neuen Projekts haben wir uns entschieden, zu einem gro\u00dfen Teil auf die Modellierung mittels UML und die anschlie\u00dfende Generierung von Code aus den Modellen zu setzen. Nur in der Treiberschicht soll manuelle Codierung eingesetzt werden. Zu diesem Zweck werden das Design und die Implementierung vollst\u00e4ndig in Rhapsody durchgef\u00fchrt.<\/p>\n Au\u00dferdem pflegen wir eine Architektur, die die Blaupause f\u00fcr Design und Implementierung darstellt.<\/p>\n Im betrachteten Projekt erfolgt die Entwicklung der Software als die Erstellung einer Hierarchie von Modellen. Diese Modelle werden durch Relationen ihrer jeweiligen Elemente miteinander verbunden. Eine dieser Relationen nennen wir Verfeinerung. In unserem Beispiel gibt es die Modelle Architektur, Entwurf und Codierung. Die Modelle werden in der Hierarchie von oben nach unten immer detaillierter und dabei immer konkreter. In unserem konkreten Anwendungsfall enth\u00e4lt die Architektur die Schichten, der Entwurf betrachtet Komponenten und weitere Details innerhalb der Schichten, die Codierung schlie\u00dflich stellt konkrete Elemente der Zielsprache dar, z.B. C-Funktionen.<\/p>\n Die Elemente eines Modells werden in dem hierarchisch darunterliegenden Modell verfeinert. Die Architektur wird manuell zum Entwurf verfeinert, dieser wird in unserem Falle weitestgehend automatisiert durch einen Generator zur Implementierung implizit verfeinert.<\/p>\n In Abb. 1 (siehe\u00a0PDF<\/a>) ist als Beispiel die Verfeinerung eines UML Packages aus der Architektur (Modell\u00a0Mn<\/sub><\/em>)) in zwei UML Packages im Entwurf (Modell\u00a0Mn<\/sub><\/em>+1<\/sub>) dargestellt: Diese Verfeinerung ist sp\u00e4ter wichtig f\u00fcr die Pr\u00fcfung. Die Verfeinerung erfolgt manuell und folgt in unserem Beispiel einer Namensregel, was f\u00fcr die Nachvollziehbarkeit zwar w\u00fcnschenswert, jedoch im Allgemeinen nicht notwendig ist. Die hier beschriebene Vorgehensweise ist \u00fcbrigens unabh\u00e4ngig von den konkreten Typen der Elemente und somit auch nicht auf die UML festgelegt.<\/p>\n F\u00fcr unseren Ansatz ist es gleichg\u00fcltig, in welcher Reihenfolge die Modelle erstellt und ver\u00e4ndert werden. Die Modelle k\u00f6nnen nachtr\u00e4glich ver\u00e4ndert und erweitert werden. Es ist somit nicht notwendig, die Modelle und die Verfeinerungen streng sequentiell und top-down (analog zu eine Wasserfallmodell) durchzuf\u00fchren, eine iterativ-inkrementelle Vorgehensweise ist jederzeit m\u00f6glich. Tats\u00e4chlich nutzt die angewendete Pr\u00fcfungsmethodik die Modelle und die Verfeinerungsrelationen, jedoch kein Wissen \u00fcber Reihenfolgen im Entstehungsprozess.<\/p>\n Wenn man UML-Werkzeuge einsetzt, um die hier angesprochenen Modelle zu definieren, dann hat man das Problem, dass in UML selbst nur ein UML-Modell existiert. Diagramme dienen nur der Darstellung, haben aber ansonsten keine Auswirkungen auf die Struktur des UML-Modells.<\/p>\n Um in der Hierarchie der Modelle pr\u00fcfen zu k\u00f6nnen, ob eine korrekte Verfeinerung vorliegt, m\u00fcssen die Modelle disjunkt und \u00fcber die Verfeinerungsrelation verbunden sein. Ansonsten ist eine Pr\u00fcfung nicht m\u00f6glich. Beispiel: Nehem wir an, die gleichen UML Package-Entit\u00e4ten werden sowohl in der Architektur als auch im Entwurf genutzt.<\/p>\n In Abb. 2 (siehe\u00a0PDF<\/a>) wird in Modell\u00a0Mn<\/sub><\/em>\u00a0eine UML Dependency zwischen zwei Packages\u00a0A<\/strong>\u00a0und\u00a0B<\/strong>\u00a0eingef\u00fchrt, weil in\u00a0Mn<\/sub><\/em>+1<\/sub>\u00a0in diesen Packages enthaltene Klassen voneinander ableiten. Genau diese Abh\u00e4ngigkeit h\u00e4tte man so bereits in der Architektur einf\u00fcgen k\u00f6nnen. Es l\u00e4sst sich nicht mehr pr\u00fcfen, ob diese Abh\u00e4ngigkeit korrekt von der Architektur in den Entwurf verfeinert worden ist.<\/p>\n Das Beispiel zeigt auch, dass ein System, bei dem eine \u00c4nderung in einem Modell automatisch zu einer \u00c4nderung im anderen Modell f\u00fchrt, keine Konsistenzpr\u00fcfung zwischen den Modellen zul\u00e4sst. Oft wird diese Kopplung als Vorteil gesehen („das Gesamtmodell stimmt immer“), es ist aber nur aus dem Gesichtspunkt des Reverse-Engineerings und des simplen Programmverstehens sinnvoll („ich sehe, was ist“). Aus der Sicht der Planung, der Nachvollziehbarkeit und des abstrakten Programmverstehens („ich sehe, wo die Unterschiede liegen zwischen dem was ist, und dem was sein sollte“) ist dieses Vorgehen kontraproduktiv.<\/p>\n Um die Integrit\u00e4t der Architektur zu gew\u00e4hrleisten, haben wir uns entschlossen, die Architektur im Enterprise Architect zu modellieren, das Design jedoch in Rhapsody. Auf diese Weise ist bereits technisch ausgeschlossen, dass ungewollte Beziehungen aus einem Modell in ein anderes gelangen.<\/p>\n Die Pr\u00fcfung zwischen zwei Modellen in der Modellhierarchie verl\u00e4uft als Graphenoperation, bei der jeder Entit\u00e4t und Beziehung aus dem konkreten Modell eine Entit\u00e4t bzw. Beziehung aus dem abstrakteren Modell zugeordnet wird [1].<\/p>\n Gelingt dies nicht, so liegt ein Versto\u00df vor. Dabei k\u00f6nnen sich folgende Situationen ergeben:<\/p>\n Bei der Erstellung der Verfeinerung (siehe Abb. 3,\u00a0PDF<\/a>):<\/p>\n Jede Verfeinerung zwischen zwei Modellen\u00a0Mn<\/sub><\/em>\u00a0und\u00a0Mn<\/sub><\/em>+1<\/sub>\u00a0muss die Relationen des Modells\u00a0Mn<\/sub><\/em>\u00a0im Modell\u00a0Mn<\/sub><\/em>+1<\/sub>\u00a0in der Verfeinerung beibehalten. Wenn dies nicht der Fall ist, dann ist die Abbildung zwischen den Modellen nicht sinnvoll. Diese Situation bedeutet einen Modellierungsfehler, siehe Abb. Z (PDF<\/a>).<\/p>\n W\u00e4hrend des eigentlichen Pr\u00fcfvorgangs (siehe Abb. Z,\u00a0PDF<\/a>):<\/p>\n F\u00fcr die Architekturpr\u00fcfung m\u00fcssen wir festlegen, welche UML-Elemente (Entit\u00e4ten und Beziehungen) jeweils in der Architektur und im Entwurf verwendet werden d\u00fcrfen und wie sie einander entsprechen.<\/p>\n Beispielsweise entspricht eine Dependency mit Stereotype „use“ in der Architektur unseres Fallbeispiels einer ganzen Reihe von Dependencies und Associations im Design, z.B. Generalization, use-Dependency und Association.<\/p>\n Die Verfeinerungsrelation zwischen Architektur und Entwurf wird durch ein Python-Skript berechnet, welches die Festlegung einliest und die Verfeinerungsrelationen darauf basierend erstellt. In unserem Fall ist die Verfeinerungsrelation durch Namensregeln gegeben: Ein Package namens „A“ in der Architektur entspricht genau einem Package namens „PkgA“ im Entwurf. Diese Relation ist als 1:1-Relation besonders einfach, aber im Allgemeinen sind 1:n<\/em>-Relationen m\u00f6glich. Die oben aufgef\u00fchrten Fehlerbedingungen beim Erstellen der Verfeinerung werden ebenfalls diagnostiziert. Dadurch k\u00f6nnen Fehlbedienungen und Fehlinterpretationen im Tooleinsatz aufgedeckt werden.<\/p>\n In der t\u00e4glichen Arbeit hat sich die Pr\u00fcfung bew\u00e4hrt und Situationen aufgedeckt, die andernfalls zu einer langfristigen Erosion der Architekturbeschreibung gef\u00fchrt h\u00e4tten, siehe Abb. 6 (PDF<\/a>).<\/p>\n Die Analysen werden in einer Continuous Build-Umgebung ausgef\u00fchrt. Die einzelnen notwendigen Schritte sind:<\/p>\n Die Imports, vorbereitenden Schritte und die Pr\u00fcfungen werden mit Hilfe der Axivion Bauhaus Suite durchgef\u00fchrt. Visualisiert werden die gefundenen Verst\u00f6\u00dfe entweder graphisch oder, im t\u00e4glichen Einsatz, anhand des Dashboards der Axvion Bauhaus Suite. Dank des prozessbegeleitenden Vorgehens ist es direkt m\u00f6glich, die fraglichen Stellen architekturkonform umzubauen bzw. die entsprechende Architektur anzupassen.<\/p>\n [1] Koschke, Rainer; Simon, Daniel: Hierarchical Reflexion Models. In: Proc. of the Working Conference on Reverse Engineering, IEEE Computer Society Press, 2003.<\/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>\nEinsatz-Szenario bei Sennheiser<\/h2>\n
Hierarchisch gegliederte Modelle<\/h2>\n
Die Architekturpr\u00fcfung an sich<\/h2>\n
\n
\n
Erfolg des Einsatzes: Beispiele f\u00fcr aufgedeckte Erosion<\/h2>\n
\n
Literatur<\/h2>\n
\nModellierung – MicroConsult Trainings & Coachings<\/h2>\n
\nModellierung – Fachwissen<\/h2>\n