500 likes | 617 Views
SS 2006 Albert Zündorf, Software Engineering. Software Engineering 2 – Konstruktion interaktiver (CASE) Tools. Administratives. Vorlesung: Montags 10-12 Uhr im CIP Pool Prüfung: Projektarbeit (wir basteln uns ein Tool). Software Engineering Projekt im Hauptstudium.
E N D
SS 2006 Albert Zündorf, Software Engineering Software Engineering 2 – Konstruktion interaktiver (CASE) Tools
Administratives • Vorlesung: Montags 10-12 Uhr im CIP Pool • Prüfung: Projektarbeit (wir basteln uns ein Tool) SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Zündorf SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Überblick • Referenzarchitektur • Meta-Modell • Repository • Austauschformate • Unparsing • Checking • Code Generierung SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Repository Meta Model GUI(Commands) Generators / Interpreters QVT Import/ Export GUI(Unparsing) 1. Referenzarchitektur SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
rot next next rotgelb gelb next next grün 2. Meta-modell • abstrakter Syntaxgraph (ASG) • logische Datenstruktur hinter der Darstellung am Bildschirm • speichert Editoreingaben • beschrieben durch Klassendiagramm SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
2. Meta-modell SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 QuatschM3 braucht man nur um sich einen Knoten ins Hirn zu machen SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
3. Repository XML-Formate • generische Lade-/Speicher Routinen per Java Reflection • bestimmen aller Objekte die gespeichert werden sollen( Composite Struktur) • JDom / Xerces Basistechnologie(beherschbar) SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
3. Repository SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
4. Commands • Aktionen hinter Menüpunkten und Buttons • Viele Buttons/Menüpunkte für ein Kommando denkbar • Undo/Redo Einheiten • API Operationen • Macros SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Bildschirmdarstellung vs. interne Struktur Model Controller View SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Aufbau eines Beispiels SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Erzeugen der Darstellung SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Erzeugen der Darstellung SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Erzeugen der Darstellung SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Text Updater SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
State Mover SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Some Classes you may need ... SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Vorgehensweise • JUnit Test zur Erzeugung eines einfachen Statecharts • Fenster von letzter Woche öffnen • createUI Methode für States schreiben • Attribut-Updater schreiben • MouseListener schreiben • Model Change Listener schreiben • createUI Methode für States um Listener erweitern • JConnector von der Vorlesungsseite holen • createUI Methode für Transitions schreiben • Model Change Listener schreiben • JConnector um Pfeilspitze und JTextField erweitern • createUI Methode für Transitions um Listener erweitern • mich beeindruckt sehen SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Probleme • Statechart-Semantiken sucht euch eine aus SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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"); SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Asynchrone Nachrichten / mehrere Statecharts • state DialTone, dial (1) Event, call (1) geht an uns selbst, was passiert? SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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") SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Repository Meta Model GUI(Commands) Generators / Interpreters QVT Import/ Export GUI(Unparsing) 1. Referenzarchitektur SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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(); } } SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Empfohlene Template Engine • google for Velocity SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
rot next next rotgelb gelb next next grün Implementierung von Statecharts (schwierig) • switch case: public handleEvent(int e) { switch (currentState) { case ROT: switch (e) { case NEXT: currentState = ROTGELB; break; ... } break; case ROTGELB: ... SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
rot next next rotgelb gelb next next grün Implementierung von Statecharts (leicht) • State Design Pattern: class Rot extends BasicState {public void next () { owner.setState(new RotGelb ()); owner.getState().doAction();}} SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Owner RotGelb Rot BaseState next() next() next() rot next next rotgelb gelb next next grün Implementierung von Statecharts (leicht) current owner SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Repository Meta Model GUI(Commands) Generators / Interpreters QVT Import/ Export GUI(Unparsing) 1. Referenzarchitektur SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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, … SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Konsistenzanalysen SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Refactorings: flatten Statechart SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel
Repository Meta Model GUI(Commands) Generators / Interpreters QVT Import/ Export GUI(Unparsing) Zusammenfassung SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel