Identificare le classi in un sistema

Transcript

1 3.7 (Caso di studio facoltativo) Pensare a oggetti: identificare le classi nella specifica del problema Cominciamo ad affrontare la progettazione del simulatore di ascensore introdotto nel capitolo. Iniziamo con il progetto dell ascensore stesso, lasciando perdere per il momento l interfaccia utente e la visualizzazione. Identificare le classi in un sistema Il primo passo del nostro procedimento di progettazione orientata agli oggetti è identificare gli oggetti dalla specifica del problema e raggrupparli in classi. Poi, descriveremo le classi in maniera formale e le implementeremo in Java. Per prima cosa, rivediamo la specifica del problema della sezione.9 e identifichiamo i sostantivi chiave; è probabile che alcuni di essi identifichino oggetti che faranno parte del simulatore di ascensore (l analisi dei sostantivi è un modo semplice di identificare gli oggetti; nell industria, vengono usati anche procedimenti più sofisticati). La figura 3.5 elenca i sostantivi trovati. Sceglieremo solo i sostantivi che hanno significato nella simulazione dell ascensore. Pertanto, ometteremo parecchi sostantivi. Non abbiamo bisogno di modellare azienda come una classe, perché l azienda non fa parte della simulazione. Non modelliamo palazzo, cioè dove l ascensore si trova, perché il palazzo non ha rilevanza nella nostra simulazione di ascensore. I termini visualizzazione, audio e musica dell ascensore riguardano la visualizzazione della simulazione, ma non la simulazione in se stessa. I termini interfaccia utente grafica (GUI), utente della nostra applicazione, bottone First Floor e bottone Second Floor riguardano come l utente controlla la simulazione. Sebbene vogliamo risparmiare energia con la politica di non muovere l ascensore se non è necessario, non modelleremo l energia. Infine, la capacità è una proprietà dell ascensore e del piano, e non un entità separata. Determineremo le classi del nostro sistema raggruppando i rimanenti sostantivi. Tralasciamo, per il momento, sistema d ascensori ; ci focalizziamo solo sul progetto del simulatore I sostantivi nella specifica del problema azienda sistema di ascensori interfaccia utente grafica (GUI) palazzo pozzo dell ascensore persona ascensore porta del piano piano (primo piano; secondo piano) simulatore software campanello interno bottone First Floor (all ascensore) passeggero luce al piano bottone Second Floor utente della nostra energia audio applicazione bottone del piano capacità musica dell ascensore bottone dell ascensore cabina dell ascensore visualizzazione Figura 3.5 I sostantivi nella specifica del problema

2 CAPITOLO 3 e non sul rapporto tra tale simulatore e l intero sistema. Combiniamo ascensore e cabina dell ascensore in ascensore, perché la specifica del problema usa i due termini in modo invariato. Dei sostantivi rimanenti nella figura 3.5, ognuno si riferisce a uno o più dei seguenti (indichiamo tra parentesi la traduzione in inglese per facilitare il lettore nell associazione con i nomi delle relative classi, che da qui in avanti verrà usato): buca dell ascensore (elevator shaft) ascensore (elevator) persona (person) piano (primo piano; secondo piano) (floor; first floor; second floor) porta dell ascensore (elevator door) porta del piano (floor door) bottone dell ascensore (elevator button) bottone del piano (floor button) campanello (bell) luce (light) gli elementi di questa lista sono probabilmente delle classi che dovremo implementare nel nostro sistema. Notate che abbiamo elencato i bottoni del piano e dell ascensore separatamente. I due tipi di bottoni hanno scopi differenti nella nostra simulazione: i bottoni dei piani chiamano l ascensore, e il bottone dell ascensore comanda all ascensore di muoversi verso l altro piano. Ora possiamo modellare le classi del sistema in base alla lista che abbiamo creato. Per convenzione, scriviamo i nomi delle classi con l iniziale maiuscola (come in Java). Se il nome di una classe contiene più di una parola, accostiamo le parole e scriviamo l iniziale di ogni parola con la lettera maiuscola (ad es. ParolaDiPiuLettere). Con queste convenzioni, creiamo le classi Shaft,, Person, Floor, Door, FloorDoor, Button, FloorButton, Bell e Light. Prima di iniziare a costruire il sistema, però, dobbiamo capire meglio le relazioni tra le classi. Modellare le classi Il linguaggio UML ci permette di modellare, usando dei diagrammi di classe, le classi del simulatore di ascensore e le loro relazioni. I diagrammi di classe modellano la struttura di un sistema raffigurando le classi, ovvero i mattoni, del sistema. La figura 3.6 rappresenta la classe. In UML, ogni classe è rappresentata da un rettangolo con diviso in tre scomparti. Lo scomparto superiore contiene il nome della classe. Lo scomparto di mezzo contiene gli attributi della classe (di cui parleremo nelle sezioni 4.4 e 5.). Lo scomparto inferiore contiene le funzionalità della classe (di cui parleremo nella sezione 6.5). Figura 3.6 Rappresentare una classe in UML

3 INTRODUZIONE ALLE APPLET JAVA 3 La figura 3.7 mostra le relazioni tra le classi Shaft, e FloorButton. In questo diagramma, i rettangoli non sono divisi in scomparti, in modo da ottenere un diagramma più leggibile. Tale tipo di diagramma viene detto depennato, perché alcune informazioni, come il contenuto degli scomparti di mezzo e inferiore, non sono modellate. Aggiungeremo queste informazioni rispettivamente nelle sezioni 4.4 e 6.5. Nella figura 3.7, una linea continua che connette delle classi rappresenta un associazione. Un associazione è una relazione tra classi. I numeri vicino alle linee rappresentano valori di cardinalità, che esprimono quanti oggetti di una certa classe partecipano all associazione. Dal diagramma, possiamo vedere che due oggetti della classe FloorButton sono associati a un oggetto della classe Shaft, perché ci sono due bottoni del piano sul pozzo dell ascensore. Quindi, la classe FloorButton ha una relazione due-a-uno con la classe Shaft; la classe Shaft ha una relazione uno-a-due con la classe FloorButton. Inoltre, la classe Shaft ha una relazione uno-a-uno con la classe, e viceversa. Usando UML, possiamo modellare diversi tipi di cardinalità. La figura 3.8 mostra i tipi di cardinalità e come vengono rappresentati. Resets FloorButton Shaft Requests Signals arrival Figura 3.7 Diagramma di classe che mostra le associazioni tra alcune classi del sistema Simbolo Significato 0 Nessuno Uno m Un valore intero 0.. Zero o uno m, n m o n m..n Almeno m, ma non più di n * Zero o più 0..* Zero o più..* Uno o più Figura 3.8 Tipi di cardinalità

4 4 CAPITOLO 3 Le associazioni possono avere dei nomi. Per esempio, la parola Requests (richiede) sopra la linea che connette le classi FloorButton ed indica il nome dell associazione, mentre la freccia indica la direzione dell associazione. Queste parte del diagramma si legge due oggetti della classe FloorButton richiedono un oggetto della classe. Notate che i nomi delle associazioni hanno una direzione indicata dalla freccia, quindi sarebbe sbagliato leggere l associazione precedente come un oggetto della classe richiede due oggetti della classe FloorButton. Inoltre, la parola Resets indica che un oggetto della classe Shaft azzera due oggetti della classe FloorButton. Infine, le parole Signal arrival indicano che un oggetto della classe segnala l arrivo dell oggetto a un oggetto della classe Shaft. Oltre a indicare semplici relazioni, le associazioni possono specificare relazioni più complesse, in cui gli oggetti di una classe sono composti di oggetti di altre classi. Considerate un ascensore reale. Di quali parti è composto? L azienda che ci ha chiesto di costruire il simulatore ci dice che questo sistema completo di ascensori è composto di un pozzo dell ascensore, due bottoni dei piani, due luci, due porte dei piani e una cabina dell ascensore. La cabina dell ascensore è composta di diverse parti: un bottone dell ascensore, una porta dell ascensore e un campanello. I rombi sulle linee di associazione nella figura 3.7 indicano che Shaft è costruito a partire da altre parti. La relazione denotata da questa associazione è chiamata aggregazione. L aggregazione implica una relazione tutto/parte. La classe che ha il simbolo di aggregazione dal suo lato della linea di associazione è il tutto (in questo caso, Shaft), mentre la classe all altro lato della linea di aggregazione è la parte (in questo caso, FloorButton e ). Quindi, in questo diagramma, l associazione indica che un oggetto della classe Shaft è formato da due oggetti della classe FloorButton e un oggetto della classe. Il pozzo dell ascensore ha un ascensore e due bottoni del piano. La relazione ha un definisce l aggregazione (mentre, come vedremo nella sezione 0. la relazione è un definisce l ereditarietà). La figura 3.9 mostra il diagramma di classe completo basato sulle relazioni tra gli oggetti descritti nella specifica del problema. Abbiamo modellato tutte le classi identificate e le loro relazioni ( espanderemo questo diagramma nel capitolo 0 usando il concetto di ereditarietà). La classe Shaft è un aggregazione di un oggetto della classe e due oggetti per ciascuna classe fra Light, FloorDoor e FloorButton (notate la relazione due-auno tra ognuna di queste classi ed Shaft). La classe è un aggregazione delle classi Door, Button e Bell. La classe Person è associata con le classi FloorButton ed Button (ed anche altre, come vedremo). Il nome dell associazione Presses (preme) e la direzione della freccia indicano che un oggetto della classe Person preme questi bottoni. L oggetto della classe Person viaggia (rides) inoltre nell oggetto della classe e cammina (walks across) lungo l oggetto della classe Floor. Il nome dell associazione Requests indica che un oggetto della classe FloorButton richiede un oggetto della classe. Il nome dell associazione Signals to move indica che l oggetto della classe Button segnala all oggetto della classe di muoversi verso l altro piano. Il diagramma indica poi altre associazioni. Notate la parola passenger (passeggero) sulla linea di associazione tra Person ed. Questo è un nome di ruolo, che identifica il ruolo dell oggetto Person nella relazione con

5 INTRODUZIONE ALLE APPLET JAVA 5 Light FloorDoor Opens Door Turns on/off Opens Signals arrival Shaft Rings Bell Resets Requests Signals to move Resets Floor FloorButton Presses Presses Button Rides Walks across Person Passenger Figura 3.9 Diagramma di classe per il modello dell ascensore. Un nome di ruolo aggiunge significato a una associazione tra classi. In questo caso, il nome di ruolo passenger indica che quando un oggetto Person viaggia su un oggetto, è un passenger di. Per molte delle associazioni del diagramma, il significato è già chiaro, e non è necessario specificare esplicitamente un nome di ruolo. Ora abbiamo identificato le classi del nostro sistema (anche se potremmo scoprirne altre in fasi successive della progettazione). Nella sezione 4.4, vedremo gli attributi di ciascuna classe, e nella sezione 5. useremo questi attributi per esaminare come il sistema cambi nel tempo e per introdurre i suoi aspetti comportamentali. Identificare le classi in un sistema. Perché potrebbe essere più complicato implementare un palazzo con tre (o più) piani?. I grandi palazzi di solito hanno più ascensori. Vedremo nel capitolo 0 che, una volta creato un ascensore, è facile crearne quanti ne vogliamo. Quali vantaggi e problemi vedete nell avere parecchi ascensori, ognuno dei quali può caricare e scaricare passeggeri a ogni piano del palazzo? 3. Per semplicità, abbiamo dato al nostro ascensore e a ogni piano una capacità di una persona. Quali vantaggi e problemi si possono determinare se aumentiamo queste capacità?