LABORATORIO DI SISTEMI SOFTWARE

Requirements

Questo sprint si occupa della concorrenza fra client, ossia della presenza di più client all'interno della tearoom. Si occupa inoltre della gestione del maxstaytime e di ultimare il pannello di controllo del manager. In particolare, i seguenti punti della tabella dei requisiti:

NUMERO REQUISITO	ATTORE REQUISITO	DESCRIZIONE REQUISITO	TAG REQUISITO
5	WAITER	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)
5bis	WAITER	Il waiter in risposta alla richiesta ricevuta tramite lo smartbell deve poter rispondere che il client deve aspettare un certo tempo prima che vi sia un table AVAILABLE	waitingTime(TIME>0)
6	WAITER	Il waiter deve poter tener conto di quanto tempo un client sia stato al tavolo affinchè non ci resti più di maxstaytime	maxstaytime
7	WAITER	Qualora non ci siano tavoli puliti disponibili (AVAILABLE) il waiter deve poter stimare il massimo tempo di attesa per averne uno	calcWaitingTime
29	SISTEMA	Assicurarsi che all'interno della tearoom ci siano al massimo `N` clienti contemporaneamente (`N`=numero tavoli=2)
30	SISTEMA	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

Requirement analysis

Per maxstaytime si intende il massimo tempo di permanenza all'interno della tearoom consentito al cliente.
Per waitingTime si intende la quantità di tempo che il cliente dovrà attendere prima di entrare in sala. In caso di superamento, il cliente abbandonerà il sistema.

Problem analysis

Concorrenza dei client

La base di conoscenza non richiede modifiche per introdurre più client concorrenti dal momento che per come è stata progettata negli sprint precedenti essa risulta già in grado di scalare a seconda del numero dei client.

Gestione del tempo

Dai requisiti 5, 5bis, 6 e 7 risulta necessario introdurre dei meccanismi che possano tenere traccia dello scorrimento del tempo e poter verificare che un client non stia più di un certo tempo nella stanza.

QActor timersmanager context ctxtearoom {

    State s0 initial {
        discardMsg Off
    }Goto waitingRequests

    State waitingRequests{ println("[TIMER] Waiting for new requests")}
    Transition t0 whenMsg startTimer -> timer
    
    State timer {
        onMsg(startTimer : startTimer(P)) {
            // init timer
        }
    }Goto waitingRequests

}

Nel caso in cui il maxstaytime sia scaduto, se il cliente ha consumato l'ordine dovrà saldare il conto prima di uscire, in caso contrario uscirà direttamente.

Simulazione di più clienti

Anche se non è previsto nei requisiti, è necessario poter simulare più client per fornire una demo al committente. Pertanto sarà necessario modificare il clientsimulator.

View del manager

In sede di sprint retrospective dello sprint 2 nel realizzare un'interfaccia per fornire una demo del sistema si è raggiunto un livello già da ritenersi sufficiente per il committente.

Test plans

Le funzionalità aggiunte possono essere testate con i test precedentemente realizzati, ad eccezione di quelle espresse nel requisito 6 per cui sarà necessario simulare un cliente che non rispetti i vincoli di tempo.

TAG TEST	STATO INIZIALE	STATO FINALE
maxstaytime	Il client si trova nel suo table	Allo scadere di maxstaytime, il client viene accompagnato alla exitdoor, se ha un pagamanto pendente deve aver pagato prima di uscire.

Project

Concorrenza dei client

Dal momento che ci sono più client concorrenti è stato necessario introdurre nel payload di alcuni messaggi l'id specifico del cliente a cui ci si riferisce. Ogni nuovo cliente viene aggiunto come una nuova regola prolog con un id e uno stato corrente, che all'inizio è sempre "waiting".

%% ------------------------------------------ 
%% Clients State
%% ------------------------------------------ 
 
client(1,waiting).

clientsIDs([1]).

Inoltre è stata aggiunta nel codice una variabile busy per sapere se il waiter sia impegnato ad eseguire un task. In caso affermativo, il nuovo task da eseguire viene aggiunto ad una coda di pendingTask in base di conoscenza. Quando il waiter finisce di eseguire un task, controlla se siano presenti task in sospeso in questa coda.

Per una visione più approfondita si rimanda a tearoomkb.pl.

Gestione del tempo

Dovendo misutare lo scorrere di una certa quantità di tempo è risultato utile introdurre un timer, si è pensato ad un attore: timersmanager.
Il quale ricevuto un dispatch (startTimer) che ha come paylod quattro elementi

L'attore a cui notificare lo scadere del tempo
Il nome del messaggio che dovrà mandare allo scadere del tempo
Payload del messaggio che dovrà mandare
Il tempo che deve trascorrere prima dell'invio del messaggio

lancia una coroutine che una volta scaduto il tempo manderà il messaggio all'attore richiesto. In questo modo si possono gestire facilmente più scadenze temporali contemporaneamente, senza che serva un attore-timer per ogni timer.

Simulazione di più clienti

È stato introdotto un unico attore (clientsmanager) che riceve (e risponde a) tutti gli eventi e messaggi destinati ai clienti, aggiornando di volta in volta lo stato relativo allo specifico cliente nella base di conoscenza, impersonificandolo nelle eventuali risposte.

Per una visione più approfondita si rimanda a tearoom.qak.

Our Team

LABORATORIO DI SISTEMI SOFTWARE

Requirements

Requirement analysis

Problem analysis

Concorrenza dei client

Gestione del tempo

Simulazione di più clienti

View del manager

Test plans

Project

Concorrenza dei client

Gestione del tempo

Simulazione di più clienti

Our Team

Ugo Leone Cavalcanti

Amir Al Sadi

Nicolò Romandini