Unified Modeling Language -Index -

Transcript

1 Unified Modeling Language -Index - Henry Muccini Università degli Studi dell'aquila muccini@di.univaq.it Engineering IgTechnology Imola Informatica Maggioli Informatica Micron Technology Neta Nous Informatica ObjectWay SED TechnoLabs Taiprora Master in Web Technology IV Edizione 2007/08 Dipartimento di Informatica Università degli Studi dell Aquila

2 Copyright Notice» Il materiale riportato in queste slide puo essere riutilizzato, parziale o totalmente, a patto che le fonti e gli autori vengano citati Henry Muccini 2

3 Index 1/2: UML for OO systems» Index» Best Practices e Overview su UML: > Cos e > Quando e perche nasce» Introduzione alle Web Application» Use Case diagram» Class diagram» Sequence diagram» State diagram» Tools» Esempi» Bibliografia 3

4 Index 2/2: UML-Web» Design Decisions» Uml & Web: Approccio WAE: Conallen» Uml & Web: Applicazione Approccio WAE» Uml & Web: Approccio UWE: Koch et al.» Applicazione Approccio UWE» Uml & Web: Approccio WebML 4

5 Other» UML and Software Architecture» UML and Data Modeling» UML and Security 5

6 Pianificazione Master 6

7 Pianificazione Lezioni L01:Overview e Use Case Diagram L02: Class Diagram L03: Sequence e State Diagram L04: Design Decisions L05: Esempio da discutere in classe L06: WAE L07: WAE L08: UWE L09: UWE L10: Revisione Progetto L11: WebML L12: Revisione Progetto 7

8 Pianificazione» Lezione 1: > Identificazione esigenze e skill dei discenti > Presentazione 01.1: Indice > Presentazione 01.2: Best Practices e Overview su UML > Presentazione 01.3: Introduzione alle Applicazioni Web > Presentazione 01.4: Use Case Diagram > Esercitazione da fare a casa (IntelliHome) - Da discutere durante la Lezione 5 Venerdi 19 Ottobre Mattina» Lezione 2: > Considerazioni su Lezione precedente > Presentazione 02: Class Diagram > Acquisizione di familiarità con il Tool > Esercitazione da fare a casa (IntelliHome) - Da discutere durante la Lezione 5 Giovedi 25 Ottobre Pomeriggio 8

9 Pianificazione Venerdi 26 Ottobre Mattina» Lezione 3: > Considerazioni su Lezione precedente > Presentazione 03.1: Sequence Diagram > Presentazione 03.2: State Diagram > Acquisizione di familiarità con il Tool > Esercitazione da fare a casa (IntelliHome) - Da discutere durante la Lezione 5 9

10 Pianificazione Sabato 27 Ottobre Pomeriggio» Lezione 4: > Considerazioni su Lezione precedente > Presentazione 04: Design Decision > Esercitazione da fare a casa (IntelliHome) - Da discutere durante la Lezione 5 > Studio capitoli 1-3 del libro - Moran and Carroll Eds. (1996), Design Rationale (Lawrence Erlbaum Associates) 10

11 Pianificazione Venerdi 09 Novembre Pomeriggio» Lezione 5: > Considerazioni su Lezione precedente > Controllo esercitazione fatta a casa - UML Modeling - Design Decisions > Presentazione 05.1: Tools > Presentazione 05.2: CaseStudy(E-commerce) > Presentazione 05.3: Bibliografia 11

12 Pianificazione Sabato 10 Novembre Mattina» Lezione 6: > Considerazioni su Lezione precedente > Considerazioni su Lezione precedente > Presentazione 06: Approccio WAE Conallen - Parte 1 > Case Study > Tool 12

13 Pianificazione Giovedi 15 Novembre Pomeriggio» Lezione 7: > Considerazioni su Lezione precedente > Considerazioni su Lezione precedente > Presentazione 07: Approccio WAE Conallen - Parte 2 > Case Study > Tool 13

14 Pianificazione» Lezione 8 e Lezione 9: > Considerazioni su Lezione precedente > Presentazione 08 e 09: Approccio UWE > Case Study > Tool Venerdi 16 Novembre Mattina Sabato 17 Novembre Pomeriggio 14

15 Pianificazione Giovedi 22 Novembre Pomeriggio» Lezione 10: > Considerazioni su Lezione precedente > Revisione di Progetto 15

16 Pianificazione Giovedi 23 Novembre Pomeriggio» Lezione 11: > Considerazioni su Lezione precedente > Presentazione 11: WebML > Case Study > Tool 16

17 Pianificazione Sabato 24 Novembre Mattina» Lezione 12: > Considerazioni su Lezione precedente > Revisione di Progetto 17

18 Gestione del Corso» Metodo di insegnamento: > Slide, lavagna, interazione diretta, uso di PC» Piu domande fate, piu impariamo insieme > Se non mi rendo conto che non capite, non vi posso aiutare!» Esempi: > Diversi esempi d uso verranno proposti» Esercitazioni: > Da verificare a lezione 18

19 Progetti» 1 Esercitazione: > UML modeling (senza voto) - Gruppi da 2 - Sistema: Intelligent Home - Consegna: - Discussione: prima della lezione 5»1 Progetto con voto: > Web Modeling con WAE: - Gruppi Internazionali e Locali - Gruppi (in totale) da 4 -Sistema: Intelligent Home - Consegna: - Dicembre

20 Altro» Mailing list > > Da creare subito» Permesso di entrata per il Sabato > Vostri nomi e cognomi» Questionario elettronico > Per controllare i vostri skill» Sito: > Troverete gia : questionario, sistema IntelliHome, Design Decisions 20

21 Tempistica» Deadlines: > 24 Ottobre: questionari e mailing lists > 25 Ottobre: use case diagram dell IntelliHome > 27 ottobre: lettura dei tre capitoli su design decision > 05 novembre: formazione gruppi: - Gruppi locali - Gruppi internazionali > 09 novembre: UML dell IntelliHome > Consegna progetti - 21 Dicembre: internazionali - 28 Gennaio: locali 21

22 Progetti» Dovrete consegnare: > UML WAE dell IntelliSystem > Design Decision > Communications log > Consistency log > Personal Journal > Controllate: - General Project Guidelines.zip che riassume i vari documenti da consegnare ed i ruoli - Roles.zip che spiega i vari ruoli - Documents.zip che spiega i vari documenti da consegnare - TemplateForTheDesignSpace.zip che fornisce il template per il Design Space 22

23 Unified Modeling Language -Best Practice- Henry Muccini Università degli Studi dell'aquila Engineering IgTechnology Imola Informatica Maggioli Informatica Micron Technology Neta Nous Informatica ObjectWay SED TechnoLabs Taiprora Master in Web Technology IV Edizione 2007/08 Dipartimento di Informatica Università degli Studi dell Aquila

24 Copyright Notice» Il materiale riportato in queste slide puo essere riutilizzato, parziale o totalmente, a patto che le fonti e gli autori vengano citati Henry Muccini 2

25 Agenda» Problemi Attuali» Modellazione» Diagrammi UML: overview» Caratteristiche di UML 3

26 Situazione Sviluppo SW» Negli USA ogni anno si spendono circa $ milioni sullo sviluppo di applicazioni IT» Costo medio > $ per aziende grandi > $ per medie aziende > $ per piccole aziende» 31.1% dei progetti cancellati prima che finiscano» 52.7% dei progetti costano il 189% delle previsioni iniziali» Perdita di costi approssimativamente 3 bilioni di dollari Fonte Standish Group,

27 Piu recentemente» NIST (National Institute of Standards and Technology) study in 2002 [NIST], > software errors cost the U.S. economy $59.5 billion every year.» Standish Chaos report [Standish] > a clear statement of requirements is one of the three main reasons that lead to project success, as well as incomplete requirements are one of the main reason of projects deletion. [NIST] The economic impacts of inadequate infrastructure for software testing. In NIST Planning Report affairs/releases/n02-10.htm. [Standish] The standish group report: Chaos

28 What do they have in common?» Ariane 5» X-ray machine» Denver Airport» Air Traffic Control» Word 3.0 for MAC» NSA» First launch of space shuttle» Airbus 320» Audi 5000» Mariner 1 launch» AT&T telephone network They All Failed! [Fatal Defect, Ivars Peterson, 1995] $85 Billion in lost productivity due to faulty software last year 6

29 Aeroporto di Denver» Grande due volte Manhattan» Software > 35 km di rotaie per 4000 tele-carrelli > circa 100 calcolatori, 400 ricevitori, 5000 fotocellule > costo software: 193 milioni di dollari» Ritardo 9 mesi nell apertura dell aeroporto dovuto al malfunzionamento del software per lo smistamento automatico dei bagagli» Perdite di oltre 1/2 milione di dollari al giorno News a Giugno

30 Cause di fallimento» Gestione non disciplinata dei requisiti» Comunicazione ambigua ed imprecisa» Architetture instabili» Complessità ingestibile» Incoerenze tra requisiti, progettazione e implementazione» Test insufficienti 8

31 Soluzione: Best practice Utilizzo dell Ingegneria del Software, per: 1. Sviluppare il SW in modo iterativo 2. Gestire i requisiti 3. Utilizzare architetture basate su componenti 4. Modellare il software in modo visuale 5. Verificare la qualità del SW 6. Controllare le modifiche apportate al SW UML contribuisce in tutte queste aree 9

32 Risultati sperati Risparmio di 17,2 milioni di dollari Aumento % della produttivita Costo delle correzioni (% del costo totale) La Raytheon ha risparmiato 17,2 milioni di dollari e raddoppiato la produttivita utilizzando procedimenti rigorosi

33 Introduzione all UML» Introduzione a UML > Modelli > Cosa è > Obiettivi iniziali > Caratteristiche > Un po di storia» Elementi di UML (cenni) 11

34 UML: Cosa è?» Acronimo Unified Modeling Language > Language: linguaggio > Unified: standard, modello unificato > Modeling: per la modellazione» Linguaggio per > Visualizzare > Specificare > Costruire > Documentare gli elaborati di un sistema software 12

35 Modelli» Obiettivo non è costruire documenti ma SW che soddisfi le richieste dell utente con tempi e modi prevedibili» Modelli aiutano a costruire del buon SW» Modellazione tecnica di ingegneria provata e accettata > Modelli matematici per previsioni > Modelli per costruire macchine, automobili 13

36 Modelli» Cosa è > Un modello è una semplificazione della realtà» Perché > Si costruiscono modelli per meglio comprendere il sistema che si sta sviluppando 14

37 Modelli nella Metereologia 15

38 Modeling a bridge 16

39 Hardware Modeling 17

40 Modelli» Scopi > Documentano le decisioni prese - Aiutano a visualizzare un sistema così com è e così come lo vogliamo - Permettono di specificare la struttura o il comportamento di un sistema - Danno un template che guida alla costruzione di un sistema > Possono essere usati per analisi 18

41 Esempi» Documentazione: > Invece di avere 500 pagine di documenti, abbiamo i modelli (SOLO quelli che servono)» Disambiguare le specifiche: > Le propedeudicita sono state eliminate - Ma l esame iniziale e una propedeudicita? - Ma tutte le propedeudicita sono state eliminate, o solo quelle relative a certi corsi? - 19

42 Analizzare» Basti pensare ai modelli di ingegneria civile, ai modelli di Gaudi 20

43 Principi di modellazione» La scelta di quale modello utilizzare ha una profonda influenza su come un problema è attaccato e risolto» Ogni modello può essere espresso a diversi livelli di precisione» I migliori modelli sono connessi alla realtà» Un solo modello non è sufficiente. Vari piccoli modelli indipendenti 21

44 Diagrammi UML: overview 22

45 Tipi di diagrammi» Diagrammi statici > Rappresentano la struttura base del sistema oggetto di realizzazione» Diagrammi dinamici > Enfatizzano il comportamento del sistema 23

46 24

47 Modello statico» Costruisce e documenta l aspetto statico di un sistema» Riflette la base, lo scheletro di un sistema SW» Crea una rappresentazione degli elementi del dominio del problema» Diagrammi statici in UML > Use-case diagrams > Class diagrams > Object diagrams > Component e Deployment diagrams 25

48 Modello Dinamico» Creare diagrammi che mostrano il comportamento di un sistema» Diagrammi dinamici in UML > Interaction diagrams - Sequence diagrams - Collaboration diagrams > State-chart diagrams > Activity diagrams 26

49 Altri elementi in UML» Package: meccanismo general-purpose per organizzare gli elementi in gruppi» Commenti (note) in UML» Meccanismi di estensione > Stereotipi: permette di estendere l UML > Tagged value: estende le proprietà di un elemento in UML > Constraint: estende la semantica di un elemento in UML 27

50 Modelli Statici 28

51 Use-case diagram Perform card tra nsactio n Custo mer Retail institu tion Process customer bill Reconcile transaction Individual Customer Corporate Customer Sponsoring financial institution Manage customer account 29

52 Class diagram 30

53 Object diagram» Mostrano un insieme di oggetti e le loro relazioni» Rappresentano un fotografia statica delle cose trovate nel class diagram» Vengono utilizzati qualora il class diagram è complesso e uno scenario semplifica la comprensione 31

54 Component diagram 32

55 Deployment diagram 33

56 Modelli Dinamici 34

57 Sequence diagram 35

58 Communication diagram 36

59 State-chart diagram 37

60 Activity diagram 38

61 Caratteristiche di UML 39

62 Caratteristiche» E un linguaggio di modellazione e non un processo, quindi può essere utilizzato in diversi processi > Un processo buono in un contesto, può essere un disastro in un altro contesto > La selezione di un processo dipende fortemente dal dominio del problema 40

63 Caratteristiche (1/4) Linguaggio di modellazione grafica che permette semplicità d uso ed elevata espressività semantica Linguaggio grafico Diagrammi Ogni simbolo ha una sua semantica ben definita 41

64 Caratteristiche cognome nome Id_ut chiave-pubblica sesso chiave-pub-restart residenza UTENTE 1,1 indirizzo orario-okfunz data-nascita importo 1,1 STIPULA 1,n stato-sociale intervallo-tempo-okfunz professione 1,n CONTRATTO data scadenza tipo-contratto Id_pr PROVIDER chiave-pubblica cod-operatore chiave-pub-restart COLLEGATO 1,n Ip_rt Router Master 0,n tipo PREVEDE chiave-pubblica chiave-pub-restart ROUTER localizzazione 1,n CHIAMA orario-okfunz 0,n 1,1 ATTIVA CONNESSO 1,(1) 1,n 1,n 0,n SERVIZIO tipo-servizio denominazione 1,n chiave-pubblica chiave-pub-restart Id-cs numero-telefono 1,n CENTRO SERVIZI tipologia 1,n localizzazione chiave-pub-restart chiave-pubblica Ip-sv SERVER CHIAMA 42 1,n

65 Caratteristiche UTENTE indirizzo 1,1 43

66 Caratteristiche residenza sesso indirizzo UTENTE data-nascita 1,1 STIPULA stato-sociale professione residenza Problema Simboli Standard sesso indirizzo data-nascita utente stipula stato-sociale professione 44

67 Caratteristiche residenza sesso indirizzo UTENTE data-nascita 1,1 STIPULA stato-sociale professione Problema Semantico Cosa indica la notazione 1,1? Cosa indica il simbolo romboidale?... 45

68 Caratteristiche residenza sesso indirizzo data-nascita UTENTE 1,1 STIPULA Problema stato-sociale professione Composizione Notazione 1,1 UTENTE STIPULA 46

69 Caratteristiche (2/4)» Meccanismi di estensibilita e specializzazione» Poter comunque introdurre concetti nuovi» Indipendenza da linguaggi di programmazione particolari» E un linguaggio di progettazione non di programmazione 47

70 Caratteristiche (3/4)» Linguaggio standard, risultato di un lavoro di collaborazione fra diversi team: > Incoraggiamento dello sviluppo del mercato dei tools per sistemi OO > Riuso» Adeguatezza nella rappresentazione di sistemi reali 48

71 Caratteristiche (4/4)» Per gestire e controllare la complessita del sistema > Differenti viste del sistema - Diagrammi differenti per Statica, Dinamica, Deployment, > Differenti livelli di rappresentazione - Nella fase dei Requisiti e per il Design 49

72 Storia» Un po di storia > Anni 70 Approccio Strutturato > Anni 80 Information Engineering > Anni 90 Approccio Object-Oriented : da 10 a 50 linguaggi di modellazione (guerra dei metodi)» Metà degli anni 90: Booch 93, OOSE e OMT-2 iniziano a prevalere sulle altre tecniche > OOSE è un sistema per l analisi dei requisiti (Use-Case) > OMT-2 orientato all analisi di sistemi data-intensive > Booch 93 utile nella fase di disegno e di costruzione del sistema SW 50

73 Storia» Grady Booch, James Rumbaugh e Ivar Jacobson furono spinti a creare un linguaggio di modellazione unificato per le seguenti motivazioni» Gennaio 1997: sottoposta all OMG la standardizzazione di UML 1.0» Versione attuale UML

74 OMG» Object Management Group (OMG) è un organizzazione internazionale con l intento di stabilire delle linee guida per le industrie al fine di fornire un framework comune per lo sviluppo di applicazioni» Composto da oltre 800 membri, fra sviluppatori, utenti e vendors» Fondato nel 1989» Promuove la teoria e la pratica di tecnologie Object-oriented» 52

75 UML & WEb -Web Applications - Henry Muccini Università degli Studi dell'aquila muccini@di.univaq.it Engineering IgTechnology Imola Informatica Maggioli Informatica Micron Technology Neta Nous Informatica ObjectWay SED TechnoLabs Taiprora Master in Web Technology IV Edizione 2007/08 Dipartimento di Informatica Università degli Studi dell Aquila

76 Copyright Notice» Il materiale riportato in queste slide puo essere riutilizzato, parziale o totalmente, a patto che le fonti e gli autori vengano citati Henry Muccini 2

77 Agenda» Breve storia del Web» Introduzione ad Applicazioni Web e Glossario dei termini» Architettura di una Applicazione Web» Perche modellare una applicazione Web 3

78 Prima di cominciare 4

79 Storia di Internet in pillole» 1965: L'ARPA dà inizio di un progetto > comunicazione e lo scambio di risorse tra i computer dei vari laboratori universitari finanziati dall'agenzia. > Stimolare e finanziare la ricerca di base in settori che avrebbero potuto avere una ricaduta militare» 1969: Rete Arpanet in funzione 5

80 Storia di Internet in pillole» 1970: Protocollo FTP» 1972: Ray Tomlinson inventa la posta elettronica» 1974: nascita di TCP/IP» 1980: nasce il PC» 1988: nasce la chat di IRC» : > Posta elettronica, mailing list, newsletter, newsgroup, chat» 1989: nasce il WWW» : Netscape ed IE» 1999: file sharing in P2P 6

81 Internet: concetto di Rete» Reti tradizionali > I tubi del gas possono trasportare soltanto del gas > I cavi dell'enel possono trasportare soltanto l'energia elettrica > La rete idrica non può che trasportare dell'acqua > La rete telefonica trasporta la voce» La rete internet trasporta: > messaggi di posta elettronica, pagine Web > informazioni da agenzie di stampa > brani musicali, fotografie digitali > prenotazioni, acquisti, pagamenti > richieste a motori di ricerca e relative risposte 7

82 Internet oggi» Terra: oltre 665 milioni di utenti - [fonte UIT, ottobre 2003]» Italia: 23 milioni di utenti - (fonte Associazione Italiana Editori, Rapporto 2005 sull'editoria digitale [ Un milione di domini ".it" (News del CNR, gennaio 2005) 8

83 Servizi Internet» Siti Web: > Informazioni > News, Newsletter > Chat > Forum > Mailing list > Immagini, Icone, > Calendario degli eventi > Sondaggi > Domande e Risposte > Filmati ed Audio > PDA» Posta Elettronica» Chat e VoIP» Scrittura Condivisa e Remota 9

84 Vostre conoscenze sul mondo Web» Html» Object Oriented» Java» > Altro?» Domanda: ma il Web e solo Html? > Contenuti dinamici > Operazioni complesse, grandi quantita di dati, cambiamenti frequenti, 10

85 Sito Web 11

86 Siti Web Richiesta Browser Documento Web server File system Pagine HTML statiche 12

87 Limiti» Nessuna adattabilita : > Immaginiamo di non usare Templates» Difficolta nella Manutenzione: > Assumiamo di dover cambiare dei dati sulla mia pagina web > Perche e cosi difficile?» Discussione sui sistemi Web complessi reali > Quali siti visitate? > Quali servizi utilizzate? > Sareste in grado di realizzarli in Html base? 13

88 Esempio di Applicazione Web 14

89 L Applicazione ha al suo interno» Tecnologie Web > Grafica > Servizi > Database» Contenuti > Almeno 15 persone che lavorano full-time sui contenuti

90 Grafica 16

91 Servizi» Meteo» SMS» Sondaggi» Ricerche» Forum» 17

92 Dati 18

93 Applicazioni Web Browser Richiesta Web server Application server Documento Pagine HTML Base di dati 19

94 Applicazione Web» Applicazione Web > Definizioni: - Applicazione scritta per operare su Internet - Estenzione dinamica ad un Web server - Un programma che prende in input dei dati dal richiamo di un link (GET) o dalla sottomissione di una form HTML (POST) e restituisce come output un documento HTML - A software program that uses HTTP for its core communication protocol and delivers Web-based information to the user in the HTML language. Also called a Web-based application (Microsoft). > Include applicazioni realizzate con varie tecnologie - piattaforma J2EE - CGI o Perl, ASP, JSP, JavaScript, 20

95 Web Application» Web site Web application» Web application = > web site con business logic > client che invia input che vengono eseguiti dall esecuzione di un modulo» Presenza di un Application Server che permette di gestire business logic» Chi esegue tale computazione??? 21

96 Architettura minimale: Client-Server 22

97 Limiti dell Approccio C/S» Ben presto ci si accorge che il modello architetturale C/S e inadatto ad applicazione di tipo Web» Nel modello C/S, l interfaccia utente ètotalmente implementata sul client, il database management è totalmente allocato sul server mentre il process management èin un qualche modo suddiviso tra client e server!» Cosa accade se vogliamo toccare la grafica senza modificare la logica (o viceversa)? > Tutto e mischiato e non sappiamo come muoverci 23

98 Soluzione: Tre livelli concettuali» Livello Presentazione: > si occupa di ricevere le GET e le POST dal server, per ottenere l input del programma > costruisce i documenti HTML che costituiscono l output del programma» Livello Logico: > calcola l output a partire dall input e dai dati memorizzati nel terzo livello > definisce la funzione del programma» Livello Dati: > costituito tipicamente da un database, mette a disposizione dell applicazione un supporto per memorizzare le informazioni 24

99 25

100 Vantaggi» Maggiore scalabililtà e modificabilità, dal momento che, cambiando la business logic, non si devono modificare tutti i clients» Clients leggeri, che forniscono soltanto funzionalità per la rappresentazione di dati e l interazione dell utente con il sistema» Possibilità di implementare logiche aggiuntive, estremamente interessanti 26

101 Perche modellare Applicazioni Web?» Browser» Protocolli (HTTP, )» Pagine Web (HTML, )» Web server (Apache, )» Programmi server» Application server» Data Base» 27

102 Unified Modeling Language UML2.0 -Use Case Diagrams - Henry Muccini Università degli Studi dell'aquila muccini@di.univaq.it Engineering IgTechnology Imola Informatica Maggioli Informatica Micron Technology Neta Nous Informatica ObjectWay SED TechnoLabs Taiprora Master in Web Technology IV Edizione 2007/08 Dipartimento di Informatica Università degli Studi dell Aquila

103 Copyright Notice» Il materiale riportato in queste slide puo essere riutilizzato, parziale o totalmente, a patto che le fonti e gli autori vengano citati Henry Muccini 2

104 Sommario» Use Case Diagram > Attore > Use Case > Attore e Use Case > Relazione tra attori (generalizzazione) > Relazioni tra use case 3

105 Use Case Diagram» Specifica le funzionalita del sistema > Use Case» Specifica gli attori umani o automatici che utilizzano il sistema (e le sue funzionalita ) > Attori» Evidenzia come le funzionalità del sistema vengono messe a disposizione degli utilizzatori del sistema > Use Case Diagram = Use Case, attori, e relazioni tra loro» Catturano il comportamento di un sistema che si sta sviluppando, senza specificare come il sistema lo implementerà» Costituiscono il contratto tra il committente e l implementatore del sistema 4

106 Vantaggi» Strumento facilmente comprensibile dagli utenti e quindi utilizzati per comunicare ed ottenere la validazione dei requisiti» Permettono di definire chiaramente i confini del sistema ed evidenziarne i vari attori (umani e non)» Esprimono il comportamento del sistema, evidenziando eventuali incoerenze e lacune nella fase di analisi dei requisiti» Forniscono un ottima documentazione 5

107 Sistema» Prima di iniziare a modellare le funzionalità del sistema è necessario determinare i confini del sistema stesso» E necessario stabile i confini in modo tale che non si rischia di modellare entità che non fanno parte del sistema» Graficamente è rappresentato come un rettangolo che contiene tutti gli use case del sistema» E opzionale e viene fatto raramente 6

108 Sistema UML2.x: Questo box non rappresenta per forza un package. Puo rappresentare un qualsiasi modo di collezionare Use Cases 7

109 Attore» Insieme coerente di ruoli che un utente di un caso d uso (funzionalità) recita quando interagisce con esso» Non necessariamente persona fisica, può essere anche un altro sistema» E un entità esterna al sistema oggetto di modellazione» Rappresentato mediante un omino stilizzato (stick man) 8

110 Attore UML2.x: Icone specifiche possono essere introdotte per non-human actors Studente Universitario Legacy System Cliente Amministratore Billing System 9

111 Attore» Attori comunicano con il sistema inviando o ricevendo messaggi» Due tipi > Primari: utilizzano le funzioni proprie del sistema; sono detti attivi > Secondari: fruiscono di informazioni o notifiche generate da use case; sono detti passivi» Attore può essere attivo in uno use case e passivo in un altro 10

112 Use Case» Descrizione di un insieme di sequenze di azioni che un sistema esegue per ottenere un risultato osservabile di valore per un attore» Sequenza di azioni che l entità esegue interagendo con il relativo attore che sono necessarie per erogare un certo servizio» Rappresentano quindi i requisiti funzionali del sistema 11

113 Use Case» Graficamente è rappresentato mediante una ellisse» Ha un nome che identifica la funzionalità > Può essere semplice o con path (se appartiene ad un package) > Generalmente i nomi sono frasi brevi prese dal vocabolario del sistema che si sta modellando» Ha una breve descrizione che descrive il ruolo e lo scopo dello use case 12

114 Use Case Validate user Place Order Sensors::Calibrate location 13

115 Use Case» Descrive cosa un sistema fa (le sue funzionalità) ma non come, cioè la sequenza di azioni eseguita dal sistema per realizzare una determinata funzionalità» E necessario descrivere un flusso di eventi che modella il comportamento dello use case» Flusso di eventi può essere descritto > Formato testuale: generalmente rappresentato tramite pseudo-codice (cioè testo strutturato) > Formalmente: mediante activity oppure tramite sequence (generalmente vengono utilizzati successivamente alla descrizione testuale) 14

116 Use Case» Flusso di eventi è composto > Flusso principale (basic flow o happy path) Descrive quello che accade il più delle volte quando viene eseguito lo use case > Flussi alternativi Generalmente descrivono i flussi eccezionali (cioè che gestiscono situazioni di errori) oppure flussi che si verificano raramente. Sono utilizzati anche per organizzare use case complessi 15

117 Use Case» Pre-condizioni > Definiscono lo stato in cui si deve trovare il sistema prima che inizi lo use case > Possono essere descritte in forma testuale oppure formale (es. O.C.L.)» Post-condizioni > Definiscono una lista di possibili stati in cui si deve trovare il sistema dopo che è terminato lo use case > Possono essere descritte in forma testuale oppure formale (es. O.C.L.) 16

118 Esempio UML2.0: Notazione alternativa per Use Cases Studente Registrazione Corsi Catalogo Corsi 17

119 Bacheca Virtuale: funzionalita analizzate dai gruppi > Il sistema deve permettere di: - Anagrafica messaggi: - Inserire, modiicare, cancellare e leggere messaggi - Anonimato - Identificare categorie di messaggi - Autenticazione, Registrazione, modifica, controllo diritti di accesso - Scadenza messaggi - Ricerca (con certi criteri) di messaggi - Moderazione sui messaggi - Newsletter sulla categoria di interesse - Profilo utente - Contatto: , sms, chat - Amministrazione del sito 18

120 Considerazioni» Solo funzionalita, non altro! > Cos e una funzionalita?» Non tutte le funzionalita sono allo stesso livello di astrazione» Una funzionalita puo contenere altre sotto-funzionalita» Alcune funzionalita possono essere simili» Alcune funzionalita possono richiedere altre funzionalita come pre-condizione» Non tutte le funzionalita hanno la stessa importanza» Diversi attori richiedono diverse funzionalita» Accorpare funzionalita 19

121 Attore e Use Case» Attori sono entità esterne al sistema che interagiscono con esso» Le interazioni consistono in uno scambio di messaggi» Attore è connesso con gli use case mediante una relazione di associazione che permette di attivare (attore attivo) lo use case o di ricevere (attore passivo) i risultati 20

122 Attore e Use Case» Relazione di associazione è l unica relazione possibile tra attore e use case» Può avere la proprietà di navigazione (cioè può esserci una freccia) la quale indica, per convenzione, la direzione dell inizio della comunicazione tra lo use case e l attore» Per una comunicazione che coinvolge una risposta non è necessario inserire la freccia nella parte che ha attivato la funzionalità» Se la comunicazione iniziale avviene da entrambe le direzioni le frecce vengono omesse 21

123 Attore e Use Case Effettua Ordine Cliente Venditore Verifica Ordine 22

124 Generalizzazione tra attori» Può succedere che attori presentino diverse e significative similitudini» E possibile raccogliere a fattor comune tale similitudini creando un attore padre ed esprimere gli altri attori in termini di estensione del primo» Rappresentato come la relazione di generalizzazione tra classi 23

125 Generalizzazione tra attori Venditore Studente Supervisore Studente full-time Studente part-time 24

126 Generalizzazione tra attori Inserimento Ordine Venditore Verifica Stato Ordine Annullamento Ordine Supervisore Generazione Report 25

127 Generalizzazione tra attori Inserimento Ordine Venditore Verifica Stato Ordine Annullamento Ordine Supervisore Generazione Report 26

128 Relazioni tra Use Case» Generalizzazione» Inclusione» Estensione» Realizzazione > Collaboration 27

129 Generalizzazione» Può capitare che diversi use case presentino somiglianze e condividano comportamento» E possibile utilizzare la generalizzazione per creare uno use case genitore (che contiene le somiglianze) ed estenderlo (modificando il comportamento o aggiungendo dei passi allo use case) mediante casi d uso figli» Rappresentata come la generalizzazione tra classi» L esecuzione degli use case fratelli è esclusiva 28

130 Generalizzazione Cliente Validazione Utente Check Password Scansione Retina 29