UML. Unified Modeling Language (UML) Breve storia dell UML. Perchè usare la progettazione visuale? Ken Jacobs, Oracle Vice-president:

Transcript

1 UML Unified Modeling Language (UML) Lo standard emergente nella progettazione del software (e non solo) Perchè usare la progettazione visuale? Perchè usare la progettazione visuale? Ken Jacobs, Oracle Vice-president: Le definizioni dei dati per i database ad oggetti sono di difficile comprensione se si esamina la loro espressione testuale. Con una rappresentazione grafica si possono, invece, facilmente capire le relazioni tra essi ed il resto del DB. Mary Loomis, HP - Software Technology Laboratory: la progettazione visuale e le tecniche di rappresentazione visuale ( ) permettono di rappresentare le specifiche in un modo comprensibile sia per le persone che per i tool di sviluppo Perchè usare la progettazione visuale? John Roskill, Microsoft - Director of Product Marketing for Microsoft Visual Studio: Breve storia dell UML Noi riteniamo la progettazione visuale molto importante nello sviluppo delle applicazioni di livello enterprise basate su componenti ( ) perché permette di gestire la complessità dell applicazione.

2 La storia dell UML Nov 97 UML viene approvato dall OMG Cosa è l UML Cosa è l UML Struttura dell UML Obiettivi dell UML Che cos è l UML? UML è l acronimo di Unified Modeling Language È un linguaggio visuale per la specifica, la costruzione e la documentazione di sistemi software complessi UML: Unified Modeling Language Un linguaggio "standard" (accettato dall'omg) per la modellazione di sistemi software UML deriva dalla "integrazione" di modelli preesistenti (proposti nel contesto di metodologie): Booch et al. OMT (Rambaugh et al.) OOSE (Jacobson et al.) Gli autori di UML sono Booch, Rumbaugh e Jacobson UML: principi ispiratori Modellazione (allo scopo di produrre software migliore) La modellazione è essenziale in ogni attività ingegneristica complessa, in quanto permette di astrarre e semplificare costruiamo modelli per comprendere meglio i sistemi che stiamo sviluppando [Booch et al: The UML User Guide] costruiamo modelli disistemi complessi altrimenti non potremmo comprendere tali sistemi nella loro interezza Finalità della modellazione Visualizzazione del sistema (così com'è o come lo si vorrebbe) in quanto unafiguravale più dimille parole Specifica della struttura e del comportamento di un sistema in manieraprecisa, completa e senza ambiguità Definizione delle linee guida per la costruzione di un sistema forward engineering reverse engineering Documentazione delle decisioni prese UML è stato pensato per supportare tutto questo

3 UML, questioni generali I diagrammi di UML Diagrammi e viste i diagrammi sono una rappresentazione dei vari aspetti dell applicazione ogni diagramma descrive una vista della applicazione secondo una certa prospettiva Abbellimenti (adornments): per ogni costrutto esiste una notazione grafica base, cui possono essere aggiunti dettagli e note Distinzioni di base: classe-oggetto (schema-istanza); notazione: classe oggetto:classe :classe oggetto interfaccia-implementazione Use Case Use Case Sequence Scenario Scenario Collaboration Scenario Scenario Statechart Use Case Use Case Use Case Models Activity State State Class Component Component Deployment State State Object State State Component I diagrammi di UML (9 tipi diversi) Diagramma delle classi (Class) Diagramma degli oggetti (Object) Diagramma dei casi di uso (Use case) Diagrammi di interazione (Interaction) Diagramma disequenza(sequence) Diagramma dicollaborazione (Collaboration) Diagramma delle attività (Activity) Diagramma degli stati (Statechart) Diagramma dei componenti (Component) Diagramma della distribuzione dei componenti (Deployment) Obiettivi dell UML 1) Fornire all utente un linguaggio di specifica espressivo, visuale e pronto all uso 2) Offrire meccanismi di estensibilità e specializzazione del linguaggio 3) Essere indipendente dagli specifici linguaggi di programmazione e dai processi di sviluppo 4) Incoraggiare la crescita dei tool OO commerciali 5) Supportare concetti di sviluppo ad alto livello come frameworks, pattern ed i componenti 6) Integrare i migliori approcci. Cosa non è l UML Non è un linguaggio di programmazione visuale (è un linguaggio di specifica visuale) Parti di UML UML non è un modello per la definizione di interfacce UML non è dipendente dal paradigma di sviluppo nel quale può essere utilizzato

4 UML UML può essere suddiviso in due grandi parti: Diagrammi strutturali Diagrammi comportamentali Diagrammi strutturali Diagrammi di classe: Descrivono le classi di oggetti che compongono il sistema, ossia gli aspetti che accomunano diversi oggetti nella loro struttura e nel loro comportamento Diagrammi di implementazione: Illustrano le interazioni nel sistema organizzandole attorno agli oggetti e ai legami tra gli oggetti Diagrammi comportamentali Diagrammi di attività: Forniscono la sequenza di operazioni elementari che definiscono un attività più complessa Diagrammi comportamentali Use case diagrams Specificano il comportamento del sistema, ossia come il sistema agisce e reagisce dal punto di vista degli attori (possibili figure di utenti del sistema) Sequence diagrams Forniscono una rappresentazione dei vari scenari che possono verificarsi nel ciclo di vita del sistema orientata a visualizzare in sequenza le interazioni tra gli oggetti del sistema. Quando due oggetti interagiscono? E cosa trasmettono l uno all altro? Diagrammi comportamentali Collaboration diagrams Illustrano le interazioni nel sistema organizzandole attorno agli oggetti e ai legami tra gli oggetti (come i Sequence descrivono i possibili scenari, ma da un diverso punto di vista) Diagrammi comportamentali Component diagrams Rappresentano come i moduli software del sistema (le componenti) sono organizzati e quali sono le loro dipendenze Statechart diagrams (diagrammi di stato) Descrivono il "ciclo di vita" degli oggetti del sistema, visualizzando in che modo essi vengono modificati da eventi che possono occorrere nella processo di funzionamento del sistema Deployment diagrams (diagrammi di allocazione) Illustrano la dislocazione al run-time dei nodi elaborativi, delle componenti, dei processi e degli oggetti che risiedono presso di essi.

5 Diagramma dei casi d uso Use Cases Diagram Ci sono modi diversi di guardare a un SISTEMA. "aprirlo" e guardarci dentro, per vedere come è strutturato all'interno ( punto di vista del progettista) guardare a come può essere utilizzato. In questo caso il sistema viene visto come una "black box", sigillata, ed è possibile osservarne solo i comportamenti dall'esterno ( punto di vista dell'utilizzatore, e di tutto ciò che interagisce con il sistema nell'ambito del suo funzionamento). Questo secondo punto di vista corrisponde al modello dei casi d'uso. Casi d uso Il termine "use case" è stato coniato dal metodologo svedese Ivar Jacobson. I casi d'uso sono semplicemente i modi in cui il sistema può essere utilizzato. Casi d uso I casi d'uso svolgono un duplice ruolo nello sviluppo di un sistema. nelle fasi iniziali della progettazione, servono per chiarire cosa dovrà fare il sistema. guidano l'intero progetto di sviluppo. Caso d uso Un caso d uso rappresenta un interazione tra un utente ed il sistema: cattura le funzionalità del sistema da realizzare così come esse sono percepite dall utente. Registra voti I casi d uso sono le azioni che un utente intraprende in un sistema Un sistema è qualcosa che svolge una funzione Modellare la realtà Secondo UML, modellare la realtà d interesse significa: individuare tutti i possibili casi d uso del sistema individuare tutti gli utenti dei singoli casi d uso (attori) rappresentare le interazioni tra casi d uso e utenti

6 Attore cosa è? Qualcuno o qualcosa, esterno al sistema, che interagisce con i casi d uso. Ogni attore corrisponde ad un insieme coerente di ruoli che i soggetti esterni possono assumere interagendo con il sistema. Attore cosa è? Gli attori comunicano con il sistema inviando o ricevendo messaggi: forniscono lo stimolo trigger agli use case; ciò equivale a dire che ogni caso d uso deve essere avviato da una esplicita richiesta di un attore Individuazione Attore Primari (o attivi): avviano le funzionalità proprie del sistema, forniscono uno stimolo al sistema Secondari: fruiscono di informazioni o notifiche generate da use case eseguiti da altri attori, ricevono messaggi e non forniscono un vero e proprio stimolo Individuazione Attore Primari (o attivi): avviano le funzionalità proprie del sistema, forniscono uno stimolo al sistema Secondari: fruiscono di informazioni o notifiche generate da use case eseguiti da altri attori, ricevono messaggi e non forniscono un vero e proprio stimolo Sistema E' l'entità i cui utilizzi vengono descritti dall'insieme dei casi d'uso. Un insieme completo di casi d'uso descrive in modo completo gli utilizzi del sistema dall'esterno, ossia dal punto di vista degli attori che interagiscono con esso, senza rivelare la struttura interna del sistema Sistema Un confine ideale separa ciò che è interno al sistema da ciò che ne è al di fuori. i casi d'uso rientrano all'interno del contesto del sistema, mentre tutti gli attori sono esterni al sistema.

7 Confini del Sistema Il primo passo nella realizzazione dei modelli dei casi d uso consiste nello stabilire con precisione il confine del sistema. La definizione del contesto del sistema è una delle attività più delicate di un progetto, APPROCCIO ITERATIVO INCREMENTALE Una buona idea consiste nell individuare il core del nuovo sistema (le funzionalità indispensabili). Attori e casi d uso Ogni caso d'uso è collegato agli attori, uno o più, che partecipano al caso d'uso stesso mediante una associazione, che ha il significato di "comunicazione" (rappresentata da una linea continua che collega attore e caso d'uso). comunicazione bi-direzionale La comunicazione tra attori e casi d'uso, nei due sensi, avviene tramite segnali, ed è pertanto da considerarsi asincrona. Attori e casi d uso L'associazione può essere orientata (ed essere quindi rappresentata con una freccia), per evidenziare la direzione delle comunicazioni nell'interazione (si tratta di una estensione definita nel profilo UML relativo al Software Development Process). comunicazione unidirezionale Associazioni tra attori L'unica associazione ammessa tra attori è la specializzazione o generalizzazione. L'attore specializzato eredita il comportamento del genitore e loestendein qualche maniera L'attore specializzato eredita la partecipazione a tutti i casi d'uso con i quali comunica l'attore generico, ma può partecipare ad ulteriori casi d'uso ai quali l'attore generico non è collegato. La relazione di specializzazione, in UML, è espressa graficamente con una linea continua, e con una punta di freccia triangolare e bianca. Generalizzazione Un attore che ne specializza un altro può sempre essere utilizzato al posto di quello esteso (genitore o padre) Cattiva organizzazione gerarchica attori

8 Diagramma ristrutturato Esempio organizzazione gerarchica attori in un sistema Associazioni tra casi d uso Ogni caso d'uso descrive un utilizzo completo del sistema, e non è quindi ammessa in UML la possibilità che casi d'uso distinti abbiano tra loro un'associazione di comunicazione. Associazioni tra casi d uso Le associazioni ammesse sono tre: Generalizzazione/Specializzazione extend include L'effetto globale dell'utilizzo delle associazioni tra casi d'uso è comunque quello di una frammentazione del singolo caso d'uso, anche se basata sull'"emersione" di particolarità (specializzazione ed extend) o di comportamenti comuni (include). Generalizzazione/Specializzazione Associa un caso d'uso di tipo generale ad uno o più casi d'uso specializzati. Generalizzazione/Specializzazione Ogni caso d'uso generale può avere più figli (casi d'uso specializzati). Ogni caso d'uso può avere più padri, cioè specializzare diversi casi d'uso generali. L esecuzione di use case fratelli può avvenire solo in alternativa

9 Esempio Generalizzazione/Specializzazione Il diagramma indica la proiezione statica delle funzionalità: specifica che il caricamento di un ordine richiede la validazione dell utente e la verifica dell ordine stesso. Il diagramma non specifica nulla circa la dinamica dell operazione Diagramma degli eventi Codice cap 3 pag 41. Generalizzazione/Specializzazione Il comportamento specifico di un caso d uso figlio può essere indicato inserendo opportune sezioni o sovrascrivendone altre nella sequenza di azioni ereditate dallo use case genitore (in modo del tutto analogo a quanto succede con i metodi nelle classi) Quando il caso d uso geneitore è astratto lo use case ereditante deve provvedere, Include Casi d'uso diversi possono avere in comune una sequenza di passi da svolgere. In questo caso è possibile enucleare la sequenza comune, e definirla come un caso d'uso a sé stante, da "includere" nei casi d'uso originari. Così facendo si evidenziano le parti comuni, e si evitano le ripetizioni nelle descrizioni dei casi d uso.

10 Include In termini di sequenza di azioni, che ciascun caso d uso esegue per erogare il servizio, la relazione di Include comporta l esecuzione della sequenza di azioni dello use case incluso sotto il controllo e nella locazione specificata nello use case base. Use case che include <<include>> Use case incluso Include Ogni caso d'uso può includere un numero illimitato di altri casi d'uso. Viceversa, ogni caso d'uso può essere incluso in un numero illimitato di altri casi d'uso. L'associazione di inclusione è rappresentata da una dipendenza (linea tratteggiata, punta della freccia aperta) con lo stereotipo <<include>>, la cui direzione va dal caso d'uso "includente" al caso d'uso "incluso". Esempio Include Il concetto di inclusione è per molti versi analogo a quello di invocazione di una funzione: viene eseguita la sequenza di azioni dello use case base quando viene raggiunto un punto di inclusione il controllo viene passato al caso d uso ivi indicato (incluso) e ne viene eseguita completamente la sequenza di azioni, quindi il controllo ritorna allo usecase base. Esempio Extend L'associazione "extend" permette di definire che un caso d'uso "base" può venire "esteso" con il comportamento definito in un altro caso d'uso, detto di estensione. L'estensione riguarda un comportamento opzionale del caso d'uso base, ed è soggetta ad una condizione di attivazione. Il caso d'uso base "ignora le proprie estensioni". La sequenza dei passi che lo descrive è in sé completa, e non contiene alcun riferimento alle condizioni ed ai comportamenti definiti nel caso d'uso di estensione.

11 Extend L'associazione di estensione è rappresentata da una dipendenza (linea tratteggiata, punta della freccia aperta) con lo stereotipo <<extend>>, la cui direzione va dal caso d'uso "di estensione" al caso d'uso "base". Extend L'unica particolarità che contraddistingue un caso d'uso soggetto ad estensioni è che nell'ambito della sua sequenza vengono definiti uno o più punti di estensione ("extension point"), che sono dei punti di ancoraggio ai quali si agganceranno i casi d'uso di estensione. Use case che estende <<extend>> Use case esteso I punti di estensione possono essere rappresentati in un comparto specifico dell'ellisse che rappresenta il caso d'uso base. Extend: funzionamento Il funzionamento prevede che quando una istanza dello use case base raggiunge una locazione referenziata da un punto di estensione la condizione viene valuatata : Se l esito è positivo (valore TRUE) allora le azioni specificate nel caso d uso estendente vengono eseguite Altrimenti si procede con le successive istruzione dello use case base Esempio Extend: funzionamento L assenza di una condizione corrisponde ad un valore sempre true. Se una relazione ha più punti di estensione la condizione viene verificata solo la prima volta ossia prima dell esecuzione del primo frammento

12 Esempio Inclusione o Estensione? Opzionalità: se l esecuzione del flusso di azioni di uno use case invocato deve avvenire solo al verificarsi di particolari condizioni (ossia rappresentauna variante al flusso di azione) bisogna usare la relazione di estensione. Inclusione o Estensione? Inclusione o Estensione? Se uno use case viene invocato solo da un altro probabilmente è opportuno usare l estensione. Se può essere usato nel flusso di azione di svariati casi d uso allora è da preferire la relazione di inclusione La relazione di inclusione ricorda molto l invocazione di una procedura (o metodo) e pertanto lo use case incluso deve ricevere (dallo use case base) gli eventuali attributi di cui necessita per eseguire il flusso di azioni Inclusione o Estensione? Esempi Lo use case esteso contiene il flusso primario degli eventi e non ha conoscenza diretta di eventuali altri casi d uso estendenti

13 FINE