Esempio Ragionato di analisi-progetto-sviluppo. Casello autostradale

Transcript

1 Casello Autostradale 1 Esempio Ragionato di analisi-progetto-sviluppo Casello autostradale Deriva dal compito del 28/6/2004 Ultima revisione Luglio 2007 Lo scopo di questo documento è illustrare il processo di analisi-progettazione-sviluppo in riferimento ad un caso applicativo in cui è dominante l aspetto dello stato degli oggetti. Il caso applicativo si presta bene a illustrare l impiego dei thread di java. Sarò grato a chi vorrà segnalarmi errori presenti nel testo e nel programma. In particolare sarò grato a chi apporterà e mi segnalerà miglioramenti al programma. bucci@dsi.unifi.it

2 INDICE 2 Indice 1 Il problema 3 2 Considerazioni sul dominio applicativo Un aspetto strutturale Casi d uso 5 4 Il modello di dominio Modellazione del comportamento con le macchine a stati Realizzazione del sistema a controllo di programma Il casello Le porte La porta di uscita Il lettore di biglietto Il driver del lettore di biglietto Porta di uscita e driver del lettore di biglietto Dove sta il parallelismo? Il programma allegato Premessa: Processi concorrenti, thread e altro Sincronizzazione tra processi Uso di soli semafori binari per la sincronizzazione Difficoltà nell uso dei semafori I thread di Java Sincronizzazione Le operazioni wait e notify di Java Progetto con uso dei thread e simulazione visuale dei dispositivi Rappresentazione visuale dei dispositivi Porta di ingresso Porta di uscita Configurazione La simulazione grafica Progettazione di dettaglio con i thread Casello Porte e driver Driver e dispositivi Il programma allegato Appendice - Esempio di uso dei semafori (binari) Porte e driver Semafori Il programma allegato

3 1 IL PROBLEMA 3 1 Il problema Si vuole progettare e sviluppare il software di gestione e controllo di un casello autostradale ad alta automazione. Il casello si compone di porte di ingresso e porte di uscita. Le porte hanno un semaforo che è verde se sono attive e rosso se non attive. Quando non sono attive non consentono il passaggio (non rispondono a richiesta di biglietto di ingresso o di pagamento). L attivazione/disattivazione delle porte è fatta da un operatore (che interagisce col programma di controllo). Un porta di ingresso attiva ripete ciclicamente queste operazioni: fornisce un biglietto quando viene premuto il pulsante relativo; apre la sbarra quando il biglietto viene estratto dal distributore; chiude la sbarra quando il sensore di passaggio indica che la macchina è passata (il sensore di passaggio ha anche la funzione di servire al conteggio dei mezzi che entrano). Un porta di uscita attiva ripete ciclicamente queste operazioni: accetta e legge un biglietto, calcolando l importo dovuto; presenta l indicazione dell importo e attende il pagamento automatico; quando il danaro è stato introdotto apre la sbarra e fornisce l eventuale resto. Diversamente da come funzionano le porte automatiche, si assuma che, se il viaggiatore non preleva il resto o ne lascia una parte, l ammontare corrispondente venga incamerato dalla porta. Si richiede che il sistema tenga conto delle rimanenze e tenga traccia degli incassi (quelli dovuti) e delle rimanenze totali. chiude la sbarra quando il sensore di passaggio indica che la macchina è passata. Vincoli di progetto Il software di gestione delle porte deve corrispondere al prodotto finale che, ipoteticamente, verrebbe consegnato al committente. I dispositivi periferici (pulsanti, lettori biglietto, ecc.) devono essere simulati. I componenti software (driver) che gestiscono i dispositivi devono presentare una ben definita interfaccia verso le porte, in modo che essi possano essere sostituiti all occorrenza, senza richiedere interventi sulla logica delle porte. Inoltre essi devono richiedere un interfaccia verso i dispositivi simulati tale da poter essere impiegati (con il minimo intervento) anche con dispositivi reali. Il software deve essere scritto in Java. Si sviluppi una versione di iniziale a controllo di programma, cioè senza fare ricorso ai thread (o ad altri costrutti che realizzino il parallelismo). Successivamente si sviluppino una o più versioni usando i thread di Java.

4 2 CONSIDERAZIONI SUL DOMINIO APPLICATIVO 4 2 Considerazioni sul dominio applicativo Occorre rilevare che questo esempio appartiene al campo applicativo in cui l aspetto fondamentale è il controllo. Rispetto al modo delle applicazioni Enterprise dove l aspetto fondamentale è costituito dai dati, le differenze sono così riassumibili: Numero limitato di oggetti. Oggetti per i quali è irrilevante l aspetto del controllo ovvero del loro stato. In altre parole gli oggetti applicativi non sono Data Objects, ma piuttosto dei Control (o Service) Objects. Essi stessi rappresentano la logica applicativa. Non c è il problema della persistenza, nel senso che le entità di controllo svolgono la loro funzione nel tempo. Problemi di persistenza potrebbero esserci in un eventuale sistema gestionale del casello (che è da considerare come un eventuale attore esterno). Essendo rilevante l aspetto comportamentale, nella modellazione è naturale fare impiego esteso delle macchine a stati. 2.1 Un aspetto strutturale Si può immaginare che la catena di controllo sia fatta di 4 livelli. A livello più alto c è il controllore del casello; al livello sottostante i controllori di porta; sotto ai controllori di porta stanno i controllori dei dispositivi; infine, a livello più basso stanno i periferici. La corrispondente gerarchia è illustrata in Figura 1. In figura mostra solo 3 livelli, in quanto non è stato rappresentato il livello più alto (il controllore del casello). Apparentemente la parte a destra mostra quattro livelli; il motivo dell ulteriore suddivisione è illustrato nel seguito. La Figura 1 serve a chiarire il concetto di simulazione e a precisare il concetto di reimpiego dei componenti. La parte di sinistra si riferisce a come sarebbe sviluppato il sistema nel caso reale; quella al centro mostra la soluzione con i dispositivi fisici simulati (cioè quella oggetto del nostro interesse); la parte di destra mostra come i componenti sviluppati nel presente lavoro possono essere utilizzati nel caso reale. Figura 1: Gerarchia tra componenti e dipendenze. Tre differenti realizzazioni. Al centro quella completamente simulata (il nostro caso); a sinistra il caso reale realizzato in modo naturale, con i driver che driver gestiscono direttamente i dispositivi; a destra la soluzione che impiega i driver del caso simulato adattandoli alle interfacce dei dispositivi reali. Il livello più basso della gerarchia è il livello fisico (reale o simulato); il livello più alto è il controllore della porta (sopra questo c è il controllore del casello non mostrato in figura); il livello intermedio è quello del driver del dispositivo.

5 3 CASI D USO 5 Nei tre casi di Figura 1 le interfacce (IDriver) tra le porte e i driver non cambiano. Dunque, il componente Porta passa invariato da caso a caso. In altre parole possono essere usati gli stessi componenti Porta nei tre distinti casi. Nel caso reale (a sinistra in Figura 1) il driver di un dispositivo deve necessariamente riferirsi all interfaccia che il dispositivo presenta (IDispReale), definita dal suo costruttore, della quale il programmatore deve prendere atto. Nel nostro caso (al centro in Figura 1), il driver deve essere sviluppato in riferimento al dispositivo simulato. Se questo venisse simulato in modo da riprodurne il comportamento in ogni dettaglio, il driver sarebbe lo stesso del caso reale. Naturalmente non ha molto senso, almeno ai fini del nostro esempio, simulare esattamente il dispositivo: 1 è molto più conveniente definire un comportamento funzionalmente ragionevole, attraverso l interfaccia IDispSimulato. Per esempio: si può stabilire che dispositivo logico (l oggetto della classe DrivLettoreBiglietto) ottenga la lettura del biglietto chiamando il metodo leggi() del dispositivo simulato (l oggetto della classe LettoreBiglietto che simula il lettore fisico). Come illustrato nella parte a destra di Figura 1, il driver usato per il dispositivo simulato può comunque essere impiegato senza variazioni nel caso di periferici reali. A tale scopo si tratta di introdurre uno strato di adattamento tra il driver del dispositivo simulato e l effettivo dispositivi fisico. In altra parole si tratta di adattare IDispReale a IDispSimulato. Con riferimento all esempio, quando si dovesse impiegare DrivLettoreBiglietto nel caso reale, il metodo leggi() dovrà essere trasformato dall adatatore nella sequenza di effettive operazioni che portano alla lettura sul dispositivo fisico reale. La realizzazione di questo strato richiederebbe l impiego della Native Interface (JNI). I precedenti ragionamenti evidenziano quanto sia rilevante, ai fini del riuso del codice, la definizione di una appropriata interfaccia tra i livelli. Nel resto di questo documento si fa esclusivamente riferimento alla schematizzazione al centro di di Figura 1, corrispondente all enunciato del nostro esercizio. Inoltre, si stabilisce la convenzione che i dispositivi fisici simulati abbiano lo stesso nome del dispositivo (ad esempio, LettoreBiglietto), mentre i relativi driver vengono descritti con il prefisso Driv al nome del dispositivo (ad esempio, DrivLettoreBiglietto). 3 Casi d uso Da come è posto il problema ci sono tre soli casi d uso, come schematizzato in Figura 2. Figura 2: I casi d uso Gli attori sono: (a) l operatore, che interviene solo per attivare/disattivare le porte e (b) il viaggiatore con il suo mezzo, coinvolto nell attraversamento delle porte. Se si considerasse il fatto che il casello può trasmettere gli incassi a una sede centrale, o comunicare con le banche per le transazioni che coinvolgono carte di credito, ecc., il numero degli attori crescerebbe come pure il numero di casi d uso. 1 Si tenga anche conto che stiamo programmando in Java.

6 4 IL MODELLO DI DOMINIO 6 4 Il modello di dominio in base alle specifiche e a quanto detto al paragrafo 2.1, si ottiene il diagramma delle classi di Figura 3. Come accennato sopra, la parola Dispositivo rappresenta Dispositivo simulato. Figura 3: Il diagramma delle classi nella versione che corrisponde all applicazione dei concetti dell OO (polimorfismo, aggregazione, delega, ecc.). Il diagramma di Figura 3 è stato tracciato seguendo i criteri della progettazione OO, cercando di definire una struttura che consenta di sfruttare il polimorfismo, l aggregazione degli oggetti e la loro composizione al tempo di esecuzione. Il modello di Figura 3 può essere esteso facendo derivare i periferici da classi più ampie. Per esempio si potrebbe derivare il dispositivo Sbarra dalla classe astratta Attuatore, il PulsanteBiglietto dalla classe astratta Sensore, oppure dalla classe astratta Pulsante a sua volta derivata dalla classe astratta Sensore. A loro volta Sensore e Attuatore potrebbero essere derivati dalla classe astratta Dispositivo. I driver potrebbero essere derivati da classi più generali. La Figura 4 mostra questo genere di estensioni. Si noti che sul lato attuatori, si è tracciata una gerarchia contenuta, mentre sul lato sensori sono stati mostrati più livelli di dettaglio. Figura 4: Estensioni al modello tramite uso dell ereditarietà). La domanda che l analista si deve porre è questa: vale la pena di costruire una gerarchia dettagliata come in Figura 4?. La risposta è ovvia: vale la pena quando la gerarchia e la specializzazione servono non solo a concettualizzare meglio il problema, ma anche a derivarne dei vantaggi in termini realizzativi; ovvero quando gli aspetti a comune possono effettivamente essere fattorizzati e messi a profitto nella scrittura del programma.

7 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA 7 Nel caso concreto gli aspetti fattorizzabili con l ereditarietà sono pochi. Riferendosi alle porte, si può immaginare che Porta definisca il metodo getstato() comune sia a PortaIngresso che a PortaUscita. Inoltre ambedue le porte hanno il driver della (relativa) sbarra e quello del (relativo) sensore di passaggio. Ma se per esempio si considera l emissione e la lettura del biglietto, sia i dispositivi che i relativi driver hanno praticamente niente in comune. Per questo motivo è meglio riferirsi alla Figura 3, come faremo nel seguito. 4.1 Modellazione del comportamento con le macchine a stati E del tutto evidente che nel nostro sistema l aspetto rilevante è quello del controllo. Possiamo immaginare che, a regime, ogni oggetto derivante dal modello di Figura 3 esegua ripetitivamente un ciclo nel corso del quale si sincronizza o scambia dati con altri oggetti. Il comportamento dei singoli oggetti può essere descritto attraverso le macchine a stati di UML. La modellazione del comportamento di un oggetto attraverso macchine a stati è in linea di principio indipendente dagli aspetti implementativi; in particolar modo è indipendente dalla modalità secondo cui viene realizzata la concorrenza delle attività (simulandola a controllo di programma, usando i thread, ecc.). Tuttavia questa modalità influisce sul modo in cui le varie macchine coordinano il loro comportamento; inoltre, anche a livello di modellazione, il fatto che due attività concorrenti si sincronizzino attraverso l emissione/attesa di segnali o controllando variabili di stato, può comportare delle differenze. Nella parte seguente si fa esplicito riferimento all implementazione delle macchine a stati a controllo di programma. 5 Realizzazione del sistema a controllo di programma Occorre simulare il meccanismo di sospensione/attivazione tipico dei sistemi multitasking. Si possono seguire questi criteri: Ogni oggetto viene modellato con una macchina a stati. Ogni oggetto presenta uno o più metodi di interfaccia la cui chiamata può determinare un cambiamento di stato. I metodi di interfaccia, in base allo stato in cui si trova la macchina e in base agli eventuali ingressi o eventi osservati, calcolano lo stato futuro e effettuano le azioni previste dal diagramma di stato. Di norma ogni oggetto prevede il metodo getstato() che restituisce lo stato dell oggetto stesso, in modo che l oggetto (la macchina) che la controlla possa prendere decisioni influenzate dallo stato della macchina in questione. Il metodo getstato() può limitarsi a restituire lo stato della macchina, ma può anche essere usato per far campionare gli ingressi e decidere se deve essere svolta qualche operazione e/o attuarsi un cambiamento di stato,. Quando una macchina non prevede di per sé nessun metodo avente l effetto di farle cambiare stato, viene introdotto il metodo tick(), avente lo scopo di far avanzare di un tick il campionamento degli ingressi della macchina stessa Il casello Con le precedenti assunzioni l oggetto casello, che rappresenta il processo di controllo del casello stesso, esegue perennemente un ciclo nel corso del quale esamina lo stato delle porte da esso controllate (per semplicità due: una di entrata e una di uscita) ed effettua le azioni conseguenti, come esemplificato nel seguente tratto di codice. while (true) { switch(pi.getstato(){ //pi è una porta di ingresso case s0: // esecuzioni azioni relative al fatto che pi sia in stato s0 break; case sx: // esecuzioni azioni relative al fatto che pi sia in stato sx break; 2 Si può assimilare il tick al clock delle classiche macchine a stati (automi a stati finiti) sincrone.

8 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA 8 ecc. switch(pu.getstato(){ //pu è una porta di uscita case s0: // esecuzioni azioni relative al fatto che pu sia in stato s0 ecc. Per semplicità, nello sviluppare il programma, supporremo che il casello non sia interessato ai dati o all operatività delle porte, ma che abbia solo il compito di dare i tick alle medesime. In altre parole, il comportamento del casello è così schematizzabile: while (true) { pi.tick(); pu.tick(); // tick a PI // tick a PU Il tratto Java seguente mostra lo schema della porta di uscita in riferimento alla sollecitazione tramite il metodo tick(). public class PortaUscita extends Porta{ //attributi tra cui s: stato della porta public PortaUscita(){ //costruttore public void tick(){ switch (s){ case LETTURABIGLIETTO: // azioni relative ed eventuale cambiamento di stato break; case LETTURAMONETE: // azioni relative ed eventuale cambiamento di stato break; // ecc Le porte In base alla specifica, il diagramma di stato aggregato di una porta può essere schematizzato come in Figura 5. Nel seguito, siccome lo stato Disabilitata e le transizioni da/per il medesimo sono di poca rilevanza, per semplicità espositiva si trascura il caso d uso Abilitazione/disabilitazione, tenendo conto soltanto dello stato Abilitata. Figura 5: Diagramma di stato di una porta nella forma più aggregata. [A rigore, il modello della porta software dovrebbe prevedere anche uno stato iniziale e uno finale.]

9 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA La porta di uscita Il diagramma di stato della porta di uscita è in Figura 6; esso rappresenta l espansione dello stato Abilitata di Figura 5. Figura 6: Diagramma di stato della porta di uscita. Versione iniziale. Il diagramma di Figura 6 è stato tracciato tenendo conto dei seguenti punti. Lo stato LetturaBiglietto corrisponde a quello in cui la porta attende che si presenti una vettura. Ai fini della logica della porta questo stato equivale ad una sorta di stato di Idle, ovvero allo stato in cui la macchina attende il verificarsi dell evento che dà inizio ad una sequenza di passaggio di un mezzo. Il diagramma di Figura 6 mostra che la porta di uscita esce dallo stato LetturaBiglietto quando si verifica la condizione Biglietto Letto, ovvero quando lo stato del driver del lettore indica che un biglietto è stato letto. Nello stato LetturaMonete la porta di uscita, tramite il lettore di monete, legge le monete (eventualmente mostrando quanto deve essere introdotto). Delta è la differenza tra quanto introdotto e quanto dovuto: Finché delta < 0 la macchina continua a leggere. Con delta = 0 la macchina esce da questo stato senza erogare resto. Con delta > 0 la macchina esce da questo stato ma deve erogare il resto. Se non c è da erogare resto la porta di uscita va nello stato AperturaSbarra-ControlloPassaggio dove resta fino a che il sensore di passaggio non indica che il veicolo è transitato. Se c è da erogare il resto, la macchina si porta nello stato AperturaSbarra-Erogazione-ControlloPassaggio, nel corso del quale eroga il resto ed apre la sbarra. Si esce da questo stato, come nel caso precedente, quando il mezzo è transitato, ma, per le ipotesi fatte circa la questione dei resti e delle rimanenze, si rende necessario che prima di passare (o nel passare a seconda dell implementazione) allo stato ChiusuraSbarra venga letto quanto il guidatore ha lasciato e tenerne conto nel complesso delle rimanenze. Si noti che nello stato AperturaSbarra-Erogazione-ControlloPassaggio sono operativi questi dispositivi: l erogatore, la sbarra e il sensore di passagio (quest ultimo indica quando il mezzo è transitato).

10 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA 10 Nello stato ChiusuraSbarra la porta aspetta semplicemente che la sbarra sia chiusa prima di tornare allo stato LetturaBiglietto. Il diagramma di stato della porta di uscita viene rifinito con le aggiunte di Figura 7. Figura 7: Aggiunta delle azioni al diagramma di stato di Figura 6. Sono stati eliminati gli archi corrispondenti all ingresso e all uscita dallo stato aggregato Il lettore di biglietto Un lettore di biglietto reale (fisico) è ragionevolmente schematizzabile come in Figura 8. Con riferimento alla schematizzazione di Figura 8, un modo per gestire il lettore fisico consiste nel comandarlo e interrogarlo, leggendone lo stato, in modo da poter prelevare il dato letto quando disponibile. Alternativamente si può stabilire che, il lettore fisico avvisi direttamente il lettore quando un dato è disponibile. In un sistema reale (non simulato) ciò si ottiene attraverso la generazione di un interruzione raccolta dal lettore. Il nostro oggetto LettoreBiglietto deve simulare il dispositivo fisico di Figura 8 (si faccia riferimento alle Figure 1 e 3). Per rendere realistica la simulazione si può stabilire che LettoreBiglietto: a) presenti il metodo enable(), con il quale viene abilitato a riconoscere l inserimento di un biglietto (l inserimento del biglietto viene simulato battendo su console il carattere $ ); 3 b) presenti il metodo leggi(), che restituisce il nome della città di provenienza letto sul biglietto (la lettura della provenienza viene simulata battendo una stringa su console); 3 Si è stabilito di simulare con $ l introduzione del biglietto. Spetta al driver del lettore verificare che sia stato effettivamente battuto il carattere $, assumendo che se non viene battuto $ ciò vada interpretato come un inserimento non corretto (come può capitare nella realtà).

11 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA 11 Figura 8: Schematizzazione del lettore fisico di biglietto. Il lettore ha una porta per i comandi una per la lettura dello stato e una per la lettura del dato (la provenienza letta sul bilietto). Il lettore può essere abilitato a generare interruzioni al verificarsi di un dato evento; ad esempio, per segnalare che è disponibile la lettura di un biglietto. c) funzioni come il Subject del design pattern Observer e che il driver funzioni come l Observer. In tal modo l avvenuto inserimento del biglietto e/o della lettura vengono segnalati attraverso un meccanismo che modella quello dell interruzione. Dalle precedenti considerazioni deriva il seguente testo Java. public class LettoreBiglietto extends Observable { InputStreamReader BufferedReader String isr; keyb; inl; public LettoreBiglietto(){ isr = new InputStreamReader(System.in); keyb = new BufferedReader(isr); public void enable() throws Exception{ System.out.println("====================== \n Inserire Biglietto (battere $) "); inl = keyb.readline(); this.setchanged(); notifyobservers(inl); public void leggi() throws Exception{ System.out.println("Da dove provieni?"); inl = keyb.readline(); this.setchanged(); notifyobservers(inl); //avvisa il DrivLettoreBiglietto (se si è registrato!) //che hanno inserito(?) il biglietto //avvisa il DrivLettoreBiglietto che è stata //letta la provenienza È importante rilevare che LettoreBiglietto avvisa il suo osservatore (il driver DrivLettoreBiglietto) dell occorrenza di un evento, non di quale specifico evento (introduzione biglietto/lettura biglietto) si sia verificato. Spetta al driver decidere in base alla sua conoscenza dello stato in cui si trova il lettore (cioè in base al fatto che abbia chiamato enalbe() o leggi(). Lo stato del driver deve quindi riflettere quello del dispositivo Il driver del lettore di biglietto Da parte della porta di uscita il driver del lettore di biglietto può essere riguardato come una macchina il cui diagramma di stato è in Figura 9. Per la porta hanno rilevanza solo due stati:

12 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA 12 Lo stato DatoDisponibile in cui il driver del lettore ha disponibile il dato (la provenienza) letto dal lettore sul biglietto. Lo stato StatoAggregato che corrisponde a tutti gli altri possibili stati driver del lettore. Ovviamente se, in aggiunta al dato letto (dal biglietto), si volesse tenere conto di ulteriori aspetti del comportamento del driver (e quindi del lettore), gli altri stati (per esempio lettore inceppato) andrebbero esplicitati. La transizione dallo stato aggregato allo stato di DatoDisponibile viene causata dal completamento della lettura da parte del lettore fisico simulato, mentre la lettura del dato (di provenienza) da parte della porta determina il ritorno allo stato aggregato. Figura 9: Diagramma di stato equivalente del driver del lettore di biglietto visto dalla porta di uscita. Possiamo dunque stabilire che l interfaccia del driver del lettore di biglietto presenta due metodi getstato() e getprovenienza(). Il primo restituisce lo stato del lettore, il secondo restituisce il dato letto (la provenienza). L esecuzione di questo metodo fa compiere la transizione letturadato di Figura 9. Nell implementare il driver del lettore di biglietto conviene dividere lo StatoAggregato in due stati: Idle e LetturaBiglietto. Il primo corrisponde alla situazione in cui nessuno è alla porta; il secondo alla situazione in cui un biglietto è stato introdotto e il lettore sta leggendo (il modo in cui queste due condizioni vengono simulate è stato spiegato al Paragrafo 5.1.1). In base a ciò, il diagramma di stato del driver del lettore del biglietto diventa quello di Figura 10. Figura 10: Diagramma di stato dettagliato del driver del lettore di biglietto.

13 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA 13 Con i precedenti ragionamenti e tenuto conto che il driver viene realizzato come Observer del lettore, il driver assume la forma seguente (riportata senza alterazioni rispetto al testo effettivo). public class DrivLettoreBiglietto implements Observer{ private int s; private String provenienza; private LettoreBiglietto dispositivo; public DrivLettoreBiglietto(){ //costruttore del driver s = Stato.IDLE; // inizialmente in Idle dispositivo = new LettoreBiglietto(); dispositivo.addobserver(this); //Il driver si registra sul dispositivo public void enable(){ //abilitazione dispositivo try {dispositivo.enable(); catch (Exception e){ //il catch voluto da Java System.out.println("Driver LettoreBiglietto: Il lettore fisico fa le bizze!"); System.out.println(e.getMessage()); public int getstato(){ return s; public String getprovenienza(){ //lettura della provenienza if (s!= Stato.DATODISPONIBILE){ //situazione incongruente!!!! System.out.println("Driver Lettore Di Biglietto: Non posso leggere la" + "provenienza se non è disponibile"); s = Stato.IDLE; return provenienza; public void update(observable o, Object arg) { switch (s){ case Stato.IDLE: String x = (String)arg; if (x.equalsignorecase("$") ) { // ha infilato il biglietto s = Stato.LETTURABIGLIETTO; try {dispositivo.leggi(); catch (Exception e){ System.out.println("Driver Lettore Biglietto: Il lettore fisico non legge"); else { //ha letto qualcosa diverso da "$" try {dispositivo.enable(); //riprova a leggere "$" catch (Exception e){ System.out.println("Driver Lettore Biglietto: Il lettore fisico fa le bizze!"); System.out.println(e.getMessage()); break; case Stato.LETTURABIGLIETTO: provenienza = (String) arg; if (provenienza.length()>0){ //deve leggere qualcosa s = Stato.DATODISPONIBILE; else { //prendiamolo come inserimento errato System.out.println(" Inserire bene il biglietto"); try {dispositivo.leggi(); catch (Exception e){ System.out.println("Driver Lettore Biglietto: Il lettore fisico non legge"); break; case Stato.DATODISPONIBILE: break; public class Stato{ //definisce simbolicamente i possibili stati public static final int IDLE = 0;

14 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA 14 public static final int LETTURABIGLIETTO = 1; public static final int DATODISPONIBILE = 2; Porta di uscita e driver del lettore di biglietto Vale la pena di soffermarsi brevemente su come la porta di uscita interagisce col driver del lettore. A tale scopo, riferendosi per esempio al diagramma di stato di Figura 7, l algoritmo della porta per quanto si riferisce al controllo del lettore di biglietto è schematizzabile nel modo che segue. I nomi usati hanno significato evidente. Si consiglia comunque di fare riferimento al programma allegato. public void tick(){ switch (s){ //s è la variabile di stato della porta di uscita (PU) case StatoPU.LETTURABIGLIETTO: if (dlettb.getstato()==drivlettorebiglietto.stato.datodisponibile){ importodovuto= calcolaimporto(dlettb.getprovenienza()); System.out.println(" Importo dovuto: " + importodovuto); dlettm.open(); //comando al (driver del) lettore di monete s=statopu.letturamonete; importoinserito = 0; ; break; // altri rami case relativi ad altri valori di s case StatoPU.CHIUSURASBARRA: if(dsbarra.getstato()== DrivSbarra.S.CHIUSA) { System.out.println(" Questo pedaggio: " + importodovuto + " Importo inserito: " + importoinserito+ " Resto: " + delta + " Rimanenza: " + rimanenza + "\n Incassi Totali: " + incassi + " Rimanenza totale: " + totalerimanenze + "\n" ); s = StatoPU.LETTURABIGLIETTO; dlettb.enable(); break; Dove sta il parallelismo? Con riferimento al diagramma di stato della porta (Figura 7), risulta evidente che la lettura del biglietto è una attività che si esplica in parallelo con la sola attività della porta dedicata al controllo dell avanzamento dell operazione di lettura. La lettura delle monete si attua in una fase successiva (quindi non in parallelo con la lettura del biglietto) e sempre con modalità analoga alla precedente (cioè in parallelo solo con l attività delle parta che controlla l avanzamento della lettura delle monete). Dunque, se ci si limita a queste due sole operazioni e si prende in considerazione la sola porta, il parallelismo non è di per sé necessario e le due operazioni potrebbero essere effettuate in sequenza, sotto il diretto controllo della porta. Tuttavia il parallelismo tra porte resta, anche se una singola porta opera in maniera strettamente sequenziale. Si noti che negli stati AperturaSbarra-ControlloPassaggio e AperturaSbarra-Erogazione-ControlloPassaggio può esserci un effettivo parallelismo tra le attività. In particolare, nel caso di AperturaSbarra-Erogazione- ControlloPassaggio, la sbarra può essere in fase di apertura mentre viene erogato il resto e mentre il sensore di passaggi controlla se il mezzo sta transitando.

15 5 REALIZZAZIONE DEL SISTEMA A CONTROLLO DI PROGRAMMA Il programma allegato I file.java relativi agli altri componenti la porta di uscita si trovano nel file Casello CP.zip scaricabile. Non è stata sviluppata la porta di ingresso per lasciare al lettore la possibilità cimentarsi con la programmazione. I file contenuti in Casello CP.zip sono organizzati in più cartelle. Conviene costruire un progetto Eclipse e copiarli nella cartella scr, mantenendo la struttura attuale. Il lettore noterà che, seguendo lo schema di Figura 3, sono state previste le classi astratte Driv e Dispositivo, dalle quali sono stati rispettivamente derivati i driver e i dispositivi, anche se, specialmente per quanto riguarda i dispositivi, questa derivazione è piuttosto artificiosa e non molto significativa (peraltro, come indicato nel relativo commento, il lettore di biglietto, non è stato derivato da Dispositivo).

16 6 PREMESSA: PROCESSI CONCORRENTI, THREAD E ALTRO 16 Parte 2 In questa parte si discute una realizzazione che asseconda il parallelismo insito nell applicazione con l uso dei thread di Java. 6 Premessa: Processi concorrenti, thread e altro E stato già osservato che il nostro è un tipico problema di controllo in tempo reale. Se esso dovesse essere sviluppato concretamente la cosa più naturale sarebbe ricorrere a una realizzazione a processi concorrenti. Il coordinamento dei processi richiede l uso di qualche meccanismo di sincronizzazione. Nella parte che segue vengono telegraficamente discussi alcuni meccanismi di sincronizzazione; prima in riferimento ai metodi classici della programmazione procedurale (non OO) e successivamente in riferimento a Java. 6.1 Sincronizzazione tra processi Il modo classico consiste nell utilizzare primitive di sincronizzazione operanti su semafori e/o scambio di messaggi. Ad esempio, se P1 e P2 sono due processi, un interazione in cui P1 chiede a P2 di svolgere una data operazione può essere modellata nel modo seguente. 4 P1: while (true){ P2: while (true){ ::: ::: preparazione del messaggio Mes per P2; waitmessage(q, mess); sendmessage(q, Mes); execute(mess.command); ::: signal(mess.semrisposta); wait(sem) :::: ::: Si osservi che: I due processi eseguono un ciclo perenne, come naturalmente deve fare un processo di controllo. l operazione sendmessage(q, Mes) è una primitiva di sincronizzazione. Essa ha l effetto di trasmettere il messaggio Mes nella coda Q. L operazione non è bloccante (per chi la esegue), dunque, trasmesso il messaggio, P1 può procedere. Il messaggio Mes può essere impiegato per scambiare qualunque informazione. Ad esempio, Mes può avere almeno due componenti command e semrisposta, dove P1 scrive rispettivamente il comando da trasmettere a P2 e l identità del semaforo su cui si aspetta la risposta da P2. La preparazione del messaggio Mes per P2 può essere schematizzata come: Mes.command = comando per P2; Mes.semRisposta = sems L operazione waitmessage ha l effetto di attendere un messaggio nella coda Q. Se la coda contiene almeno un messaggio, questo viene prelevato 5 da chi esegue l operazione. Se la coda è vuota chi esegue l operazione viene bloccato in attesa dell arrivo di un messaggio e viene riattivato all arrivo del primo messaggio. Nel messaggio prelevato mess si trova il comando da eseguire e l indicazione del semaforo su cui il processo sollecitante si aspetta la risposta (ovvero l indicazione che il comando è stato eseguito). 6 Le operazioni wait e signal su un semaforo (binario) hanno rispettivamente la funzione di bloccare chi la esegue se il semaforo è rosso e di portare a verde il semaforo rosso (il semaforo è inizializzato a rosso). In altre parole, se P1 effettua wait(sem) prima che P2 abbia effettuato signal(sem), allora P1 resta bloccato in attesa che P2 effettui signal(sem), riportando sem a verde. 4 Si usa la notazione di Java, ma si suppone che la programmazione sia di tipo procedurale non a oggetti. Si faccia conto di usare il C. 5 Si assuma che prelevare un messaggio voglia dire che esso viene copiato (in mess) nella memoria provata di P2. 6 Supponiamo che la coda sia gestita in modo FCFS (First-Come-First-Served).

17 6 PREMESSA: PROCESSI CONCORRENTI, THREAD E ALTRO 17 La sincronizzazione richiede che P1 e P2 siano d accordo sulla coda Q. Per il resto Mess viene composto nella memoria privata di P1 e copiato nella memoria privata di P2. Il semaforo sem è nella memoria di P1. Questo consente a P1 di sincronizzarsi, per esempio, su differenti semafori con differenti processi. Il precedente modello permette a P1 e P2 di operare in modo asincrono, ma li mantiene sincronizzati in modo da fare un giro sempre assieme, per via della sincronizzazione su sem. Si possono rendere i due processi completamente asincroni, ad esempio eliminando il vincolo della sincronizzazione su sem. In tal caso sarebbe possibile che la coda Q crescesse per il fatto che P2 impiega più tempo a effettuare i comandi di quanto impieghi P1 a fare un giro. Ovviamente ci sono molte variazioni in tema che però non rientrano nello scopo di questo documento. Si considera solo quella del prossimo paragrafo Uso di soli semafori binari per la sincronizzazione Se P1 e P2 devono procedere accoppiati (come abbiamo supposto nel caso illustrato) e se il comando è sempre lo stesso, bastano le sole operazioni su semafori binari. Ad esempio, si possono usare due semafori sem1 e sem2; sul primo aspetta P2, sul secondo aspetta P1. P1: P2: while (true){ while (true){ ::: ::: signal(sem1); wait(sem1); ::: :::: wait(sem2) signal(sem2); ::: :::: In questo caso l accoppiamento è molto rigido: i due processi devono sapere l uno dell altro. Nel caso precedente l unico dettaglio di cui ambedue dovevano avere conoscenza era la coda Q Difficoltà nell uso dei semafori Occorre tenere conto di questi problemi: Java fornisce su tutti gli oggetti le operazioni wait() e notify(), ma come mostreremo ai prossimi paragrafi, queste non corrispondono alle wait() e signal() dei paragrafi 6.1 e Java è un linguaggio a oggetti e quindi i modelli sopra seguiti devono essere modificati nel senso che occorrerebbe definire semafori, code, buffer, ecc come oggetti e su questi le operazioni corrispondenti (presumibilmente ricorrendo al supporto di Java stesso, cioè usando wait() e notify()). In Appendice, e in particolare al Paragrafo 8.2, si discute l implementazione di un semaforo binario. Java fornisce il costrutto Thread. al Paragrafo 6.2 e seguenti. È ovvio che ci si debba adeguare alle sue caratteristiche. Di esse si parla 6.2 I thread di Java In Java ci sono i Thread. Un thread è definito come un processo light-weight, ovvero come un entità che somiglia a un processo, senza averne tutte le caratteristiche. Normalmente un thread è inteso come una attività parallela che viene avviata in un dato momento e che si svolge in parallelo con l attività principale responsabile della sua attivazione. Usualmente, conclusi i sui compiti, il thread ha termine (ricongiungendosi con l attività principale). In Java ci sono due modi per realizzare i thread consistenti nel: (1) dichiarare una classe estensione di Thread; (2) dichiarare che una classe implementa l interfaccia Runnable. Alle due modalità corrisponde una sintassi leggermente diversa, ma, in ogni caso, un thread viene attivato attraverso l esecuzione dell operazione run(). Si consideri il thread T

18 6 PREMESSA: PROCESSI CONCORRENTI, THREAD E ALTRO 18 public class T extends Thread{ // public void run(){ //fa qualcosa ; e si consideri la classe UnaClasse che presenta un metodo che avvia T, prosegue con l esecuzione delle sue attività e successivamente si si ricongiunge con T. public class UnaClasse { // public void UnMetodo(){ // T t = new T(); t.start(); // altre cose t.join(); // //istanziazione del thread t //avvio thread t (fa eseguire il metodo run() di t //ricongiungimento con T Lo schema precedente è quello classico di uso dei thread: lancio di un percorso di esecuzione parallelo che poi ha termine. Esso è schematizzato in Figura 11. La prima barra di sincronizzazione corrisponde all esecuzione di t.start(), la seconda all esecuzione di join() che fa ricongiungere il thread (quando questo ha concluso). Figura 11: Schematizzazione del meccanismo di attivazione/ricongiunzione del thread t. E importante rilevare che, a meno di non intervenire sulle priorità, l ordine di schedulazione non è definito, nel senso che l esecuzione di t.start() non implica che a t venga immediatamente allocata la CPU, ma neanche l opposto. In altre parole, l ordine di schedulazione dei thread è arbitrario Sincronizzazione La sincronizzazione tra i thread si attua attraverso il meccanismo dei monitor, ovvero dei lock. Ogni oggetto Java ha un suo monitor (anche se di esso normalmente non si fa nessun conto). Supponiamo che ci sia un oggetto Buffer, il quale presenta due metodi deposita() e preleva(), e supponiamo che due thread t1 e t2 accedano al buffer, il primo per depositare, il secondo per prelevare elementi di informazione nel/dal buffer. Poiché i due metodi modificano le variabili che consentono la gestione del buffer (puntatori, contatori, ecc.), occorre garantire che l accesso sia eseguito in modo esclusivo, nel senso che se t1 acquisisce l accesso (il lock) tramite deposita(), t2 non possa accedere al buffer tramite preleva, fino a che t1 non rilascia il lock (conclude deposita()). Senza entrare troppo nei dettagli, un modo consiste nel dichiarare i due metodi come synchronized. Ad esempio public synchronized void deposita(qualchecosa){

19 6 PREMESSA: PROCESSI CONCORRENTI, THREAD E ALTRO 19 // deposito di qualchecosa nel Buffer Il paragrafo seguente chiarisce il significato delle operazioni synchronized Le operazioni wait e notify di Java In Java, sulla classe Object e quindi su tutte le classi possibili, sono definite le due operazioni wait() e notify(). Riportiamo qui il loro significato riprendendolo direttamente dalla documentazioni delle API Java. public final void wait(long timeout) throws InterruptedException Causes current thread to wait until either another thread invokes the notify() method for this object... The current thread must own this object s monitor.... public final void notify() Wakes up a single thread that is waiting on this object s monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object s monitor by calling one of the wait methods. The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object.... Per garantire che le operazioni di wait e notify siano eseguite quando è posseduto il monitor dell oggetto conviene definire due nuove operazioni sincronizzate attendi() e segnala() eseguite in modo esclusivo. Ad esempio nel thread t1 si possono definire 7 : public synchronized void attendi(){ wait(); public synchronized void segnala(){ notify(); Avere i due metodi sincronizzati implica che l esecuzione dell uno è esclusiva dell esecuzione dell altro. Come corollario segue che se viene eseguito un wait() che blocca il thread, il lock viene rilasciato per dare modo di eseguire un eventuale notify() (la ripresa del wait() presuppone la riacquisizione del lock). Si consideri ora il seguente codice nel quale t1 fa partire il thread t2 e, apparentemente, si sincronizza con un operazione di wait rispetto al notify di t2. // thread t1 // thread t2 public void run(){ public void run(){ t2.start(); //fa qualcosa //fa qualcosa t1.segnala(); attendi(); //altro //fa qualche altra cosa public synchronized void attendi(){ 7 La definizione richiede il costrutto try-catch che evitiamo di trascrivere per rendere più leggera la lettura. A tale proposito si vedano i programmi allegati.

20 6 PREMESSA: PROCESSI CONCORRENTI, THREAD E ALTRO 20 wait(); public synchronized void segnala(){ notify(); Purtroppo la sincronizzazione che uno spererebbe di ottenere con il precedente schema ha luogo solo se t1 invoca attendi() prima che t2 esegua t1.segnala(). Se t2 esegue t1.segnala() prima che t1 abbia eseguito attendi() la segnalazione è perduta, e t1 si trova ad attendere (presumibilmente in eterno, se non arrivano altri notify()). In altre parole wait e notify di Java hanno un significato che non corrisponde a quello di wait e signal visti ai paragrafi 6.1 e Per poter utilizzare direttamente il wait() di Java ai fini della sincronizzazione è necessario garantirsi che la sua esecuzione avvenga prima di quella del corrispondente notify(). Ma siccome la maniera in cui avviene la schedulazione dei thread non è definita (è lasciata a ogni singola implementazione del linguaggio), per garantirlo occorrono misure forti, che possono limitare la generalità del meccanismo di sincronizzazione. A tale proposito, si invita il lettore a esaminare come è stata definita l operazione segnala() nel programma allegato Casello Thread, al fine di garantire che, in una interazione come la precedente, l operazione wait() venga invocata prima del corrispondete notify(). Si osserverà anzitutto che le due operazioni attendi e segnala sono definite per i driver e che l operazione segnala() effettua comunque un attesa di un millisecondo, chiamando il metodo statico sleep() di Thread. Tale attesa garantisce che il controllo (il lock) venga rilasciato prima del notify, in modo che il wait del thread che ha attivato quello che esegue notify possa esse eseguito prima del notify in questione.

21 7 PROGETTO CON USO DEI THREAD E SIMULAZIONE VISUALE DEI DISPOSITIVI 21 7 Progetto con uso dei thread e simulazione visuale dei dispositivi Nel progetto sviluppato in precedenza il lettore di biglietto era simulato tramite la console del sistema. Altri periferici erano semplicemente simulati da programma, senza nessuna interazione con l utente (che corrisponde il guidatore del mezzo). In questa parte ci poniamo il problema di simulare i dispositivi anche in modo visuale. Per esempio, il pulsante di richiesta del biglietto di una porta di ingresso dovrà essere rappresentato con un pulsante sul video, in modo che l operatore interagisca col medesimo esattamente come fa il guidatore con il pulsante ad una porta reale. Vogliamo inoltre che il parallelismo sia ottenuto attraverso i thread. La simulazione visuale dei dispositivi e le interazioni con l utente possono essere ottenute attraverso il supporto swing di java e la programmazione per eventi. 7.1 Rappresentazione visuale dei dispositivi In questa parte viene data una descrizione della rappresentazione visuale dei dispositivi. Questa rappresentazione serve come una sorta di specifica (intuitiva) del sistema. L aspetto delle porte è quello di Figura 12. Figura 12: Schema delle due porte a riposo. A sinistra la porta di ingresso a destra quella di uscita. Ognuna delle due porte raccoglie i dispositivi che la compongono, schematizzati attraverso icone, campi testuali, ecc Porta di ingresso Con riferimento alla Figura 12, partendo dall angolo in alto a sinistra e percorrendo la porta di ingresso in senso antiorario si incontrano i seguenti dispositivi. 1. Pulsante di richiesta del biglietto (PulsanteBiglietto). Questo pulsante viene abilitato per iniziare un un ciclo di transito. Esso cambia aspetto quando viene premuto, appare la scritta Pulsante premuto e viene abilitato l emettitore di biglietto (come a sinistra in Figura 13). 2. Pulsante di emergenza (PulsanteEmergenza). Questo pulsante è normalmente disabilitato (il passo relativo a questo pulsante non viene illustrato in Figura 13). Esso viene abilitato solo quando si verifica la mancanza di biglietti sull emettitore (vedi sotto). A quel punto, quando il pulsante deve essere premuto dall operatore dal guidatore. Ciò determina automaticamente il riempimento (simulato) dell emettitore con una nuova risma di biglietti e determina la riabilitazione del pulsante di richiesta del biglietto, che deve essere nuovamente premuto per procedere. 3. Emettitore del biglietto (EmettitoreBiglietto). Quando è abilitato l emettitore di biglietto assume l aspetti di Figura 13 a sinistra. Come si vede viene indicata la scritta che ci si aspetta sul biglietto: nome del casello, giorno e ora. il click sull icona (a emettitore abilitato) equivale al prelievo del biglietto

22 7 PROGETTO CON USO DEI THREAD E SIMULAZIONE VISUALE DEI DISPOSITIVI 22 Figura 13: A sinistra la porta di ingresso dopo che è stato premuto il pulsante di richiesta biglietto; a destra dopo che il biglietto è stato prelevato e la sbarra si è alzata. e all avvio della fase successiva, consistente nell abilitazione del sensore di passaggio e nell apertura della sbarra. È stato previsto che ci sia un massimo al numero di biglietti che l emettitore può contenere, in modo che quando questi sono finiti abbia luogo la procedura che prevede la pressione del pulsante di emergenza. 4. Sensore di passaggio (SensorePassaggio). Questo dispositivo ha l aspetto di sinistra in Figura 13 quando non è abilitato. Ha l aspetto di destra quando esso è stato abilitato a seguito del prelievo del biglietto. Il sensore simula il passaggio del veicolo. Quando il veicolo è transitato, il sensore ritorna all aspetto di sinistra di Figura 13; inoltre la porta viene informata del passaggio in modo che sia comandabile la chiusura della sbarra. 5. Sbarra (Sbarra). La sbarra viene alzata quando il biglietto è stato prelevato e riabbassata dopo il passaggio del veicolo. Vale la pena di rimarcare che mentre le due fasi di richiesta e emissione del biglietto si svolgono in modo rigorosamente sequenziale, l attività del sensore e quella della sbarra si esplicano in parallelo, almeno fino al punto in cui il sensore riconosce il transito del veicolo Porta di uscita Con riferimento alla Figura 12, partendo dall angolo in alto a sinistra e percorrendo la porta di ingresso in senso antiorario si incontrano i seguenti dispositivi. 1. Lettore biglietto (LettoreBiglietto). E il dispositivo che legge il biglietto. Cliccandoci sopra appare una finestra che permettere di scegliere da quale città proviene il veicolo (Figura 14 a sinistra). La selezione della città porta all abilitazione del gestore automatico del pagamento. 2. Gestore automatico del pagamento (GestorePagamento). Il significato del dispositivo è ovvio. Si è stabilito di non dover tenere conto delle rimanenze dei resti (si assume che il resto venga preso tutto). Il dispositivo calcola il prezzo del biglietto in base alla provenienza e presenta l importo. Il guidatore può scegliere se pagare per carta di credito o contanti. Se paga per contanti viene abilitata la pulsantiera delle monete e deve essere selezionata, anche in più riprese, una cifra pari o superiore all importo (nel secondo caso viene indicato l ammontare del resto). A tale proposito si veda la parte destra di Figura 14, dove appare che devono essere ancora introdotte delle monete per arrivare al pagamento del biglietto. 3. Sensore di passaggio (SensorePassaggio). Esattamente come per la porta di ingresso. 4. Sbarra (Sbarra). Esattamente come per la porta di ingresso.