SPRINT 1

Requirements

Il primo Sprint si occupa di modellare la tearoom nella condizione in cui vi è un solo cliente presente che compie le azioni seguenti:
  • Suonare lo smartbell
  • Farsi misurare la febbre dallo smartbell
  • Entrare nella sala (ci sarà il sempre il table libero)
  • Sedersi al table
  • Compiere un'ordinazione (chiamare il waiter e ordinare)
  • Consumare il drink
  • Pagare il servizio
  • Lasciare la stanza
Si supponga che:
  • Nella simulazione è presente un solo client
  • Il waiter deve poter madare l'ordinazione al barman e portarla al client quando è pronta
  • Non si tenga conto degli stati del table e della pulizia da parte del waiter
  • Non si tenga conto del rispetto del maxstaytime
  • Il client non compia azioni diverse da quelle elencate precedentemente

Requirement analysis

Di seguito sono riportati i requisiti trattati in questo sprint:

NUMERO REQUISITOATTORE REQUISITODESCRIZIONE REQUISITOTAG REQUISITO
0WAITER L'entità waiter deve poter essere in grado di muoversi autonomamente tra i punti home, servicedesk, table1, table2, entrancedoor, exitdoor
1WAITER All'inizio il waiter si trova nel punto home e ci ritorna quando non ha più task da svolgere
2WAITER Il waiter deve poter raggiungere l'entrata reach
3WAITER Il waiter deve poter andare dal barman a ritirare il drink e portarlo al table del client serve
4WAITER Il waiter deve poter accompagnare il cliente alla exitdoor e dall'entrata al table convoy
5WAITER Il waiter in risposta alla richiesta ricevuta tramite lo smartbell deve poter rispondere che il client può entrare, se ci sono table AVAILABLE waitingTime(0)
8WAITER Il waiter deve poter prendere l'ordine dal client e trasmetterlo al barman take
9WAITER Il waiter deve far pagare il client quando ha finito di consumare oppure è scaduto il maxstaytime collect
12BARMAN Il barman quando riceve l'ordine dal waiter deve mettersi a preparare il the orderReq
13BARMAN Il barman deve poter notificare al waiter che il drink è pronto ready
14CLIENT Il client deve poter suonare lo smartbell per richiedere di entrare notify
15CLIENT Il client deve poter avvisare il waiter che è pronto per ordinare readyToOrder
16CLIENT Il client deve poter ordinare il the al waiter order
17CLIENT Il client deve poter richiamare il waiter per avvertirlo che ha finito di consumare exitReq
23SMARTBELL Lo smartbell deve presentare al client un'interfaccia da cui poter chiedere di entrare nella tearoom
24SMARTBELL Lo smartbell deve misurare la temperatura del client e comunicargli l'esito della verifica tempResult
25SMARTBELL Lo smartbell deve avvisare il waiter della presenza di un client pronto per entrare checkAvail
26SMARTBELL Lo smartbell deve riportare al client l'avviso che un waiter sta arrivando per accompagnarlo, se ci sono table liberi accept

Nell'implementare (e poter testare) la possibilità del waiter di muoversi autonomamente tra i punti della stanza, emergono alcuni aspetti:

  1. Rappresentare lo spazio
  2. Conoscere la posizione corrente del waiter nello spazio
  3. Spostarsi da un punto all'altro dello spazio

Rappresentare lo spazio
La rappresentazione dell'ambiente (mappa) è la base di conoscenza che racchiude le informazioni sulla posizione degli elementi nella stanza. Per quanto riguarda tutti gli elementi tranne il waiter, la mappa potrebbe rimanere invariata per tutto il tempo di esecuzione del sistema (non emergendo dai requisiti la necessità di spostare tavoli, barman, porte, ...). La mappa iniziale, ovvero priva delle informazioni sulla posizione waiter, potrebbe essere calcolata dal waiter stesso o, vista la natura del problema, fornita all'inizio dell'esecuzione del sistema dall'esterno.

Posizione corrente del waiter
Per quanto riguarda, invece, il waiter la sua posizione deve essere aggiornata ogni volta che si muove nell'ambiente.

Pianificare i percorsi
Infine per poter calcolare le mosse da eseguire per muoversi nell'ambiente sono possibili due strade:

  • si potrebbe essere portati a ricorrere ad una più semplice implentazione "dummy" con percorsi prefissati
  • si potrebbe affrontare sin da subito la progettazione di una soluzione in grado di calcolare i percorsi dinamicamente
Volendo ottimizzare i tempi, e disponendo all'interno della nostra software-house di una utility per implementare un planner già pronta, risulta più conveniente iniziare da subito con una soluzione più vicina al prodotto finale. Ciò permette di ridurre i tempi di sviluppo: un'implementazione a percorsi predefiniti, utile in una prima fase di prova, sarebbe poi da sostituire con la successiva pianificazione dinamica dei percorsi (più affidabile e quindi più appropriata per il prodotto finale): tantovale iniziare a investire tempo di sviluppo fin da subito su di una soluzione definitiva, sopratutto se è già disponibile un'utility software per farlo.

TestPlans
Per formalizzare un primo set di test plans ed avere anche una base di partenza per la realizzazione di un planner si potrebbe suddividere il pavimento della tearoom in una griglia di R * C quadrati di lato L. Dove L è la dimensione più piccola possibile tale da contenere il robot. Ogni cella può essere libera oppure occupata da un ostacolo. A questo punto si può definire la posizione di ogni elemento nella mappa come una coppia di coordinate (R,C). Il planner calcolerà il percorso da eseguire dalla posizione corrente del waiter fino al punto richiesto, e alla fine dell'esecuzione si potrà testare verificando che la posizione raggiunta sia quella richiesta inizialmente.

Questo concetto di mappa è stato già usato nella nostra software house, supponendo che, in ogni cella:

  • r significa "cella occupata dal waiter"
  • x significa "cella occupata da un ostacolo"
  • 1 significa "cella nota come libera"
  • 0 significa "cella goal"

Da tutto ciò consegue che potrebbe essere utile far muovere il waiter di cella in cella definendo questo tipo di movimento "step".

Problem analysis

Dal punto di vista logico, il nostro sistema distribuito è composto da varie entità ognuna concepita come un attore, modellato come una FSM. Sicuramente l'entità waiter dovendo soddisfare vari requisiti è quella che presenta il maggior grado di complessità. Per risolvere i vari problemi ad essa relativi potrebbe risultare conveniente adottare un'architettura a layer, sopratutto perchè sono già disponibili all'interno della nostra software-house alcune componenti pronte per essere riutilizzate a tal proposito.
La componente it.unibo.qak20.basicrobot (definito qui) infatti risulta molto utile per realizzare un'entità che si collochi nel mezzo tra "la mente" del waiter e la sua realizzazione "fisica", potendo ricevere comandi di alto livello come "step" e facendoli attuare ad un robot virtuale.


Per quanto riguarda la pianificazione dei percorsi è già disponibile nella nostra software-house anche un planner già compatibile con il basicrobot.

Test plans

Di seguito è riportata una tabella che riassume tutte le funzionalità coperte e testate all' interno di questo sprint, evidenziando stato pre e post interazione.
Le interazioni colorate in verde sono quelle testate nella sezione di Testing, mentre quelle non colorate si suppongono già testate in quanto semplici interazioni (dispatch, request-response definite qui) implementate nel framework di riferimento QAK già presente nella nostra software-house.

TAG TEST STATO INIZIALE STATO FINALE
notify Il client si trova all'ingresso Il client aspetta la risposta dello smartbell
tempResult Lo smartbell ha ricevuto una richiesta di ingresso da un client Il client esce dal sistema (temperatura pari o superiore ai 37.5°C) o aspetta di conoscere il tempo di attesa dallo smartbell
checkAvail Lo smartbell ha appena accettato un cliente misurandogli la temperatura Lo smartbell è pronto a fare una accept del client nella stanza
waitingTime(0) Il client è in attesa di scoprire se può entrare Il client aspetta il waiter alla entrancedoor
accept Lo smartbell ha appena ricevuto dal waiter il via libera a far entrare senza attesa il client nella stanza Il client aspetta il waiter per essere portato al tavolo
reach Il robot waiter è fermo nella home Il robot waiter si trova alla entrancedoor
convoy Il client si trova nella entrancedoor Il client si trova nel suo table
readyToOrder Il client ha deciso cosa ordinare Il client si mette in attesa del waiter per comunicargli la sua ordinazione
take Il client aspetta il waiter per comunicargli l'ordine Il waiter è arrivato al table ed è pronto a conoscere il contenuto dell'ordinazione
order Il waiter ha domandato al client di comunicargli il contenuto della sua ordinazione Il waiter ha ricevuto l'ordine dal client
orderReq Il waiter ha preso in consegna l'ordine del client Il waiter ha comunicato al barman il contenuto dell'ordinazione
ready Il barman ha concluso di preparare l'ordinazione Il waiter sa che il barman ha concluso il drink
serve Il waiter è fermo in un punto della mappa Il waiter ha preso in consegna il drink pronto, lo ha portato al table del client e il client inizia la consumazione del drink
exitReq Il client ha concluso la consumazione Il waiter sa che può andare dal client per fargli effettuare il pagamento
collect Il waiter comunica l'importo della ordinazione al client Il waiter ha raccolto l'importo
convoy Il client si trova nel suo table Il client si trova nella exitdoor

Nuova interazione per l'ordinazione client

Quando il barman ha finito di preparare il drink richiesto dal client, lo comunica al waiter tramite un ready.

Allora il waiter lo va a prendere e lo porta al table del client consegnandoglielo con una serveDrink.

Project

Si riporta l'esempio relativo al waiter per evidenziare l'architettura a layer adottata. In particolare viene mostrato il caso in cui un client richieda di uscire dalla sala da te.

Per una definizione formale di tutta la struttura, l'interazione ed il comportamento si rimanda alla definizione dei QActor:

Testing

Tutti i test sono stati svolti con JUnit4


I test sono stati svolti analizzando il flusso delle interazioni fra i vari attori del sistema, concentrandosi particolarmente sul movimento del waiter. La logica di confronto è basata sull'osservazione della composizione della mappa dopo ogni spostamento del robot e il test è svolto confrontando la mappa al momento del test (ottenuta tramite il riferimento in plannerUtil.kt) e la mappa che ci si aspettava in quel momento.

Per motivi di testing, tutte le entità esterne al waiter sono state rese attori senza logica applicativa. Tutti gli attori sono inseriti nel contesto del waiter (si guardi tearoom.qak).
Nello specifico, le classi di test sono:
  1. TestWaiterConvoyEntrance.kt verifica che il waiter compia correttamente le azioni di reach, convoy all'ingresso e successivo ritorno alla home.
  2. TestWaiterDrinkOrder.kt verifica che il waiter compia correttamente le azioni di readyToOrder (che implica raggiungimento del tavolo del client), take, order e successivo ritorno alla home.
  3. TestWaiterBringingDrink.kt verifica che il waiter compia correttamente la serve (che implica che il barman gli abbia notificato una ready), e successivo ritorno alla home.
  4. TestWaiterPaymentExit.kt verifica che il waiter compia correttamente le azioni di collect, payment, convoy in uscita e successivo ritorno alla home.
  5. TestWaiterComplessivo.kt esegue in successione i precedenti test, simulando tutto il flow del client all'interno del sistema.

ATTENZIONE! Ricaricare la mappa virtuale a ogni tentativo di test, in modo da sincronizzare correttamente la base di conoscenza.


Our Team