LABORATORIO DI SISTEMI SOFTWARE
Requirements
5 | WAITER |
Il | waitingTime(0) |
5bis | WAITER |
Il | waitingTime(TIME>0) |
6 | WAITER |
Il | maxstaytime |
7 | WAITER |
Qualora non ci siano tavoli puliti disponibili (AVAILABLE) il | 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 |
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ù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 unQActor 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ù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
maxstaytime | Il |
Allo scadere di maxstaytime, il |
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
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:
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
Simulazione di più clienti
È stato introdotto un unico attore (
Per una visione più approfondita si rimanda a tearoom.qak.