Differenza tra interfacce procedurali, dei dati e di rappresentazione

Domain Requirements

In ingegneria dei requisiti, per Domain (o in italiano Dominio) s’intende il dominio di applicazione in cui il sistema sarà utilizzato, e quindi questi requisiti ne rispecchiano le caratteristiche ed i limiti. La loro definizione solitamente prevede l’utilizzo di una terminologia specifica del dominio e, ovviamente, possono sia dar luogo a nuovi requisiti funzionali, sia vincolare quelli già esistenti, inoltre potrebbero anche riportare determinati calcoli da realizzare.

Essendo questi requisiti specialistici del dominio, gli ingegneri del software riscontrano delle difficoltà nel capire in che modo questi si rapportino ad altri requisiti del sistema. Tra l’altro sono di fondamentale importanza, poiché essi riflettono i fondamenti del dominio di applicazione, e se non soddisfatti potrebbero portare il sistema a non lavorare in maniera soddisfacente.
Un grave problema legato a questi requisiti, è dettato dal fatto che essi sono scritti tipicamente adoperando il “linguaggio” del dominio di applicazione (si pensi ad esempio a specifiche equazioni matematiche), e questo li conduce a una difficile comprensione da parte degli ingegneri del software che, infatti, dovrebbero conoscere in dettaglio il particolare sistema in esame. Un altro problema, legato a questi requisiti, è dovuto al fatto che tipicamente gli esperti del dominio potrebbero lasciare fuori dai requisiti delle informazioni perché per loro implicite, ma potrebbero non esserlo per gli sviluppatori del sistema, che implementerebbero così il requisito in modo errato.

Specifica delle interfacce software

Nella maggioranza dei casi, quasi tutti i sistemi software andranno a operare in ambienti costituiti da sistemi preesistenti, con i quali dovranno necessariamente interagire. Poiché l’interfacciamento tra i sistemi può avvenire in diversi modi, è fondamentale, al fine di garantire lo scambio d’informazioni tra il nuovo e i preesistenti sistemi, specificare con precisione le interfacce di questi ultimi.

 

Tipicamente, in un documento di specifica dei requisiti, è possibile specificare tre tipi d’interfacce:

1. Interfacce procedurali: riguardano i servizi offerti da programmi o sottosistemi già esistenti mediante l’invocazione delle corrispondenti procedure d’interfaccia (API, Application Programming Interfaces);
2. Interfacce dei dati: descrivono le strutture dati trasmesse da un sistema all’altro. Per la loro descrizione si preferisce tipicamente l’utilizzo di modelli grafici.
3. Interfacce di rappresentazione: definiscono specifici pattern utilizzati per la descrizione dei dati (ad esempio la disposizione dei bit). Il modo migliore per descriverle è quello di usare strutture con commenti che spiegano la funzione di ogni gruppo di bit.

Le interfacce software dovrebbero essere specificate adottando un alto livello di astrazione, in altre parole senza descriverle nel dettaglio e inoltre, tutte le funzionalità da esse offerte potrebbero essere descritte mediante un linguaggio naturale strutturato, oppure mediante un linguaggio tabellare.

Quindi, anche se le notazioni formali permettono di definire le interfacce in modo non ambiguo, si preferisce l’utilizzo di un linguaggio naturale strutturato, poiché data la natura specialistica delle notazioni formali, se la descrizione delle interfacce non fosse corredata da ulteriori spiegazioni, risulterebbe incomprensibile. Inoltre strutturare la specifica di un’interfaccia come un modello astratto è certamente anche un’azione rivolta al riuso.