Concetti fondamentali del linguaggio SDL

Transcript

1 Concetti fondamentali del linguaggio SDL [Autore: Ing. Sauro Carsughi Facoltà di Ingegneria, Università degli Studi di Firenze, Settembre 2001] Introduzione Il linguaggio SDL (Specification and Description Language) è un linguaggio formale, non proprietario, standardizzato a livello internazionale, utilizzato per specificare e descrivere sistemi anche molto complessi, specialmente negli ambiti del real-time e delle telecomunicazioni. In generale è possibile specificare vari aspetti di un sistema, quali ad esempio la progettazione dell hardware, le dimensioni fisiche, il consumo di potenza, le prestazioni e così via. SDL si occupa della parte riguardante la specifica del comportamento e la modellazione della struttura di un sistema, nonché delle informazioni che lo stesso elabora. Questi tre aspetti sono fra loro correlati; si pensi a come dei dati in ingresso ad un sistema possano influenzarne il comportamento, ad esempio se una certa azione scaturita dalla ricezione di un segnale dipende dal valore di una variabile trasportata dal segnale stesso. Gli aspetti inerenti i vincoli non funzionali di un sistema, come ad esempio le prestazioni (tipo il tempo di risposta o il numero di transazioni in un secondo) o questioni di affidabilità (tipo il tempo medio che intercorre tra un fallimento e l altro) esulano dallo scopo di SDL, e andranno perciò modellati, se necessario, con strumenti adeguati. SDL non è sempre adatto a modellizzare tutte le componenti di un sistema molto complesso, qualora queste componenti si riferiscano a requisiti non strettamente funzionalicomportamentali: si pensi a quando il sistema include un ampio database oppure una interfaccia utente basata su finestre, che quindi sarà più appropriato realizzare con dei tools specifici. Per Specificazione di un sistema si intende l analisi dei requisiti che esso deve soddisfare e conseguentemente la definizione del suo comportamento dinamico in tutte le possibili condizioni di utilizzo, tenendo in opportuna considerazione l interazione con l ambiente esterno nel quale il sistema dovrà operare. Il sistema viene visto quindi come una scatola nera: bisogna stabilire una comprensione del dominio dell applicazione in modo da catturare, formalizzare, analizzare e infine validare i requisiti funzionali della scatola nera; non viene data importanza a come le sue parti componenti interne verranno progettate e implementate ma bensì ai requisiti funzionali che la scatola nera deve soddisfare. Dall altro lato invece, con il termine Descrizione ci si riferisce alla struttura interna del sistema considerando ora tutti i dettagli progettuali ed implementativi che non sono stati deliberatamente affrontati al precedente livello di analisi, in modo così da poter realizzare un sistema realmente funzionante. Il linguaggio SDL non fa una netta differenziazione tra la specificazione e la descrizione; in SDL la linea di confine tra i due ambiti è in realtà spesso vaga ed in genere con il solo termine specificazione si tende a denotare entrambi, sarà poi compito di colui che definisce le specifiche del sistema decidere a quale livello di raffinatezza una specifica ne rifletta anche la struttura interna. 1

2 Parentesi storica Lo sviluppo di SDL iniziò nel 1972, quando un gruppo di studio formato da 15 membri e rappresentante diversi paesi e importanti società di telecomunicazione come Bellcore, Ericsson e Motorola iniziò la ricerca per la realizzazione di un linguaggio standard per la specifica di sistemi nell area delle telecomunicazioni. SDL è stato sviluppato all interno del CCITT (Comité Consultatif International Télégraphique et Téléfonique) successivamente trasformatosi in ITU (International Telecommunications Union). La prima versione del linguaggio uscì nel 1976 e da allora è stata seguita da nuove versioni uscite sempre a distanza di quattro anni l una dall altra (l ultima nel 2000) ogni volta espandendo considerevolmente il linguaggio e semplificando l interfaccia. A partire dalla versione iniziale la quale permetteva esclusivamente di specificare il comportamento del sistema in un modo informale ed abbastanza rudimentale, sono stati introdotti via via meccanismi per trattare la struttura del sistema, i tipi di dati basati su ADT (Abstract Data Types), una definizione formale e non più informale della semantica, la possibilità di chiamare procedure remote, il non-determinismo per affrontare fenomeni aleatori, fino ad arrivare ad un notevole miglioramento nel 1992 con l introduzione nel linguaggio dell orientazione agli oggetti dando così la possibilità di usare i tipi e di mantenerli all interno di librerie chiamate packages. A tutt oggi SDL può essere considerato un linguaggio completo in tutti i sensi rappresentando uno standard internazionale riconosciuto, e come un linguaggio maturo, viene utilizzato largamente nell industria. Il suo uso si è via via esteso al di là dell area delle telecomunicazioni, come ad esempio nei settori dell industria automobilistica, ferroviaria ed aeronautica, ben adattandosi alla realizzazione di tutti i tipi di sistemi realtime e sistemi distribuiti. Punti di forza di SDL Nell ultimo decennio la dimensione del software prodotto è cresciuta drammaticamente. I sistemi sempre più spesso sono multiprocesso e distribuiti, ed eseguono in un ambiente eterogeneo. Di pari passo con le dimensioni del software, si è sviluppata la consapevolezza, specialmente in determinati segmenti industriali, che il modo migliore per soddisfare i requisiti di questi sistemi sia attraverso i metodi formali. Così oggi è largamente riconosciuto che un punto cruciale per realizzare con successo un sistema consiste in una accurata e rigorosa specificazione e progettazione. Un linguaggio di specificazione permette di valutare, analizzandole e simulandole, differenti soluzioni alternative per un dato sistema; questo approccio spesso non è fattibile con i tradizionali linguaggi di programmazione a causa dei lunghi tempi necessari e conseguentemente degli enormi costi. Contrariamente ad un programma, una specifica formale non si prefigge lo scopo di girare su un computer, essa postpone le decisioni implementative provvedendo a dare, dopo una accurata simulazione e validazione del modello, una base per l implementazione finale del sistema. E fondamentale perciò avere dei linguaggi di specificazione fatti su misura e che permettano di soddisfare il più possibile i seguenti requisiti: Concetti ben definiti Specifiche chiare, precise, concise e non ambigue Capacità di analizzare la correttezza e la completezza delle specifiche 2

3 Capacità di verificare la consistenza delle specifiche Possibilità di simulare e quindi validare le specifiche Capacità di verificare la conformità dell implementazione rispetto alle specifiche SDL è stato progettato su misura per venire incontro a queste esigenze: una ragione del suo successo e della sua popolarità rispetto a tool concorrenti risiede proprio nel fatto che SDL è stato sviluppato da ingegneri con una lunga esperienza nella specificazione e progettazione di sistemi nell area delle telecomunicazioni, rispondendo così alle necessità dei progettisti. Un esempio dell adattamento del linguaggio al modo di lavorare degli ingegneri lo si può notare subito nella sua veste grafica basata su simboli che consente di mostrare i sistemi con uno stile familiare ed intuitivo, vedendo quest ultimi come un insieme di diagrammi correlati che rappresentano differenti livelli di astrazione e di dettaglio, iniziando cioè da una visione generale del sistema fino ad addentrarsi ai dettagli specifici di basso livello. Ciò consente di fornire automaticamente anche una sorta di documentazione del progetto, e non solo per gli addetti ai lavori. SDL è in grado di descrivere la struttura ed il comportamento di un sistema con rigore matematico, eliminandone le ambiguità e garantendone l integrità. Il suo formalismo definisce precisamente la semantica che sta dietro ad ogni simbolo e ad ogni concetto, assicura chiarezza precisione e consistenza nella fase di design. Come risultato di questo formalismo, SDL ha un alto grado di testabilità, permettendo la simulazione delle specifiche del modello prima della sua validazione: rispetto alle tradizionali tecniche di progettazione non-formali, si ha un notevole miglioramento in termini di velocità e qualità di progettazione. L orientazione agli oggetti del linguaggio estende il tradizionale concetto di classe passiva, tipico ad esempio del C++ e Java, verso oggetti attivi che specificano parti del comportamento del sistema; questi oggetti sono più orientati verso applicazioni tecniche e il loro funzionamento segue esattamente quello di una macchina a stati, in cui si passa da uno stato all altro tramite delle transizioni innescate dalla ricezione di un input/segnale. Come tutti i linguaggi object-oriented, SDL supporta pienamente le proprietà di incapsulazione, ereditarietà, specializzazione, polimorfismo. A differenza della maggior parte dei linguaggi formali, SDL supporta due equivalenti notazioni. Oltre alla già citata notazione grafica (SDL GR), è standardizzata anche una notazione testuale (SDL PR). La rappresentazione testuale usa esclusivamente una sintassi testuale, mentre quella grafica non usa solo componenti grafiche ma anche alcune parti testuali, identiche a SDL-PR, dato che per alcuni tipi di specifiche ciò risulta più naturale. Sebbene la notazione grafica non sia pretesa per determinare il comportamento formale del sistema, essa senza dubbio migliora considerevolmente la leggibilità e la facilità di comprensione delle specifiche. SDL consente un alto grado di riusabilità e manutenibilità, proprio grazie alla notazione grafica, alla chiarezza visuale, alla testabilità, alla sua orientazione agli oggetti, all utilizzo di librerie, e soprattutto alla possibilità di definire varie viste del sistema celando ogni volta i dettagli degli strati a più basso livello, secondo una tipica struttura ad albero. Tutto questo, oltre a facilitare gli aspetti concernenti riuso e manutenzione di grosse applicazioni, dà la possibilità di condividere informazioni e parti di codice fra sistemi diversi. 3

4 SDL, come linguaggio non proprietario, è portabile, scalabile, aperto. Le implementazioni in codice SDL sono indipendenti dai compilatori, dai sistemi operativi, dai processori, dai meccanismi di interprocess communication, e quindi possono essere utilizzate per differenti architetture e configurazioni. SDL ben si adatta a fungere da nucleo centrale per grossi progetti ingegneristici pienamente scalabili, grazie alla sua abilità di interfacciarsi con altri linguaggi: fra questi si possono citare altre notazioni di alto livello che coadiuvano l analisi, quali OMT (object modeling technique), UML (unified modeling language), MSC (message sequence charts), oppure, per la definizione di nuovi data-types, ASN.1 (abstract sintax notation one), IDL (interface description language), CORBA (common object request broker architecture), infine, per la fase di testing e validazione, TTCN (tree and tabular combined notation). Inoltre in SDL è possibile definire delle procedure esterne al sistema ed implementarle con appropriati linguaggi di programmazione. Infine le specifiche SDL possono essere convertite direttamente ed automaticamente (per mezzo di tools di supporto disponibili in commercio) nel codice eseguibile di un linguaggio di programmazione, come il C/C++ o il CHILL, linguaggio di alto livello dell ITU. Uno sguardo d insieme del linguaggio Lo scopo di questo capitolo non è quello di spiegare nei dettagli la sintassi e la semantica del linguaggio, che d altro canto, sarebbe impossile trattare in poche pagine. Qui si vuol semplicemente illustrare sinteticamente quei concetti fondamentali che stanno alla base del linguaggio e che saranno utili per comprendere meglio il lavoro svolto nei successivi capitoli, tralasciando ad esempio, l aspetto lessicale e sintattico, oppure quello inerente l orientazione agli oggetti. Per una reale conoscenza di SDL si rimanda agli opportuni manuali [1] [2]. Il linguaggio SDL vede il mondo come diviso in due parti: il sistema e l ambiente esterno. Le specifiche scritte in SDL sono limitate al sistema, come oggetto della nostra analisi. La specificazione tende a concretizzare un modello formale che definisca le proprietà rilevanti ed il comportamento di un sistema del mondo reale, da progettare o già esistente. Ogni cosa al di fuori del sistema, viene considerata facente parte dell ambiente. La specificazione perciò definisce come il sistema in esame reagisce agli eventi che avvengono nell ambiente, i quali comunicano con il sistema per mezzo di segnali discreti. Un sistema SDL può interagire con il suo ambiente solo tramite lo scambio reciproco di segnali. Signals Environment SDL System Figura 1 Sistema SDL ed ambiente esterno 4

5 Una minima assunzione sull ambiente è che esso si comporti in una maniera compatibile con la metodologia SDL, così da permettere la comunicazione con il sistema attraverso segnali. Da un punto di vista formale, nessuna altra assunzione verrà fatta, anche se a volte sarà necessario vincolare maggiormente il comportamento dell ambiente, ad esempio evitando che esso spedisca segnali in modo totalmente casuale e caotico. Un sistema in SDL può essere decomposto in modo gerarchico, ottenendo il cosidetto partizionamento del sistema. Con il partizionamento si tende a raggiungere i seguenti obiettivi: 1. nascondere le informazioni, spostando i dettagli meno importanti verso livelli più bassi per avere una visione d insieme 2. seguire una naturale suddivisione delle funzioni 3. creare moduli di dimensioni maneggevoli 4. creare una effettiva corrispondenza con il software reale o l hardware 5. riusare specifiche già esistenti. I livelli gerarchici di un sistema SDL sono quindi i seguenti: System Block Process Service Procedure Un sistema (system) deve contenere almeno un blocco (block), e un blocco deve contenere almeno un processo (process). I servizi (service) sono opzionali, possono esistere o meno all interno di un processo; risultano utili allorchè un processo sia molto complesso, consentendo di decomporlo in due o più parti. Anche le procedure (procedure) sono opzionali, il loro uso permette di strutturare le informazioni all interno di processi e servizi. Figura 2 Vista strutturale di un sistema SDL 5

6 La struttura statica del sistema viene definita con i blocchi, mentre il comportamento e la struttura dinamica vengono determinati dall insieme dei processi, i quali eseguono in parallelo, sono indipendenti l un l altro e comunicano fra di loro e con l ambiente grazie allo scambio di segnali discreti. I blocchi, costituiti al loro interno da processi, sono a loro volta i componenti basilari che formano il sistema. Essi possono essere anche contenuti dentro un altro blocco a più alto livello, secondo una classica struttura ad albero dove il sistema rappresenta la radice; qualora si abbiano più livelli gerarchici di blocchi, solamente i blocchi foglie conterranno processi. Nonostante i blocchi non definiscano direttamente il comportamento del sistema, essi influiscono su questo vincolando lo scambio di segnali fra i processi. Infatti i blocchi sono collegati fra loro per mezzo di canali (channel) dove vengono instradati i segnali che si scambiano i processi di blocchi diversi. I canali possono essere definiti con-ritardo oppure senza-ritardo: quelli senza ritardo trasferiscono i segnali in modo istantaneo, quelli con ritardo possono ritardare i segnali in modo non deterministico, pur preservando sempre l ordine di spedizione su ogni canale. Tipi di dati Prima di addentrarci sulle caratteristiche e sul funzionamento dei processi, è necessario illustrare i tipi di dati consentiti in SDL. SDL usa il concetto di Abstract Data Types (ADT) per i suoi dati. Nelle ultime versioni del linguaggio è possibile usare anche ASN.1 (Abstract Sintax Notation one) che è una notazione che definisce i tipi di dati con un meccanismo molto simile a quelli di solito conosciuti nei linguaggi di programmazione; ASN.1 per la verità, risulta più un approccio alternativo che complementare a quello di SDL. Il concetto di Abstract Data Types definisce i tipi di dati in un modo indipendente dall implementazione, sia per quelli predefiniti che per quelli definiti dall utente. Gli abstract data types descrivono le proprietà funzionali dei dati, definiscono il risultato delle operazioni sui dati senza vincolare sul come questo risultato è ottenuto. I dati perciò vengono definiti solamente dalle loro proprietà e non sono limitati da vincoli hardware o software. Gli abstract data types, dal punto di vista concettuale, sono abbastanza differenti dai tipi di dati usati nei classici linguaggi di programmazione. Infatti per questi ultimi l utente dipende sui tipi esistenti definiti nel linguaggio, ed anche i nuovi tipi che l utente può definire sono basati su quelli già esistenti. Questi possono essere vincolati nella loro estensione, per esempio, a 16 o 32 bit per gli interi dipendentemente dal computer. Al contrario, un intero definito in SDL corrisponde al concetto matematico di intero e non è limitato dal computer. Inoltre, cosa ancora più importante per l utente, si possono definire nuovi operatori per qualunque tipo di dato, e questo non è possibile per i linguaggi di programmazione. I tipi di dati in SDL sono chiamati sort, onde evitare di essere confusi con abstract data types. In SDL noi abbiamo un singolo abstract data type che è definito dall insieme di tutti i sorts, il quale esiste solo implicitamente e non ha un nome. Infatti un abstract data type può contenere più di un sort, e gli operatori definiti possono avere argomenti di sorts differenti; comunque il risultato di una operazione è sempre di un dato singolo sort. In sostanza, un abstract data type può essere riassunto così: abstract data type = sorts + operatori 6

7 In ogni punto dell albero di specificazione del sistema (vedi fig. sottostante), c è solamente un abstract data type che è definito da tutti i sorts ed operatori introdotti dalla radice dell albero fino al punto in questione. System S Block B1 Block B2 Process P11 Process P12 Process P13 Process P21 Process P22 Figura 3 Struttura gerarchica di un sistema SDL I sorts che non sono definiti in un diretto progenitore di un certo processo o blocco, non sono rilevanti, vale a dire visibili, per quel processo o blocco. Ad esempio, i sorts definiti in P21, sono del tutto irrilevanti per P22. La specificazione di un sort ha le seguenti componenti: Un insieme di valori Un insieme di letterali o nomi di valori Un insieme di operazioni su questi valori Un insieme di equazioni o assiomi per definire gli operatori che svolgeranno le operazioni. Seguendo l approccio che SDL ha verso i tipi di dati, ogni utente dovrebbe definire tutti i sorts di cui necessita. In pratica (anche se ciò non era strettamente necessario), la definizione del linguaggio SDL ha sollevato gli utenti dall arduo compito di dover definire tutti i sorts, includendo così nel linguaggio alcuni sorts predefiniti. Ad ogni modo, l utente può definire a suo piacimento un qualunque numero addizionale di sorts. L insieme dei sorts predefiniti in SDL rende possibile lavorare con i dati in un modo tradizionale. Per tutti i sorts, anche per quelli che saranno definiti dall utente, esiste implicitamente l operatore di uguaglianza e di disuguaglianza, al quale si aggiungono specifici operatori per ciascun sort. Vi è infine la possibilità di definire nuovi operatori o per via assiomatica (soluzione complessa) o per via algoritmica mediante un diagramma di tipo procedurale (soluzione più semplice). I sorts predefiniti sono i seguenti: Integer Real Boolean 7

8 Character Charstring Time Duration PId I primi 5 tipi di dati sono molto intuitivi, avendo, dal punto di vista semantico e sintattico, le peculiarità dei loro omonimi nei linguaggi di programmazione come ad esempio C e Pascal. Gli ultimi 3 sono caratteristici di SDL, e sono orientati verso la gestione di applicazioni real-time. Il sort Time viene utilizzato per denotare il tempo assoluto, rappresenta cioè un punto nel tempo ; in SDL è definito un operatore now, il quale ritorna un valore di sort Time che rappresenta il corrente tempo globale del sistema. Il sort Duration invece viene usato per denotare un intervallo di tempo, o per meglio dire il tempo che intercorre tra due eventi. I letterali dei sorts Time e Duration sono gli stessi del sort Real, però non hanno gli stessi identici operatori. Inoltre, poiché SDL adotta un rigido controllo di compatibilità fra i tipi ( name compatibility anche detto strong type checking ) i tre sorts non sono affatto interscambiabili. Infine il sort PId (Process Identificator) rappresenta l identificatore univoco di ogni istanza di processo: ogni istanza di processo ha un unico indirizzo che non viene determinato dall utente, ma bensì dal simulatore di SDL ogni volta che viene creata una istanza di un processo. E il simulatore a garantire che ogni istanza abbia un indirizzo univoco. PId ha un solo letterale, null, che rappresenta un indirizzo vuoto. Tutti gli altri valori di sort PId sono ottenuti con quattro espressioni predefinite di SDL, di cui si parlerà nel prossimo paragrafo. E possibile definire un nuovo sort partendo da sorts già esistenti. La parola chiave syntype consente di usare con un nome differente un sort già definito e di restringere o meno l intervallo dei valori. La parola chiave synonym viene utilizzata per definire delle costanti. Con la parola chiave newtype si possono creare dei tipi di dati più o meno complessi, come ad esempio record o strutture (struct), vettori e matrici (array), insiemi (powerset), tipi enumerazione (literals). Specificazione del comportamento: i processi Il comportamento dinamico di un sistema SDL viene descritto per mezzo dei processi. Per ogni processo definito nel sistema, si possono avere più istanze attive contemporaneamente, le quali determinano il comportamento complessivo del sistema. Tutte le istanze di un processo hanno le stesse identiche specifiche sul comportamento, sebbene esse possano trovarsi in stati differenti nel medesimo istante. Per ogni specificazione di processo perciò può esistere più di una istanza, ed ognuna avrà il proprio identificatore univoco (PId); ciò rende possibile mandare segnali ad istanze individuali di uno stesso processo. Non c è nessuna gerarchia associata con le istanze dei processi, esse esistono ed eseguono in parallelo con uguali diritti. Tutte le istanze hanno il loro proprio ciclo di vita: vengono create, e dopo essere esistite per un certo tempo, esse possono morire. Alcune istanze saranno create implicitamente al momento dello start-up del 8

9 sistema, altre invece successivamente durante il ciclo di vita del sistema; quest ultime verranno create da altre istanze, ma una volta create, le nuove istanze saranno sullo stesso livello. Le istanze di processi SDL sono particolari Macchine a Stati Finiti. Una macchina a stati finiti ha sempre un numero finito di stati, uno dei quali è lo stato iniziale. Una transizione fra due stati viene effettuata solo dopo la ricezione di un segnale, e se non ci sono segnali pendenti il processo rimane inattivo in qualche stato. I limiti di una macchina a stati finiti risultano immediatamente evidenti non appena si devono modellare sistemi di media complessità. Per certe funzioni, come ad esempio un banale conteggio, il numero di stati richiesto può crescere in modo drammatico, ottenendo la cosiddetta state explosion. Una Macchina a Stati Finiti Estesa risolve questo problema introducendo delle variabili in aggiunta agli stati espliciti della macchina. Le variabili riducono la complessità visibile del sistema nascondendo le informazioni meno importanti; ad esempio, l uso di un intero come una variabile permette di nascondere in questa variabile tutti i valori interi. Tutto ciò consente una forma più condensata per la specificazione del sistema. Una variabile, senza essere uno stato vero e proprio, cioè uno stato esplicito, contribuisce a determinare lo stato globale della macchina: si capisce che allorchè un nuovo e differente valore viene assegnato ad una variabile, lo stato globale cambia. La decisione riguardo quali stati dovranno essere stati espliciti o variabili è arbitraria, non esistono regole formali, ed essa dipende molto dall applicazione. In generale comunque, una buona pratica è quella di specificare con stati espliciti le informazioni che riflettono fortemente il comportamento del sistema, mentre con le variabili si dovrebbero specificare le informazioni che hanno un debole effetto sul comportamento. I processi sono dunque delle macchine a stati finiti estese comunicanti fra loro e con l ambiente per mezzo di segnali discreti ed in maniera asincrona. Ogni processo è composto da un certo numero di stati e da un certo numero di transizioni che connettono fra di loro gli stati. Gli stati sono i punti di stabilità del comportamento del processo. In essi il processo rimane inattivo, non accade niente di osservabile; a questo punto, previa ricezione di un segnale, può iniziare una transizione che porterà il processo in un nuovo stato. In qualunque momento della vita del sistema, una istanza perciò può trovarsi solamente in una delle due condizioni: 1. Sta eseguendo una transizione fra due stati 2. E inattiva in uno stato e sta aspettando un qualche segnale. Ogni istanza di un processo, non appena viene creata, inizia la sua vita interpretando il simbolo di start, il quale è obbligatorio e farà scattare immediatamente una transizione (anche vuota) che condurrà l istanza nello stato iniziale. Ogni processo può avere solamente un singolo simbolo di start, altrimenti il momento di inizio esecuzione non sarebbe definito in modo univoco. In pratica, facendo un paragone con i linguaggi di programmazione, il simbolo di start corrisponde alla prima espressione non dichiarativa nella parte principale di un programma. Ogni istanza di un processo può cessare la sua esistenza solamente in modo autonomo dopo l interpretazione del simbolo di stop. Questo non possiede parametri e può essere ripetuto un qualunque numero di volte in un qualunque numero di transizioni. Con la morte di una istanza cesseranno di esistere anche le sue variabili e le sue componenti interne, vale a dire eventuali servizi e procedure. 9

10 Mentre una istanza può essere uccisa solo da se stessa, essa invece può essere creata non solo allo start-up del sistema ma anche successivamente da un altra istanza. Per questo scopo si utilizza un simbolo di creazione durante una transizione. Come già detto sopra, non appena una istanza viene creata, essa inizia la sua esecuzione indipendentemente dall istanza padre ed in nessun modo essa è inferiore al padre. Tutte le istanze dei processi del sistema sono concorrenti ed eseguono in parallelo. Ogni istanza ha il suo proprio spazio di memoria ben separato dagli altri: vale a dire che i dati su cui lavora ogni istanza sono locali per quell istanza e a nessuno è permesso di cambiare i valori delle sue variabili. Questo aspetto è molto importante poiché riduce drasticamente il numero dei difetti e degli errori nella modellazione del sistema aumentando di conseguenza la robustezza e l affidabilità. Ad ogni modo, alcune variabili possono esser definite visibili per le istanze appartenenti a processi diversi purchè dentro il medesimo blocco. Ciò è possibile dichiarando una variabile con l attributo revealed; un processo poi potrà accedere al valore di questa variabile con il costrutto view, senza comunque poterne cambiare il valore. I collegamenti fra i processi: signal routes In generale un sistema SDL contiene diversi processi. Questi non possono comunicare l un l altro senza delle restrizioni, e la struttura statica del sistema specifica quali processi possono comunicare fra di loro. I segnali vengono trasportati su dei percorsi di comunicazione: come già si è detto, i segnali che passano da un blocco all altro lo fanno per mezzo dei cosiddetti canali, che possono essere con ritardo o senza ritardo; all interno di uno stesso blocco invece, i processi comunicano fra loro grazie a dei collegamenti detti signal routes. A differenza dei canali, i signal routes consentono solamente il trasporto senza ritardo dei segnali, i quali così verranno trasferiti istantaneamente. Invece, come per i canali, anche i signal routes preservano singolarmente l ordine di spedizione dei segnali. Se i processi comunicanti sono contenuti nello stesso blocco, i soli signal routes sono sufficienti per il trasferimento dei segnali. Nel caso invece i processi siano contenuti in blocchi differenti, i segnali dovranno passare anche attraverso i canali, rendendo così necessario un punto di contatto fra canali e signal routes. I signal routes così potranno terminare sul confine del blocco, ed in quel punto essi saranno connessi ai canali: i segnali attraverseranno i signal routes sia all inizio che alla fine del loro percorso. Le regole per una tale connessione sono le seguenti: Un canale deve essere connesso ad almeno un signal route. Un signal route deve essere connesso ad almeno un canale. Nel caso più canali e signal routes siano connessi insieme (cioè convergono verso un punto di contatto) in una relazione del tipo m:n, dove sia m che n siano maggiori di uno, l insieme di tutti i segnali che passano nei canali in una data direzione deve essere identico all insieme dei segnali che passano nei signal routes nella stessa direzione. Questo è necessario per garantire che i segnali non vengano persi quando si muovono da un canale a un signal route o viceversa. Nell eventualità che un segnale abbia più di un canale o signal route da scegliere per raggiungere il confine del blocco, ne verrà scelto uno in modo non deterministico, cioè del tutto casuale: un tale comportamento, a meno che non sia voluto, va assolutamente evitato specificando in maniera univoca e non ambigua i percorsi che i segnali possono intraprendere. 10

11 Semantica della comunicazione I segnali in SDL possono avere dei parametri, i quali aggiungono un contenuto informativo ai segnali così come le variabili aggiungono informazione agli stati espliciti dei processi. Non vi è nessuna regola formale sulla scelta tra segnali espliciti e segnali con parametri: dipende quale aspetto di un segnale vogliamo che sia chiaramente visibile. Quando un processo manda un segnale ad un altro processo, nella rappresentazione grafica SDL avremo un simbolo di output con il nome del segnale e gli eventuali parametri attuali, cioè una lista di espressioni che denotano dei valori. Nel processo ricevente avremo invece un simbolo di input (che deve essere sempre attaccato ad uno stato) con lo stesso nome del segnale ed una corrispondente lista di parametri formali, vale a dire delle variabili alle quali verranno assegnati i valori dei parametri attuali trasportati dal segnale stesso. Naturalmente i parametri attuali di un output e i parametri formali di un input devono essere dello stesso tipo, e la corrispondenza viene stabilita dalla posizione nelle due liste. Ogni segnale spedito può essere ricevuto solo da una istanza di un processo, e tutte le volte che parte un segnale, SDL verifica quali istanze sono abilitate a riceverlo. Se non esistono istanze oppure queste sono irraggiungibili, il segnale viene scartato. Se invece l istanza che dovrà ricevere il segnale non può essere identificata in modo univoco, essa sarà scelta in modo del tutto casuale fra tutte le possibili istanze abilitate. SDL utilizza per i suoi processi un meccanismo di comunicazione asincrono: ogni volta che viene spedito un segnale, il processo mittente non deve sincronizzarsi con il processo ricevente, ovvero non aspetta nessuna notifica di ricezione e può così continuare la sua esecuzione. Il segnale viene immesso direttamente in un percorso, composto da signal routes ed eventuali canali, che lo condurrà a destinazione. signal route signal Process Instance Input queue signal route signal Process Instance Input queue Process Instance Input queue Figura 4 Comunicazione fra i processi Ogni istanza di un processo ha associata una coda infinita di tipo FIFO (First In First Out) che viene chiamata input queue. Un segnale che arriva alla sua istanza di destinazione e che appartiene all insieme dei segnali permessi per quell istanza, viene collocato nella 11

12 input queue personale di quell istanza. La input queue, proprio perché infinita, è permanentemente nella condizione di poter ricevere segnali, che verranno immagazzinati in base al loro ordine di arrivo. Un processo generalmente tratta solo un sottoinsieme di tutti i segnali specificati nell intero sistema. Questo sottoinsieme viene denominato complete valid input signal set e contiene tutti quei segnali che il processo può trattare e quindi accettare. Se una istanza perciò riceve un segnale che non appartiene al suo complete valid input signal set, questo segnale viene scartato senza essere inserito nella input queue. I segnali immagazzinati nella input queue, vengono prelevati e consumati nel loro ordine di arrivo da parte dell istanza del processo. La transizione che scaturisce dal segnale consumato dipenderà sia dallo stato in cui si trova l istanza, sia dal tipo di segnale. Appena un segnale viene consumato, esso viene rimosso dalla input queue e tutti gli eventuali segnali che seguono in coda vengono spostati di una posizione per occupare il posto vacante. Se la input queue è temporaneamente vuota, l istanza rimarrà inattiva in qualche stato (sempre che non stia eseguendo una transizione) in attesa dell arrivo di un segnale. Per alcune combinazioni di stati e segnali, la transizione può essere vuota, nel senso che non è prevista nessuna transizione: ad esempio, riferendoci alla figura 3.5, se l istanza si trova nello stato s2 ed il prossimo segnale della coda è d, lo stato non cambia ed il segnale viene consumato senza effettuare nessuna azione particolare. In sostanza, tutti quei segnali che non sono menzionati esplicitamente dopo uno stato, vengono consumati implicitamente per quello stato senza produrre alcun effetto: una siffatta transizione viene chiamata transizione implicita. INPUT QUEUE PROCESS GRAPH b a d a Stato S1: il segnale a inizia una transizione verso lo stato S2 d S1 a b a d Stato S2: il segnale d viene scartato b a Stato S2: il segnale a inizia una transizione verso un altro stato S2 a b f Figura 5 Funzionamento della input queue Molto spesso comunque i segnali non arrivano nell ordine preferito, e si vorrebbe consumarli in un ordine differente da quello di arrivo. A questo scopo SDL ha provveduto fornendo agli utilizzatori due costrutti molto utili che consentono di violare la modalità FIFO per il prelievo dei segnali dalla input queue. Questi due meccanismi sono il save ed il priority input. 12

13 save Il costrutto save viene usato per trattenere e salvare dei segnali nella input queue per poi consumarli successivamente: il simbolo di save, che deve essere sempre attaccato ad uno stato, contiene i nomi dei segnali che devono essere salvati, cioè trattenuti nella input queue; lo stato che quindi ha un insieme di segnali da salvare specificati nel save, preleva dalla input queue il primo segnale che non appartiene a questo insieme. I segnali salvati saranno così resi disponibili per gli stati successivi che li potranno utilizzare per effettuare transizioni. La figura 3.6 mostra il funzionamento del costrutto save: i segnali {A,C} vengono salvati in un save, di conseguenza l istanza del processo passa al primo segnale della coda che non appartiene all insieme dei segnali salvati, cioè B. L ordine di prelevamento dei segnali diversi da {A,C} rimane invariato, cioè con modalità FIFO. B B A D A C INPUT QUEUE Figura 6 Funzionamento del costrutto Save In pratica, il costrutto save è indispensabile quando alcuni segnali non servono ad un determinato stato ma non si può buttarli via con transizioni implicite in quanto necessari per altri stati del processo. E importante ricordare che ogni costrutto save ha rilevanza solo per lo stato al quale è applicato; i segnali salvati possono così essere inavvertitamente consumati dagli stati successivi se questo non è tenuto in considerazione, perciò se necessario dovranno essere specificati ulteriori costrutti save. priority input Il simbolo di priority input, così come il save e l input normale, deve essere sempre attaccato ad uno stato, ed ha perciò rilevanza solo per quel determinato stato. Esso serve per assegnare ad alcuni segnali una priorità maggiore rispetto ai rimanenti; i segnali che vengono definiti nel costrutto di priority input devono essere prelevati e consumati prima degli altri, anche se nella input queue non occupano le posizioni di testa. Il priority input concede la possibilità di prelevare i segnali dalla input queue in un modo non FIFO, che potremmo meglio caratterizzare con la dicitura semi-fifo : prima si andrà a cercare nella input queue quei segnali definiti nel priority input prelevandoli comunque con modalità FIFO, poi si passerà ai rimanenti segnali e anche questi verranno prelevati in base alla loro posizione nella coda. In definitiva i segnali vengono divisi in due gruppi, di cui uno ha precedenza sull altro ma all interno di ciascun gruppo i segnali seguono il principio FIFO. 13

14 Metodi di indirizzamento Quando un segnale viene spedito, ci si aspetta che esso sia ricevuto da una istanza di processo. Come si è già detto, i segnali che non trovano nessuna istanza di destinazione vengono scartati; si fa notare che per le versioni di SDL precedenti al 1992, questo comportamento conduceva ad un errore dinamico nel sistema con conseguente blocco della simulazione. Affinchè un segnale riesca a pervenire correttamente ad una sola istanza, SDL si è dotato di meccanismi di indirizzamento molto potenti e ben strutturati. Ogni istanza di processo ha un indirizzo univoco che gli viene assegnato da SDL al momento della sua creazione. Gli indirizzi in SDL sono di un tipo predefinito, il sort PId. Ciascuna istanza possiede quattro espressioni predefinite di sort PId, il cui utilizzo permette un preciso ed efficace indirizzamento dei segnali. Queste quattro espressioni sono indirizzi di istanze: Self, l indirizzo dell istanza stessa. Sender, l indirizzo dell istanza dalla quale è stato ricevuto l ultimo segnale, anche se questo ha prodotto una transizione implicita; se tuttavia l istanza non ha ricevuto nessun segnale, l espressione sender assume il valore null, ovvero un indirizzo vuoto. Offspring, l indirizzo dell ultima istanza creata dall istanza in questione; se non è stata creata nessuna istanza, l espressione offspring assume il valore null. Parent, l indirizzo dell istanza che ha creato l istanza in questione; se quest ultima non è stata creata da un altra istanza ma bensì allo start-up del sistema, l espressione parent avrà sempre il valore null. Lo specificatore di un sistema SDL può assegnare a delle variabili di sort PId il valore di queste espressioni predefinite, in modo da immagazzinarvi indirizzi per un successivo uso: ad esempio, può essere necessario mandare un segnale ad una istanza sender non subito ma dopo aver ricevuto altri segnali ed effettuato una serie di transizioni, oppure ad una specifica istanza creata sotto certe condizioni. In linea generale, i metodi per indirizzare i segnali possono essere divisi in due categorie, che sono indirizzamento esplicito ed indirizzamento implicito. Con l indirizzamento esplicito, l indirizzo di una particolare istanza viene specificato univocamente. Questo assicura la consegna del segnale a meno che l istanza di destinazione cessi di esistere prima che il segnale la raggiunga. Nel simbolo di output verrà utilizzata la parola chiave to seguita dall indirizzo dell istanza, e l indirizzo sarà o una delle quattro espressioni predefinite o una variabile di sort PId contenente pur sempre una delle quattro espressioni. Nell indirizzamento implicito invece, l indirizzo dell istanza di destinazione non viene specificato direttamente in modo univoco. In molte situazioni infatti, non è possibile conoscere l indirizzo esplicito di una istanza, né è possibile identificarlo in modo univoco dalla struttura del sistema. Si cerca allora di porre dei vincoli su come il segnale deve essere instradato o su quali istanze possono riceverlo, cercando di restringere ad una sola istanza ricevente. Se infatti un segnale trova più di una istanza disponibile a riceverlo, SDL ne sceglierà una in un modo non deterministico. 14

15 Per vincolare il segnale a seguire un determinato percorso, si utilizza nel simbolo di output la parola chiave via, dopo la quale sarà specificato il canale o il signal route che il segnale dovrà percorrere. Per restringere l insieme delle possibili istanze riceventi, si può utilizzare la parola chiave to seguita dal nome di un processo (quello assegnato dallo specificatore). Questa tecnica però individua una istanza univoca solo nel caso il processo in questione non ne preveda più di una. E possibile utilizzare assieme le due parole chiave to e via, nel caso ciò possa essere utile a vincolare maggiormente la destinazione del segnale. Il metodo di indirizzamento implicito è il solo modo di stabilire il primo contatto fra blocchi differenti, in quanto nessuna delle quattro espressioni predefinite {self, sender, offspring, parent} è di aiuto, dato che una istanza può essere creata da un altra solo all interno dello stesso blocco. Una volta stabilito il contatto, si potrà utilizzare l espressione sender per ottenere gli indirizzi delle istanze che hanno mandato segnali, e quindi passare da un indirizzamento implicito ad uno esplicito. Gestione del tempo: i Timer SDL è un linguaggio usato soprattutto per descrivere e specificare sistemi real-time e sistemi di telecomunicazione: in tali aree applicative è essenziale poter specificare il tempo ed i vincoli temporali. Per esempio, può essere necessario specificare un comportamento di default per il sistema qualora si verifichi una situazione di time-out. In SDL è possibile specificare attività sensibili al tempo in due differenti modi. Il primo consiste nel controllare, durante una transizione, una qualche condizione temporale accedendo al tempo globale del sistema per mezzo dell espressione predefinita now: essa ritorna un valore di sort Time che denota un tempo assoluto. Il secondo modo si basa sull utilizzo dei timer. I timer sono oggetti che appartengono ad una istanza di un processo. I timer devono essere dichiarati prima dell uso, proprio come una qualunque variabile. Esistono dal momento in cui l istanza che li possiede viene creata fino a quando questa muore. Tutti i timer di una istanza e l istanza stessa operano in parallelo. Dal punto di vista funzionale un timer è un contatore: esso viene settato su un certo valore, che può rappresentare o un intervallo di tempo relativo o un tempo assoluto. Quando gli si chiederà di partire, ossia verrà attivato, il timer comincerà a contare come un orologio e appena avrà raggiunto il time-out genererà un segnale che avrà il nome del timer e che verrà istantaneamente immesso nella input queue dell'istanza a cui il timer appartiene. Il timer quindi confronta il tempo corrente con il suo tempo di scadenza. Nel caso in cui il tempo di scadenza, arrivi o addirittura sia già stato superato nel momento in cui si attiva il timer, il segnale relativo al timer viene generato immediatamente e immesso nella input queue. Nella stragrande maggioranza dei casi un timer viene settato su un tempo relativo, piuttosto che su un tempo assoluto. Può essere settato esplicitamente su un certo valore al momento della sua attivazione o implicitamente su un valore opzionale di default specificato al momento della sua dichiarazione. Il valore di default dovrà essere un sort Time se ci si riferisce ad un tempo assoluto, se invece si specifica un tempo relativo, un sort Duration: in quest ultimo caso, quando il timer verrà attivato, verrà sommato al tempo corrente del sistema il valore di default. Nel settaggio esplicito di un tempo relativo si ricorre all espressione predefinita now, che ci dà il tempo corrente, alla quale si somma un valore di sort Duration che rappresenta appunto il tempo relativo. 15

16 In SDL un timer viene attivato con la parola chiave set, cui segue il nome del timer e, se si ricorre ad un settaggio esplicito, l eventuale tempo di scadenza. Uno stesso timer può essere usato con lo stesso nome in differenti parti della specifica di un processo, per scopi diversi e con tempi di scadenza diversi. Non è perciò sempre necessario definire un timer distinto per ogni scopo, ma occorre fare molta attenzione: infatti ogni volta che un timer viene attivato di nuovo, il suo eventuale segnale presente nella input queue e non ancora consumato, verrà inesorabilmente rimosso dalla coda! Questo assicura che non vi sia un numero incontrollato di segnali dello stesso timer nella input queue, poichè produrrebbe confusione. Un timer può essere anche resettato durante una transizione mediante la parola chiave reset. Ciò provoca l interruzione permanente del conteggio, ed il timer viene così reso inattivo. Se però nel momento del reset il timer è già scaduto ma il relativo segnale non è ancora stato consumato, questo segnale verrà rimosso dalla input queue. Un reset su un timer non attivo non sortisce alcun effetto. I segnali generati dai timer vengono gestiti dalla input queue come qualunque altro segnale tranne per il fatto che essi possono essere rimossi senza essere stati consumati quando il timer viene nuovamente attivato oppure resettato. Così, come i costrutti save e priority input, anche i timer possono intaccare la modalità FIFO per il prelievo dei segnali dalla input queue. Inoltre si fa notare che nel momento in cui una istanza consuma un segnale generato da un suo timer, le due espresioni predefinite self e sender assumono lo stesso valore. Analogamente agli altri segnali, anche i segnali dei timer possono avere dei parametri. Questi parametri comunque non sono usati per trasportare informazioni, ma bensì per identificare un particolare timer quando vi sono molti timer dello stesso tipo, cioè con lo stesso nome. Quindi un timer può essere identificato, oltre che con il nome, anche con un certo numero di parametri specificati al momento della dichiarazione: per ogni combinazione dei valori dei parametri, i quali potranno essere anche infiniti, potrà esistere un unico timer, o per meglio dire una distinta istanza di quel particolare tipo di timer. E possibile perciò scegliere per uno stesso tipo di problema, o diversi tipi di timer senza parametri o un singolo tipo di timer ma con parametri. Nel caso un certo problema richieda un numero potenzialmente infinito di timer, si dovranno obbligatoriamente usare tipi di timer con parametri, ad esempio di sort Integer. Qualche volta è molto utile definire un timer con un parametro di sort PId, il che permette di avere istanze distinte dello stesso timer da utilizzarsi per la comunicazione con alcune specifiche istanze di un determinato processo, essendo quest ultime identificate dal loro indirizzo di sort PId: per esempio, può essere necessario avere un differente time-out per le diverse istanze di un processo, e questo time-out deve essere comunicato da parte dell istanza che possiede il timer parametrizzato. Ciò è particolarmente vero qualora non si abbia alcuna informazione circa il numero di possibili istanze comunicanti. A conclusione di questa parte, si precisa che nessuna unità di tempo, ad esempio il millisecondo, è specificata per i sort Time e Duration. L utilizzo di una determinata unità di tempo dipende dal contesto dell applicazione, e quindi non è definita formalmente. L unità di tempo verrà scelta dallo specificatore al momento della simulazione, ma è buona regola indicarla in un modo informale, ad esempio con un commento, nella specificazione del sistema. In genere si tende ad utilizzare il secondo piuttosto che le sue frazioni, in quanto permette all occhio umano di analizzare meglio il funzionamento e l evoluzione del sistema, e quindi la correttezza delle specifiche. 16

17 Sommario dei simboli grafici In questo paragrafo vengono illustrati tutti i simboli grafici del linguaggio SDL che sono stati utilizzati nella realizzazione del nostro progetto. Essi rappresentano praticamente tutti i simboli del linguaggio, se si escludono tre simboli dedicati alla orientazione agli oggetti più altri due simboli di scarso utilizzo pratico. Tutti i simboli possono essere ingranditi e deformati nelle due direzioni cartesiane in base ad esigenze puramente grafiche, conservando comunque il loro significato semantico. I seguenti simboli vengono utilizzati per la definizione dei 5 livelli gerarchici di un sistema SDL: al loro interno viene scritto il nome del relativo livello gerarchico e rappresentano una referenza o link ad un frame che conterrà la specificazione del contenuto. Simbolo di system e di block. Simbolo di process. Simbolo di service. Simbolo di procedure. Il simbolo successivo può essere contenuto all interno dei frame che specificano il contenuto dei 5 livelli gerarchici. Esso delimita un area in cui vengono dichiarati eventuali nuovi tipi di dati, variabili e timer. Simbolo di text. I seguenti simboli definiscono il comportamento dei processi, dei servizi e delle procedure. Si fa notare che i simboli di start e di stop per le procedure sono graficamente diversi da quelli per i processi e i servizi: essi sono riportati alla fine dell elenco. Simbolo di start; fa scattare la prima transizione che condurrà allo stato iniziale. Simbolo di state (stato); contiene il nome dello stato. Simbolo di input; contiene il nome del segnale o dei segnali la cui ricezione innesca una transizione. Simbolo di priority input; contiene il nome del segnale o dei segnali che hanno priorità di prelevamento dalla input queue. 17

18 Simbolo di output; contiene il nome del segnale o dei segnali che vengono spediti. Simbolo di save; contiene il nome del segnale o dei segnali che per un determinato stato devono essere trattenuti nella input queue per un eventuale consumo successivo. Simbolo di task; è utilizzato per assegnare un valore ad una variabile o per settare e resettare un timer. Simbolo di decision; divide una transizione in due o più rami in base al valore di certe condizioni contenute al suo interno. Simbolo di label; viene definita con all interno un nome e ridireziona il flusso di controllo della transizione in un preciso punto. Simbolo di procedure call (chiamata a procedura); contiene il nome della procedura e una lista opzionale di parametri attuali. Simbolo di create; crea un nuovo processo e al suo interno ne viene specificato il nome e gli eventuali parametri attuali che gli verranno passati. Simbolo di stop; termina definitivamente la transizione e uccide il processo o servizio in cui è specificato. Simbolo di start per le procedure. Simbolo di stop per le procedure; restituisce il controllo all entità (processo, servizio o altra procedura) chiamante. 18