La specifica del problema

Transcript

1 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a oggetti alla fine di questo e dei prossimi capitoli vi introdurranno alla metodologia orientata agli oggetti mediante l esame di un caso di studio completo che riguarda un ascensore. Questo non va considerato un esercizio, ma una esperienza di apprendimento completa che mostra il tipo di problematiche che potreste incontrare nell industria. La specifica del problema Un azienda vuole costruire un palazzo di due piani e dotarlo di un ascensore. L azienda vuole sviluppare un simulatore software (orientato agli oggetti) che modella il funzionamento dell ascensore, in modo da determinare la sua buona funzionalità. L azienda vuole che la simulazione contenga un sistema di ascensori che consite di una cabina d ascensore e un pozzo dell ascensore. Nella nostra simulazione, le persone si spostano tra i piani usando la cabina dell ascensore, come mostrato nelle figure 2.22, 2.23 e L ascensore comprende una porta che si apre quando l ascensore arriva in un piano, si chiude quando l ascensore riparte, e rimane chiusa nel percorso tra i piani per evitare danni ai passeggeri. Inoltre, il pozzo dell ascensore è collegato a ogni piano mediante una porta che si chiude quando l ascensore non si trova a quel piano, per evitare che le persone cadano [Nota: le porte ai piani non sono mostrate nelle Secondo piano Bottoni ai piani Luci Pozzo dell ascensore Primo piano Persona che va verso l ascensore Bottone GUI Bottone GUI (disabilitato) Allarme Porta ascensore Ascensore Bottone ascensore Figura 2.22 Una persona che si muove verso l ascensore sul primo piano

2 2 CAPITOLO 2 Figura 2.23 Una persona sull ascensore che si muove verso il secondo piano Persona che esce dall ascensore La luce del piano si accende quando arriva l ascensore Porta dell ascensore aperta Figura 2.24 Una persona che sta uscendo dall ascensore figure, perché nasconderebbero l interno dell ascensore.] La porta dell ascensore ha un meccanismo che chiude e apre le porte ai piani quando l ascensore parte e arriva, quindi entrambe le porte si aprono e chiudono allo stesso tempo, e le persone le vedono come una sola porta. Una persona all interno dell ascensore vede la porta dell ascensore e può uscire quando questa è aperta; una persona all esterno dell ascensore vede la porta del piano e può entrare nell ascensore quando questa è aperta.

3 INTRODUZIONE ALLE APPLICAZIONI JAVA 3 L ascensore all inizio si trova al primo piano e le porte sono chiuse. Per risparmiare energia, l ascensore si muove solo quando è necessario. Per semplicità, supponiamo che sia l ascensore che i piani abbiano una capacità di una sola persona (dopo aver studiato la simulazione, potreste modificarla in modo da avere più persone nell ascensore e ai piani). L utente della nostra applicazione dovrebbe, in qualsiasi momento, poter creare una deter minata persona nella simulazione e porla al primo o al secondo piano (figura 2.22). Una volta creata, la persona cammina verso l ascensore e, se la porta non è aperta, preme un bottone (detto bottone del piano ) vicino al pozzo dell ascensore. Se premuto, il bottone si illumina, e l ascensore viene richiesto, e inizia a muoversi verso il piano in cui la persona si trova, se non si trova già lì, e in tal caso non si muove. Al suo arrivo, l ascensore azzera il bottone all interno dell ascensore (detto bottone dell ascensore ), fa suonare il campanello interno, e apre la porta dell ascensore (che apre anche la porta del piano). Poi, segnala al pozzo dell ascensore il suo arrivo; il pozzo dell ascensore, dopo aver ricevuto questo messaggio, azzera il bottone del piano e accende la luce al piano. Può capitare che una persona richieda l ascensore mentre questo si sta muovendo. Se la richiesta è arrivata dal piano da cui l ascensore è appena partito, l ascensore deve ricordarsi di tornare a quel piano dopo aver portato il passeggero corrente al piano di destinazione. Quando la porta del piano si apre, la persona che aspetta l ascensore entra nell ascensore dopo che il passeggero (se c è) è uscito. Se nessuna persona entra o richiede l ascensore, questo chiude la porta e rimane a quel piano fino a che qualcuno premo un bottone del piano per chiamarlo. Quando una persona entra nell ascensore, preme il bottone dell ascensore, che si illumina. L ascensore chiude la porta (che chiude anche la porta del piano), parte verso l altro piano, e impiega cinque secondi per il viaggio tra i piani. Quando l ascensore arriva al piano di destinazione, la porta dell ascensore si apre (insieme alla porta del piano), e la persona esce. L utente dell applicazione crea una persona al primo o al secondo piano premendo i bottoni First Floor o Second Floor, rispettivamente. L utente può creare quante persone vuole, ma non può creare una persona in un piano se vi è già un utente in attesa dell ascensore sul medesimo piano. Per esempio, la figura 2.22 mostra che il bottone First Floor è disabilitato per impedire all utente di creare più persone al primo piano. La figura 2.23 mostra che il bottone viene nuovamente abilitato quando la persona entra nell ascensore. L azienda richiede che mostriamo l esecuzione dell applicazione in modo grafico, come mostrato nelle figure 2.22, 2.23 e Lo schermo dovrebbe dunque mostrare una persona che cammina verso l ascensore, preme un bottone, entra nell ascensore ed esce. Inoltre, la visualizzazione deve mostrare l ascensore che si muove, le porte che si aprono, le luci che si accendono e spengono, i bottoni che si illuminano se premuti e si oscurano se azzerati. L azienda richiede che l audio sia integrato nell applicazione. Per esempio, se una persona cammina, l utente dovrebbe udire il rumore dei passi. Ogni volta che un bottone viene premuto o azzerato, l utente dovrebbe sentire un click. Il campanello dovrebbe suonare all arrivo dell ascensore, e si dovrebbero sentire le porte aprirsi e chiudersi. Infine, tra un piano e l altro, si dovrebbe sentire della musica all interno dell ascensore. Analizzare e progettare l ascensore Il precedente problema è un esempio semplificato di una specifica dei requisiti, ovvero un documento che specifica lo scopo del sistema e le condizioni che deve soddisfare per risolvere

4 4 CAPITOLO 2 il problema. La specifica dei requisiti di solito è il risultato di un processo dettagliato di raccolta dei requisiti, che si compone di interviste con gli utenti del sistema e con esperti in determinati campi. Ad esempio, un consulente che viene assunto per progettare del software per una banca potrebbe intervistare degli esperti di finanza per capire meglio come il software debba funzionare. Gli analisti devono analizzare la specifica dei requisiti e progettare il sistema prima di iniziare l implementazione. L analisi della specifica dei requisiti dovrebbe produrre un progetto ad alto livello che descrive che cosa è necessario per risolvere il problema. Il risultato della fase di progettazione, invece, deve specificare chiaramente come il sistema deve essere costruito, in modo da soddisfare la specifica dei requisiti. Nelle prossime sezioni Pensare a oggetti, porteremo avanti un procedimento di progettazione orientata agli oggetti (objectoriented design, OOD) del sistema dell ascensore. Il linguaggio UML è stato pensato per l utilizzo con qualunque procedimento OOD, ad esempio Rational Unified Process, sviluppato da Rational Design Corporation. Per questo caso di studio, useremo un nostro procedimento di progettazione semplificato. Ora iniziamo la fase di progettazione del nostro ascensore. Un sistema è un insieme di componenti che interagiscono fra loro per risolvere un problema. Nel nostro caso di studio, l applicazione simulatore di ascensore rappresenta il sistema. Un sistema può contenere dei sottosistemi, che sono sistemi all interno di un sistema. I sottosistemi semplificano la progettazione perché ognuno si occupa di un sottoinsieme delle funzionalità del sistema. I progettisti possono dividere le funzionalità tra i vari sottosistemi, progettarli, e quindi integrarli nel sistema globale. Abbiamo deciso di dividere il nostro simulatore di ascensore in tre sottosistemi: 1. La logica del simulatore (che rappresenta il funzionamento dell ascensore), 2. La visualizzazione del simulatore sullo schermo e 3. L interfaccia utente grafica (che permette all utente di controllare la simulazione. La struttura del sistema descrive gli oggetti del sistema e le loro relazioni. Il comportamento del sistema descrive come il sistema cambia a seguito dell interazione dei propri oggetti. Ogni sistema ha sia una struttura che un comportamento, e dobbiamo progettare entrambi. Ci sono, comunque, diversi tipi di strutture e comportamenti. Per esempio, le interazioni tra gli oggetti del sistema sono diverse dalle interazioni tra l utente e il sistema, ma entrambe fanno parte del comportamento del sistema. Il linguaggio UML specifica nove tipi di schemi grafici per modellare sistemi (ci sono in realtà altri tre schemi, Packages, Subsystems e Modules, che non discutiamo in questo caso di studio). Ogni diagramma modella una caratteristica distinta della struttura o del comportamento del sistema. I primi quattro diagrammi si riferiscono alla struttura del sistema, mentre i rimanenti cinque si riferiscono al comportamento: 1. Diagrammi di classe (class diagrams), di cui parleremo nella sezione 3.7, che modellano le classi (i mattoni ) usate nel sistema. Ogni entità nella specifica del problema è un candidato a divenire una classe del sistema (ad esempio, person, elevator, floor ecc.). 2. Diagrammi di oggetto (object diagrams), che modellano una istantanea del sistema rappresentando gli oggetti del sistema e le loro relazioni in un dato istante nel tempo. Ogni oggetto rappresenta un istanza di una classe del diagramma delle classi (ad esempio, l oggetto ascensore è un istanza della classe elevator), e ci possono essere diversi oggetti che sono

5 INTRODUZIONE ALLE APPLICAZIONI JAVA 5 istanze della medesima classe (ad esempio, gli oggetti che rappresentano i bottoni sia del primo che del secondo piano sono creati dalla classe floorbutton). In questo caso di studio, non è necessario un diagramma degli oggetti, e quindi non lo useremo. 3. Diagrammi di componente (component diagrams), che modellano i componenti, ad esempio risorse (come grafica, audio ecc.) E package che compongono il sistema. 4. Diagrammi di impiego (deployment diagrams), che modellano i requisiti di esecuzione del sistema (come ad esempio il computer o i computer su cui il sistema verrà eseguito), i requisiti di memoria del sistema, o altri dispositivi che il sistema richiede durante l esecuzione. In questo caso di studio, non è necessario un diagramma di impiego, perché il nostro sistema non ha requisiti hardware specifici, e quindi non lo useremo. 5. Diagrammi degli stati (statechart diagrams), che modellano come un oggetto cambia il suo stato (cioè, la condizione di un oggetto in un certo momento). Quando un oggetto cambia stato, può cambiare anche il suo comportamento. 6. Diagrammi di attività (activity diagrams), che modellano l attività di un oggetto, ovvero come svolge il suo compito durante l esecuzione del programma. Un diagramma di attività è un diagramma di flusso che modella le azioni che l oggetto svolgerà e in che ordine. 7. Diagrammi di collaborazione (collaboration diagrams), che modellano quali interazioni avvengono tra gli oggetti nel sistema. 8. Diagrammi di sequenza (sequence diagrams), che modellano quando avvengono delle interazioni tra oggetti nel sistema. 9. Diagrammi di utilizzo (use case diagrams), che rappresentano le interazioni tra l utente e il sistema (cioè, tutte le azioni che l utente può fare sul sistema). Il nostro caso di studio prosegue nella sezione 3.7, in cui identificheremo le classi a partire dalla specifica del problema, e svilupperemo un diagramma delle classi.