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

Präsentation zum Thema: "Software Engineering 2 – Konstruktion interaktiver (CASE) Tools SS 2006 Albert Zündorf, Software Engineering."—  Präsentation transkript:

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

2 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 2 Administratives m Vorlesung: Montags 10-12 Uhr im CIP Pool m Prüfung: Projektarbeit (wir basteln uns ein Tool)

3 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 3 Software Engineering Projekt im Hauptstudium m Vorbesprechung: 19.4.05, 13:00 Uhr, Raum 1340 m Thema: Story Driven Testing l Neue Konzepte zur Testgenerierung aus Story Boards l Vereinfachte Code Generierung l Ausnutzung der Zwischenschritte

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

5 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 5 Überblick 1. Referenzarchitektur 2. Meta-Modell 3. Repository 4. Austauschformate 5. Unparsing 6. Checking 7. Code Generierung

6 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 6 1. Referenzarchitektur Repository Meta Model GUI (Commands) Generators / Interpreters QVT Import/ Export GUI (Unparsing)

7 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 7 2. Meta-modell m abstrakter Syntaxgraph (ASG) m logische Datenstruktur hinter der Darstellung am Bildschirm m speichert Editoreingaben m beschrieben durch Klassendiagramm rot grün gelbrotgelb next

8 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 8 2. Meta-modell

9 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 9 Meta Meta Meta m M0: Objekte / Instanzen zur Laufzeit (Jim, GET-Vorlesung) m M1: Modell Diagramme die der Benuzter eingibt (Student, Vorlesung,...) (oft UML) m M2: Meta-Modell: Klassendiagramm, dass Benuterzdiagramm beschreibt / Tool Ebene (mit UML oder MOF) m M3: Wer beschreibt das Meta-Modell? Meta-Meta Modell (meist MOF, MOF ist selbstbeschreibend M n+1 = M n ) aus Sicht des Tool-Bauers ist M3 Quatsch M3 braucht man nur um sich einen Knoten ins Hirn zu machen

10 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 10 Meta Object Facility – MOF m yet another meta model for class diagrams m UML notation + klare Semantik + standard Implementierung (z.B. JMI Repository) + standard Austauschformate (XMI) m Akademische Initiative m Open source m oft als Austauschformat zwischen Tools benutzt

11 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 11 3. Repository Man will ja auch mal abspeichern und wieder laden: Binäre File-Formate / Java Serialisierung m class C implements Serializable m bestimmen aller Objekte die gespeichert werden sollen ( Composite Struktur) m transiente Attribute werden ausgeklammert AnforderungenSerialisierung Speichern und Laden+ Einfachheit++ Tool-KopplungO Multi-User Support- Versionierung-- Schema-Evolution? ScalingO

12 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 12 3. Repository XML-Formate m generische Lade-/Speicher Routinen per Java Reflection m bestimmen aller Objekte die gespeichert werden sollen ( Composite Struktur) m JDom / Xerces Basistechnologie (beherschbar) AnforderungenXML - Formate Speichern und Laden+ Einfachheit+ Tool-Kopplung+ Multi-User Support- Versionierung-- Schema-Evolution+ Scaling-

13 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 13 3. Repository Relationale Datenbanken m Objekte und Beziehungen werden als Tupel in Datenbanktabellen gespeichert m Zugriff per ODBC m Middleware m Multi-User Betrieb durch Datenbank Sperrkonzepte und Transaktionen l pessimistische Sperren l Caching schwierig AnforderungenDatenbanken Speichern und Laden+ Einfachheit- Tool-Kopplung+ Multi-User Support+ Versionierung- Schema-Evolution+ Scaling++

14 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 14 3. Repository Coobra: COmmon Object Replication frAmework m Basismechanismus von Fujaba m Protokollierung aller Attributzugriffe als Deltas per Listener m Undo / Redo m Deltas Checkin / Checkout in Repository m optimistisches Locking / Merging m Integriert in Fujaba Code Generierung m manuelle Implementierung möglich AnforderungenCoobra Speichern und Laden+ Einfachheit++ Tool-Kopplung+ Multi-User Support++ Versionierung++ Schema-Evolution+ Scaling-

15 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 15 3. Repository AnforderungenSerialisierungXML - Formate DatenbankenCoobra Speichern und Laden++++ Einfachheit+++- Tool-KopplungO+++ Multi-User Support--+++ Versionierung-- -++ Schema-Evolution?+++ ScalingO-++-

16 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 16 4. Commands m Aktionen hinter Menüpunkten und Buttons m Viele Buttons/Menüpunkte für ein Kommando denkbar m Undo/Redo Einheiten m API Operationen m Macros

17 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 17 4. Commands m Normalerweise ein Objekt/eine Klasse pro Command m Aufwändige Protokolle für's Undo/Redo m API getrennt m 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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 18 4. Commands Aufgabe m Klasse StatechartEditor bauen m main Methode baut eine Instanz m initGUI Methode baut Hauptfenster aus FWT Elementen m erwartete Operationen / GUI Elemente: l Load / Save l Undo / Redo l Create / Delete State l Create / Delete Transition l startDobs l Unparsing später, wir schauen uns das im Dobs an

19 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 19 5. Unparsing m Metamodell: interne Speicherung z.B. für Code Generierung m GUI: Darstellung am Bildschirm z.B. mit Swing Elementen m Unparsing: Erzeugung der Darstellung aus dem Metamodell

20 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 20 Bildschirmdarstellung vs. interne Struktur Model Controller View

21 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 21 Aufbau eines Beispiels

22 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 22 Erzeugen der Darstellung

23 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 23 Erzeugen der Darstellung

24 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 24 Erzeugen der Darstellung

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

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

27 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 27 Some Classes you may need...

28 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 28 Unparsing Summary m Suuuper aufwändig (da sollte mal jemand etwas tun...) und die Model-Change-Listener fehlen noch m Eclipse GEF: etwas komfortabler aber viel Einarbeitung m Fujaba FSA: beta aber generische Listener m FWT: pre-alpha m aktuelles Projekt: Trimos

29 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 30 Interpreter 1. Stufe: m Metamodell um Ausführungsinformation erweitern: l Interpreter Objekt l Zeiger auf aktuellen Zustand l handleEvent-Methode: l Transition suchen l Guards prüfen l Zustand wechseln l Aktionen ausführen

31 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 31 Probleme m Statechart-Semantiken sucht euch eine aus

32 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 32 Action Language m 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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 33 Asynchrone Nachrichten / mehrere Statecharts m state DialTone, dial (1) Event, call (1) geht an uns selbst, was passiert?

34 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 34 Asynchrone Nachrichten / mehrere Statecharts (cont.) Synchrone Eventverarbeitung: m Zustand bei re-entrant Transition-Aktionen oder Entry / Do Aktionen unklar m Zustand wird eventuell verlassen bevor Do Aktion ausführbar m... Asynchrone Eventverarbeitung: m Events werden in Queue abgelegt m Queue wird nebenläufig abgearbeitet

35 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 35 Asynchrone Nachrichten / mehrere Statecharts (cont. 2) m Zusätzliches Scheduler Objekt / Klasse m Scheduler hat viele Statechart-Interpreter m Jeder Statechart-Interpreter hat Event-Queue m Jeder Statechart-Interpreter hat event(e) Methode, die Events in die Queue ablegen m Scheduler ruft reihum die handleEvent Methode auf den Interpretern m Actions sollten Events nicht Broadcasten sondern gezielt ausliefern: statechart1.event("a")

36 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 36 1. Referenzarchitektur Repository Meta Model GUI (Commands) Generators / Interpreters QVT Import/ Export GUI (Unparsing)

37 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 37 Code Generierung Mehrere Alternativen: m Visitor der das Metamodell durchläuft und Strings in eine Datei schreibt. l hoher Aufwand l indentieren und so ist doof pretty printer nehmen l nicht sehr Wartungsfreundlich m Template basierte Code Generierung l hat sich durchgesetzt

38 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 38 Template basierte Code Generierung class $state.name extends $state.super.name { #foreach ( $trans in $state.exitTransitions) public void $trans.name () { // change to target state owner.setCurrentState ($trans.targetState); owner.getCurrent ().doAction(); }

39 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 39 Empfohlene Template Engine m google for Velocity

40 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 40 Implementierung von Statecharts (schwierig) m 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

41 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 41 Implementierung von Statecharts (leicht) m State Design Pattern: class Rot extends BasicState { public void next () { owner.setState(new RotGelb ()); owner.getState().doAction(); } } rot grün gelbrotgelb next

42 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 42 Implementierung von Statecharts (leicht) rot grün gelbrotgelb next BaseState next() Rot next() RotGelb next() Owner current owner

43 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 43 1. Referenzarchitektur Repository Meta Model GUI (Commands) Generators / Interpreters QVT Import/ Export GUI (Unparsing)

44 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 44 Query – View – Transformation m Zentraler Teil der Model Driven Architecture (MDA) Initiative m man will auch mal mit den schönen Modellen rechnen m Ausführung / Code Generierung m Modell A in Modell B umbauen m Konsistenzanalysen m Refactorings, …

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

46 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 46 Konsistenzanalysen (2cd) m Inkonsistenzen fallen meist bei Ausführung / Code-Generierung auf Einfache Strategie: m Fehler-Management-Objekt einführen m pro Fehler: l fehler Markierungsobjekt erzeugen l fehlerhafte Stelle markieren l an Fehler-Management-Objekt anhängen l Fehlerliste anzeigen l vor jeder neuen Analyse / Ausführung / Code-Generierung alte Fehler löschen

47 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 47 Refactorings: flatten Statechart

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

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

50 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel 50 Zusammenfassung Repository Meta Model GUI (Commands) Generators / Interpreters QVT Import/ Export GUI (Unparsing)