Corso di Ingegneria del Software a.a. 2009/2010 Casi...

Post on 18-Feb-2019

218 views 0 download

Transcript of Corso di Ingegneria del Software a.a. 2009/2010 Casi...

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Corso di Ingegneria del Softwarea.a. 2009/2010

Casi d’uso

Mario Vacca

mario.vacca1@istruzione.it

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Casi d’uso

Casi d’uso

Sommario

1. Casi d’uso

2. Diagrammi dei casi d’uso

2.1 Il linguaggio dei casi d’uso2.2 Esempi

3. Bibliografia

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Casi d’uso

Casi d’uso

Sommario

1. Casi d’uso

2. Diagrammi dei casi d’uso

2.1 Il linguaggio dei casi d’uso2.2 Caratteristiche dei casi d’uso2.3 Esempi

3. Bibliografia

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Casi d’uso

Generalita

La tecnica dei casi d’uso e stata definita da Ivar Jacobson (1992) comeevoluzione dei classici storyboards, e fa parte ora di UML.I casi d’uso rappresentano i servizi (funzioni) che un software fornisce adun utente. storie interazione tra un utente ed il software.I servizi possono essere rappresentati a diversi livelli di dettaglio e diaggregazione.Il software e visto dalla prospettiva dell’utente che gli chiede un servizio.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Casi d’uso

Generalita

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 descritticon linguaggio naturale.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Casi d’uso

Sommario

1. Casi d’uso

2. Diagrammi dei casi d’uso

2.1 Il linguaggio dei casi d’uso2.2 Caratteristiche dei casi d’uso2.3 Esempi

3. Bibliografia

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Attore

Un attore definisce un insieme coerente di ruoli

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Caso d’uso

Uno use case rappresenta una funzionalita completa cosı come vienepercepita da un attore.

Definisce il comportamento di un sistema o di un’altra entita senza rivelarnela struttura interna.Un caso d’uso e un tipo di classificatore che rappresenta un’unita coer-ente di funzionalita fornita da una specifica entita (sistema, sottosistema,classe) e descritta sia dalla serie di messaggi scambiati tra l’entita stessae un’altra interagente esterna (attore), sia dalla sequenza di azioni svolte.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Caso d’uso

Uno use case rappresenta una funzionalita completa cosı come vienepercepita da un attore.

Definisce il comportamento di un sistema o di un’altra entita senza rivelarnela struttura interna.Un caso d’uso e un tipo di classificatore che rappresenta un’unita coer-ente di funzionalita fornita da una specifica entita (sistema, sottosistema,classe) e descritta sia dalla serie di messaggi scambiati tra l’entita stessae un’altra interagente esterna (attore), sia dalla sequenza di azioni svolte.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

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 ilsistema che implementa il caso d’uso) e rappresentata mediante una lineache collega i due elementi (associazione).

Figura: Il docente registra il voto

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

System Boundary

Actor Rappresenta attore o un

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

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 casod’uso solamente come sorgente di dati in input oppure come ricevitore didati in output.L’attore secondario ha quindi un ruolo di supporto al caso d’uso, il quale econcepito per fornire una funzionalita il cui valore e percepito soprattuttodall’attore primario.Un database esterno al sistema e un esempio tipico di attore secondarioche riceve o fornisce dati ma che non utilizza altrimenti il sistema.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Relazione di generalizzazione tra attori

Esempi

Un attore A e generalizzazione di un attore B quando B e visto come uncaso particolare di A.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Relazione di generalizzazione tra casi d’uso

La generalizzazione si applica sia ad attori sia a use case. Uno use caseA e generalizzazione di uno use case B quando B e visto come un casoparticolare di A.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Extend

La relazione extend tra use case e rappresentata da una freccia etichettatacon hhextendii 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 ogniistanza di B, in condizioni particolari, viene esteso con le funzionalitdi unaistanza di A.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

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 funzionalita

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

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Include

Una relazione d’inclusione tra Use Case e rappresentata da una frecciatratteggiata tra lo Use Case che include e quello che e incluso.La freccia e etichettata con “include” (stereotipo hhincludeii).

Viene usata quando c’e una funzionalita comune tra piu Use Case ed equindi conveniente metterla a fattor comune.puo essere utilizzato per modellare componenti riutilizzati/riutilizzabiliLo use case incluso e incondizionatamente incorporato nell’esecuzione dellouse case che include.La responsabilita della decisione su quando e perchE usare lo use caseincluso e dello usa case che include.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Include

Una relazione d’inclusione da uno use case A ad uno use case B, indica cheogni istanza dello use case A includera anche il comportamento specificatoper lo use case B. In altre parole, qualche funzionalita di A richiede diservirsi di qualche funzionalita di B.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Include

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Una relazione d’inclusione tra casi d’uso mette a fattor comune tra di essiattivita ricorrenti e condivise.Si utilizza per evitare il ripetere della esplicitazione di questi casi d’uso di“servizio” in diagrammi complessi.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Inclusione e Estensione: similarita

I entrambe fattorizzano comportamenti comuni a piu use case

I entrambe aumentano il comportamento dello use case di base

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Inclusione e Estensione: differenze

L’intento e differente

I nell’estensione l’attore esegue sia lo use case base che tutte le sueestensioni (se attivabili).

I nell’inclusione l’attore esegue sia lo use case base che tutte le sueinclusioni.

Nell’inclusione (spesso) non c’e un attore associato con lo use case comune(incluso)

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Diagrammi dei casi d’uso

Inclusione e Estensione: uso

Usare:

I extend quando si stanno descrivendo variazioni dalla funzionalitastandard o condizioni particolari (es. di errore)

I include quando si sta ripetendo la stessa funzionalita in piu use caseseparati e si vogliono quindi evitare queste ripetizioni

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Bibliografia

Casi d’uso

Sommario

1. Casi d’uso

2. Diagrammi dei casi d’uso

2.1 Il linguaggio dei casi d’uso2.2 Esempi

3. Bibliografia

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Bibliografia

Bibliografia

Riferimenti bibliografici - Generali

1. R. Pressman “Ingegneria del software” Mc Graw Hill Italia, 5aedizione, 2007, capitolo 9.

2. P. Jalote “A Concise Introduction to Software Engineering”Springer, 2008, capitolo 3.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Bibliografia

Bibliografia

Riferimenti bibliografici - Specifici

1. S. Bennett, J. Skelton, K. Lunn, “Introduzione a UML”, McGrawHill, 2002.

2. M. Fowler, “UML Distilled Guida rapida al linguaggio dimodellazione standard”, Addison Wesley, 2004.

Corso di Ingegneria del Software a.a. 2009/2010 Casi d’uso

Bibliografia

Bibliografia

Riferimenti bibliografici - Siti utili

1. StarUMLhttp://staruml.sourceforge.net/en/

2. ArgoUMLhttp://argouml.tigris.org/