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)
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++…
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!
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


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)
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
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…
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
Componenti di EMF

EMF Core





EMF Edit


Metamodello ECore
Model Change Notification & Validation
Persistenza, serializzazione, Reflection
Supporto runtime per i modelli generati
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
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
Metamodello Ecore – 2

Metamodello
Modello
UML ECore
Serializzazione
XMI
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
Costrutti UML supportati – 1
Costrutti UML supportati – 2
Costrutti UML supportati – 3
Costrutti UML supportati – 4
One Way Reference
Two Ways Reference
Factory e Package

Package:fornisce
Factory:
dà accesso
metodi
ai metadati
per la creazione
del modello,
di istanze
sia sotto
delle
varie classi,
forma
di costanti
un metodo
che di per
oggetti
accedere
del metamodello
al PackageECore
del
modello e un riferimento statico al singleton della Factory
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
Adapters

Esempio
Abbiamo
O tramite di
visto
factory:
implementazione
in precedenza di
la un
chiamata
adapter:
a eNotify:

Gli EObject hanno una lista di observers (adapters);
eNotify scorre la lista e notifica gli adapters
Gli adapters si possono aggiungere direttamente:

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…
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
Tempo di demo…
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
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
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)
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
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…
EMF + GEF – 1

Partiamo da un modello semplice, importiamolo in EMF
e generiamo le implementazioni
EMF + GEF – 2
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…
Un esempio più concreto: Visual Editor
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
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
GMF Workflow: in dettaglio
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
Feature runtime

Compartimenti espandibili
Direct Editing
Diagram Assistants
Tool e comandi comuni
Anteprima di stampa
Supporto clipboard

Vediamo qualcosa in azione…





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