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

[email protected]


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


Casi d’uso

Casi d’uso

Sommario

1. Casi d’uso


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

3. Bibliografia


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.


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.


Diagrammi dei casi d’uso

Casi d’uso

Sommario

1. Casi d’uso


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

3. Bibliografia



Attore

Un attore definisce un insieme coerente di ruoli



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.



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



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 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.



Relazione di generalizzazione tra attori

Esempi

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



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.



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.



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



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.



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.



Include



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.



Inclusione e Estensione: similarita

I entrambe fattorizzano comportamenti comuni a piu use case

I entrambe aumentano il comportamento dello use case di base



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)



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


Bibliografia

Casi d’uso

Sommario

1. Casi d’uso


2.1 Il linguaggio dei casi d’uso2.2 Esempi

3. Bibliografia


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.


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.


Bibliografia

Bibliografia

Riferimenti bibliografici - Siti utili

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

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

http://staruml.sourceforge.net/en/

http://argouml.tigris.org/

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

Documents

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