Use Case Driven Object Modeling: ICONIX

Transcript

1 Use Case Driven Object Modeling: ICONIX Un esempio di specifica, analisi, progetto e sviluppo utilizzando ICONIX Ditta di Noleggio Dvd Un sistema per la gestione di una ditta di noleggio dvd che ha più punti di distribuzione Autore: Valeriano Sandrucci Università di Firenze Facoltà di Ingegneria Corso di Ingegneria del Software (Prof. Giacomo Bucci)

2 ICONIX ICONIX è una metodologia di sviluppo software In ICONIX (come pure in Unified Process (UP)) il processo è guidato dai casi d'uso UML ICONIX è un approccio più leggero di UP ICONIX (a differenza dell'extreme Programming (XP)) fornisce una documentazione sufficiente dei requisiti e dell'analisi e del progetto Non si ha il problema noto come Analysis Paralysis ICONIX è descritto nel libro: Use Case Driven Object Modeling with UML: Theory and Practice.

3 ICONIX ICONIX è un processo che permette di trasformare i casi d'uso in codice funzionante Prima di iniziare il processo ICONIX occorre avere disponibile l'analisi dei requisiti. Dalla specifica dei requisiti si identificano i casi d'uso, il modello di dominio ed il prototipo dell'interfaccia Modello di dominio, casi d'uso ed interfaccia vengono validati per mezzo della Robustness Analysis Utilizzando i diagrammi dei passi precedenti viene costruito un diagramma delle classi a livello di specifica ed i diagrammi di sequenza Deployment: vengono scritti i test necessari a verificare il buon funzionamento del sistema e viene scritto il codice.

4 ICONIX Il tratto caratteristico di ICONIX è il suo uso dell'analisi di robustezza, un metodo per colmare la distanza tra Analysis e Design L'analisi di robustezza riduce l'ambiguità nella descrizione dei casi d'uso assicurando che vengano scritti nel contesto del corrispondente modello di dominio L'analisi di robustezza rende i casi d'uso più facili da implementare e testare

5 Analisi dei Requisiti Analisi dei Requisiti (operazione preliminare al processo ICONIX)

6 Cosa sono i requisiti Con la parola requisito si intende una caratteristica od una proprietà che una data persona o cosa è tenuta a possedere Requisiti del prodotto software Un requistito è: Qualcosa che il prodotto deve fare Una caratteristica che deve possedere Un requisito esiste sia perché il prodotto stesso lo richiede, sia perché il committente vuole che esso sia parte del prodotto.

7 Cosa sono i requisiti Distinguiamo tra scopo del prodotto e suoi requisiti Scopo: obiettivo (finalità) che il prodotto si prefigge Requisiti: insieme delle caratteristiche che il prodotto deve possedere per soddisfare al proprio scopo di uso. Esempio: Un sistema per il controllo del traffico areo Scopo: il controllo del traffico aereo di una certa regione Requisiti: N minimo di aerei controllati nello stesso tempo Riconoscimento immediato di situazioni che possono portare a collisioni Robustezza rispetto ad attacchi di hacker (terroristi).

8 Requisiti funzionali Ciò che il sistema deve fare Costituiscono la ragione stessa per la quale il sistema viene costruito/impiegato Esempio: Il sistema deve consentire ad un generico utente dal proprio PC di vedere i movimenti sul suo CC Il sistema deve consentire di effettuare operazioni di deposito dagli sportelli abilitati all'operazione....

9 Altri requisiti Requisiti non funzionali: proprietà (qualità) che il sistema deve possedere Il sistema deve essere portabile tra gli ambienti X,Y e Z Vincoli (Constraints): Requisiti di carattere generale che si applicano all'intero prodotto e sono definiti inizialmente prima che inizi l'effettiva raccolta dei requisiti Lo scopo del progetto è esso stesso un vincolo (ne determina i requisiti funzionali); gli utenti sono un vincolo (influenzano l'usabilità del prodotto)

10 Requisiti 1/3 Scopo Gestione dell'operazione di noleggio video Vincoli La ditta ha più punti di distribuzione sul territorio ognuno dei quali deve poter operare in modo indipendente dagli altri Gli utenti devono poter fruire di un servizio web nel quale trovare informazioni relative a tutti i punti di distribuzione

11 Requisiti 2/3 [R1] Il sistema deve consentire il noleggio di dvd da parte di un utente [R1.1] Ogni dvd si riferisce ad un solo film [R1.2] Ogni film ha un titolo una descrizione della trama ed un genere [R2] Il sistema deve permettere ad un utente autorizzato il caricamento e la rimozione di dvd nel punto di distribuzione

12 Requisiti 3/3 [R3] Il sistema deve permettere all'utente di lasciare un feedback relativamente ad un film che ha precedentemente noleggiato [R4] Il sistema deve permettere la prenotazione di dvd se disponibili

13 Analysis Inizia il processo ICONIX

14 Domain Model Domain Model

15 Domain Model Si vuole derivare il modello di dominio dall'elenco dei requisiti Il modello di dominio si rappresenta con un Class Diagram UML Il diagramma delle classi è volutamente semplice I dettagli verranno aggiunti successivamente Col modello di dominio si descrivono gli aspetti statici del sistema

16 Domain Model Nel diagramma delle classi: Non si specificano per adesso attributi e metodi delle classi Si adoperano solo le relazioni: Generalization (essere) Aggregation (avere)

17 Domain Model 1/3

18 Domain Model 2/3

19 Domain Model 3/3

20 Use Cases Use Cases

21 Use Cases Si vuole derivare il modello dei casi d'uso dall'elenco dei requisiti Il modello dei casi d'uso si rappresenta con un Use Cases Diagram UML Anche in questo caso è importante costruire una vista d'insieme e non perdersi nei dettagli Col modello dei casi d'uso si descrivono gli aspetti dinamici del sistema

22 Use Cases Nel costruire il diagramma dei casi d'uso Il committente potrebbe non comprendere le relazioni: include ed extends Sono più intuitive le relazioni: precedes ed invokes Nel costruire il diagramma dei casi d'uso conviene procedere per approssimazioni successive I casi d'uso devono riferirsi al modello di dominio

23 Actors

24 Use Cases Summary

25 Use Cases Summary

26 Distributor System

27 Distributor Use Cases 1/3

30 Distributor Domain Model

31 Center System

32 Center Use Cases 1/3

35 Center Domain Model

36 Use Cases Text & Mock-up Use Cases Text & Mock-up

37 Use Cases Text Il testo dei casi d'uso può essere rigorosamente formattato o meno (dressed use cases) Il testo dei casi d'uso deve essere non ambiguo e fare esplicito riferimento al modello di dominio ed alle interfacce usate

38 Use Cases Text Semplice template per i casi d'uso: UC: <nome del caso d'uso> Scope: <sistema/sottosistema cui si riferisce> Level: <livello di astrazione> Summary User goal Function Actor: <attore che inizia il caso d'uso> Basic Course: <interazione legata al caso positivo> Alternative Courses: <flussi alternativi>

39 Mock-up Sono prototipi dell'interfaccia Servono a capire come si presenterà il sistema una volta realizzato Sono estremamente facili da comprendere per il committente

40 Distributor Use Cases

41 UC: Search for Dvd UC: Search for Dvd Scope: Distributor System Level: User Goal Actor: Distributor User Basic Course: 1. Distributor User sulla maschera DvdSearch imposta filtri preme [Search] 2. Distributor System: 2.1 Estrae i Movie corrispondenti ai filtri 2.2 Estrae i Dvd disponibili corrispondenti ai Movie 2.3 Mostra DvdResults Alternative Corse: 2.1a Nessun Movie trovato: 2.1a.1 Distributor System mostra DialogMessage col messaggio "Nessun film trovato" 2.2a Nessun Dvd disponibile: 2.2a.1 Distributor System mostra DialogMessage col messaggio "Nessun Dvd disponibile" a Read error: a.1 Distributor System mostra DialogMessage col messaggio "Errore di sistema. Servizio non disponibile"

42 Mock-up DvdSearch DvdResults DialogMessage

43 UC: Get Dvd availability UC: Get Dvd availability Scope: Distributor System Level: User goal Actor: Center System Basic Course: 1. Center System chiama il metodo howmanydvdavailable di DistributorService per il distributore desiterato specificando id di Movie 2. Distributor System conteggia il numero di Dvd disponibili e restituisce AvailableDvd

44 Boundary Classes

46 Center Use Cases

47 UC: Create User UC: Create User Scope: Center System Level: User Goal Actor: Center Admin Basic Course: 1. Center Admin sulla maschera UserList preme [Create New User] 2. System mostra la maschera UserDetail vuota 3. Center Admin compila la maschera e preme [Save] 4. Center System: 4.1 Valida i dati 4.2 Salva il nuovo User 4.3 Mostra la maschera UserList aggiornata Alternative Courses: 3a. Center Admin preme [Cancel] 3a.1 Center System mostra la maschera UserList 4.1a Dati non validi: 4.1a.1 Center System mostra la maschera UserDetail con messaggio "Dati non validi" 4.2a Errore di salvataggio: 4.2a.1 Center System Mostra la maschera UserDetail col messaggio "Salvataggio non riuscito"

48 Mock up UserList UserDetail

49 UC: Notify Dvd unload UC: Notify Dvd unload Scope: Center System Level: User Goal Actor: Distributor System Basic Course: 1. Distributor System chiama il metodo unloaddvd di CenterService specificando id del distributore ed id del Dvd 2. Center System cancella il Dvd specificato e restituisce true (Boolean) Alternative Course: 2a Save Error: 2a.1 Center System restituisce false (Boolean)

50 CenterService Boundary

51 Center Domain Model

52 Robustness Analysis Robustness Analysis

53 Robustness Analysis L'analisi di robustezza è il tratto più caratteristico di ICONIX Per ogni caso d'uso si costruisce un diagramma di robustezza I diagrammi di robustezza devono essere costruiti con riferimento al modello di dominio ed all'interfaccia del sistema

54 Robustness Analysis Nei diagrammi di robustezza ci sono: Actor, Boundary, Controller, Entity Non tutte le relazioni sono ammissibili Sono ammissibili le relazioni tra: Actor Boundary Boundary Controller Controller Controller Controller Entity

55 UC: Search for Dvd 1/6 UC: Search for Dvd Scope: Distributor System Level: User Goal Actor: Distributor User Basic Course: 1. Distributor User sulla maschera DvdSearch imposta filtri preme [Search] 2. Distributor System: 2.1 Estrae i Movie corrispondenti ai filtri 2.2 Estrae i Dvd disponibili corrispondenti ai Movie 2.3 Mostra DvdResults Alternative Corse: 2.1a Nessun Movie trovato: 2.1a.1 Distributor System mostra DialogMessage col messaggio "Nessun film trovato" 2.2a Nessun Dvd disponibile: 2.2a.1 Distributor System mostra DialogMessage col messaggio "Nessun Dvd disponibile" a Read error: a.1 Distributor System mostra DialogMessage col messaggio "Errore di sistema. Servizio non disponibile"

60 UC: Search for Dvd 6/6

61 UC: Get Dvd availability UC: Get Dvd availability Scope: Distributor System Level: User goal Actor: Center System Basic Course: 1. Center System chiama il metodo howmanydvdavailable di DistributorService per il distributore desiterato specificando id di Movie 2. Distributor System conteggia il numero di Dvd disponibili e restituisce AvailableDvd

62 UC: Create User UC: Create User Scope: Center System Level: User Goal Actor: Center Admin Basic Course: 1. Center Admin sulla maschera UserList preme [Create New User] 2. System mostra la maschera UserDetail vuota 3. Center Admin compila la maschera e preme [Save] 4. Center System: 4.1 Valida i dati 4.2 Salva il nuovo User 4.3 Mostra la maschera UserList aggiornata Alternative Courses: 3a. Center Admin preme [Cancel] 3a.1 Center System mostra la maschera UserList 4.1a Dati non validi: 4.1a.1 Center System mostra la maschera UserDetail con messaggio "Dati non validi" 4.2a Errore di salvataggio: 4.2a.1 Center System Mostra la maschera UserDetail col messaggio "Salvataggio non riuscito"

63 UC: Create User

64 UC: Notify Dvd unload UC: Notify Dvd unload Scope: Center System Level: User Goal Actor: Distributor System Basic Course: 1. Distributor System chiama il metodo unloaddvd di CenterService specificando id del distributore ed id del Dvd 2. Center System cancella il Dvd specificato e restituisce UnloadSuccess Alternative Course: 2a Save Error: 2a.1 Center System restituisce UnloadFail

65 UC: Notify Dvd unload

66 Architecture

67 Design Design

68 UC: Search for Dvd

69 Distributor Application

70 Search for Dvd

72 Riassumendo ICONIX inizia dopo che sono stati raccolti i requisiti ICONIX si compone di due fasi principali Analysis e Design (per ora abbiamo visto solo Analysis) La Robustness Analysis completa la fase di Analysis ICONIX non specifica in che modo debbano essere trattati i requisiti non funzionali ed architetturali

73 Osservazioni L'analisi di robustezza completa la fase di analisi I diagrammi di robustezza permettono di verificare che casi d'uso, modello di dominio ed interfacce sono consistenti tra di loro I diagrammi di robustezza saranno la base per la successiva fase di Design

74 Osservazioni ICONIX sembra un metodo di sviluppo a cascata Ogni fase può essere applicata ad un sotto-problema in modo da rendere iterativo il metodo Esempio: scrivo il testo e disegno le interfacce solo per un sottoinsieme di casi d'uso La gestione delle fasi può essere fatta con UP Le iterazioni di ogni fase possono venire gestite con ICONIX