xUML - executable UML

Seminar Modellgetriebene Softwareentwicklung

xUML - executable UML

Vortrag im Rahmen des Seminars zum Thema Modellgetriebene Softwareentwicklung

René Heilmann

executable UMLRené Heilmann 2


Inhalt

Motivation Was ist xUML? Ablauf der Modellierung Zusammenfassung Ausblick



Motivation

Experteneinsatz in ihren Fachgebieten unterstützen Domainexperten Softwareentwicklungsexperten

Funktionale Verhalten der Software auf Basis des Modells verifizierbar

Agile Softwareentwicklung auf neuer Abstraktionsebene Abtrennung der Anforderungen durch die Plattform von

der Anwendung Austauschbarkeit der Hardware- und Softwareplattform

erreichen



Was ist xUML?

auch x(t)UML, für executable and translatable UML Integration von Modell und Programmiersprache

für gleiche Semantik stehen grafische und textbasierte Notation zur Verfügung

UML-Profil eingegrenzte UML Modellmenge + präzisere

Elementbeschreibung, entfernte Doppelbelegung „Stützpfeiler“ der MDA

Nutzermodelle gemäß xUML entsprechen PIMs Abgrenzung von der MDA

PSM als entbehrliche grafische Zwischenstufe zum Code angesehen



Ablauf der Modellierung

externe Sicht auf Systemverhalten Domainspezifikation USE-CASEs

Erkennen der Anforderungen interne Sicht

Klassen Constraints Lebenszyklus

Kommunikation / Synchronisation der Objekte

Domänenverifikation Modellkompilierung / -verbund



Ablauf: Domains und USE-CASEs

Domain (realer, abstrakter, hypothetischer Problemraum): voneinander eindeutig abgrenzbaren Teile des System Darstellung: grafisch - Domain Chart + textbasierte

Beschreibung Verknüpfung über „Join Points“, Umsetzung über Bridges

USE-CASE: dienen Modellgründung und Testfallermittlung, keine

Ausführbarkeit Aktivitätsdiagramme zur Verdeutlichung der Abfolge

Annahme Anforderung

Domäne1 Bridge Domäne2 Anforderung Annahme



Ablauf: Klassen I

Modellierung mithilfe von Klassendiagrammen Attribute:

core type, domain type (nutzerdefiniert, sind zu bevorzugen) Operationen / Methoden

definiert über klasseneigene Zustandsmaschine Signale

ist nicht mit Operation gleichzusetzen, sondern Auslöser Parametrisierung möglich

Assoziationen Generalisierung, Spezialisierung, ... analog UML

Klassenmodellierung erzwingt keine objektorientierte Umsetzung



Ablauf: Klassen II

Action Language: bildet Umgang mit (konkreten) Instanzen ab

Erstellen, Löschen, Zugriff auf Attribute, Iterationen, Auswahl, Datenmanipulation, Berechnungen (allgemein)

abstrahiert Details der Softwareplattform (Datenstrukturen) Basis bildet „Precise Action Semantics for UML“, mit eigens

für xUML definierten Syntax

Constraints: Regeln zur Festlegung gültiger Werte Umsetzung mittels OCL (Object Constraint Language) ausführbar, definiert berechenbare Werte, unterstützt

Laufzeittests



Ablauf: Lebenszyklus I

Abbildung von Ereignis – Zustandsrelation der Instanzen einer Klasse mittels Zustandsmaschine

Abbildungsmittel: Zustandsdiagramm Elemente:

Zustände, Ereignisse Transition (Regel zur Festlegung welcher neue Zustand durch

welches Ereignis eintritt) Prozeduren (notwendige, zu vollendende Aktivität / Operation

bei Erlangung eines neuen Zustandes Action Language) initiale, finale Pseudozustände

ergänzend: Zustandsübergangstabelle Matrix aus Ereignisse X Zustände finden verborgener

Übergänge, Kombinierbarkeit



Ablauf: Lebenszyklus II

Kommunikation / Synchronisation von Objekten Abbildungsmittel Interaktionsdiagramme:

Kollaborationsdiagramme - Kommunikation zwischen Klassen Sequenzdiagramme – zeitl. Verlauf eines Szenarios, bei

bekannten Zuständen und Attributwerten Informationsaustausch als Signale zwischen den

nebenläufigen Instanzen der jeweiligen Zustandsmaschinen Modellierer hat korrekte Reihenfolge und Datenkonsistenz

zu garantieren



Überblick



Ablauf: Domänenverifikation

Testfälle für einzelnen Use-Case betrachtet eine Aktivität: precondition, initiales Signal,

postcondition Basis = Szenario: Kombination aus initialem Systemzustand

(Zustandsmaschine), festgelegter Wertebereich für Signalparameter und Attributwerte

Menge der Testfälle durch Anfangszustände und Signalparameterwerte bestimmt

Testvektoren bestimmen ein bestehen / fehlschlagen des Tests

Automatisierung mithilfe der Action Language



Ablauf: Modellcompiler

Compiler trifft HW- / SW-Entscheidungen

allein Compiler entscheidet wie die einzelnen Modellelemente in Quelltext umgesetzt werden

Verflechtung der Nutzermodelle: Regelwerk aufgebaut aus Urtypen (archetypes) Urtypen: Fragment aus Datenzugriff und Textmanipulation,

welches formal eine Überführung in Text beschreibt Datenzugriff – Repository aus xUML Modellen Textmanipulation – mögliche Anpassung der Textausgabe



Zusammenfassung I

Compiler

„weaving“

xUML Anwendungsmodelle Quelltext

xUML-Metamodell

Systemarchitektur Metamodell

Abstraktionsebene



Zusammenfassung II

möglicher Einsatz von Experten aus Anwendungsgebiet Plattformunabhängigkeit, vereinfachte

Technologiewechsel erhöhte Wiederverwendbarkeit und Qualität debuggen auf Modellebene UML versierte Anwender kaum Einarbeitung fördert konkurrierende Entwicklung



Ausblick

Ergebnisse der OMG QVT Standardisierung könnte nochmals zu Veränderungen führen (Metamodellmapping untereinander)

OMG RFP für Standard um Metamodell nach Text zu mappen

Entwickler nur noch Modellierung und Modellkompileranpassung darunterliegende Ebene (höhere Programmiersprache) bleibt unangetastet, wie heutzutage Assemblerebene



Quellen

Mellor, Stephen, Balcer, Marc: Executable UML – A Foundation for Model-Driven Architecture. Addison-Wesley, 1. Auflage 2002

http://www.pafis.shh.fi/graduates/leogal01.pdf http://www.bptrends.com/publicationfiles/06-04%20COL

%20Agile%20MDA%20-%20Frankel%20-%20Mellor.pdf http://www.embedded.com/story/OEG20030115S0043 http://www.sigs.de/publications/os/2005/MDD/

Buehler_MDA_OS_2005.pdf http://www.acceleratedtechnology.com/embedded/

nuc_xtuml.html http://www.informit.com/articles/article.asp?

p=28274&seqNum=3&rl=1 http://www.stsc.hill.af.mil/crosstalk/2004/09/0409Mellor.html



Vielen Dank für Ihre Aufmerksamkeit

Documents

xUML - executable UML