Firefly QAK

Requirements

Definire un sistema firefly che simula il comportamento di una lucciola
Il sistema deve poter simulare un numero N di luccile (con N al più 100).
Ogni lucciola deve simulare ad intervalli di tempo regolari la propria bioluminescenza.
Ciascuna lucciola ha un proprio tempo di pulsazione in cui emette luce, per poi spegnersi dopo un arco tempo costante (es 500ms).

Requirement analysis

Da R1: Per poter definire il comportamento di una lucciola, ne viene definito il modello in linguaggio QAK. La singola lucciola infatti viene realizzata attraverso un QActor, ossia come un automa di Moore, cui transazioni di stato definiscono il comportamento stesso della singolo individuo.
Dopo uno stato iniziale, la lucciola deve emettere ad intervalli di tempo regolari bioluminescenza, per poi spegnersi. La lucciola dovrà reagire a eventi di tipo temporale, per sapere esattamente quando emettere luce.

                QActor firefly context ctxfirefly{
                    [#  
                        var num		= 0
                          val DT = (200L..2000L).random()
                     #]

                     //initial state of every firefly
                    State s0 initial{
                        println("$name | Hi I'm alive, I blink every $DT ms") color green
                    }
                    Transition t0
                        whenTimeVar  DT -> handleBlink  //event every delta time (200ms-2000ms)
                    
                    State handleBlink{
                        [# num ++ #]
                        println("$name | $num light on") color yellow
                        delay 500
                        println("$name | $num light off") color black
                    }Transition t0
                        whenTimeVar  DT -> handleBlink	
                }

Dai requisiti si evince che attualmente la singola lucciola può essere anche realizzata senza dover interagire attraverso messaggi con le altre in quanto il comportamento della singola è completamente autonomo e non interagisce con le altre durante il tempo di vita.

Da R2-R4: Ogni lucciola deve avare un comportamento autonomo rispetto alle altre, con un proprio tempo di pulsazione in cui emette luce. Questo comportamento si può ottenere definendo un QActor per ogni lucciola in modo tale che le coroutine non vengano interrotte da altri actor. Ciascuna pertanto definisce un proprio perido ed emette periodicamente luce. Questo suggerisce il problema di creare dinamicamente le lucciole in base il numero desiderato.

Problem analysis

Il problema principale riguarda la creazione di N = 100 QActor indipendenti, ognuno descritto dal modello presentato in fase di analisi, in modo da poter emettere periodicamente luce in modo svincolato dagli altri individui.
Per questo motivo è stato scelto di usare un'architettura basata su un QActor creator, che ha il compito di creare tutte le lucciole. Per fare ciò è stato necessario avvalersi della creazione di attori a runtime, definenone solo il template con la keyword dynamicOnly

Creator ha un ruolo puramente iniziale, nel creare N firefly attraverso l'istruzione:

                create firefly _"$num"

Tuttavia poichè il numero di lucciole da creare potrebbe non essere noto a priori e per implementare la nozione di ciclo iterativo di creazione delle lucciole, ci si avvale di un helper, che ha il compito di rispondere al messaggio del tipo:

                msg: msg(start,dispatch,creator,helper,start(10),8)

dove start(10) è il contenuto di un messaggio di dispatch inviato dal creatore, per avviare il protocollo di creazione, specificando il numero di lucciole da costruire.
L'helper potrebbe essere impostato come attore in kotlin che reagisce al messaggio di start definito in precedenza. La reazione consiste proprio nell'implementazione di un ciclo di dispatch da inviare al creator, che corrispondono ognuna alla creazione di una luccuola.
L'Helper potrebbe essere dichiarato come segue:

                CodedQActor helper context ctxfirefly className "fireflyqak.helper"

I Messaggi del tipo inviati dall'helper al creator sono:

                msg(build,dispatch,helper,creator,build(1),9)

Dove build è il nome del messaggio e 1 è il numero identificatore specifico che definisce il nome dell'attore/lucciola ($num). L'helepr ha il solo compito ciclico di inviare N messaggi dispatch al creator, che provvederà a produrre le lucciole necessarie.
Una volta ricevuto il messaggio di build il creator ha il solo compito di estrarre dal messaggio il numero id. della firefly da creare ed usare la create definita prima per avviare il QActor corrispondente.

Firefly QAK

Introduction

Requirements

Requirement analysis

Problem analysis

Test plans

Project

Testing

Deployment

Maintenance