Sviluppo di tool basati su un metamodello editabile graficamente

1. Davide Devescovi - 9 maggio 2006 Argomenti Avanzati di Ingegneria del Software - aa 2005/06 Sviluppo di tool basati su un metamodello editabile graficamente Eclipse Modeling Framework (EMF) Graphical Editing Framework (GEF) Graphical Modeling Framework (GMF)

2. Che cos’è Eclipse? • Nome normalmente associato a Eclipse SDK: Java IDE (integrated development environment) • Eclipse SDK è un tool basato su Eclipse Platform: insieme di componenti per lo sviluppo di tool e applicazioni arbitrarie • Sottoinsiemi di componenti consentono lo sviluppo di applicazioni (esempio: RCP, Rich Client Platform) • EP sviluppata in Java, ma non è solo Java: diventa un Java IDE aggiungendo JDT (Java Development Tools), ma esiste CDT per programmare in C\C++…

3. Eclipse Platform Overview – 1 • Supporta la costruzione di una varietà di tools per lo sviluppo di applicazioni • Supporta un insieme non ristretto di sviluppatori di tools, inclusi ISV (independent software vendors) • Supporta tools per manipolare contenuti arbitrari (HTML, Java, C, JSP, EJB, XML, GIF…) • Integration Point: facilita l’integrazione di tools sia tra contenuti diversi, sia tra differenti fornitori di tools • Supporta ambienti di sviluppo basati o meno su GUI • Funziona su un’ampia gamma di OS, tra cui Windows, Linux, Mac OS X, Solaris AIX… • Sfrutta la popolarità di Java per la programmazione di tools • Naturalmente è open source!

4. Eclipse Platform Overview – 2 • Platform Runtime: kernel che fornisce funzionalità di base • Workbench: il cuore della UI, è “quello che si vede quando si lancia Eclipse”; presenta all’utente una UI estensibile • Workspace: spazio di lavoro dell’utente, costituito da risorse (progetti, dir, file…); ha sistemi di history e di notifica delle modifiche apportate alle risorse • Help e Team

5. Architettura a plug-in – 1 • Tutti i componenti di EP sono plugin (tranne Platform Runtime) • Plugin: la più piccola unità funzionale di EP sviluppabile e distribuibile separatamente • Plugin = codice Java (JAR) + risorse varie; può essere composto da più frammenti • Plugin manifest • manifest.mf = dipendenze runtime • plugin.xml = elenco di extension points ed extensions (interconnessioni con altri plugin)

6. Architettura a plug-in – 2 • All’avvio, Platform Runtime scopre i plugin, legge i loro manifesti e crea il Plugin Registry, reso disponibile tramite Platform API • I plugin possono essere aggiunti, sostituiti o rimossi anche dopo l’avvio • Un plugin viene attivato solo quando il suo codice deve essere eseguito: l’avvio è molto rapido • Una volta attivato, un plugin accede al Registry per scoprire le extensions collegate ai suoi extension points: non è necessario che i plugin che lo estendono vengano attivati • Quindi grazie al Registry i plugin hanno sempre a disposizione le informazioni rilevanti riguardanti il contesto di esecuzione

7. Esempi reali • Plugin per i più svariati linguaggi (C, C++, C#, Symbian per Nokia, LaTeX…) • IBM WebSphere: versione commerciale di Eclipse con ulteriori funzionalità • RCP di ogni genere, commerciali e non…

8. Eclipse Modeling Framework: che cos’è? • Framework open source per la generazione di tools e applicazioni basati su un modello strutturato • Modello = specifica di oggetti, attributi, operazioni, relazioni e vincoli di un’applicazione: in sostanza class diagram • EMF offre: • Generazione automatica di codice Java a partire dal modello • Possibilità di modifiche al codice generato • Reflective API e generazione dinamica del modello • Persistence API: supporto XMI/XML per (de)serializzazione • Supporto per la generazione di editor

9. Componenti di EMF • EMF Core • Metamodello ECore • Model Change Notification & Validation • Persistenza, serializzazione, Reflection • Supporto runtime per i modelli generati • EMF Edit • Usato per costruire editor e visualizzatori per il modello • EMF Codegen • Generatore di codice per componenti basati su Core ed Edit • Framework estensibile per l’importazione di modelli

10. Metamodello Ecore – 1 • EObject è l’equivalente di java.lang.Object: • eClass(), come Object.getClass(), dà informazioni sull’istanza, ad esempio la sua EClass • Reflective API: eGet(), eSet() per accedere ai dati. Equivalente a java.lang.reflect.Method.invoke() ma più efficiente • EObject estende Notifier, che consente di monitorare le modifiche dei dati dell’oggetto • ECore ha propri data type (EFloat, EChar, EBoolean), serializzabili

11. Metamodello Ecore – 2 • Metamodello ECore • Serializzazione XMI • Modello UML

12. Definire un modello EMF • Il code generator può importare modelli di vari tipi: • ECore model scritto direttamente in XMI • XML Schema • Diagramma UML (supporto per Rational Rose) • Annotated Java

13. Costrutti UML supportati – 1

14. Costrutti UML supportati – 2

15. Costrutti UML supportati – 3

16. Costrutti UML supportati – 4

17. One Way Reference

18. Two Ways Reference

19. Factory e Package • Package: dà accesso ai metadati del modello, sia sotto forma di costanti che di oggetti del metamodello ECore • Factory: fornisce metodi per la creazione di istanze delle varie classi, un metodo per accedere al Package del modello e un riferimento statico al singleton della Factory

20. Reflective API • Accesso generico a metodi e attributi • Usando dati reperiti dal Package • Meno efficiente rispetto a una chiamata diretta • Usato da EMF.Edit per creare comandi generici

21. Adapters • Esempio di implementazione di un adapter: • O tramite factory: • Abbiamo visto in precedenza la chiamata a eNotify: • Gli EObject hanno una lista di observers (adapters); eNotify scorre la lista e notifica gli adapters • Gli adapters si possono aggiungere direttamente:

22. Personalizzare le implementazioni • Metodi personalizzati possono essere aggiunti normalmente, non verranno modificati dalla rigenerazione del codice • I metodi generati sono contraddistinti dal tag @generated: modifiche a questi metodi saranno perse • Soluzione: rimuovere il tag. Ma se il modello cambia non ho aggiornamento automatico… • “Overload” dei metodi…

23. Varie ed eventuali • Validazione: l’utente deve specificare le condizioni che fanno fallire il check • Operazioni: EMF genera lo scheletro dei metodi dichiarati nelle interfacce, ma il comportamento non è modellizzato  l’utente deve implementare il metodo • Bidirectional reference handshaking • Ereditarietà multipla: bisogna scegliere una classe come base per l’implementazione, le altre diventano interfacce le cui implementazioni vengono copiate nella classe figlia • Dynamic EMF: modelli ECore possono essere definiti dinamicamente in memoria, istanziando elementi tramite l’ECore API

24. Tempo di demo…

25. Graphical Editing Framework: che cos’è? • Framework open source per lo sviluppo di rappresentazioni grafiche di modelli esistenti • Permette di costruire editor grafici per la modifica di modelli usando funzioni quali drag & drop, copy and paste… • Ad esempio editor UML, ma anche tool per creare pagine web, forms ecc… • Due componenti: • Draw2D, sistema grafico lightweight per la visualizzazione • GEF vero e proprio

26. Draw2D • Libreria autocontenuta, utilizzabile indipendentemente da GEF o Eclipse • Si appoggia su SWT: gli oggetti Draw2D sono hostati da un controllo heavyweight SWT • Feature principali: • LightweightSystem: classe responsabile del mappaggio tra SWT e Draw2D (eventi, repaint degli oggetti…) • Figure: non limitate alla forma rettangolare; predisposte per la notifica di listeners • Borders, layout, layers: grande flessibilità di visualizzazione • Connections, anchors, routers

27. GEF Framework • Basato sul pattern Model-View-Controller • Il modello in questo caso è codice Java già implementato • Le viste sono realizzate da Draw2D • I controller sono le EditParts: definiscono il mappaggio tra modello e viste • In genere bisogna creare un EditPart per ciascuna classe del modello: stessa gerarchia • Due tipi principali di EditPart: • GraphicalEditPart (associato a una figura/classe) • ConnectionEditPart (connessione tra GraphicalEditPart)

28. EditParts • Create tramite Factory • Un’EditPart va attivata per informare GEF della sua esistenza; viene disattivata quando non serve più • GraphicalEditPart: deve creare una figura (Draw2D), aggiornarla in base alle modifiche del modello ed eliminarla quando necessario • ConnectionEditPart: è in realtà una GraphicalEditPart con campi source e target

29. Usare EMF e GEF insieme • Vantaggio immediato: code generation di EMF… • La notifica delle modifiche al modello è già presente in EMF • Le implementazioni generate rimangono consistenti al variare del modello • La Reflective API di EMF consente di usare il nostro editor su modelli EMF generici • Problema: espandere EMF.Edit con GEF non è immediato, non sono stati pensati per cooperare • Proviamo allora a sviluppare un piccolo editor usando un modello EMF in GEF…

30. EMF + GEF – 1 • Partiamo da un modello semplice, importiamolo in EMF e generiamo le implementazioni

31. EMF + GEF – 2

32. EMF + GEF – 3 • Creiamo una serie di Commands: operazioni che modificano effettivamente il modello • Creiamo EditParts per ogni classe (più o meno…) • Implementiamo i metodi createFigure per associare figure Draw2D agli EditParts • Ci mettiamo “in ascolto” (EMF adapters!) e definiamo il comportamento in caso di modifica del modello • Definiamo le EditPolicies: come si deve comportare una EditPart quando succede qualcosa alla vista • Meglio vedere “dal vivo” per capire meglio…

33. Un esempio più concreto: Visual Editor

34. Graphical Modelling Framework: che cos’è? • Framework open source per lo sviluppo di editor grafici di modelli… dov’è la novità? • Si appoggia su EMF e GEF per creare editor in maniera molto più semplice • Cerca di sostituire la stesura di codice grazie a una serie di modelli intermedi e di mappaggi tra di essi assistiti da wizard • Due parti principali: • Tooling: serie di editor per creare modelli alla base dell’editor grafico + generatore per creare l’implementazione dell’editor • Runtime: classi su cui si appoggia l’editor generato • E’ un progetto ancora in fase di sviluppo

35. GMF Workflow • Domain model (informazioni non grafiche) • Diagram definition model (elementi grafici) • Mapping model (mappaggio tra i due modelli) • Generazione automatica editor grafico • Customizzazione del codice generato

36. GMF Workflow: in dettaglio

37. I modelli di GMF • Domain model: modello ECore del dominio che ci interessa; non è necessario cominciare da qui, ma di norma lo si fa • Graphical definition: il modello che rappresenta gli oggetti grafici che verranno usati dall’editor • Tooling definition: rappresenta la palette di strumenti a disposizione dell’utente dell’editor • Mapping definition: esegue il mappaggio tra i tre modelli precedenti • Generator model: modello che consente la generazione del diagramma

38. Feature runtime • Compartimenti espandibili • Direct Editing • Diagram Assistants • Tool e comandi comuni • Anteprima di stampa • Supporto clipboard • Vediamo qualcosa in azione…

39. Linkografia • http://www.eclipse.org - Eclipse Plaftorm • http://www.eclipse.org/emf/docs.php - EMF • http://www.eclipse.org/gef/reference/articles.html - GEF • http://www.eclipse.org/gmf - GMF • http://wiki.eclipse.org/index.php/Graphical_Modeling_Framework • http://www.eclipse.org/vep - Visual Editor • IBM Redbook “Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework” http://www.redbooks.ibm.com/abstracts/sg246302.html