Valutazione di strumenti per la modellazione UML

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Ingegneria del Software Valutazione di strumenti per la modellazione UML Anno Accademico 2013/2014 Candidato: Giuseppina De Stefano matr.n

2 Indice Introduzione 3 Da model-based a model-driven 4 Struttura dell'elaborato 4 Capitolo 1. Model Driven Development Unied Modeling Language Model Driven Architecture (MDA) Vantaggi dello sviluppo Model Driven 12 Capitolo 2. Sparx Enterprise Architect Interfaccia graca MDA in Enterprise Architect Generazione automatica del codice in EA 17 Capitolo 3. Un caso di studio reale: sistema di gestione degli spettacoli di un teatro Da PIM a ISM 20 PSM: Java Model 21 PSM: C# Model 21 Generazione del codice di implementazione Diagrammi comportamentali 26 Use case diagram 26 Sequence diagram: prenotazione posto 26 Conclusioni 29 Bibliograa 30 2

3 Introduzione I sistemi basati su elaboratori sono ormai entrati a far parte di molti aspetti della nostra vita quotidiana, a partire dal supporto alle attività commerciali, ai trasporti, alle comunicazioni, alla biomedica, per non parlare dell'automazione industriale e della sicurezza della persona e dei beni. Man mano, nel corso degli anni, questi sistemi diventano sempre più complessi, tali da rendere dicili la progettazione, lo sviluppo e la manutenzione necessaria anché si garantisca che i requisiti di sicurezza ed adabilità siano ancora soddisfatti. In genere, questi sistemi posseggono un'architettura distribuita di grandi dimensioni, in cui la complessità è dovuta anche all'eterogeneità dei componenti, sia per quanto riguarda la parte software che per quella hardware. Quindi, è necessario che il processo di sviluppo renda possibile l'evidenza formale del rispetto dei requisiti. A tale scopo sono stati introdotti alcuni approcci di modellazione formale che consentono l'analisi e la verica e validazione di un modello del sistema. Però, l'applicazione di metodi formali nell'ambito industriale è rallentato dalle dicoltà dovute sia alla complessità dei modelli sia alla necessità di avere personale specializzato nell'uso di linguaggi formali e nello sviluppo di modelli. Così, oltre all'ingegneria del software, si è aermata anche l'ingegneria dei modelli, che denisce le metodologie e i processi necessari a creare le attività di sviluppo di modelli complessi e a migliorare il rapporto qualità/prezzo. Concetti importanti di questo elaborato sono i modelli e lo sviluppo modeldriven con UML. I modelli sono lo strumento chiave per lo sviluppo di software. Rappresentano un'astrazione del sistema e permettono agli sviluppatori di prendere decisioni architetturali importanti prima che l'applicazione sia sviluppata. Però, non è suciente che il modello sia ben progettato. Infatti, può accadere che errori in fase di progettazione vengano rilevati solo nella fasi di implementazione o testing e ciò potrebbe avere un impatto fatale sui costi e sui tempi del progetto. 3

4 Figura MDD Da model-based a model-driven. Nello sviluppo model-based i modelli sono utilizzati nelle fasi di progettazione ed implementazione. Le modiche dei requisiti e del progetto vengono eettuate direttamente sul codice, il che porta ad una situazione in cui i modelli originali non sono più aggiornati e quindi inutili: gli aggiornamenti manuali dei modelli possono richiedere molto tempo e c'è il rischio che i modelli diventino inconsistenti. A questo proposito l'approccio model-driven ha vantaggi signicativi rispetto a quello model-based. I modelli non sono documenti del progetto, ma sono parte di esso e il codice può essere generato automaticamente a partire dai modelli. Le modiche sono eettuate direttamente sui modelli e non più sul codice. Ciò aumenta l'ecienza del sistema e diminuisce i costi e i tempi di sviluppo. Struttura dell'elaborato. Lo scopo di questo elaborato è quello di trovare metodi e strumenti in grado di risolvere il problema di coerenza tra un codice sorgente e un modello, rappresentato come diagramma UML. Esistono molti strumenti creati a tale proposito, quali Visual Paradigm, IBM Rational Software Architect, StarUML, Microsoft Visual Studio, Sparx Enterprise Architect e molti altri. questo elaborato verrà trattato Sparx Enterprise Architect. L'elaborato è strutturato come segue: nel primo capitolo viene introdotta la metodologia di sviluppo Model Driven con UML. nel secondo capitolo viene presentato il CASE tool Enterprise Architect. De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML In

5 nel terzo ed ultimo capitolo viene mostrato un esempio utilizzando il tool descritto nel capitolo precedente. De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

6 CAPITOLO 1 Model Driven Development I modelli si utilizzano per ragionare sul problema e per trovare una soluzione ad esso. Le relazioni tra i modelli forniscono una rete di dipendenze. Ciò ci permette di denire il tipo di modelli che bisogna costruire e la semantica degli stessi. Inoltre, possiamo denire regole per l'automatizzazione delle operazioni per la conversione di un modello in un altro. Questa metodologia è chiamata Model Driven Development, MDD, che è un paradigma per la scrittura e l'implementazione rapida di applicazioni, ecace e al minimo costo. Lo sviluppo Model-Driven (MDD) mira ad aumentare il livello di astrazione per lo sviluppo software mediante l'uso di modelli come strumenti chiave. MDD sta guadagnando sempre di più l'attenzione di industrie e comunità di ricerca. Quindi, il Model Driven Development rappresenta un'alternativa alla programmazione tradizionale. Infatti, non vi è un codice sorgente da compilare o eseguire, ma viene modellato il sistema che si vuole implementare. La modellazione viene eettuata attraverso strumenti appositi. I modelli vengono poi convertiti in codice eseguibile attraverso una serie di trasformazioni. Le seguenti sezioni presentano un' introduzione allo Unied Modeling Language (UML) e al Model Driven Architecture (MDA) Unied Modeling Language Lo Unied Modeling Language (UML), che potremmo tradurre linguaggio di modellazione unicato, è una famiglia di notazioni grache che si basano su un singolo meta-modello e servono a supportare la descrizione ed il progetto dei sistemi software, in particolare quelli costruiti seguendo il paradigma orientato agli oggetti (OO) [1]. I linguaggi di modellazione hanno fatto parte dell'industria del software per molto tempo. La ragione principale della loro introduzione è il livello di astrazione dei 6

7 1.1. UNIFIED MODELING LANGUAGE linguaggi di programmazione, che non è abbastanza alto da permettere la discussione diretta delle scelte di progetto[1]. Grazie a UML la progettazione può essere eettuata in modo tale che, tutte le persone coinvolte nello sviluppo del sistema, possano comprendere ed esaminare il sistema in maniera eciente ed essere parte attiva della costruzione. La prima versione uciale fu prodotta nel 1997 da OMG (Object Management Group) e da allora divenne uno standard de-facto per la costruzione di software object-oriented. UML: Nello sviluppo del software ci sono molti modi con cui gli sviluppatori utilizzano UML come abbozzo (sketch): UML viene utilizzato per documentare alcuni aspetti del sistema. Gli abbozzi si possono usare sia per il forward engineering che per il reverse engineering. Nel primo caso, si tratta di scrivere il diagramma UML prima del codice; nel secondo caso, si ricostruisce il diagramma partendo dal codice. UML come progetto (blueprint): UML viene utilizzato per guidare la realizzazione o la manutenzione del software. Lo scopo è quello di fornire agli sviluppatori un modello dettagliato su cui basarsi. É rivolto in primis alla completezza del sistema. UML come linguaggio di programmazione : ci sono alcuni tool che generano il codice direttamente dai diagrammi. In questo caso, non è più corretto parlare di reversee forward engingeering, poiché codice sorgente e rappresentazione coincidono. UML denisce 13 diagrammi divisi in due categorie Figura1.1.1: (1) diagrammi strutturali, che deniscono l'architettura statica del sistema. Sono utilizzati per modellare le relazioni e le dipendenze tra gli elementi. Esempi di diagrammi strutturali sono: Class diagrams: descrivono il tipo degli oggetti che compongono il sistema e le relazioni statiche esistenti tra loro. Package diagrams: sono utilizzati per dividere il modello in contenitori logici, o package, per descrivere le interazioni tra essi ad alto livello. De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

8 1.1. UNIFIED MODELING LANGUAGE Figura diagrammi UML Object diagrams: mostrano come le istanze degli elementi sono collegati tra loro a tempo di esecuzione. Component diagrams: evidenziano l'organizzazione e le dipendenze tra i componenti software. Deployment diagrams: modellano l'architettura del sistema a run-time. Mostrano la congurazione degli elementi hardware, nodi, e come gli elementi software sono mappati su questi nodi. Composite structure: mostra la struttura interna, includendo le interazioni tra le parti del sistema. (2) diagrammi comportamentali, che descrivono il comportamento dinamico di un sistema: Use case diagrams: sono utilizzati per descrivere le interazioni tra gli attori e il sistema. Interaction diagrams: fondono i sequence diagram e gli activity diagram. De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

9 1.2. MODEL DRIVEN ARCHITECTURE (MDA) Statecharts diagram: modellano il comportamento di un singolo oggetto, specicando come esso reagisce quando riceve un segnale oppure in seguito ad un evento mediante azioni e transizioni. Activity diagrams: sono utilizzati per mostrare la sequenza di attività; mostrano il usso dall'inizio alla ne; permettono di modellare processi paralleli e la loro sincronizzazione. Communication diagrams: rappresentano un insieme di oggetti che collaborano per realizzare il comportamento di uno scenario di un caso d'uso. Timing diagrams: fondono i sequence diagram e gli statechart. Sequence diagrams: deniscono la logica di uno scenario di un caso d'uso, specicando la sequenza temporale dei messaggi che gli oggetti si scambiano. Il vantaggio dell'utilizzo di UML sta nel fatto che, è molto più semplice apportare modiche ad un modello piuttosto che al codice sorgente. Infatti, molti dei bug presenti nei software sono dovuti ad errori in fase di progettazione. Se si crea un modello robusto e ben strutturato, secondo i requisiti richiesti, non si avrebbero problemi nel convertirlo in codice e a renderlo funzionante. Quindi, è necessario concentrarsi maggiormente sulla revisione e il miglioramento del modello UML, piuttosto che sul codice sorgente Model Driven Architecture (MDA) Il Model Driven Architecture è stato introdotto dall'organizzazione OMG nel MDA è un approccio di progettazione per lo sviluppo di sistemi software. Fornisce una serie di linee guida per strutturare le speciche, che sono espresse come modelli. Sono stati scelti i modelli come oggetto centrale perché aiutano i progettisti a ragionare sulla progettazione del sistema, ignorando i dettagli extra e dando maggiore attenzione ai problemi rilevanti. Inoltre, l'approccio Model Driven allo sviluppo del software permette alle persone di lavorare insieme su un progetto, anche se i loro livelli di esperienza individuali variano notevolmente. MDA supporta il model driven engineering di sistemi software. Bisogna sottolineare che, anche se De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

10 1.2. MODEL DRIVEN ARCHITECTURE (MDA) MDD e MDA si riferiscono alla stessa metodologia, MDA è solo uno stile di MDD, che ore la possibilità di denire regole per automatizzare le operazioni necessarie per convertire un modello in un altro. Poiché queste operazioni automatiche di conversione dei modelli sono l'oggetto principale di questo elaborato, da ora in poi utilizzeremo il termine MDA. Essenzialmente, MDA è una tecnica standard per utilizzare UML come linguaggio di programmazione [1]. MDA viene spesso associato a UML, poiché lo utilizza come linguaggio di modellazione base, anche se naturalmente si può usare UML senza farvi riferimento [1]. MDA suddivide lo sviluppo software in quattro aree principali: (1) CIM (Computation Indipendent Model): riette le attività e i loro modelli, denito a livello di dominio del problema (2) PIM (Platform Indipendent Model): è un modello che riette l'analisi e i modelli di progettazione del sistema software da sviluppare, denito nel dominio della soluzione. (3) PSM (Platform Specic Model): riette i modelli di progettazione dettagliati del sistema software in costruzione, denito a livello di dominio software (4) ISM (Implementation Specic Model): riette l'implementazione e l'esecuzione dei modelli, denito a livello di dominio dell'implementazione Figura MDA I componenti di MDA, illustrati nella Figura1.2.1, rappresentano tutte le attività incluse nel processo di sviluppo software Model Driven. Un Computation Indipendent Model descrive come un sistema dovrebbe comportarsi in termini di un linguaggio adatto ad un utente (ad esempio un progettista De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

11 1.2. MODEL DRIVEN ARCHITECTURE (MDA) didattico). Si focalizza sull'ambiente e sulle speciche del sistema, nascondendo i dettagli strutturali. Un Platform Indipendent Model raccoglie tutte le informazioni necessarie dal CIM per descrivere il comportamento del sistema in modo indipendente dalla piattaforma su cui sarà implementato. Si focalizza sul funzionamento del sistema, nascondendo i dettagli specici della piattaforma. Quindi, può essere utilizzato su diverse piattaforme. Un Platform Specic Model descrive il sistema dal punto di vista di una specica piattaforma e comprende anche le speciche del PIM con i dettagli che specicano come il sistema utilizza un particolare tipo di piattaforma. Un Implementation Specic Model è una descrizione del codice del sistema. La trasformazione da CIM a PIM viene eettuata manualmente, mentre quelle da PIM a PSM e da PSM a ISM vengono eettuate automaticamente con appositi strumenti. In MDA, i modelli indipendenti dalla piattaforma (PIM) sono inizialmente espressi in un linguaggio di modellazione indipendente dalla piattaforma, come ad esempio UML [2]. Il modello indipendente dalla piattaforma viene successivamente tradotto in un modello specico (PSM), mappando il PIM in uno specico linguaggio di implementazione o piattaforma (ad esempio, Java, C++) utilizzando le regole formali [2]. La trasformazione da PIM a PSM permette di ottenere un'applicazione sviluppata in uno specico linguaggio. Inne, dal PSM viene generato il codice (ISM). Se il processo che converte un modello in un altro è automatico, allora si può utilizzare UML come linguaggio di programmazione, altrimenti, come nel caso della trasformazione da CIM a PIM, che avviene manualmente, si parla di blueprint(vedi 1.1). Grazie a MDA è possibile diminuire lo sforzo implementativo e ciò permette di diminuire anche i tempi ed i costi di produzione del software. Il suo successo è dovuto al fatto che la generazione automatica del codice partendo da un modello è meno problematica dell'implementazione manuale del codice. L'automazione è il mezzo tecnologico più ecace per incrementare la produttività e l'adabilità di un sistema software. De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

12 1.2. MODEL DRIVEN ARCHITECTURE (MDA) Figura MDA bridge Vantaggi dello sviluppo Model Driven. L'adozione di MDA comporta una serie di vantaggi. Il primo fra tutti riguarda l'aumento della produttività. Lavorare a livello PIM vuol dire non doversi preoccupare dei dettagli tecnici e tecnologici che si troveranno a livello PSM. Il PIM è un modello di business e quindi si tratta di qualcosa più vicino alla realtà così come richiesta dall'utente nale, che porta, quindi, a sviluppare meglio e in meno tempo il sistema desiderato. Un altro vantaggio risiede nella portabilità. Un PIM è, per denizione, un modello indipendente dalla piattaforma e quindi sempre valido, a prescindere dalla tecnologia che verrà poi utilizzata per costruire i PSM. Quindi, tutto ciò che è contenuto nei PIM è portabile. L'unico problema potrebbe essere quello di trovare appositi tool che permettano di trasformare un PIM in diversi PSM. Un ulteriore vantaggio è dato dall'interoperabilità: da uno stesso PIM si possono derivare tanti PSM, specici per una piattaforma. L'insieme dei diversi PSM può avere interrelazioni, chiamate bridge Figura Per costruire un bridge, bisogna trovare una corrispondenza tra gli elementi caratteristici di un dato PSM e quelli caratteristici di un altro PSM. De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

13 CAPITOLO 2 Sparx Enterprise Architect 9.0 Esistono diversi CASE (Computer- Aided Software Engineering) tool [7] di modellazione, gratuiti e non. La scelta dello strumento per la modellazone di un sistema con UML dipende dalle proprie esigenze, nonché dal budget che si ha a disposizione. Per questo lavoro si è scelto di utilizzare Enterprise Architect 9.0. Enterprise architect è un CASE tool sviluppato dalla compagnia australiana Sparx Systems [3]. È possibile scaricare gratuitamente una versione di prova di 30 giorni dal sito uciale [3]. Le piattaforme supportate sono Windows e Linux. Il tool di Sparx è utilizzato per lo sviluppo di vari tipi di sistemi software per una vasta gamma di settori, tra cui: aerospaziale, bancario, sviluppo web, ingegneria, nanza, medicina, militare, della ricerca, del mondo accademico, dei trasporti, ingegneria elettrica e molti altri. È anche utilizzato ecacemente per UML e architettura di business ai ni della formazione in molte scuole importanti, strutture educative e università di tutto il mondo. EA è un tool per la gestione dei requisiti, l'analisi e lo sviluppo di sistemi software e per la modellazione del processo di business. Permette una rappresentazione completa ed intuitiva delle caratteristiche e dei requisiti di un sistema software. Dispone di una modellazione graca basata sui 13 formalismi deniti nelle speciche UML 1.1. Inoltre, consente di denire relazioni sia tra i requisiti che tra gli elementi di modelli diversi. Il tool supporta l'intero processo di sviluppo software no ad arrivare alla generazione automatica del codice in accordo con gli standard deniti dal MDA 1.2. Vi è anche la possibilità di trasformare i diagrammi UML in altri formati, quali XSD deniti da XMI [4]. Oltre al forward e reverse engineering, EA supporta anche la tracciabilità della documentazione di progetto, nonché una serie di funzionalità di groupware, per consentire la comunicazione e il lavoro in parallelo di diversi teamm impegnati nello stesso progetto. Quindi, EA è un CASE tool che copre l'intero ciclo di vita del software, dalla fase di analisi e progettazione, no 13

14 al testing e la manutenzione del sistema. È possibile, inoltre, l'integrazione con altri IDE commerciali, come ad esempio Visual Studio [6] ed Eclipse [5]. Presenta un framework di supporto per le tecnologie MDG (Model Driven Generation): l'utente può importare risorse di una specica tecnologia per estendere le capacità di modellazione del tool. Figura Sparx EA La generazione del codice e il reverse engineering sono una parte importante di Enterprise Architect, con il supporto di oltre 10 linguaggi. L'integrazione con Eclipse e Visual Studio ore un accesso diretto ai modelli, alla loro modica, il tutto all'interno di IDE scelto dall'utente. Il tool sostiene le trasformazioni avanzate MDA utilizzando semplici modelli. Ci sono diversi linguaggi inclusi in Enterprise Architect come ad esempio: C#, DDL, EJB, Java, JUnit, NUnit, WSDL, XSD. Enterprise Architect supporta un'ampia gamma di standard aperti per la progettazione e la modellazione di sistemi software: UML SysML BPMN BPEL SoaML SPEM WSDL De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

15 XSD DDS ArchiMate Geography Markup Language (GML) ODM, OWL e RDF Purtroppo la maggior parte di queste funzionalità sono incluse nella versione aziendale, che è più sosticata e più costosa e non fa parte della versione di valutazione gratuita. Interfaccia graca. Il tool di Sparx si presenta molto intuitivo. L'utente può personalizzare il tavolo di lavoro come meglio desidera, semplicemente aggiungendo o eliminando le viste (View) o spostando i vari pannelli. Nella toolbox appaiono tutti gli strumenti relativi al modello che si sta costruendo. Ad esempio, verranno mostrati gli elementi utili per costruire un class diagram Figura2.0.2: Figura Toolbox/Project Browser De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

16 2.1. MDA IN ENTERPRISE ARCHITECT Sulla sinistra, invece, vi è il Project Browser, in cui vengono mostrati i vari modelli del progetto Figura MDA in Enterprise Architect La trasformazione MDA fornisce un modo per convertire un modello o parti di esso in altri modelli. Ciò comporta la conversione da PIM a PSM 1.2: un elemento singolo del PIM può essere responsabile della creazione di più elementi PSM. Le trasformazioni comportano un aumento della produttività e riducono la necessità di implementare manualmente il codice. Il tool Enterprise Architect include alcune trasformazioni di base integrate, come da PIM a Data Model, da PIM a C #, da PIM a Java e da PIM a XSD. EA legge il le di origine e lo associa al nuovo PSM. Crea anche le associazioni interne tra ogni PSM creato e il PIM originale. Questo è fondamentale, in quanto consente di sincronizzare il PIM con il PSM spesso, aggiungendo o eliminando funzionalità.. Così, per esempio, l'aggiunta di un nuovo attributo ad una classe PIM può essere sincronizzato con una nuova colonna del modello di dati. Cosa molto importante è che non vengono cancellate o sovrascritte eventuali caratteristiche di elementi che non erano originariamente generati dalla trasformazione. Così è possibile aggiungere nuovi metodi agli elementi. Le trasformazioni attualmente possibili sono: DDL - trasforma elementi di una classe indipendente dalla piattaforma in elementi delle tabelle di una specica piattaforma. EJB Entity - trasforma elementi di una classe indipendente dalla piattaforma in package contenenti gli elementi della classe e dell' interfaccia che compongono un EJB Entity Bean. EJB Session - trasforma elementi di una classe indipendente dalla piattaforma in package contenenti gli elementi della classe e dell' interfaccia che compongono un EJB Session Bean. Java - trasforma gli elementi di un PIM in elementi in linguaggio Java. C# - converte un PIM in un set di impementazione standard C#. XSD - trasforma elementi indipendenti dalla piattaforma in elementi XSD. De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

17 2.2. GENERAZIONE AUTOMATICA DEL CODICE IN EA Figura MDA in EA Il principio generale è abbastanza semplice: EA fornisce l'accesso ai diversi elementi (classi, attributi, operazioni, ecc) del modello UML originario. Il linguaggio di scripting denisce le regole con cui le proprietà di ogni elemento possono essere copiate e / o trasformate in un corrispondente elemento del modello di destinazione. EA costruisce anche le associazioni interne tra ogni PSM e il PIM di origine. EA fornisce una piattaforma MDA solida ed estensibile, grazie a template di generazione del codice, proli UML, patterns UML, frameworks, capacità di reverse engineering e uan completa automazione dell'api per lo scripting e l'estensione Generazione automatica del codice in EA Il tool fornisce un ambiente di progettazione e strumenti per la generazione automatica del codice, per il reverse engineering e per la sincronizzazione tra codice sorgente De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

18 2.2. GENERAZIONE AUTOMATICA DEL CODICE IN EA e modello. La generazione del codice sorgente (forward engineering) prende gli elementi di un diagramma UML e crea un codice sorgente equivalente che verrà poi elaborato e compilato. Con il forward engineering, si evita di dover implementare manualmente classi e metodi. Avviene tutto automaticamente e la simmetria tra il modello ed il codice è assicurata. Enterprise Architect supporta la generazione del codice nei seguenti linguaggi: Action Script C C# C++ Delphi Java PHP Python Visual Basic Visual Basic.NET Il codice viene generato dagli elementi delle classi. Gli attributi diventano variabili e le operazioni diventano metodi. Prima di generare il codice, bisogna assicurarsi che le impostazioni di default per la generazione del codice siano compatibili con le proprie esigenze. Le impostazioni di default si possono trovare nella pagina Source Code Engineering nella nestra Options: selezionare Tools Options Source Code Engineering menu option Figura De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

19 2.2. GENERAZIONE AUTOMATICA DEL CODICE IN EA Figura Source Code Engineering De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

20 CAPITOLO 3 Un caso di studio reale: sistema di gestione degli spettacoli di un teatro In questo capitolo si applicherà la metodologia di modellazione 1, proposta nei capitoli precedenti al caso di studio del sistema di gestione degli spettacoli di un teatro, utilizzando il tool di Sparx 2. Il sistema è costituito dai seguenti elementi: I posti di un teatro: ogni teatro è suddiviso in aree (ad esempio, platea e galleria). Il prezzo di un posto dipende dal teatro, dallo spettacolo e dall'area. Le aree sono divise in settori, ciascuno dei quali contiene dei posti. In un teatro i posti sono identicati da un numero di la e colonna, ma nel biglietto va indicato anche il settore. Le prenotazioni dei posti: un cliente può prenotare uno o più posti per un certo evento. In una prenotazione, tutti i posti devono riguardare un singolo settore. Le prenotazioni hanno associato un codice, oltre a nome e cognome del cliente. Le prenotazioni decadono dopo una settimana dal momento in cui vengono eettuate. La vendita dei posti: un cliente può acquistare dei posti prenotati (indicando il codice della prenotazione), oppure acquistare direttamente dei posti. Procediamo ora con la modellazione del sistema e mostriamo un pratico esempio su come attuare lo sviluppo model driven Da PIM a ISM Al ne di fornire una descrizione statica del sistema si è utilizzato il diagramma delle classi Figura

21 3.1. DA PIM A ISM Figura Class Diagram Sono state aggiunte, oltre agli attributi, anche le operazioni eseguite da ciascuna classe, per una descrizione più dettagliata. Facendo click destro su ciascun elemento, comprese le associazioni e le generalizzazioni, è possibile modicare le impostazioni. Vediamo ora com'è possibile generare un modello dipendente dalla paittaforma a partire dal PIM appena descritto. PSM: Java Model. Considerando il class diagram Figura3.1.1, si è attuata la trasformazione nel modello Java (Tools Model Transformation(MDA) Transform Current Package) Figura3.1.2: Il risultato della trasformazione è un PSM. Si può notare Figura3.1.3 che il modello ottenuto è costituito dalle stesse classi dell'originale, ma con l'aggiunta di nuove funzioni necessarie per implementare il sistema nel linguaggio specicato, in questo caso Java. PSM: C# Model. L'innovazione dell'utilizzo del model driven permette di generare diversi PSM a partire dallo stesso PIM. Per esempio, considerando ancora una volta il diagramma delle classi Figura3.1.1, possiamo generare un modello De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

22 3.1. DA PIM A ISM Figura Model Transformation Figura Java model De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

23 3.1. DA PIM A ISM Figura C# model C# Figura3.1.4, che risulterà completamente diverso dal Java Model Figura Seguiamo lo stesso procedimento utilizzato per la trasformazione nel modello Java. Notiamo, inoltre, che i tipi di dati generici sono stati convertiti in tipi Java e che sono state create funzioni di accesso. Generazione del codice di implementazione. Il PSM generato può ora essere utilizzato come modello di origine per generare il codice, tramite il modello di generazione di codice predenito di EA. Il tool ore un editor integrato da cui è possibile visualizzare il codice sorgente: facendo click destro su ciascuna classe, l'opzione View source code mostrerà il codice relativo a tale classe Figura3.1.5 Figura Questo codice può essere ulteriormente modicato, compilato e costruito utilizzando un apposito IDE, come ad esempio Eclipse. Quando si genera il codice per una determinata lingua, è possibile impostare alcune opzioni, tra cui creare un costruttore di default, creare una distruttore, generare un costruttore di copia, selezionare la lingua predenita, generare metodi per interfacce implementate e impostare le opzioni Unicode per la generazione del codice. Tutto ciò è possibile accedendo Tools De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

24 3.1. DA PIM A ISM Figura Source code java Figura Source code C# De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

25 3.1. DA PIM A ISM Options Source Code Engineering.Figura3.1.7Figura3.1.8 Figura Java options Figura C# options De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

26 3.2. DIAGRAMMI COMPORTAMENTALI 3.2. Diagrammi comportamentali Passiamo ora ad analizzare il comportamento del sistema. Per fare ciò, si è ricorso all'utilizzo di un case use diagram e di un sequence diagram. Use case diagram. Il diagramma dei casi d'uso è stato costruito applicando le regole fornite dalla teoria dell'ingegneria del software.figura3.2.1: Figura Use case Diagram Sequence diagram: prenotazione posto. Mostriamo il sequence diagram riguardante la funzionalità di prenotazione di un posto da parte di un cliente Figura Il diagramma è stato costruito eseguendo un drag & drop delle classi dal Java Model. In questo modo, ogni classe conterrà i vari metodi e sarà possibile inserire le funzioni relative al caso d'uso automaticamente Figura Anche in questo caso è possibile visualizzare il codice sorgente delle classi tramite l'editor integratofigura De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

27 3.2. DIAGRAMMI COMPORTAMENTALI Figura Sequence diagram Figura Message properties De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

28 3.2. DIAGRAMMI COMPORTAMENTALI Figura code from sequence diagram De Stefano Giuseppina N Valutazione di strumenti per la modellazione UML

29 Conclusioni In questo elaborato si è denito un nuovo approccio per la modellazione e l'analisi di sistemi complessi, basato su tecniche e strumenti Model Driven, con l'obiettivo di generare il codice automaticamente a partire dai modelli. Si è voluto dimostrare come è più semplice lavorare sui modelli anziché direttamente sul codice, evitando così la comparsa di errori nelle fasi successive. Quindi, è necessario dedicare più tempo alla fase di modellazione, apportando le eventuali modiche ai modelli, per prevenire che errori vengano rilevati successivamente, quando sarà più complicato risolverli. L'obiettivo principale dello sviluppo Model Driven è quello di migliorare la produttività, diminuendo i tempi e i costi di produzione. Il suo successo è dovuto al fatto che la generazione automatica del codice partendo da un modello è meno problematica dell'implementazione manuale del codice. L'automazione è il mezzo tecnologico più ecace per incrementare la produttività e l'adabilità di un sistema software. Esistono molti strumenti che permettono di utilizzare tale approccio. Per questo elaborato si è scelto Sparx Enterprise Architect: lo strumento è risultato intuitivo e facile da utilizzare. Si è visto come è possibile generare il codice automaticamente con poche operazioni, mentre altri tool necessitano di maggiori impostazioni. Per questa sua capacità, il tool è molto utilizzato nelle aziende per creare applicazioni ecienti in tempi ridotti. 29

30 Bibliograa [1] UML distilled: guida rapida al linguaggio di modellazione standard- Martin Flower, Terza Edizione, Addison-Wesley [2] Model-Driven Architecture: Vision, Standards And Emerging Technologies, [3] Sparx Enterprise Architect, [4] XMI, [5] MDG integration for Eclipse, [6] MDG integration for Visual Studio, [7] CASE tools, [8] Eclipse, 30