Oltre le variabili
L’analisi del flusso dati si può estendere anche su altri “oggetti”, non solo variabili.
Per esempio, è possibile prevedere le seguenti operazioni su un file:
- \(\op{a}\) (apertura): specializzata in per lettura o per scrittura;
- \(\op{c}\) (chiusura);
- \(\op{l}\) (lettura);
- \(\op{s}\) (scrittura).
Date queste operazioni si possono individuare una serie di regole, come per esempio:
- \(\op{l}\), \(\op{s}\) e \(\op{c}\) devono essere precedute da \(\op{a}\) senza \(\op{c}\) intermedie;
- \(\op{a}\) deve essere seguita da \(\op{c}\) prima di un’altra \(\op{a}\);
- legami tra tipo di apertura (per lettura o per scrittura) e relative operazioni.
È interessante notare il legame tra l’attività di analisi del flusso di dati e i diagrammi UML a stati finiti: un oggetto risponde a una certa tipologia di eventi, può essere in diversi stati e in certi stati non sono ammesse alcune operazioni. Si noti come nessuna delle due discipline entra comunque nel merito del valore delle variabili, relegato ad un’analisi a runtime.
Criterio di copertura del budget
Molto spesso nei contesti reali l’unico criterio applicato è quello di copertura del budget: si continuano a creare casi di test finché non sono finite le risorse (tempo e soldi). Questa tecnica ovviamente non fornisce alcuna garanzia sull’efficacia dei test, ed è sicuramente sconsigliata.