I requisiti funzionali e i casi d'uso sono una descrizione informale del comportamento di un sistema. Normalmente sono sufficienti, ma talvolta è utile una descrizione più dettagliata o precisa del comportamento del sistema. I contratti delle operazioni usano pre-condizioni e post-condizioni per descrivere nel dettaglio i cambiamenti agli oggetti in un modello di dominio, come risultato di un'operazione di sistema.
I contratti posso essere considerati parte del Modello dei casi d'uso, poiché forniscono maggiori dettagli dell'analisi sull'effetto delle operazioni di sistema implicate dai casi d'uso.
Input per i contratti:
- modello di dominio
- SSD
A loro volta i contratti possono fare da input per la progettazione a oggetti.
Esempio di contratto...
| Operazione: | enterItem(itemID : ItemID, quantity : integer) |
|---|---|
| Riferimenti: | casi d'uso: Elabora Vendita |
| Pre-condizioni: | è in corso una vendita s |
| Post-condizioni: | - è stata creata un'istanza sli di SalesLineItem |
| - sli è stata associata con la Sale corrente s | |
| - sli è stata associata con una ProductDescription, in base alla corrispondenza con itemID | |
| - sli.quantity è diventata quantity |
| Operazione: | Nome e parametri dell'operazione di sistema. |
|---|---|
| Riferimenti: | Casi d'uso in cui si può verificare l'operazione di sistema. |
| Pre-condizioni: | Ipotesi significative sullo stato del sistema e degli oggetti nel modello di dominio. Le ipotesi non sono banali. |
| Post-condizioni: | Descrive i cambiamenti di stato degli oggetti nel modello di dominio dopo il completamente dell'operazione. |
Le operazioni di sistema sono operazioni che il sistema, considerato come un componente a scatola nera, offre "pubblicamente". Gli SSD mostrano eventi di sistema, ovvero messaggi di input o output relativi al sistema. Un evento di sistema implica che il sistema definisca un'operazione di sistema per gestire quell'evento. L'intero insieme delle operazioni di sistema, tra tutti i casi d'uso, definisce l'interfaccia di sistema pubblica, considerando il sistema come un singolo componente. Il sistema in UML può essere genericamente rappresentato con un nome del tipo System.
Le post-condizioni...
Descrivono cambiamenti nello stato degli oggetti nel modello di dominio. I cambiamenti di stato comprendono:
- oggetti (concettuali) creati
- collegamenti formati o rotti
- attributi modificati
Le post-condizioni non sono azioni da eseguire nel corso dell'operazione, si tratta piuttosto di osservazioni sugli oggetti del modello di dominio come risultato al termine di un'operazione.
Per quanto riguarda un collegamento spezzato: si consideri un'operazione che consente l'eliminazione di una riga di vendita per un articolo. La post-condizione potrebbe essere "è stato rotto il collegamento tra la SalesLineItem selezionata e la Sale corrente".
Le post-condizioni di cancellazione (eliminazione) di oggetto sono le più rare, poiché solitamente non si ha interesse nell'attuare in modo esplicito la distruzione di qualcosa nel mondo reale. Per esempio: in molti paesi, dopo che una persona ha dichiarato il fallimento e sono trascorsi sette o dieci anni, tutta la documentazione relativa al fallimento deve essere distrutta per legge. Si noti che questo è un punto di vista concettuale, non di implementazione. Non si tratta di istruzioni su come liberare le memoria del computer occupate da oggetti software.
Le post-condizioni sono correlate al modello di dominio:
- quali oggetti si possono creare? Quelli corrispondenti al modello di dominio;
- quali collegamenti si possono formare? Quelli corrispondenti alle associazioni del modello di dominio, e così via.
Motivazione per le post-condizioni...
Un contratto è un'ottimo strumento nell'analisi de requisiti o nell'analisi orientata agli oggetti per descrivere in modo molto dettagliato i cambiamenti richiesti dall'esecuzione di un'operazione di sistema (in termini di oggetti del modello di dominio), senza dover descrivere come devono essere ottenuti questi cambiamenti.
In altre parole, la progettazione si può rimandare e ci si può concentrare sull'analisi di che cosa deve accadere e non è importante come deve accadere.
Come scrivere una post-condizione...
Le post-condizioni vanno espresse sempre con un verbo al passato, per sottolineare che si tratta di osservazioni su dei cambiamenti di stato provocati da un'operazione, e non di un'azione che deve accadere. Esempio:
- è stata creata una SalesLineItema (migliore)
- creare una SalesLineItem, oppure viene creata una SalesLineItem (sconsigliato)
Analogia per le post-condizioni...
Si pensi alle post-condizione nel modo seguente.
Il sistema e i suoi oggetti sono mostrati sul palcoscenico di un teatro.
- Prima dell'operazione di sistema, si fa una foto al palcoscenico
- Si chiude il sipario, si applica un'operazione di sistema
- Si apre il sipario e si fa una seconda foto
Le post-condizioni sono rappresentate da questa seconda foto: sono cambiate delle cose e non è chiaro il come.
Si pensi ad esse come la migliore ipotesi iniziale, consapevoli che non possono essere complete e che raramente sono perfette.
Esempi per l'operazione enerItem...
Tale operazione viene eseguita quando una vendita è già cominciata e viene eseguita una volta per ciascun articolo acquistato da un cliente. Nel caso d'uso è scritto che il cassiere richiede questa operazione inserendo il codice identificativo e la quantità dell'articolo acquistato. Le post-condizioni devono descrivere l'effetto complessivo causato da una singola esecuzione dell'operazione in termini di cambiamento di stato degli oggetti di dominio.
Creazione o cancellazione di oggetti...
Dopo che il cassiere ha inserito un codice identificativo e la quantità di un articolo, quali nuovi oggetti devono essere stati creati? Un SalesLineItem. Pertanto:
- è stata creata un'istanza sli di SalesLineItem
Si noti che all'istanza è stato assegnato un nome, questo nome consente di fare riferimento alla nuova istanza nelle altre post-condizioni.
Formazione o rottura di collegamenti...
Dopo che il cassiere ha inserito l'itemID e la quantity di un articolo, quali collegamenti tra oggetti nuovo o esistenti devono essere stati formati o spezzati? La nuova SalesLineItem deve essere stata collegata alla sua Sale, e collegata anche ad una sua ProductDescription. Pertanto:
- sli è stata associata con la Sale corrente s
- sli è stata associata con un ProductDescription, in base alla corrispondenza con itemID
Modifica di attributi...
Dopo che il cassiere ha inserito l'itemID e la quantity di un articolo, quali attributi di oggetti nuovi o già esistenti devono essere stati modificati? La quantity della SalesLineItem creata deve essere diventata pari al parametro quantity. Pertanto:
- sli.quantity è diventata quantity
Esempio: pre-condizioni per enterItem...
La sezione delle pre-condizioni di un contratto di un'operazione di sistema descrive ipotesi significative sullo stato del sistema prima dell'esecuzione dell'operazione. In pratica, questa sezione può essere scritta come una descrizione sintetica dello stato di avanzamento del caso d'uso. Per esempio, l'operazione enterItem viene eseguita quando una vendita è già cominciata, ma non è ancora conclusa. Nell'esecuzione del caso d'uso, è stata già eseguita l'operazione makeNewSale e l'operazione enterItem potrebbe essere già stata eseguita (zero o più volte). Lo stato di avanzamento del caso d'uso si può riassumente con la pre-condizione "è in corso una vendita".
Nelle pre-condizioni di un'operazione è utile indicare anche gli oggetti rilevanti a quel punto dell'esecuzione del caso d'uso, e in particolare quelli che si vogliono citare nelle post-condizioni. Per esempio, una delle post-condizioni di enterItem è "sli è stata associata con la vendita corrente s", e per questo è utile citare la vendita corrente s nelle pre-condizioni. Dunque la pre-condizione può essere scritta come "è in corso una vendita s".
Adottare un punto di vista concettuale e della conoscenza...
Una prospettiva della conoscenza da parte del sistema in discussione, ovvero ragionare in termini di oggetti, collegamenti e attributi nel dominio di interesse che il sistema ha necessità di conoscere e ricordare.
Secondo la prospettiva di conoscenza, una post-condizione "è stata creata un'istanza X" va interpretata come "è iniziata la conoscenza da parte del sistema di X". Si consideri un sistema per l'anagrafe di un comune, e un'operazione per la registrazione di un nuovo bambino, che è un'istanza di una classe concettuale Persona. Quando viene richiesta questa operazione, il bambino esiste già (è nato), ma il sistema non lo sa ancora. Nelle post-condizioni di questa operazione viene scritta la post-condizione "è stata creata una nuova istanza di Persona", non per indicare che il bambino è nato durante l'esecuzione dell'operazione di sistema, ma per specificare che l'esecuzione dell'operazione ha data inizio alla conoscenza da parte del sistema del bambino.
Un modello di dominio, come abbiamo detto nelle argomentazioni ad esso dedicate, esprime concetti che riguardano il sistema in maniera diretta, concetti che il sistema ha necessità di conoscere e con cui interagisce, i concetti non utili direttamente al sistema sono utili per una migliore comprensione del dominio. Tuttavia in altri modelli potrebbero rappresentare solo gli elementi del dominio necessari in maniera diretta al sistema (vedi altri modelli di dominio).
I contratti, come abbiamo visto, si scrivono tenendo conto degli oggetti che il sistema deve ricordare.