Gli ingegneri in tutti i campi costruiscono e analizzano modelli, che vanno dai tunnel del vento alle equazioni di Navier-Stokes ai diagrammi dei circuiti ai modelli a elementi finiti degli edifici. Fondamentalmente, la modellazione affronta due problemi nell'ingegneria.

In primo luogo, l'analisi e il test non possono attendere fino a quando l'artefatto reale non è costruito, che si tratti di un edificio o di un sistema software.

In secondo luogo, è impraticabile testare l'artefatto reale così approfonditamente come vorremmo, che significa esporlo a tutte le forze prevedibili di uragano e terremoto, o a tutti gli stati e gli input possibili del programma.

I modelli ci permettono di iniziare l'analisi prima e di ripeterla man mano che il progetto evolve, e ci consentono di applicare metodi analitici che coprono una classe molto più ampia di scenari di quanto non possiamo testare esplicitamente. Molte di queste analisi possono essere automatizzate.

Overview

Un modello è una rappresentazione più semplice dell'artefatto che rappresenta ma conserva (o almeno approssima) alcune caratteristiche importanti dell'artefatto reale. Il nostro interesse in questo capitolo è nei modelli dell'esecuzione del programma, e non nei modelli di altri (altrettanto importanti) attributi come lo sforzo richiesto per sviluppare il software o la sua usabilità.

Un buon modello (o, più precisamente, una buona classe di modelli) deve tipicamente essere:

• Compatto: Il modello deve essere rappresentabile e manipolabile in una forma ragionevolmente compatta. Ciò che è "ragionevolmente compatto" dipende principalmente da come il modello verrà utilizzato. I modelli destinati all'ispezione e al ragionamento umano devono essere abbastanza piccoli da essere comprensibili. I modelli destinati esclusivamente all'analisi automatizzata possono essere troppo grandi e complessi per la comprensione umana, ma devono comunque essere sufficientemente piccoli o regolari per l'elaborazione informatica.
• Predittivo: Un modello utilizzato nell'analisi o nel design deve rappresentare abbastanza bene alcune caratteristiche salienti dell'artefatto modellato per distinguere tra risultati "buoni" e "cattivi" dell'analisi, rispetto a quelle caratteristiche.
• Significativo semanticamente: Oltre a distinguere tra previsioni di successo e fallimento, è generalmente necessario interpretare i risultati dell'analisi in modo che consenta una diagnosi delle cause del fallimento. Ad esempio, se un modello a elementi finiti di un edificio prevede il crollo in un uragano di categoria cinque, vogliamo sapere abbastanza su quel crollo per suggerire delle revisioni al progetto. Allo stesso modo, se un modello di un sistema contabile prevede un fallimento quando usato contemporaneamente da diversi clienti, abbiamo bisogno di una descrizione di quel fallimento sufficiente per suggerire possibili revisioni.
• Sufficientemente generale: I modelli destinati all'analisi di una caratteristica importante (ad esempio, resistere ai terremoti o l'operazione concorrente da parte di molti clienti) devono essere abbastanza generali per un uso pratico nel dominio di applicazione previsto.

Dal momento che i modelli di progettazione sono destinati in parte ad aiutare nella presa e nella valutazione delle decisioni di progettazione, dovrebbero condividere queste caratteristiche con i modelli costruiti principalmente per l'analisi. Tuttavia, alcuni tipi di modelli - in particolare le notazioni di progettazione UML ampiamente utilizzate - sono progettati principalmente per la comunicazione umana, con meno attenzione al significato semantico e alla previsione.

I modelli sono spesso utilizzati in modo indiretto nella valutazione di un artefatto. Ad esempio, alcuni modelli non vengono analizzati direttamente, ma vengono utilizzati per guidare la selezione dei casi di test. In tali casi, le qualità di essere predittivo e semanticamente significativo si applicano al modello insieme alla tecnica di analisi o di test applicata a un altro artefatto, tipicamente il programma o il sistema effettivo.

Finite Abstraction of Behavior

Una singola esecuzione di un programma può essere vista come una sequenza di stati alternati con azioni (ad esempio, operazioni della macchina). I comportamenti possibili di un programma sono un insieme di tali sequenze. Se astraiamo dai limiti fisici di una macchina specifica, per tutti tranne i programmi più banali, l'insieme di sequenze di esecuzione possibili è infinito. Quell'intero insieme di stati e transizioni è chiamato lo spazio degli stati del programma. I modelli di esecuzione del programma sono astrazioni di quello spazio.

Gli stati nello spazio degli stati dell'esecuzione del programma sono correlati agli stati in un modello finito di esecuzione da una funzione di astrazione. Poiché una funzione di astrazione sopprime alcuni dettagli dell'esecuzione del programma, raggruppa insieme stati di esecuzione che differiscono per i dettagli soppressi ma sono altrimenti identici.

La Figura 5.1 illustra due effetti dell'astrazione: il modello di esecuzione viene semplificato (sequenze di transizioni vengono ridotte in meno passaggi di esecuzione), e viene introdotto il nondeterminismo (perché si sacrifica l'informazione necessaria per fare una scelta deterministica).

I modelli finiti di esecuzione del programma sono inevitabilmente imperfetti. Comprimere gli stati potenzialmente infiniti dell'esecuzione reale in un numero finito di stati modello rappresentativi comporta necessariamente l'omissione di alcune informazioni. Sebbene si possa sperare che le informazioni omesse siano irrilevanti per la proprietà che si desidera verificare, ciò è raramente completamente vero. Nella Figura, le parti 2(a) e 2(b) illustrano come l'astrazione possa causare un insieme di transizioni deterministiche a essere modellato da una scelta nondeterministica tra transizioni, rendendo così l'analisi imprecisa. Ciò a sua volta può portare a "falsi allarmi" nell'analisi dei modelli.