POLITECNICO DI MILANO
Facoltà di Ingegneria
Corso di laurea in Ingegneria Elettronica
GESTIONE MULTIUTENTE DELLA LIBRERIA DI UN AMBIENTE OBJECT-ORIENTED PER LA COSTRUZIONE DI MODELLI DI SIMULAZIONE
Relatore: Chiar.mo Prof. Claudio MAFFEZZONI
Correlatori: Ing.Roberto GIRELLI
Ing.Alberto LEVA
Tesi di Laurea di:
Norberto Eros MAGNI Matr.n. 593856
Alberto TOGNAZZO Matr.n. 592701
Anno Accademico 1994-95
Alle nostre famiglie
INDICE
INTRODUZIONE...................................................................................................................................................................................
1. MOSES................................................................................................................................................................................................
1.1) Approccio procedurale e approccio dichiarativo...........................................................................................
1.2) Modellizzazione gerarchica e modulare di una realtà fisica.............................................................
1.2.1) Modelli semplici.....................................................................................................................................................................
1.2.2) Modelli composti...................................................................................................................................................................
1.2.3) Standardizzazione delle interfacce..................................................................................................................................
1.2.4) Connessioni tra i terminali................................................................................................................................................
1.3) Implementazione di MOSES su Database...............................................................................................................
2. VisualMOSES..............................................................................................................................................................................
2.1) Creazione e memorizzazione dei modelli.............................................................................................................
2.2) Gestione dell’accesso concorrente........................................................................................................................
2.3) Salvaguardia dei dati da accesso non autorizzato.................................................................................
2.3.1) Le figure di utente................................................................................................................................................................
2.3.2) Il meccanismo dei diritti.....................................................................................................................................................
2.3.3) Integrazione dei due meccanismi.....................................................................................................................................
2.4) Backup e restore della libreria.................................................................................................................................
3. GemStone.....................................................................................................................................................................................
3.1) Caratteristiche dei database ad oggetti...........................................................................................................
3.1.1) Memorizzazione flessibile dei dati...................................................................................................................................
3.1.2) Oggetti attivi........................................................................................................................................................................
3.1.3) Identità degli oggetti..........................................................................................................................................................
3.1.4) Persistenza degli oggetti....................................................................................................................................................
3.2) Architettura di GemStone.............................................................................................................................................
3.2.1) Stone......................................................................................................................................................................................
3.2.2) Gem.........................................................................................................................................................................................
3.3) GEODE.............................................................................................................................................................................................
3.4) LE INTERFACCE DI GEMSTONE..............................................................................................................................................
4. LE INTERFACCE GRAFICHE......................................................................................................................................................
4.1) Sistemi di windowing.........................................................................................................................................................
4.2) Portabilità..............................................................................................................................................................................
4.3) OSF/MOTIF: Ambiente di sviluppo di VisualMOSES...............................................................................................
4.4) Principi generali di progettazione di una interfaccia...............................................................................
4.4.1) Consistenza...........................................................................................................................................................................
4.4.2) Manipolazione diretta........................................................................................................................................................
4.4.3) Flessibilità............................................................................................................................................................................
4.4.4) Distruzione esplicita...........................................................................................................................................................
4.5) La rappresentazione ergonomica delle informazioni...............................................................................
4.5.1) Presentazione di dati, valori, informazioni....................................................................................................................
4.5.2) Parametri fisici ed ergonomici della rappresentazione dell’informazione..............................................................
4.5.3) Parametri fisici ed ergonomici dell’organizzazione dello schermo..........................................................................
4.6) Caratteristiche grafiche di VisualMOSES...........................................................................................................
4.6.1) Regole di stile di VisualMOSES.......................................................................................................................................
4.6.2) Parametri ergonomici.........................................................................................................................................................
5. IMPLEMENTAZIONE DEL CODICE..........................................................................................................................................
5.1) Implementazione dell’interfaccia grafica.......................................................................................................
5.1.1) Organizzazione delle classi di finestre............................................................................................................................
5.1.2) Organizzazione dei metodi................................................................................................................................................
5.2) Gestione della multi-utenza.......................................................................................................................................
5.2.1) Implementazione della libreria.........................................................................................................................................
5.2.2) Gestione o controllo della concorrenza.........................................................................................................................
5.2.3) Protezione dei dati da un accesso non autorizzato......................................................................................................
5.2.4) Backup e restore della libreria.........................................................................................................................................
6. ESEMPI DI FUNZIONAMENTO...................................................................................................................................................
6.1) Login, logout e navigazione della libreria........................................................................................................
6.1.1) Spostamento lento...............................................................................................................................................................
6.1.2) Spostamento veloce.............................................................................................................................................................
6.2) Costruzione di un impianto...........................................................................................................................................
6.2.1) Creazione della radice dell’impianto.............................................................................................................................
6.2.2) Assegnamento dei diritti sul modello..............................................................................................................................
6.2.3) Creazione di un modello semplice...................................................................................................................................
6.2.4) La copia dei modelli...........................................................................................................................................................
6.2.5) Il collegamento dei terminali............................................................................................................................................
6.2.6) Creazione di un modello aggregato................................................................................................................................
6.2.7) Operazioni preliminari alla simulazione di un impianto: versioni e stati d’impianto..........................................
6.3) Operazioni di competenza del Library Manager.............................................................................................
6.3.1) Creazione di un gruppo di lavoro....................................................................................................................................
6.3.2) Operazioni di manutenzione della libreria: backup e restore...................................................................................
Bibliografia..................................................................................................................................................................................
Il presente lavoro consiste nella progettazione e realizzazione di un ambiente grafico multiutente, denominato VisualMOSES, per la definizione di modelli matematici di sistemi fisici dinamici complessi. Si inserisce nel progetto dell’ambiente di simulazione MOSES in corso di sviluppo al dipartimento di elettronica e informazione del Politecnico di Milano.
In MOSES si vuole realizzare un ambiente per la modellizzazione e simulazione interattiva di sistemi dinamici in forma dichiarativa, ossia le equazioni del modello possono essere definite in forma implicita senza specificarne ingressi e uscite. Per poter comprendere il presente lavoro verrà tracciata una breve presentazione di MOSES nel capitolo 1.
Il capitolo 2 è dedicato alla presentazione di VisualMOSES trascurandone i dettagli implementativi. Tali dettagli sono stati inseriti nel capitolo 5 dopo aver descritto nei capitoli 3 e 4 rispettivamente, gli strumenti software utilizzati e le ‘regole di stile’ seguite per definire la veste grafica dell’interfaccia.
L’ambiente software nel quale è stato sviluppato MOSES è il database GemStone della Servio Corporation. Si tratta di un DBMS (Data Base Management System) ad oggetti al quale è stata recentemente aggiunta un’interfaccia grafica denominata GeODE che supporta delle funzioni per la gestione della grafica in ambiente OSF/MOTIF. L’ultima release di GemStone-GeODE ha consentito quindi, lo sviluppo di un’interfaccia utente semplice ed intuitiva.
Nel capitolo 6 è stato realizzato un manuale utente composto da una serie di tipiche sessioni di lavoro che mostrano tutte le funzionalità supportate dall’interfaccia.
Nella definizione di modelli matematici per la simulazione numerica di sistemi fisici dinamici, vi sono due approcci diversi; quello dichiarativo e quello procedurale. Prima di inoltrarci nella struttura propria di MOSES, li introdurremo entrambi per poter meglio comprendere le loro peculiarità. Per un maggior approfondimento di tutti gli aspetti del progetto MOSES si rimanda ai lavori precedenti riportati in bibliografia.
Un modello si dice in forma procedurale quando può essere espresso come una funzione che calcola le ‘uscite’ del componente quando sono dati gli ‘ingressi’.
Si è obbligati perciò a scegliere la causalità da imporre al modello, cioè definirne gli ingressi e le uscite. Nella maggior parte dei pacchetti di simulazione esistenti (SIMULINK, SPICE, CSSL), si è seguita questa strada perché il modello viene definito direttamente in una forma adatta alla simulazione numerica delle equazioni.
Il problema principale, legato a questa scelta, riguarda la bassa riusabilità dei modelli creati. La definizione di un modello dipende dal contesto nel quale è usato e può essere riutilizzato solo se ricompare nello stesso contesto.
L’approccio dichiarativo consente di risolvere questo problema, introducendone però altri ben più complessi.
Un modello si dice in forma dichiarativa se ad ogni componente è associato un modulo software indipendente dal contesto nel quale il componente è usato.
Si ha quindi una descrizione non causale dei componenti, perché non si definiscono ingressi ed uscite.
Il comportamento del componente fisico viene definito utilizzando bilanci di massa, quantità di moto, energia ed altre equazioni della fisica, anche scritte in forma implicita.
Tale forma però non può essere usata direttamente per la simulazione, perciò è necessario eseguire una manipolazione simbolica delle equazioni al fine di ottenerne una procedurale e di produrre, una volta definito il contesto, il codice di simulazione. Questa elaborazione verrà indicata con il nome di compilazione in quanto è analoga alla compilazione fatta su un pezzo di codice scritto in un linguaggio evoluto (la forma dichiarativa), che produce un codice eseguibile (la forma procedurale). La forma procedurale generata è un insieme di equazioni algebriche e differenziali (DAE).
Come riportato precedentemente, in MOSES si definiscono i modelli in forma dichiarativa con le peculiarità riportate nel resto di questo capitolo.
Un sistema fisico complesso è generalmente rappresentabile come aggregazione di sistemi più semplici, per i quali una ulteriore scomposizione risulterebbe in una diminuzione nella chiarezza del loro significato fisico.
Per modellizzazione gerarchica si intende la possibilità di definire un modello come aggregazione di altri più semplici, raggiungendo in questo modo un arbitrario grado di astrazione nella definizione del modello stesso. L’utilità di una gerarchia cresce al crescere della complessità dei modelli che si vogliono definire, dato che consente di modellizzare con una strategia ‘Top-Down’, utilizzata comunemente per ridurre in passi successivi la complessità di un problema.
In MOSES sono stati definiti essenzialmente due tipi di modelli; quelli che aggregano altri modelli e quelli che descrivono il comportamento di un componente fisico elementare.
Questi ultimi verranno chiamati modelli semplici, mentre gli altri saranno detti modelli composti. La rappresentazione di una parte di realtà fisica con un modello semplice invece di uno composto è arbitraria, in quanto è il modellista che decide come suddividere, di volta in volta, un modello complesso.
La modularità non è stata realizzata unicamente attraverso l’approccio dichiarativo, ma anche standardizzando i modi nei quali i singoli moduli possono scambiarsi le informazioni. Tali modi sono chiamati ‘terminali del modello’.
Contengono la descrizione matematica, in forma dichiarativa, del comportamento di una porzione di realtà, che può essere ad esempio una resistenza elettrica, una valvola o il giunto rotazionale di un robot. C’è la possibilità di definire sia modelli a tempo continuo che a tempo discreto, ed entrambi hanno le seguenti componenti fondamentali:
· variabili: rappresentano quantità di valore variante nel tempo.
· parametri: sono coefficienti numerici il cui valore è noto solo quando il modello è usato in una specifica occasione.
· equazioni: rappresentano il comportamento del modello usando le variabili ed i parametri in esso definiti.
· terminali: rappresentano l’interfaccia del modello col mondo esterno.
Un modello composto ha unicamente la funzione di aggregare altri modelli che possono essere semplici oppure composti a loro volta.
Tali modelli si distinguono in:
I. Generici: contengono informazioni riguardanti le connessioni tra i terminali dei sottomodelli (vedi par.1.2.4).
II. Impianti: contengono la porzione di realtà che si vuole modellizzare per una simulazione, ossia sono gli oggetti radice della gerarchia di aggregazione. L’informazione contenuta per la simulazione è così strutturata:
A. Versione: attribuisce i valori ai parametri del modello. Spesso si fanno diverse simulazioni sullo stesso impianto, cambiando solo i valori di alcuni parametri. Tutto ciò non porta a definire diversi modelli simili, ma ad associare ad un unico modello le varie versioni, ciascuna delle quali rappresenta l’insieme dei valori dei suoi parametri.
B. Stato d’impianto: fissa i valori iniziali delle variabili esogene e di stato, completando così la definizione dei dati necessari per la simulazione. Lo stato d’impianto si riferisce ad una versione perché, solamente quando un impianto è completamente definito può possedere una condizione di funzionamento.
Un terminale è un insieme di variabili i cui valori sono condivisi fra il modello ed il suo ambiente. Tali variabili si dicono esportate dal modello. Ogni forma di scambio di potenza ha un suo terminale; esiste un terminale per scambiare potenza elettrica, uno per scambiare potenza meccanica e così via. Questi terminali vengono chiamati terminali fisici. Esiste anche un secondo tipo di terminale chiamato terminale di controllo. Questi tipi di terminali possono esportare qualunque tipo di variabile.
I terminali fisici vengono rappresentati con una struttura ad albero che serve per organizzare logicamente le variabili. Tale struttura è stata standardizzata per ogni tipo di potenza scambiata.
La potenza esportata da un terminale è
sempre del tipo 
dove:
· Fi è una variabile di sforzo (effort) o intensiva. Queste variabili si trasmettono uguali attraverso il terminale (es.: la tensione nei circuiti elettrici e la pressione negli impianti idraulici).
· Wi è una variabile di flusso (flow) o estensiva. Queste variabili si trasmettono cambiate di segno attraverso il terminale (es: la corrente nei circuiti elettrici e la portata in quelli idraulici).
I terminali di controllo non sono soggetti a standardizzazione della struttura ma contengono semplicemente la lista degli elementi esportati. L'utente può estenderne la struttura a seconda delle sue esigenze. Si suddividono in terminali di ingresso e terminali di uscita. Ad ognuno di essi è quindi associata una causalità che serve a individuare le variabili esogene nelle equazioni del modello.
Una connessione rappresenta l'interazione tra due modelli, i quali si scambiano informazioni attraverso due terminali.
Esistono due tipi di connessioni:
1. Connessioni orizzontali: sono legami tra modelli che stanno al medesimo livello di aggregazione. Una connessione orizzontale dichiara che le variabili corrispondenti associate ai terminali condividono lo stesso valore se sono variabili di sforzo, ed hanno valore opposto se sono di flusso. La corrispondenza fra le variabili è dedotta automaticamente dalla loro posizione nel terminale.
2. Connessioni verticali: sono legami che coinvolgono un terminale di un modello ed un terminale di un sotto-modello. Il terminale del modello contenitore agisce come rappresentante del terminale del modello contenuto, perciò possiamo dire che le connessioni verticali realizzano il meccanismo di astrazione nell’aggregazione dei modelli.
L’elevata riusabilità dei modelli creati, resa possibile dall’approccio dichiarativo e dalla standardizzazione delle interfacce, ha fornito un valido motivo per sviluppare MOSES utilizzando un database. Un tipico database può fornire infatti numerose facilitazioni per l’archiviazione ed il reperimento dei modelli creati in una libreria. Per organizzare meglio la ricerca di un modello in libreria sono state introdotte delle partizioni sui modelli memorizzati. Una partizione è realizzata tramite categorie, le quali non sono altro che raggruppamenti di modelli uniti da un tema comune. Un esempio di tale partizione è la creazione di una categoria per modelli robotici, una per modelli elettrici e così via. Ovviamente sono a discrezione del modellista le modalità di organizzazione dei modelli memorizzati.
E’ stato scelto il database GemStone della Servio Corporation, il quale consente un accesso multiutente ai dati memorizzati, permettendo in tal modo collaborazioni tra tutti gli utenti di MOSES. Questa possibilità conduce alla delineazione di differenti figure di utenti, ognuna delle quali indica il modo o i limiti di accesso di un utente alla libreria. Tutto questo sarà comunque approfondito nel successivo capitolo.
VisualMOSES gestisce l’interazione tra l’utente e MOSES attraverso una rappresentazione grafica delle strutture dati di MOSES. Il suo utilizzo non richiede nessuna conoscenza del database sul quale è stato implementato, in quanto incapsula in modo semplice e intuitivo le principali funzionalità di un tipico database multiutente, ovvero:
· Creazione e memorizzazione di modelli
· Gestione dell’accesso concorrente da parte di più utenti ai modelli memorizzati
· Salvaguardia dei dati da un accesso non autorizzato
· Backup e restore dei modelli creati
I modelli creati in questo ambiente sono contenuti in un oggetto chiamato libreria. Si è scelto di creare un’unica libreria per tutti gli utenti, in modo da facilitare la collaborazione tra di essi.
L’idea fondamentale sulla quale si basa VisualMOSES è che l’utente lavora direttamente nella libreria, creando nuovi modelli o apportando modifiche a quelli esistenti.
Le operazioni di creazione e di memorizzazione sono quindi, in VisualMOSES, un’unica operazione logica che potremmo definire come una operazione di modifica della libreria.
Il modello concettuale della libreria che VisualMOSES fornisce all’utente è quello di un archivio i cui modelli sono organizzati gerarchicamente in una struttura ad albero, come in fig.2.1.
La rappresentazione grafica della libreria e delle funzioni eseguibili su di essa sono riportate nella seconda parte del capitolo 4. Nella prima parte sono riportate le linee guida più importanti per la progettazione delle interfacce grafiche. La lettura di quest’ultima è importante per capire ogni decisione adottata nella progettazione di questo ambiente.
VisualMOSES permette a più utenti di poter lavorare contemporaneamente ad uno stesso progetto, impedendo quelle operazioni che porterebbero la libreria in una condizione di inconsistenza logica. A tale proposito, un esempio intuitivo è la modifica contemporanea delle componenti di un modello semplice da parte di due utenti. Se infatti l’utente A ne modifica i parametri mentre l’utente B ne modifica le equazioni, il modello risultante nel database non rappresenterà ne il modello pensato da A ne quello da B.
Oltre a questa situazione banale possono presentarsene altre più sottili per capire le quali occorre addentrarsi nel funzionamento di GemStone. Per il momento basti sapere che è stato messo a punto un meccanismo, comunemente chiamato di locking, che permette di evitare queste situazioni di incongruenza logica dei dati.
Operativamente è necessario, prima di apportare una qualunque modifica ad una o più entità della libreria, mettere un blocco su tutte le entità coinvolte nell’operazione. Tale blocco serve ad impedire che altri utenti possano apportare contemporaneamente delle modifiche alle stesse entità. Per capire quali siano tutte le entità che occorre bloccare, bisogna rifarsi alle strutture dati di MOSES e analizzare gli eventuali legami coinvolti nell’operazione prescelta. Alcuni di questi legami sono evidenti, non è possibile cancellare un modello semplice contenuto in un aggregato senza modificare quest’ultimo. Occorrerà quindi bloccare entrambi i modelli, prima di eseguire l’operazione.
Il bloccaggio di un modello comporta l’invalidazione di tutti gli oggetti grafici appartenenti agli altri utenti che rappresentano il modello bloccato oppure una sua componente. L’invalidazione di una finestra significa che il modello rappresentato è in fase di modifica e quindi non è assicurata la coerenza tra ‘modello rappresentato nella finestra’ e ‘modello contenuto in libreria’.
Le limitazioni sull’accesso ai modelli sono state realizzate attraverso una definizione delle varie figure di utente e l’assegnamento ai modelli di alcuni diritti. Questi due meccanismi danno la possibilità di configurare la “vista di un utente” della libreria, permettendone così una buona adattabilità a specifici contesti applicativi.
Questo meccanismo serve per limitare le funzioni eseguibili da un utente generico sulla libreria.
Sono state previste le seguenti tipologie di utente:
· Library Manager: Si occupa dell’assegnamento di account a nuovi utenti, della loro organizzazione in gruppi di lavoro e della manutenzione della libreria.
· Group Manager: Si occupa del coordinamento del suo gruppo di lavoro.
· Simple User: Costruisce e simula i modelli presenti in libreria.
Nella figura 2.2 è riportata l’organizzazione gerarchica delle 3 tipologie; le operazioni possibili ad un livello sono possibili anche a livello superiore.
Un modello è accessibile ad un utente con modalità definite attraverso una serie di 4 attributi:
1. None: il modello non è visibile in libreria.
2. Read: è possibile la sola lettura.
3. Modify: è possibile la modifica dei dati contenuti nel modello.
4. Delete: è possibile cancellare il modello dalla libreria.
Gli attributi sono ordinati dal più debole al più forte, da n°1 al n°4, in modo che un attributo implichi tutti quelli precedenti. L’attributo delete serve solamente ad impedire una errata cancellazione dei dati.
Il meccanismo dei diritti è più forte di quello di locking perché un utente avrà accesso solo ai modelli per i quali il suo diritto è almeno read, mentre gli altri resteranno ‘invisibili’. Inoltre non potrà bloccare un modello se non possiede almeno il diritto modify. La possibilità di assegnare i diritti è limitata ai modelli che si trovano in una categoria, in quanto si considera logicamente unitario uno stesso progetto di lavoro, sia esso un impianto o un modello aggregato.
Occorre definire le modalità con le quali un utente può assegnare i diritti per un modello.
L’utente che crea un modello ne diventa il proprietario.
Ogni Simple User può assegnare i diritti unicamente per i modelli dei quali è il proprietario, mentre ogni Group Manager può assegnare i diritti per tutti i modelli il cui proprietario è un membro di un loro gruppo. Il Library Manager potrà ovviamente assegnare i diritti per tutti i modelli contenuti nella libreria.
Per semplificare il meccanismo dei diritti, si è deciso di rendere possibile l’assegnamento di specifici diritti solo per tre entità:
· Proprietario del modello
· Gruppi di appartenenza del proprietario
· Mondo ovvero qualsiasi utente
Sarà quindi possibile ad esempio rendere un modello invisibile al mondo, leggibile da alcuni gruppi e modificabile da altri ma cancellabile esclusivamente dal proprietario.
Queste operazioni sono state implementate per completare le funzionalità minime dell’ambiente ma attualmente possono essere eseguite esclusivamente sull’intera libreria dei modelli e non su una sua parte.
L’operazione di backup crea una copia della libreria su file, mentre quella di restore esegue l’operazione inversa. L’unica scelta operabile dall’utente è quella di definire la locazione del file creato specificandone il path di destinazione.
Il compito di eseguire tali operazioni è stato demandato al Library Manager, il quale dovrà periodicamente farsi carico di questa incombenza.
Le masse di dati utilizzati dalle applicazioni odierne sono troppo complesse e articolate per essere rappresentate ed elaborate con i tradizionali strumenti. Un esempio di queste applicazioni sono i sistemi di produzione “real time”, le modellizzazioni e simulazioni matematiche, i sistemi CAD (computer aided design), CASE (computer aided software engineering). L’utilizzo di sistemi basati su database relazionali si è dimostrato inadeguato per applicazioni che implicavano l’utilizzo di grandi e complesse strutture dati soprattutto quando queste risultavano altamente intercorrelate.
Questi tipi di applicazioni richiedono una differente struttura organizzativa, da cui la nascita dei database ad oggetti.
GemStone (da noi utilizzato) è un database ad oggetti puro.
I database ad oggetti forniscono i medesimi servizi di quelli tradizionali quali:
· archiviazione, reperimento e sicurezza dei dati.
· limitazione in fase di accesso ai dati tramite un meccanismo di autorizzazioni.
· controllo dell’accesso concorrente di diversi utenti attraverso la gestione delle loro transazioni.
Nei paragrafi successivi vengono analizzate alcune caratteristiche salienti dei database ad oggetti, mentre per un ulteriore approfondimento si rimanda a [Gupta & Horovitz ‘91] e [GEMSTONE 1993].
La maggior parte dei database tradizionali richiedono ai programmatori di modellare i dati come un insieme ordinato di campi (record) fortemente tipizzati. Per esempio, i sistemi tradizionali richiedono che i dati vengano rappresentati come gruppi di tabelle bidimensionali le cui relazioni vengono definite da speciali colonne e tabelle separate.
I database ad oggetti superano questa forte restrizione permettendo di memorizzare i dati in strutture che sono consone alla loro stessa natura. ([GEMSTONE 1993, cap 1.3]).
Le applicazioni che lavorano su database, utilizzano programmi per manipolare i dati.
Nei sistemi database relazionali, i programmi risiedono nelle applicazioni e i dati nel database vero e proprio. Nei database ad oggetti invece l’idea è quella di immagazzinare i programmi con i dati stessi.
Ci sono fondamentalmente due tipi di database ad oggetti: quelli che memorizzano dati passivi e quelli che memorizzano dati attivi. I database ad oggetti passivi sono molto simili a quelli relazionali per il fatto che i dati e programmi che operano sui dati sono memorizzati separatamente.
I database attivi (come GemStone) incapsulano metodi e dati dentro negli oggetti rendendo così gli oggetti attivi. ([GEMSTONE 1993, cap 1.4]).
Una ragione che rende i database ad oggetti così potenti è che ciascun oggetto ha una unica identità indipendentemente dallo stato dello stesso. Nei database tradizionali ciascun elemento è memorizzato in tabelle ed identificato dalla sua chiave primaria.
Nei database ad oggetti un oggetto è referenziato da un numero generato internamente chiamato identificatore (o puntatore).Questo numero è indipendente dal valore, stato e indirizzo dell’oggetto stesso. ([GEMSTONE 1993, cap 1.5]).
La persistenza di un oggetto è strettamente legata all’idea che ciascun oggetto possiede caratteristiche uniche e invarianti indipendentemente dal fatto che cambi stato.
Un oggetto la cui natura e i cui riferimenti ad altri oggetti, viene garantita attraverso le varie sessioni di lavoro viene detto persistente. ([GEMSTONE 1993, cap 1.5]).
GemStone è costituito da una base di dati sulla quale operano due tipi di processi: Gem e Stone.
L’architettura è di tipo client-server. In ogni database GemStone esiste un solo processo Stone che opera da server ai processi Gem e tanti processi Gem che operano da server per l’applicazione. ([GEMSTONE 1993, cap 2]).
Poiché GemStone è un database multiutente, le operazioni di sincronizzazione e allocazione delle risorse devono essere coordinate per mantenere consistenza nel database.
Le sue funzionalità tipiche sono:
· Controllo di operazioni di login e logout.
· Allocazione delle pagine nel database.
· Creazione di identificatori agli oggetti su richiesta di un processo Gem, per identificare nuovi oggetti.
· Gestione della concorrenza in fase di modifica degli oggetti del D.B. da parte di un processo Gem.
· Meccanismo di recovery.
Le sue funzionalità tipiche sono:
· Archiviazione e il recupero dei dati su disco.
· Compilazione ed esecuzione di programmi.
Ciascun processo Gem è composto di un programma per l’utilizzo e la creazione di nuovi dati e di un interfaccia per la traduzione e la comunicazione tra l’applicazione e il database.
GemStone fornisce un proprio ambiente di sviluppo chiamato GeODE, GemStone Object Development Enviroment ([GEMSTONE 1993, cap 2.2]), che consiste di un insieme di strumenti (di cui molti anche grafici) per la costruzione di applicazioni software. Il suo linguaggio di programmazione è OPAL ([GEMSTONE 1993, cap 4],[Goldberg &Robson ‘83]), un linguaggio ad oggetti puro derivato da Smalltalk.
Oltre al già citato linguaggio di programmazione OPAL, le applicazioni che risiedono in GemStone possono essere scritte in C++, Smalltalk e COBOL. Ciò comporta l’uso di specifiche interfacce, quali GCI (GemStone C interface) e GSI (GemStone Smalltalk interface). ([GEMSTONE 1993, cap 2-6, 2-7, 2-8, 2-9]).
Lo stato dell’arte della modalità di interazione uomo-macchina, si è rapidamente evoluto nell’ultimo decennio dalle tecniche di dialogo unicamente testuale, caratteristiche dei primi sistemi interattivi, alle attuali interfacce grafiche di tipo WIMP (Windows, Icons, Menu, Pointing).
L’affermazione delle interfacce utente grafiche GUI (Graphic User Interface) ha portato all’adozione della metafora della scrivania (desktop) che utilizza per la sua rappresentazione il paradigma WYSIWYG (What You See Is What You Get), secondo la quale tutte le azioni devono produrre un feedback visivo immediato sullo schermo, e ha come modalità di interazione la manipolazione diretta.
Questa evoluzione ha dato un significativo contributo all’accessibilità dei sistemi informatici da parte di un più vasto pubblico. Infatti l’uso estensivo dei simboli grafici rende l’interfaccia molto intuitiva e facile da usare.
L’introduzione delle interfacce ha dato inoltre un impulso fondamentale all’approfondimento del rapporto uomo-macchina mettendo in risalto i principi fondamentali di cui occorre tenere conto nella progettazione di interfacce, come la consistenza e la dipendenza contestuale. Per quanto riguarda la consistenza, l’interfaccia deve presentare uniformità nei comandi così che l’utente, dopo aver compreso la logica di funzionamento, possa utilizzarla nei diversi contesti in cui si trova ad operare. Relativamente alla dipendenza contestuale, solo le informazioni rilevanti allo stato in cui si trova l’applicazione dovrebbero essere visualizzate.
In seguito all’introduzione delle GUI la realizzazione di interfacce è diventato però un processo ad alto impegno di risorse umane: sono quindi necessari ambienti di sviluppo e metodologie che consentano una riduzione significativa di tale impegno non solo nelle fase di sviluppo ma anche di mantenimento dell’applicazione.
Le interfacce utente grafiche (GUI) consistono di un sistema di windowing o sistema a finestre che controlla gli oggetti sullo schermo e di un insieme di regole che determinano lo stile di comportamento degli oggetti sulla finestra.
Un sistema di windowing fornisce un ambiente a finestre in cui più applicazioni possono coesistere sullo stesso schermo, cioè ogni applicazione condivide lo schermo con altre applicazioni utilizzando una finestra per interagire con l’utente. Vengono inoltre fornite facilitazioni per la condivisione di dati fra applicazioni diverse.
Generalmente i compiti inerenti alla gestione delle finestre quali il controllo del posizionamento e delle dimensioni delle finestre vengono svolti da una applicazione dedicata chiamata window-manager.
La logica con cui opera una applicazione interattiva sviluppata in ambiente di windowing è event-driven. Una applicazione che gira sotto interfaccia grafica cede il controllo all’utente, che dirige le azioni della applicazione stessa tramite una serie di eventi. Applicazioni event-driven sono guidate e controllate da eventi che vengono comunicati dal sistema all’applicazione. Il sistema genera eventi per esempio quando l’utente preme un tasto della tastiera o del mouse.
Fra i sistemi di windowing più diffusi si possono ricordare i seguenti: Macintosh, Microsoft Windows, OS/2, X Window. A differenza degli altri, X Window, non può essere classificato come una GUI completa, nell’accezione precedente, perché non ha uno stile predefinito. Tuttavia proprio per questo viene utilizzato come sistema di windowing di base per molte GUI; ad esempio OSF/MOTIF si basa su X-Window.
Per un maggiore approfondimento di X-Window si rimanda a [Johnson & Reichard ‘92] e a [Young ‘90].
I benefici derivanti dalla adozione di uno standard di interfaccia grafica, che determinano la portabilità di una GUI su applicazioni diverse possono essere visti sotto i duplici aspetti:
· Standard d’uso dell’utente che consente uniformità e quindi rapidità di apprendimento a fronte di applicazioni diverse.
· Standard di sviluppo software che consentono la creazione e la interoperabilità di applicazioni in ambienti distribuiti e eterogenei.
Esiste un aspetto problematico legato agli standard: i tempi lunghi necessari per la loro definizione, accettazione e la diffusione rischiano di non tenere il passo dell’evoluzione tecnologica.
Nonostante questi problemi la necessità di operare in ambienti standard è reale, ed è testimoniata dal fatto che, in mancanza di quelli ufficiali, in questi ultimi anni si sono imposti standard di fatto quali OSF/MOTIF ([Berlage ‘91]).
Le regole di stile determinano il “look and feel” di una GUI e specificano come gli oggetti grafici come menù, icone, finestre di dialogo dovrebbero apparire e quali dovrebbero essere le loro caratteristiche funzionali.
Se i suggerimenti di stile non vengono seguiti si rischia di perdere parte dei benefici derivanti da una GUI; per questo è importante avere degli strumenti che assistono lo sviluppatore nella creazione di interfacce conformi alle linee guida.
A questo scopo diversi toolkit forniscono librerie di componenti di base precostituiti (come ad esempio pulsanti, menù, finestre di dialogo) per la costruzione di interfacce.
OSF/MOTIF, ambiente di sviluppo di VisualMoses, fornisce strumenti di controllo e di impostazione dell’ambiente di lavoro molto evoluti. Sono di tipo grafico e sono stati studiati prendendo spunto dagli oggetti che ci circondano nella vita reale, come i pulsanti della radio, i pulsanti della luce, insomma oggetti con cui l’utente ha molta famigliarità in seguito al loro utilizzo nella vita quotidiana e che quindi rendono il lavoro molto intuitivo.
Gli strumenti di controllo utilizzati dall’ambiente sono fondamentalmente di tre tipi:
· Pulsanti che si attivano semplicemente tramite selezione.
· Finestre di ausilio allo specifico problema che contengono uno o più pulsanti da attivare con testi di spiegazione.
· Indicatori di stato che, come si può intuire, permettono la valutazione dello stato della applicazione.
I seguenti quattro punti possono considerarsi fondamentali ai fini del progetto di una buona interfaccia:
1. Consistenza.
2. Manipolazione diretta.
3. Flessibilità.
4. Distruzione esplicita.
Ad una applicazione è richiesta la prerogativa della consistenza con sé stessa e con le altre applicazioni che condividono lo stesso ambiente.
Consistenza significa :
· I controlli simili operano in maniera simile e hanno usi simili.
· Le stesse azioni hanno sempre lo stesso risultato.
· Una applicazione deve presentare le sue funzionalità in modo ordinato.Quelle necessarie e di uso comune devono essere presentate per prime e in ordine logico. Per esempio, funzioni essenziali devono essere incluse in una barra di menù poste in alto all’area di lavoro utente, in modo da risultare sempre visibili e di facile selezione.
· Funzionalità più sofisticate o di minor utilizzo devono risultare non direttamente visibili ma pur sempre raggiungibili.
Si ricorda che la consistenza accresce il senso di padronanza dell’utente sulla applicazione. L’utilizzo di una applicazione può rendersi proficuo anche per un’altra, creando un positivo travaso di conoscenza dall’una all’altra.
Quando un’applicazione lavora in maniera consistente rispetto ad un’altra applicazione l’utente si trova nelle condizione di essere confidente nelle sue capacità di utilizzare proficuamente il programma.
([HP OSF/MOTIF ‘93, cap 1-2]).
La manipolazione diretta riguarda l’interazione tra l’azione di un utente e la risposta osservabile dell’oggetto sul quale è stata compiuta l’azione.
Con la manipolazione diretta si simula un ambiente di lavoro reale, nel quale se l’utente compie una azione su un oggetto, riesce a percepire il cambiamento di stato dell’oggetto stesso e quindi a valutare se l’azione ha avuto il risultato desiderato o no.
([HP OSF/MOTIF ‘93, cap 1-3]).
Il termine flessibilità sta ad indicare insieme operabilità e configurabilità.
Essa implica fornire all’utente molti modi di accedere alle funzioni della applicazione, al fine di accrescere il suo senso di controllo.
Per esempio, una funzione deve essere accessibile attraverso menu, pull-down menù, o tramite la digitazione multipla di pulsanti. Il fatto di poter accedere in maniera multipla a funzioni del programma rende ovviamente molto versatile il suo utilizzo per utenti che hanno diverse esigenze, diverso grado di esperienza, preferenze personali o abitudini. ([HP OSF/MOTIF ‘93, cap 1-3]).
Distruzione esplicita significa che se una azione ha una conseguenza negativa irreversibile, deve essere richiesto all’utente conferma in modo tale da permettere eventuali ripensamenti.
Operazioni che causano la perdita di parti di applicazione devono avvisare l’utente sulle conseguenze dell’azione. Data la possibile gravità di tali azioni, esse dovrebbero essere rese inattuabili.
Ogni finestra di lavoro deve prevedere la funzione di aiuto (“help”) e il suo testo dovrebbe essere chiaro, conciso e scritto in linguaggio facilmente accessibile. La funzione di help deve essere facilmente richiamabile e altrettanto facilmente eliminabile.
([HP OSF/MOTIF ‘93, cap 1-4]).
Si riportano le più recenti linee guida relative agli argomenti connessi alla rappresentazione e alla codifica delle informazioni sugli schermi. Le linee guida raccolte sono state suddivise in tre sottoinsiemi corrispondenti ad altrettanti argomenti unitari.
In particolare sono state analizzate e riportate le guidelines riguardanti:
1. Presentazione dei dati, valori, informazioni.
2. Parametri fisici ed ergonomici della rappresentazione dell’informazione.
3. Parametri fisici ed ergonomici dell’organizzazione dello schermo.
Molti studi condotti nell’ambito della teoria della informazione, hanno dimostrato che è profondamente errato fornire troppe informazioni ad un operatore che si trovi ad interagire con qualsiasi tipo di display. Troppe fonti di informazioni portano inevitabilmente a commettere omissioni.
Un eccessivo numero di dettagli diventano “rumore” di fondo nel quale l’informazione diventa difficilmente reperibile. D’altro canto se l’informazione è carente si possono avere errori dovuti al fatto che l’operatore deve affidarsi ad interpolazioni o estrapolazioni tra i valori informativi dati.
Linee guida :
· Il rapporto tra la percentuale di video occupata da informazioni-figure e quella libera non dovrebbe mai superare il 50%, ma il rapporto ideale è del 30%.
· Vanno riportate solo le informazioni-figure necessarie o comunque utili al processo decisionale.
· Tutte le informazioni utili ad un unico processo devono preferibilmente essere accorpate in un unico schermo.
· Le informazioni-figure devono essere raggruppate in base ad un criterio unificante. I criteri più seguiti sono: l’importanza, la frequenza, o la funzione dei messaggi riportati.
· Ogni pagina video contenente informazioni deve essere titolata. Il titolo della pagina deve essere riportato nella parte alta della pagina video.
· L’ampiezza dell’informazione grafica deve tener conto della distanza dell’operatore dal video.
([Brown ‘81] e [Eastman ‘83]).
I parametri fisici attraverso i quali le informazioni vengono rappresentate su video sono stati suddivisi in due principali sottoinsiemi corrispondenti alle più importanti caratteristiche inerenti la rappresentazione:
1. Colore.
2. Forma.
Il colore è una caratteristica a detezione automatica e come tale ha un accesso più diretto al sistema di elaborazione dell’informazione dell’uomo. In una persona non affetta da particolari deficit visivi e percettivi, l’impiego del colore rappresenta un netto vantaggio rispetto ad altri tipi di simbologia ed è stato dimostrato come il colore sia più direttamente codificabile rispetto ad altre caratteristiche o ai simboli.
Va tuttavia sottolineato come l’impiego del colore deve tener conto di una serie di indicazioni e di linee guida che, se non soddisfatte, possono causare problemi dovuti ad incompatibilità tra tipo di colore e consolidata esperienza legata alla simbologia del colore stesso.
Linee guida :
· L’impiego del colore riduce l’eventuale confondibilità delle informazioni e ne accorcia il tempo di ricerca.
· Il colore facilita l’individuazione spaziale dell’informazione.
· Rispetto ad altri tipi di codici visivi quali ad esempio la forma e la dimensione il colore risulta essere quello che viene rilevato in maniera più automatica e quindi più veloce.
· Quando le informazioni vengono codificate in base al colore, i codici devono essere compatibili con le altre pagine e gli altri schermi nei quali i codici sono stati impiegati.
· Eventuali codici trasmessi con il colore devono essere compatibili con il significato che tradizionalmente hanno nell’ambito del settore di applicazione.
· Generalmente, i colori che devono essere utilizzati di più sono: giallo, rosso, verde, blu.
· Quando il colore deve essere impiegato per favorire una qualche discriminazione non deve mai essere impiegati più di 8 colori.
([Christ ‘75], [Bagnara ‘84], [Bagnara & Groppelli & Nicoletti & Zaretto ‘93]).
L’impiego della forma nelle varie simbologie grafiche può essere suddivisa in due distinte categorie:
1. Rappresentazione schematica dell’oggetto che si vuole rappresentare.
2. Simboli grafici che non hanno alcuna attinenza grafica con il concetto che devono rappresentare e come tali devono essere appresi dall’utente.
Linee guida:
· Generalmente diverse forme sono codificate più velocemente di differenti etichette verbali.
· Quando la forma collegata ad un concetto deve essere impiegata più volte è opportuno che la forma sia rappresentata in diverse dimensioni per facilitare la generalizzazione del simbolo.
· Quando la comprensione è di fondamentale importanza la forma è preferibile al simbolo.
· Il codice rappresentato da una data forma deve essere mantenuto costante per tutto il contesto e per le varie pagine eventualmente impiegabili.
· Ogni simbolo oltre a dover essere analogo tra tutte le pagine eventualmente impiegate, deve essere scelto tenendo conto degli standard e deve poter essere condiviso da diversi utenti.
· Quando è possibile è preferibile impiegare forme che rappresentino, seppur schematicamente, l’oggetto o il concetto piuttosto che forme basate esclusivamente sull’idea astratta.
· Il numeri massimo di simboli che possono essere impiegati nello stesso contesto non deve mai superare i 20 anche se il numero ottimale è di 7/8.
· Quando i simboli vengono impiegati unitamente ai colori,l’informazione deve essere veicolata da uno soltanto dei due elementi.
· Qualsiasi simbolo deve essere rappresentato nel modo più semplice possibile.
([King & Tierey ‘70], [Mosier ‘86]).
Linee guida:
· I pulsanti che devono essere attivati in rapida successione devono essere adiacenti o comunque in un rapporto di vicinanza.
· Un concetto molto importante è quello di compatibilità spaziale nel senso che i pulsanti che vengono utilizzati più frequentemente e in vari spazi di lavoro devono trovare uguale disposizione in tutte le applicazioni.
La progettazione della veste grafica di VisualMOSES si avvale oltre che delle argomentazioni generali trattate nei precedenti paragrafi (4.1, 4.2, 4.3, 4.4) anche dell’analisi di alcuni pacchetti software che utilizzano la grafica per l’interazione con l’utente. I programmi considerati, per l’attinenza con l’ambiente e la vasta diffusione che ottengono negli ambienti in cui si fa’ simulazione, sono Simulink e Labview. Si è cercato di analizzarne le logiche di funzionamento per poterne poi reimplementare le caratteristiche salienti, pensando che un tale approccio consenta di ridurre le difficoltà di apprendimento del nostro ambiente per utenti che abbiano già lavorato con i due pacchetti software citati.
Si è cercato di rappresentare oggetti concettualmente e strutturalmente simili con un unico tipo di finestra, ricorrendo a differenziazioni secondarie, quali colore e etichette, per distinguere il tipo di oggetto rappresentato. L’esempio più importante è la rappresentazione di modelli composti e categorie. Entrambi sono contenitori di modelli con un’unica differenza strutturale fondamentale: i modelli aggregati in una categoria, non possono avere connessioni tra di loro. Si è quindi utilizzata la stessa finestra per rappresentare entrambi, impedendo semplicemente che l’utente possa effettuare una connessione in una categoria.
Definire un ambiente troppo strutturato, che vincoli rigidamente le azioni possibili all’utente, può risultare frustrante per un utente esperto ma utile per uno inesperto in quanto guiderebbe quest’ultimo verso la soluzione del problema. Si è scelto di privilegiare l’utente esperto, cercando di fornire la massima flessibilità nell’ordine delle operazioni da eseguire per ottenere un determinato risultato. L’utente inesperto, che comunque avrà letto il manuale, sarà aiutato (o guidato) da una serie di help disponibili localmente ed in ogni momento attraverso menù o pulsanti.
Abbiamo deciso di privilegiare l’utente esperto perché supponiamo si impari in tempi relativamente brevi ad usare in modo efficiente questo ambiente.
VisualMOSES consta di poche finestre primarie (quelle sulle quali si svolge gran parte del lavoro) e ciò consente di dare all’ambiente una veste particolarmente semplice ed intuitiva.
Al fine di accrescere l’uniformità del comportamento delle finestre (quindi di fornire consistenza all’ambiente), si è posta particolare attenzione alla modalità di visualizzazione dei comandi eseguibili sulla finestra. Si è adottata la strategia di rendere sempre visibili le voci legate alla finestra nella quale si opera e attivabili solamente quelle conformi allo stato dell’applicazione. Questo non solo consente di minimizzare l’insorgere di errori, ma anche di insegnare all’utente la logica di funzionamento dell’ambiente. Si ricorda che comunque in ogni finestra è disponibile una funzione di “help”, dal testo chiaro e conciso, che consente di comprendere e quindi di valutare le azioni attuabili nello specifico contesto.
Essendo VisualMOSES una ambiente grafico, tutte le azioni associate alle diverse finestre sono eseguibili tramite mouse. Alla modalità di azionamento di ogni suo pulsante (semplice “click” o doppio “click”) è associata una particolare azione che è indipendente dal contesto nel quale si trova l’utente.
Si ricorda a questo punto quali siano le azioni associate ai singoli tasti riportati in figura 4.1 con la relativa modalità:
1. Pulsante n°1 con semplice click:
Provoca la selezione dell’oggetto che si trova sotto il cursore e la contemporanea deselezione di quelli precedentemente selezionati. Nel caso che l’oggetto considerato sia un terminale e venga mantenuto premuto il primo pulsante si inizia una procedura di collegamento dei terminali.
2. Pulsante n°1 con doppio click:
A questa azione è associata l’operazione di inspect, ovvero la visualizzazione o modifica dell’oggetto sul quale si compie l’azione.
Si può eseguire su due elementi diversi:
· Inspect di un oggetto in veste grafica.
· Inspect di un elemento di una lista.
3. Pulsante n°2 con semplice click + trascinamento del mouse:
Implica lo spostamento di un oggetto,(ad esempio un modello) in una finestra, oppure da una finestra all’altra.
4. Pulsante n°3 con semplice click:
Provoca la visualizzazione di un menù momentaneo di azioni possibili sull’oggetto (menu Pop-up). Sempre rispecchiando la modalità di visualizzazione dei comandi definita in OSF/MOTIF vengono sempre visualizzate tutte le voci del menù e rese attivabili solamente quelle conformi allo stato della applicazione.
Come sancito dalle regole di stile proprie di OSF/MOTIF, in risposta ad ogni azione eseguita su un qualsiasi oggetto dell’ambiente è importante mandare un segnale all’utente (principio della manipolazione diretta), indicante l’esito dell’azione esercitata. Questo segnale può essere un semplice cambio di colore dello sfondo (azione di semplice selezione), un messaggio (di esito positivo o di errore) oppure una richiesta di conferma all’utente sull’azione da svolgere (generalmente associata all’azione di distruzione esplicita).
Infine si ricorda che le azioni eseguibili da un utente devono rispondere solamente ad una logica di corretto funzionamento, mentre viene lasciata ampia discrezionalità sull’ordine e sulle modalità di esecuzione delle medesime.
Molte azioni sono accessibili anche da tastiera, rendendo così particolarmente versatile l’utilizzo di VisualMOSES per utenti che hanno diversi gradi di esperienza, preferenze personali o abitudini.
E’ stata scelta una rappresentazione grafica simile al programma di simulazione Simulink, con rettangoli per rappresentare i modelli e linee per individuare i collegamenti. Tale rappresentazione si è rivelata la più flessibile e la più intuitiva nel definire la struttura di un impianto come aggregazione di sottomodelli semplici o aggregati. I terminali del modello sono rappresentati da rettangoli posti sul modello stesso.
Ogni modello, sia esso semplice, aggregato o categoria, presenta sempre due campi (vedi fig. 4.2), riportanti rispettivamente le seguenti informazioni:
· Campo 1: scritta del nome proprio del modello ed eventualmente una icona rappresentativa del fatto che il modello sia “bloccato”.
· Campo 2: scritta riportante il tipo del modello (semplice continuo, discreto, aggregato generico...) e relativa rappresentazione simbolica tramite icona. La differenza tra i modelli semplici e quelli aggregati è evidenziata dallo spessore del bordo del rettangolo (i modelli semplici presentano il bordo più fine).
· Una scritta ne riporta il nome.
· Ad ogni tipo di terminale è associato un colore. Essendo il numero di tipi di terminali esiguo, è possibile veicolare l’informazione con il colore, che come sappiamo è una caratteristica a detezione automatica per l’uomo.
Un collegamento è sempre rappresentato graficamente da una spezzata che collega due terminali (vedi Fig. 4.4)
1) Terminali di scambio potenza: Il collegamento è visualizzato con tratto continuo dello stesso colore dei terminali.
2) Terminali di scambio informazioni: Il collegamento viene visualizzato con tratteggio di colore nero.
In questo capitolo esporremo le scelte adottate nell’implementazione di VisualMOSES, riferendoci in modo più esteso agli strumenti software utilizzati. Si suppone che il lettore abbia familiarità con la programmazione object-oriented pura, ovvero conosca i concetti di classe, istanza e metodo. Saranno introdotti i concetti fondamentali, per quanto riguarda i database e la multi-utenza, prima di un loro utilizzo.
Per la definizione e costruzione delle finestre è stato utilizzato uno strumento di GeODE chiamato ‘Forms Designer’. Questo strumento fornisce un supporto grafico per la creazione e manipolazione di istanze delle classi di OSF/Motif e X-Toolkit. Per ogni finestra creata viene definita una classe OPAL, istanziando la quale si visualizzano automaticamente gli oggetti grafici relativi alla finestra. Agli eventi rilevati da una finestra è possibile associare delle azioni, ovvero invocare dei metodi di istanza della classe alla quale appartiene la finestra stessa. Un modo alternativo di gestire gli eventi nella finestra è quello di ricorrere ad una programmazione ‘Visual’, mediante uno strumento chiamato ‘Visual Program Designer’. Tale programmazione, valutate le possibilità fornite dallo strumento e le specifiche richieste a VisualMOSES, è stata ritenuta inefficiente e quindi non è stata utilizzata.
In sostanza, il Forms Designer è uno strumento che consente di progettare l’aspetto dell’interfaccia, ricercando la soluzione più soddisfacente attraverso una verifica immediata delle modifiche apportate. Ogni scelta implementativa dei metodi, sia nel contenuto che nella dislocazione, è tesa al raggiungimento di un elevato grado di modularità in modo da garantire un limitato sforzo nell’apportare successive modifiche o estensioni alle funzionalità.
L’inconveniente principale del Forms Designer è quello di non permettere la definizione di una gerarchia tra le classi associate alle finestre create. Le classi vengono create come sottoclassi di una finestra di base. Questa è sicuramente una grave limitazione, in quanto si rinuncia alla possibilità di sfruttare, a livello dell’aspetto grafico delle finestre, l’ereditarietà della programmazione object-oriented. Durante lo sviluppo di VisualMOSES, si è avuta la necessità di eseguire continui cambiamenti alla veste grafica delle finestre, per cercare di soddisfare al meglio le linee guida esposte nel capitolo 4. Senza tale strumento non sarebbe stato possibile collaudare rapidamente l’effettivo vantaggio apportato dai cambiamenti introdotti, a meno di significativi allungamenti dei tempi di lavoro.
Le operazioni fondamentali per la gestione grafica della finestra, come per esempio la chiusura o l’apertura della finestra stessa, sono ereditate dalla super-classe comune. Per quanto riguarda la manipolazione degli oggetti visualizzati nelle finestre, in ognuna di esse è stato implementato il codice strettamente necessario alla gestione del proprio oggetto, in modo da garantirne la corretta costruzione e archiviazione in libreria. In aggiunta, in ogni finestra è stato inserito del codice inerente alle proprie peculiarità grafiche.
Le operazioni globali, quelle cioè che coinvolgono tutte le finestre dell’applicazione sono state inglobate in una finestra ‘radice’ della sessione di lavoro, alla quale puntano tutte le finestre create successivamente.
Questa finestra, chiamata ‘Session Manager’ si occupa di incapsulare il funzionamento delle seguenti operazioni:
· Inizio/Termine sessione
· Gestione del buffer di sessione
· Ricerche globali nelle finestre aperte
· Attuazione del protocollo di locking
In sintesi, ogni metodo contenuto in una finestra manipola esclusivamente l’oggetto visualizzato, mentre per le operazioni globali si ricorre al Session Manager. Ciò dovrebbe garantire quella modularità necessaria per poter sviluppare separatamente ogni singola parte di questo lavoro.
GemStone fornisce ad ogni utente una lista di dizionari chiamata ‘Symbol List’. Ogni dizionario contiene gli oggetti accessibili dall’utente proprietario della Symbol List. Questi oggetti sono chiamati persistenti poiché rimangono memorizzati nella memoria del calcolatore attraverso le differenti sessioni di lavoro. Un’altra funzione fondamentale di questa lista è quella di permettere la condivisione dei dati da parte di più utenti. Se un oggetto compare in due dizionari diversi di due utenti diversi, entrambi potranno accedervi. Ogni utente VisualMOSES ha quindi un riferimento all’oggetto libreria nella sua Symbol List, in modo da potervi accedere.
La considerazione fatta nel capitolo precedente, riguardante le analogie tra categorie e modelli composti, si è mostrata molto utile nella definizione della struttura della libreria. Per riutilizzare il più possibile il codice definito in MOSES è stata semplicemente definita una nuova sottoclasse di ‘AggregateModel’ per la gestione delle peculiarità di una categoria o direttorio. La libreria ha quindi la struttura ad albero di un modello aggregato, la cui radice è una categoria.
Questa scelta ha consentito di riutilizzare interamente il codice MOSES esistente, dopo aver fatto piccole modifiche e aggiunte, per la creazione di un generico impianto e la navigazione in esso.
L’unicità della libreria, come detto precedentemente, facilita la collaborazione tra gli utenti semplificando notevolmente le modalità di scambio dati tra le varie sessioni di lavoro. Una sola libreria implica però una elevata probabilità di conflitto tra le varie transazioni concorrenti, in quanto più utenti si potrebbero trovare spesso ad operare sugli stessi dati. In questo tipo di transazioni è richiesta una elevata interazione con l’utente, il quale dovrà effettuare scelte complesse.
Le principali differenze tra queste transazioni e quelle classiche sono:
· Lunga durata. Una transazione interattiva è composta da operazioni complesse, durante le quali è richiesta l’interazione tra il calcolatore e l’utente. Le operazioni di creazione, modifica e simulazione di un impianto possono richiedere alcune ore.
· Scambio dati. Se diversi utenti stanno cooperando ad un progetto, può essere necessario che le transazioni si scambino dati prima di un eventuale commit.
· Sotto-compiti. Una transazione interattiva può essere composta da diversi compiti iniziati dall’utente. Questi può decidere di eseguire un abort su uno di questi compiti senza causare l’abort dell’intera transazione.
· Recoverability. E’ inaccettabile dover eseguire un abort di una transazione dovuto ad un crash del sistema. La transazione attiva deve essere ripristinata ad uno stato esistente poco prima del guasto, in modo da perdere poco lavoro ‘umano’.
· Performance. In un sistema transazionale interattivo con buone performance il tempo di risposta è molto breve. Questo è in contrasto con lo scopo che si vuole ottenere in sistemi non interattivi, rappresentato da un elevato ‘throughput’ (numero di transazioni al secondo) del sistema. Sistemi con elevato throughput sfruttano efficientemente le risorse del sistema. Tuttavia, in transazioni interattive la ‘risorsa’ più costosa è l’utente. Occorre quindi ottimizzare l’efficienza del sistema dal punto di vista dell’utente.
Maggiori dettagli sulle problematiche legate a questo tipo di transazione sono state trattate in [Korth & Silbershatz ‘91, cap 12.8, pag.413] con il nome di ‘Long-duration transactions’.
Una caratteristica importante di VisualMOSES è quella di permettere ad un utente di ispezionare la libreria, aprendo e chiudendo a piacere delle finestre sui modelli desiderati. C’è la possibilità che più utenti abbiano aperta una finestra sullo stesso modello, e che uno di essi decida di modificarlo. In tal caso occorre notificare tale azione agli altri utenti attraverso l’invalidazione delle relative finestre. In questo modo nessun utente cercherà di eseguire delle azioni su degli oggetti in fase di modifica da parte di un altro.
Fino a quando una transazione non termina, non vengono rese effettive le modifiche apportate agli oggetti persistenti. Se avviene un guasto nella memoria volatile quando la transazione non è ancora terminata, tutti i dati inseriti o modificati dall’ultima transazione conclusa con successo, verrebbero irrimediabilmente persi. In transazioni di lunga durata, quali sono le nostre, si rischia di perdere molto lavoro. Scomponendo una lunga transazione in diverse sub-transazioni, diminuiscono i rischi di perdere una quantità eccessiva di lavoro. Si ottengono così numerose transazioni, che però non incidono significativamente sulle prestazioni generali dell’interfaccia perché sono tutte di piccola entità. Tutto ciò garantisce all’utente una buona discrezionalità su come organizzare in sicurezza il proprio lavoro.
Qualche esempio chiarirà quanto esposto:
La creazione di un modello semplice è una transazione. Viene istanziata la classe prescelta e aggiunta alla libreria con il nome voluto dall’utente. L’aggiunta di ogni componente del modello rappresenta una sub-transazione. In caso di crash del sistema si perde solo l’ultima componente creata e non l’intera sessione di lavoro. Creando un modello composto l’utente può decidere se definirne prima la struttura interna oppure i collegamenti esterni con altri modelli. Qualunque sia la scelta fatta, l’utente rischierà di perdere solo l’ultima operazione.
GemStone fornisce tre tipi di locks:
1. Read: indica l’intenzione di leggere l’oggetto, senza che questo possa essere modificato da altri.
2. Write: indica l’intenzione di modificare l’oggetto
3. Exclusive: indica l’intenzione di usare l’oggetto in modo esclusivo, sia per lettura che scrittura.
Mentre i read-locks possono essere condivisi da più sessioni, gli altri due possono essere ottenuti da una sola sessione alla volta. Non è consentito l’upgrade di un lock da un tipo ad un altro. La granularità di locking in GemStone è ovviamente l’oggetto. Le sessioni concorrenti possono inviarsi dei messaggi costituiti da un codice numerico ed un campo di testo. I messaggi ricevuti da una sessione vengono contenuti in apposite liste e conservati fino alla loro lettura.
In VisualMOSES, abbiamo realizzato un protocollo di locking ‘manuale’, ovvero in cui l’utente decide quali modelli bloccare ed esegue l’operazione selezionando le voci dai menu dell’interfaccia. Quando un utente blocca un modello le altre sessioni ricevono un messaggio da quella sessione. Il codice associato al messaggio indica che è stato bloccato un modello e quindi occorre valutare se le finestre visualizzate sono valide.
Tuttavia va tenuto presente che l’invio di un messaggio non può forzarne la lettura, per cui si rischia di capitare nella seguente situazione:
· Un utente prende un lock sul modello.
· Le altre sessioni ricevono un messaggio ma non lo leggono subito.
· L’utente rilascia il lock prima che le altre sessioni abbiano letto il messaggio.
In questa situazione, l’unico modo per valutare se un modello è stato cambiato, è quello di controllare l’intera struttura di ogni finestra visualizzata. Ciò risulta molto oneroso in termini di tempo in quanto implica numerosi controlli inutili.
Per rendere più efficiente l’invalidazione delle finestre, è stato implementato il meccanismo delle firme. Questo meccanismo sostituisce parzialmente l’uso dei locks di sistema. Si basa su un dizionario di associazioni tra modelli e firme con la struttura di figura 5.1.
Il campo firma ha due sottocampi; uno per le firme in scrittura e l’altro per le firme in lettura. La firma in scrittura indica quale sessione che ha acquisito un blocco sul modello. La firma in lettura ha tre sottocampi che significano rispettivamente:
1. Sessione che visualizza il modello.
2. Finestra nella quale è visualizzato.
3. Coerenza del modello con la finestra.
Quando un utente acquisisce una firma in scrittura, tutti i campi n°3 delle firme in lettura relative alle altre sessioni, vengono poste a false. Sarà quindi possibile stabilire la validità della finestra con una semplice ricerca in questo dizionario. I locks di sistema sono stati impiegati per evitare l’insorgere di conflitti sulle modifiche al dizionario delle firme. In figura 5.2 è riportata la sequenza di operazioni necessaria per accedere al dizionario delle firme. Il tipo di lock dipende dal tipo di query. Per queries di lettura sarà un read-lock, per quelle di modifica un write-lock. Le operazioni di COMMIT servono per avere immagini aggiornate della libreria e del dizionario.
E’ evidente che con questo protocollo di locking non sono possibili situazioni di stallo (deadlock), in quanto si cerca di acquisire lo stesso lock per ogni query, quello sul dizionario.
L’aumento di carico del calcolatore, dovuto a questo meccanismo, si è dimostrato accettabile rispetto ai vantaggi apportati ed al complessivo funzionamento di VisualMOSES.
GemStone fornisce diversi meccanismi per proteggere i dati da un accesso non autorizzato. Un primo livello di protezione è il meccanismo di login, il quale attraverso la richiesta all’utente di userID e password, stabilisce un collegamento logico con il database.
Successivamente sono possibili tre tipi di protezione:
I. Occultamento del nome: se un oggetto non compare nella Symbol List dell’utente, questi non può accedervi.
II. Protezione procedurale: quando gli oggetti sono accessibili solo tramite metodi è possibile inserire dei controlli su chi è l’utente e agire di conseguenza.
III. Protezione non-procedurale: questo tipo di protezione si realizza con due meccanismi indipendenti :
A. Meccanismo delle autorizzazioni: Con questo meccanismo è possibile stabilire il tipo di accesso (none, read, write) per degli oggetti raggruppati in ‘segmenti’. Per ogni segmento è possibile definire i diritti per l’utente proprietario, per i membri di 4 gruppi e per tutti gli utenti di GemStone.
B. Meccanismo dei privilegi: Con questo meccanismo è possibile stabilire quali metodi ‘potenti’ può utilizzare un utente. Questi metodi si riferiscono alla possibilità di esercitare un controllo su tutti gli oggetti di GemStone, comprese le sessioni, e alcune funzioni di sistema. Alcuni di questi consentono di modificare le password, reperire informazioni sulle sessioni e gestirne il controllo, fino a modificare i segmenti permettendo così di violare senza problemi il meccanismo delle autorizzazioni.
Ritenendo troppo limitativa la possibilità di definire i diritti solamente per quattro gruppi, abbiamo implementato in VisualMOSES un meccanismo ibrido di protezione che comprende parte di tutti quelli sopra riportati.
Sostanzialmente è stata utilizzata una protezione procedurale, che permette di assegnare, per ogni modello di libreria, i diritti dell’utente proprietario, quelli di ogni gruppo al quale appartiene il proprietario e per tutti gli utenti di VisualMOSES.
Come già riportato i diritti si articolano nei seguenti 4 attributi: none, read, modify, delete.
Per rilasciare la restrizione dei quattro gruppi per i quali è possibile assegnare un diritto sul modello, è stato necessario implementare una gestione degli utenti diversa da quella di GemStone, che seppur appoggiandosi a quella predefinita per la creazione di un nuovo utente, ne estende le caratteristiche mantenendo dei dizionari degli utenti e dei gruppi di VisualMOSES.
Il meccanismo delle protezioni è stato utilizzato solamente per creare un segmento, accessibile ai soli utenti VisualMOSES, nel quale riporre la libreria.
Queste operazioni sfruttano direttamente le funzioni fornite da GemStone per il trasferimento su file, ed il successivo ripristino, di oggetti.
Lo scopo di questi esempi è quello di far acquisire fiducia all’utente sull’ambiente e sulla sua logica di funzionamento. Ricordiamo che sono disponibili delle funzioni di ‘Help’ in ogni finestra, nel testo delle quali sono riportate tutte le funzionalità della finestra stessa.
Nel cap.6.1. si spiega come iniziare una sessione di lavoro e come ‘navigare’ nella libreria dei modelli.
Attraverso la costruzione di un impianto nel cap.6.2, sono mostrate tutte le funzionalità dell’interfaccia accessibili ad un generico ‘Simple User’. Ricordiamo che il ‘Group Manager’ può eseguire le stesse operazioni di un ‘Simple User’, su tutti i modelli degli altri utenti appartenenti al suo gruppo (vedi cap.2.3.1).
Nel cap.6.3 si mostrano le operazioni eseguibili dal ‘Library Manager’. Queste operazioni consistono nella creazione e organizzazione di account di utenti, oltre alle operazioni di backup e restore della libreria.
All’utente che ha eseguito correttamente la procedura di login di GemStone, viene presentata la finestra ‘Session Manager’ di figura 6.1.
La chiusura di questa finestra rappresenta la fine della sessione di lavoro ed il logout da GemStone.
Premendo il pulsante ‘Models Library’ si apre la radice della libreria, la quale si presenta all’utente come in figura 6.2. Si può notare che la categoria ‘LabAut1’ è invalida, ovvero un altro utente ne ha già acquisito un blocco.
Per ‘navigare’ all’interno della libreria sono possibili due modi, uno lento ed uno veloce.
La procedura da eseguire è la seguente:
1. Posizionare il puntatore sull’oggetto che si vuole ispezionare
2. Eseguire un doppio-click con il 1° pulsante del mouse o selezionare la voce open del Menu-Popup ( premere il 3° pulsante del mouse sul rettangolo del modello ).
Si aprirà una nuova finestra uguale a quella di fig.6.2, rappresentante il contenuto del modello selezionato. Procedendo in questo modo si può arrivare in qualsiasi ‘nodo’ della libreria. Per risalire la gerarchia è possibile selezionare la voce Open Parent Level del menu Control che si trova nella Menu-Bar.
Sono disponibili i due seguenti modi:
1. Posizionare il puntatore sul nodo di libreria che si vuole ispezionare e selezionare la voce structure del Menu-Popup.
2. Selezionare la voce Search del menu Models che si trova nella Menu-Bar. Sarà possibile scegliere come radice dell’albero (visualizzato dallo StructureInspector) una tra le tre seguenti: RootLibrary, Current, Top. Mentre le prime due sono ovvie, la terza si riferisce al primo modello che si trova in una categoria, risalendo nella gerarchia di aggregazione del modello corrente.
Si apre una finestra, che si chiama StructureInspector, la quale mostra il contenuto della libreria mediante un albero. Nella fig.6.3. è stata eseguita questa operazione sulla categoria Robotic di fig.6.2. Le scatole con un triangolo alla loro estremità destra, rappresentano modelli aggregati . Premendo il 3° pulsante del mouse su tali scatole, è possibile espandere l’albero fino al raggiungimento delle foglie, ovvero dei modelli semplici. Questo spostamento è più rapido rispetto quello precedente perché viene mostrata solo la struttura gerarchica del modello, tralasciando le informazioni riguardanti i terminali ed i collegamenti.
Per ispezionare un modello aggregato, nella modalità ‘lenta’ di figura 6.2, occorre selezionare la scatola che lo rappresenta e premere il pulsante Open. Lo stesso procedimento vale per un modello semplice, ma i risultati verranno mostrati nei prossimi paragrafi.
L’esempio al quale si farà riferimento è quello rappresentato in figura 6.4. Esso è costituito da due link di un robot collegati da un giunto rotazionale. Gli ingranaggi, azionati dal motore, servono per ottenere il movimento relativo tra i due link. Da questo punto in avanti ci riferiremo a questo robot con il nome “2LRobot”.
Occorre innanzitutto rappresentare tale robot nelle sue parti fondamentali. In figura 6.5 è riportata una possibile scomposizione, scelta per evidenziare la struttura originaria del robot. Supporremo che tutti i modelli di cui è composto siano presenti nella libreria dell’ambiente, ad eccezione del modello Link_0 che costituirà l’esempio di costruzione di un modello semplice.
Innanzitutto occorre spostarsi nella categoria prescelta per contenere l’impianto (es. LabAut3) e bloccarla selezionando la voce Lock>Current del menu Locks nella Menu-Bar.
Il menu Locks della Menu-Bar permette anche di bloccare l’intero sotto-albero del modello corrente, selezionando Lock>Subtree. E’ buona norma bloccare solo i modelli necessari alla sessione di lavoro, per favorire l’accesso concorrente alla libreria. Le operazioni di blocco e sblocco dei modelli sono attivabili anche da Menu-Popup.
Il menu Create della Menu-Bar serve per creare gli oggetti nello spazio di lavoro della finestra, siano essi categorie, modelli oppure terminali.
Per creare un nuovo impianto occorre selezionare la voce Model>Plant e introdurne il nome (2LRobot) nell’apposita finestra secondaria. Il modello creato ora è presente nello spazio di lavoro della finestra, ed è possibile posizionarlo a piacere trascinandolo con il secondo pulsante del mouse. Ogni nuovo modello creato è automaticamente bloccato dall’utente.
La situazione in cui ci si viene a trovare è quella rappresentata in figura 6.6. Il bloccaggio del modello creato è riconoscibile dal piccolo lucchetto che appare in alto a sinistra sul modello stesso.
Per definire i diritti di accesso al modello appena creato da parte di altri utenti occorre attivare la voce Attributes del Menu-Popup associato al modello stesso ( premere il 3° pulsante del mouse sul rettangolo del modello ). La figura 6.7 mostra il risultato dell’operazione sul nostro esempio. Per default, l’unico utente che ha il diritto ‘modify’ sul modello è il proprietario, mentre gli altri utenti (Groups e World) hanno ‘none’.
Per modificare i diritti del proprietario (Owner) e degli utenti in generale (World), è sufficiente selezionare il pulsante voluto. Per quelli di un gruppo (Groups) occorre prima selezionare il nome del gruppo nella lista.
Ricordiamo brevemente le proprietà dei diritti:
· Sono definiti in ordine di importanza in modo che uno comprenda quelli precedenti: Delete=>Modify=>Read=>None.
· Sono assegnabili solo alle categorie ed ai modelli che ne sono direttamente contenuti. I modelli contenuti in impianti o in modelli aggregati ereditano i diritti dal loro contenitore.
· Sia il ‘Library Manager’ che un ‘Group Manager’ del proprietario possono non rispettare questi diritti.
Occorre innanzitutto aprire l’impianto appena creato (doppio-click o Menu-Popup) e, come visto prima, selezionare la voce Model>SimpleContinous nel menu Create della nuova finestra.
Il modello sarà creato nello spazio di lavoro della finestra.
Con doppio-click sull’icona del nuovo modello, oppure selezionando la voce Open>All Components del Menu-Popup, si inizia la definizione delle parti del modello.
La situazione è quella mostrata in figura 6.8, dove ad ogni finestra corrisponde una lista di componenti del modello. Il pulsante ‘ADD’ ha la funzione di aggiungere un elemento alla lista, mentre quello ‘DEL’ di rimuoverne l’elemento selezionato. Per la modifica di una componente occorre eseguire un doppio-click sull’elemento della lista desiderato.
Prima di definire una equazione bisogna creare le variabili ed i parametri contenuti in essa.
Premendo il pulsante ADD della lista Vars si aggiunge una variabile al modello attraverso la finestra mostrata in figura 6.9.
Creiamo quindi la variabile W1, che rappresenta la velocità angolare del Link, attraverso la seguente procedura:
1. Inserire il nome della variabile nella casella di testo ‘Name’.
2. Scegliere l’unità di misura utilizzando il relativo Menu-Popup (3° pulsante mouse sulla casella di testo), oppure digitandone il nome nella casella di testo.
3. Scegliere il tipo di variabile, scalare o matriciale, e in quest’ultimo caso specificarne le dimensioni.
4. Inserire, se lo si desidera, il significato della variabile nello spazio ‘Info’.
5. Infine, premere il pulsante ‘Apply’.
In ogni finestra per l’aggiunta o la modifica di una componente del modello, sono presenti gli stessi pulsanti; ‘Apply’, ‘Close’, ’Reset’, ‘Help’.
Il pulsante ‘Help’ ha il consueto significato. Il pulsante ‘Apply’ crea la componente e la aggiunge alle altre. Il pulsante ‘Reset’ azzera le modifiche apportate dal momento dell’ultimo ‘Apply’. Il pulsante ‘Close’ chiude semplicemente la finestra.
In figura 6.10 è mostrata la finestra per la definizione di un parametro, corrispondente alla matrice dei momenti di inerzia del Link.
Procedura per la creazione di un terminale:
1. Inserire il nome nella casella di testo ‘Name’
2. Scegliere il tipo di parametro, scalare o matriciale, e in quest’ultimo caso specificarne le dimensioni.
3. In modo facoltativo si può decidere se definirne il valore adesso oppure più avanti.
4. In modo facoltativo si può aggiungere un commento al parametro creato.
5. Infine, premere il pulsante ‘Apply’.
Supponiamo di aver definito tutti i parametri e le variabili che ci servono per la definizione delle equazioni.
La procedura è relativamente semplice e avviene nella finestra mostrata in figura 6.11. Si inserisce l’equazione come un testo, con il relativo commento e si preme il pulsante ‘Apply’.
In figura 6.12.a è mostrata la costruzione di un terminale meccanico mentre in figura 6.12.b quella di un terminale per scambio informazioni.
Procedura di creazione di un terminale:
1. Inserire il nome in ‘Name’
2. Selezionare il tipo di terminale desiderato. La selezione determina la costruzione della struttura del terminale nello spazio denominato ‘Structure’ e la visualizzazione di un elenco di variabili esportabili nella spazio denominato ‘Variables’.
3. In modo facoltativo è possibile scegliere una posizione per il terminale sull’icona del modello. Ciò si esegue selezionando un rettangolo nello spazio ‘Position’. Non scegliendo alcuna posizione, sarà assegnata al terminale la prima posizione libera.
4. Per modificare il numero di elementi di un terminale per scambio informazioni sono attivabili i pulsanti di ‘ADD’ e ‘DEL’.
5. Per collegare una variabile al terminale, è sufficiente eseguire un doppio-click su quella desiderata nella lista ‘Variables’, oppure scriverne il nome nella relativa casella. Una variabile può essere esportata da un unico terminale.
6. Come per le altre componenti è possibile associare delle informazioni al terminale, scrivendole nel campo ‘Info’.
7. Infine, premere il pulsante ‘Apply’.
La copia di un modello avviene attraverso un ‘buffer’ con i seguenti comandi:
· In finestre di tipo mostrato in figura 6.2, sono disponibili le voci Cut, Copy e Paste nel menu Models. In alternativa è possibile trascinare il modello con il 2° pulsante del mouse dalla finestra sorgente a quella di destinazione.
· Nella finestra tipo ‘StructureInspector’ (figura 6.3) occorre premere il pulsante Copy, dopo aver selezionato il modello.
Per instaurare un collegamento tra due terminali occorre eseguire la seguente procedura:
· Premere il primo pulsante del mouse sul rettangolo del primo terminale.
· Tenendo sempre premuto il primo pulsante, trascinarlo fino alla sovrapposizione con il secondo terminale.
· Il collegamento sarà effettuato al rilascio del pulsante. Se i terminali erano già collegati, vengono eliminate le vecchie connessioni ed instaurata quella nuova.
La costruzione di un modello aggregato può avvenire in due modi:
1. Top-Down: Si crea il contenitore ed i suoi terminali, li si collega con altri modelli ed infine si creano i sottomodelli.
2. Bottom-Up: Si creano i sottomodelli, si effettuano i collegamenti e li si aggregano con l’apposita funzione.
Per mostrare tutte le possibilità, il modello ‘Scatola Ingranaggi’ sarà creato nel primo modo, mentre ‘Trasmissione’ nel secondo modo.
Supponiamo di aver copiato dalla libreria alla finestra dell’impianto i seguenti modelli: ‘Base’, ‘Motore’, ‘Power’, ‘Giunto Rot.1’, Link 1’, ‘Link 0’. Dopo averli posizionati nella finestra dell’impianto 2LRobot si collegano come in figura 6.5.
Selezionando la relativa voce nel menu Create, aggiungiamo all’impianto il modello aggregato ‘Ingranaggi’. Dalla figura 6.5 si vede che tale modello ha 3 terminali meccanici. Per creare uno di essi occorre attivare la voce CreateTerm>Mechanic del Menu-Popup del modello. Verrà richiesto un nome per il nuovo terminale, il quale sarà aggiunto nella prima posizione libera. Se la posizione non è quella desiderata, è possibile spostare il terminale trascinandolo con il 2° pulsante del mouse e avendo premuto contemporaneamente il tasto ‘Ctrl’.
Dopo aver effettuato i collegamenti necessari, ci si trova nella situazione illustrata in figura 6.13.
Si basa sulle funzioni di aggregazione e disaggregazione automatica dei modelli. Si selezionano i modelli che si vuole aggregare (disaggregare) e si attiva la voce Make Aggregate From Selected (Divide Selected Aggregate) nel menu Aggregate. Vengono automaticamente creati o eliminati alcuni terminali in modo da poter riaggiustare i collegamenti.
Apriamo ora il modello ‘Ingranaggi’ e copiamo al suo interno i modelli necessari, mostrati in figura 6.5. Dopo aver collegato i terminali, selezioniamo i tre modelli che costituiscono il modello ‘Trasmissione’ e attiviamo la funzione di aggregazione automatica. Verrà creato un nuovo modello aggregato ed i tre modelli selezionati precedentemente diventeranno suoi sottomodelli.
La situazione del modello ‘Ingranaggi’ dopo queste operazioni è mostrata in figura 6.14, mentre in figura 6.15 è mostrato il nuovo modello ‘Trasmissione’.
Selezionando la voce Version&PlantState del menu Simulation nella Menu-Bar, si apre la finestra mostrata in figura 6.16.
Si può notare che le liste dei nomi ‘Name’ hanno i pulsanti di ‘ADD’ e ‘DEL’ mentre le altre no. E’ infatti possibile solo la modifica del valore dei parametri e del valore iniziale delle variabili di stato. La modifica di un valore è possibile con un doppio-click sull’elemento della lista (come per tutte le liste viste precedentemente).
Nella parte centrale della finestra vengono riportati i nomi delle scelte selezionate per la simulazione. Per cambiare scelta occorre selezionare, nelle rispettive liste, la versione e lo stato d’impianto desiderato, premendo infine il pulsante 'Select Configuration'.
L’aggiunta o la rimozione di nuovi utenti, così come il backup o restore della libreria, sono operazioni che richiedono l’uso esclusivo dell’ambiente. Il ‘Library Manager’ non può effettuare nessuna di queste operazioni mentre altri utenti sono collegati a VisualMOSES.
Per iniziare queste operazioni occorre premere il relativo pulsante sul ‘Session Manager’ mostrato in figura 6.1.
La creazione di un utente e di un gruppo di lavoro avviene utilizzando la finestra ‘Groups/Users Manager’ mostrata in figura 6.17
L’utilizzo delle liste è identico a quello mostrato per le componenti di un modello. L’unica differenza riguarda la lista ‘Members’, per la quale è stato aggiunto il pulsante ‘Set Leader’. Selezionando un elemento di ‘Members’ e premendo tale pulsante, si dichiara che quell’utente è ‘Leader’ o ‘Group Manager’ del gruppo visualizzato.
Ricordiamo le principali caratteristiche di questa gestione:
· Si può definire un solo ‘GroupManager’ per gruppo.
· Un utente può appartenere a più gruppi.
· Il ‘Library Manager’ diventa proprietario dei modelli dell’utente che è stato eliminato.
Le operazioni di backup e restore avvengono attraverso la finestra mostrata in figura 6.18.
E’ sufficiente assegnare il nome al file da creare o da ripristinare e attendere la fine dell’operazione.
Documentazione tecnica
· [GEMSTONE '93] Manuale di riferimento: Introduction to GemStone, Servio Corporation, 1988-1993.
· [GeODE '93] Manuale di riferimento: Introduction to GeODE, Servio Corporation, 1988-1993.
· [OPAL '93] Manuale di riferimento: Programming in OPAL, Servio Corporation, 1988-1993.
Databases e programmazione ad oggetti
· [Korth & Silbershatz ‘91] Henry F.Korth, Abraham Silbershatz, Database system concepts, 2° Edition, McGRAW-HILL, 1991.
· [Gupta & Horovitz ‘91] Rajiv Gupta, Ellis Horovitz. Object- Oriented DataBases with Applications to CASE, NETWORKS and VLSI CAD. Prentice Hall, 1991.
· [Goldberg &Robson ‘83] A. Goldberg and D.Robson. SMALLTALK-80. The language and its implementation. Addison-Wesley, 1983.
Linee guida e progettazione delle interfacce grafiche
· [HP OSF/MOTIF ‘93] Manuale di riferimento: HP OSF/MOTIF STYLE GUIDE, 1993.
· [Bagnara & Groppelli & Nicoletti & Zaretto ‘93] S.Bagnara, P. Groppelli, R.Nicoletti, G. Zaretto. Prima validazione del progetto di console informatizzata innovativa. Relaz. n° 343.342-2, rapp. n° 241/93 , 1993.
· [Johnson & Reichard ‘92] E.F. Johnson, K.Reichard. X-Window Applications programming. MIS Press,1992.
· [Berlage ‘91] T.Berlage. OSF/MOTIF Concepts and programming. Addison Wesley, 1991.
· [Young ‘90] D.A Young. The X-Window system; Programming and application with Xt. Prentice Hall, 1990.
· [Norman ‘88] D.A. Norman. The psychology of everyday things, Basic Books, Inc., Publisher, New York, 1988.
· [Mosier ‘86] Smith S.L Mosier, J.N.. Guidelines for designing user interface software, pp 86-278, Hanscom Air Force Base, Massachusetts: Electronis System Division, United States Air Force, 1986.
· [Bagnara ‘84] S.Bagnara. L’attenzione. Bologna, il Mulino, 1984
· [Eastman ‘83] Eastman Kodak Co. Ergonomic Design for People at Work. Belmont,California, Liftime Learning Publications, 1983.
· [Brown ‘81] Brown, D.M. Human Factors Engineering Criteria for Information Processing System. Sunnyvale, California, June 1981
· [Christ ‘75] Christ ,R.E. Review and Analysis of color coding research for visual displays. Human Factors, pp 542-570, 1975.
· [King & Tierey '70] King , L.E. Tierey. Legibility: Symbols versus word higway signs. Highway Research Information Service, West Virginia University, West Virginia. 1970
Lavori precedenti sul progetto MOSES:
· [Girelli & Meroni '93] R.Girelli, S.Meroni. Ambiente Object-Oriented per la simulazione dinamica: progetto e implementazione dello schema e della manipolazione della base dati. Master's thesis, Politecnico di Milano, 1993.
· [Carpanzano & Formenti '94] E.Carpanzano, F.Formenti. Manipolazione simbolica di sistemi DAE: algoritmi, sviluppo del software ed applicazioni. Master's thesis, Politecnico di Milano, 1994.
· [Gementi & Molina '94] C.G.Gementi, A.Molina. Progetto e realizzazione di un ambiente per la simulazione d'impianto integrato in un sistema Object-Oriented per la creazione e la gestione dei modelli. Master's thesis, Politecnico di Milano, 1994.