LABORATORIO DI SISTEMI SOFTWARE

Introduction - Tea-room COVID-19

Remember our motto:
there is no code without a project, no project without problem analysis and no problem without requirements .

Il manager di una sala da the (tearoom) vorrebbe regolare l'accesso al servizio impiegando un DDR robot (waiter).

La tearoom è una stanza rettangolare che include: Il waiter può muoversi liberamente lungo i bordi della stanza, poichè lungo il perimetro non ci sono ostacoli.
tearoom20.png

User stories

Come cliente: Come manager:

Requirements

Il waiter deve eseguire le seguenti attività: Dal momento che la sala può contenere al massimo N clienti alla volta, il waiter deve ridurre il più possibile i tempi di attesa delle richieste di ogni singolo cliente.

Optional Requirements: solo un cliente nella hall

Il waiter deve aprire la exitdoor solo quando la hall è libera, i.e. non deve aprire la porta se la hall è già occupata da un cliente in attesa di entrare dalla entrancedoor.

Requirement analysis

  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

Problem analysis

  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

In fase di analisi sono emersi delle problematiche critiche che saranno affrontate più nel dettaglio nei successivi sprint:
  1. Generare e immagazzinare i clientidentifier e dare definizione più precisa dell'interazione fra gli attori e lo smartbell.
  2. Valutare da quando viene misurato il maxstaytime e comprendere chi si deve occupare di tenere il conteggio del tempo trascorso.
  3. Comprendere come tenere la hall in sicurezza utilizzando il presencedetector (Evitando così gli assembramenti).
  4. Definire formalmente cosa si intende per "lo stato della stanza": quali caratteristiche includervi? Oltre a ciò, decidere come e dove conservare queste informazioni: distribuirle su tutto il sistema o centralizzarle?

Test plans

Essendo ogni entità modellata come automa a stato finito, una strategia percorribile per fare testing potrebbe essere quella di determinare se i cambiamenti di stato siano avvenuti come ci si aspetterebbe dopo ogni relativo messaggio.
A tal proposito è necessario identificare univocamente uno stato e poter verificare lo stato corrente di ogni entità.

Nel file tearoom.qak è stata data una definizione formale del modello, in cui si può vedere la relazione fra stati e messaggi.
Il piano di testing deve essere progettato per verificare tutte queste condizioni.

Piano di lavoro

Dalla analisi preliminare del sistema risulta necessario pianificare un piano di lavoro architettato in sprint, di seguito riportati.
NOME DESCRIZIONE MOTIVAZIONE
SPRINT 1 Si occupa della modellazione del sistema nell'ipotesi in cui operi un solo client e che compia unicamente le azioni previste dal suo comportamento standard, senza interferenze di alcun genere. La scelta di questo primo sprint è motivata dalla volontà di simulare un primo scenario di base che preveda una interazione "controllata" e "prevista" del sistema, in modo da aggiungere nei successivi sprint i casi imprevisti.
SPRINT 2 Si occupa della definizione dello stato della stanza.

Questo sprint aggiunge al primo sprint una descrizione degli elementi della stanza, introducendo il concetto di architettura esagonale.

Inoltre in questo sprint si inizia a costruire il pannello di controllo da fornire al manager.
Dopo aver verificato le funzionalità base del sistema è necessario iniziare a dare una forma a quella che sarà l'architettura finale.
SPRINT 3 Si occupa della concorrenza fra client, ossia la presenza di più client nella tearoom contemporaneamente, e della gestione del tempo (maxstaytime e waitingtime). Dopo aver costruito una prima versione dell'architettura finale, aggiungiamo al sistema ulteriori casi d'uso con lo scopo di avvicinarlo sempre più al prodotto finale richiesto.
SPRINT 4 Deployment del sistema e impiego di robot fisici oltre che del virtual robot fornito. Possibilità di interrompere alcuni task per riprenderli in seguito. Questo sprint finale rende il sistema pronto per essere consegnato al cliente e ne dimostra il funzionamento su dei DDR reali.


Our Team