1 / 50

Software Engineering 2 – Konstruktion interaktiver (CASE) Tools

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.

wyatt
Download Presentation

Software Engineering 2 – Konstruktion interaktiver (CASE) Tools

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

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

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

  6. 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

  7. 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

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

  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 QuatschM3 braucht man nur um sich einen Knoten ins Hirn zu machen SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  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 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 • 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

  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) SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  15. 3. Repository SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  16. 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

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

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

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

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

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

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

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

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

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

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  29. 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

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

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

  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"); SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  33. 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

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  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") SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

  36. 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

  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 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(); } } SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

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

  40. 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

  41. 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

  42. 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

  43. 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

  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, … SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

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

  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 SS 2005 Software Engineering 2 Albert Zündorf, University of Kassel

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

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

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

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

More Related