DEFINIZIONE DI UN SUPPORTO ALLA ESECUZIONE DEL WORKFLOW DI PASSI

Transcript

1 SCUOLA DI SCIENZE DI BASE E APPLICATE Laurea in Informatica Dipartimento di Matematica e Informatica DEFINIZIONE DI UN SUPPORTO ALLA ESECUZIONE DEL WORKFLOW DI PASSI TESI DI LAUREA DI SALVATORE PERNA RELATORE RAFFAELE GIANCARLO CO-RELATORE MASSIMO COSSENTINO ANNO ACCADEMICO

2 Indice dei contenuti 1. Introduzione 3 2. Aspetti teorici del problema CASE e metacase Un esempio di metacase: MetaEdit Un meta-modello per la modellazione di processi: SPEM Stato dell arte e tecnologie usate BPMN e XPDL Business Process Modeling Notation Xml Process Definition Language Scelta delle tecnologie usate Software Realizzato Overview del software Dettagli implementativi Valutazione delle Prestazioni Conclusioni 29 Bibliografia 30 2

3 1. Introduzione Lo sviluppo di sistemi informatici con complessi application domains è sempre stato argomento di ottimizzazioni e di ricerche di metodologie che ne semplificassero lo sviluppo. L ingegneria del software è proprio la disciplina che si occupa di formalizzare e definire queste metodologie. Quello che accomuna molte di queste metodologie è sicuramente l intervento di molteplici attori che si dividono il carico di lavoro, a seconda delle competenze, del processo di lavoro. Diventa importante quindi definire un linguaggio che permetta di definire e descrivere il processo in maniera univoca e interpretabile da tutti gli attori coinvolti. In questa tesi parleremo a proposito di SPEM, il meta-modello per la modellazione di processi definito da OMG, di BPMN, la notazione di modellazione dei processi aziendali anch essa definita da OMG, e di XPDL, il linguaggio per la definizione XML dei processi prodotto dalla WfMC. L aumentare del numero degli attori e della complessità e vastità dei processi ha fatto sì che l automazione di questi processi, della divisione dei compiti e della gestione del flusso dei work products diventasse necessaria. A tal proposito in questa tesi verranno introdotti i concetti di CASE e metacase tools, strumenti largamente utilizzati nell ingegneria del software, parlando in particolare di MetaEdit+. Il lavoro di tesi verrà quindi finalizzato nello sviluppo di una parte del solution domain dei problemi fin ora espressi: la realizzazione di un interfaccia di supporto all esecuzione del workflow di PASSI come plug-in della piattaforma di sviluppo Eclipse. Diventa interessante a questo punto fare una breve introduzione ai sistemi ad agenti e a PASSI. Un agente è un entità software che è capace di agire con un 3

4 certo grado di autonomia al fine di svolgere tasks per conto di qualcun altro (sia esso un utente o un altro software). Così come un oggetto è definito in termini di metodi e attributi, un agente è definito in termini di behavior. Le definizioni di agente sono molteplici, accomunate da concetti come: Autonomia: gli agenti hanno la capacità di effettuare decisioni, scegliere i tasks, definire priorità, assumere comportamento guidato da obbiettivi in completa autonomia, in assenza di intervento umano. Il codice infatti non viene eseguito su richiesta ma rimane costantemente in running. Abilità sociali: gli agenti sono in grado di interagire con altri componenti attraverso tipologie varie di comunicazione e collaborazione; possono collaborare per portare a termine un task. Reattività: gli agenti percepiscono l ambiente e il contesto in cui sono immersi e reagiscono ai cambiamenti in maniera appropriata. Pro-attività: gli agenti non agiscono solo in relazione a cambiamenti nell ambiente ma sono in grado di generare obbiettivi e di agire in maniera razionale al fine di raggiungerli. È evidente come le potenzialità dei sistemi ad agenti siano notevoli. Gli esempi di sistemi ad agente sono molteplici, dall E-Commerce (gli agenti possono rappresentare sia venditori che acquirenti) alla gestione dei sistemi di trasporto, dal trading in borsa allo shopping automatizzato (i cosiddetti shopping bots). Tra le varie metodologie a supporto dello sviluppo di sistemi ad agenti definite dall AOSE (Agent Oriented Software Engeneering), e in particolare tra quelle che si occupano dei MAS, i Multi-Agent System, PASSI (Processo per l Implementazione e lo Sviluppo di Società di Agenti) risulta una tra le più importanti. PASSI [1] è una metodologia passo-per-passo e dai-requisiti-alcodice per la progettazione e lo sviluppo di società multi-agente, che integra modelli di progettazione e concetti propri sia dell object-oriented software engeneering (OOSE) sia degli approcci all intelligenza artificiale estendendo la notazione UML. 4

5 Nel processo PASSI, l elemento corrispondente al processo in SPEM è chiamato modello, ed è composto da fasi. I modelli e le fasi di PASSI (schematizzate in figura 4) sono: 1. System Requirements Model: un modello dei requisiti del sistema. È composto da cinque fasi: a. Domain Requirements Description (DRD) b. Agents Identification (AI) c. Agent Structure Exploration (ASE) d. Roles Identification (RI) e. Tasks Specification (TS) 2. Agent Society Model: un modello delle interazioni sociali e delle dipendenze tra i vari agenti coinvolti nella soluzione. È composto da tre fasi: a. Domain Ontology Description (DOD) b. Communication Ontological Description (COD) c. Roles Description (RD) 3. Agent Implementation Model: un classico modello dell architettura della soluzione in termini di classi e metodi; la differenza sostanziale con l approccio object-oriented è la presenza di due differenti livelli di astrazione: il livello sociale (multi-agent) e il livello single-agent. Ognuno dei due livelli è composto da due fasi: a. Agent Structure Definition (ASD) b. Agent Behavior Devinition (ABD) 4. Code Model: un modello della soluzione al livello codice che è composto dalle seguenti fasi: a. Code Reuse (CR) b. Code Production (CP) 5

6 5. Deployment Model: un modello della distribuzione delle parti del sistema nelle unità hardware e della loro migrazione tra le varie unità. È composto da una fase: a. Deployment Configuration (DC) 6. Testing: l attività di testing è stata divisa in due fasi differenti: a. Agent Test b. Society Test Per lo scopo di questa tesi non è richiesto scendere ulteriormente in profondità nelle specifiche PASSI, nel qual caso si voglia si rimanda alla lettura di [1]. 6

7 2. Aspetti teorici del problema Prima di scendere nello specifico dello stato dell'arte e delle tecnologie scelte per realizzare il progetto, è bene soffermarci un attimo sugli aspetti più generici del problema, iniziando proprio dal concetto di workflow: così come definito dalla WfMC 1 (Workflow Management Coalition, l'organizzazione mondiale che si occupa di definire gli standard relativi a workflow e BPM), un workflow è l'automazione di un processo aziendale, in parte o nella sua interezza, durante il quale documenti, informazioni o compiti sono passati da un partecipante ad un altro per svolgere attività, secondo un set di regole procedurali. Un processo aziendale (business process o BP) è quindi un insieme di attività (che possono comprendere vari partecipanti) collegate tra loro al fine di produrre determinati output a partire da input definiti. La necessità di automatizzare quanto più possibile i processi aziendali nasce proprio dall'ottimizzazione di tempi e costi e dalla drastica riduzione di errori umani che questa comporta, soprattutto nell'ottica di organizzazioni complesse e flussi di lavoro che comprendono numerosi partecipanti. A tal proposito, entrando nel campo dello sviluppo di sistemi informativi, diventa opportuno parlare di CASE tools e metacase. 2.1 CASE e metacase [3] L'ingegneria del software si occupa di fornire le metodologie per sviluppare complessi sistemi informativi quanto più efficienti e privi d'errore possibile, nonostante queste non siano sempre facilmente applicabili. I CASE (Computer Aided Software Engineering) tools forniscono l'automazione necessaria a semplificare l'applicabilità di tale disciplina, nonostante anch'essi non siano privi di limiti. 1 Glossario WfMC, 7

8 Il limite più grande dei CASE tools tradizionali è infatti quello di essere legati ad un solo metodo: vengono sviluppati a partire da un metodo definito (è molto diffuso in tal senso l'uml nei tool per la modellazione object-oriented) e per tanto risultano poco flessibili nel caso di domini applicativi che richiedono concetti o notazioni non incluse nel metodo stesso. I modelli così creati risultano quindi di difficile lettura e comprensione da parte degli utenti finali in quanto i concetti in essi utilizzati sono semanticamente distanti dal loro dominio applicativo. I progetti di sviluppo software e le organizzazioni d'altronde differiscono sostanzialmente l'una dall'altra, e si evolvono nel tempo. Diventa palese quindi che un solo metodo non può essere adatto a tutti i casi. La soluzione ideale è quindi quella di personalizzare il metodo a seconda del dominio applicativo e delle necessità dell'utente. E' in questo contesto che si inserisce metacase: il pensiero alla base è proprio quello di fornire metodi flessibili attraverso la modifica dell'architettura stessa dei tool. I CASE tools tradizionali si basano su una architettura a due livelli: il primo contiene il metodo, che è programmato direttamente all'interno del tool e che definisce quali modelli possono essere creati e analizzati. Il fatto che sia programmato nel tool implica che solo il produttore del tool può effettuare modifiche al metodo. Il secondo livello è quello composto dai modelli stessi. MetaCASE modifica questa architettura rendendola a tre livelli: il livello più basso è lo stesso dell'architettura CASE, composto dai modelli che possono essere creati con il metodo. Il livello intermedio piuttosto che essere composto dal metodo programmato all'interno del tool, contiene un modello del metodo (meta-modello), costituito dalle regole, le notazioni e i concetti chiave del metodo in questione. La potenza di metacase sta proprio nella possibilità di modificare o cambiare il metamodello a seconda delle necessità. Il terzo livello, il più alto, contiene il linguaggio di meta-modellazione che 8

9 consente di descrivere i metodi. Questo è il livello che viene programmato direttamente all'interno del software metacase, analogamente a come viene programmato il metodo nei tradizionali CASE tools Un esempio di metacase: MetaEdit+ [4] MetaEdit+ è un ambiente multi-utente e multi-piattaforma che supporta sia lo sviluppo di sistemi che lo sviluppo di metodi. Si presenta quindi anche come un CAME (Computer Aided Method Engineering) tool, dal momento che a differenza di altri metacase tools mette a disposizione strumenti per gestire, integrare e riutilizzare i metodi. E' interessante vedere come a livello di CAME tool, in MetaEdit+ i tre livelli dell'architettura operano un livello di astrazione in più verso l'alto rispetto ai livelli metacase: il livello più alto è chiamato il livello di meta-metamodellazione, dove sintassi e semantica di vari linguaggi di meta-modellazione sono definite. Gli altri due livelli corrispondono quindi ai due livelli più in alto dell'architettura metacase tradizionale. MetaEdit+ è composto da due tool principali: il workbench, che copre la componente CAME, e il modeler, che copre la componente CASE. Nel workbench si definiscono i concetti e le regole del linguaggio (graficamente o tramite l'utilizzo di strumenti di meta-modellazione), si disegnano gli elementi della notazione con il Symbol Editor (o si importano elementi grafici già creati) e si creano i generatori per produrre codice, configurazioni, analisi, etc. Una volta definito il linguaggio di modellazione si può iniziare a produrre modelli. A questo punto il meta-modello può essere modificato in qualsiasi momento e i modelli esistenti vengono aggiornati automaticamente alla nuova versione del linguaggio. Nel modeler si creano i modelli, si genera il codice e la documentazione. Essendo un ambiente multi-utente e multi-piattaforma inoltre, MetaEdit+ offre la possibilità di essere eseguito su vari clients contemporaneamente (collegati 9

10 ad un server tramite una rete) e su varie piattaforme. 2.2 Un meta-modello per la modellazione di processi: SPEM SPEM [6] (Software & Systems Process Engineering Metamodel) è un metamodello usato per descrivere e modellare processi. E' una specifica OMG (Object Management Group) ed è definito come un profilo UML, di conseguenza molti degli elementi SPEM sono descritti tramite l'utilizzo di classi UML. Il behaviour del processo è descritto tramite diagrammi di attività e diagrammi di stato, mentre la struttura del processo è descritta tramite diagrammi di classe. Gli elementi principali di SPEM sono: Process role: definisce il ruolo che una o più persone possono svolgere all'interno del progetto. Può essere identificato come primario o addizionale. E' responsabile di uno o più work products e di svolgere specifiche activities. E' rappresentato tramite un attore UML stereotipato come <<process role>>. Work Product: qualsiasi cosa prodotta, modificata o consumata da un processo. Possono essere identificati come obbligatori o opzionali, e possono essere composti da altri work products (ciò è rappresentato tramite composizione o aggregazione UML). Una associazione tra ruolo e work product definisce chi è il process role responsabile per quel determinato work product. E' rappresentato tramite una classe UML stereotipata come <<work product>>. Activity: è un task relativamente breve in durata, assegnabile ad un ruolo. È rappresentato tramite una operazione (su una classe) stereotipata come <<activity>>. Ha work products di input e di output, rappresentati come parametri e può essere decomposta in passi atomici. E' consigliabile per altro che le activities creino nuovi prodotti o cambino lo stato di work 10

11 products esistenti (altrimenti si può non essere certi che l'activity sia effettivamente stata eseguita). Nel modellare processi adattivi può essere estremamente utile identificare e descrivere i diversi stati in cui un work product può trovarsi all'interno del suo ciclo vitale (soprattutto se si riferiscono a vari gradi di completezza, dando così criteri oggettivi per la sua descrizione). In questo caso si possono usare diagrammi di stato UML per identificare stati e transizioni possibili. Un modo interessante di fornire informazioni aggiuntive è fornito tramite le guidance: sostanzialmente note che possono essere associate a qualsiasi elemento SPEM (anche se spesso sono associate ad activities e work products). Di seguito è riportato un esempio di diagramma SPEM Figura 1 - Esempio di diagramma SPEM Object Management Group, Software & System Process Engineering Meta-Model Specification version 2.0, 2008, Figura 7.1 p

12 3. Stato dell arte e tecnologie usate L automazione dei business process passa dai workflow enactment software, aggregati di workflow engines, software che si occupano di definire ed eseguire il processo, in parte o nella sua interezza; essi si occupano quindi di monitorare e gestire lo stato delle attività e, cosa assai più interessante, determina le transizioni da un attività all altra e da un attore all altro in base al modello del processo su cui si basa. Figura 2 - Strutture e tipologie di Workflow Enactment Systems 3 In Figura 2 è riportato uno schema che descrive le varie strutture e tipologie di sistemi che hanno lo scopo di mettere in atto workflows. Come è possibile 3 Workflow Management Coalition, The Workflow Reference Model, , fig 4, p 16 12

13 notare, linguaggi e notazioni per il Process Definition diventano quindi di fondamentale importanza all interno dei workflow enactment systems. Tra gli standard utilizzati ne emergono due per quanto riguarda diffusione e compatibilità: BPMN e XPDL. 3.1 BPMN e XPDL BPMN (Business Process Modeling Notation [5]) e XPDL (Xml Process Definition Language [7]) sono due formati standardizzati rispettivamente dalla OMG e dalla WfMC per la specifica dei processi di business. Il primo è stato creato per definire e fornire una notazione facile da capire e interpretare per tutti gli utenti, dagli analisti ai tecnici. Il secondo per fornire un modo di scambiare definizioni di processo tra software diversi. S può affermare inoltre che XPDL rappresenta la serializzazione XML di BPMN Business Process Modeling Notation [5] BPMN supporta tre principali categorie di modelli di processi di business: 1. Processi o Orchestrazioni I modelli di orchestrazione rappresentano il punto di vista di una singola azienda o di un organizzazione sui flussi di processo. Le orchestrazioni includono: Business Process (interni) Privati; Processi pubblici. 2. Coreografia Un modello di coreografia definisce i comportamenti attesi tra i partecipanti al processo, in pratica definisce un contratto procedurale. In una coreografia i soggetti dell interazione non appartengono ad un medesimo contesto. 13

14 3. Collaborazione Un modello di collaborazione mostra le interazioni tra due o più partecipanti (business entitities). Una collaborazione può contenere una coreografia e una o più orchestrazioni. In particolare, i Business Process privati sono quelli interni ad una specifica organizzazione, e sono generalmente chiamati workflow o processi BPM. Nell ambito dei servizi Web un sinonimo molto diffuso è orchestrazione dei servizi (Orchestration). I processi privati si distinguono in due tipi: Eseguibili e non-eseguibili. I primi sono processi modellati con lo specifico scopo di essere eseguiti. I secondi invece sono quei processi privati modellati con lo scopo di documentare il behaviour del processo a un livello di dettaglio definito da chi lo ha modellato. Quindi, le informazioni necessarie all esecuzione tipicamente non sono incluse in un processo non-eseguibile. Nel caso si utilizzi una notazione simile alle swimlanes (ad es. le Collaborazioni), allora un processo privato sarà interamente contenuto all interno di una pool; il flusso dei messaggi è l unico elemento che fa eccezione e può attraversare i confini della pool al fine di mostrare le interazioni tra processi privati separati. Le uniche attività incluse nel processo pubblico sono quelle usate per comunicare con gli altri partecipanti (tutte le attività interne del processo privato non sono quindi visibili). In breve, il processo pubblico mostra al mondo esterno il flusso e l ordine dei messaggi che sono necessari ad interagire con quel processo. Una coreografia è simile in alcuni aspetti ad un processo privato, visto che consiste di una rete di attività, eventi e gateways(controllori di flusso di eventi). D altro canto però, una coreografia differisce nel fatto che le attività sono interazioni che rappresentano un insieme di scambi di messaggi, che coinvolgono due o più partecipanti. In più, a differenza di un normale processo, non vi è alcun central controller, responsable entity o observer. 14

15 In una collaborazione invece lo scambio di messaggi tra i partecipanti è mostrato da un message flow che connette due partecipanti (oppure due oggetti al loro interno). Si possono per altro mostrare i messaggi associati ai message flows. Una collaborazione può essere mostrata, inoltre, attraverso due o più processi pubblici che comunicano l uno con l altro. L obiettivo di BPMN, è quello di creare un meccanismo semplice e facilmente comprensibile per la creazione di modelli di Business Process, mantenendo però allo stesso tempo la capacità di gestire la complessità intrinseca degli stessi. L approccio usato per gestire questi due requisiti contrastanti è stato quello di organizzare gli aspetti grafici della notazione in categorie specifiche. Questo fa sì che ci sia un piccolo insieme di categorie di notazione cosicché il lettore di un diagramma BPMN possa facilmente riconoscere i tipi base degli elementi e comprendere il diagramma. All interno delle categorie base degli elementi si possono inserire variazioni e informazioni aggiuntive a supporto dei requisiti di complessità senza però cambiare drasticamente il look del diagramma. Le cinque categorie principali di elementi sono: 1. Flow Objects rappresentazione grafica degli elementi utili a descrivere il behaviour di un business process, quali Events, Activities e Gateways; 2. Data rappresentati con i quattro elementi Data Objects, Data Inputs, Data Outputs e Data Stores; 3. Connecting Objects suddivisi in quattro oggetti per la comunicazione Sequence Flows, Message Flows, Associations e Data Associations; 4. Swimlanes suddivise in Pools e Lanes; 5. Artifacts Group e Text Annotation sono quelli standardizzati. Per le notazioni grafiche degli elementi BPMN si rimanda alla consultazione delle specifiche OMG [1]. 15

16 3.1.2 Xml Process Definition Language [7] XPDL invece vuole fornire un modo di scambiare definizioni di processo tra software diversi. Esso si occupa quindi di dare delle specifiche per l interfaccia tra il process definition e il workflow engine (vedi figura 3). Quindi un workflow engine compatibile con XPDL potrà eseguire un processo definito in qualsiasi tool compatibile con XPDL, a prescindere dal produttore dei software. In definitiva, quello che XPDL offre (insieme ad altre specifiche WfMC) sono proprio gli strumenti per poter parlare di inter-operatività nei sistemi software orientati alla gestione e all esecuzione di workflow. Ricordiamo pure che XPDL può essere usato come formato file per i diagrammi BPMN (visto che ne rappresenta una sua serializzazione) risolvendo alcuni dei problemi sulla portabilità e sulla mancanza di una semantica d esecuzione definita. Per una mappatura tra BPMN e XPDL si rimanda alla consultazione dell apposito documento OMG [7]. Figura 3 - Componenti e Interfacce del Workflow Reference Model 4 4 Workflow Management Coalition, The Workflow Reference Model, , fig 6, p 20 16

17 3.2 Scelta delle tecnologie usate L obiettivo del lavoro di tesi riguarda lo sviluppo di un supporto all esecuzione del workflow di PASSI indirizzato ai designer. Considerati questi come target, quindi, si è scelto di perseguire l usabilità come requisito fondamentale. Di conseguenza, in considerazione anche della natura dei frammenti specifici della metodologia con cui il supporto si andrà ad interfacciare (che sono stati sviluppati come plug-in del framework Eclipse), si è scelto di integrare quanto più possibile il tool con Ecplise, come verrà ampiamente mostrato nel prossimo capitolo. 17

18 4. Software realizzato Il software realizzato in questa tesi svolge la funzione di interfaccia di processo per la metodologia PASSI. L'obiettivo è quello di fornire un interfaccia facilmente interpretabile, visivamente efficace ed intuitiva, adatta ai novizi di PASSI ma allo stesso tempo non restrittiva verso i designer più esperti. A tale scopo si è deciso di non adottare la rappresentazione SPEM del workflow di Passi, che nella sua completezza sarebbe risultato ostico da rappresentare soprattutto a causa dei numerosi cicli iterativi, in favore di una più semplice rappresentazione che mantiene i contenuti informativi interessanti per lo scopo del tool realizzato (vedi figura 4). Figura 4 - Rappresentazione del Workflow di PASSI. Vista la natura dei diagram editors, realizzati come plug-in di Eclipse, con cui il software va ad interfacciarsi, si è deciso di sviluppare anche questo come plug-in Eclipse utilizzando SWT come package di librerie grafiche. 18

19 4.1 Overview del software Il tool sviluppato, essendo come detto in precedenza un plug-in Eclipse, si integra completamente con la piattaforma Eclipse disponendo di un suo menù tra quelli presenti nella barra principale del workbench (vedi figura 5). Figura 5 - Il menù ptk. Questa scelta è stata fatta prendendo in considerazione la possibilità di scalare il software in termini di funzionalità, senza quindi avere la necessità a posteriori di modificare la struttura principale. Basterà infatti agganciare i nuovi action handlers agli extension point del menù. Per creare o aprire un progetto Passi occorre dunque selezionare la voce PTK GUI e inserire il nome del progetto (vedi figura 6). Figura 6 - La finestra di inserimento del nome del progetto. Il bottone Ok rimane disabilitato fintanto che il campo testuale è vuoto. Una volta acquisito il nome del progetto viene lanciata l'interfaccia principale 19

20 del tool realizzato (vedi figura 7). Il nome del progetto viene ricordato nel titolo della finestra. Figura 7 - PTK GUI La figura 4 rappresenta l'interfaccia relativa ad un nuovo progetto (o comunque un progetto in cui non sono ancora stati creati diagrammi PASSI). Nel caso venga aperto un progetto già esistente, l'interfaccia risulterà aggiornata rispetto ai diagrammi che esistono già (colorando di verde i relativi riquadri, vedi figura 6) e che seguono le convenzioni che verranno illustrate più avanti. Al momento alcuni frammenti di PASSI sono sotto sviluppo e pertanto non disponibili; per segnalare ciò si è scelto di disabilitare momentaneamente le voci corrispondenti ai frammenti in corso di sviluppo. La selezione da parte di un utente di uno dei frammenti provoca inizialmente un controllo sui work product propedeutici all esecuzione del frammento e la 20

21 creazione dello specifico diagramma. Nel caso in cui uno o più work product propedeutici risultassero mancanti, l'utente verrà avvisato tramite una finestra di warning che elencherà quali diagrammi considerati requisiti sono assenti, e chiederà se si ha intenzione di continuare ugualmente (vedi figura 8). Figura 8 - Finestra di warning. Nel caso l'utente voglia continuare, o nel caso siano presenti tutti i work products considerati requisiti, viene aperto all'interno di Eclipse l editor del diagramma di riferimento del frammento selezionato con un nuovo diagramma convenzionalmente identificato dal nome <project_name><diagram_type>.diagram (ad es. PTKDemoRDDiagram.diagram per il diagramma del Roles Description del progetto PTKDemo).Una volta aperto (o appena viene trovato all'interno del progetto) il diagramma, il riquadro corrispondente viene colorato di verde (vedi figura 9 ). 21

22 Figura 9 - Diagramma trovato. Se in seguito non è più possibile trovare il diagramma, il riquadro verrà colorato di rosso (vedi figura 10). L'update sullo stato dei diagrammi viene effettuato ogni volta che la finestra della GUI passa in primo piano e ogni volta che viene aperto un nuovo diagramma. Figura 10 - Diagramma non più reperibile. Infine, qualora non venga seguito il workflow come da specifiche PASSI, un warning viene mostrato nella parte inferiore della finestra (vedi figura 11). 22

23 Figura 11 - Warning sul flusso del workflow. 4.2 Dettagli implementativi Il plugin si aggancia agli extension points di Eclipse relativi ai comandi (per quanto riguarda il comando Ptk2.commands.opengui), agli handlers (per quanto riguarda l'handler ptk2.handlers.openptkgui), ai bindings (per definire le shortcut da tastiera) e ai menus (per quanto riguarda l'aggiunta del menù PTK, effettuato dopo il campo additions, e della voce all'interno del menù relativa all'handler ptk2.handlers.openptkgui). L'handler si occupa quindi di lanciare l'applicazione definita dalla classe PTKGUI. La GUI è stata sviluppata utilizzando le librerie SWT, dal momento che sono quelle su cui si basa Eclipse e che quindi vengono già caricate all'avvio di Eclipse stesso. Ciò comporta un ovvio vantaggio rispetto all'utilizzo di librerie alternative (ad es. SWING). Lo scheletro del workflow (figura 12) viene disegnato all'interno di un canvas. 23

24 L'immagine viene reperita tramite una funzione definita nella libreria PTKUtil, la getimagefromrelativepath(string path, Class cla) che consente di acquisire l'immagine da un path relativo senza perdere in portabilità (sfruttando il classpath tramite una richiesta al ClassLoader). Figura 12 - Lo scheletro del workflow così come viene disegnato sul canvas, prima dell applicazione delle labels. Sul canvas vengono poi posizionate, utilizzando il null Layout (posizione assoluta), una Clabel (una custom Label che permette l'utilizzo contemporaneo di un immagine e di un campo testuale, utilizzata in questo contesto per il warning sul workflow) e varie Labels. Tra queste ci sono quelle puramente informative, come ad esempio le labels che identificano il nome dei blocchi dei vari modelli (es. Agent Implementation Model), quelle che rappresentano gli effettivi tasti. Queste ultime sono della dimensione esatta dei rettangoli, e ognuna di esse registra un mouse listener creato ad hoc che si occupa sia di controllare l'eventuale assenza di work product ritenuti necessari (tramite la funzione checkrequirements(boolean[] diagrams, int[] fragments) della classe PTKUtil) ed eventualmente di lanciare la finestra di warning controllando la 24

25 scelta effettuata, sia delle operazioni legate all'apertura del diagramma: si apre/crea il diagramma di riferimento richiamando la funzione opendiagram(string projectname, String diagramtype) della classe PTKUtil si cambia il colore al riquadro, settandolo verde. si aggiorna la struttura dati di riferimento per lo status dei diagrammi creati/esistenti, l'array di booleans diagrams. viene forzato un refresh delle button-labels attraverso la funzione redrawalllabels( boolean[] diagrams, boolean[] labelarray, CLabel Warning). Come strutture dati vengono utilizzati tre array l'array di boolean diagrams, usato per mantenere le informazioni relative allo stato d'esistenza dei diagrammi (per ogni indice di riferimento true se il corrispondente diagramma esiste, false altrimenti) e alla corretta esecuzione del flusso del workflow. l'array di boolean lcdiagrams, identico in struttura a diagrams, utilizzato per vedere se nel momento in cui la GUI acquista focus, ci sono stati cambiamenti in relazione all'esistenza dei diagrammi che richiedono un redraw delle labels (attraverso un confronto con diagrams, che invece viene aggiornato ad ogni focus gain e ad ogni click sulle button-labels). Viene aggiornato quando vengono verificati questi cambiamenti. l'array di Label labelarray, contenente le button-labels ordinate per indice d'apparizione. E una lista di String, missingparts che viene usata per contenere di volta in volta le stringhe che rappresentano i missing work products identificati dalla funzione checkrequirements. Altre funzioni utilizzate e presenti nella classe PTKUtil sono: getuptodate(string projectname), che cerca l'esistenza di un progetto con nome projectname all'interno del workspace, aprendolo in caso di 25