Riferimenti Iniziali Introduzione a UML

Transcript

1 Riferimenti Iniziali Introduzione a UML UML Distilled, Martin Fowler, Addison-Wesley, Giuseppe Berio Obiettivi della Presentazione Fornire una panoramica sugli elementi principali di UML, dal punto di vista del loro utilizzo Discutere i pregi e i limiti di UML Le Attività di un Progetto Software Requisiti del Contesto (Requisiti) Requisiti del Software (Analisi) Progetto del Software Implementazione del Software Verifica e Validazione (Test) Manutenzione del Software Project Management

2 Requisiti del Contesto e del Sistema Introduzione a UML Panorama OOA/OOD/OOP decine di metodologie con centinaia di personalizzazioni più di cinquanta strumenti CASE e Meta-CASE, ognuno con la propria interpretazione delle metodologie centinaia di tool e ambienti di sviluppo che gestiscono componenti, ognuno con i propri concetti e il proprio repository non esiste consenso su questi approcci soprattutto tra keyplayers Introduzione a UML Il Progetto UML principalmente, convergenza di tre proposte (Rumbaugh,OMT, Booch,OOD, Jacobson,OOSE) scopo : fornire un supporto a tutte le attività sul software copre la fasi di analisi e progetto anche se nato principalmente per la progettazione del software la versione 1.1 e stata accettata da OMG nell ottobre 1997 la versione attuale 1.3, non totalmente compatibile con la precedente, è in evoluzione: si attende la versione 2.0 nel corso del 2001 Unified Modelling Language Notazione Regole Sintattiche o come i simboli possono essere combinati Semantiche o significato dei simboli e dei costrutti Pragmaticheo come usare il linguaggio o simboli grafici e costrutti testuali Strutturate in un Architettura a Quattro Livelli

3 Differenti Viste in UML Vista Strutturale Diagrammi delle classi Diagrammi degli oggetti Vista Comportamentale Diagrammi di sequenza Diagrammi di collaborazione Diagrammi di stato Diagrammi di attività Vista Utente Diagrammi Casi d uso Vista di Implementazione Diagrammi delle componenti Vista di Ambiente Diagrammi di distribuzione Uso Diagrammi UML I diagrammi vengono usati per definire modelli, che sono poi il risultato di ogni attività riguardante il software Ogni modelli è costruito sulla base di un diagramma Il modello deve (dovrebbe) essere sempre consistente con gli altri modelli avere un certo livello di dettaglio La Vista Utente Uno scenario è una sequenza di passi che descrivono l interazione tra un sistema e un utente (che dovrebbe trarre vantaggio dall interazione) Es.: Negozio online su World Wide Web (NOL) scenario: Acquisto di un Prodotto Il cliente naviga nei catalogo e raccoglie gli articoli desidera/i in un carrello della spesa virtuale. Quando il cliente desidera pagare, descrive la modalità di spedizione e fornisce la necessaria informazione riguardante la propria carta di credito prima di confermare l acquisto. Il sistema controlla se la carta di credito è valida e conferma l acquisto sia immediatamente che con un successivo messaggio di posta elettronica. Questo scenario descrive come potrebbero andare le cose. Tuttavia, la carta di credito potrebbe non essere valida: questo rappresenterebbe uno scenario separato. un caso d uso è un insieme di scenari legati da un obiettivo comune per l utente Es.NOL: caso d uso Acquisto di un Prodotto con due scenari corrispondenti a: successo della transazione invalidità della carta di credito Rappresentazione del caso d uso: descrizione degli scenari e delle relazioni esistenti tra essi Esempio: Acquisto di un Prodotto Obiettivo: vendita on-line di prodotti Scenario principale: 1. Il cliente naviga nel catalogo e seleziona gli articoli da comprare. 2. Il cliente accede alla finestra di dialogo (check out). 3. Il cliente indica le informazioni relative alla spedizione (indirizzo; scelta tra consegna giornaliera o entro 3 giorni). 4. Il sistema presenta un prospetto con il totale (comprese le spese di spedizione) 5. Il cliente fornisce le informazioni sulla carta di credito. 6. Il sistema autorizza l acquisto. 7. Il sistema conferma immediatamente la vendita. 8. Il sistema invia al cliente un di conferma. Alternativa: Carta di credito non valida Al passo 6, il sistema non autorizza l acquisto con carta di credito. Si deve permettere al cliente di reinserire le informazioni relative e riprovare. Alternativa: Cliente abituale 3a.Il sistema visualizza l informazione sull indirizzo precedentemente memorizzata, il conto totale e le ultime quattro cifre del numero della carta di credito. 3b.Il cliente può accettare o ridefinire queste informazioni di default. Si ritorna allo scenario principale a partire dal passo 6

4 I casi d uso possono essere descritti mediante diagrammi UML (è importante notare che non è necessario disegnare questi diagrammi per utilizzare i casi d uso) Concessione Attività Sportiva Circoscrizione Casi d uso include Stipula contratto include Prenotazione Tennis Impiegato Persona Attore Sistema (dominio) Esempio relativo alla prenotazione di un campo da tennis: l utente richiede il campo desiderato l impiegato verifica la disponibilità del campo per il giorno e l ora richiesta l utente paga la prenotazione del campo l impiegato rilascia una ricevuta Definizione di Caso d Uso da OMG Un caso d uso serve per descrivere il comportamento di un'entità senza rivelarne il contenuto. Un caso d uso è una sequenza di attività, comprese le varianti, che l'entità segue interagendo con i suoi attori. L'entità può essere un sistema, un sottosistema oppure una classe. Il fatto di avere un obiettivo comune (misurabile per gli attori) è legato alla necessità di giustificare il caso d uso; ciò costituisce una regola pragmatica di UML ma: gli attori che perseguono l obiettivo del caso d uso talvolta non interagiscono direttamente con tale caso d uso; viceversa, gli attori che interagiscono direttamente con il caso d uso non perseguono direttamente l obiettivo espresso. La Vista Utente Un attore è un ruolo(i) interpretato(i) da un utente(i) (entità esterna) nei confronti dell entità a cui il caso d uso appartiene. Un utente può ricoprire più di un ruolo: quando si ragiona in termini di attori, è importante concentrarsi sui ruoli e non sugli utenti. Gli attori partecipano ai vari casi d uso; un singolo attore può partecipare a più casi d uso; viceversa in un caso d uso potrebbe parteciparvi più attori. Dovrebbe essere definito un attore speciale, chiamato attore principale, il quale da inizio al caso d uso (e dovrebbe essere il più interessato ai risultati prodotti dal caso d uso). Gli attori possono essere in relazione di generalizzazione, per esprimere il fatto che un attore ha tutti i ruoli di un altro attore e può sempre sostituire questo ultimo. La Vista Utente Identificare i Casi d Uso Il concetto di attore è utile soprattutto quando si cerca di definire i casi d uso; per sistemi complessi può risultare difficile compilare una lista di casi d uso: può essere utile compilare una lista di attori, poi identificare i casi d uso che coinvolgono ogni attore. Un altra fonte per l identificazione dei casi d uso, sono gli eventi esterni (generati da attori) ai quali il sistema deve reagire: un certo evento può o deve causare una reazione del sistema: identificare gli eventi ai quali bisogna rispondere aiuterà ad identificare i casi d uso. Non occorre preoccuparsi eccessivamente delle relazioni attori/casi d uso; in genere, quello che davvero importa sono i casi d uso mentre gli attori sono solo un modo possibile di identificarli: bisogna comprendere bene i casi d uso e gli obiettivi degli attori che essi soddisfano.

5 Identificare i Casi d Uso con gli Obiettivi degli Attori has Actor Goal names justified by participates in Use Case contains Scenario Casi d Uso e Sottosistemi other company company other dept. computer system other System Our Sys. subsystem E possibile raffinare i casi d uso sfruttando una gerarchia di sottosistemi fino a raggiungere il sistema informatico ovvero il software. Utilizzare i Casi d Uso per Rappresentare i Requisiti del Software (ed anche per il Contesto) dal punto di vista degli attori Verificare e Validare il progetto del software Quality assurance Sviluppare help-on-line o manuali utente Documentare il software Non Utilizzare i Casi d Uso per L implementazione (a meno di situazioni particolari) Rappresentare una visione funzionale del sistema Casi d Uso e Requisiti Funzionali Requisito Funzionale Use Case Step Step Step Step Requisito Funzionale Requisito Funzionale

6 Relazioni tra Casi d Uso Esempi di Generalizzazione Inclusione Estensione Generalizzazione <<include>> Prelevare Banconote Interagire con ATM Verificare Saldo Ricarica Telefono Interagire con ATM Verificare Saldo Comprare on-line Comprare on-line con Carta Esempio di <<include>> e <<extend>> Fornire Dati del Cliente Riassumendo La condivisione di un caso d uso dovrebbe essere rappresentata da: - <<include>>, se il suo utilizzo è sempre richiesto, - <<extend>>, se il suo utilizzo è opzionale e i casi d uso che devono essere estesi sono ragionevolmente completi. <<include>> Ordinare un Prodotto Extension Points Richiesta del cliente: Addetto Call-Centre Un diagramma di casi d uso dovrebbe: - contenere solo casi d uso a un certo livello di astrazione, - rappresentare solo gli attori necessari. Cliente dopo la creazione dell ordine <<extend>> Il cliente chiede un prodotto fuori catalogo Richiesta di Prodotti Fuori Catalogo Se molti casi d uso sono necessari, dovrebbero essere raggruppati logicamente usando il costrutto di package (o altri meccanismi di modularità)

7 Diagramma delle Classi Diagramma delle Classi classe: una tipologia 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( ) prodotto 0..* prodotto 1..* 0..* Prestito produttore 1 scrittore 0..* 0..* Utente Editore ragione sociale nome breve indirizzo sede telefono variazione dati editore( ) Autore nome : type = initval cognome : type = initval anno nascita anno morte variazione anagrafica( ) variazione anagrafica( ) nomeclasse attributi operazioni gerarchia di specializzazione (superclassesottoclasse) Libro cod_libro titolo data edizione ISDN data acquisizione richiesta( ) restituzione( ) create( ) Libro prezioso valore : lire = 0 valorizza( ) 0..* 1..* 0..* Prestito associazione 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() classe associativa Uso del Diagramma delle Classi rappresenta le classi che compongono il sistema, ed i relativi attributi ed operazioni specifica, mediante le associazioni, i vincoli che legano tra loro le classi può essere definito in fasi diverse (analisi, progetto, implementazione) può rappresentare diverse tipologie di classi, chiamate stereotipate (tipo, interfaccia, implementazione) dovendo essere usate in molti contesti, le classi permettono di definire caratteristiche molto dettagliate per gli oggetti, molte delle quali sono mutuate direttamente dai linguaggi di programmazione OO: visibilità, classi astratte, classi parametriche tuttavia il diagramma delle classi ha una limitata validità concettuale che limita anche il supporto dato alla validazione Diagramma degli Oggetti Persona nome : char cognome : char impiego : boolean = false Azienda nome : char Persona Mario Rossi : Persona FIAT : Azienda Classe Oggetto link

8 Aggregazione e Composizione Aggregazione: rappresenta il legame fra un oggetto e le sue parti (che sono a loro volta degli oggetti componenti dell oggetto di partenza): l'insieme rappresentato da un oggetto e dalle sue componenti è spesso chiamato oggetto composto L'aggregazione può essere vista come una associazione speciale caratterizzata da proprietà semantiche addizionali:» proprietà transitiva: se A è parte di B e B è parte di C, allora A è parte di C» proprietà antisimmetrica: se A è parte di B, allora B non è parte di A Se un oggetto componente può essere parte di un solo oggetto composto si parla di composizione (è una forma forte di aggregazione) L'aggregazione/composizione può avere un numero arbitrario di livelli (albero di aggregazione) Computer Monitor System Box Mouse Tastiera 1 1..* Cabinet Ventola CPU RAM Auto-BMW 1 Motore * * Stile 1 1 colore selleria 1 composizione Auto-FIAT aggregazione Nella composizione le componenti vengono eliminate se è distrutto l oggetto composto N.B.: la propagazione della cancellazione può essere necessaria anche nel caso di una qualsiasi associazione di tipo 1..1; ad esempio: Dipartimenti cancellando un dipartimento devono essere cancellati tutti i suoi corsi 1 cancellando uno studente, verificare che i corsi a cui è iscritto abbiano ancora 10..* almeno 3 iscritti Corsi 0..* 3..* Studenti cancellando un corso, verificare che il dipartimento in cui è tenuto abbia ancora almeno 10 corsi, senza cancellare gli studenti (associazione opzionale) Generalizzazione Esprime il rapporto che lega una sottoclasse s alla sua superclasse S Tuttavia in UML esiste il problema del suo significato, che è molto (troppo) ampio, che potrebbe rendere difficile la sua realizzazione in un linguaggio di programmazione Sebbene strettamente correlate, l'ereditarietà e la generalizzazione sono due cose distinte: l'ereditarietà è solo un meccanismo sintattico Figure Geometriche la generalizzazione è un meccanismo concettuale Figure Piane Punto Linea Poligono Solido superficie volume Poliedro Concetti Comuni Note Le note sono un concetto aggiunto nella notazione UML Usate per inserire commenti, vincoli (se abbinate allo <stereotype> <<constraints>>) oppure codice di metodi Sono tipicamente abbinati all elemento(i) al quale si riferiscono attraverso una linea tratteggiata Esempi: Triangle + move (in dist : Point) + scale (in factor : Real) Autore: Mario Rossi Versione: 1.0 foreach v in vertices do v.x := v.x + dist.x; v.y := v.y + dist.y Persona padre nome cognome età figlio <<constraints>> Persona.età>Persona.figlio.età foreach v in vertices do v.x := factor * v.x; v.y := factor * v.y

9 Concetti Comuni Dipendenze Le dipendenze tra elementi di digrammi sono espresse generalmente con A B A dipende da B Sono spesso stereotipate (il loro significato è molto ampio) Ne esistono di pre-definite attraverso stereotipi Le dipendenze operano principalmente sulla sintassi La Vista Strutturale Package Un package è un contenitore utilizzabile per incapsulare classi, associazioni, operazioni, gerarchie, packages (e altro), tra cui esistono legami sulla base dei servizi forniti dal package stesso Ha un nome che permette di indicare il package come un unità e di completare il nome di ciascuno dei suoi elementi interni Idealmente un package ha un interfaccia minima e ben definita verso gli altri sottosistemi Controllo Elementi Grafici Editor Gestione della grafica Sisteme a finestre Esempi di relazioni tra package X Y Z B Y::C +C +Z::F +F Y::F «import» -D «import» -H A Y::E +E -Z::G +G X Y Z B +C «access» «access» A +E +G -D +F -H Tale vista comprende diversi tipi di diagrammi, diagrammi di sequenza, di collaborazione, di stato e di attività: consideriamo i primi due, detti anche diagrammi di interazione perché descrivono come gruppi di oggetti possono ovvero devono interagire ai fini dello svolgimento di una certa attività. Esempio: preparazione (fisica) di un ordine con più linee riguardanti ciascuna un articolo che può essere disponibile o deve essere riordinato. 1. Dalla finestra Inserisci Ordine si manda un messaggio di preparazione a un Ordine 2. L Ordine invia messaggi di preparazione a tutte le Linee d Ordine contenute nell Ordine ogni Linea d Ordine controlla il corrispondente Articolo 3. Se questo controllo ha esito positivo, la Linea d Ordine rimuove la quantità appropriata di Articolo dal magazzino e crea un prodotto pronto per la consegna 4. Se la disponibilità dell Articolo è scesa ad un determinato livello sotto il quale è opportuno ordinarne una nuova quantità, l oggetto Articolo genera una richiesta di ordinazione

10 Diagramma di sequenza Una finestra Inserisci Ordine 1: prepara () messaggio Un Ordine 1.1 * prepara () iterazione ( linea,...) Una Linea Ordine Articolo hadisponib := controllo () Ordine tra messaggi [hadisponib] remove () condizione (il messaggio è generato se...) oggetto linea di vita chiamata interna deveriordinare := deveriord () [deveriordinare] new Un Riordine di Articolo Notazione per Messaggi predecessor(s)/ guard-condition, sequence-expression return-value := message-name (argument-list) move (5, 7) : move (5, 7) 3.7 *[1..5] : move (5, 7) iteration [hadisponib] new creazione Un Prodotto da Consegnare thread of control 3.7 [ z > 0 ] : move (5, 7) condition A3, B4 / [ x < 0 ] C3.1 [ y < 0 ] : res := getlocation (fig) tempo/passi X attivazione linea di ritorno predecessors guard sequence number condition return value message name argument list cancellazione Tipi di Stimoli e Messaggi Esempi Simile alla chiamata di procedura anche annidata e sincrona Chiamata non annidata, tipicamente asincrona Chiamata asincrona Flusso Annidato teller : order : article getvalue price getname Flusso non Annidato caller exchange callee lift receiver dial tone dial digit dial digit routing ringing tone ringing signal lift receiver Flusso Asincrono appl err-handl alarm unknown alarm Ritorno di chiamata

11 Esempio, Iterazione e Branching branching iterazione calculator filter value [ x < 0] transform () iterate () [ x > 0] getvalue () getvalue () attivazioni muliple e indipendenti Diagramma di Sequenza In un Diagramma di Sequenza, una freccia rappresenta uno stimolo che da un oggetto viene inviato ad un altro I messaggi e gli stimoli corrispondono alle richieste di servizi che gli oggetti si scambiano I messaggi costituiscono la specifica degli stimoli ovvero gli stimoli sono istanze dei messaggi I servizi sono implementati da metodi e operazioni delle classi Analizzando i Diagrammi di Sequenza è possibile capire quale interfaccia l oggetto ovvero la sua classe dovrebbe fornire verso l esterno» quindi, dai Diagrammi di Sequenza si evincono le operazioni e i metodi delle classi» permettono una maggiore formalizzazione dei casi d uso Uso del Diagramma di Sequenza Un diagramma di sequenza potrebbe rappresentare un utilizzo particolare degli oggetti ovvero potrebbe essere un raffinamento di uno use-case Anche i diagrammi di sequenza possono essere visti a più livelli di astrazione; un raffinamento di un diagramma di sequenza dovrebbe introdurre nuovi oggetti che permettano di gestire meglio l aspetto comportamentale Analizzando i diagrammi di sequenza è possibile: capire quale interfaccia l oggetto ovvero la sua classe dovrebbe fornire verso l esterno definire i meccanismi di controllo che permettono la realizzazione del diagramma Diagramma di Collaborazione L interazione degli oggetti coinvolti in ogni evento ed i link tra gli stessi costituisce un Diagramma di Collaborazione ai livello di istanza Esempio: Utente 1: chiede campo 3: comunica giorno ora 7: conferma 9: paga 14: consegna ricevuta 8: saldo 6: chiede conferma 2: chiede info campo 13: stacca prenotazione 4: seleziona prenotazione 10: scrive prenotazione Registro Prenotazione Impiegato Ricevuta 11: conferma prenotazione 5: comunica info 12: scrive prenotazione

12 Diagramma di Collaborazione In un Diagramma di Collaborazione, un rettangolo rappresenta un oggetto o la classe a cui appartiene, le linee fra i rettangoli rappresentano rispettivamente link o associazioni; i messaggi sono seguiti da una freccia che ne indica la direzione I Diagrammi di Collaborazione indicano una visione alternativa ai Diagrammi di Sequenza I Diagrammi di Collaborazione possono essere sia a livello di specifica che a livello di istanza:» a livello di specifica permettono di capire le associazioni che vengono usate nello scambio di messaggi» a livello di istanza mostrano lo scambio di messaggi tra gli oggetti attraverso i link, entrambi eventualmente creati attraverso messaggi Analizzando i Diagrammi di Collaborazione è possibile capire lo scambio di messaggi tra le singole classi attraverso le associazioni Esempio di Sincronizzazione tra Messaggi A2,B2/2: completed (job) : Factory-Scheduler : Factory-JobManager B1/B2 : completed(r-job) 1/B1 : start(r-job) 1: start(job) : Robot : Oven A1/A2 : completed(o-job) 1/A1 : start(o-job) Diagramma di collaborazione (a livello di istanza) Un diagramma di collaborazione mostra: Una finestra Inserisci Ordine Un Ordine Una Linea Ordine Un Prodotto{new} da Consegnare 1 prepara () 2 * prepara () 3 hadisponib := controllo () 4 [hadisponib] remove () 7 [hadisponib] new messaggio oggetto come sono connessi staticamente gli oggetti come sono correlati gli oggetti mediante i messaggi la sequenza dei messaggi, data dalla loro numerazione un altra rappresentazione del diagramma di sequenza delega interna Articolo Un Riordine{new} di Articolo 5 deveriordinare := deveriord () 6 [deveriordinare] new numero di sequenza Diagrammi di Stato (Statechart) Un diagramma di stato collega eventi e stati Quando un evento (istanza o occorrenza) è ricevuto da un oggetto in un certo stato, l oggetto entra in uno stato dipendente sia dall'evento (istanza) che dallo stato di origine Un arco tra due stati viene etichettato con una classe di evento ed è detto transizione Nella sua forma più semplice, un diagramma degli stati è un grafo i cui nodi sono gli stati e i cui archi diretti sono le transizioni

13 Uso dei Diagrammi di Stato In principio, per rappresentare ogni sistema (reattivo) il cui comportamento sia guidato da eventi discreti In pratica, per rappresentare il comportamento di ogni oggetto istanza di una classe un maggior grado di dettaglio delle interazioni tra oggetti (attivi) Stati Lo stato corrisponde ad un intervallo tra due eventi ricevuti da un oggetto ovvero ad una condizione Gli eventi rappresentano dei punti nell'asse temporale, gli stati rappresentano intervalli Lo stato di un oggetto è determinato dai valori dei suoi attributi Per esempio: "l'acqua è liquida" significa dire che il valore dell'attributo temperatura è tra 0 e 100 Un oggetto che si trova in uno stato soddisfa delle condizioni, attende il verificarsi di eventi, ed, eventualmente, esegue delle operazioni NAME Action label / action expression UML-defined Action label is entry, exit, do Eventi interazioni: invocazione di operazioni di oggetti (evento di chiamata) segnale asincrono (segnale) eventi temporali termine di un intervallo temporale raggiunta una misura temporale modifica del valore di attributi di oggetti Istanza (occorrenza) di un evento si verifica in un particolare istante temporale (passo di computazione) e non ha durata Eventi e Classi E utile vedere gli eventi come classi di istanze di evento Per esempio, il volo 123 parte da Chicago e il volo 456 parte da Roma sono istanze della classe Airplane Flight Departs; questa classe può avere come attributi: airline, flight-number, city, time Anche tali classi possono essere organizzate in gerarchie di generalizzazione I valori degli attributi di una classe rappresentante un evento costituiscono le informazioni trasmesse da un istanza di evento Pressione Mouse Dx Pressione Mouse Pressione Mouse Sx

14 Esempio di diagramma di stato compitazione numero del numero altro numero fine del numero riattacca attesa risposta risponde conversazione riattacca riattacca finisce il tono riattacca exit digita un numero entry alza il ricevitore inizia il tono riattacca Il Comportamento di Transizioni Semplici Sono relazioni tra due stati Ogni transizione è etichettata con una stringa della forma evento (parametri) guardia / operazioni I parametri rappresentano gli attributi della classe evento La guardia è una condizione che può contenere anche proprietà del tipo (in S), not (in S)) che permettono di sincronizzare stati concorrenti Il comportamento di una transizione è il seguente: se un istanza della classe evento si verifica, si valuta la guardia: se la guardia è vera, si eseguono tutte le operazioni e si modifica lo stato e in questo caso di dice che la transizione spara altrimenti, lo stato non si modifica e le operazioni non vengono eseguite la semantica è run to completion ovvero o la transizione è eseguita interamente o non è eseguita per niente Non determinismo in Statechart Esempio con Condizioni Tipo di Non Determinismo Causa Soluzione Possibile Rilevabile Staticamente Eventi Uguali e medesima istanza (stesso stato) Introdurre Guardie Esclusive Non Rilevabile Staticamente Eventi Distinti con istanze al medesimo istante/passo (stesso stato) Impedire istanze di eventi al medesimo tempo (già adottata in UML) fine del tempo Nord-Sud possono andare dritti fine del tempo [macchine nelle corsie sx N-S] fine del tempo [corsie sx N-S vuote] Nord-Sud possono girare a sinistra fine del tempo fine del tempo [corsie sx E-O vuote] Sebbene non sempre sia necessario risolvere il non-determinismo Est-Ovest possono girare a sinistra fine del tempo [macchine nelle corsie sx E-O] Est-Ovest possono andare dritti

15 Esempio di Azioni Esempio di generalizzazione di stati Folle pressione di R pressione di N Retromarcia In attesa pressione pulsante dx / visual. menu pressione pulsante sx / cancella.menu Menu visibile entry pressione di F pressione di N Avanti incrementa trascinamento / evidenzia la voce del menu entry Prima scala Seconda incrementa scala Terza Tipologie di Stato Composto Stati Concorrenti/Aggregati Stati Specializzati/Componenti (region) S1 Transizioni di ingresso e d uscita da uno stato aggregato barra fork Conto Corrente Nessuna Stringa: eventualmente, si una una stringa unica associata alla barra S1 S2 S2 Passivo Attivo Bloccato Normale barra join

16 Priorità della transizioni annidate Evento Storie profonde (deep) e superficiali (shallow) permettono di rappresentare il ritorno ad uno stato (interno a un superstato) precedentemente visitato Evento sospendi/ Diagnostica1 Diagnosi Diagnostica2 Step11 Step21 riprendi/ H* Step12 Step22 La transizione più interna è prioritaria se entrambe possono sparare Storia Profonda Stato di Default Interazione di Diagrammi di Stato Generalmente esiste un diagramma di stato per ogni classe avente comportamento dinamico rilevante La sincronizzazione di più diagrammi può avvenire in due maniere: tramite le condizioni tramite eventi tramite variabili condivise Nel primo caso si mette un predicato sullo stato di un altra classe nella condizione Nel secondo caso alcuni diagrammi generano eventi a cui altri diagrammi devono (possono) reagire Esempio interazione di diagrammi di stato Off Telecomando Controllo TV Videoregistratore click-on-vcr-control(power) / click click-on-vcr-control(power) / click Press-Power / click-on-tv-control(power) Televisione click-on-tv-control(power) / click Off click-on-tv-control(power) / click On Press-Power / click-on-vcr-control(power) VCR TV Controllo VCR On

17 La Biblioteca e il Libro La Biblioteca e il Libro Prenotato(Date) [Date<=Today+2 and Date>Today] / Prenotato Prestato(Date) / [Date<=Today+2 and Date>Today] / Prenotare(Date) Prenotato / Prestare(Date) Disdetto() / / Disdire() After(2 giorni) / After(2 giorni) / Disponibile Prestato(Date) / In Prestito Disponibile / Prestare(Date) In Prestito Riportato(Date) / / Riportare(Date) Riportato(Date) / Perduto When(Today>Limit) / / Riportare(Date) Perduto When(Today>Limit) / La Biblioteca e il Libro Riportato(Date) / Prenotato Prenotato(Date) / Prestato(Date) / Disdetto() / Libero Prenotato When(Today>Limit) / In Prestito Generazione del codice (sequenziale) delle operazioni per gli oggetti (di controllo) Messaggio / Operazione Messaggio / Operazione; Messaggio1 Private. STATE Private Operazione( ); Public Messaggio( ); Operazione( ); If (STATE= = S1) Messaggio1( ); ;... Libero When(Today>Limit) / Messaggio / Messaggio1 Private. STATE Public Messaggio( ); After(2 giorni) / Prenotato Riportato(Date) /... If (STATE= = S1) Perduto... Messaggio1( ); ;

18 Generazione del codice (sequenziale) per gli oggetti (dato) Private. STATE Public Operazione( );... If (STATE= = S1) STATE=S2; ;... Diagramma di Attività Cliente Vendita Magazzino Richiesta Paga Ordine [Inviato] Inserire Ordine Ordine [Gestito] Ordine [Registrato] Gestire Ordine Messaggio / Operazione Private. STATE Private Operazione( ); Public Messaggio ( ); Ordine [Evaso] Invia Merce... If (STATE= = S1) Operazione( );... Raccogli Ordini Non tutti i diagrammi di attività hanno senso ma non essendo formalmente definiti, non è possibile costruire algoritmi per decidere se un diagramma ha senso o meno Esempio Elementi Metodologici Analisi del Dominio L obiettivo è di arrivare alla definizione sufficientemente rigorosa dei requisiti di sistema In genere, si analizzano prima gli aspetti più astratti del dominio poiché errori nelle astrazioni si propagano nelle soluzioni più concrete Ogni modello può essere rappresentare un certo livello di dettaglio al fine di permettere le necessarie analisi partendo da un livello più astratto, e, successivamente, andando verso un livello più concreto Si costruiscono modelli per gli aspetti funzionale (diagrammi di attività, casi d uso, diagrammi di sequenza e di collaborazione) statico ovvero strutturale (diagramma delle classi e degli oggetti) dinamico per classi di oggetti (Statechart)

19 Analisi del Dominio L obiettivo è di rappresentare, valutare, sviluppare i requisiti di sistema in un determinato contesto La rappresentazione e la valutazione dei requisiti possono essere più o meno formali a seconda dei fattori di successo Le strade da seguire sono principalmente due, ben distinte: migliorare o modificare situazioni esistenti sviluppare nuove soluzioni Analisi del Dominio Fasi Metodologiche Concettualizzazione Analisi degli Oggetti Analisi della Dinamica Relazioni tra Fasi Metologiche Normalmente gli aspetti temporali sono i più difficili da modellare Di conseguenza è spesso preferibile esaminare inizialmente gli aspetti statici di un sistema (cioè la struttura degli oggetti e le associazioni tra di essi) Successivamente si analizza l'evoluzione temporale di oggetti e associazioni Gli aspetti di un sistema che riguardano il tempo e l evoluzione costituiscono il modello della dinamica del sistema Analisi del Dominio Concettualizzazione Studio del dominio del problema per delimitarne nitidamente i contorni ed evidenziarne le realtà di interesse (Requisiti del Contesto) Stesura, in linguaggio naturale, delle specifiche di dominio: Problem Statement

20 Analisi del Dominio Regole empiriche per la stesura di un Problem Statement corretto la sua formulazione deve stabilire cosa deve essere fatto e non come (specifica delle esigenze, non una soluzione proposta) brevità del documento buona capacità di astrazione evitare, per quanto possibile, le ambiguità considerare il fatto che è attraverso i diagrammi UML che i requisiti dovrebbero essere sviluppati Analisi degli Oggetti Fasi Identificazione delle classi Definizione di un Dizionario Dati Identificazione delle associazioni Identificazione degli attributi Ereditarietà Iterazione del procedimento Analisi degli Oggetti Definizione di un Dizionario Dati Le parole possono essere soggette ad interpretazioni differenti per cui è necessario compilare un dizionario dati per tutte le classi rilevate nella fase precedente Si specifica una definizione che descriva precisamente ogni classe di oggetti nel contesto del problema corrente È la base di partenza per il processo iterativo caratteristico della metodologia associata a UML Analisi degli Oggetti Identificazione delle classi Elencare le classi candidate a partire dal Problem Statement evidenziando tutti i sostantivi che ne fanno parte Evitare costrutti tipici dell implementazione (a meno che il Problem Statement non sia prettamente informatico) Eliminare le classi scorrette

21 Analisi degli Oggetti Criteri di eliminazione delle classi classi ridondanti: due classi esprimono la stessa informazione (es: cliente ed utente) classi irrilevanti: classi che sono marginali all interno del Problem Statement classi vaghe attributi: i nomi che descrivono oggetti essenzialmente singoli dovrebbero essere riformulati come attributi (es: età di una persona) operazioni: se un nome descrive un operazione applicata ad oggetti e non viene esso stesso manipolato (es: telefonata) ruoli: il nome di una classe dovrebbe riflettere la sua reale natura e non il ruolo che ricopre in un associazione (es: marito) Analisi degli Oggetti Identificazione delle associazioni tra le classi Estrarre tutti i verbi candidati dalla formulazione del Problem Statement o del Dizionario dei Dati Qualunque dipendenza verbale tra due o più classi è un associazione Un riferimento da una classe all altra è un associazione Eliminare le associazioni scorrette Analisi degli Oggetti Criteri di eliminazione delle associazioni associazioni tra classi eliminate: se una delle classi dell associazione è stata eliminata, l associazione deve essere eliminata o riformulata associazioni irrilevanti: associazioni estranee al dominio del problema o che considerano costrutti relativi all implementazione azioni: un associazione deve descrivere proprietà strutturali del dominio del problema e non un evento passeggero associazioni derivate: tralasciare le associazioni che possono essere definite in termini di altre associazioni (non sempre) associazioni con nomi erronei: non dire come o perché una situazione accade, ma cosa è Analisi degli Oggetti Associazioni: suggerimenti pratici nomi di ruoli: aggiungere i nomi di ruolo dove occorre; i nomi di ruolo descrivono il ruolo che la classe ricopre nell associazione dal punto di vista dell altra classe molteplicità: specificare la molteplicità e verificare la molteplicità uno

22 Analisi degli Oggetti Identificazione degli attributi Gli attributi sono proprietà di singoli oggetti (es: età, nome, colore, peso...) Gli attributi, generalmente, corrispondono a sostantivi seguiti dal complemento di specificazione (es: il colore dell auto) Se un attributo descrive uno stato interno di un oggetto che è invisibile all esterno, eliminare l attributo dal modello Non introdurre attributi fittizi per l identificazione degli oggetti perché già impliciti Analisi degli Oggetti Ereditarietà Organizzare le classi usando l'ereditarietà per condividere le proprietà comuni L'ereditarietà può essere raggiunta in due modi: generalizzando aspetti comuni di classi esistenti in una superclasse specializzando classi esistenti in sottoclassi Analisi degli Oggetti Procedimento iterativo L Analisi degli Oggetti è costituita da continue iterazioni successive Il dizionario dati ne è parte integrante poiché punto di partenza delle iterazioni Analisi degli Oggetti Risultato dell Analisi degli Oggetti Un diagramma delle classi (oggetti) che dovrebbe rappresentare gli oggetti del dominio (senza riferimento ad aspetti implementativi) Alcune classi (oggetti) potrebbe contenere solo alcuni elementi Alcuni oggetti necessari per il controllo dell applicazione potrebbero non essere parte di tale diagramma (interfacce) Alcuni oggetti di controllo potrebbero quindi essere introdotti come risultato dell Analisi Dinamica (atomicità su più oggetti)

23 Analisi Dinamica Rappresentazione delle interazioni del Sistema, da e verso l esterno, mediante Diagrammi dei Casi d Uso (ma anche con diagrammi di attività) Eventualmente, rappresentazione delle precedenti interazioni con Diagrammi di Sequenza o di Collaborazione Rappresentazione delle interazioni interne al Sistema mediante Diagrammi di Sequenza oppure Diagrammi di Collaborazione (Trasformazione di Casi d Uso) Rappresentazione della dinamica dei singoli oggetti, istanze di una classe, mediante Diagrammi Statechart Tra le varie tipologie di diagrammi è possibile introdurre una relazione di astrazione rispetto alla rappresentazione di una medesima situazione per cui: i casi d uso sono più astratti dei diagrammi di interazione i diagrammi di interazione sono più astratti di statechart Mentre il diagramma delle classi è unico (sebbene al suo interno sia possibile usare il concetto di classe in modo differente), l analisi dinamica sfrutta varie tipologie di diagrammi; la scelta di quali usare dipende da: grado di conoscenza della dinamica tipologia della dinamica fattori di successo Analisi Dinamica Risultato dell Analisi Dinamica Il modello dinamico globale prodotto consiste principalmente di più diagrammi di stato: uno per ogni classe con un comportamento dinamico rilevante Infatti, attraverso i diagrammi statechart, i diagrammi di interazione e i casi d uso sono rappresentati ad un maggior livello di dettaglio Se, però, gli oggetti applicativi sono più legati all implementazione, è possibile rimandare l introduzione di statechart alla fase di progetto I diagrammi di stato delle varie classi possono essere combinati in un singolo modello dinamico nel quale gli eventi vengono condivisi E possibile avere nel prodotto finale il diagramma delle attività Analisi Dinamica Trasformazione di Casi d Uso in Diagrammi di Interazione Considerare sempre l interazione più lunga : è la più significativa» uno scenario del tipo l utente arriva, cambia idea e se ne va non è molto significativo, anche se corrisponde ad un caso d uso reale» solitamente l interazione più lunga è quella in cui va tutto bene, non ci sono cioè né ripensamenti né eccezioni Fare in modo che un solo oggetto gestisca il controllo di un caso d uso» with a little help from my friends, per ogni caso d uso c è un oggetto che sa come lo si gestisce, gli altri oggetti fanno da supporto a tale gestione» tale accorgimento aumenta notevolmente la riusabilità degli oggetti e favorisce la realizzazione di architetture client-server Analisi Dinamica Costruzione di Statechart Costruire un diagramma di stato solo per classi con comportamento dinamico rilevante sebbene la rilevanza dinamica non sia oggettiva si potrebbero considerare solo classi di oggetti passivi, demandando al progetto una specifica dettagliata del controllo applicativo Usare sia Casi d Uso che Diagrammi di Sequenza come base per la definizione dei diagrammi di stato La distinzione tra azione e attività è basata sulla specifica applicazione Usare stati annidati quando la stessa transizione si applica a più stati ovvero quando uno stesso comportamento si ripete più volte Definire il diagramma di stato di una sottoclasse in maniera indipendente da quello della(e) superclasse(i)

24 Consistenza Diagrammi Classi(Oggetti)/Interazione Le classi utilizzate nei diagrammi di interazione devono essere definite nel diagramma delle classi I messaggi devono essere definiti come operazioni nel diagramma delle classi Consistenza Statechart/Diagrammi di Interazione Un diagramma di sequenza rappresenta, in generale, un interazione degli oggetti applicativi (o di controllo) Lo statechart di un oggetto applicativo deve realizzare le sequenze di messaggi indicate nei diagrammi di sequenza per quel oggetto Lo statechart di un oggetto passivo deve permettere le sequenze di messaggi indicate nei diagrammi di sequenza Consistenza di Statechart Gli oggetti passivi (o dato ) hanno statechart privo di messaggi verso altri statechart Lo statechart di un oggetto passivo deve rappresentare tutti i comportamenti possibili di detto oggetto indipendentemente dalle applicazioni Un oggetto di controllo potrebbe essere un rappresentante di un oggetto passivo Analisi Dinamica Quantitativa Se esiste la necessità di analisi quantitative, i diagrammi UML devono essere ulteriormente trasformati in notazioni più formali che permettano di svolgere tali analisi (automaticamente) Tali trasformazioni non sono sempre evidenti e necessitano di nuova informazione ovvero della formulazione di ipotesi

25 Progettazione Object-Oriented Transizione dall insieme di modelli sviluppati nell analisi del dominio in un insieme modelli che tiene conto dell architettura di riferimento, dell ambiente software che accoglierà l applicazione Per effettuare la transizione esistono vari modi tra cui (object) design patterns euristiche Progettazione Object-Oriented La notazione UML può essere usata anche in fase di progettazione sebbene necessità specifiche possano richiedere l impiego di notazioni non-uml La transizione dai diagrammi di analisi può essere molto complessa: nel caso più semplice si raffinano i diagrammi statechart e di classe introdotti nell analisi del dominio In ogni caso, dovrebbe essere garantita la tracciabilità ovvero il legame tra i diagrammi della fase precedente e gli attuali Architettura rappresentata con Package Letteratura Michael Blaha, William Premerlani: Object-Oriented Modeling and Design for Database Applications, Prentice Hall, ISBN Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, ISBN John Cheesman, John Daniels: UML Components: A Simple Process for Specifying Component-Based Software, Addison-Wesley, ISBN Bruce Powel Douglass: Real-time UML: Developing Efficient Objects for Embedded Systems, Addison-Wesley, ISBN UI Oggetti del Dominio Memorizzazione Utilità Desmond D'Souza, Alan Wills: Objects, Components and Frameworks With UML: The Catalysis Approach, Addison-Wesley, ISBN

26 Letteratura Brian Henderson-Sellers, Bhuvan Unhelkar: OPEN Modeling with UML, Addison- Wesley, ISBN Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process, Addison-Wesley, ISBN Craig Larman: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, Prentice Hall, ISBN Pierre-Alain Muller: Instant UML, Wrox Press, ISBN James Rumbaugh, Ivar Jacobson, Grady Booch: The Unified Modeling Language Reference Manual, Addison-Wesley, ISBN X. Perdita Stevens, Rob Pooley: Using UML: software engineering with objects and components, Addison-Wesley, Object Technology Series, Updated edition for UML1.3: first published 1998 (as Pooley and Stevens), ISBN Conclusioni UML è quindi una notazione ricca che può essere usata in tutte le attività di sviluppo del software poiché raccoglie molte delle notazioni usate nel passato La ricchezza notazionale implica che UML debba necessariamente essere usato attraverso una ben definita metodologia (più che in passato), infatti: esiste il rischio di associare impropriamente i diagrammi esiste il problema della consistenza tra modelli Permangono però il problema del significato della notazione il problema della metodologia La notazione è in continua evoluzione e non esiste garanzia di compatibilità