Software Engineering 2 – Konstruktion interaktiver (CASE) Tools WS 08 / 09 Vorlesung: Albert...

Software Engineering 2 – Konstruktion interaktiver (CASE) Tools

WS 08 / 09

Vorlesung: Albert Zündorf, Software Engineering

Übungen: Nina Aschenbrenner, Software Engineering

SS 2007 Software Engineering 2 Albert Zündorf, University of Kassel

2

Administratives

Vorlesung: Montags 15-18 Uhr Raum 1342 (4SWS)

Prüfung: Projektarbeit (wir basteln uns ein (EPK) Tool)


3

Überblick

1. Referenzarchitektur

2. Meta-Modell

3. Repository

4. Austauschformate

5. Unparsing

6. Checking

7. Code Generierung


4


Repository

Meta Model

GUI(Commands)

Generators / Interpreters

QVT

Import/ Export

GUI(Unparsing)


5

2. Meta-modell

abstrakter Syntaxgraph (ASG)

logische Datenstruktur hinter der Darstellung am Bildschirm

speichert Editoreingaben

beschrieben durch Klassendiagramm

File Edit Tools X


6

2. Meta-modell


7

A more complete Example

BPMN_Poster


8

2. Meta-modell


9

Meta Meta Meta


10

Meta Object Facility – MOF

yet another meta model for class diagrams

UML notation

+ klare Semantik

+ standard Implementierung(z.B. JMI Repository)

+ standard Austauschformate(XMI)

Akademische Initiative

Open source

oft als Austauschformat zwischen Tools benutzt


11

Nach Atkinson Kühne: Model-Driven Development:A Metamodeling Foundation; IEEE Software

• linguistic instance-of

• ontological instance-of

- M3: Werkzeugbausteine

- M2: Programmbausteine

- M1: Laufzeitdaten

- M0: reale Welt


12

Nach Atkinson Kühne: Model-Driven Development:A Metamodeling Foundation; IEEE Software

• linguistic instance-of

• ontological instance-of

- beide Dimensionen gleichberechtigt?


13

3. Repository

Man will ja auch mal abspeichern und wieder laden:

Binäre File-Formate / Java Serialisierung

class C implements Serializable

bestimmen aller Objekte die gespeichert werden sollen( Composite Struktur)

transiente Attribute werden ausgeklammert

Anforderungen Serialisierung

Speichern und Laden +

Einfachheit ++

Tool-Kopplung O

Multi-User Support -

Versionierung --

Schema-Evolution ?

Scaling O


14

3. Repository

XML-Formate

generische Lade-/Speicher Routinen per Java Reflection

bestimmen aller Objekte die gespeichert werden sollen( Composite Struktur)

JDom / Xerces Basistechnologie(beherschbar)

Anforderungen XML - Formate


Einfachheit +

Tool-Kopplung +

Multi-User Support -

Versionierung --

Schema-Evolution +

Scaling -


15

3. Repository

Relationale Datenbanken

Objekte und Beziehungen werden als Tupel in Datenbanktabellen gespeichert

Zugriff per ODBC

Middleware (z.B. Hibernate)

Multi-User Betrieb durch Datenbank Sperrkonzepte und Transaktionen pessimistische Sperren Caching schwierig

Anforderungen Datenbanken


Einfachheit -

Tool-Kopplung +

Multi-User Support +

Versionierung -

Schema-Evolution +

Scaling ++


16

3. Repository

Coobra: COmmon Object Replication frAmework

Basismechanismus von Fujaba

Protokollierung aller Attributzugriffe als Deltas per Listener

Undo / Redo

Deltas Checkin / Checkout in Repository

optimistisches Locking / Merging

Integriert in Fujaba Code Generierung

manuelle Implementierung möglich

Anforderungen Coobra


Einfachheit ++

Tool-Kopplung +

Multi-User Support ++

Versionierung ++

Schema-Evolution +

Scaling -


17

3. Repository

Anforderungen Serialisierung XML - Formate

Datenbanken Coobra

Speichern und Laden + + + +

Einfachheit ++ + - ++

Tool-Kopplung O + + +

Multi-User Support - - + ++

Versionierung -- -- - ++

Schema-Evolution ? + + +

Scaling O - ++ -


18

4. Commands

Aktionen hinter Menüpunkten und Buttons

Viele Buttons/Menüpunkte für ein Kommando denkbar

Undo/Redo Einheiten

API Operationen

Macros


19

4. Commands

Normalerweise ein Objekt/eine Klasse pro Command

Aufwändige Protokolle für's Undo/Redo

API getrennt

Bei uns Undo/Redo per Coobra


20

4. Commands

Aufgabe

Klasse BPMNEditior bauen

eclipse GMF plugin

erwartete Operationen / GUI Elemente: Load / Save Undo / Redo Create / Delete State Create / Delete Transition refineTaskToComplexSubProcess startDobs Unparsing später, wir schauen uns das im Dobs an


21


Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)


22

Simulation


23

Simulation


24

Simulation


25

Simulation


26

5. Unparsing

Metamodell: interne Speicherung z.B. für Code Generierung

GUI: Darstellung am Bildschirm z.B. mit GEF (oder Swing)

Unparsing: Erzeugung der Darstellung aus dem Metamodell

2 Teilprobleme:

1. Erzeugung von Darstellungselementen für Modell

2. Synchronisation bei Änderungen

?p1:Place t1:Transition

a1:Arc

pn:PetriNet

p2:Place

a2:Arc


27

Bildschirmdarstellung vs. interne Struktur

p1:Place t1:Transition

a1:Arc

pn:PetriNet

p2:Place

a2:Arc

c:Canvas

c1:Circle r1:Rectangle c1:Circle

l1:Label cn1:Connection cn2:Connection l2:Label

Model

View

GUI

Action Update


28

… The GEF Way (1)


a1:Arc

pn:PetriNet

p2:Place

a2:Arc

c:Canvas



Model

View

GUI

Update

Create/Update

Paint

Action

3 Probleme:

1. Initiales Unparsing

2. Update des Views bei Änderung am Model

3. Umsetzen von Nutzeraktionen in Modelländerungen

MVC


29

View-Update: Model-View-Controller


a1:Arc

pn:PetriNet

p2:Place

a2:Arc

c:Canvas



Model

View

Interface

Model weiß nichts über View Notification Mechanism

View weiß nichts über Model

Controller Bringt beides zusammen…

Interface

l1:Listener l2:Listener...

setGraphicalPropertyX()

…

setName(„myPlace“)

firePropertyChange(…)

setText(„myPlace“)

Controllerc1:Controller c2:Controller


30


a1:Arc

pn:PetriNet

p2:Place

a2:Arc

Interface

c:Canvas



Interface

… The GEF Way (2)

Model

View

create()setGraphicalPropertyX()

…

ControllerGEF

Action

ep1:EditPart ep2:EditPart...epf:EditPartFactory

c1:Command

ep1:EditPolicy

z.B. EMF

Draw2DFigures

„1:1“

1:1

create()


31

EMF + GEF = GMF

GEF ist schön und gut, aber …

… immer noch viel zu kompliziert und aufwändig

… nicht model-driven (Java-Hacken)

GMF (Graphical Modeling Framework)

Führt EMF und GEF zusammen

Spezifizieren statt Programmieren

… alles viel schöner, einfacher, schneller, besser !?

Sehr spezifische Anforderungen an das Modell(1:1 Umsetzung): Da gibt‘s noch was zu tun…


32

GMF Übersicht


33

Graphical Definition Model

Definiert die Diagrammelemente

Figure-Gallery enthält graphische Primitive

Nodes, Connections… binden Figures an logische Diagrammelemente

Graphical Definition Model =Visual Language


34

Tooling Definition

Toolbar

Menüs

…


35

Mapping Model / Notation Model

Bildet das Domain Model auf das Graphical Definition Model ab Im Wesentlichen 1:1 Kanten aus Objekten oder Links braucht Komposition im Modell … Etwas komplexere Mappings über

OCL-Bedingungen möglich In Zukunft (vielleicht) mal flexibler

durch „echtes“ Model-Mapping mit QVT

Mapping Model + Graphical Definition Model = Notation Model

Ordnet Tools aus Tooling Definition zu


36

Unparsing Summary


37


Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)


38

setUp

Beispiel Petri Net: Uni-Party

Idea OrgaTeam

start

findPeople

Date

Bands

Room

corePlanning go

Advertising

PartyTeam

Equipment

FireDep.

DrinkingFood.

detailingprepareopen

entryparty

begincloseIt

wrapUP

teamParty

celebrate

increment


39

Nebenläufigkeit: corePlanning

OrgaTeam

Date

Bands

Room

planing

DatePlan BandPlan RoomPlan

dateNegos bandNegos roomNegos

DateFixed BandFixed RoomFixed

reviewing

[failure]

[success]

[success]

[success]


40

Semantikvorschlag:

ordne jeder Transition ein Java-Codefragment zu

In und Out Stellen sind Variablen (a bis e) vom Typ Stelle

Transitionen werden neu geschedult wenn sich an einerIn oder Out Stelle was ändert

Transition entscheidet ob und welche Token konsumiert und produziert werden

wenn eine Transition etwas tut, wird sie neu geschedult

es gibt spezielle Input und Output stellen

Input Stellen können von außen befüllt werden

Output Stellen können von außen geleert werden

Initial Marking ist leer

a

t

b c

d e


41


Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)


42

Query – View – Transformation

Zentraler Teil der Model Driven Architecture (MDA) Initiative

„man will auch mal mit den schönen Modellen rechnen“

Konsistenzanalysen

Refactorings, …

Modell A in Modell B umbauen

Ausführung / Code Generierung


43

elementare Konsistenzanalysen:

Stellen und Transitionen eindeutig benannt

jede Transition hat mind. eine In und eine Out Stelle

jede Stelle hat mindestens eine Transition


44

inhaltliche Konsistenzanalysen:

jede Input Stelle trägt zu mind. einer Output stelle bei

jede Output Stelle wird von mind. einer Input Stelle versorgt


45

Konsistenzanalysen (2cd)

Inkonsistenzen fallen meist bei Ausführung / Code-Generierung auf

Einfache Strategie:

Fehler-Management-Objekt einführen

pro Fehler: fehler Markierungsobjekt erzeugen fehlerhafte Stelle markieren an Fehler-Management-Objekt anhängen Fehlerliste anzeigen vor jeder neuen Analyse / Ausführung / Code-Generierung alte

Fehler löschen


46

Refactorings: merge Transitions

fasse zwei Transitionen zu einer zusammen

name der ersten

Java Code von beiden hintereinander

In Stellen von beiden

Out Stellen von beiden


47

Refactorings: merge Places

fasse zwei Stellen zu einer zusammen

Name der ersten

Transitionen von beiden


48

Refactorings: split Place

ersetze Stelle durch zwei Stellen mit Transition dazwischen

die Transition liest und schreibt auf beiden neuen Stellen

Java Code kopiert alle Token vor und zurück


49


Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)


50

Interpreter

1. Stufe:

Metamodell um Ausführungsinformation erweitern: Interpreter Objekt Token mit Zeigern auf Dokumente

Interpreter: bei Stellen als Listener für Tokenänderungen subscriben bei Tokenchange, benachbarte Transitionen in Todo-Queue Transitionen aus Todo-Queue feuern, d.h. Java Code ausführen


51

Action Language

Action Language Bean-Shell www.beanshell.org

import bsh.Interpreter;

Interpreter i = new Interpreter(); // Construct an interpreter

i.set("foo", 5); // Set variables i.set("date", new Date() );

Date date = (Date)i.get("date"); // retrieve a value from a variable

// Eval a statement and get the result i.eval("bar = foo*10"); System.out.println( i.get("bar") );

// Source an external script file i.source("somefile.bsh");


52

Ampel Beispiel:

red_yellow

ry

green

yellow

yggy

yr

red

Token t = red.getFirstFromTokens();if (t != null) {

// firered.removeFromTokens (t);t.getDocument.setYellow(true);red_yellow.addToTokens (t);

}


53

class Ampel

Ampel

red : Booleanyellow : Booleangreen : Boolean


54


Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)


55

Code Generierung

Mehrere Alternativen:

Visitor der das Metamodell durchläuft und Strings in eine Datei schreibt. hoher Aufwand Indentieren und so ist doof Pretty Printer nehmen nicht sehr Wartungsfreundlich

Template basierte Code Generierung hat sich durchgesetzt


56

Template basierte Code Generierung

class $owner.name { public void initPetriNet () {

#foreach ( $place in $net.places)

Place $place = new Place ();$place.setName ("$place");

#end

#foreach ( $trans in $net.transitions)

Transition $trans = new Transition ();

#foreach ( $src in $trans.preplaces )

$trans.addToPreplaces ($src);

#end. . .

#end} }


57

Empfohlene Template Engine

google for Velocity


58

Zusammenfassung

Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)

Software Engineering 2 – Konstruktion interaktiver (CASE) Tools WS 08 / 09 Vorlesung: Albert...

Documents

Transcript of Software Engineering 2 – Konstruktion interaktiver (CASE) Tools WS 08 / 09 Vorlesung: Albert...