FloorButton - pressed : Boolean = false + resetbutton( ) : void + pressbutton( ) : void

Transcript

1 0. (Caso di studio facoltativo) Pensare a oggetti: incorporare l ereditarietà nel simulatore di ascensore Rivisitiamo ora il nostro progetto di simulatore di ascensore per vedere come può beneficiare dell ereditarietà. Per applicare l ereditarietà, abbiamo bisogno di scoprire le cose in comune tra le classi del simulatore. Iniziamo esaminando le somiglianze tra le classi FloorButton e ElevatorButton. La figura 0.24 mostra gli attributi e le funzionalità di ciascuna classe. Entrambe le classi hanno lo stesso attributo (pressed) e funzionalità (pressbutton e resetbutton). Saremmo tentati di usare l ereditarietà in questa situazione, cioè estrarre le cose in comune tra le classi FloorButton e ElevatorButton, metterle in una superclasse comune Button, e poi derivare le classi FloorButton e ElevatorButton dalla classe Button. Però, se gli oggetti FloorButton e ElevatorButton hanno un comportamento identico, usare l ereditarietà non è giustificato. In realtà, non possiamo neppure giustificare l uso di classi diverse per questi oggetti! L oggetto FloorButton segnala all oggetto Elevator di muoversi al piano richiesto. L oggetto ElevatorButton segnala all oggetto Elevator di muoversi al piano opposto. Come mostrato nel diagramma di attività della figura 5.29, il FloorButton e l ElevatorButton segnalano all oggetto Elevator di muoversi verso un piano. L oggetto Elevator si muove in risposta a un segnale di FloorButton solo se l Elevator si trova sul piano opposto della richiesta ed è fermo. L Elevator si muove in risposta a un segnale da ElevatorButton solo se è fermo. In ogni caso, né FloorButton, né ElevatorButton ordinano a Elevator di muoversi verso l altro piano. Piuttosto, l Elevator risponde al segnale di un bottone in dipendenza dal suo stato corrente. Ogni bottone ha un solo comportamento, cioè segnalare a Elevator di muoversi. Gli oggetti FloorButton e ElevatorButton sono realmente solo oggetti separati della stessa classe; possiamo allora combinare le classi FloorButton e ElevatorButton nella classe Button ed eliminarle dal nostro caso di studio. Ingegneria del software 0.3 Se parecchi oggetti hanno gli stessi attributi ed esibiscono il medesimo comportamento, sono probabilmente oggetti della stessa classe. Prima di usare l ereditarietà nel vostro programma, assicuratevi che ogni classe abbia attributi distinti e/o esibisca comportamenti distinti. Ora cominciamo a cercare delle classi che esibiscano comportamenti simili (ma non identici). Nella sezione 4.4, abbiamo incontrato il problema di rappresentare la posizione di Person: in quale piano è posizionata una persona quando viaggia nell ascensore? Usando l ereditarietà, ora possiamo modellare una soluzione. Sia Elevator che Floor sono posizioni in cui Person si trova nel simulatore. In altre parole, Elevator e Floor sono tipi di posizioni, ma un Elevator certamente non è un Floor. FloorButton ElevatorButton Figura 0.24 Attributi e funzionalità delle classi FloorButton e ElevatorButton

2 2 CAPITOLO 0 Modifichiamo le classi Elevator e Floor in modo che ereditino da una nuova superclasse chiamata Location. Il linguaggio UML specifica una relazione chiamata generalizzazione che modella l ereditarietà. La figura 0.25 è il diagramma di classe che modella la generalizzazione della superclasse Location e delle sottoclassi Elevator e Floor. Le frecce con la punta vuota indicano che le classi Elevator e Floor ereditano dalla classe Location. La classe Location contiene l attributo private locationname, che contiene un valore stringa tra firstfloor, secondfloor e elevator. Includiamo il metodo setlocationname in modo che ogni sottoclasse possa impostare il valore appropriato. Notate che il metodo setlocationname ha un modificatore di accesso che non abbiamo ancora visto, il segno di cancelletto (#), che indica che il metodo è protected, in modo che solo le sottoclassi Elevator e Floor possano usare questo metodo per impostare locationname. Inoltre, includiamo il metodo public getlocationname, in modo che ogni oggetto possa ottenere il valore di locationname. Cerchiamo altre similarità tra le classi Elevator e Floor. Secondo il diagramma di classe della figura 6.20, entrambe le classi condividono l attributo intero capacity (che vale ). Ora, la classe Location contiene l attributo private capacity, che rappresenta il massimo numero di oggetti Person che possono occupare quella posizione. Nella nostra simulazione, il valore di questo attributo non cambierà durante l esecuzione, e dunque la classe Location dichiara questo attributo come costante usando il termine {frozen} vicino all attributo capacity. La classe Location contiene anche il metodo public getcapacity, che ritorna il valore di capacity, mentre un metodo setcapacity non è necessario, perché il valore di questo attributo non può essere cambiato. Le sottoclassi Elevator e Floor ereditano dunque l attributo capacity e il metodo getcapacity. Location - locationname : String - capacity : Integer = {frozen} # setlocationname( String ) : void + getlocationname( ) : String + getcapacity( ) : Integer Elevator - moving : Boolean = false - summoned : Boolean = false - currentfloor : Integer - destinationfloor : Integer - traveltime : Integer = 5 + ride( ) : void + requestelevator( ) : void + enterelevator( ) : void + exitelevator( ) : void + departelevator( ) : void Floor Figura 0.25 Diagramma di classe che modella la generalizzazione della superclasse Location e delle sottoclassi Elevator e Floor

3 LA PROGRAMMAZIONE ORIENTATA AGLI OGGETTI: POLIMORFISMO 3 Continuiamo a cercare altre similarità. Secondo la figura 3.9, la classe Elevator contiene dei riferimenti al suo bottone e alla sua porta. La classe Floor contiene dei riferimenti al suo bottone e alla sua porta attraverso l associazione di Floor con la classe ElevatorShaft. La classe ElevatorModel aggrega le classi Floor e ElevatorShaft e può passare un riferimento di tipo ElevatorShaft al costruttore della classe Floor. Usando questa associazione, la classe Floor può riferire gli oggetti Button e Door di ElevatorShaft. Quindi, nella nostra simulazione, la classe Location conterrà i metodi public getbutton e getdoor che ritornano rispettivamente dei riferimenti a oggetti Button e Door. La classe Floor sovrascrive questi metodi per ritornare i riferimenti a oggetti Button e Door di quel piano, mentre la classe Elevator sovrascrive questi metodi per ritornare i riferimenti a oggetti Button e Door dell ascensore. Dichiariamo la classe Location come astratta in modo che le sottoclassi Button e Door siano obbligate a implementare i metodi getbutton e getdoor. Il linguaggio UML raccomanda di indicare i nomi delle classi astratte (e dei metodi astratti) in italico, come abbiamo fatto nella figura I metodi getbutton e getdoor non sono invece indicati in italico nelle sottoclassi Elevator e Floor, in quanto in questo caso sono metodi concreti con un implementazione distinta. Notate che le classi Elevator e Floor indicano le funzionalità getbutton e getdoor nel loro terzo scomparto, perché ognuna delle classi ha un implementazione diversa del metodo sovrascritto. In questa simulazione, usare l ereditarietà sembra appropriato per progettare Elevator e Floor. Ogni classe rappresenta una Location che un oggetto Person può occupare, ma la classe Elevator contiene degli attributi e dei comportamenti aggiuntivi che la distinguono dalla classe Floor. Introduciamo un associazione tra la classe Person e la classe Location, che rappresenta il fatto che la persona si trovi sul primo piano, o sul secondo piano, o sull ascensore. Ora rivolgiamo la nostra attenzione alle classi e FloorDoor. Ancora una volta, vediamo se è il caso di usare l ereditarietà con queste classi. La figura 0.26 mostra che gli attributi e le funzionalità di tali classi sono identici: entrambe le classi possiedono l attributo open e le funzionalità opendoor e closedoor. Comunque, in base alla specifica del problema, sappiamo che e FloorDoor hanno comportamenti diversi. Quando si apre, deve aprire FloorDoor per assicurarsi che le porte si aprano insieme. La classe FloorDoor ha gli attributi e le funzionalità di base richieste per tutte le porte, quindi rinominiamo la classe FloorDoor nella classe Door, che rappresenta una generalizzazione delle porte nel nostro caso di studio. La classe rappresenta un caso speciale della più generale classe Door: un oggetto, quando si apre, ha il compito di aprire un altro oggetto Door. Quindi, stabiliamo una relazione di generalizzazione tra la classe e la classe Door. La classe sovrascrive i metodi opendoor e closedoor in modo da implementare il comportamento specifico (figura 0.27). FloorDoor Figura 0.26 Attributi e funzionalità delle classi e FloorDoor

4 4 CAPITOLO 0 Door Figura 0.27 Generalizzazione della superclasse Door e della sottoclasse La figura 0.28 è un diagramma di classe aggiornato del nostro modello che riflette questi cambiamenti, incorpora l ereditarietà, elimina le classi FloorButton, ElevatorButton e FloorDoor e introduce le classi Button, Door e Location. Rimuoviamo le associazioni tra Person e Elevator e tra Person e Floor dal diagramma delle classi, perché il riferimento a Location di Person può essere sia un riferimento a Floor che un riferimento a Elevator. Un oggetto Person imposta il suo riferimento di tipo Location a Elevator quando entra nell ascensore, e a Floor quando cammina su quel piano. Infine, assegniamo alla classe Elevator due riferimenti di tipo Location, che rappresentano il piano corrente dell Elevator e il piano di destinazione (avevamo precedentemente usato degli interi per rappresentare tali informazioni). Permettiamo a un oggetto Person che occupa una posizione di interagire con diversi oggetti (accessibili dall oggetto Location su cui si trova) nel simulatore. Per esempio, un Light 2 Turns on/off ElevatorShaft Resets Floor 2 2 Door Signals arrival Button Presses Person 0..* Opens/Closes Opens Closes Elevator Signals to move Resets Occupies Rings Bell Location - locationname : String 2 - capacity : Integer = {frozen} # setlocationname( String ) : void + getlocationname( ) : String + getcapacity( ) : Integer Figura 0.28 Diagramma di classe del nostro simulatore (con l ereditarietà)

5 LA PROGRAMMAZIONE ORIENTATA AGLI OGGETTI: POLIMORFISMO 5 oggetto Person può premere un oggetto Button dalla sua posizione specifica. Un oggetto Person può occupare solo un oggetto Location per volta, quindi dovrebbe poter interagire solo con gli oggetti noti a quell oggetto Location. Usando il suo riferimento a Location, un oggetto Person non può eseguire un azione illegale, come premere il bottone del primo piano mentre viaggia sull ascensore. Questa restrizione vale anche nel mondo reale. Abbiamo presentato gli attributi e le funzionalità con i modificatori di accesso nella figura 8.9. Ora, presentiamo un diagramma di classe modificato che incorpora l ereditarietà nella figura Questo diagramma abbreviato non mostra le relazioni di ereditarietà, ma invece mostra gli attributi e i metodi dopo che abbiamo applicato l ereditarietà al nostro sistema. Questo diagramma non include gli attributi mostrati dalle aggregazioni nella figura 0.28 per le classi ElevatorShaft e Elevator. Come abbiamo fatto nella figura 4.8, abbiamo scelto di risparmiare spazio nella figura 0.29 non mostrando questi attributi aggiuntivi; comunque, li includeremo nell implementazione Java finale. Ingegneria del software 0.4 Un diagramma di classe completo mostra tutte le associazioni tra le classi e tutti gli attributi e funzionalità di ogni classe. Quando il numero di attributi, metodi e associazioni è notevole (come nelle figure 0.28 e 0.29), è pratica comune dividere queste informazioni in due diagrammi: uno focalizzato sulle associazioni, l altro focalizzato sugli attributi e sui metodi. Creare due diagrammi di classe in questo modo favorisce la leggibilità. La classe Person ora contiene un riferimento location a un oggetto Location, che indica se la persona si trova su un piano o sull ascensore. Implementazione: forward engineering (con l ereditarietà) Nella sezione 8.7, abbiamo usato UML per esprimere le classi Java per la nostra simulazione. Continuiamo la nostra implementazione usando l ereditarietà, prendendo la classe Elevator come esempio.. Se una classe B è una generalizzazione della classe A, allora la classe A estende la classe B nella dichiarazione di classe. Per esempio, la superclasse astratta Location è una generalizzazione della classe Elevator; quindi, la dichiarazione di classe dovrebbe essere public class Elevator extends Location { // costruttore public Elevator() {} } 2. Se la classe B è una classe astratta e la classe A è una sottoclasse della classe B, allora la classe A deve implementare i metodi astratti della classe B (se la classe A deve essere una classe concreta). Per esempio, la classe Location contiene i metodi astratti getbutton e getdoor; quindi, la classe Elevator deve implementare questi metodi. La figura 0.30 mostra il codice Java della classe Elevator dalle figure 0.28 e Notate che il metodo get- Button (righe 26-29) ritorna un riferimento all oggetto Button di Elevator, e il metodo getdoor (righe 23-25) ritorna un riferimento all oggetto Door di Elevator: l oggetto Elevator ha delle associazioni con entrambi gli oggetti, come indicato dal diagramma di classe della figura La classe Elevator eredita i campi capacity e locationname, e i metodi non astratti getcapacity, setlocationname e getlocationname dalla

6 6 CAPITOLO 0 Location - locationname : String - capacity : Integer = {frozen} # setlocationname( String ) : void + getlocationname( ) : String + getcapacity( ) : Integer Light - lighton : Boolean = false + turnonlight( ) : void + turnofflight( ) : void ElevatorShaft Person - ID : Integer - moving : Boolean = true - location : Location + dooropened( ) : void Elevator - moving : Boolean = false - summoned : Boolean = false - currentfloor : Location - destinationfloor : Location - traveltime : Integer = 5 + ride( ) : void + requestelevator( ) : void + enterelevator( ) : void + exitelevator( ) : void + departelevator( ) : void + ringbell( ) : void Floor Bell Button Door Figura 0.29 Diagramma di classe con attributi e funzionalità (con l ereditarietà) superclasse Location, quindi non abbiamo bisogno di dichiararli. La figura 0.29 specifica gli attributi summoned, moving, currentfloor, destinationfloor e traveltime e le funzionalità ride, requestelevator, enterelevator, exitelevator e departelevator per la classe Elevator. Le righe 6-0 della figura 0.30 dichiarano i campi per questi attributi, e le righe 9-23 dichiarano i metodi per queste funzionalità. I riferimenti elevatorbutton, elevatorfloor e bell (righe -3) sono campi specificati dalle aggregazioni di Elevator della figura // Elevator.java 2 // Generato usando il diagramma di classe 0.28 e public class Elevator extends Location { 4 5 // attributi Figura 0.30 La classe Elevator generata dalle figure 0.28 e 0.29 (continua)

7 LA PROGRAMMAZIONE ORIENTATA AGLI OGGETTI: POLIMORFISMO 7 6 private boolean moving; 7 private boolean summoned; 8 private Location currentfloor; 9 private Location destinationfloor; 0 private int traveltime = 5; private Button elevatorbutton; 2 private Door elevatordoor; 3 private Bell bell; 4 5 // costruttore 6 public Elevator () {} 7 8 // funzionalita 9 public void ride() {} 20 public void requestelevator() {} 2 public void enterelevator() {} 22 public void exitelevator() {} 23 public void departelevator() {} // metodo che sovrascrive getbutton 26 public Button getbutton() 27 { 28 return elevatorbutton; 29 } 30 3 // metodo che sovrascrive getdoor 32 public Door getdoor() 33 { 34 return elevatordoor; 35 } 36 } Figura 0.30 La classe Elevator generata dalle figure 0.28 e 0.29 Collaudo e messa a punto 0. Usare degli strumenti di modellazione UML per generare il codice automaticamente aiuta a ridurre la quantità di errori che i programmatori introducono di solito quando scrivono il codice manualmente. Ingegneria del software 0.5 Parecchi strumenti di modellazione UML convertono i modelli UML in Java. Questi strumenti possono velocizzare considerevolmente il processo di implementazione. Abbiamo fornito una buona base di partenza per implementare dei progetti UML in Java. Nella sezione.9, ritorneremo alle interazioni, e ci concentreremo su come gli oggetti generano e gesticono i messaggi passati nelle collaborazioni, e useremo ancora il forward engineering per generare altro codice Java dai diagrammi di classe.