Java Simulation Layer 2.0 (Korretto)

1 Propositi di Progetto
L'idea principale che ha mosso questo progetto e' stata quella di realizzare un package che mimasse nel miglior modo possibile le primitive del linguaggio Simula67. Nelle nostre intenzioni questo doveva rendere triviale l'implementazione di esperimenti scritti in Simula nel nuovo ambiente ad oggetti Java, eliminando la necessita' di dover disporre di un ulteriore compilatore e l'apprendimento di un altro linguaggio.
Si sono immediatamenti individuati due filoni di lavoro:

Implicitamente si e' delineato un altro area di sviluppo che si proponeva di realizzare esempi funzionanti in modo da testare i punti suddetti, fornire punti di riferimento a futuri utenti del pacchetto e verificare la somiglianza con il codice originale ove possibile.
 

2. Primitive di Linguaggio

A sua volta questa parte si e' rivelata composta da piu' sotto-problemi:

Si e' constatato immediatamente che non era possibile fornire un mapping perfetto del linguaggio Simula, soprattutto in termini di sintassi, ma pure in termini di struttura, molto piu' moderna in Java. Molte chiamate di linguaggio sono diventate metodi statici di classi Java (vedi Lang), e, ad esempio, la notazione REF di Simula non e' riproducibile.

Per quanto riguarda le estensioni di Simset, queste sono state mappate in una gerarchia di classi radicata nell'astratto Linkage con specializzazioni Link (elemento semplice) e Head (elemento principale della lista).   Sono state mantenute tutte le caratteristiche delle chiamate a queste classi (ad esempio se si chiama into(H) ove H sia un riferimento a Head nullo, come nel linguaggio originale l'elemento chiamato esce da ogni coda nella quale risiedeva).

Lo sviluppo del sottopackage Simulation si e' rivelato ben piu' impegnantivo: Simula infatti prevede che i processi si interrompano a ogni chiamata di scheduling ( hold, passivate ecc. ) riprendendo, alla riattivazione, dal punto di sospensione. Vi e' cioe' un passaggio implicito del flusso di esecuzione tra processi che non ha eguali in linguaggi come Java: la soluzione si e' presentata con l'uso dei Thread.  Ogni istanza della classe Process e' collegata, in modo invisibile all'utente, ad un thread e vi e' una classe, Simulation, che si preoccupa di reagire alle chiamate di scheduling aggiornando automaticamente una coda nascosta, attivando o passivando i relativi thread.
 

3. Generazione di numeri pseudocasuali
Questa parte dello sviluppo ha risentito in maniera maggiore dell'influenza dell'ambiente ospite (Java).
Infatti la traduzione delle API di Simula relative a questo sottoproblema e' risultata in due gerarchie di classi, che hanno come radici le classi astratte Value e Generator.

I discendenti di Generator realizzano i generatori di numeri pseudocasuali ciascuno secondo una distribuzione di probabilita' differente. E' stata realizzata una classe per ogni distribuzione che viene citata nelle API di Simula. L'estrazione di un numero avviene chiamando il metodo draw(), che deve essere opportunamente ridefinito da ogni discendente.

Poiche' i valori su cui sono defintite tutte le variabili casuali di interesse sono di natura diversa (reali, interi o booleani) e poiche' l'interfaccia della classe Generator doveva essere il piu' semplice possibile, si e' reso necessario incapsulare tutti questi tipi di dati in un unico oggetto. Questa e' stata la ragione che ha portato alla creazione della gerarchia di classi che discende da Value che, comunque rimane celata all'utilizzatore finale del package. Ma l'interfaccia di Value e' sufficiente per utilizzare in tutti i modi corretti i valori estratti.

E' stata poi pensata una ulteriore possibilita' in questo ambito che pero' non e' richiesta da Simula.
Infatti vi e' una terza gerarchia, radicata in RandomEngine, che consente di avere per ogni generatore un diverso motore, ovvero diversi modi di generare sequenze di bit in manira pseudocasuale, che verranno poi interpretati da un discendente di Generator per calcolare il numero richiesto.
 

4. Autori
5. API reference