$$ \require{color} % Regular operations \def\op#1{ \fcolorbox{black}{white}{$\vphantom{d} \sf{#1}$} } \def\d{\op{d} \,} \def\a{\op{a} \,} \def\u{\op{u} \,} % Erroneous operations \def\opR#1{ \fcolorbox{black}{orangered}{$\vphantom{d} \color{white}{\sf{#1}}$} } \def\dR{\opR{d} \,} \def\aR{\opR{a} \,} \def\uR{\opR{u} \,} % Subscript operations \def\Op#1#2{ \fcolorbox{black}{white}{$\vphantom{d_6} \sf{#1}_{#2}$} } \def\D#1{\Op{d}{#1} \,} \def\A#1{\Op{a}{#1} \,} \def\U#1{\Op{u}{#1} \,} % Warning subscript operations \def\OpW#1#2{ \fcolorbox{black}{orange}{$\vphantom{d_6} \sf{#1}_{#2}$} } % Green subscript operations \def\OpG#1#2{ \fcolorbox{black}{lightgreen}{$\vphantom{d_6} \sf{#1}_{#2}$} } \def\DG#1{\OpG{d}{#1} \,} \def\AG#1{\OpG{a}{#1} \,} \def\UG#1{\OpG{u}{#1} \,} % Error \def\Err{ \color{red}{\sf{ERROR}} } \def\err{ \, \Err } $$

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:

  1. \(\op{l}\), \(\op{s}\) e \(\op{c}\) devono essere precedute da \(\op{a}\) senza \(\op{c}\) intermedie;
  2. \(\op{a}\) deve essere seguita da \(\op{c}\) prima di un’altra \(\op{a}\);
  3. 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.