risorse | jackson

Software Specifications & Requirements

Ho da poco riletto questo splendido libro^[1]. Essendo strutturato come un'ipertesto, ho tracciato una sorta di mappa per orientarmi meglio tra le varie tematiche presentate:

Descrizioni

Esistono diversi tipi di descrizioni, in particolare:

designations

rappresentano i phenomena di interesse; li descrivono con linguaggio informale e ne attribuiscono un nome univoco con il quale denotarli. Ad esempio: «m è la madre genetica di x ≈ Madre(m,x)» è la descrizione (designazione) della relazione essere-madre-di.

definitions

introducono una definizione formale che può essere utilizzata in altre descrizioni. Ad esempio: «Figlio(x,y) ≡ Madre(y,x) ∨ Padre(y,x)»;

refutable descriptions

sono affermazioni riguardanti uno o più phenomena di un dominio, che potrebbero in linea di principio essere sia vere, sia false; assumono la forma di predicati (predicate logic). Ad esempio: «∀ x, y | Madre(x,y) ⇒ ¬Madre(y,x)».

rough sketches

sono descrizioni informali, il cui scopo è fissare un concetto, riservandosi di formalizzarlo successivamente; ad esempio: «ogni individuo appartiene ad almeno una famiglia».

Le designations costituiscono una sorta di mappa dell'application domain; è dunque fondamentale che esse catturino gli aspetti caratteristici in modo chiaro e univoco, per consentire la costruzione di descrizioni chiare e incontrovertibili. È altrettanto importante che l'insieme dei phenomena designati sia il più piccolo possibile: le designations devono stabilire un narrow bridge tra il problem context e la sua descrizione. È inutile introdurre una designation per il concetto di Fratello se già sono disponibili quelle per Maschio, Padre e Madre: «Fratello(x,y) ≡ Maschio(x) ∧ (∃p | Padre(p,x) ∧ Padre(p,y)) ∧ (∃m | Madre(m,x) ∧ Madre(m,y))».

Le descrizioni sono caratterizzate da:

• un'intenzione o mood, che può essere “indicativa”, quando si asserisce una verità, oppure “ottativa” (il modo della speranza e della potenzialità), quando si esprime un desiderata. Le descrizioni indicative si riferiscono al application domain, le seconde a machine. È importante, quando si produce una nuova descrizione, riflettere sulla sua intenzionalità, evitando di mescolare i due mood in una stessa descrizione;
• un'estensione o span: rappresenta l'insieme di phenomena cui la descrizione si riferisce; per esempio, la designation «x è cittadino di y ≈ Cittadino(x,y)» è applicabile ai cittadini di qualunque paese, mentre la definition «Italiano(x) ≡ Cittadino(x,Italia)» si estende ai soli cittadini italiani;
• uno ambito o scope: è la parte di dominio cui la descrizione di riferisce, che dipende dall'insieme delle designation citate nella descrizione.

Requisiti e specifiche

I requisiti (requirements) definiscono il problema, asserendo fatti relativi a phenomena dell'application domain; l'implementazione (o program) definisce le modalità operative della macchina, ed è per tale motivo di pertinenza del dominio machine; le specifiche (specifications) definiscono l'interfaccia tra il dominio applicativo e la macchina, e riguardano gli shared phenomena condivisi tra application domain e machine.

In modo più formale:

C, P → S (l'esecuzione del programma P sul computer C soddisfano la specifica S);

D, S → R (le proprietà di dominio D, congiunte con le specifiche S – effetto dell'esecuzione di P su C –, soddisfano i requisiti R).

È interessante soffermarsi sull'esempio citato dall'autore, riguardante un incidente aereo avvenuto a causa del mancato azionamento del sistema di retro-spinta durante un atterraggio in acquaplaning (l'areoplano finì fuori pista); i requisiti erano:

• WHEEL-PULSES-ON ⇔ WHEEL-TURNING;
• WHEEL-TURNING ⇔ MOVING-ON-RUNWAY.

WHEEL-TURNING e MOVING-ON-RUNWAY sono phenomena di application domain, mentre WHEEL-PULSES-ON è uno shared phenomena di application domain e machine.

Le specifiche per l'azionamento della retro-spinta erano:

• REVERSE-ENABLED ⇔ WHEEL-PULSES-ON

REVERSE-ENABLED è lo shared phenomena che il sistema utilizza per comunicare al application domain per attivare il sistema di retro-spinta.

L'incidente è stato causato dall'errata interpretazione del dominio del problema, in particolare del secondo requisito, che non cattura la reale condizione di rullaggio: così come specificato infatti, in caso di acquaplaning si deve giungere alla conclusione che dato che le ruote non girano, l'areoplano non si trova sulla pista.

L'analisi va quindi corretta, in primis modificando la specifica in:

• REVERSE-ENABLED ⇔ MOVING-ON-RUNWAY,

quindi individuare un nuovo shared phenomena che possa indicare a machine la condizione di MOVING-ON-RUNWAY, e modificare il programma P in modo da rispettare la nuova specifica.

Analisi

Le principali fasi dell'analisi comprendono:

problem → application domain + machine

Il primo passo che il buon analista deve compiere è quello di scindere il problem context nelle due componenti che lo caratterizzano, ovvero l'application domain, che rappresenta l'ambiente nel quale il sistema in fase di definizione andrà ad operare, e la machine, che rappresenta il sistema vero e proprio. Deve sussistere una netta distinzione tra ciò che è di pertinenza del problema, ovvero cosa il sistema deve fare per risolvere il problema – what – e ciò che invece compete alla macchina, ovvero come il sistema opera per risolvere il problema – how.

application domain → domains

In funzione della complessità del dominio applicativo, può essere conveniente procedere ad un partizionamento in sotto-domini, badando di ottenere sotto-domini coesi, cioè relativi a phenomena di natura simile, e fortemente disaccoppiati, cioè con pochi shared phenomena in comune con i sotto-domini connessi.

Organizzare i sotto-domini in strutture gerarchiche è spesso sintomo di eccessiva semplificazione: più aderenti alla realtà sono strutture a grafo, mono- – o più spesso – multi-strato.

Questa fase culmina con la realizzazione del context diagram, un diagramma che rappresenta il problem context come insieme di domini interdipendenti.

domains → domain characteristics + domain interactions

Una volta individuati i sotto-domini applicativi, si procede ad un'analisi di massima della loro natura, prendendo in considerazione aspetti quali:

• dinamicità: il dominio è statico o dinamico? Nel secondo caso, è inerte, reattivo o attivo?
• dimensionalità: il dominio è mono- o multi-dimensionale?
• concretezza: il dominio è tangibile? Se sì, potrebbe essere soggetto a qualche vincolo di natura fisica;
• formalità: se il dominio è informale, è da considerarsi illimitato, in quanto non è possibile descriverlo in maniera esaustiva.

Un importante aspetto da considerare sono le tipologie di interazioni tra domini, in particolare in presenza di latenze o altre inconsistenze che non permettono di individuare uno shared phenomena comune attraverso il quale modellare l'interazione. In questo caso si ricorre a un dominio ausiliario di disaccoppiamento, il connection-domain. Un esempio in tal senso è costituito dall'invio e dalla successiva ricezione di una missiva: i due eventi sono sufficientemente distanti nel tempo da non essere vissuti dal mittente e dal destinatario come due aspetti di un unico evento; in secondo luogo non è nemmeno certo che ad un invio segua una ricezione, per esempio perché la lettera potrebbe venir smarrita. Si introduce allora un connection domain che rappresenta un ufficio postale: l'invio diventa uno shared phenomena tra il dominio del mittente ed il connection domain, mentre la ricezione diventa uno shared phenomena tra il connection domain e il dominio del destinatario

domain characteristics + domain interactions → problem frame

Note le caratteristiche e le dipendenze tra i sotto-domini del problema, si cerca di stabilire una corrispondenza con uno dei problem frame noti, nella speranza di poter mettere in atto le strategie risolutive più adeguate per il tipo di problema. È utile a questo punto tracciare il frame diagram, che è un context diagram arricchito delle relazioni esistenti tra i domini, oltre all'evidenziazione del dominio machine: questo permette di identificare la struttura del problema e consente di valutarne la somiglianza con gli schemi noti.

Per valutare il grado di compatibilità del frame diagram con un problem frame, bisogna tener conto di:

• completezza: ogni sotto-dominio del frame diagram dev'essere associato ad una componente del problem frame;
• separabilità: ogni sotto-dominio del frame diagram deve essere associato ad una sola componente del problem frame;
• compatibilità: i sotto-domini del frame diagram devono avere caratteristiche simili alle componenti del problem frame alle quali sono stati associati;
• uniformità: i sotto-domini del frame diagram devono essere equamente distribuiti tra quelli del problem frame.

problem frame → method

Se è stato individuato un problem frame compatibile, si può procedere alla risoluzione del problema originale applicando il metodo risolutivo – method – associato.

Alcune tra le caratteristiche di un «buon» metodo sono:

• dispassionate methodology: quanto è disinteressato colui che lo promuove?
• close fitting frame: più specifico è il problem frame, più è probabile che il metodo sia efficace;
• frame exploitation: il metodo sfrutta a fondo le caratteristiche intrinseche del problem frame?
• deferred invention: più è procrastinato il ricorso alla creatività, meglio è;
• beneficient difficulty: sono esplicitate le difficoltà e i punti deboli del metodo?

Altro

Modellazione del tempo

Il fluire del tempo è scandito da eventi, separati tra loro da intervalli, ovvero periodi di tempo durante i quali nulla accade (cfr. events and intervals).

Influsso dell'implementazione (implementation bias)

L'implementazione non deve inquinare la descrizione del problema, ovvero ci dev'essere una netta distinzione tra ciò che è specification e ciò che è implementazione. La descrizione del problema dovrebbe essere fatta nell'ipotesi di poter disporre di qualunque tecnologia necessaria, reale o immaginaria, così da procrastinare alla fase di implementazione le scelte tecniche.

Riferimenti

1. Jackson, M. Software Specifications & Requirements. Addison-Wesley Professional, 1995.
2. "Problem frames approach". Wikipedia. <http://en.wikipedia.org/wiki/Problem_Frames_Approach>. Visitato il 16 Dicembre 2011.

Pagina modificata il 03/01/2012