Software Engineering 2 – Konstruktion interaktiver (CASE) Tools SS 2006 Albert Zündorf, Software...

Software Engineering 2 – Konstruktion interaktiver (CASE) Tools

SS 2006

Albert Zündorf, Software Engineering

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

2

Administratives

Vorlesung: Montags 10-12 Uhr im CIP Pool

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


3

Software Engineering Projekt im Hauptstudium

Vorbesprechung: 19.4.05, 13:00 Uhr, Raum 1340

Thema: Story Driven Testing Neue Konzepte zur Testgenerierung aus Story Boards Vereinfachte Code Generierung Ausnutzung der Zwischenschritte


4

Zündorf


5

Überblick

1. Referenzarchitektur

2. Meta-Modell

3. Repository

4. Austauschformate

5. Unparsing

6. Checking

7. Code Generierung


6


Repository

Meta Model

GUI(Commands)

Generators / Interpreters

QVT

Import/ Export

GUI(Unparsing)


7

2. Meta-modell

abstrakter Syntaxgraph (ASG)

logische Datenstruktur hinter der Darstellung am Bildschirm

speichert Editoreingaben

beschrieben durch Klassendiagramm

rot

grün

gelbrotgelb

next

nextnext

next


8

2. Meta-modell


9

Meta Meta Meta

M0: Objekte / Instanzen zur Laufzeit (Jim, GET-Vorlesung)

M1: Modell Diagramme die der Benuzter eingibt(Student, Vorlesung, ...)(oft UML)

M2: Meta-Modell: Klassendiagramm, dass Benuterzdiagramm beschreibt / Tool Ebene(mit UML oder MOF)

M3: Wer beschreibt das Meta-Modell? Meta-Meta Modell (meist MOF, MOF ist selbstbeschreibend Mn+1 = Mn)

aus Sicht des Tool-Bauers ist M3 Quatsch

M3 braucht man nur um sich einen Knoten ins Hirn zu machen


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

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


12

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 -


13

3. Repository

Relationale Datenbanken

Objekte und Beziehungen werden als Tupel in Datenbanktabellen gespeichert

Zugriff per ODBC

Middleware

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

Anforderungen Datenbanken


Einfachheit -

Tool-Kopplung +

Multi-User Support +

Versionierung -

Schema-Evolution +

Scaling ++


14

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 -


15

3. Repository

Anforderungen Serialisierung XML - Formate

Datenbanken Coobra

Speichern und Laden + + + +

Einfachheit ++ + - ++

Tool-Kopplung O + + +

Multi-User Support - - + ++

Versionierung -- -- - ++

Schema-Evolution ? + + +

Scaling O - ++ -


16

4. Commands

Aktionen hinter Menüpunkten und Buttons

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

Undo/Redo Einheiten

API Operationen

Macros


17

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

FWT direkter Aufruf von Operationen Operationen beliebig gruppierbar (z.B. in Klasse StatechartEditor) FWT Elemente benutzen direkt die API


18

4. Commands

Aufgabe

Klasse StatechartEditor bauen

main Methode baut eine Instanz

initGUI Methode baut Hauptfenster aus FWT Elementen

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


19

5. Unparsing

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

GUI: Darstellung am Bildschirm z.B. mit Swing Elementen

Unparsing: Erzeugung der Darstellung aus dem Metamodell


20

Bildschirmdarstellung vs. interne Struktur

Model

Controller

View


21

Aufbau eines Beispiels


22

Erzeugen der Darstellung


23



24



25

Text Updater


26

State Mover


27

Some Classes you may need ...


28

Unparsing Summary

Suuuper aufwändig (da sollte mal jemand etwas tun ...)und die Model-Change-Listener fehlen noch

Eclipse GEF: etwas komfortabler aber viel Einarbeitung

Fujaba FSA: beta aber generische Listener

FWT: pre-alpha

aktuelles Projekt: Trimos


29

Vorgehensweise

1. JUnit Test zur Erzeugung eines einfachen Statecharts

2. Fenster von letzter Woche öffnen

3. createUI Methode für States schreiben

4. Attribut-Updater schreiben

5. MouseListener schreiben

6. Model Change Listener schreiben

7. createUI Methode für States um Listener erweitern

8. JConnector von der Vorlesungsseite holen

9. createUI Methode für Transitions schreiben

10. Model Change Listener schreiben

11. JConnector um Pfeilspitze und JTextField erweitern

12. createUI Methode für Transitions um Listener erweitern

13. mich beeindruckt sehen


30

Interpreter

1. Stufe:

Metamodell um Ausführungsinformation erweitern: Interpreter Objekt Zeiger auf aktuellen Zustand handleEvent-Methode:

Transition suchen Guards prüfen Zustand wechseln Aktionen ausführen


31

Probleme

Statechart-Semantiken sucht euch eine aus


32

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 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");


33

Asynchrone Nachrichten / mehrere Statecharts

state DialTone, dial (1) Event, call (1) geht an uns selbst, was passiert?


34

Asynchrone Nachrichten / mehrere Statecharts (cont.)

Synchrone Eventverarbeitung:

Zustand bei re-entrant Transition-Aktionen oder Entry / Do Aktionen unklar

Zustand wird eventuell verlassen bevor Do Aktion ausführbar

...

Asynchrone Eventverarbeitung:

Events werden in Queue abgelegt

Queue wird nebenläufig abgearbeitet


35

Asynchrone Nachrichten / mehrere Statecharts (cont. 2)

Zusätzliches Scheduler Objekt / Klasse

Scheduler hat viele Statechart-Interpreter

Jeder Statechart-Interpreter hat Event-Queue

Jeder Statechart-Interpreter hat event(e) Methode, die Events in die Queue ablegen

Scheduler ruft reihum die handleEvent Methode auf den Interpretern

Actions sollten Events nicht Broadcasten sondern gezielt ausliefern: statechart1.event("a")


36


Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)


37

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


38

Template basierte Code Generierung

class $state.name extends $state.super.name {

#foreach ( $trans in $state.exitTransitions)

public void $trans.name () {

// change to target stateowner.setCurrentState ($trans.targetState);

owner.getCurrent ().doAction();

}

}


39

Empfohlene Template Engine

google for Velocity


40

Implementierung von Statecharts (schwierig)

switch case:

public handleEvent(int e) {switch (currentState) {case ROT:

switch (e) {case NEXT:

currentState = ROTGELB;break;

...}break;

case ROTGELB:...

rot

grün

gelbrotgelb

next

nextnext

next


41

Implementierung von Statecharts (leicht)

State Design Pattern:

class Rot extends BasicState {

public void next () {owner.setState(new RotGelb ());owner.getState().doAction();

}}

rot

grün

gelbrotgelb

next

nextnext

next


42

Implementierung von Statecharts (leicht)

rot

grün

gelbrotgelb

next

nextnext

next BaseState

next()

Rot

next()

RotGelb

next()

Owner current

owner


43


Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)


44

Query – View – Transformation

Zentraler Teil der Model Driven Architecture (MDA) Initiative

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

Ausführung / Code Generierung

Modell A in Modell B umbauen

Konsistenzanalysen

Refactorings, …


45

Konsistenzanalysen


46

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


47

Refactorings: flatten Statechart


48


49


50

Zusammenfassung

Repository

Meta Model

GUI(Commands)


QVT

Import/ Export

GUI(Unparsing)

Software Engineering 2 – Konstruktion interaktiver (CASE) Tools SS 2006 Albert Zündorf, Software...

Documents

Transcript of Software Engineering 2 – Konstruktion interaktiver (CASE) Tools SS 2006 Albert Zündorf, Software...