Das Dokument behandelt die metamodellbasierte Validierung und Werkzeuganpassung bei der Deutschen Post COM GmbH, insbesondere die Konzepte der Metamodellierung und Modellvalidierung zur Verbesserung von Qualität und Effizienz in Entwicklungsprozessen. Es werden verschiedene Arten von Metamodellen, deren Klassen und Anwendungsfälle sowie die Rolle der Object Constraint Language (OCL) im Validierungsprozess dargestellt. Abschließend wird auf den Einsatz von Case-Tools und die Aufwandsminimierung durch strukturierte Modellierungsansätze eingegangen.

1. UML-Modelle im Griff Metamodellbasierte Validierung und Werkzeuganpassung bei der Deutschen Post Com GmbH Frank Egger Deutsche Post Com GmbH Ingo Feltes Itemis Gmbh und Co. KG

2. Überblick Einführung in die Metamodellierung Modellvalidierung auf Basis von Metamodellen Aufwandsminimierung und Qualitätssteigerung durch CM3 Case-Tool Konfektionierung zur frühzeitigen Validierung

3. Teil 1 Einführung in die Metamodellierung

4. Begriffsfindung … kommt aus dem Griechischen und bedeutet „zwischen“, „inmitten“, „nach“, „nachher“ … drückt aus, dass sich etwas auf einer höheren Stufe oder Ebene befindet Meta… … sind Abbilder der Wirklichkeit … betonen bestimmte Eigenschaften … lassen nebensächliche Aspekte außer acht Modelle… Metamodell Elemente der Metamodells Modell Elemente des Modells Zu beschreibende Domäne Elemente der „ wirklichen Welt“ beschreibt beschreibt Modelle von Modellen sind Metamodelle?

5. Mehrstufige Klassifizierung Modelle erstellen durch Anwendung einer Klassifikationsabstraktion Straßennetz: Busliniennetz: Logistiknetz: Netz: Durch erneute Klassifikation entsteht ein Modell der Modelle

6. Ontologische Metamodelle Ein durch mehrstufige Klassifizierung entstandenes Modell heißt Ontologisches Metamodell Metamodell Modell Instanzen Klassifikation Nicht transistiv! „ Berlin“ ist eine Instanz der Klasse „Stadt“ Die Klasse „Stadt“ ist eine Instanz der Klasse „Knoten“ „ Berlin“ ist keine Instanz der Klasse „Knoten“

7. Generalisierung vs. Metamodelle Für ein ontologisches Metamodell gilt… Die Instanzen der Klasse „Knoten“ sind die Klassen „Stadt“, „Haltestelle“, „Briefkasten“ Eine Instanz der Klasse „Stadt“ (z. B. Berlin) ist keine Instanz der Klasse „Knoten“ Für die Generalisierung gilt… „ Stadt“, „Haltestelle“, „Briefkasten“ sind keine Instanzen von der Klasse „Örtlichkeit“ Jede Instanz der Klasse „Stadt“ ist auch gleichzeitig eine Instanz der Klasse „Örtlichkeit“

8. Modelle von Modellen vs. Metamodelle Verbindung Elektronen pro Energieniveau Das Atommodell ist ein Beispiel aus der klassischen Modellierung Reduziert man das Atommodell auf die im jeweiligen Atom vorhandenen Elektronen pro Energieniveau, kann man ein Modell des Atommodells erstellen Dieses Modell des Atommodells ist allerdings kein onthologisches Metamodell, da es nicht durch mehrstufige Klassifizierung, sondern nur durch Abstraktion entstanden ist Modell eines Modells ≠ Metamodell Der Schein trügt O H O 1 2,6 2,6

9. Linguistische Metamodelle – Basis für die UML Problembereich Menge von Originalen Modellbereich Gleichartige Modelle Verschiedener Originale Metamodell Beschreibt die Art der Im Modellbereich Verwendeten Modelle

10. Linguistische vs. Onthologische Metamodelle Welche Teilbereiche bestimmen ein linguistisches Metamodell? … entstehen durch mehrstufige Klassifikation innerhalb des Modellbereichs Onthologische Metamodelle… … modellieren die verwendbaren Modellierungskonstrukte und verlassen damit den Modellbereich … sind keine Modelle von Modellen sondern Modelle von Modellbereichen , d.h. Mengen von gleichartiger und nach gleicher Technik erstellter Modelle … werden in der Praxis häufig auf den Begriff „Metamodell“ reduziert Linguistische Metamodelle…

11. Die drei Achsen der Metamodellierung Metamodell (konkrete Syntax) Metamodell (statische Semantik) Metamodell (Prozess)

12. Metamodellarchitekturen der OMG Prozess Semantik 0 0 1 2 1 2 Angewandtes Metaisierungsprinzip Metaisierungsbasis Relative Hierarchieposition M 0 Modell M 1 Metamodell M 2 Modell M 1 Metamodell M 2

13. Metamodellarchitekturen der OMG – Theorie … Prozess Semantik 0 0 1 2 1 2 Universe Of Discourse … … … … … … … … …

14. Metamodellarchitekturen der OMG – Praxis UML-Diagramme UML-Metamodell Entwicklungs- prozess … Prozess Semantik 0 0 1 2 1 2 Universe Of Discourse … … … … … … … … … System Prozess- management Unified Modeling Process Unified Profile- Modeling Process MOF CM3 Case-Tools

15. UML Metamodell-Architektur

16. Metamodelle und die Praxis Sprach- u. Methodenformalisierung (MOF, UML, OML) Domänenspezifische und architekturzentrierte Modellierung Formalisierung von Entwicklungsprozessen Vorlage für Werkzeugimplementierungen, Toolanpassungen Basis für Meta-CASE-Werkzeuge Modellvalidierungen generische Transferformate (CDIF, XMI) Sprach- und Methodenvergleich Systemintegration Modelltransformation / Code-Generierung Einsatz und Nutzen Vorlage für Werkzeugimplementierungen, Toolanpassungen Modellvalidierungen

17. Teil 2 Modellvalidierung auf Basis von Metamodellen

18. Warum Validieren? Semantische Korrektheit zum Metamodell Korrekte Verwendung von Modellelementen, Stereotypen und Tagged Values Vollständigkeit aller methodischen Konstrukte Integrität zu referenzierten oder inkludierten Modellen Definition von Qualitätskriterien auf Fachmodellebene Frühzeitige Behebung von Fehlern Lange Iterationen zur Fehlerbehebung werden vermieden Fehlerbehebung während der Erfassung von Modellen ist günstiger als in der Implementierung oder sogar im Betrieb Automatisierung von Modellrevision und –abnahmen

19. Validierung mit OCL (Object Constraint Language) Sprache zur Formulierung von Prüfregeln für objektorientierte Modelle Standardisiert von der OMG als Teil der UML 2.0 Möglichkeit zur Anreicherung eines Metamodells mit zusätzlicher Semantik Prinzipiell auf jeder Modell-Hierarchieebene einsetzbar (z.B. M1, M2) Grundlagen Elemente der Sprache Constraints für Vorbedingungen, Nachbedingungen und Invarianten Expressions für z. B. Wert- und Initialwertprüfungen für Attribute Queries zur Selektion von Modellelementen

20. OCL auf M1 bei AndroMDA OCL Query an einer M1-Operation Möglichkeit zur Übersetzung der Query für verschiedene Persistenzframeworks SELECT DISTINCT OBJECT (project) FROM Project project WHERE project.type= ?1 EJB-QL from org.andromda.sample.Project as project where project.type = ? Hybernate-QL

21. OCL auf M2 bei AndroMDA Bedeutung der OCL-Constraint: Bei einer Operation dürfen weder Ergebnistyp noch Name leer sein.

22. Beispiel für Business Process Modeling context UseCase inv: let useCaseName : String = name in useCaseName -> notEmpty() and model.allUseCases-> one (name = useCaseName) „ Each use-case must have a non-empty name that is unique among all use-cases.“ final java.lang.Object contextElement = this ; boolean constraintValid = OCLResultEnsurer.ensure(OCLCollections .notEmpty(OCLIntrospector.invoke(contextElement, "name")) && OCLCollections.one(OCLIntrospector.invoke( contextElement, "model.allUseCases"), new Predicate() { public boolean evaluate(java.lang.Object object) { return OCLExpressions.equal(OCLIntrospector .invoke(object, "name"), OCLIntrospector.invoke( contextElement, "name")); } })); if (!constraintValid) validationMessages. add(new ModelValidationMessage( this .getClass(), this .getName(), "Each use-case must have a non-empty name that is unique among ..."));

23. Teil 4 Aufwandsminimierung und Qualitätssteigerung durch CM3

24. Aufwandsgenerator „Einarbeitung“ Architekten sind besonders zum Projektstart mit Coaching überfordert Entwickler sind mit dem breiten Spektrum an Modellierungsalternativen überfordert Hohem „Wissensdurst“ in Entwicklerteams kann nicht ausreichend begegnet werden Nicht alle Entwickler können aufgrund des Zahlenverhältnisses ausreichend Coaching bekommen Wiederholung von Modellierungsfehlern in Entwickler-Teams aufgrund zu geringem Coachings frustriert beide Seiten Architekten Entwickler Coaching Qualitätskriterien / Modellierungsrichtlinien Feedback Ergebnisse

25. Aufwandsgenerator „Lange Iterationen“ Architekt 1: Architekturrahmen entwerfen Designer 2: PIM Modellieren UML - Profil Entwickler 3: PIM attributieren PIM - - Build 6: Anwendung übersetzen und verpacken Build Parameter Build Umgebung 7: Anwendung deployen und testen Generator 4: Architekturrahmen generieren XMI Generator - Schablonen 5: Businesslogik einfügen Code Feedback und validieren und validieren mit Metamodell - Constraints

26. Aufwände bei der Entwicklung Start Aufwand in EW-Tagen Zeit Ohne Validierung / Werkzeug-anpassung Initialer Aufbau der generativen Architektur Projektsetup, Einarbeitung Entwickler Fach-modellierung und Attributierung Generierung Implementierung und Build Kleines Team mit Architekten Manuelle Weitergabe / Verbreitung von Best Practices Lange Iterationen bei Modellierungs-fehlern und Modellrevision Test / Deployment Manuelle Einarbeitung und Wissensvermittlung, Überforderung der Architekten Formalisierung von Qualitäts-kriterien on top Intuitive Zugänglichkeit, Toolgestützte Einarbeitung, Konzentration auf das Wesentliche Minimalismus bei der Modellierung durch Einsatz von Pattern-Wizards Mit Validierung / Werkzeug-anpassung

27. Kosten / Nutzen Case-Tool unterstützt Erweiterungen z. B. in Form von Plugins Erstellung von Transformationsvorlagen für die Werkzeuganpassung Versionierung mit Metamodell in der Architektur Voraussetzungen für Werkzeuganpassung und Validierung Weitere Vorteile Integration in eine Validierungsverkettung (1. Case-Tool, 2. Generator) Erweiterung eines Nightly-Builds Standardisierung / Strukturierung von Prozessen und Vorgehensmodellen Erhöhung der Vergleichbarkeit von Fachmodellen Frühzeitige Risikominimierung

28. Danke für Eure Aufmerksamkeit! Noch Fragen?