Il linguaggio di modellazione UML. Rational Unified Process. Model Driven Architecture. Sistemi Informativi Aziendali

Transcript

1 Contenuti Il linguaggio di modellazione UML Rational Unified Process. Model Driven Architecture. Sistemi Informativi Aziendali Con le slides che seguono l intento è quello di introdurre gli strumenti e i metodi per la modellazione a partire dal linguaggio di modellazione Unified Modeling Language, con i suoi costrutti fondamentali, passando attraverso il Rational Unified Process, inteso come metodologia di riferimento per lo sviluppo di un progetto software e, per finire, la Model Driven Architecture, standard OMG che ha come scopo la definizione delle soluzioni in modo indipendente dalla piattaforma tecnologica su cui verranno poi realizzate.

2 Linguaggio di modellazione : UML Uno standard de facto che ormai si è affermato è il linguaggio di modellazione UML (Unified Modeling Language). Le specifiche di UML sono di proprietà del consorzio noprofit OMG (Object Management Group). UML non è un metodo, ma un insieme di diagrammi e notazioni grafiche e testuali attraverso le quali è possibile documentare quasi tutti gli artefatti necessari durante l Analisi. L UML, Unified Modeling Language, è un linguaggio per descrivere, specificare e documentare i prodotti del processo di sviluppo del software. Può essere utilizzato per sistemi di tipo e grandezza differenti ed è caratterizzato da un alto potere espressivo in accordo con la prospettiva Object Oriented. UML, infatti consente di rappresentare e di mantenere diverse viste di uno stesso sistema descrivendo gli oggetti che lo compongono da diversi punti di osservazione, strutturale e comportamentale e a diversi livelli di astrazione.

3 Unified Modelling Language Ivar Jacobson Grady Booch James Rumbaugh Unified Modeling Language un linguaggio (e notazione) universale, per rappresentare un qualunque sistema uno standard OMG (Object Management Group), dal nov.1997 gli autori: Grady Booch Ivar Jacobson Jim Rumbaugh i co-proponenti: Microsoft, IBM, Oracle, HP, Platinum, Sterling, Unysis (e tanti altri) Sistemi Informativi Aziendali

4 Evoluzione dello UML Sistemi Informativi Aziendali Il progetto dello UML, originariamente, fu avviato da Grady Booch e James Rumbaugh, con l intento di produrre un nuovo metodo, detto inizialmente metodo unificato, che raccogliesse il meglio dei metodi di Booch e OMT-2, del quale Rumbaugh ne era stato uno dei principali promotori. Nel 1995 si unì a loro Ivar Jacobson, fautore del metodo denominato OOSE (Object Oriented Software Engineering): il terzetto si era così costituito. La prima versione, la famosissima 1.0, fu disponibile nel gennaio Visto l enorme successo riscosso, nell ambito del mondo reale ed in quello accademico, e considerato il relativo riconoscimento a livello di standard (UML 1.0 è stato proposto al Object Management Group nel gennaio 1997), gli stessi ideatori dichiararono ormai conclusa la loro esperienza in questo ambito tanto da dedicarsi a nuove sfide. Allo stato attuale lo sviluppo dell UML è affidato alle varie task force appartenenti all OMG, le famose Revision Task Force, dirette da Chris Kobyrn. Obiettivo di tale gruppo è accogliere ed analizzare suggerimenti provenienti dalle industrie, correggere inevitabili imperfezioni, colmare eventuali lacune e così via. L evoluzione dello UML è mostrata nella slide, attraverso il diagramma dei package, uno degli strumenti messi a disposizione dal linguaggio. Le linee tratteggiate etichettate con la parola refine rappresentano uno stereotipo della relazione di dipendenza. Molto semplicemente indicano che un aggiornamento apportato ad un oggetto indipendente (quello a cui puinta la freccia) implica una revisione e verosimilmente una modifica dell oggetto dipendente.

5 Unified Modelling Language: questioni generali Diagramma e specifica: i diagrammi sono una semplificazione della realtà, che segue una sintassi precisa; ogni diagramma può presentare una vista (parziale) del sistema. Distinzioni di livello: classe e oggetto; interfaccia. Meccanismi di estensibilità stereotipo: estensione del vocabolario, estende la semantica di un costrutto. UML: principi ispiratori Modellazione del progetto prima dello sviluppo; La modellazione è essenziale in ogni attività ingegneristica complessa, in quanto permette di astrarre e semplificare: we build models so that we can better understand the system we are developing [Booch et al: The UML User Guide]; we build models of complex systems because we cannot comprehend such a system in its entirety [Booch et al: The UML User Guide]. Il primi principio a cui si ispira UML riguarda la modellazione del progetto svolta prima di passare allo sviluppo, ovviamente in questo modo la modellazione non è finalizzata a se stessa, ma ha lo scopo di produrre un software migliore. In secondo luogo, ci si basa sul fatto che la modellazione è un attività essenziale per il corretto svolgimento di qualsiasi attività ingegneristica, in quanto permette di astrarre e di semplificare.

6 Finalità della modellazione Visualizzazione di un sistema (così com'è o come lo si vorrebbe); Specifica della struttura e/o del comportamento di un sistema; Definizione delle linee guida per la costruzione di un sistema; Documentazione delle decisioni prese;

7 Cos è UML (e cosa non è) è un linguaggio di progettazione; serve a progettare un nuovo sistema; è universale; è un linguaggio e non un metodo; definisce una notazione standard; continua Cos è UML (e cosa non è) continua non definisce un processo; è utilizzato con metodi diversi; è un linguaggio non proprietario; ha ricevuto il contributo di altri metodologi; l OMG ne cura l evoluzione; Definiamo ora cos è (e cosa non è) UML. è un linguaggio di progettazione, e non un linguaggio di programmazione come Java, VisualBasic, C++,...;

8 quindi serve a progettare un nuovo sistema, o a apportare modifiche alla progettazione di un sistema esistente, senza perdersi nei dettagli dei linguaggi di programmazione; è universale, nel senso che può rappresentare sistemi molto diversi senza differenze legate alla tecnologia: dai sistemi web a quelli più tradizionali, dalle vecchie applicazioni Cobol a quelle object oriented e a componenti; è un linguaggio, non un metodo come quelli di Yourdon e De Marco, o di Rumbaugh o Jacobson; definisce una notazione standard, basata su un metamodello integrato degli oggetti che compongono un sistema software; non prescrive una sequenza di processo, cioé non dice prima bisogna fare questa attività, poi quest altra ; quindi può essere (ed è) utilizzato da persone e gruppi che seguono metodi diversi (è indipendente dai metodi ); è un linguaggio non proprietario, standard, i suoi autori (Grady Booch, Jim Rumbaugh e Ivar Jacobson) non hanno il copyright su UML; la versione diventata standard OMG (Object Management Group) ha ricevuto i contributi di molti altri metodologi, e delle più importanti società di software mondiali; la sua evoluzione è a carico dell OMG, e soggetta a procedure ben definite per ogni cambiamento.

9 UML: meta-modello e diagrammi UML fa riferimento ad un meta-modello; permette di creare modelli rivolti ai sistemi da progettare; molti elementi sono rappresentati da un icona; gli elementi del meta-modello appartengono a diversi diagrammi; UML è basato su un meta-modello integrato, composto da numerosi elementi collegati tra loro, secondo regole precise. Grazie a queste regole, è possibile creare modelli particolari per le singole applicazioni da progettare. Molti elementi (ad esempio l elemento classe ) hanno un icona che li rappresenta graficamente e possono comparire in diagrammi di diverso tipo.

10 Diagrammi UML 1.1 Diagrammi strutturali : diagramma delle classi (class); diagramma dei componenti (component); diagramma di distribuzione dei componenti (deployment); Diagrammi comportamentali : diagramma dei casi d uso (use case); diagramma di sequenza (sequence); diagramma di collaborazione (collaboration); diagramma di transizione di stato (statechart); diagramma delle attività (activity); Diagrammi UML 2.0 Diagrammi strutturali : diagramma delle classi (class); diagramma degli oggetti (object); diagramma dei package; diagramma dei componenti (component); diagramma delle strutture composite (composite structure); diagramma di distribuzione dei componenti (deployment); Diagrammi comportamentali : diagramma dei casi d uso (use case); diagramma di stato (statechart); diagramma delle attività (activity); diagramma di sequenza (sequence); diagramma di comunicazione (communication); diagramma di temporizzazione (timing); diagramma di sintesi dell interazione(interaction overview); interaction

11 Diagrammi UML 2.0 Diagramma UML 2.0 Diagramma strutturale Diagramma comportamentale Diagramma delle classi Diagramma dei componenti Diagramma di dislocazione Diagramma use case Diagramma State machine Diagramma degli oggetti Diagramma di struttura composita Diagramma dei package Diagramma di interazione Diagramma di attività Diagramma di comunicazione Diagramma di sequenza Diagramma di temporizzazione Diagramma interaction overview UML nella sua ultima versione 2.0 comprende 13 diagrammi ufficiali che vengono classificati come mostrato nella slide in funzione dell aspetto del sistema che si propongono di descrivere: diagrammi strutturali, che consentono di modellare la struttura del sistema; diagrammi comportamentali, che descrivono il comportamento assunto dal sistema. La classificazione dei diagrammi non è rigida tant è che è possibile ritrovare la stessa tipologia di diagramma per descrivere aspetti differenti del medesimo sistema.

12 Diagrammi: viste Vista strutturale Vista dinamica diagrammi di interazione - diagramma di sequenza - diagramma di comunicazione - diagramma di interaction overview - diagramma di temporizzazione diagramma state machine diagramma protocol state machine diagramma delle classi diagrammi degli oggetti diagramma dei package diagramma di struttura composito diagramma dei componenti diagramma di deployment Vista comportamentale diagramma use case diagramma attività Oltre alla vista strutturale e comportamentale, è possibile descrivere anche come il sistema evolve nel tempo, offrendo una vista dinamica del sistema.

13 Diagramma dei casi d uso Diagramma dei casi d'uso: vendita per corrispondenza effettua ordine Venditore verifica stato avanzamento Customer attore: un utilizzatore del sistema (essere umano, altro sistema, ) caso d uso: una particolare modalità di utilizzo del sistema Nella slide è riportato un esempio elementare di diagramma dei casi d uso. E facile identificare due costrutti fondamentali in UML: il costrutto attore, che rappresenta un utilizzatore del sistema (sia esso un essere umano o un altro sistema) e il costrutto caso d uso, a descrivere una particolare modalità di utilizzo del sistema. Le linee che uniscono questi due costrutti indicano che l attore interessato interagisce col sistema attuando la modalità di utilizzo descritta dal caso d uso.

14 Casi d uso : a cosa servono rappresentano le modalità di utilizzo del sistema da parte di uno o più utilizzatori (attori); descrivono l interazione tra attori e sistema, non la logica interna della funzione; sono espressi in forma testuale, comprensibile anche per i non addetti ai lavori ; possono essere definiti a livelli diversi (sistema o parti del sistema); ragionare sui casi d uso aiuta a scoprire i requisiti; Ruolo dei casi d uso Acquirente Venditore requisiti caso d uso: effettua ordine modelli di analisi e disegno unità di rilascio Ordine DataArrivo Numero Prezzo verifica( ) evadi( ) 0..* Cliente nome indirizzo 1 StabilisciCredito( ) casi di test Una volta tradotti i requisiti in casi d uso, questi sono il collegamento con il modello fisico delle classi che dall analisi arriva alla progettazione, con i casi di test e con le unità di rilascio.

15 Livello di utilizzo degli use case Caso d uso di business: descrive l interazione con il sistema (in attesa di una risposta o di un evento). Caso d uso di sistema: implica l interazione con il software. Il costrutto caso d uso può essere utilizzato a livello di business e a livello di sistema. In ciascuno di questi due casi sarà assegnato uno stereotipo diverso in modo da poter distinguere quando il costrutto descrive l interazione con il sistema (in attesa di una risposta o di un evento) o l interazione con il software.

16 Relazioni fra Attori e Use Case relazione di associazione Un attore può essere in relazione con: uno use case (relazione di associazione) use case 1 Attore 1 un altro attore (relazione di generalizzazione) L attore specializzato eredità le associazioni dell attore base e può interagire con gli use case associati a quest ultimo. relazione di specializzazione attore base Attore 1 use case 1 use case 2 attore specializzato Attore 2 Gli attori possono essere in relazione con: un caso d uso; un altro attore. Nel primo caso la relazione è di associazione e sta ad indicare che l attore interagisce col sistema attuando la modalità di utilizzo descritta dal caso d uso. La relazione che lega un attore ad un altro attore è invece una generalizzazione secondo la quale l attore specializzato eredita le associazioni dell attore base e può interagire con i casi d uso associati a quest ultimo.

17 Esempio di Generalizzazione fra Attori diagramma use case senza relazione fra gli attori Cassiere Crea conto corrente Modifica conto corrente Funzionario Cancellazione conto corrente diagramma use case con la relazione fra gli attori Operatore Crea conto corrente Modifica conto corrente Cassiere Funzionario Cancellazione conto corrente Le relazioni fra gli attori aumentano la leggibilità dei diagrammi e forniscono un modello logico più articolato. In questo esempio viene introdotto il concetto di attore Operatore che può creare un conto o modificare un conto. Entrambi gli attori Cassiere e Funzionario specializzano Operatore (e quindi ereditano la possibilità di creare o modificare un conto), il primo non aggiunge nessuna funzionalità il secondo ha in più la possibilità di chiudere un conto.

18 Diagramma dei casi d uso di un Bancomat Bancomat Lista movimenti Utente Preleva Stampa saldo Attiva bancomat Operatore Disattiva bancomat Leggi registrazioni Consorzio Banche Questo esempio mostra come un semplice diagramma contenga tutte le informazioni fondamentali del sistema bancomat. Mette in luce quali sono le attività che possono essere eseguite e soprattutto chi ha la capacità di svolgerle.

19 Casi d uso e scenari Uno scenario definisce un comportamento elementare all interno del caso d uso ovvero rappresenta un percorso del caso d uso; per ogni caso d uso si possono avere n scenari;

20 Le Relazioni fra Use Case Sistemi di grandi dimensioni o articolati forniscono responsabilità che potrebbero: condividere comportamenti comuni; essere estese da altre responsabilità. In queste situazioni l uso di relazioni tra gli Use Case può comportare un enorme risparmio di tempo per la modellazione fattorizzando i comportamenti comuni oppure riusando degli use case esistenti. Le Relazioni fra Use Case Le relazioni fra Use Case sono: inclusione estensione generalizzazione incorpora il comportamento di uno use case in un altro estende uno use case con un comportamento opzionale consente di specializzare uno use case Uno dei vantaggi più significativi derivanti dall impiego dei casi d uso, riguarda la possibilità di legarli attraverso delle relazioni di inclusione, estensione o generalizzazione, che permettono di esprimere, in maniera chiara, applicazioni caratterizzate da una certa complessità.

21 Qualora un caso d uso risultasse abbastanza complesso da annettere numerosi scenari (ognuno dei quali rappresenta un comportamento opzionale) sarebbe possibile distinguere più casi d uso legati da una relazione di estensione; al contrario si può verificare che un caso d uso ne includa un altro, in questo caso la relazione sarà di inclusione, infine, alcune funzionalità del sistema potrebbero essere specializzate con altre a cui corrisponderanno altrettanti casi d uso legati alla funzionalità padre da una relazione di generalizzazione/specializzazione.

22 Diagramma delle classi classe: una collezione di oggetti, con propri attributi ed operazioni Libro cod_libro titolo data edizione ISDN data acquisizione richiesta( ) restituzione( ) create( ) Libro prezioso valore : lire = 0 valorizza( ) 0..* 1..* 0..* pubblicato da Prestito scritto da 0..* 1 0..* Editore ragione sociale nome breve indirizzo sede telefono variazione dati editore( ) Autore nome : type = initval cognome : type = initval anno nascita anno morte Utente variazione anagrafica( ) variazione anagrafica( ) Diagramma delle classi E la descrizione di un insieme di oggetti che condividono gli stessi attributi, operazioni, metodi, relazioni e semantiche. UML usa il termine caratteristiche per indicare le proprietà e le operazioni di una classe. Le proprietà rappresentano le caratteristiche strutturali di una classe. Il diagramma delle classi è uno strumento fondamentale per le metodologie Object Oriented ed è utilizzato in diversi momenti del ciclo di vita di un sistema informativo per modellarne la struttura statica a diversi livelli di astrazione: per descrivere modelli concettuali nelle attività di analisi, per definire delle specifiche nel corso del progetto, per definire particolari tecniche di implementazione.

23 Un diagramma delle classi descrive il tipo degli oggetti che fanno parte di un sistema, le varie tipologie di relazioni statiche tra di essi (di dipendenza, associazione, generalizzazione e realizzazione), le proprietà, ossia le caratteristiche strutturali come gli attributi e le associazioni, le operazioni di una classe, i vincoli che si applicano ai collegamenti tra gli oggetti di una classe e le interfacce.

24 Diagramma delle classi diagramma delle classi I diagrammi delle classi mostrano le classi che modellano un dominio del pproblema e le loro relazioni. Classe2 Classe3 assoc1 Classe1 Classe4 assoc2 Classe6 Classe5 assoc4 assoc3 diagramma degli oggetti I diagrammi degli oggetti mostrano le istanze delle classi in particolari istanti temporali. ist1:classe2 attz = val :classe3 attk = val attj = val :classe4 attw = val :classe6 attx = val atty = val Un diagramma degli oggetti equivale ad una fotografia del sistema in un particolare momento della sua vita descrivendo insiemi di oggetti, le loro relazioni e il loro stato. Dal momento che mostra istanze piuttosto che classi, un diagramma degli oggetti viene spesso chiamato diagramma delle istanze. L utilità associata a tale diagramma è duplice: facilita la comprensione degli aspetti strutturali del sistema nel suo complesso, in quanto fornisce una rappresentazione esemplificativa in termini di istanze degli oggetti del sistema piuttosto che di classi cui tali istanze appartengono; offre la possibilità di visualizzare lo stato di una porzione del sistema e la configurazione che tale porzione assume in un determinato momento del suo ciclo di vita permettendo l esamina di quali oggetti sono presenti, quale stato tali oggetti assumono e quali sono le relazioni tra di loro in modo da verificare il corretto funzionamento del sistema.

25 I diagrammi di interazione diagramma di sequenza I diagrammi di sequenza sono diagrammi di interazione focalizzati sull ordinamento temporale dei messaggi inviati agli oggetti. inst1:classe1 :classe2 :classe3 :classe5 msg1 «create» :classe6 msg2 msg3 msg4 msg5 «delete» I diagrammi di collaborazione sono diagrammi di interazione focalizzati sull organizzazione spaziale degli oggetti. diagramma di comunicazione 1 : msg1 2 : msg2 :classe2 istanza:classe1 :classe3 8 : msg8 7: msg7 :classe5 :classe6 4 : msg4 3 : msg3 5 : msg5 6 : msg6 :classe4 Un diagramma di interazione descrive il comportamento di gruppi di oggetti che collaborano tra loro per svolgere un determinato compito, o meglio rappresenta il flusso di controllo tra gli oggetti per la realizzazione di una funzione del sistema descritta in un caso d uso. La specifica dei diagrammi di interazione comporta l assegnazione di responsabilità agli oggetti, in quanto il fatto stesso che un oggetto sia in grado di rispondere ad un messaggio inviato da un altro oggetto, indica una decisione progettuale di assegnazione delle responsabilità. Nella sua versione più recente UML definisce quattro diversi formalismi per la descrizione delle interazioni: il diagramma di sequenza, di comunicazione (o collaborazione), di temporizzazione e di sintesi dell interazione. In particolare il diagramma di sequenza è la tipologia più utilizzata dei diagramma di interazione e documentano il comportamento di un singolo scenario. Un diagramma di sequenza infatti include un certo numero di oggetti, o meglio di partecipanti, e i messaggi scambiati tra essi durante l esecuzione del caso d uso. A ciascun partecipante è associata una linea tratteggiata verticale, o lifeline, sulla quale sono posizionate delle barre di attivazione utilizzate come punto di partenza e di arrivo dei messaggi da e verso il partecipante. La forza che scaturisce dall uso dei diagrammi di sequenza si riassume nella chiarezza con cui la sequenza delle chiamate evidenzia le modalità e le differenze di interazione tra i partecipanti illustrando cosa fa ognuno di essi. I diagrammi di comunicazione enfatizzano lo scambio di dati tra i partecipanti. Ogni oggetto è rappresentato tramite un icona e collegato agli altri oggetti tramite links, i messaggi scambiati sono preceduti

26 da un numero, secondo un particolare stile di numerazione progressivo o nidificato, ad indicare la sequenza con cui avvengono le chiamate. Invece di indicare ogni partecipante con la sua linea di vita e rappresentare l ordine dei messaggi in base alla posizione lungo l asse verticale, come nel diagramma di sequenza, quelli di comunicazione permettono di disegnare i partecipanti in qualsiasi posizione aggiungendo collegamenti per mostrare le connessioni. Volendo spiegare la differenza in modo più razionale, si può affermare che i diagrammi di sequenza esprimono meglio la successione delle chiamate, mentre quelli di comunicazione pongono l accento sul collegamento tra gli oggetti.

27 Diagramma di sequenza interfaccia richiesta : Utente : interfaccia biblioteca consente all'utilizzatore di richiedere in prestito uno o più libri 1: RichiestaPrestito L'utente fornisce i dati 2: relativi al libro (ai libri) che vuole in prestito. Il sistema verifica se l'utente è censito, 6: err: utente non censito ( 5: 9: Verifica quindi se ha 10: err: utente deve restituire libri in prestito da restituire, o se ne ha già tre in prestito, segnala l'impossibilità del prestito. Altrimenti il sistema controlla se i libri sono 14: 15: err: libro già in prestito disponibili, e se lo sono li fornisce all'utente, altrimenti segnala l'errore controllo : Utente : Libro : Prestito richiesta messaggio 3: ControlloUtentePerPrestito ( 4: 7: PrestitiDelCliente ( ) 8: 11: richiesta (cod_libro) 12: Prestito ( ) 13: oggetto specifica di scenario (caso d uso) attività dell oggetto Diagramma di sequenza: a cosa serve evidenzia il modo in cui uno scenario (uno specifico percorso in un caso d uso) viene risolto dalla collaborazione tra un insieme di oggetti specifica la sequenza dei messaggi che gli oggetti si scambiano può specificare nodi decisionali e iterazioni diagrammi di sequenza e diagrammi di collaborazione (di comunicazione) esprimono informazioni simili, ma le evidenziano in modo diverso

28 Diagramma di sequenza Asse verticale: tempo, dall'alto verso il basso Asse orizzontale: oggetti, da sinistra verso destra in ordine decrescente di importanza; nella prima colonna l'oggetto che avvia la collaborazione Due caratteristiche importanti, per ciascun oggetto la "linea della vita" il "focus of control": evidenzia il periodo di tempo durante il quale un oggetto sta eseguendo un'azione, direttamente o utilizzando una procedura subordinata

29 Ancora diagramma state machine I diagrammi statechart mostrano la macchina a stati che modella la logica di controllo di un oggetto. evento / azione Stato A Stato B Stato C Inizio del ciclo di vita dell oggetto evento / azione evento / azione diagramma delle attività evento / azione Fine del ciclo di vita dell oggetto I diagrammi delle attività mostrano i flussi fra le attività, cioè fra azioni non atomiche. [condizione] Attività 1 Attività 5 [condizione] Attività 4 Attività 2 Attività 3 Negli approcci Object Oriented il comportamento assunto da un singolo oggetto durante il suo ciclo di vita viene riassunto in un diagramma di macchina a stati. Un oggetto può assumere diversi stati nel contesto dei casi d uso ai quali partecipa e i suddetti diagrammi servono proprio a chiarire la logica con la quale avviene il passaggio da uno stato all altro. Gli elementi principali di questo diagramma sono tutti i possibili stati e le transizioni che indicano i possibili passaggi di stato. Più stati possono essere raggruppati in superstati allo scopo di indicare in modo semplice un comportamento comune dell oggetto in stati differenti, ad esempio transizioni che si svolgono in modo identico da e verso un gruppo di stati. Ovviamente non è pensabile produrre un diagramma per ogni classe, il che risulterebbe oneroso e al tempo stesso inutile, ma ci si limita a quelle che hanno una logica interna interessante e complessa in modo da migliorare la comprensione del loro funzionamento. I diagrammi di attività sono in grado di modellare gli aspetti dinamici di un sistema in quanto rappresentano l insieme di azioni da svolgere per ottenere un certo risultato. Per questa ragione vengono utilizzati per descrivere una logica procedurale, processi di business e workflow. Le attività che prendono parte a un diagramma di questo tipo hanno inizio a partire dal nodo iniziale e terminano in uno o più punti che indicano la fine della sequenza. Le relazioni che collegano un attività all altra rappresentano il passaggio del flusso di controllo e possono essere di varia natura: è possibile che più sequenze di azioni vengano svolte contemporaneamente, in questo caso i flussi di attività saranno introdotti da un fork, ossia un elemento grafico che ha un solo flusso in ingresso e tanti flussi in uscita quanti sono i flussi di controllo eseguiti in modo concorrente; ovviamente ovunque ci sia parallelismo sorge anche

30 la necessità di sincronizzarsi, ovvero di ricomporre i vari flussi in uno unico. Per esprimere tale esigenza si ricorre all elemento grafico di join caratterizzato da più flussi in ingresso e un solo flusso in uscita. In certi casi infine l esecuzione di un attività potrebbe essere stabilita di volta in volta in seguito al verificarsi di una certa condizione: opportuni punti di decisione daranno quindi luogo a flussi distinti ciascuno contraddistinto da guardie tutte mutuamente esclusive. Un merge servirà a segnalare la fine del comportamento condizionale. In questo modo il diagramma delle attività si limita a specificare le regole essenziali di ordinamento, quelle che non possono essere violate, lasciando al responsabile del processo descritto la libertà di scegliere l ordine di esecuzione delle azioni. Questo è molto utile in fase di modellazione di business, dal momento che in tale ambito spesso si verifica che i processi sono svolti in parallelo. Inoltre, sempre per far fronte ad esigenze che emergono durante l attività di modellazione, ricorrendo alla divisione del diagramma in partizioni risulta possibile associare ad una singola organizzazione o ad una classe già identificata la responsabilità di ciascuna delle azioni presenti nel diagramma. È evidente dunque che questo tipo di diagramma può essere utilizzato per mostrare il comportamento di organizzazioni il cui sistema software si trova ad interagire con processi molto complessi e più in generale per analizzare in dettaglio le attività previste all interno di uno use case, evidenziando i vincoli di sequenzialità fra diverse attività o invece la possibilità di eseguire alcune attività in parallelo.

31 Diagramma di stato stato iniziale acquisizione libro( dati libro, autori, editore ) evento transizione di stato stato acquisito prestito( data ) in prestito stato finale cancellazione libro( ISDN ) restituzione( data restituzione ) restituzione( data restituzione ) cancellazione libro( ISDN ) scadenza termini in ritardo sollecito Diagramma di stato: a cosa serve specifica il ciclo di vita degli oggetti di una classe, definendo le regole che lo governano quando un oggetto si trova in un certo stato può essere interessato da determinati eventi (e non da altri) come risultato di un evento l oggetto può passare ad un nuovo stato (transizione)

32 Esempio di Diagramma di Attività con Swimlanes Cliente Vendita Magazzino stato di sincronizzazione (fork) Richiesta prodotto Ricezione ordine stato di sincronizzazione (join) Pagamento Evasione ordine Consegna ordine Archiviazione ordine Diagramma delle attività: a cosa serve a rappresentare sistemi di workflow, oppure la logica interna di un processo (di qualunque livello, dai business process ai processi di dettaglio) permette di rappresentare processi paralleli e la loro sincronizzazione è un caso particolare di diagrammi di stato, in cui ogni stato è uno stato di attività

33 Diagramma delle attività Attivit: esecuzione non atomica (in una macchina a stati); include azioni (esecuzione di operazioni, calcoli, invio di messaggi,) Diagramma delle attivit: descrive il flusso fra attivit I diagrammi delle attivit sono quindi più dettagliati dei diagrammi dinterazione (diagramma delle sequenze e diagramma di collaborazione)

34 Diagramma di flusso oggetto-azione Cliente Vendite Magazzino richiedi servizio paga ordine [effettuato] ricevi ordine ordine [completato] ordine [inserito] completa ordine ricevi merce ordine [spedito] spedisci merce Diagramma di flusso oggetto-azione: a cosa serve a rappresentare le interazioni tra processi e oggetti è un caso particolare di diagramma di attività è un vero e proprio flow chart

35 Considerazioni: UML è uno standard, e questo è un bene (uniformità nei concetti e nelle notazioni utilizzate, interoperabilità tra strumenti, indipendenza dai produttori, dalle tecnologie, dai metodi) UML è articolato: può rappresentare qualunque sistema, a diversi livelli di astrazione UML è complesso: va adattato ("ritagliato") in base alle specifiche esigenze dei progettisti e dei progetti, utilizzando solo ciò che serve nello specifico contesto

36 Systems Modeling Language è un linguaggio di modellazione che supporta la specifica, l analisi, il design, la verifica e la validazione di un ampio insieme di sistemi complessi che possono includere: hardware servizi software personale informazioni impianti System Modeling Language è uno standard di OMG per la rappresentazione dei sistemi complessi non solo software. Lo standard per la rappresentazione del software deriva da UML, pertanto SysML può essere considerato un profilo di UML, cioé una sua estensione ufficiale per la rappresentazione di sistemi complessi, costituiti da componenti hardware e software. La prima versione di SysML (1.0) è del settembre 2007, la 1.1 del maggio 2008, mentre lapiù recente, la 1.2 del giugno 2010.

37 Systems Engineering: non solo requisiti Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem. Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. INCOSE (Intl. Council on Systems Engineering) Il Systems Engineer deve avere: visione interdisciplinare: i sistemi non sono fatti SOLO di software, ma anche di hardware, di meccanica, etc. capacità di mediazione tra le esigenze del business e i vincoli tecnici, con un occhio alle nuove opportunità tecnologiche. Cerchiamo di capire che cosa si intende veramente per Systems Engineering. Quella nel riquadro è la definizione che ne dà la INCOSE, l International Council on Systems Engineering, un ente internazionale e indipendente che da molti anni si occupa della definizione di metodologie per il Systems Engineering. E chiaro che quello che emerge è che il sistemista ha un ruolo estremamente importante nella progettazione di sistemi complessi. Al sistemista è richiesto avere: una visione interdisciplinare: i sistemi non sono fatti SOLO di software, ma anche di hardware, di meccanica, etc..; la capacità di mediazione tra le esigenze del business e i vincoli tecnici, con un occhio alle nuove opportunità tecnologiche. System Engineering è, dunque, un approccio interdisciplinare e mezzi per consentire la realizzazione di sistemi di successo. Esso si concentra sulla definizione delle esigenze dei clienti e delle funzionalità richieste nelle prime fasi del ciclo di sviluppo, sul documentare i requisiti, quindi di procedere con la progettazione di sintesi e di convalida del sistema, mentre si prende in considerazione il problema nel suo complesso. Systems Engineering integra tutte le discipline e gruppi specializzati in un lavoro di squadra strutturato formando un processo di sviluppo che parte dal concetto di produzione operativa. Systems Engineering ritiene sia il business e le esigenze tecniche di tutti i clienti l'obiettivo per fornire un prodotto di qualità che soddisfi le esigenze degli utenti.

38 Systems Modeling Language Riuso di parte del meta-modello UML 2.1 Tra i nuovi elementi introdotti: il requisito testuale il blocco il constraint block Il SysML è basato su un subset del meta-modello di UML 2.1 con delle specifiche estensioni, di qui l omogeneità e l inter-operabilità dei con i modelli di design. Tra le numerose novità introdotte dallo standard, abbiamo tre nuove entità di modello: il requisito testuale, che permette di visualizzare e relazionale l elemento fondamentale del Requirement Engineering e le relazioni che esistono con gli elementi di design del modello UML (superando ampiamente i limiti e gli usi impropri degli use case che spesso venivano usati come rappresentazioni dei requisiti nel modello); il blocco, che è una estensione della classe. Questa così come è non poteva andare bene per il System Engineering perché pensata espressamente per i sistemi software. Il blocco serve a descrivere le parti del sistema e la struttura interna delle parti; il constraint block, che non è semplicemente la possibilità di vincolare gli elementi UML che era già presente in UML (esempio il linguaggio formale OCL), ma qualcosa di più e specifico per il Systems Engineering perché permette di modellare proprietà, formule e quantità invarianti della struttura interna del sistema. Insieme alle nuove entità, sono state aggiunti i corrispondenti nuovi diagrammi che forniscono la prospettiva visuale (punti di vista) dei Requisiti (Requirement Diagram), della struttura del sistema (Definition e Internal Block Diagram), dei vincoli parametrici (Constraint Block Diagram).

39 Processo di sviluppo: note introduttive Business Modeling Analisi e Definizione dei Requisiti Analisi Concetuale Progettazione Implementazione Test e collaudi Il processo di sviluppo di un sistema software è costituito da un insieme di passi che consentono di muoversi dalle attività di Business Modeling e Analisi dei requisiti fino all Implementazione e alla consegna del sistema guidando i diversi team di lavoro durante l intero ciclo di vita del sistema informatico.

40 Il Modello a Cascata Business Modeling Analisi e Definizione dei Requisiti Analisi Concetuale Progettazione A cascata vuol dire che lo sviluppo del sistema procede attraverso una fase alla volta: una fase viene terminata completamente e quindi si passa alla successiva. Implementazione Test e collaudi Inizialmente si riteneva che lo sviluppo di un sistema potesse essere condotto mediante un approccio sequenziale, cosiddetto a cascata, che consta di una sequenza di fasi strutturata in analisi dei requisiti, progetto, sviluppo, collaudo, integrazione e manutenzione. Ciascuna di queste fasi produce un ben preciso output che viene utilizzato come input per la fase successiva. Sebbene il modello a cascata ebbe un enorme successo negli anni settanta quando venne teorizzato e viene utilizzato ancora oggi, la complessità crescente dei sistemi da realizzare ha reso impraticabile questo approccio. Infatti le attività di analisi e progettazione di un grande sistema si presentano di lunghezza e complessità tali da ritardare oltremodo l avvio del sistema e da comportare rischi di obsolescenza del sistema prima che lo stesso entri nella fase realizzativa.

41 Il Modello Incrementale Incrementale vuol dire creare qualcosa pezzo per pezzo e integrare i pezzi un po alla volta per realizzare il sistema finale. Tale modello deriva dalla fusione del modello a cascata e di quello iterativo, infatti prevede lo svolgimento sequenziale di quattro fasi - analisi dei requisiti, progetto, codifica e test (o collaudo)- che si ripetono in blocco in modo che in uscita da ogni sequenza di svolgimento delle fasi si ottenga una versione funzionante del sistema, migliore della precedente. L utilizzo di questo modello supera i limiti del modello a cascata e consente una progettazione adeguata in quanto conduce ad un sistema solido. Tale approccio è consigliabile quando si ha fin dall inizio una visione abbastanza chiara dell intero progetto, perché occorre fare in modo che la realizzazione della generica versione k risulti utile per la realizzazione della versione k+1.

42 Piano metodologico di riferimento Disciplina Modello Elaborato Business Modeling Linguaggio naturale UML Business Use Case diagram Documento di Visione Analisi e definizione dei requisiti Analisi concettuale Progettazione Realizzazione Verifica Sistemi Informativi Aziendali Le attività che costituiscono la realizzazione di un progetto informatico sono quelle riportate nella prima colonna della tabella. A ciascuna di queste attività corrisponde un modello, ossia un insieme di artefatti creati come il risultato di un processo di astrazione che viene adottato per eliminare i dettagli inessenziali ai fini della specifica attività condotta e per comunicare i risultati e agevolarne la comprensione. In questo modo ciascuna attività svolta prevede l emissione di prodotti-elaborato che consentono di descrivere nel dettaglio quanto previsto nell ambito di ciascuna di esse.

43 Metodologia di riferimento Il RUP è un processo per lo sviluppo del software, definito e commercializzato da Rational nel 1999 (nel 2003 la Rational è stata acquisita da IBM), che provvede a disciplinare l'assegnazione dei compiti e delle responsabilità nel contesto di un progetto software. Un processo di sviluppo del software identifica un insieme di attività necessarie per trasformare le esigenze dell'utente in un'applicazione software. Anche se RUP (Rational Unified Process) viene spesso chiamato processo è in realtà un infrastruttura per la definizione di processi che fornisce un vocabolario e una struttura generica utile per discutere i processi software. Per questo la prima cosa da fare quando si sceglie di adottare il RUP è definire il caso di sviluppo, ossia il particolare processo adottato per il progetto corrente. Infatti a seconda delle esigenze del progetto, del tipo di sistema che si deve costruire e delle sue dimensioni oltre che della tecnologia utilizzata, varieranno l esatta sequenza dei passi da compiere e i prodotti rilasciati durante il processo. A prescindere dal particolare caso di sviluppo il RUP è un processo iterativo e incrementale: il sistema non viene rilasciato un unica volta alla fine del processo ma in passi successivi. Questo permette dei vantaggi significativi quanto più aumenta la complessità del sistema da sviluppare. Innanzitutto la comprensione del problema da risolvere non avviene in un unica fase iniziale ma in passi successivi con il raffinamento e la crescita incrementale di un medesimo modello nel corso di cicli successivi. Inoltre l approccio iterativo garantisce la possibilità di accogliere nuove esigenze o modifiche negli obiettivi per i quali viene sviluppato il sistema e di affrontare e risolvere già nelle fasi iniziali i rischi collegati allo sviluppo del sistema quali i rischi tecnologici, professionali e organizzativi.

44 Le Discipline del RUP Una disciplina (processo) definisce tutte le attività attraverso le quali viene prodotto un insieme di artefatti. Un artefatto (elaborato) è un insieme di informazioni usato o prodotto dal processo di sviluppo del software. Una disciplina è descritta da: discipline Elementi di base Concetti Workflow Elenco delle attività Elenco degli artefatti Elenco delle linee guida Il RUP prevede le discipline, o core workflows, ciascuna delle quali definisce le attività attraverso le quali vengono prodotti gli artefatti. Queste discipline servono anche a raggruppare logicamente i vari elementi della componente statica e sono a loro volta suddivise in engineering workflows e supporting workflows Un artefatto è un insieme di elementi del progetto realmente tangibili (elaborato) usato o prodotto dal processo di sviluppo del software. Un aretfatto può presentarsi sotto moletplici forme: come Modelli o Elementi di modelli (ad esempio diagramma dei casi d uso e dunque caso d uso, classe,...), come documenti generici o codici sorgente, come eseguibili (ossia come prototipi funzionanti). Ogni disciplina è descritta tramite diversi elementi acui corrisponde una specifica rappresentazione grafica.

45 Gli Elementi di RUP Il RUP è descritto usando quattro elementi: Workflow (quando) Worker (chi) Attività (come) Artefatti (cosa) Il RUP è rappresentato usando quattro elementi di modellazione: i workflow, che chiariscono quando le cose vengono realizzate; i worker, che rappresentano chi fa il lavoro, sia esso una singola persona o un gruppo di lavoro; le attività, che esprimono come viene svolto il lavoro; gli artefatti, che mostrano cosa viene fatto. Un workflow è una sequenza di attività che produce un risultato osservabile; ovvero è quella cosa che, raggruppandoli logicamente, va oltre il semplice elenco di ruoli, attività e artefatti, andando a palesare le interazioni tra essi. In UML sono espressi come sequence diagram, collaboration diagram o activity diagram. I workflow sono solitamente espressi in varie forme, comunemente abbiamole Discipline, ovvero workflow di alto livello e i Workflow Details che sono i workflow presenti all interno delle discipline I worker, o ruoli, sono come un cappello che una persona o un gruppo indossa. Una persona o un gruppo può ricoprire più ruoli e un ruolo può essere ricoperto da più persone.

46 Una attività relativa a uno specifico ruolo è una unità di lavoro da svolgere, caratterizzata da un preciso traguardo espresso come modifica o creazione di artefatti. Le attività possono essere ripetute da parte dello stesso ruolo più volte sullo stesso artefatto, anche se il ruolo non è lo stesso individuo. Un artefatto è un insieme di elementi del progetto realmente tangibili (elaborato) usato o prodotto dal processo di sviluppo del software. Un aretfatto può presentarsi sotto moletplici forme: come Modelli o Elementi di modelli (ad esempio diagramma dei casi d uso e dunque caso d uso, classe,...), come documenti generici o codici sorgente, come eseguibili (ossia come prototipi funzionanti).

47 Le Fasi del RUP Le quattro fasi del ciclo di vita del processo RUP sono: 1. ideazione: obiettivo di questa fase è comprendere profondamente il contesto del business, quindi definire il dominio del problema e scoprire tutti i requisiti di alto livello. In questa fase è possibile effettuare una stima preliminare dei tempi e dei costi relativi al progetto che si vuole intraprendere contestualmente all identificazione degli eventuali rischi connessi; 2. elaborazione: la fase di elaborazione ha la responsabilità di affrontare la maggior parte delle difficoltà legate all aspetto tecnologico del sistema. Devono essere affrontate le problematiche relative al design, all implementazione, al testing, alla scelta dell architettura di base e delle interfacce, ponendo particolare attenzione sulle comunicazioni inter-processo e alla persistenza dei dati; 3. costruzione: in questa fase avviene l implementazione del software; vengono prodotte varie release interne e alla fine si deve ottenere una prima versione beta funzionante e completa di documentazione, materiale di supporto all utilizzo e pronta per l installazione; 4. transizione: alla fine del ciclo di vita ci si occupa del testing complessivo e delle modifiche di poco conto. Si affrontano il fine-tuning e le piccole modifiche legate al feedback ottenuto dall utente finale (se si è operato in modo corretto in tutte le fasi queste modifiche saranno inezie, poiché le modifiche importanti e strutturali devono già essere emerse nelle fasi precedenti).

48 Schematizzazione del RUP Il processo è strutturato su due dimensioni: la struttura dinamica, ovvero la dimensione temporale del processo, l asse orizzontale in figura che mostra come il processo, espresso come cicli, fasi, iterazioni e milestones si distribuisce su tutto il ciclo di vita del progetto; la struttura statica: è l asse verticale in figura e raggruppa logicamente in workflow gli elementi del processo (attività, discipline, ruoli e artifatti).

49 Fasi e Milestone Una fase ha le seguenti caratteristiche: identifica il periodo di tempo fra due milestone principali del processo; durante la fase vengono soddisfatti un insieme ben definito di obiettivi; durante la fase vengono completati degli artefatti; include le decisioni per passare alla fase successiva. Un milestone principale ha le seguenti caratteristiche: è un evento a livello di sistema definito al termine di ogni fase di sviluppo per dare visibilità a elementi significato a livello di sistema; sincronizza le prospettive gestionali e ingegneristiche; verifica che gli obiettivi della fase siano stati raggiunti.

50 Sviluppare un Progetto in Modo Iterativo Sviluppare un progetto in maniera iterativa vuol dire eseguire in modo ripetitivo un insieme di processi o di attività orientati al miglioramento di un prodotto parziale fino a farlo diventare prodotto finale. Sviluppare un Progetto in Modo Iterativo Una release è un insieme relativamente completo e consistente di artefatti, contenente possibilmente una versione eseguibile del sistema (build). Una release rappresenta un rilascio formale del risultato di un iterazione e pertanto deve essere formalmente pianificata. Nella categoria dei modelli iterativi rientrano tutti i processi di sviluppo che permettono di ritornare ad una fase del procedimento già affrontata in precedenza. Per ogni fase iterabile si tende a partire con un abbozzo della soluzione che verrà successivamente raffinata al passaggio seguente.

51 Schematizzazione di un Iterazione Il RUP si basa su un approccio di tipo iterativo e incrementale che consiste in una serie di step, detti iterazioni, ripetuti per raffinarne il prodotto. Ciascuna iterazione può coinvolgere tutti o solo alcuni dei settori dello sviluppo, dalla raccolta dei requisiti all analisi passando per le fasi di design e implementazione. L output di una iterazione equivale all input dell iterazione successiva che, a sua volta, restituisce un output più raffinato facendo così evolvere il prodotto fino ad ottenere il prodotto finale, completo e perfettamente funzionante. Ogni iterazione ha un focus on differente a seconda dell avanzamento del progetto: le prime iterazioni sono comunemente incentrate sulla raccolta dei requisiti e sull analisi mentre le iterazioni svolte sul prodotto ad uno stadio più maturo si concentrano principalmente sulle fasi di implementazione e test. Questo tipo di approccio permette di aggredire in modo molto efficace le criticità tipiche dello sviluppo del software ed in particolar modo permette di: evidenziare i problemi gravi in maniera molto precoce, permettendo così di porvi rimedio efficacemente e a basso costo; aumentare gli scambi informativi con i clienti, in modo da individuarne le reali aspettative e i reali requisiti del sistema; anticipare i test sul prodotto in modo da valutare in maniera oggettiva lo stato di avanzamento del progetto ed evidenziare precocemente le incoerenze tra requisiti e prodotto; migliorare il processo di sviluppo stesso utilizzando le conoscenze acquisite dai gruppi di lavoro nel corso del progetto.

52 Il Modello Iterativo Il modello iterativo indica che un sistema, un sottosistema, un componente, ecc., viene realizzato in più passi in modo che a ogni passo una parte di essi venga creata estendendo e arricchendo in modo consistente un altra parte già realizzata. Fasi del RUP e Iterazioni

53 Model Driven Architecture: che cosa è MDA? L MDA ha come scopo la definizione delle soluzioni in modo indipendente dalla piattaforma tecnologica. ciò garantisce la portabilità delle stesse soluzioni ai medesimi problemi presenti anche in progetti diversi; il concetto di piattaforma è molto di più esteso di quello che si potrebbe pensare: oltre a OS e HW, comprende anche framework di simulazione e di testing; MDA invita a progettare un intero sistema con modelli diversi, uno per ogni livello di astrazione, assicurando in cambio una completa portabilità della soluzione grazie a delle trasformazioni tra modelli di diverso livello. Model Driven Architecture è uno standard OMG che ha come scopo la definizione delle soluzioni in modo indipendente dalla piattaforma tecnologica su cui viene realizzata. Ciò garantisce la portabilità delle stesse soluzioni ai medesimi problemi presenti anche in progetti diversi. Il concetto di piattaforma è molto di più esteso di quello che si potrebbe pensare, include, oltre a OS e HW, anche framework di simulazione e di testing. Quindi far migrare una stessa applicazione da una piattaforma all altra può includere: simulare e testare una applicazione embedded su un normale PC (piattaforma = OS+dispositivi HW); instrumentare il codice per valutare la copertura dei test (piattaforma + framework di testing). MDA invita a progettare un intero sistema con modelli diversi, uno per ogni livello di astrazione, assicurando in cambio una completa portabilità della soluzione grazie a delle trasformazioni tra modelli di diverso livello.