Fast Food Manager (esame completo)

Gestione di un piccolo fast food

Il software si occuperà di gestire un piccolo fast food, in cui lavorano un dirigente, uno o più cassieri, uno o più cuochi e uno o più addetti a pulizie e manutenzione. I clienti ordinano e dopo il pagamento viene loro assegnato un numero sequenziale, dopodiché attendono la preparazione. Su un display al centro della sala viene visualizzato il numero dell'ultima ordinazione pronta in modo che il cliente possa avvicinarsi per ritirarla. Il cuoco preleva gli ingredienti da un frigorifero, il cui contenuto è monitorato. Introduco alcune approssimazioni, per semplificare l'intero progetto: non essendo un software gestionale, esso non tiene traccia delle spese dell'attività, dunque non si preoccupa di far quadrare i bilanci; né si occupa della gestione del personale. Inoltre si assuma che tutti gli ingredienti siano presenti - e necessari - in unità monoporzione: ad esempio, per preparare una data pietanza servono gli ingredienti necessari in una sola porzione.

ingredienti α e β, ovvero una unità dell'ingrediente α e una dell'ingrediente β. Il frigorifero contiene esclusivamente prodotti così confezionati.

Per la generazione dei diagrammi UML delle classi e di collaborazione ho utilizzato il programma UmbrelloUML Modeller di KDE. Le immagini sono state esportate in SVG per non perdere definizione.

Mario Cianciolo (M01/000499) 3

Definizioni

Di seguito alcune definizioni che saranno utilizzate nel resto del documento.

• INGREDIENTE: singolo elemento monoporzione usato come base per le preparazioni
• FRIGORIFERO: contenitore per gli ingredienti
• PIETANZA: composizione di uno o più ingredienti
• ORDINE: gruppo di pietanze da preparare e servire insieme
• CODA: sequenza in cui gli ordini vengono inseriti, e successivamente vengono estratti dal cuoco per essere preparati. L'estrazione avviene nell'ordine di ingresso nella coda (FIFO)

UID: intero sequenziale univoco

associato ad ogni ordine non appena viene pagato, e quindi immesso nella coda

CASSIERE: dipendente che immette l'ordine nel sistema e, dopo il pagamento, comunica al cliente il corrispondente UID

DIRIGENTE: dipendente che rilascia gli stipendi agli altri dipendenti.

Requisiti funzionali

Il sistema dovrà permettere ai cassieri di inserire ordini nella coda. Ogni ordine comprenderà una o più pietanze, ognuna con il proprio prezzo. Il cassiere potrà calcolare il totale dell'ordine, che appena pagato sarà inserito in coda con un UID. La coda manterrà l'UID dell'ultimo ordine servito.

Il frigorifero ha una capienza massima, e registrerà ogni volta che un ingrediente viene prelevato o introdotto.

Ogni pietanza è composta da diversi ingredienti, ed è disponibile solo se sono presenti tutti gli ingredienti necessari. La coda è attiva solo se almeno una pietanza è disponibile, altrimenti

dovrà essere formattata utilizzando i tag HTML appropriati. Ecco come potrebbe apparire il testo formattato:

Il locale dovrà chiudere. Il cuoco estrae gli ordini dalla coda, li prepara e infine imposta l'UID dell'ordine all'ultimo servito. Ogni dipendente timbra per registrare le proprie ore di lavoro, così il dirigente può calcolare lo stipendio in base alla paga oraria di ciascuno. Il dirigente può ottenere resoconti sugli ingredienti utilizzati, in modo da poterli acquistare per tenere il frigorifero pieno.

Legenda: classe attributo operazione

• Mario Cianciolo (M01/000499) 4

Progettazione

La classe Dipendente ha gli attributi pagaOraria e oreLavoro. Dipendente possiede i metodi timbraInizio() e timbraFine(): il primo avvia un timer, l'altro lo termina e aggiorna oreLavoro. Possiede infine i metodi calcolaStipendio() e resetOreLavoro(), le cui funzioni appaiono chiare dal nome. Dipendente è una classe abstract: emergono le classi derivate Dirigente, Cassiere, Cuoco e Inserviente. Alcune di esse interagiscono con altre classi. Ogni classe

Il tuo compito è formattare il testo fornito utilizzando tag html. ATTENZIONE: non modificare il testo in altro modo, NON aggiungere commenti, NON utilizzare tag h1;

derivata specifica la propria pagaOraria nel costruttore.

Dirigente utilizza i metodi di tutti gli altri Dipendente per calcolare il loro stipendio. Inoltre utilizza i metodi sul consumo di ingredienti di Frigorifero per poterli reintegrare dopo la giornata lavorativa.

Cassiere utilizza Coda per introdurre ordini nella coda, Ordine e PoolOrdine per creare l'ordine e calcolarne il totale, Pietanza e CreatorPietanza per popolarlo, tutto tramite il metodo immettiIngrediente().

Cuoco utilizza Coda per estrarre gli ordini da preparare e per poi impostare l'ultimo ordine servito. Inoltre utilizza Ordine per estrarre gli oggetti Pietanza, da cui estrae gli oggetti Ingrediente da passare poi a Frigorifero.

La classe principale è FastFood. Dovrebbe contenere main(). Contiene una Coda, un Frigorifero e una lista di Dipendente con relativi getter. L'accesso deve essere filtrato da un singleton.

La classe Frigorifero ha l'attributo capienza, più due interi per ogni

ingrediente esistente, che ne indicano la quantità presente (<=capienza) e la quantità consumata dall'ultimo controllo. Il metodo ingredienteDisponibile(Class) indica se un ingrediente è presente, getConsumo(Class) restituisce la quantità consumata dall'ultimo reset, eseguito con resetConsumo(Class). Tramite inserisciIngrediente(Class, int) e prelevaIngrediente(BuilderIngrediente) si immette o si ottiene una istanza (factory method) di un ingrediente.

La classe Pietanza ha l'attributo prezzo, e il metodo isDisponibile() che verifica che siano disponibili tutti gli ingredienti necessari per la preparazione. La classe è abstract: deve essere specializzata una volta per ogni pietanza. Il metodo da specializzare è getIngredienti(), che restituisce in un array gli ingredienti necessari. Possiede il metodo getPrezzo(). Ogni classe derivata deve specificare il valore di prezzo nel costruttore.

Anche classe Ingrediente è abstract, e

schermo. La classe Dipendente ha anche un attributo ruolo, con getter e setter, per indicare il ruolo del dipendente all'interno del ristorante. La classe Pietanza ha un attributo prezzo, con getter e setter, per indicare il prezzo della pietanza. La classe Ingrediente ha un attributo categoria, con getter e setter, per indicare la categoria dell'ingrediente.

schermo e l'eventuale logging.

Mario Cianciolo (M01/000499)

Diagrammi delle classi

A partire dalla precedente sezione, ho modellato le classi in UML. Per semplicità e leggibilità del grafico, ho deciso di suddividerlo in tre parti, in base al tipo di relazioni tra le classi e alle funzioni svolte da esse.

Verranno anche messi in evidenza anche i design pattern utilizzati, che verranno approfonditi in seguito.

Diagramma 1

FastFood

• instance : FastFood = null
• FastFood()+ getInstance() : FastFood
• getCoda() : Coda
• getDipendenti() : List<Dipendente>
• getFrigorifero() : Frigorifero

Inserviente

• Dipendente
• Dirigente

Cassiere

• calcolaStipendio() : int
• resetOreLavoro()
• getNome() : String
• immettiOrdine()

Cuoco

• ultimoUid : int = 0
• Cuoco(nome)

Coda

Frigorifero

sono rappresentate con frecce tratteggiate.

evidenziano le classi derivate da Dipendente. Di queste, due (Cassiere e Cuoco) utilizzano metodi di Coda, il primo per inserire, il secondo per estrarre elementi. Infine, la composizione di FastFood con sé stesso è dovuta all'utilizzo di un singleton per impedire istanze multiple.

Mario Cianciolo (M01/000499) 6

Diagramma 2

Frigorifero

• capienza : int
• ingredienti : Map<Class,int>
• consumo : Map<Class,int>

+ ingredienteDisponibile(classIngr : Class) : boolean

+ getConsumo(classIngr : Class) : int

+ resetConsumo(classIngr : Class)

+ inserisciIngrediente(classIngr : Class, qty : int)

+ prelevaIngrediente(c : CreatorIngrediente) : Ingrediente

+ getTipi() : List<Class> «interface»

ConcreteCreatorIngrediente

+ creaIngrediente() : Ingrediente

Ingrediente

ConcreteProductIngrediente

• nome : String
• + getNome() : String

*1

Pietanza

ConcreteProductPietanza

• prezzo : int
• nome : String

+ Pietanza(nome : String, prezzo : int)

+ isDisponibile() :

boolean ConcreteCreatorPietanza+ getPrezzo() : int+ getNome() : String+ getIngredienti() : List<Class> * «interface»CreatorPietanza+ creaPietanza() : Pietanza1 Ordine- uid : int+ getUid() : int+ setUid(n : int)+ clearPietanze()+ addPietanza(p : Pietanza)+ getPietanze() : List<Pietanza>+ calcolaTotale() : int

Il diagramma 2 analizza il modo in cui gli ingredienti vengono creati e prelevati dal frigorifero, e analogamente mostra come le pietanze vengono inserite nell'ordine. Essendo gli ingredienti, al momento, sconosciuti, ho preferito utilizzare la rappresentazione più generica possibile, e soprattutto la più espandibile. Ho deciso di fare uso in entrambi i casi (evidenziati nei riquadri) del Factory Method: sono presenti le interfacce CreatorPietanza e CreatorIngrediente, che i ConcreteCreator dovranno implementare. Allo stesso mod