Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca mario.vacca1@istruzione.it
1. 2. 2.1 Il linguaggio dei casi d uso 2.2 Esempi 3. Bibliografia Sommario
1. 2. 2.1 Il linguaggio dei casi d uso 2.2 Caratteristiche dei casi d uso 2.3 Esempi 3. Bibliografia Sommario
Generalità La tecnica dei casi d uso è stata definita da Ivar Jacobson (1992) come evoluzione dei classici storyboards, e fa parte ora di UML. I casi d uso rappresentano i servizi (funzioni) che un software fornisce ad un utente. storie interazione tra un utente ed il software. I servizi possono essere rappresentati a diversi livelli di dettaglio e di aggregazione. Il software è visto dalla prospettiva dell utente che gli chiede un servizio.
Generalità I casi d uso rappresentano cosa fa un software, non entrano in come tecnicamente lo fa. I casi d uso possono essere rappresentati con diagrammi (UML), o descritti con linguaggio naturale.
1. 2. 2.1 Il linguaggio dei casi d uso 2.2 Caratteristiche dei casi d uso 2.3 Esempi 3. Bibliografia Sommario
Attore Un attore definisce un insieme coerente di ruoli
Caso d uso Uno use case rappresenta una funzionalità completa così come viene percepita da un attore. Definisce il comportamento di un sistema o di un altra entità senza rivelarne la struttura interna. Un caso d uso è un tipo di classificatore che rappresenta un unità coerente di funzionalità fornita da una specifica entità (sistema, sottosistema, classe) e descritta sia dalla serie di messaggi scambiati tra l entità stessa e un altra interagente esterna (attore), sia dalla sequenza di azioni svolte.
Caso d uso Uno use case rappresenta una funzionalità completa così come viene percepita da un attore. Definisce il comportamento di un sistema o di un altra entità senza rivelarne la struttura interna. Un caso d uso è un tipo di classificatore che rappresenta un unità coerente di funzionalità fornita da una specifica entità (sistema, sottosistema, classe) e descritta sia dalla serie di messaggi scambiati tra l entità stessa e un altra interagente esterna (attore), sia dalla sequenza di azioni svolte.
Relazione di associazione tra attori e casi d uso Esempio L interazione tra l attore e il caso d uso (e, indirettamente, tra l attore e il sistema che implementa il caso d uso) è rappresentata mediante una linea che collega i due elementi (associazione). Figura: Il docente registra il voto
System Boundary Actor Rappresenta attore o un
Attori primari e secondari Un attore primario attiva (o inizia) il caso d uso. Un attore secondario ha un ruolo marginale poich e partecipa al caso d uso solamente come sorgente di dati in input oppure come ricevitore di dati in output. L attore secondario ha quindi un ruolo di supporto al caso d uso, il quale è concepito per fornire una funzionalità il cui valore è percepito soprattutto dall attore primario. Un database esterno al sistema è un esempio tipico di attore secondario che riceve o fornisce dati ma che non utilizza altrimenti il sistema.
Relazione di generalizzazione tra attori Esempi Un attore A è generalizzazione di un attore B quando B è visto come un caso particolare di A.
Relazione di generalizzazione tra casi d uso La generalizzazione si applica sia ad attori sia a use case. Uno use case A è generalizzazione di uno use case B quando B è visto come un caso particolare di A.
Extend La relazione extend tra use case è rappresentata da una freccia etichettata con hhextend ii dallo use case che definisce l estensione allo use case base. La relazione extend tra uno use case A ed uno use case B indica che ogni istanza di B, in condizioni particolari, viene esteso con le funzionalit`di una istanza di A.
Una relazione extend tra uno Use Case A ed uno Use Case B indica che ogni istanza dello Use Case B viene estesa (con riferimento a condizioni particolari specificate nell estensione) con le funzionalità di un istanza di Use Case A. Il caso d uso base definisce (eventualmente) il punto di estensione e il caso d uso di estensione definisce la condizione di attivazione
Include Una relazione d inclusione tra Use Case è rappresentata da una freccia tratteggiata tra lo Use Case che include e quello che è incluso. La freccia è etichettata con include (stereotipo hhincludeii). Viene usata quando c è una funzionalità comune tra più Use Case ed è quindi conveniente metterla a fattor comune. può essere utilizzato per modellare componenti riutilizzati/riutilizzabili Lo use case incluso è incondizionatamente incorporato nell esecuzione dello use case che include. La responsabilità della decisione su quando e perchè usare lo use case incluso è dello usa case che include.
Include Una relazione d inclusione da uno use case A ad uno use case B, indica che ogni istanza dello use case A includerà anche il comportamento specificato per lo use case B. In altre parole, qualche funzionalità di A richiede di servirsi di qualche funzionalità di B.
Include
Una relazione d inclusione tra casi d uso mette a fattor comune tra di essi attività ricorrenti e condivise. Si utilizza per evitare il ripetere della esplicitazione di questi casi d uso di servizio in diagrammi complessi.
Inclusione e Estensione: similarità entrambe fattorizzano comportamenti comuni a più use case entrambe aumentano il comportamento dello use case di base
Inclusione e Estensione: differenze L intento è differente nell estensione l attore esegue sia lo use case base che tutte le sue estensioni (se attivabili). nell inclusione l attore esegue sia lo use case base che tutte le sue inclusioni. Nell inclusione (spesso) non c è un attore associato con lo use case comune (incluso)
Inclusione e Estensione: uso Usare: extend quando si stanno descrivendo variazioni dalla funzionalità standard o condizioni particolari (es. di errore) include quando si sta ripetendo la stessa funzionalità in più use case separati e si vogliono quindi evitare queste ripetizioni
Bibliografia 1. 2. 2.1 Il linguaggio dei casi d uso 2.2 Esempi 3. Bibliografia Sommario
Bibliografia Bibliografia Riferimenti bibliografici - Generali 1. R. Pressman Ingegneria del software Mc Graw Hill Italia, 5a edizione, 2007, capitolo 9. 2. P. Jalote A Concise Introduction to Software Engineering Springer, 2008, capitolo 3.
Bibliografia Bibliografia Riferimenti bibliografici - Specifici 1. S. Bennett, J. Skelton, K. Lunn, Introduzione a UML, McGraw Hill, 2002. 2. M. Fowler, UML Distilled Guida rapida al linguaggio di modellazione standard, Addison Wesley, 2004.
Bibliografia Bibliografia Riferimenti bibliografici - Siti utili 1. StarUML http://staruml.sourceforge.net/en/ 2. ArgoUML http://argouml.tigris.org/