LABORATORIO DI SISTEMI SOFTWARE

Requirements

Questo sprint si occupa del deployment dei DDR fisici e della possibilità da parte del waiter di interrompere un task in favore di un altro. In particolare, i seguenti punti della tabella dei requisiti:
NUMERO REQUISITOELEMENTO REQUISITODESCRIZIONE REQUISITOTAG REQUISITO
31SISTEMA E' richiesto il deployment della tearoom su DDR robot, oltre che su robot virtuale.

Requisiti emersi dal confronto col cliente

NUMERO REQUISITOELEMENTO REQUISITODESCRIZIONE REQUISITOTAG REQUISITO
32WAITER Si richiede che il waiter possa interrompere un task in esecuzione a favore di un altro più urgente.

Requirement analysis

  • Per DDR robot si intende un robot dotato di due ruote motrici montate sullo stesso asse. Ogni ruota può essere azionata, in maniera indipendentemente, in avanti o indietro.
  • Con interruzione di un task si intende la possibilità di sospendere un task attualmente in esecuzione per svolgerne un secondo, per poi successivamente riprendere quello interrotto.
  • Per pulizia di un tavolo si intende una generica operazione di lavaggio eseguita per una certa durata di tempo prestabilito.

Problem analysis

Interrompibilità dei task in esecuzione
Da questo nuovo requisito risulta necessario introdurre una nuova semantica di esecuzione dei task. Nelle precedenti versioni infatti i task venivano eseguiti in maniera atomica mentre ora è richiesto di potersi fermare durante l'esecuzione, per eseguire un'altra mansione, e nel caso riprendere in seguito quella bloccata.
Deployment su DDR robot
Per far si che da un robot virtuale il basicrobot possa passare ad un robot fisico è necessario un qualcosa che permetta di far attuare i comandi senza dover conoscere i dettagli dello specifico robot in uso, ma ciò è già fornito qui all'interno della nostra software house.

Test plans

Risulta necessario verificare che il robot abbandoni il task corrente nel momento in cui riceve la richiesta di svolgere un task più urgente, verificandone la transizione di stato.

Project

Interrompibilità dei task in esecuzione

Gli unici task interrompibili scelti sono:
  • La pulizia del tavolo (sanitizing), in quanto risulta di maggiore urgenza servire il cliente.
  • Il ritorno alla home (returnHome), in quanto non è un task relativo al servizio del cliente ma una semplice azione di spostamento.
  • Il prendere l'ordinazione (takingOrder) e la riscossione del pagamento (collectingPayment), in quanto sono task che richiedono l'attesa di un messaggio dal cliente, che potrebbe non arrivare mai. Serve quindi poter "sbloccare" il waiter.
Pulizia del tavolo
Timersmanager
E' stato riutilizzato il timersmanager implementato nello sprint precedente introducendo la possibilità di annullare un conteggio attivo. Per fare ciò si è assegnato ad ogni timer un identificativo univoco, che consente di poter identificare ed eventualmente cancellare la Coroutine corrispondente a uno specifico timer.
Base di conoscenza
E' stata modificata la base di conoscenza relativa ai table aggiungendo per ognuno il tempo rimanente di pulizia (remainingTime).
%% ------------------------------------------ 
%% Teatables
%% ------------------------------------------ 
%% busy		(not free and not clean)
%% dirty	(free and not clean)
%% available (free and clean)	

%% (teatable number, state, cleaning time, seated client)
teatable( 1, available, 0, -1).
teatable( 2, available, 0, -1).
                
Waiter
Quando il waiter arriva al tavolo per sanificarlo, fa partire un timer con il tempo rimanente di pulizia e salva l'identificativo (ID). Successivamente si possono verificare 2 situazioni distinte:
  • Se il timer conclude il conteggio del tempo della pulizia del tavolo, il waiter notificherà la fine della pulizia al resourcemodel.
  • Se il waiter riceve un nuovo task da eseguire:
    1. Interrompe la pulizia, cancellando il timer avente identificativo ID (cancelTimer(ID) a timersmanager).
    2. Notifica al resourcemodel comunicando il tempo rimanente per il completamento della pulizia del tavolo. (cleaningInterrupted(remainingTime) a resourcemodel).
    3. Esegue il nuovo task.
Ritorno alla home
Waiter
Quando il waiter riceve come nuovo task il returnHome, va in uno stato che è in grado di gestire 2 diverse situazioni:
  • L'effettivo raggiungimento della home (notificatogli dal planner), in questo caso il waiter notifica al resourcemodel di aver concluso i task.
  • La ricezione di un nuovo task da eseguire, che comporta:
    1. Interruzione del movimento verso la home, inviando al planner un messaggio stopTask().
    2. L'esecuzione del nuovo task.
Timeout Client
Come detto in precedenza, occorre un meccanismo che permetta di "sbloccare" il waiter durante l'attesa di una risposta dal cliente (l'ordine o il pagamento).
Waiter
Quando il waiter esegue il task takingOrder o collectingPayment, appena arrivato al tavolo fa partire un timer di 10 secondi. Due diverse situazioni possono verificarsi:
  • Il cliente notifica al waiter l'ordine o il pagamento. In questo caso il timer attivato viene cancellato e il waiter continua nella sua esecuzione.
  • Lo scadere del tempo conteggiato dal timer. In questo caso il waiter continua l'esecuzione di eventuali altri task o ritorna alla home. Il cliente invece ritorna nello stato precedente.

Deployment su DDR robot

Sono stati realizzati due robot sulla base di un Mbot.


Our Team