MTFLOW - Informatik 5

Transcription

MTFLOW – Ein System für workflow-basierte
Ausführung von Modelltransformationen
Mohamed Amine Chatti
[email protected]
19. Mai 2004
Motivation

Ziel der Arbeit
¾
Den Ansatz der workflow-basierten Modelltransformationen analysieren und
empirisch bewerten
¾
MTFLOW (Model Transformation workFLOWs ): Eine PrototypImplementierung

MTFLOW – Überblick
¾
Schnelle Spezifikation von Software-Systemen in einer Produktlinie mit Hilfe
der Sprachen UML und OAL
¾
Die Spezifikation entsteht durch die aufeinanderfolgende Anwendung von
Modelltransformationen, ausgeführt mit Hilfe der Sprache XMI
¾
Die Reihenfolge der angewendeten Transformationen wird mit einem
Workflow-Modell überwacht
19.05.2004
MTFLOW
2
Gliederung

Produktlinienansatz und generative Programmierung
Modelltransformationen
Metamodell für MTFLOW-Workflow-Modelle
Versionierungssysteme als Anwendungsbeispiel
Empirische Untersuchungen
Zusammenfassung und Ausblick
19.05.2004
MTFLOW
3
Generative Programmierung

Beziehung zu dem Produktlinienansatz bzw. der generativen
Programmierung
¾
SW-Produktlinie
Analogie Softwareentwicklung-Industrie
¾
Meilensteine der …
…Industrialisierung
1826
Einsatz
austauschbarer
Teile
1901
erstes
Fließband
1981
Einsatz von
Robotern
Produktion mit
Wiederverwendung
Massenproduktion
Automatisierte
Produktion
1970er
1980er
2000
Objektorientierung
SoftwareSystemfamilien
GenerativeProgrammierung
…Software-Entwicklung
19.05.2004
MTFLOW
4
Generative Programmierung

Ziele der generativen Programmierung
¾
¾
Die Entwicklung von SW-Systemen vereinfachen, verbessern und beschleunigen
Automatisierte Produktion der Systeme in einer SW-Systemfamilie

Phasen der Produktlinienentwicklung
Domänen-Engineering
Domänenwissen
DomänenAnalyse
Applikations-Engineering
neue
Anforderungen
Kundenanforderungen
AnforderungsAnalyse
Domänenmodell
Produktmerkmale
DomänenEntwurf
Architektur und
Produktionsplan
DomänenImplementierung
ProduktKonfiguration
Komponenten,
DSLs,
Generatoren,
Infrastruktur
Produktkonfiguration
Integration
und Test
Produkt
19.05.2004
MTFLOW
5
Gliederung

19.05.2004
MTFLOW
6
Modelltransformationen in MDA

MDA (Model Driven Architecture)
¾
Trennung der Definition der Funktionalität eines Systems von der Definition
der Implementierung dieser Funktionalität für eine bestimmte Plattform
¾
Modelle in MDA
•
•
¾
PIM (Platform-Independent Model)
PSM (Platform-Specific Model)
Abbildung zwischen Modellen
•
•
•
•
PIM zu PIM
PIM zu PSM
PSM zu PSM
PSM zu PIM
19.05.2004
MTFLOW
7
Modelltransformationen in MDA
Verfeinerung
PIM
Anwendungsspezifisches
Metamodell
(z.B. Enterprise Computing)
(UML-Profil)
definiert auf
Customer
Name : String
ReverseEngineering
optional
Transformation
Verfeinerung
PSM
Plattform-Metamodell
(z.B. Enterprise JavaBeans)
(UML-Profil)
<<EJBRemoteInterface>>
Customer
definiert auf
<<EJBRemoteMethod>> getName()
<<EJBRemoteMethod>> setName()
Generierung
Verfeinerung
Code
Implementierungssprache
(z.B. Java)
19.05.2004
definiert auf
public interface Customer {
public String getName();
public void setName(String name);
}
MTFLOW
8
Modelltransformation mit XMI

XMI (XML Metadata Interchange)
¾
XMI ist ein textbasiertes Austauschformat für Modelle
xmi.id, xmi.uuid
idref, href
XMI.difference, XMI.add, XMI.delete, XMI.replace
Model Merging
¾
¾
¾
¾
19.05.2004
MTFLOW
9
Project
Offer
customer : String
price : float
delete
Project
replace
New Offer
customer : String
add
Task
name : String
description : String
19.05.2004
<XMI.content>
<UML:Package xmi.id=„p1“ name=„Project“>
<UML:Class xmi.id=„c1“ name=„Offer“>
<UML:Classifier.feature>
<UML:Attribute xmi.id=„a1“ name=„customer“>
<UML:StructuralFeature.type>
<UML:DataType xmi.idref=„s“>
</UML:DataType>
</UML:StructuralFeature.type>
</UML:Attribute>
<UML:Attribute xmi.id=„a2“ name=„price“>
<UML:DataType xmi.idref=„f“>
</UML:DataType>
</UML:Attribute>
</UML:Classifier.feature>
</UML:Class>
</UML:Package>
original.xmi
</XMI.content>
<XMI.content>
<UML:Package xmi.id=„p1“ name=„Project“>
<UML:Class xmi.id=„c1“ name=„New Offer“>
<UML:Attribute xmi.id=„a1“ name=„customer“>
</UML:DataType>
</UML:Attribute>
</UML:Class>
<UML:Class xmi.id=„c2“ name=„Task“>
<UML:Attribute xmi.id=„a3“ name=„name“>
</UML:DataType>
</UML:Attribute>
<UML:Attribute xmi.id=„a4“ name=„description“>
</UML:DataType>
</UML:Attribute>
</UML:Class>
</UML:Package>
new.xmi
</XMI.content>
MTFLOW
<XMI.content>
<XMI.difference>
<XMI.add href=„original.xmi | p1“ >
<UML:Class xmi.id=„c2“ name=„Task“>
<UML:Attribute xmi.id=„a3“ name=„name“>
</UML:DataType>
</UML:Attribute>
<UML:Attribute xmi.id=„a4“ name=„description“>
</UML:DataType>
</UML:Attribute>
</UML:Class>
</XMI.add>
<XMI.delete href=„original.xmi | a2“/>
<XMI.replace href=„original.xmi | c1“>
<UML:Class xmi.id=„c1“ name=„New Offer“/>
</XMI.replace>
</XMI.difference>
difference.xmi
</XMI.content>
10
Modelltransformation mit XMI

Erweiterung der XMI-Spezifikation

Ablauf der Modelltransformation in MTFLOW
Spezifikationsbaum (bi)
Velocity-Prozessor
A
B
Kontext (ki) (als Hashtabelle)
C
Schlüssel A
A als Java-Objekt
Schlüssel B
B als Java-Objekt
Schlüssel C
C als Java-Objekt
VTLVorlage (vi)
…
Merge (Velocity)
generiertes
XMI-Differenz-Dokument (di)
XMI-Model-Dokument (mi)
Merge
(XMI)
XMI-Model-Dokument (mi-1)
19.05.2004
MTFLOW
11
Gliederung

19.05.2004
MTFLOW
12
WorkflowModel
R2
+supercategory
1
R9
name : String
R14
+workflow
model
1
+root
name : String
0..n index : int
category
sub- minOccurence : int 1
category maxOccurence : int
R1
1..n
0..n
ConfStep
+source
name : String
1 isEntry : boolean 1
+sink
+variable 0..n
ConfVariable
i dentifie r : String
i ndex : int
type : String
minOccurence : String
maxOccurence : String
getsN ewMId : Boolean
getsMId FromD omain : Boolean
+value 0..n
selection
R8
+template
1
R6
R7
R5
R4
19.05.2004
+step
+category
R3
1
1 +step
+step
1
+category
filename : String
+template
+steps
ConfCategory
Template
1
0..n +functio n
+evaluates
+evaluates
Function
display
transition
identifier : String
condition
value
body : String
0..1
1
returnType : String
+outgoi ng
0..1 transition
+incoming
Transi tion
transition
name : String
0..1
+transition
R11
1
1 +transition
R 12
+connector
+connector
0..n
0..n
0..n
+evaluates
ControlConnector
template
R10
values
name : String
+transfered
values
0..n
+evaluates
1
transfered values
DataFlow
0..n
0..1
name : String
+data flow
+va lue dom ain
MTFLOW
R15
R13
13
Gliederung

19.05.2004
MTFLOW
14
Versionierungssysteme

¾
¾
¾
■
■
■
Speicherung versionierter und nicht versionierter Objekte
Attribute
Operationen auf Objekten
Beziehungen zwischen Objekten
Gleitende Beziehungsende (floating relationship ends)
Kandidatenmenge (candidate version collection)
Zugriffsmöglichkeiten:
Vorauswahl von Objektversionen (pinning), regelbasierte Auswahl, gesamte CVC
Propagierung von Operationen
Arbeitskontexte
Informationsmodell
19.05.2004
MTFLOW
15
Informationsmodell
VersionedVSObjectType
Offer
customer : String
price : float
validUntil : String
isPart
1..*
0..*
contains
1
Task
name : String
startDate : String
dueDate : String
0..*
causedBy ratedCosts
0..*
1
Cost
wages : float
travelExpences : float
materialExpenses : float
validUntil : String
0..*
attaches
0..*
Project
VSWorkspaceType
19.05.2004
MTFLOW
16
Versionierungssysteme

Viele Variationsmöglichkeiten
¾
Angaben über versioniert und unversioniert zu speichernde Objekttypen
Beziehungen
Arbeitskontexte
Propagierung von Operationen über Beziehungen
¾
¾
¾
Versionierungssysteme als Produktlinie
■
Workflow-Modell für Versionierungssysteme
¾
Modellieren von Workflow-Prozessen mit Petri-Netzen oder Statecharts und
Activitycharts
Schrittweise Verfeinerung der Modelle ist mit Statecharts und Activitycharts
möglich
¾
19.05.2004
MTFLOW
17
Versioning System_AC
ObjectTypes (OTs)
ObjectTypes (OTs),
RelationshipTypes (RTs)
ObjectTypes (OTs)
Define_ObjectType_A
Make_ObjectType_
Versionable_A
Define_
RelationshipType_A
Define_
WorkspaceType_A
ObjectTypes (OTs)
ObjectTypes (OTs),
versionable ObjectTypes (verOTs)
@Versioning System_SC
Versioning System_SC
new WT/
st! (Define_
WorkspaceType_A)
new OT/
st! (Define_
ObjectType_A)
new RT/
st! (Define_
RelationshipType_A)
Define_ObjectType_S
new OT
19.05.2004
new verOT
Make_ObjectType_
Versionable_S
new verOT/
st! (Make_ObjectType_
Versionable_A)
new RT
Define_
RelationshipType_S
new RT/
st! (Define_
RelationshipType_A)
MTFLOW
new WT
Define_
WorkspaceType_S
new WT/
st! (Define_
WorkspaceType_A)
18
Beispiel
Konfigurationsschritt A
Define ObjectType
19.05.2004
MTFLOW
19
Beispiel
Konfigurationsschritt B
Make ObjectType versionable
…
…
19.05.2004
…
…
…
…
MTFLOW
20
Beispiel
Konfigurationsschritt C
Define RelationshipType
…
…
…
…
19.05.2004
MTFLOW
21
Beispiel
Konfigurationsschritt D
Define WorkspaceType
…
…
…
…
…
…
19.05.2004
MTFLOW
22
Gliederung

19.05.2004
MTFLOW
23

durchgeführte Untersuchungen
¾
¾
Analyse der Transformationsvorlagen
Analyse der Transformationsergebnisse
■
verwendete Metriken
¾
Anzahl der Anweisungen
zyklomatische Komplexität
Halstead-Aufwand
MTFLOW-spezifische Metriken
¾
¾
¾
19.05.2004
MTFLOW
24
Analyse der Transformationsvorlagen
¾
¾
¾
Vorlage C hat die höchste Komplexität
Konstantes Verhältnis zwischen Umfang und Komplexität der Vorlagen
Anzahl der Anweisungen, Referenzen, Fallunterscheidungen und XMI-Elemente
steigen mit der Größe der Vorlagen an
19.05.2004
MTFLOW
25
¾
¾
verschiedene Modelle als Informationsmodelle: UML Core Package, CWM Relational
Package, MOF Model Package
Ermittlung der Anzahl der verschiedenen generierten XMI-Elemente in jedem
Konfigurationsschritt
19.05.2004
MTFLOW
26
¾
Anzahl der UML:Class-, UML:Association- und OAL:Method-Elemente
¾
Anzahl der generierten XMI-Elemente im Vergleich mit der Anzahl der in den
Vorlagen enthaltenen XMI-Elemente
19.05.2004
MTFLOW
27
¾
Anzahl der generierten XMI-Elemente im Vergleich mit dem Aufwand der
Spezifikation eines SW-Systems
19.05.2004
MTFLOW
28
Gliederung

19.05.2004
MTFLOW
29
¾
¾
¾
¾
¾
¾
¾
¾
Ein domänenspezifisches Workflow-Modell und eine Menge von
domänenspezifischen Vorlagen können bei der Spezifikation eine
DSL ersetzen
OAL als geeignete Sprache zum Modellieren der Semantik
konstantes Verhältnis zwischen Umfang und Komplexität der
Vorlagen
Vorlage C zu komplex (hoher Halstead-Aufwand)
Aufteilung der Vorlage C sinnvoll
Aufwand der Entwicklung der Vorlagen zahlt sich aus
lineare Abhängigkeit zwischen Anzahl der generierten XMIElemente und Aufwand der Spezifikation (Faktor 20)
Bewertung verschiedener Produktlinien
19.05.2004
MTFLOW
30

Fragen?
19.05.2004
MTFLOW
31

MTFLOW - Informatik 5

Transcription

Similar documents

PDF-Download

Umsetzung mehrsprachiger Lerninhalte auf der Basis von

11.07.00 - Institut für Informatik

TEAM[:]niel

Basisrichtlinie für die Konstruktion von Anlagen und

Softwarearchitektur verteilter Systeme

Softwareproduktlinien