Modellazione di un ascensore mediante analisi e progettazione orientate agli oggetti [chiuso]

Ci sono una serie di domande che sembrano essere comunemente utilizzate nelle interviste e nelle lezioni quando si tratta di progettazione e analisi orientate agli oggetti. Questo è uno di loro; sfortunatamente, il mio professore di OOP al college non ha mai realmente risposto, e quindi mi chiedevo.

Il problema è il seguente: progettare un insieme base di oggetti / metodi da utilizzare per simulare un banco di elevatori. Quali sono gli oggetti e i loro attributi / metodi?

Per ragioni di argomento, supponiamo che il nostro edificio abbia venti piani; il piano inferiore è la hall e il secondo piano si collega al garage (pertanto, le persone entreranno / usciranno dall'edificio al piano inferiore o al secondo piano). C'è una banca dell'ascensore che serve tutti i piani; ci sono tre assi dell'ascensore nella banca dell'ascensore e un ascensore per asse.

Quale sarebbe il modo corretto di modellarlo in un modello orientato agli oggetti?

Prima c'è una classe di ascensore. Ha una direzione (su, giù, stand, manutenzione), un piano corrente e un elenco di richieste di piano ordinate nella direzione. Riceve la richiesta da questo ascensore.

Poi c'è una banca. Contiene gli ascensori e riceve le richieste dai piani. Questi sono programmati per tutti gli ascensori attivi (non in manutenzione).

La pianificazione sarà come:

• se disponibile, scegli un ascensore per questo piano.
• altrimenti scegli un ascensore che si sposta su questo piano.
• altrimenti prendi un ascensore in piedi su un altro piano.
• altrimenti scegli l'ascensore con il carico più basso.

Ogni ascensore ha una serie di stati.

• Manutenzione: l'ascensore non reagisce ai segnali esterni (solo ai propri segnali).
• Stand: l'ascensore è fissato su un piano. Se riceve una chiamata. E l'ascensore è su quel piano, le porte si aprono. Se si trova su un altro piano, si muove in quella direzione.
• Su: l'ascensore si alza. Ogni volta che raggiunge un piano, controlla se deve fermarsi. In tal caso si ferma e apre le porte. Aspetta un certo periodo di tempo e chiude la porta (a meno che qualcosa non si stia muovendo attraverso di loro. Quindi rimuove il pavimento dall'elenco delle richieste e controlla se c'è un'altra richiesta. In tal caso l'ascensore inizia a muoversi di nuovo. Altrimenti entra nel posizione statale.
• Giù: come su ma in direzione opposta.

Ci sono segnali aggiuntivi:

• allarme. L'ascensore si ferma. E se si trova su un piano, le porte si aprono, l'elenco delle richieste viene cancellato, le richieste tornano alla banca.
• porta aperta. Apre le porte se un ascensore è su un piano e non si muove.
• la porta si chiude. Chiuso la porta se sono aperti.
  

EDIT: Alcuni ascensori non iniziano in fondo / primo_piano esp. in caso di grattacieli.

min_floor e max_floor sono due attributi aggiuntivi per Elevator.

The Art of Computer Programming Vol.1 di Donald Knuth ha una dimostrazione di ascensore e strutture dati. Knuth presenta una discussione e un programma molto approfonditi.

Knuth (1997) "Strutture informatiche", L'arte della programmazione informatica Vol. 1 pagg. 302-308

Ho visto molte varianti di questo problema. Una delle principali differenze (che determina la difficoltà) è se vi sia un tentativo centralizzato di avere un "sistema intelligente ed efficiente" che avrebbe un bilanciamento del carico (ad esempio, inviare più ascensori inattivi nella hall al mattino). In tal caso, il design includerà un intero sottosistema con un design davvero divertente.

Un progetto completo è ovviamente troppo da presentare qui e ci sono molti altenativi. Anche l'ampiezza non è chiara. In un'intervista, proveranno a capire come pensi. Tuttavia, queste sono alcune delle cose di cui avresti bisogno:

1. Rappresentazione del controller centrale (supponendo che ce ne sia uno).

2. Rappresentazioni di ascensori

3. Rappresentazioni delle unità di interfaccia dell'ascensore (che possono essere diverse da un ascensore all'altro). Ovviamente anche i pulsanti di chiamata su ogni piano, ecc.

4. Rappresentazioni delle frecce o degli indicatori su ciascun piano (quasi una "vista" del modello dell'ascensore).

5. Rappresentazione di un essere umano e di carico (può essere importante per il factoring in carichi massimi)

6. Rappresentazione dell'edificio (in alcuni casi, poiché alcuni piani possono essere bloccati a volte, ecc.)

Vedere:

Lu Luo, A UML Documentation for a Elevator System
Distributed Embedded Systems, Fall 2000
Ph.D. Project Report
Carneghie Mellon University

collegamento

Risposta dettagliata:

http://www.angelfire.com/trek/software/elevator.html

La cosa da considerare durante la progettazione del sistema di ascensore,

Elevator
Floor/Location Identifier
Number of steps
Rotation speed
Daterange
InstallationDate
MaintainenceDate
Department Identifier
AllowedWeight
Detail / Description
Poison Ratio (Statistics)
Start
Stop
SetDirection
SetRotationSpeed
EmergencyStop = Stop + Alert
EmergencyAccidentSenser Handler

Ogni pressione del pulsante provoca una richiesta di ascensore che deve essere servita. Ognuna di queste richieste viene tracciata in un luogo globale

Il numero di ascensori nell'edificio sarà determinato dall'utente. L'edificio conterrà un numero fisso di piani. Sarà fissato il numero di passeggeri che possono entrare nell'ascensore. I passeggeri verranno conteggiati quando escono dall'ascensore al piano di destinazione. Il piano di destinazione verrà determinato utilizzando un intervallo di Poisson "casuale". Quando tutti i passeggeri dell'ascensore avranno raggiunto i piani di destinazione, l'ascensore tornerà nella hall per raccogliere più passeggeri

La cosa principale di cui preoccuparsi è come notificheresti all'ascensore che deve muoversi su o giù. e anche se hai intenzione di avere una classe centralizzata per controllare questo comportamento e come puoi distribuire il controllo.

Sembra che possa essere molto semplice o molto complicato. Se non prendiamo la concorrenza o il tempo per un ascensore per arrivare a un posto, allora sembra che sarà semplice poiché dobbiamo solo controllare gli stati dell'ascensore, come se si muovesse su o giù o stando fermi. Ma se rendiamo Elevator implementabile Runnable e controlliamo e sincronizziamo costantemente una coda (LinkedList). Una classe Controller assegnerà a quale piano andare in coda. Quando la coda è vuota, il metodo run () attenderà (queue.wait ()), quando un piano viene assegnato a questo ascensore, chiamerà queue.notify () per riattivare il metodo run () ed eseguirà ( ) chiamerà goToFloor (queue.pop ()). Ciò renderà il problema troppo complicato. Ho provato a scriverlo su carta, ma non credo che funzioni. Sembra che non abbiamo davvero bisogno di prendere in considerazione il problema della concorrenza o dei tempi qui,

Qualche suggerimento?