Anbieter zum Thema
Die Architekturprüfung an sich
Die Prüfung zwischen zwei Modellen in der Modellhierarchie verläuft als Graphenoperation, bei der jeder Entität und Beziehung aus dem konkreteren Modell eine Entität bzw. Beziehung aus dem abstrakteren Modell zugeordnet wird [1]. Gelingt dies nicht, so liegt ein Verstoß vor. Dabei können sich folgende Situationen ergeben:
Bei der Erstellung der Verfeinerung (siehe Bild 3):
- Ein abstraktes Element wird nicht konkreter verfeinert
- Ein konkretes Element ist keine Verfeinerung eines abstrakteren.
Jede Verfeinerung zwischen zwei Modellen Mn und Mn+1 muss die Relationen des Modells Mn im Modell Mn+1 in 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.
Während des eigentlichen Prüfvorgangs (siehe Abb. Z):
- Es gibt eine Relation a -> b in Mn+1, wobei a eine Verfeinerung von A und b eine Verfeinerung von B, jedoch gibt es keine Relation A -> B in Mn (diese Situation nennen wir Divergenz).
- Es gibt eine Relation A -> B in Mn, jedoch keine Verfeinerung a von A und Verfeinerung b von B, so dass a -> b gilt (diese Situation nennen wir Absenz)
Für die Architekturprüfung müssen wir festlegen, welche UML-Elemente (Entitäten und Beziehungen) jeweils in der Architektur und im Entwurf verwendet werden dürfen und wie sie einander entsprechen.
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-Depencency und Association.
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-Relationen möglich.
Die oben aufgeführten Fehlerbedingungen beim Erstellen der Verfeinerung werden ebenfalls diagnostiziert. Dadurch können Fehlbedienungen und Fehlinterpretationen im Tooleinsatz aufgedeckt werden.
Erfolg des Einsatzes: Beispiele für aufgedeckte Erosion
In der täglichen Arbeit hat sich die Prüfung bewährt und Situationen aufgedeckt, die andernfalls zu einer langfristigen Erosion der Architekturbeschreibung geführt hätten, siehe Bild 6.
Die Analysen werden in einer Continuous Build-Umgebung ausgeführt. Die einzelnen notwendigen Schritte sind:
- Import der Architektur aus Enterprise Architekt
- Import des Designs aus Rhapsody
- Vorbereitende Schritte: Interpretation der Modelle, Berechnen der Verfeinerungsrelation
- Durchführung der Prüfung
- Visualisierung der Ergebnisse
Die Imports, vorbereitenden Schritte und die Prüfungen werden mit Hilfe der Axivion Bauhaus Suite durchgeführt. Visualisiert werden die gefundenen Verstöße entweder graphisch oder, im täglichen Einsatz, anhand des Dashboards der Axivion Bauhaus Suite. Dank des prozessbegleitenden Vorgehens ist es direkt möglich, die fraglichen Stellen architekturkonform umzubauen bzw. die entsprechend Architektur anzupassen.
Modellgetriebene Entwicklung
Versionierung: Die Herausforderung bei der Modellierung
Techniken und Tools
Modellbasiert entwickeln im Internet of Things
Codegenerierung – was man damit (nicht) machen kann
Literatur
[1] Koschke, Rainer; Simon, Daniel: Hierarchical Reflexion Models. In: Proc. of the Working Conference on Reverse Engineering, IEEE Computer Society Press, 2003.
* Ingo Battis ist System Architekt in der Professional Systems Division bei der Sennheiser electronic GmbH & Co. KG. Die Schwerpunkte seiner Tätigkeit in der Produktentwicklung sind die Erstellung von Software Architekturen, die Steuerung eines Software-Entwicklungsteams im agilen Umfeld und die SW Integration.
* Thomas Eisenbarth ist Gründer und Geschäftsführer der Axivion GmbH, die in Kooperation mit den Unis Stuttgart und Bremen Analysewerkzeuge rund um das Thema Entwicklung und Qualitätssicherung von Software entwickelt und vertreibt.
(ID:44055610)