LABORATORIO DI SISTEMI SOFTWARE

1. Dai requisiti emerge che si dovrà realizzare un sistema distribuito composto dalle seguenti entità:
   • waiter
   • teatable1
   • teatable2
   • smartbell
   • presencedetector
   • barman
   • manager
   • client
   Si dovrà lavorare sul software del waiter e quello dello smartbell, mentre invece il manager ed il client saranno persone fisiche, tuttavia per poter simulare agevolmente il sistema è utile introdurre le entità corrisponenti come attori. Sarà quindi utile introdurre, ad esempio, un clientsimulator che impersonifichi "via software" le attività del client.
   Un discorso simile vale per il barman che sarà visto dal waiter come un servizio.
2. Movimenti del waiter:
   • L'entità waiter deve poter essere in grado di muoversi autonomamente tra i punti home, servicedesk, table1, table2, entrancedoor, exitdoor
   • All'inizio il waiter si trova nel punto home e ci ritorna quando non ha più task da svolgere
   • Il waiter deve poter raggiungere l'entrata (reach) e accompagnare (convoy) il client al table
   • Il waiter deve poter andare dal barman a ritirare il drink e portarlo al table del client (serve)
   • Il waiter deve poter accompagnare (convoy) il cliente alla exitdoor
3. Stati dei table:
   • I table sono delle entità che possono essere occupate da dei client
   • I table possono trovarsi in tre stati diversi:
   • All'inizio i teatable sono clean. Quando sono in questo stato sono pronti per essere occupati da un client
   • Dopo che un client libera un teatable, il waiter deve tornare a pulirlo nuovamente affinchè sia di nuovo clean
4. Funzionalità dello smartbell:
   • Lo smartbell deve presentare un'interfaccia con cui il client deve poter richiedere di poter entrare (notify) nella tearoom
   • Lo smartbell deve poter misurare la temperatura corporea al client e verificare che sia al disotto dei 37.5 gradi centigradi
   • Lo smartbell deve poter mandare un messaggio di richiesta al waiter all'arrivo di un nuovo cliente
   • Lo smartbell deve presentare al client l'esito di tale richiesta
5. Interazioni waiter-barman-client:
   • Il waiter in risposta alla richiesta ricevuta tramite lo smartbell deve poter far sapere al client se può entrare (accept) oppure se deve aspettare un certo tempo (inform) che vi sia un tavolo pulito
   • Il waiter deve poter tener conto di quanto tempo un client sia stato al tavolo affinchè non ci resti più di maxstaytime
   • Qualora non ci siano tavoli puliti disponibili (cleaned) il waiter deve poter stimare il massimo tempo di attesa per averne uno
   • Il waiter deve poter prendere (take) l'ordine dal cliente e trasmetterlo al barman
   • Il barman deve poter notificare al waiter che il drink è pronto
   • Il waiter deve far pagare (collect) il client quando ha finito di consumare oppure è scaduto il maxstaytime
   • Il client deve poter richiamare il waiter per avvertirlo che ha finito di consumare
   • Il waiter deve poter pulire (clean) un table quando è sporco
6. Ad ogni client che passa il test della temperatura viene assegnato un identificativo univoco (clientidentifier)
7. All'interno della tearoom posso esserci al massimo N clienti contemporaneamente (N=numero tavoli=2)
8. Bisogna rendere disponibile un'interfaccia web da cui il manager deve poter controllare lo stato corrente della tearoom: deve essere infatti possibile in ogni momento conoscere lo stato corrente della stanza

Una descrizione formale di questo modello si può trovare in tearoom.qak

1. Data la natura distribuita del problema risulta particolarmente conveniente utilizzare l'infrastruttura QAK, già disponibile nella nostra software house, poichè si presta molto bene ad essere usata in questo tipo di situazioni. Inoltre permette una rapida prototipazione.
2. Essendo che le entità elencate nei requisiti devono svolgere le loro attività in parallelo interagendo tra loro scambiandosi messaggi e agendo in conseguenza dei messaggi ricevuti, risulta opportuno modellarle come QActor
3. Per potersi muovere tra i vari punti della stanza il waiter deve conoscerne la conformazione e la posizione di se stesso e degli altri punti: ciò implica che questa informazione gli debba essere fornita all'inizio o il waiter debba poterla ricavare tramite opportuni sensori
4. Dovendosi muovere autonomamente emerge che il waiter debba essere in grado di pianificare ed eseguire il percorso tra i vari punti della stanza evitanto anche di andare a sbattere, evitare le collisioni comporta l'uso di un sonar
5. Dai requisiti emerge che un table possa trovarsi nei seguenti stati: "libero e clean", "libero e ancora da sanificare", "occupato da un client"
6. Lo smartbell per poter misurare la temperatura deve essere equipaggiato con un sensore
7. Dovendo inoltrare la richiesta di accesso dei client al waiter potrebbe essere direttamente lo smartbell a generare e assegnare gli identificativi univoci dei clienti
8. Il waiter deve poter conoscere lo stato dei table
9. Per far rispettare il maxstaytime il waiter deve tener traccia del tempo trascorso da quanto un client si è seduto al table
10. Dai requisiti segue che ci debba essere un qualcosa che tenga traccia in tempo reale dello stato della stanza (ad esempio, potrebbe essere direttamente uno degli attori o aggiungere un elemento apposito)

Interazione ingresso client

Il client tramite un messaggio notify comunica allo smartbell di voler entrare nella stanza. Lo smartbell misura la temperatura del client, la quale deve essere inferiore a 37.5°C. Lo smartbell risponde (tempResult) al client informandolo se la sua temperatura rispetti le disposizioni sanitarie, e quindi sia autorizzato a poter entrare. Lo smartbell informa il waiter della presenza di un nuovo client inviando il clientidentifier appena generato. Il waiter legge lo stato dei table. Il waiter risponde allo smartbell se il nuovo client possa o meno entrare in sala. Tale risposta viene propagata al client, il quale in caso affermativo aspetta il waiter per essere accompagnato ad un table, mentre in caso negativo si mette in attesa.

Interazione ordinazione client

Il client tramite un messaggio readyToOrder informa il waiter che vuole ordinare. Il waiter tramite un messaggio take chiede al client il suo ordine. Dopo aver raccolto la riposta (order) del client, il waiter comunica al barman di preparare il drink richiesto (orderReq). Quando il barman ha finito di preparare il drink richiesto dal client, lo comunica al waiter tramite un ready.

Interazione richiesta uscita client

Il client informa (exitReq) il waiter di aver terminato la consumazione e di voler procedere al pagamento.

Interazione pagamento client

Il waiter tramite una collect richiede il pagamento al client, il quale gli risponde (payment) con l'importo dovuto. Questa interazione, può avvenire successivamente all'interazione richiesta uscita client oppure dopo il superamento di maxstaytime

Una descrizione formale di questo modello si può trovare in tearoom.qak