Modélisation d'un ascenseur à l'aide d'une analyse et d'une conception orientées objet
Une série de questions semble être couramment utilisée dans les entretiens et les cours en matière de conception et d'analyse orientées objet. C'est l'un d'eux; malheureusement, mon OOP professeur à l'université ne lui a jamais donné de réponse et c'est ce que je me demandais.
Le problème est le suivant: concevoir un ensemble d’objets/méthodes de base à utiliser pour simuler une banque d’ascenseurs. Quels sont les objets et leurs attributs/méthodes?
Aux fins de discussion, supposons que notre bâtiment compte vingt étages; le rez-de-chaussée est le hall d'entrée et le deuxième étage est relié au garage de stationnement (par conséquent, les gens entreront/sortiront du bâtiment au rez-de-chaussée ou au deuxième étage). Il y a une banque d'ascenseurs qui dessert tous les étages; il y a trois cages d'ascenseur dans la rangée d'ascenseurs et un ascenseur par puits.
Quelle serait la bonne façon de modéliser cela dans un modèle orienté objet?
Il y a d'abord une classe d'ascenseur. Il comporte une direction (haut, bas, stand, maintenance), un étage actuel et une liste de demandes d'étage triées dans la direction. Il reçoit la demande de cet ascenseur.
Ensuite, il y a une banque. Il contient les ascenseurs et reçoit les demandes des étages. Ceux-ci sont planifiés pour tous les ascenseurs actifs (pas en maintenance).
La planification sera comme:
- si disponible, choisissez un ascenseur pour cet étage.
- sinon choisissez un ascenseur se déplaçant à cet étage.
- sinon choisissez un ascenseur debout à un autre étage.
- sinon, choisissez l'ascenseur avec la charge la plus faible.
Chaque ascenseur a un ensemble d'états.
- Maintenance: l'ascenseur ne réagit pas aux signaux externes (uniquement à ses propres signaux).
- Stand: l'ascenseur est fixé sur un étage. S'il reçoit un appel. Et l'ascenseur est à cet étage, les portes s'ouvrent. Si c'est à un autre étage, il se déplace dans cette direction.
- Up: l'ascenseur monte. Chaque fois qu'il atteint un étage, il vérifie s'il doit s'arrêter. Si c'est le cas, il s'arrête et ouvre les portes. Il attend pendant un certain temps et ferme la porte (sauf si un mouvement est en train de les traverser. Ensuite, il retire la parole de la liste des demandes et vérifie s'il y a une autre demande. Si c'est le cas, l'ascenseur commence à se déplacer à nouveau. stand d'état.
- Down: comme en haut mais en sens inverse.
Il y a des signaux supplémentaires:
- alarme. L'ascenseur s'arrête. Et si c'est sur un étage, les portes s'ouvrent, la liste des demandes est effacée, les demandes sont renvoyées à la banque.
- porte ouverte. Ouvre les portes si un ascenseur est sur un étage et ne bouge pas.
- la porte se ferme. Fermez la porte s'ils sont ouverts.
EDIT: Certains ascenseurs ne commencent pas par bottom/first_floor esp. en cas de gratte-ciel.
min_floor & max_floor sont deux attributs supplémentaires pour Elevator.
L'art de la programmation informatique de Donald Knuth Vol.1 présente une démonstration de l'ascenseur et des structures de données. Knuth présente une discussion et un programme très approfondis.
Knuth (1997) "Structures d'information", L'art de la programmation informatique Vol. 1 pp.302-308
J'ai vu de nombreuses variantes de ce problème. L'une des principales différences (qui détermine la difficulté) est de savoir s'il existe une tentative centralisée de disposer d'un "système intelligent et efficace" qui aurait un équilibrage de la charge (par exemple, envoyer davantage d'ascenseurs inactifs au lobby le matin). Si tel est le cas, la conception inclura un sous-système complet avec une conception vraiment amusante.
Un design complet est évidemment trop à présenter ici et il y a beaucoup d'altenatifs. La largeur n'est pas claire non plus. Dans une interview, ils vont essayer de comprendre comment vous pensez. Cependant, voici certaines des choses dont vous auriez besoin:
Représentation du contrôleur central (en supposant qu'il en existe un).
Représentations d'ascenseurs
Représentations des unités d'interface de l'ascenseur (celles-ci peuvent être différentes d'ascenseur à ascenseur). Évidemment aussi appeler des boutons à chaque étage, etc.
Représentations des flèches ou des indicateurs à chaque étage (presque une "vue" du modèle d'ascenseur).
Représentation d'un humain et d'une cargaison (peut être important pour la prise en compte de charges maximales)
Représentation du bâtiment (dans certains cas, certains étages peuvent être parfois bloqués, etc.)
Voir:
Lu Luo, A UML Documentation for a Elevator System
Distributed Embedded Systems, Fall 2000
Ph.D. Project Report
Carneghie Mellon University
Réponse détaillée:
La principale chose à laquelle il faut s’inquiéter est de savoir comment informer l’ascenseur qu’il doit monter ou descendre. et aussi si vous allez avoir une classe centralisée pour contrôler ce comportement et comment pourriez-vous distribuer le contrôle.
Il semble que cela puisse être très simple ou très compliqué. Si nous ne prenons pas la simultanéité ou le temps nécessaire à un ascenseur pour se rendre à un endroit donné, il semble alors que ce sera simple puisque nous devons simplement vérifier l'état de l'ascenseur, comme s'il montait ou descendait ou restait immobile. Mais si nous faisons en sorte que Elevator implémente Runnable, vérifions et synchronisons constamment une file d'attente (linkedList). Une classe de contrôleurs assignera quel étage se placer dans la file d'attente. Lorsque la file d'attente est vide, la méthode run () attendra (queue.wait ()); lorsqu'un étage est affecté à cet ascenseur, elle appelle queue.notify () pour réactiver la méthode run () et lance ( ) cette méthode appellera goToFloor (queue.pop ()). Cela compliquera le problème. J'ai essayé de l'écrire sur du papier, mais je ne pense pas que ça marche. Il semble que nous n’ayons pas vraiment besoin de prendre en compte le problème de simultanéité ou de synchronisation, mais nous devons d’une manière ou d’une autre utiliser une file d’attente pour distribuer le contrôle.
Toute suggestion?
Chose à considérer pendant que conception le système d'ascenseur,
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
Chaque pression sur un bouton entraîne une demande d'ascenseur à servir. Chacune de ces demandes est suivie dans un lieu global
Le nombre d'ascenseurs dans le bâtiment sera déterminé par l'utilisateur. Le bâtiment comportera un nombre fixe d'étages. Le nombre de passagers pouvant entrer dans l'ascenseur sera fixé. Les passagers seront comptés lorsqu'ils quitteront l'ascenseur à l'étage de destination. Le plancher de destination sera déterminé en utilisant un intervalle de Poisson "aléatoire". Lorsque tous les passagers de l'ascenseur ont atteint leur étage de destination, l'ascenseur retournera dans le hall pour accueillir plus de passagers.