ITRM20110259A1 - AUTOMATED SYSTEM BOOK AND CALL FOR ELIMINATION OF TIMES ON WAITING LISTS - Google Patents

Description

DESCRIZIONE DESCRIPTION

Lo schema diagramma delle classi (figura 2) riporta le entità significative per la realizzazione del sistema. Queste sono distinguibili in classi concettuali che rappresentano gli utenti che accedono/interagiscono col sistema, classi esterne che rappresentano le entità/oggetti NON IMPLEMENTATE ma rese disponibili dagli apparati hw/sw integrati nel sistema, classi/oggetti che rappresentano le entità interne del sistema e infine classi/oggetti che rappresentano la logica di elaborazione del sistema. The diagram of the classes (figure 2) shows the significant entities for the realization of the system. These are distinguishable in conceptual classes that represent the users who access / interact with the system, external classes that represent the entities / objects NOT IMPLEMENTED but made available by the hw / sw devices integrated in the system, classes / objects that represent the internal entities of the system and finally, classes / objects that represent the processing logic of the system.

Nell'ordine esposto, quindi: la classe Usr_gestore rappresenta l'utente che accede al sistema con profilo di gestore/configuratore dello stesso (non accede ai servizi utente), lo stesso pertanto à ̈ dotato di un identificativo e relativa password (attributi gmilid, e gmPassword) e accede unicamente a operazioni di tipo configurazione del sistema (metodo Confìg()) o gestione del sistema (metodo Manage ()) quali avvio/stop del RDBMS. Il profilo di gestione - livello di amministrazione - viene codificato attraverso l'attributo gmProfile. Non vengono dati ulteriori dettagli su questa classe in quanto di supporto e non caratterizzanti del sistema ai fini della sua realizzazione. In the order shown, therefore: the Usr_gestore class represents the user who accesses the system with the manager / configurator profile of the same (does not access the user services), therefore the same is equipped with an identifier and relative password (gmilid attributes, and gmPassword) and only accesses operations such as system configuration (Confìg () method) or system management (Manage () method) such as start / stop of the RDBMS. The management profile - administration level - is encoded through the gmProfile attribute. No further details are given on this class as it is supportive and not characterizing the system for the purpose of its realization.

La classe Usr_sportello rappresenta le informazioni/metodi dell'operatore (o apparato self-service) che funzionalmente svuota le code di attesa (eroga fisicamente i/il servizi/o). Oltre agli attributi identificativo e password ( opUid , opPassword) la classe memorizza anche gli attributi opServizio, opSportello (istanziati a run-time quando l'operatore accede e seleziona servizio e relativo sportello da attivare) a partire dai dati disponibili nelle classi Sportelli , Servizi. In questo modo viene creata l'associazione logica operatore-sportello-servizio che permette di legare le istanze della classe ListeAttesa (code) - tramite i relativi attributi laServizio, laldSportello -all'operatore che svuota la relativa coda. I metodi srvOpen() , srvClose() settano lo stato dello sportello/servizio (aperto/chiuso) impostando gli attributi opServizio e opSportello. Il metodo srvOpen() imposta al relativo valore prelevato dalle classi Sportelli , Servizi ; il metodo srvClose() imposta i suddetti attributi al valore “NULL†. Le classi Usr_web, Usr_totem, Usr_API rappresentano i vari utenti logici secondo il canale attraverso cui avviene l'accesso ai sistema, e relativi servizi utente (http/intemet, totem in loco, applicazioni di terzi). Tutte e tre le classi ereditano attributi e metodi dalia classe padre Usr_sms, con specifiche implementazioni date le peculiarità di comportamento richiesto per ciascuna di esse. Nello specifico, la classe Usr_web possiede gli attributi tipici per gestire il riconoscimento degli utenti che accedono dal canale internet (http) quindi user-id e password (uUid e uPassword) e e-mail ( uEmail ). I metodi della classe sono i metodi tipici della gestione di un entità resa persistente in un archivio fisico (su RDBMS), ossia il set CRUD() - Create, Read, Update, Delete - più l'operazione uLogin() che ha il compito di verificare i dati di accesso e istanzia o meno l'oggetto per l'utente specifico, in base alla conclusione positiva del riconoscimento delle credenziali inserite. La classe Usr_totem in più implementa un attributo specifico fakeGsmNum che sovrascrive l'attributo padre gsmNumber per gestire lo scenario di utilizzo del sistema dal totem che permette la stampa tradizionale su carta del numero di prenotazione. In questo caso infatti deve essere gestito un numero GSM fittizio (appunto fake) che il sistema riconosce come un numero cellulare a cui non può essere inviata alcuna notifica di stato della coda di attesa. La classe Usr_API in più implementa un metodo specifico rawlnsertPRN() che permette di registrare un “numero identificativo della prenotazione†(PRN) generato direttamente dall'applicazione chiamante (client API), sovrascrivendo la logica di generazione PRN interna al sistema. La classe padre Usr_sms riporta il set di attributi minimi e comuni. L'attributo gsmNumber à ̈ il numero di cellulare associato all'utente che richiede la prenotazione, uPRN à ̈ l'identificativo univoco (id) della prenotazione (generato dal sistema) e assegnata all'utente, uAlert à ̈ il valore personalizzato richiesto dall'utente (o assegnato di default) per l'invio dei messaggi di notifica sullo stato della coda a cui l'utente risulta associato tramite l'id uPRN. The Usr_sportello class represents the information / methods of the operator (or self-service device) that functionally empties the waiting queues (physically delivers the services). In addition to the identification and password attributes (opUid, opPassword), the class also stores the attributes opServizio, opSportello (instantiated at run-time when the operator accesses and selects the service and relative branch to be activated) starting from the data available in the Branches, Services classes . In this way, the operator-counter-service logical association is created which allows you to link the instances of the ListeAttesa (code) class - through the relative attributes laServizio, laldSportello - to the operator who empties the relative queue. The srvOpen (), srvClose () methods set the status of the door / service (open / closed) by setting the attributes opServizio and opSportello. The srvOpen () method sets the relative value taken from the Sportelli, Servizi classes; the srvClose () method sets the above attributes to the value â € œNULLâ €. The Usr_web, Usr_totem, Usr_API classes represent the various logical users according to the channel through which the system is accessed, and related user services (http / intemet, on-site totem, third party applications). All three classes inherit attributes and methods from the parent class Usr_sms, with specific implementations given the peculiarities of behavior required for each of them. Specifically, the Usr_web class has the typical attributes to manage the recognition of users who access from the internet channel (http), therefore user-id and password (uUid and uPassword) and e-mail (uEmail). The methods of the class are the typical methods of managing an entity persisted in a physical archive (on RDBMS), that is the set CRUD () - Create, Read, Update, Delete - plus the uLogin () operation which has the task to verify the access data and instantiate or not the object for the specific user, based on the successful conclusion of the recognition of the entered credentials. The Usr_totem class moreover implements a specific fakeGsmNum attribute that overrides the parent attribute gsmNumber to manage the scenario of use of the system from the totem that allows the traditional printing on paper of the reservation number. In this case, in fact, a fake GSM number must be managed, which the system recognizes as a mobile number to which no notification of the status of the waiting queue can be sent. The Usr_API class also implements a specific rawlnsertPRN () method that allows you to register a â € œReservation Identification Numberâ € (PRN) generated directly by the calling application (client API), overwriting the PRN generation logic inside the system. The parent class Usr_sms reports the minimum and common set of attributes. The gsmNumber attribute is the mobile number associated with the user requesting the reservation, uPRN is the unique identifier (id) of the reservation (generated by the system) and assigned to the user, uAlert is the customized value requested by the 'user (or assigned by default) for sending notification messages on the status of the queue to which the user is associated with the id uPRN.

La classe astratta SMS_MACHINE_QUEUE e le due (istanze) figlie SMS_OUT e SMS_IN rappresentano le strutture dati per le code di ingresso/uscita implementate dall'HW integrato SMS_MACHINE. Di queste, gli attributi necessari ai fini del'implementazione del sistema, sono rappresentati dai campi: gsmnumber, à ̈ il numero da/a cui il modem GSM riceve/invia SMS nel formato “+39xxxxxxx†; i campi con post-fisso date, rappresentano i timestamp di invio/ricezione/lettura delI'SMS. Nello specifico; wrìtedate e senddate (classe SMS OUT) sono rispettivamente il timestamp della scrittura nella coda di uscita e di invio effettivo delI'SMS; msgdate e readdate (classe SMS_IN) sono, rispettivamente, gli attributi di arrivo del messaggio e di effettiva lettura dalla coda; l'attributo message à ̈ il contenuto testuale (160 caratteri) delI'SMS (in ambedue le classi). The abstract class SMS_MACHINE_QUEUE and the two (instances) children SMS_OUT and SMS_IN represent the data structures for the entry / exit queues implemented by the integrated HW SMS_MACHINE. Of these, the attributes necessary for the implementation of the system are represented by the fields: gsmnumber, is the number from / to which the GSM modem receives / sends SMS in the format â € œ + 39xxxxxxxâ €; the fields with post-fixed date, represent the sending / receiving / reading timestamps of the SMS. In particular; wrìtedate and senddate (class SMS OUT) are respectively the timestamp of the writing in the output queue and of the actual sending of the SMS; msgdate and readdate (class SMS_IN) are, respectively, the attributes of arrival of the message and of actual reading from the queue; the message attribute is the textual content (160 characters) of the SMS (in both classes).

La classe Sportelli implementa l'entità logica per la memorizzazione degli sportelli presenti dove viene erogato il servizio. Idem la classe Servizi implementa l'entità logica per i vari servizi disponibili agli sportelli. Attributi specifici: svTmedioAttesa, à ̈ il tempo medio di attesa per il dato servizio calcolato in tempo reale; svTmedLastDay, à ̈ l'ultimo tempo medio calcolato il giorno precedente (usato come valore di default alto start del sistema); svDefoultAlertNum, à ̈ il valore di default - in termini di numero di utenti mancanti al proprio turno - da utilizzare per l'invio dei messaggi di notifica nel caso non sia richiesto un valore specifico dall'utente all'atto della prenotazione. La classe Richieste viene popolata a run-time a partire dalla coda di ingresso SMS_IN, e contiene tutte le richieste/comandi (attributo rqActionRequest) che possono essere inviati (e riconosciuti) dal sistema. I comandi sono stringhe di testo che codificano i servizi implementati dal sistema. Questi sono, nell'ordine, descritti dalla seguente grammatica: “PRENOTA [servizio] [alert]†, effettua una prenotazione (assegna un PRN) per il servizio (parametro opzionale, il valore di default à ̈ il primo servizio configurato nel sistema nella classe Servizi), impostando ad alert (opzionale), il numero per la ricezione di avviso automatico sullo stato della coda (attributo rqAlertYN) - questo numero rappresenta il numero di utenti mancanti per essere serviti prima dell'utente richiedente - (il valore di default à ̈ dato dall'attributo svDefaultAlertNum configurato nel sistema nella classe Servizi ); “INTERROGA†, il sistema restituisce all'utente richiedente, un SMS con le informazioni relative allo stato della sua prenotazione (numero di prenotazione - PRN, numero utenti in attesa, tempo medio di attesa calcolato al momento); “RIACCODA†, il sistema rimette in coda l'utente assegnando un nuovo numero di prenotazione PRN (il nuovo PRN, in alcune implementazioni che lo richiedono, può essere determinato utilizzando dei criteri di priorità, non inserendo quindi l'utente all'inizio della coda); “AVVISA alert†, l'utente richiede di modificare il parametro di avviso attuale impostato nel sistema (attributo laAlert della classe ListeAttesa) con il nuovo valore (obbligatorio) alert; "RIMUOVI", il sistema elimina dalla coda di attesa (classe ListeAttesa) la prenotazione relativa all'utente richiedente. La classe implementa due metodi (del tipo Set(), Get( )) che inseriscono (a partire dalla coda SMS__IN ), o prelevano, dall'elenco delle richieste (istanze a run-time) i comandi da elaborare (a seguito dell'elaborazione il sistema accoda in SMS__OUT gli eventuali SMS da inviare). The Counters class implements the logic entity for storing the counters present where the service is provided. Ditto the Services class implements the logical entity for the various services available at the counters. Specific attributes: svTmedioAttesa, it is the average waiting time for the given service calculated in real time; svTmedLastDay, is the last average time calculated on the previous day (used as the system's high start default value); svDefoultAlertNum, is the default value - in terms of the number of missing users on their turn - to be used for sending notification messages if a specific value is not requested by the user at the time of booking. The Requests class is populated at run-time starting from the SMS_IN input queue, and contains all the requests / commands (rqActionRequest attribute) that can be sent (and acknowledged) by the system. Commands are text strings that encode the services implemented by the system. These are, in order, described by the following grammar: â € œBOOK [service] [alert] â €, make a reservation (assign a PRN) for the service (optional parameter, the default value is the first service configured in the system in the Services class), setting to alert (optional), the number for receiving an automatic alert on the status of the queue (rqAlertYN attribute) - this number represents the number of missing users to be served before the requesting user - (the value by default it is given by the svDefaultAlertNum attribute configured in the system in the Services class); â € œINTERROGâ €, the system returns to the requesting user an SMS with information relating to the status of his reservation (reservation number - PRN, number of users waiting, average waiting time calculated at the moment); â € œRECODEâ €, the system re-queues the user by assigning a new PRN reservation number (the new PRN, in some implementations that require it, can be determined using priority criteria, thus not entering the user at the beginning of the tail); â € œWARN alertâ €, the user requests to modify the current alert parameter set in the system (laAlert attribute of the ListeAttesa class) with the new (mandatory) value alert; "REMOVE", the system removes the reservation relating to the requesting user from the waiting queue (ListeAttesa class). The class implements two methods (of the type Set (), Get ()) which insert (starting from the SMS__IN queue), or take, from the list of requests (instances at run-time) the commands to be processed (following the processing, the system queues any SMS to be sent in SMS__OUT).

La classe ListeAttesa viene popolata a run-time a partire dalle richieste di prenotazione prelevate dal sistema dalla classe Richieste. La classe rappresenta quindi le code virtuali degli utenti in attesa di essere serviti. Ogni istanza (utente in coda) memorizza gli attributi necessari per la gestione della logica di assegnazione, interrogazione, avviso, riaccodamento e rimozione di una prenotazione. Gli attributi fondamentali per queste operazioni, sono: laNumGsm, à ̈ il numero GSM associato all'utente che ha richiesto la prenotazione (nel formato 39xxxx); iaServizio à ̈ il codice del servizio richiesto (distintivo della coda, quindi); laAlert à ̈ il numero degli utenti mancanti al proprio turno ed à ̈ usato dal sistema per l'invio degli avvisi automatici; laPmAssigned à ̈ il numero di prenotazione unico assegnato all'utente; laStatoAttesa à ̈ un codice identificativo dello stato della prenotazione (IN ATTESA|IN SERV!ZIO|SERVITO|ANNULLATO); laldSportello à ̈ il codice identificativo dello sportello che ha servito l'utente (quando lo stato=IN SERVlZIO|SERVITO); laTimestampINIserv e laTimestampENDserv sono i timestamp di inizio e fine servito utilizzati per il calcolo in tempo reale del tempo medio di servizio. I metodi implementati dalla classe sono costituiti dalle principali operazioni di gestione della coda: GetQ, preleva dalla coda il prossimo PRN da servire (secondo un modello FIFO); Insert() inserisce in coda un nuovo utente da servire (restituisce il PRN identificativo); Query_status(), restituisce lo stato della coda per un PRN specifico (lo stato à ̈ costituito dalla tripla numerica, #pm utente servito, #utenti in attesa, #tempo medio di attesa ); Reinsert(,) inserisce in coda un utente (PRN) ancora da servire (restituisce un nuovo PRN identificativo, considerando un eventuale criterio di priorità); SetStatus( ), imposta il nuovo stato per una specifica prenotazione PRN (lo stato deve essere un elemento dell'insieme “IN ATTESA|IN SERVIZIOISERVITOIANNULLATO", non può quindi assumere valori NULL). Essendo popolate a runt-time, le classi (istanze) Richieste e ListeAttesa devono essere rese persistenti in entità del componente RDBMS utilizzato, onde evitare perdita di dati a causa di eventuali abend applicativi. The ListeAttesa class is populated at run-time starting from the booking requests taken by the system from the Request class. The class therefore represents the virtual queues of users waiting to be served. Each instance (queued user) stores the attributes necessary for managing the logic of assigning, querying, warning, re-queuing and removing a reservation. The fundamental attributes for these operations are: laNumGsm, is the GSM number associated with the user who requested the reservation (in the 39xxxx format); iaServizio is the code of the requested service (distinctive of the queue, therefore); laAlert is the number of missing users on their turn and is used by the system for sending automatic alerts; laPmAssigned is the unique reservation number assigned to the user; laStatoAttesa is an identification code of the booking status (PENDING | IN SERV! TIO | SERVED | CANCELED); laldSportello is the identification code of the counter that served the user (when the status = IN SERVICE | SERVED); laTimestampINIserv and laTimestampENDserv are the start and end served timestamps used for the real-time calculation of the average service time. The methods implemented by the class consist of the main queue management operations: GetQ, takes the next PRN to be served from the queue (according to a FIFO model); Insert () queues a new user to be served (returns the identifying PRN); Query_status (), returns the status of the queue for a specific PRN (the status consists of the triple number, #pm user served, # users waiting, # average waiting time); Reinsert (,) queues a user (PRN) still to be served (returns a new identifying PRN, considering a possible priority criterion); SetStatus (), sets the new status for a specific PRN reservation (the status must be an element of the collection â € œPENDING | IN SERVICEISERVITOANCULLED ", therefore it cannot assume NULL values). instances) Requests and Waiting Lists must be made persistent in the entity of the RDBMS component used, in order to avoid data loss due to possible application abends.

La classe Visore memorizza le informazioni di stato delle code/servizi da visualizzare sui monitor posti nel luogo di erogazione dei servizi. Il metodo View( ) restituisce le suddette, via protocollo http, in formato HTML. The Viewer class stores the status information of the queues / services to be displayed on the monitors located in the place where the services are provided. The View () method returns the above, via http protocol, in HTML format.

La classe Demone à ̈ una classe astratta che rappresenta la logica di elaborazione continuamente in stato di esecuzione, detti anche processi demon (che implementano la bussiness logie - escluso il motore rdbms). Questi sono essenzialmente due: il processo dHttp (http server), che risponde alle richieste che avvengono su protocollo http (web, totem e api), mediando tra il core-process del sistema ( dWAS_coreEngine ) e l’utente che richiede i servizi applicativi; il processo core che implementa la logica di gestione delle code virtuali e relative notifiche (classe dWAS_coreEngine), costituita da una web-application in linguaggio Python. Dopo aver descritto il sistema da un punto di vista statico (descrizione delle entità/classi e loro semantica), le descrizioni che seguono puntano a dettagliare il comportamento dinamico del sistema descrivendo i principali scenari di utilizzo dello stesso, col supporto di diagrammi di attività e di comunicazione tra i vari componenti base (diagrammi UML). La (figura 3) e (figura 4) illustrano ta scenario di iterazione utente/sistema nel caso di invio di un comando di prenotazione da un terminale mobile (via rete cellulare GSM/GPRS). L'utente (schematizzato dall'attore Usr_sms) compone il testo del messaggio PRENOTA (con i parametri opzionali alert e servizio, il cui significato à ̈ stato illustrato in precedenza), il messaggio viene ricevuto dall'HW SMS Machine (modem GSM) e archiviato nella coda di ingresso messaggi (indicata in (figura 4) dalla classe SMS_I N). Il sistema legge da detta coda, accoda nella classe Richieste e determina la prima richiesta di prenotazione pendente (function LeggeCodaRicezione( ); argument: cmd, return: gsmnum, servizio, alert ), verifica che il gsmnum richiedente non abbia già una prenotazione per quel servizio (function VerificaPrenotazione( ): argument: gsmnum return: true/false). Se non esiste già una prenotazione, imposta Valeri per l'avviso automatico ( alert viene impostato al valore di default se NULL valore utente, function Registra Alert( )). Contemporaneamente il sistema accoda la prenotazione (nella classe ListeAttesa) per il servizio richiesto, function: MettelnLista(.); argument: servizio, return: pm - id prenotazione, len -lunghezza coda e tmed - tempo medio di attesa), compone una stringa di testo di notifica prenotazione (TXT PRN) da inviare come SMS accodandolo nella relativa coda di uscita messaggi ( SMS_OUT) del modem GSM della SMS_Machine (function: ComponeSMS(.)). Le action/funzioni GSM_Modem(SEND|RECElVE,.) sono chiaramente asincrone rispetto alle action/funzioni effettuate dal sistema, e rappresentano l'invio/ricezione materiale del SMS da parte dell'hw SMS_Machine. Le code interne (classi SMS_iN, SMS_OUT e Richieste schematizzati in (figura 4)) non solo quelle di servizio, quindi, sono necessarie e funzionali alla gestione dei colloqui asincroni tra i componenti integrati nel sistema. Lo scenario si chiude nel momento in cui l'utente riceve sul terminale mobile l' SMS con il codice prenotazione (PRN) richiesto. Notare che alcuni percorsi possono terminare in stati finali, indicati dal simbolo (X), che non comportano alcun invio di SMS (es. prenotazione già esistente). La (figura 5) illustra il caso d'uso del sistema che prevede la prenotazione del servizio attraverso un totem (con schermo touch-screen). Il caso d'uso evidenzia la peculiarità del sistema, che prevede la possibilità di scegliere di ricevere il ticket di prenotazione via SMS e non su carta ( ticketless ). Per dettagliare tale peculiarità, lo schema di (figura 6) illustra, attraverso il diagramma delle attività, il colloquio utentesistema e le relative componenti coinvolte. L'attore Usr_totem rappresenta l'utente che richiede il servizio attraverso il totem, tale richiesta avviene per mezzo di un interfaccia web (HTML), su protocollo http, che permette all'utente di selezionare il servizio a cui prenotarsi, quindi se ricevere il ticket di prenotazione via SMS (il valore di alert per le notifiche, in questo caso, viene impostato al valore di default). La scelta dell'opzione SMS innesca la sequenza di (figura 6). Il sistema espone una function PRENOTA: argument gsm, numero di telefono inserito dall’utente, servizio e alert. La funzione genera un codice di verìfica ( txt) da inviare come SMS ai numero gsm inserito (serve per verificare la veridicità della richiesta ed evitare abusi). L'utente che riceve il SMS deve rispondere con tale codice di verifica ( txt) per confermare la richiesta. L'interfaccia web avvisa l'utente sullo schermo del totem che riceverà detto codice di verifica. Se il codice richiesto viene verificato (function Verificato(.)) come proveniente dai numero gsm richiesto, lo scenario dì prenotazione si rifà a quanto già dettagliato in (figura 3) e (figura 4). The Daemon class is an abstract class that represents the processing logic continuously in a running state, also called demon processes (which implement bussiness logic - excluding the rdbms engine). These are essentially two: the dHttp process (http server), which responds to requests that occur on the http protocol (web, totem and api), mediating between the core-process of the system (dWAS_coreEngine) and the user requesting the services. applications; the core process that implements the logic for managing virtual queues and related notifications (class dWAS_coreEngine), consisting of a web-application in Python language. After having described the system from a static point of view (description of the entities / classes and their semantics), the following descriptions aim to detail the dynamic behavior of the system by describing the main usage scenarios of the same, with the support of activity diagrams and communication between the various basic components (UML diagrams). (Figure 3) and (Figure 4) illustrate the user / system iteration scenario in the case of sending a reservation command from a mobile terminal (via GSM / GPRS cellular network). The user (schematized by the Usr_sms actor) composes the text of the BOOK (with the optional parameters alert and service, the meaning of which has been illustrated above), the message is received by the HW SMS Machine (GSM modem) and stored in the message entry queue (indicated in (figure 4) by the SMS_I N class). The system reads from said queue, queues in the Requests class and determines the first pending reservation request (function LeggeCodaRicezione (); argument: cmd, return: gsmnum, service, alert), verifies that the requesting gsmnum does not already have a reservation for that service (function Verify Reservation (): argument: gsmnum return: true / false). If a reservation does not already exist, set Valeri for automatic alert (alert is set to default value if NULL user value, function Register Alert ()). At the same time, the system queues the reservation (in the ListeAttesa class) for the requested service, function: MettelnLista (.); argument: service, return: pm - reservation id, len - queue length and tmed - average waiting time), composes a reservation notification text string (TXT PRN) to be sent as an SMS by queuing it in the relative message output queue (SMS_OUT) of the GSM modem of the SMS_Machine (function: ComponeSMS (.)). The GSM_Modem actions / functions (SEND | RECElVE ,.) are clearly asynchronous with respect to the actions / functions performed by the system, and represent the material sending / receiving of the SMS by the SMS_Machine hw. The internal queues (classes SMS_iN, SMS_OUT and Requests schematized in (figure 4)) not only the service ones, therefore, are necessary and functional for the management of asynchronous conversations between the components integrated in the system. The scenario closes when the user receives the SMS with the requested booking code (PRN) on the mobile terminal. Note that some routes may end in final states, indicated by the symbol (X), which do not involve any sending of SMS (eg booking already existing). The (figure 5) illustrates the use case of the system which provides for the booking of the service through a totem (with touch-screen). The use case highlights the peculiarity of the system, which provides the possibility to choose to receive the booking ticket via SMS and not on paper (ticketless). To detail this peculiarity, the diagram of (figure 6) illustrates, through the activity diagram, the user-system interview and the related components involved. The Usr_totem actor represents the user who requests the service through the totem, this request takes place through a web interface (HTML), on http protocol, which allows the user to select the service to book, so whether to receive the booking ticket via SMS (the alert value for notifications, in this case, is set to the default value). Choosing the SMS option triggers the sequence of (figure 6). The system displays a BOOK function: argument gsm, telephone number entered by the user, service and alert. The function generates a verification code (txt) to be sent as an SMS to the gsm number entered (used to verify the veracity of the request and to avoid abuse). The user who receives the SMS must reply with this verification code (txt) to confirm the request. The web interface notifies the user on the totem screen that he will receive this verification code. If the requested code is verified (function Verified (.)) As coming from the gsm number requested, the booking scenario refers to what is already detailed in (figure 3) and (figure 4).

I diagrammi di comunicazione della (figura 7) e (figura 8) illustrano invece gli scenari d'uso da parte dell'operatore allo sportello ( Usr_sportello ) che operativamente svuota le code dei servizi. I due scenari illustrano il flusso e la logica di elaborazione: 1) nel caso in cui l'operatore chiami il prossimo utente da servire avendo servito il precedente PRN (figura 7); 2) nel caso in cui viene chiamato il prossimo PRN da servire ma il precedente non à ̈ stato servito (non si à ̈ presentato allo sportello), in questo caso il sistema riaccoda il PRN non servito generando un nuovo numero prenotazione (figura 8). L'interfaccia per l'operatore à ̈ sempre una pagina web (HTML) a cui lo stesso accede via protocollo http (gestita dal componente Demone), da questa viene selezionato lo sportello e il servizio da attivare, il sistema predispone un layout di sintesi dello stato della coda (utente servito, utenti in attesa, tempo medio di servizio) e la funzione di chiamata del prossimo numero con la possibilità di impostazione di un flag=SRV_OK|SRV_NOK che permetta di attivare la funzione http di chiamata del prossimo numero (indicata col generico nome Next( )) che prevede appunto come parametri di ingresso (argument), il servizio di riferimento e il flag suddetto. In (figura 7), pertanto, à ̈ illustrato il caso in cui tale funzione viene richiamata settando il parametro flag=SRV_OK (ossia il PRN à ̈ stato servito correttamente e chiama il prossimo in coda). Il sistema quindi preleva dalla coda del servizio il prossimo (tramite il metodo Gef() della classe ListeAttesa ); attiva il subcomponente Alert, interroga la classe ListeAttesa (col metodo Query__status( )) per ricavare tutti i numeri gsm a cui inviare le notifiche di stato delle code. I numeri recuperati (vettore gsm[.]) vengono accodati con relativo messaggio di alert (vettore di messaggi alert_txt[.]) nella coda di uscita della SMS__Machine ( SMS_OUT ). Allo stesso tempo il componente primario (Demone): aggiorna i dati (attributi) per la visualizzazione dello stato delle code tramite la classe Visore (attraverso il metodo View( ))·, e determina il prossimo PRN da servire e relativo numero gsm per la notifica (warn _txt à ̈ un messaggio di avviso del proprio turno) e anch'esso viene accodato (come messaggio singolo) nella coda di uscita della SMS Machine (SMS_OUT). La coda di uscita SMS_OUT viene svuotata (invio SMS) in modo asincrono dal modem GSM della SMS_Machine. Il flusso di gestione dello scenario in cui il numero PRN chiamato non à ̈ stato servito (flag=SRV_NOK) à ̈ similare a quanto già illustrato per il caso precedente. In più il sistema, dovendo re-inserire in coda il PRN non servito, deve generare un nuovo numero PRN anche per esso (chiamando il metodo Relnsert( ) della classe ListeAttesa, (figura 8) flusso numero 3), e ai messaggi di notifica da inviare à ̈ necessario pertanto aggiungere l'SMS di notifica del nuovo numero assegnato ( NEW_PRN) al perdente posto ( gsm_PRN_NOT_SERVED ) (figura 8) flusso numero 4. The communication diagrams of (figure 7) and (figure 8) instead illustrate the scenarios of use by the operator at the counter (Usr_sportello) who operationally empties the service queues. The two scenarios illustrate the flow and the processing logic: 1) if the operator calls the next user to be served having served the previous PRN (figure 7); 2) if the next PRN to be served is called but the previous one has not been served (has not presented itself at the counter), in this case the system re-queues the unserved PRN by generating a new reservation number (figure 8) . The interface for the operator is always a web page (HTML) which the operator accesses via the http protocol (managed by the Demon component), from which the counter and the service to be activated are selected, the system prepares a summary layout the status of the queue (user served, users waiting, average service time) and the function of calling the next number with the possibility of setting a flag = SRV_OK | SRV_NOK that allows you to activate the http function for calling the next number ( indicated with the generic name Next ()) which foresees the reference service and the aforementioned flag as input parameters (argument). In (figure 7), therefore, it is illustrated the case in which this function is called by setting the flag parameter = SRV_OK (ie the PRN has been served correctly and calls the next one in the queue). The system then fetches the next from the service queue (through the Gef () method of the ListeAttesa class); activates the Alert subcomponent, queries the ListeAttesa class (with the Query__status () method) to obtain all the gsm numbers to which to send the queue status notifications. The retrieved numbers (gsm vector [.]) Are queued with the relative alert message (alert_txt message vector [.]) In the SMS__Machine output queue (SMS_OUT). At the same time the primary component (Daemon): updates the data (attributes) for viewing the status of the queues through the Viewer class (through the View () method), and determines the next PRN to be served and the relative gsm number for the notification (warn _txt is a warning message of your turn) and it is also queued (as a single message) in the SMS Machine output queue (SMS_OUT). The SMS_OUT output queue is emptied (SMS sending) asynchronously by the SMS_Machine GSM modem. The management flow of the scenario in which the called PRN number was not served (flag = SRV_NOK) is similar to what has already been illustrated for the previous case. In addition, the system, having to re-queue the unserved PRN, must generate a new PRN number for it too (calling the Relnsert () method of the ListeAttesa class, (figure 8) flow number 3), and the notification messages to be sent, it is therefore necessary to add the SMS notifying the new assigned number (NEW_PRN) to the loser (gsm_PRN_NOT_SERVED) (figure 8) flow number 4.

Claims (10)

RIVENDICAZIONI 1 . Sistema di prenotazione da remoto per liste di attesa comprendente un terminale totem touch-screen (figura 1 — TECH_POC_TOTEM) e un apparato hw di ricezione/trasmissione SMS (figura 1 - SMS_MACHINE), caratterizzato dal fatto di integrare la tecnologia SMS come sostituto della prenotazione cartacea (c.d. ticketless), permettendo quindi all'utente di svolgere anche altre incombenze lontano dalla sede in cui effettivamente si svolge il servizio (coda virtuale), su protocollo standard IP ( Internet Protocof). L’apparato hw di ricezione/trasmissione SMS (figura 1 - SMSC) à ̈ costituito dalla centralina SMS di un operatore telefonico (mobile). CLAIMS 1. Remote booking system for waiting lists comprising a touch-screen totem terminal (figure 1 - TECH_POC_TOTEM) and an SMS receiving / transmitting hardware device (figure 1 - SMS_MACHINE), characterized by the fact of integrating SMS technology as a substitute of the paper booking (so-called ticketless), thus allowing the user to perform other tasks away from the location where the service actually takes place (virtual queue), on standard IP protocol (Internet Protocol). The hw SMS receiving / transmitting device (figure 1 - SMSC) consists of the SMS control unit of a (mobile) telephone operator. 2. Sistema di prenotazione da remoto secondo la rivendicazione 1 , in cui il componente apparato di ricezione/trasmissione SMS_MACHINE à ̈ costituito da un MODEM GSM/GPRS con alloggiamento per SIM-CARD. 2. Remote booking system according to claim 1, in which the SMS_MACHINE receiving / transmitting apparatus component consists of a GSM / GPRS MODEM with housing for SIM-CARD. 3. Sistema di prenotazione da remoto secondo qualunque rivendicazione precedente, caratterizzato dal fatto di implementare una logica elaborativa che permette all'operatore (figura 1- QUEUE CALLER) di indicare al sistema se l’utente prossimo da servire deve essere rimesso in attesa (figura 8). 3. Remote booking system according to any previous claim, characterized by the fact of implementing a processing logic that allows the operator (figure 1- QUEUE CALLER) to indicate to the system whether the next user to be served must be put back on hold ( figure 8). 4. Sistema di prenotazione da remoto secondo qualunque rivendicazione precedente, caratterizzato dalle funzioni di invio informazioni automatiche verso l'utente. Le informazioni sono costituite dalla tripla: Numero prenotazione (PRN), Numero utenti in attesa e Tempo medio di attesa (calcolato in tempo reale). In alternativa, le informazioni sono integrate da messaggi promozionali. 4. Remote booking system according to any preceding claim, characterized by the functions of sending automatic information to the user. The information consists of the triple: Reservation number (PRN), Number of users waiting and Average waiting time (calculated in real time). Alternatively, the information is supplemented by promotional messages. 5. Sistema di prenotazione da remoto secondo qualunque rivendicazione precedente, caratterizzato da funzioni di ricezione comandi dall’utente per la richiesta dei servizi applicativi del sistema codificate da stringhe testuali secondo lo standard SMS e costituite dalla quintupla: PRENOTA, INTERROGA, AWISA, RIACCODA, RIMUOVI. 5. Remote booking system according to any preceding claim, characterized by functions for receiving commands from the user for requesting system application services encoded by text strings according to the SMS standard and consisting of the quintuple: BOOK, QUESTION, AWISA, RIACCODA , REMOVE. 6. Sistema di prenotazione da remoto secondo la rivendicazione 2, in cui il numero di accesso al servizio SMS à ̈ costituito da un numero breve fornito dall’operatore mobile specifico per il servizio; in alternativa, il numero breve potrà essere a tariffazione speciale (c.d, MAS, SMS Premium). 6. Remote booking system according to claim 2, in which the access number to the SMS service consists of a short number provided by the mobile operator specific for the service; alternatively, the short number may have a special rate (so-called, MAS, SMS Premium). 7. Sistema di prenotazione da remoto secondo la rivendicazione 3, in cui la rimessa in attesa ( rìaccodamento ) avviene applicando un algoritmo a priorità. 7. Remote booking system according to claim 3, in which the putting on hold (re-queuing) takes place by applying a priority algorithm. 8. Sistema di prenotazione da remoto secondo qualunque rivendicazione precedente, in cui l’operatore allo sportello à ̈ dotato di un interruttore hw a due stati (OK/NOK) integrato su scheda a standard WI-FI con ingresso digitale; in alternativa, l’operatore à ̈ dotato di un apparato hw costituito da un lettore di codice a barre o a matrice (QR code). 8. Remote booking system according to any preceding claim, in which the operator at the counter is equipped with a two-state hardware switch (OK / NOK) integrated on the WI-FI standard card with digital input; alternatively, the operator is equipped with a hardware device consisting of a barcode or matrix (QR code) reader. 9. Sistema di prenotazione da remoto secondo la rivendicazione 1, in cui il componente apparato hw totem à ̈ dotato di interfaccia a standard RFID per la rilevazione automatica dell’utente (e relativo numero cellulare) tramite supporto dotato di RFID Tag (es. su smart-card). 9. Remote booking system according to claim 1, in which the hw totem device component is equipped with a standard RFID interface for automatic detection of the user (and relative mobile number) by means of a support equipped with an RFID Tag (eg. on smart-card). 10. Sistema di prenotazione da remoto secondo la rivendicazione 2 e qualunque altra seguente, in cui la configurazione viene modificata secondo un modello Master-Slave (Uno-a-molti). In questa configurazione il sistema Master ha la funzione di inoltro (enterprise gateway) dei messaggi in ingresso ai sistemi Slave (siti remoti, dislocati sul territorio). In questa configurazione il componente Master accede alla sola coda di ingresso della SMSC (SMS_I N), à ̈ dotato di tre strutture dati specifiche per: (a) la geolocalizzazione sul territorio dei siti Slave (su piattaforma Google MAPS), (b) l'associazione tra indirizzo IP dello Slave e “codice unico identificativo†(CUI) dello stesso, (c) l'associazione tra “codice unico identificativo" (CUI) dello slave e numero GSM chiamante. In questa configurazione il comando “prenota†viene sostituito dal codice CUI. I sistemi Slave, in questa configurazione, accedono alla sola coda di uscita della SMSC (SMS_OUT).10. Remote booking system according to claim 2 and any other claim that follows, in which the configuration is modified according to a Master-Slave model (One-to-many). In this configuration, the Master system has the function of forwarding (enterprise gateway) of incoming messages to the Slave systems (remote sites, located throughout the territory). In this configuration, the Master component accesses only the SMSC input queue (SMS_I N), it is equipped with three specific data structures for: (a) the geolocation of the Slave sites on the territory (on the Google MAPS platform), (b) the 'association between the IP address of the Slave and the â € œunique identification codeâ € (CUI) of the same, (c) the association between the â € œunique identification code "(CUI) of the slave and the calling GSM number. In this configuration, the command â € “book” is replaced by the CUI code The Slave systems, in this configuration, access only the output queue of the SMSC (SMS_OUT).