La descrizione

L’attività centrale della progettazione del software è la descrizione (che può essere definita come un particolare modo di designare una cosa o un individuo). Un particolare tipo di descrizione è la definizione (determinazione dell’esatto valore di un concetto), che deve essere la base di ogni altra descrizione. A differenza della definizione, la descrizione non fa ricorso a una costante individuale appartenente al linguaggio perché funga da nome per la cosa che si vuol prendere in considerazione, ma fa riferimento a una proprietà di cui gode la cosa in questione.

I programmi sono descrizioni delle macchine; i requisiti sono descrizioni del dominio dell’applicazione e del problema da risolvere, mentre le specifiche sono le descrizioni dell’interfaccia tra macchina e dominio dell’applicazione.

Il progettista software ha quindi bisogno di controllare le tecniche di descrizione, in modo da capire quando una particolare descrizione è adatta per un particolare scopo. La descrizione è il mezzo di pensiero più esterno e visibile.

Nel corso del progetto VAMP numerosi sono stati gli sforzi per costruire una base di ragionamento e una terminologia comune, che consentisse una comunicazione più rapida e precisa tra i diversi membri dello staff. Per far questo è stato necessario adottare diverse tecniche di descrizione. Il risultato di questo lavoro è riportato nei Capitoli 2 e 3.

Di seguito, dopo una breve digressione sui linguaggi per la descrizione, sono presentati alcuni criteri per giungere ad una descrizione soddisfacente del dominio dell’applicazione e del problema, ed è descritta quella particolare tecnica di descrizione che è la modellazione.

I linguaggi di descrizione

Il linguaggio di descrizione più utilizzato è, soprattutto nelle prime fasi dello sviluppo del software, il linguaggio naturale, scritto e parlato. Nel corso del progetto si è fatto un ampio uso del linguaggio scritto: si è ritenuta la forma scritta come il miglior mezzo di comunicazione con la committenza, poiché ciò consente di eliminare le ambiguità e di permettere di ragionare meglio sulle idee.

Nelle fasi successive entrano in campo altri linguaggi. Per un’analisi approfondita del sistema software si è fatto uso del linguaggio di modellazione UML, ma ovviamente è possibile utilizzare anche altri linguaggi, come OMT, Shlaer-Mellor o Booch, solo per citare i più diffusi[1].

Nella fase di codifica i tipici linguaggi di descrizione sono i comuni linguaggi di programmazione (C, Java, Visual Basic, ecc.), che consentono al programmatore di “comunicare” con il computer.

Descrizione del dominio dell'applicazione e del problema

Concentrare gli sforzi sul dominio dell’applicazione e sul problema significa scrivere delle descrizioni molto precise di questi. Non è sufficiente intervistare qualche persona per cercare di comprendere il dominio e il problema. Spesso infatti quello che le persone sanno può essere incompleto o sbagliato, oppure possono avere idee non chiare del problema da affrontare. L’analisi deve quindi essere approfondita, soprattutto per problemi complessi, dove può essere anche richiesto l’intervento di consulenti esterni, che consentano di comprendere meglio il dominio.

Purtroppo può capitare di risolvere il problema sbagliato (si veda [Pescio 98]). Questo può succedere per mancanza di comunicazione oppure perché chi richiede una soluzione spesso non spiega il vero problema, ma uno secondario. Le cause del fenomeno possono essere numerose:

• chi chiede la soluzione non è ben conscio del problema;
• il tempo per spiegare il problema originario sembra troppo, e ci si accontenta di una soluzione ad un problema secondario;
• il problema vero è troppo confuso ed astratto per poter essere spiegato: il problema secondario è più facile da spiegare (è spesso è un problema di tipo tecnologico).
• la cosa migliore è quella di chiedere il perché è necessario risolvere il problema presentato. Spesso è necessario risalire diversi livelli di spiegazione, risalendo all’origine del problema attuale per individuarne di nuovi (che possono poi essere i veri problemi da risolvere, se il progettista software ha fatto un buon lavoro).

La modellazione

Nello sviluppo del software è necessario costruire modelli[2] che siano in grado di descrivere gli aspetti della realtà di interesse. Tutti i modelli si basano su alcune considerazioni di base, che è opportuno qui riassumere prima di entrare nei particolari della modellazione del sistema software in esame.

Modellare la realtà significa applicare un procedimento di analisi il quale, sulla base di un particolare linguaggio, consente di mettere in evidenza gli aspetti di interesse della realtà per il particolare scopo che il modello si prefigge.

Modellare la realtà significa quindi applicare un processo di astrazione. Il risultato di questo processo è un schema di rappresentazione, sul quale è possibile costruire istanze del modello stesso.

Quando si esegue l’analisi di un problema reale, nella sua descrizione è importante individuare:

• le entità che popolano il mondo reale;
• le relazioni che esistono tra queste entità.

Per realtà di interesse si intende quel particolare aspetto della realtà utile ai fini prefissi. Nell’ambito del progetto VAMP la realtà d’interesse copre diversi aspetti. Occorre disporre di una descrizione adeguata del territorio, dei rifiuti, della situazione dei cantieri, dei processi lavorativi edili, ecc. Questo aspetto verrà approfondito nei capitoli 2, 3, 6 e 7.

In sostanza quello si fa è astrarre dalla realtà solo gli aspetti che interessano, tralasciando quelli che possono non essere utili.

Un buon modello deve catturare i diversi aspetti della realtà:

• aspetto statico: entità e relazioni statiche tra le entità;
• aspetto dinamico: relazioni dinamiche tra le entità, stato di una entità, eventi e transizioni di stato.

Occorre rilevare che durante le fasi di modellazione, la tentazione di descrivere il dominio dell’applicazione e la macchina in un’unica esposizione è spesso molto forte. La giustificazione di ciò sta nel fatto che spesso alcune parti della macchina sono un modello per alcune parti del dominio dell’applicazione. Perché dunque duplicare la descrizione? In realtà, una descrizione di questo tipo non può che essere incompleta, poiché non è possibile, nella maggior parte dei casi, catturare con una sola descrizione i due aspetti (anche se può essere presente una parte comune). Inoltre, se si fornisce una sola descrizione, nella maggior parte dei casi si è descritta una parte della macchina.

© 2001 Andrea Bulgarelli

[ Precedente ]