|
Wiki
UniCrema
Materie per semestre
Materie per anno
Materie per laurea
Help
|
|
Uni.IDS-10Marzo History
Hide minor edits - Show changes to output
Added lines 57-71:
!!!Relazioni tra casi d'uso
Casi d'uso e UML non c'entrano tra loro, ma fanno parte dello stesso standard definito nel 1999 dall'OMG; in particolare l'UML tiene conto anche del come vengono effettuate le attività, ma vedremo meglio nelle lezioni a venire.
In questo standard vengono definite tre tipi di relazioni: '''usa''', '''estende''' e '''generalizza'''. Vediamole una alla volta, utilizzando come sistema di esempio il solito bancomat.
Con la relazione '''usa''' (o ''include'') possiamo stabilire che una data sequenza di comportamenti (attività) è sottosequenza esatta di un'altra. Ad esempio:
%center%Attach:usa.jpg
La '''estende''' rappresenta una variante di un'altra sequenza, legando un caso eccezionale a un altro convenzionale. Nel nostro esempio l'attività "richiesta informazioni" ha una variante se tutto va bene e una se ho dei problemi:
%center%Attach:estende.jpg
L'estende quindi si può leggere come un "invece" e non un "fai sempre", dal momento che viene preso in considerazione solo se sono soddisfatte certe condizioni.\\
Per avere la garanzia che il nostro caso d'uso sia completo dobbiamo verificare di aver specificato ogni caso che rappresenta la negazione di una precondizione. Questa regolina è un aggancio formale a qualcosa che di formale non è, e mi mette a disposizione una tecnica automatica per verificare la correttezza della descrizione; ovviamente è un "di più" non richiesto.
Infine abbiamo la relazione '''generalizza''', che si utilizza quando un caso d'uso riassume e astrae un altro. Più formalmente, una relazione di generalizzazione implica che il caso d'uso figlio contenga tutti gli attributi, sequenze comportamentali e punti d'estensione definiti nel padre, e inoltre che partecipi a tutte le sue relazioni.
Changed lines 3-4 from:
to:
Changed lines 9-10 from:
Possiamo distinguere tra requisiti messi giù in modo '''formale''' e quelli messi in modo '''semi-formale'''. La parola ''formale'' è affascinante e prelude a meravigliose matematiche proprietà, ma la vedremo più tardi. to:
Possiamo distinguere tra requisiti messi giù in modo '''formale''' e quelli messi in modo '''semi-formale'''. La parola ''formale'' è affascinante e prelude a meravigliose matematiche proprietà, ma la vedremo più tardi. In ogni caso una volta terminata la loro stesura è possibile effettuarne un conteggio, o ancora meglio, una valutazione metrica delle varie tipologie; in questo modo sarà possibile fare previsioni di tempi e di costi. Changed lines 13-14 from:
Per la scrittura dei requisiti, non esiste uno standard industriale. Il ''control english'', il ''MoSCoW'' (must-should-may) e il ''grafo delle dipendenze'' sono ''good practices'', ma non hanno uno standard. Invece, per i casi d'uso l'OMG (Object Management Group, l'associazione che sta dietro a UML e a CORBA) ha prodotto uno standard. to:
Per la scrittura dei requisiti, non esiste uno standard industriale. Il ''control english'', il ''MoSCoW'' (must-should-could-would, di cui noi vediamo l'estratto must-should-may) e il ''grafo delle dipendenze'' sono ''good practices'', ma non hanno uno standard. Invece, per i casi d'uso l'OMG (Object Management Group, l'associazione che sta dietro a UML e a CORBA) ha prodotto uno standard. Changed lines 16-17 from:
I casi d'uso sono un'interazione tra attore esterno e sistema: l'attore interagisce con il sistema per ottenere un certo scopo. Riguardano quindi solo i requisiti funzionali. Una forma testuale di un caso d'uso potrebbe essere: la segretaria stampa la fattura. to:
I casi d'uso sono un'interazione tra attore esterno ai confini del sistema e il sistema stesso. Dato che l'attore interagisce con il sistema per ottenere un certo scopo, essi riguardano solo i requisiti funzionali. Una forma testuale di un caso d'uso potrebbe essere: la segretaria stampa la fattura. Changed lines 19-24 from:
L''''attore''', appena introdotto, non è semplicemente uno stakeholder. In realtà, un attore è un degli stakeholder, in particolare quelli che '''interagiscono''' con il sistema (vedi le [[categorie di Sommerville -> IDS-9Marzo]]).
L'attore si segna con un omino: Attach:IDSattore.png
Da tenere presente che attore può anche essere un altro sistema o un altro software: ciò che lo contraddistingue è che deve interagire con il nostro sistema, ed è esterno ad esso. to:
L''''attore''', appena introdotto, non è semplicemente uno stakeholder. In realtà, un attore è un sottoinsieme degli stakeholder, in particolare quelli che '''interagiscono''' con il sistema (vedi le [[categorie di Sommerville -> IDS-9Marzo]]); può quindi essere un utente, una classe di utenti, un ruolo o anche un altro sistema: ciò che lo contraddistingue è che deve interagire con il nostro sistema, ed è esterno ad esso.
L'attore si rappresenta con un simpatico omino: Attach:IDSattore.png Changed lines 39-40 from:
Un insieme di CdU è completo se specifica tutte le possibili interazioni del sistema. In pratica, definendo chi è dentro e chi è fuori dal sistema, definisce anche i confini del sistema stesso. Questa faccenda dei confini è importante anche dal punto di vista del contratto tra cliente e fornitore, perché serve per dire chiaramente che cosa uno deve sviluppare e che cosa invece no. to:
Un insieme di CdU è ''completo'' se specifica tutte le possibili interazioni del sistema. In pratica, definendo chi è dentro e chi è fuori dal sistema, definisce anche i confini del sistema stesso. Questa faccenda dei confini è importante anche dal punto di vista del contratto tra cliente e fornitore, perché serve per dire chiaramente che cosa uno deve sviluppare e che cosa invece no. Added lines 45-56:
Le attività descritte nel diagramma (quelle definite nelle ellissi) possono spesso essere scomposte in sottooperazioni fino a quando non arrivo a quelle elementari, ovvero non ulteriormente scomponibili. Facciamo un esempio semplicistico tanto per dare un'idea (siamo sempre nel sistema bancomat):
%center%Attach:sviluppoCdU.jpg
Il caso d'uso è generalmente corredato di uno '''schema''', nel quale tra le altre cose vanno riportati:
* le relazioni, ovvero dipendenze o altri tipi di collegamenti
* le precondizioni, ad esempio nel nostro sistema bancomat una potrebbe essere: "l'utente si autentica col PIN". In questo modo si può evitare di mettere l'ellisse corrispondente in ogni scenario
* scenari alternativi, dovuti a eventi eccezionali
* requisiti non funzionali, ad esempio "due utenti non possono collegarsi contemporaneamente allo stesso bancomat"
* punti aperti, cioè eventuali annotazioni e punti di discussione con utenti o committenti
E' molto importante che non vengano fatti esclusivamente i casi d'uso degli utenti, ma anche degli altri stakeholder diretti, e quindi di tutti i punti della struttura organizzativa a cui si interfaccerà il mio software. Tutto questo andrà fatto previo mappaggio degli attori con i ruoli che rivestono, e sempre tenendo conto delle normative vigenti imposte dai domain stakeholder. Insomma, nulla che un'analisi fatta come si deve non riesca ad ottenere.
Changed lines 28-29 from:
A noi quindi interessa sapere '''chi''' vuole fare '''cosa''' e '''in che modo''', ma non come è fatto dentro il sistema. to:
A noi quindi interessa sapere '''chi''' vuole fare '''cosa''' e '''perché''', ma non come è fatto dentro il sistema. Added lines 38-45:
!!!Insiemi di casi d'uso
Un insieme di CdU è completo se specifica tutte le possibili interazioni del sistema. In pratica, definendo chi è dentro e chi è fuori dal sistema, definisce anche i confini del sistema stesso. Questa faccenda dei confini è importante anche dal punto di vista del contratto tra cliente e fornitore, perché serve per dire chiaramente che cosa uno deve sviluppare e che cosa invece no.
!!!Schemi di casi d'uso
I casi d'uso hanno questa forma:
Attach:IDScasiduso.png
Added line 16:
Added lines 20-36:
Da tenere presente che attore può anche essere un altro sistema o un altro software: ciò che lo contraddistingue è che deve interagire con il nostro sistema, ed è esterno ad esso.
L''''attore primario''' è un attore che ha uno scopo preciso, il quale richiede l'assistenza del sistema. Nel caso di un Bancomat gli attori primarî possono essere l'utente o il cassiere che lo deve riempire.
L''''attore secondario''' è invece un attore di cui è il sistema stesso a richiedere l'intervento. Sempre nel caso del Bancomat, l'addetto all'assistenza è un attore secondario.
A noi quindi interessa sapere '''chi''' vuole fare '''cosa''' e '''in che modo''', ma non come è fatto dentro il sistema.
!!!Requisiti funzionali e casi d'uso
Non c'è sempre una corrispondenza 1:1 tra requisiti funzionali e casi d'uso. Prendiamo il caso d'uso di una segretaria che deve stampare la fattura. Esso consiste in diverse azioni, ad esempio compilarla, salvarla e poi stamparla. Queste sono rappresentate da diversi requisiti, ma hanno 1 solo scopo, e quindi un solo caso d'uso.
Nei requisiti non funzionali non si parla mai degli eventi eccezionali, e qui bisogna stare attenti: sono i comportamenti imprevisti che fanno litigare il committente con il produttore...
Una cosa che invece i casi d'uso e i requisiti hanno in comune è il '''glossario''', ovvero l'indice dei termini utilizzati con tanto di spiegazione. I termini devono essere '''uguali'''.
%warning%%white%Se all'esame il prof ci dà un glossario, noi '''dobbiamo usare quello''' e non inventarci nuove parole!
Added lines 1-21:
(:title Ingegneria del software - Appunti del 10 marzo:)
[[Torna alla pagina di Ingegneria Del Software -> Ingegneria Del Software]]
%titolo%''':: Ingegneria del software - Appunti del 10 marzo ::'''
!!Requisiti formali e semi-formali
Questi benedetti requisiti, che nella [[lezione scorsa -> IDS-9Marzo]] ci siamo dati tanta pena di raccogliere ed analizzare, dovranno trovare una loro forma per poter essere sfruttati.\\
Possiamo distinguere tra requisiti messi giù in modo '''formale''' e quelli messi in modo '''semi-formale'''. La parola ''formale'' è affascinante e prelude a meravigliose matematiche proprietà, ma la vedremo più tardi.
I '''casi d'uso''' che vedremo ora sono un buon passaggio rispetto ai meri requisiti semi-formali, perché sono visuali e diagrammatici e quindi potenzialmente più semplici da comprendere. Hanno però qualche limite, ad esempio l'impossibilità di rappresentare requisiti non funzionali oppure indicazioni temporali.
Per la scrittura dei requisiti, non esiste uno standard industriale. Il ''control english'', il ''MoSCoW'' (must-should-may) e il ''grafo delle dipendenze'' sono ''good practices'', ma non hanno uno standard. Invece, per i casi d'uso l'OMG (Object Management Group, l'associazione che sta dietro a UML e a CORBA) ha prodotto uno standard.
!!I casi d'uso
I casi d'uso sono un'interazione tra attore esterno e sistema: l'attore interagisce con il sistema per ottenere un certo scopo. Riguardano quindi solo i requisiti funzionali. Una forma testuale di un caso d'uso potrebbe essere: la segretaria stampa la fattura.
L''''attore''', appena introdotto, non è semplicemente uno stakeholder. In realtà, un attore è un degli stakeholder, in particolare quelli che '''interagiscono''' con il sistema (vedi le [[categorie di Sommerville -> IDS-9Marzo]]).
L'attore si segna con un omino: Attach:IDSattore.png
----
[[Torna alla pagina di Ingegneria Del Software -> Ingegneria Del Software]]
|
|
