3.3 Piattaforma software
3.3.3 Specifiche del sistema
3.3.3.7 Richiesta di manutenzione di un noise logger – Errore
Qualora un noise logger di maglia larga non comunicasse per diversi giorni con il server TLI, il sistema rileva automaticamente un problema in quel determinato sensore. Ciò sarà visibile all’utente in quanto il noise logger sarà di un colore differente rispetto agli altri; inoltre, una volta selezionato, si noterà uno stato differente da “OK”.
Questa funzionalità permette quindi di richiedere un intervento al fine di ripristinare il corretto funzionamento del dispositivo. La mancanza di comunicazione può essere dovuta a due cause che dovranno essere trattate separatamente: errore della Capillary
Network (sarà compito di un operatore TLI effettuare la manutenzione) oppure errore
interno al noise logger (sarà compito di un operatore dell’azienda fornitrice della sensoristica effettuare l’intervento).
Davide Pellegrino [102/146] Si procederà quindi ad una prima verifica della Capillary Network al fine di riparare il problema; successivamente all’intervento dell’operatore TLI si effettua un controllo sul corretto funzionamento del noise logger in questione. Se il dispositivo presenta ancora un errore, verrà richiesto l’intervento dell’operatore specializzato dell’azienda fornitrice della sensoristica per ripararne il danno.
Anche in questo scenario saranno presenti tre macrofasi che riguardano l’apertura del ticket, l’elaborazione del ticket e la chiusura del ticket.
Un ticket sarà caratterizzato dalla coppia (Stato, Info) che descrive il livello di avanzamento della richiesta di manutenzione. Nella seguente tabella vengono riportate quelle relative alla presenza di un errore di rete:
ID
Stato
Info
R1 Aperto attesa che un operatore TLITicket inserito nel sistema, in lo prenda in esame
R2 In elaborazione – Capillary Network
La manutenzione è in fase di elaborazione; si stanno verificando eventuali problemi
della Capillary Network
R3 In elaborazione – in attesa di intervento sul noise logger
È stata inviata la richiesta di manutenzione ad un operatore
dell’azienda fornitrice della sensoristica
R4 In elaborazione – noise logger
La manutenzione è in fase di elaborazione; si stanno verificando eventuali problemi
del dispositivo
R5 Chiuso La manutenzione è stata terminata
Tabella 3.10 – Ciclo di vita di un ticket in presenza di errore di rete
Caso d’uso di riferimento: UC7.
Prerequisiti: Dispositivo dell’utente connesso ad internet, l’utente ha effettuato la
visualizzazione della mappa, un noise logger presenta un errore di rete.
Attori coinvolti: Operatore utility, Mobile app, Server TLI, Server di elaborazione dati,
Operatore TLI, Operatore azienda fornitrice della sensoristica.
3.3.3.7.1 Apertura ticket
In questa fase viene creato un ticket successivo alla richiesta di manutenzione da parte dell’utente.
Attori coinvolti: Operatore Utility, Mobile app, Server TLI.
Davide Pellegrino [103/146]
Input:
Identificativo del noise logger che necessita di manutenzione.
Output:
Notifica di avvenuta apertura del ticket.
Elaborazioni:
Invia al server TLI la richiesta di manutenzione specificando il noise logger che presenta un errore di rete;
Una volta ricevuta la conferma dal server dell’apertura del ticket, notifica all’utente l’esito dell’operazione. In caso si presenti un errore interno al sistema l’utente viene avvertito del problema.
Server TLI
Input:
Noise logger che presenta un errore di rete.
Output:
Notifica riguardo l’esito dell’operazione.
Elaborazioni:
Riceve dalla mobile app la richiesta di intervento per uno specifico noise logger;
Elabora la richiesta inserendo nel database un nuovo ticket associato all’utility (ID R1);
Notifica all’applicazione l’avvenuta apertura del ticket ed invia a tutti gli utenti appartenenti all’utility registrati al servizio TI-LeD una email con l’identificativo della richiesta. In caso di errori del sistema viene avvertito l’utente con un messaggio visivo.
3.3.3.7.2 Elaborazione ticket
La seguente macrofase può essere a sua volta scomposta in diverse sottofasi. Questa scelta è dovuta al fatto che, come spiegato in precedenza, l’errore di rete può essere causato sia da un problema della Capillary Network sia da un problema del dispositivo. Avremo quindi una prima sottofase di elaborazione del ticket da parte dell’operatore TLI, una seconda di controllo che il problema sia stato risolto ed infine una terza nella quale si procederà ad una nuova elaborazione del ticket da parte di un operatore dell’azienda fornitrice della sensoristica.
Come è facile intuire non sempre tutte e tre le precedenti sottofasi verranno eseguite; ciò dipenderà naturalmente dal tipo di problema.
Elaborazione Ticket – Capillary Network
Davide Pellegrino [104/146] provvederà alla riparazione del guasto (se esiste).
Attori coinvolti: Server TLI, Operatore TLI.
Server TLI
Input:
Notifica di accettazione del ticket.
Output:
Notifica all’utente, mediante email, dello stato della manutenzione.
Elaborazioni:
Il Server TLI, una volta ricevuta una richiesta di manutenzione per un errore di rete, identifica sotto quale porzione di Capillary Network è presente il noise logger ed invia la richiesta ad un operatore specializzato TLI;
Rimane in attesa che l’operatore TLI prenda in carico l’intervento sulla rete, aggiorna il database relativamente lo stato del ticket (ID R2) ed infine invia una email a tutti gli utenti dell’utility registrati al servizio TI-LeD avvisando degli aggiornamenti.
Verifica connettività noise logger
Nella seguente fase, successiva all’intervento dell’operatore TLI, viene controllato se la connettività con il noise logger che presentava problemi è stata ripristinata o meno.
Se il problema è stato risolto si passa alla fase di chiusura del ticket, altrimenti viene inviata una email all’utente specificando lo stato attuale della manutenzione.
Attori coinvolti: Operatore TLI, Server TLI.
Server TLI
Input:
Notifica da parte dell’operatore TLI.
Output:
Email all’utente, solo in caso di presenza dell’errore di rete dopo la manutenzione della Capillary network.
Elaborazioni:
Il server TLI rimane in attesa della notifica dell’operatore TLI di fine intervento;
Una volta ricevuta, effettua un controllo per verificare se il guasto è stato risolto o meno (questa verifica si può effettuare o inviando un comando al noise logger in questione e vedere se questo risponde correttamente oppure aspettando una nuova rilevazione in un tempo valido);
Se il controllo ha esito positivo si passa direttamente alla fase di chiusura del ticket esposta in seguito;
Davide Pellegrino [105/146]
Se l’esito è negativo, viene aggiornato il ticket nel database in maniera tale da tenere traccia dello stato della manutenzione (ID R3) ed infine inviata una email a tutti gli utenti dell’utility iscritti al servizio per notificare i progressi della manutenzione.
Elaborazione ticket – noise logger
Questa fase viene eseguita solamente quando la prima parte della manutenzione, cioè quella relativa alla Capillary Network, non ha sortito alcun effetto sulla risoluzione del problema di rete.
La richiesta di manutenzione verrà perciò inoltrata al Server di elaborazione dati che si occuperà di selezionare un operatore dell’azienda fornitrice della sensoristica per effettuere la riparazione del dispositivo.
Attori coinvolti: Server TLI, Server di elaborazione dati, Operatore azienda fornitrice della
sensoristica.
Server TLI
Output:
Notifica all’utente, mediante email, dell’elaborazione della richiesta di manutenzione.
Elaborazioni:
Il Server TLI invia la richiesta di manutenzione al Server di elaborazione dati e rimane in attesa di una notifica che attesti la presa in consegna della stessa da parte di un operatore;
Una volta ricevuta, aggiorna la voce nel database relativa al ticket (ID R4) ed invia una email a tutti gli utenti dell’utility registrati al servizio TI-LeD per notificare l’aggiornamento dello stato della manutenzione.
Server di elaborazione dati
Input:
Informazioni riguardanti la manutenzione da effettuare. Nello specifico saranno presenti:
o ID del noise logger;
o Dettagli sul tipo di intervento.
Output:
Notifica dell’accettazione, da parte di un operatore, della richiesta di manutenzione.
Elaborazioni:
Il Server di elaborazione dati riceve dal Server TLI i dettagli riguardo il noise logger ed il tipo di intervento;
Davide Pellegrino [106/146]
Mediante un sistema interno dell’azienda fornitrice della sensoristica, seleziona un operatore specializzato e gli invia la richiesta di manutenzione;
Rimane in attesa che l’operatore accetti il ticket; una volta che ciò si verifica invia la notifica al Server TLI.
3.3.3.7.3 Chiusura ticket
In questa ultima fase, in seguito alla riparazione del guasto, viene chiuso il ticket e viene avvisato l’utente della terminazione della manutenzione.
La chiusura del ticket può avvenire o a seguito del primo intervento sulla Capillary
Network e del controllo della connettività (Paragrafo 0) oppure a seguito del secondo
intervento di riparazione del noise logger (Paragrafo 0). Ne consegue che in questa fase non sempre tutti gli attori sotto elencati entreranno in gioco.
Attori coinvolti: Operatore azienda fornitrice della sensoristica, Mobile app, Server TLI,
Server di elaborazione dati.
Server di elaborazione dati
Input:
Notifica da parte dell’operatore di fine intervento.
Output:
Notifica di avvenuta manutenzione.
Elaborazioni:
Il Server di elaborazione dati rimane in attesa che l’operatore dell’azienda fornitrice della sensoristica termini la manutenzione del dispositivo;
Una volta ricevuta la notifica, invia l’esito dell’operazione al server TLI.
Server TLI
Input:
Notifica di manutenzione ultimata.
Output:
Notifica dello stato dell’operazione di intervento.
Elaborazioni:
Il Server TLI rimane in attesa che l’intervento di manutenzione venga concluso; questo può avvenire o dopo la verifica della connessione, una volta ultimata la manutenzione della Capillary Network, oppure in seguito alla notifica di conclusione dei lavori di riparazione sul dispositivo da parte del Server di elaborazione dati.
Davide Pellegrino [107/146]
Una volta attestata la conclusione dei lavori, aggiorna nel database il ticket relativo alla richiesta di manutenzione (ID R5), invia una email a tutti gli utenti dell’utility registrati al servizio TI-LeD per informare della chiusura del ticket ed infine invia la notifica della fine dei lavori alla mobile app.
Mobile app
Input:
Notifica di avvenuta manutenzione.
Output:
Visualizzazione di un messaggio all’utente della chiusura del ticket.
Elaborazioni:
L’applicazione rimane in attesa di comunicazioni da parte del Server TLI (polling);
Una volta ricevuta la notifica della fine dei lavori di manutenzione per un determinato noise logger, mostra all’utente un messaggio relativo al ticket.
Davide Pellegrino [108/146] Figura 3.36 – Diagramma di Richiesta di manutenzione noise logger – Errore rete
Davide Pellegrino [109/146]