Ingegneria del Software

Transcript

1 Università degli Studi di Napoli Federico II Ingegneria del Software a.a. 2013/14 UML e gli Use Case Diagrams

2 Outline Cos è UML Scopi, storia, obiettivi Fornire alcuni elementi di base su UML Introdurre i diagrammi principali Fornire indicazioni sulle modalità di utilizzo di UML

3 Unified Modeling Language (UML) linguaggio per la descrizione di diverse tipologie di sistemi (software, hardware, organizzativo, ) Standard OMG (Object Management Group), dal nov.1997 Creatori: Grady Booch, Ivar Jacobson e Jim Rumbaugh noti come los gringos dell Ingegneria del SW

4 Definizione ufficiale Un linguaggio per specificare, visualizzare, e realizzare i prodotti di sistemi software, e anche per il business modeling. L UML rappresenta una collezione di "best engineering practices" che si sono dimostrate utili nella progettazione di sistemi complessi e di grandi dimensioni.

5 Cos è UML E un linguaggio di modellazione e specifica di sistemi, basato sul paradigma object-oriented Serve a specificare le caratteristiche di un nuovo sistema, oppure a documentarne uno già esistente E uno strumento di comunicazione tra i diversi ruoli coinvolti nello sviluppo e nell evoluzione dei sistemi UML svolge un'importantissima funzione di lingua comune nella comunità della progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa UML per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico

6 Cosa NON è UML Non è una metodologia E un linguaggio, non un metodo completo Notazione e sintassi sono standard La semantica è spesso intuitiva e non sempre formalmente definita o universalmente accettata. Non è un linguaggio di specifica formale La semantica è spesso intuitiva e non sempre formalmente definita o universalmente accettata. UML non è legato ad uno specifico processo, e non fornisce indicazioni sul proprio utilizzo. Quindi può essere (ed è) utilizzato da persone e gruppi che seguono approcci diversi (è indipendente dai metodi ) UML è indipendente dal linguaggio di programmazione utilizzato

7 Breve Storia I linguaggi per la modellazione object-oriented iniziano a svilupparsi negli anni '80. notazioni di varia natura, per descrivere la struttura di un sistema software a oggetti (in termini di classi e relazioni fra classi) ed il suo comportamento dinamico. La proliferazione di queste notazioni diede luogo a quelle che furono poi battezzate guerre dei metodi (method wars), con diverse organizzazioni,che adottavano e sostenevano una particolare notazione a scapito delle altre. Nella metà degli anni '90 diversi metodi e linguaggi iniziarono a fondersi, e si iniziò a delineare la possibilità di una integrazione dei principali formalismi in una notazione universalmente accettabile. Fra le metodologie e le notazioni più apprezzate e diffuse del periodo spiccavano OMT (Object Modeling Technique) di Rumbaugh, e il cosiddetto metodo Booch di Grady Booch, entrambi ricercatori presso Rational Software. Il lavoro di unificazione iniziò con loro; in seguito si unì a questo sforzo Jacobson con la sua software house Objectory. Il primo risultato congiunto di questo team fu OOSE (Object Oriented Software Engineering).

8 Breve Storia (2) Mentre "i tre gringos" operavano per unificare i propri approcci all'analisi e alla progettazione a oggetti, il progetto fu accolto sotto l'egida dell'omg (Object Management Group). Nel 1995, l'omg raccolse tutti i principali metodologisti del settore in un incontro internazionale per discutere della notazione unificata. Nel 1996 l'omg emise una RFP (Request for Proposal) per tale notazione. Nello stesso anno, Booch, Rumbaugh e Jacobson misero a punto le release 0.9 e 0.91 di UML. Il progetto fu ben accolto dalla comunità internazionale e molte grandi organizzazioni si unirono a Rational per proseguirlo. Questo gruppo esteso realizzò, nel 1997, UML 1.0, che fu sottoposto alla OMG come risposta alla RFP dell'anno precedente. La release 1.1 di UML contribuì a consolidare la semantica del linguaggio e incluse elementi tratti da una proposta avanzata indipendentemente all'omg da un gruppo composto da IBM, ObjectTime, Ptech e altre.

9 Breve Storia (3) La versione 2.0 di UML, ufficializzata da OMG nel 2005, presenta numerose novità rispetto alla precedente versione 1.5, che resta comunque quella più diffusamente supportata dai tool di modellazione e citata nella letteratura. Principali novità di UML 2.0 : ampliamento, razionalizzazione e revisione del metamodello, permettendo una maggiore flessibilità introduzione del linguaggio formale OCL come parte integrante di UML numerosi nuovi elementi per la costruzione dei diagrammi tradizionali alcuni nuovi tipi di diagrammi

10 Panoramica del Linguaggio

11 Aspetti della modellazione Il progetto e l'architettura del sistema sono il risultato di una serie di decisioni importanti formulate ad un livello astratto. Un linguaggio per la descrizione del progetto è opportuno che sia fortemente basato su diagrammi. Un singolo diagramma non può catturare ogni aspetto rilevante: molteplici aspetti sono descritti da una molteplicità di diagrammi dedicati Il diagramma non è il progetto: è una rappresentazione del modello (di una parte) del progetto e ne cattura un aspetto in un formato che facilita la discussione.

12 Aspetti della modellazione UML consente di descrivere un sistema secondo tre aspetti: Il modello funzionale rappresenta il sistema dal punto di vista dell'utente, ovvero ne descrive il suo comportamento così come esso è percepito all'esterno, prescindendo dal suo funzionamento interno. Questo tipo di modellazione serve nell'analisi dei requisiti. La modellazione funzionale utilizza gli Use Case Diagram. Il modello statico rappresenta la struttura e sottostruttura del sistema utilizzando i concetti object-oriented di classe, oggetto, le relazioni fra classi e fra oggetti. Questo tipo di modellazione può essere utilizzata sia nella fase di analisi del dominio che nelle varie fasi di progetto a diversi livelli di dettaglio. Utilizza class diagram, object diagram, e deployment diagram. Il modello dinamico rappresenta il comportamento degli oggetti del sistema, cioè le dinamiche delle loro interazioni. È strettamente legato al modello a oggetti e viene impiegato negli stessi casi. Utilizza i sequence diagram, gli activity diagram e gli statechart diagram.

13 Viste Categorizzaione più fine: Vista dei casi d'uso: Use Case Diagram. Vista logica: quali parti del sistema sono legate concettualmente; modelli statici e dinamici per la la specifica del comportamento logico del sistema. Vista del processo: pone l'attenzione sui flussi del controllo; quali possono avvenire in parallelo; quali vanno sincronizzati (per il soddisfacimento di vincoli non-funzionali); diagrammi di interazione, stato, attività, deployment per la descrizione dei flussi di controllo. Vista dello sviluppo: aspetti di gestione dello sviluppo e riuso; diagrammi dei componenti e diagrammi dei package. Vista fisica: più concreta di quella di processo si concentra sull'esecuzione del software sulle macchine fisiche; diagrammi di deployment.

14 Classificazione dei Diagrammi UML (v. 2.x) diagrammi strutturali : diagramma delle classi (class) diagramma degli oggetti (object) diagramma dei componenti (component) diagramma delle strutture composite (composite structure) diagramma di deployment(deployment) diagramma dei package (package) diagrammi comportamentali di interazione : diagramma di sequenza (sequence) diagramma di comunicazione (communication) diagramma dei tempi (timing) diagramma di sintesi dell interazione (interaction overview) diagrammi comportamentali : diagramma dei casi d uso (usecase) diagramma di stato (statechart) diagramma delle attività (activity)

15 UML - considerazioni UML è il frutto di una rielaborazione di linguaggi preesistenti è adatto a esprimere modelli di varia tipologia, creati per obiettivi diversi. può descrivere un sistema software a diversi livelli di astrazione UML è sufficientemente espressivo per rispondere ad un ampio spettro di necessità di modellazione Può essere ritagliato in base alle specifiche esigenze dei progettisti e dei progetti, utilizzando solo ciò che serve nello specifico contesto

16 UML Diversi usi I modelli documentano decisioni di progetto e sono spesso utilizzati per la comunicazione tra le parti interessate. La produzione dei modelli è una attività dispendiosa (tempo) e costosa. Strategie: Riduzione della spesa: produzioni di modelli rapidi, non conservati e senza strumenti di supporto (ad esempio nei modelli di sviluppo agili) Aumento del valore: usare I modelli come Input per altri strumenti (ad esempio generazione del codice dai class diagram, generazione automatica dei casi di test...)

17 Gli Use Case Diagrams

18 Casi d uso I casi d'uso documentano il comportamento del sistema dal punto di vista dell'utente. Utente: qualsiasi si trovi fuori dal sistema e interagisca col sistema. La modellazione dei casi d'uso aiuta a modellare vari aspetti dello sviluppo: La definizione dei requisiti La pianificazione delle interazioni La validazione del sistema. Per questa fase UML offre i diagrammi dei casi d uso che vanno usualmente accompagnati a documentazione testuale strutturata (ad es. tabelle di Cockburn) o altri diagrammi di maggior dettaglio.

19 Caso d Uso Una sequenza di azioni, incluse le varianti, che un sistema compie per produrre un risultato osservabile che ha un valore per un attore Un caso d uso corrisponde a un compito che l attore vuole eseguire (l attore inizia il caso d uso) o il sistema deve eseguire (il sistema inizia il caso d uso) La descrizione di un caso d uso definisce cosa accade nel sistema in seguito all evento di innesco Generalmente lo stimolo di inizio parte dall attore ma può anche essere il sistema stesso a iniziare il caso d uso Uno scenario è una istanza di caso d'uso e rappresenta una interazione concreta di un attore con il sistema. Uno Use Case Diagram è l insieme di tutti i casi d uso. E una descrizione sintetica e completa delle funzionalità che offre un sistema e del contesto in cui opera.

20 Applicazione dei Casi d Uso Possono aiutare a identificare i requisiti fornendo una procedura di lavoro strutturata. Si identificano gli attori Per ogni attore: Cosa chiede al sistema (attore principale); Quali altre interazioni ha con il sistema, a quali casi d'uso prende parte per beneficiare altri (attore secondario) Per ciascun caso d'uso, per aspetti organizzativi di sviluppo (ad esempio, per stabilire gli incrementi nel processo iterativo): Importanza del caso d'uso e chi ne desidera la realizzazione; Rischi del caso d'uso; Tempistica di realizzazione e risorse richieste.

21 Diagramma dei Casi d Uso Contiene Attori Casi d uso Relazioni di associazione, dipendenza e generalizzazione Usato per modellare il contesto di un sistema Confini del sistema Gli attori sono esterni al sistema I casi d uso sono all interno del sistema Usato per modellare (visualmente) i requisiti funzionali Ogni caso d uso corrisponde a uno o più requisiti funzionali Ogni caso d uso è coinvolto in una qualche relazione Possibili diversi livelli di dettaglio Decomposizione gerarchica Individuazione di funzionalità riusabili

22 Elementi grafici del modello dei casi d uso Attore: è qualcuno (utente) o qualcosa (sistemi esterni dispositivi hardware) che: Controlla le funzionalità Fornisce input o riceve output dal sistema Ha un nome univoco all interno di un diagramma NB: gli attori identificano ruoli Più utenti con lo stesso ruolo Più ruoli per il medesimo utente Attore Use Case: è una funzionalità offerta dal sistema Caso d uso

23 Esempio di diagramma

24 Confini del sistema

25 Use Case Uno USE CASE rappresenta una classe di funzionalità offerte dal sistema, in termini di un flusso di eventi. Estendi prenotazione Uno Use Case è identificato da: Un nome univoco L insieme degli attori che vi partecipano La condizione di Entry Il Flusso degli Eventi Le condizioni di Exit Altre precondizioni

26 Esempio di descrizione di un Caso d Uso Nome: EstendiPrenotazione Attori: BookBorrower Entry condition: Utente con accesso al sistema. Utente accreditato Utente ha già in prestito il libro Flusso Eventi 1. Richiesta autenticazione 2. Utenente digita codice utente 3. Autenticazione 5. Richiesta estensione 6. Inserimento codice prestito 7. Verifica prenotazioni 8. Estensione prenotazione Exit condition: Utente ha esteso prestito.

27 Relazioni tra Use - Case Associazione: identifica relazioni semplici tra attori e casi d uso Include: fattorizza proprietà comuni. Extend: Varianti di comportamento. A può essere visto come una variante di B Generalization: si applica sia ad attori che a use case. A eredita il comportamento di B. A può essere sostituito ad ogni occorrenza di B

28 Relazione di inclusione

29 Relazione di inclusione Registra la decisione di utilizzare un componente o di evitare di ripetere le stesse informazioni su più casi d'uso. La fattorizzazione facilita la comprensione Identificazione delle possibilità di riuso. Granularità inclusioni: ogni inclusione rappresenta un caso d'uso significativo anche dal punto di vista della produzione

30 Relazione extend

31 Relazione extend Si utilizzano quando un caso d'uso riassume scenari diversi con uno scenario principale e alcune possibili varianti lecati a punti interni di decisone. Le varianti sono presentate casi d'uso legati da relazione extend. La descrizione comprende: La condizione sotto cui si presenta la variante Il punto in cui si verifica la decisione (Punto di estensione)

32 Generalizzazione use case

33 Generalizzazione attori Si applica quando un attore specializza l'interazione generica col sistema di un altro attore ereditando le sue possibilità di interazione La relazione è indicata da una freccia con la punta non riempita.

34 Esempio

35 Descrizione testuale degli Use Case La notazione diagrammatica è molto astratta e concisa e non permette di rappresentare informazione rilevante sugli scenari (Precondizioni, flusso del controllo, postcondizioni, etc). Ad ogni Use Case viene associata una descrizione più dettagliata spesso usando formati di testo strutturato (formati non regolati di UML) Esistono molti approcci e formati diversi in letteratura.

36 Dettaglio testuale Use Case

37 Diagrammi di CockBurn

38 Diagrammi di CockBurn(2)

39 Corrispondenza tra Casi d'uso e diagrammi di Cockburn Ogni caso d'uso dovrebbe avere in corrispondenza con un diagramma di Cockburn o una sua estensione o subvariazione (e viceversa). Per ogni caso d'uso U' che estende un caso d'uso U ci dovrebbe essere una extension in corrispondenza di U' nel diagramma di cockburn che corrisponde a U. Ogni caso d'uso U' che specializza un caso d'uso U potrebbe essere ragionevolmente in corrispondenza o con un diagramma di cockburn autonomo o con una subvariazione del diagramma di cockburn per U. Ogni caso d'uso che rappresenta una inclusione dovrebbe essere rappresentato da una diagramma di Cockburn autonomo di Level 'subfunction'.

40 Guida alla scrittura dei Casi d'uso I nomi dei casi d uso dovrebbero includere verbi I nomi di Attori dovrebbero essere sostantivi I casi d uso iniziano con un azione di un attore (trigger) Le relazioni causali nel flusso del controllo dovrebbero essere chiare Un caso d uso dovrebbe descrivere uno scenario completo Le varianti allo scenario principale dovrebbero essere descritte nelle sezioni apposite Un caso d uso non dovrebbe descrivere un interfaccia del sistema (utilizzare prototipi mock-up!) Un caso d uso non dovrebbe superare due o tre pagine

41 Guida alla scrittura dei Casi d'uso Errori da evitare: Modellare operazioni esterne al sistema (ad esempio rappresentare funzionalità di un sistema esterno che partecipa come attore); Introdurre generalizzazioni/specializzazioni improprie (ad esempio se un attore specializzato non ha uno Use Case distintivo è inutile); Adottare livelli di granularità troppo fine nella individuazione di casi d'uso inclusi (ogni caso d'uso dovrebbe avere associata una rilevanza non trascurabile nei tempi implementativi) non si deve tentare di rappresentare il flusso dei passi elementari mediante un diagramma Use Case (il flusso va allegato a documenti testuali). Evitare diagrammi troppo intricati ed illeggibili che vanificano l'efficacia comunicativa.