Modélisation d'un ascenseur à l'aide de l'Analyse et de la Conception Orientées Objet [fermé]
Il y a un ensemble de questions qui semblent être couramment utilisées dans les entretiens et les classes en ce qui concerne la conception et l'analyse orientées objet. C'est l'un d'entre eux; malheureusement, mon professeur de POO au collège n'a jamais donné de réponse, et je me suis donc demandé.
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?
Pour des raisons d'argument, supposons que notre bâtiment a vingt étages; l'étage inférieur est le hall, et le deuxième étage se connecte 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'ascenseur qui dessert tous les étages; il y a trois cages d'ascenseur dans la banque d'ascenseur, et un ascenseur par puits.
Quelle serait la bonne façon de modéliser cela dans un modèle orienté objet?
7 answers
Il y a d'abord une classe d'ascenseur. Il a une direction (haut, bas, debout, 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 programmés pour tous les ascenseurs actifs (non en maintenance).
La planification sera comme:
- si disponible, choisissez un ascenseur debout pour cet étage.
- autre 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.
- Entretien: l'ascenseur ne réagit pas aux signaux externes (seulement à ses propres signaux).
- Stand: l'ascenseur est fixé sur un plancher. Si elle reçoit un appel. Et l'ascenseur est à cet étage, les portes s'ouvrent. S'il est à un autre étage, il se déplace là-dedans direction.
- Vers le haut: l'ascenseur monte. Chaque fois qu'il atteint un plancher, il vérifie s'il doit arrêter. Si donc il s'arrête et ouvre les portes. Il attend un certain temps et ferme la porte (à moins que quelque chose ne se déplace à travers eux. Ensuite, il supprime le plancher de la liste des demandes et vérifie s'il y a une autre demande. Si c'est le cas, l'ascenseur recommence à bouger. Sinon, il entre dans la position de l'État.
- Vers le bas: comme vers le haut mais dans le sens inverse.
Il y a des signaux:
- alarme. L'ascenseur s'arrête. Et si c'est sur un étage, les portes s'ouvrent, la liste des demandes est désactivée, les demandes déplacé vers la banque.
- , porte ouverte. Ouvre les portes si un ascenseur est sur un plancher et ne bouge pas.
- la porte se ferme. Fermé la porte si elles sont ouvertes.
MODIFIER: 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.
Il s'agit de l'un des plus grands succès de l'histoire de l'informatique.1 a 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) "Les Structures d'Information", The Art of Computer Programming, 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 y a une tentative centralisée d'avoir un "système intelligent et efficace" qui aurait un équilibrage de charge (par exemple, envoyer plus d'ascenseurs au ralenti dans le hall le matin). Si tel est le cas, la conception comprendra un sous-système entier avec un design vraiment amusant.
Un design complet est évidemment trop à présenter ici et il y a beaucoup d'altenatifs. La largeur est pas clair. Dans un interview, ils vont essayer de comprendre comment vous penseriez. Cependant, ce sont quelques-unes des choses dont vous auriez besoin:
Représentation du contrôleur central (en supposant qu'il y en ait un).
Les Représentations des ascenseurs
Représentations des unités d'interface de l'ascenseur (celles-ci peuvent être différentes de ascenseur à ascenseur). Évidemment aussi des boutons d'appel à chaque étage,etc.
Représentations des flèches ou des indicateurs sur chacun étage (presque une" vue " du modèle d'ascenseur).
-
Représentation d'un humain et d'une cargaison (peut être importante pour l'affacturage des charges maximales)
Représentation du bâtiment (dans certains cas, certains étages pouvant parfois être 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:
Chose à considérer Pendant que Conçoit 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 qui doit être servie. Chacune de ces demandes est suivie à un endroit global
, Le nombre d'ascenseurs dans le bâtiment sera déterminé par l'utilisateur. Le bâtiment contiendra un nombre fixe d'étages. Le nombre de passagers pouvant entrer dans l'ascenseur sera fixé. Les passagers seront comptés lorsqu'ils quittent l'ascenseur à leurs étage de destination. L'étage de destination sera déterminé à l'aide d'un intervalle de Poisson" aléatoire". Lorsque tous les passagers dans l'ascenseur ont atteint leurs étages de destination, l'ascenseur retournera dans le hall pour ramasser plus de passagers
La principale chose à craindre est de savoir comment aviser 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 concurrence ou le temps pour qu'un ascenseur se rende à un endroit, alors il semble que ce sera simple puisque nous avons juste besoin de vérifier les états de l'ascenseur, comme s'il se déplace vers le haut ou vers le bas, ou encore debout. Mais si nous rendons Elevator implémentable, et vérifions et synchronisons constamment une file d'attente (linkedList). Une classe de contrôleur assignera quel étage aller dans la file d'attente. Lorsque la file d'attente est vide, la méthode run() attend (file d'attente.wait() ), lorsqu'un étage est attribué à cet ascenseur, il appelle file d'attente.notify () pour réveiller la méthode run (), et la méthode run () appellera goToFloor(queue.pop()). Cela rendra le problème est trop compliqué. J'ai essayé de l'écrire sur papier, mais ne le pensez pas travail. Il semble que nous n'ayons pas vraiment besoin de prendre en compte le problème de concurrence ou de synchronisation ici, mais nous devons en quelque sorte utiliser une file d'attente pour distribuer le contrôle.
Une suggestion?