Modélisation d’un ascenseur à l’aide de l’parsing et de la conception orientées object

Il existe un ensemble de questions qui semblent être couramment utilisées dans les entretiens et les cours en matière de conception et d’parsing orientées object. C’est l’un d’eux; Malheureusement, mon professeur de POO à l’université n’a jamais vraiment répondu, et je me suis donc demandé.

Le problème est le suivant: concevoir un ensemble de base d’objects / méthodes à utiliser pour simuler une banque d’ascenseurs. Quels sont les objects et leurs atsortingbuts / méthodes?

Par souci d’argument, supposons que notre bâtiment compte vingt étages; le rez-de-chaussée est le hall et le deuxième étage se connecte au parking (par conséquent, les gens entreront / sortiront du rez-de-chaussée ou du deuxième étage). Il y a une banque d’ascenseurs qui dessert tous les étages. il y a trois cages d’ascenseur dans la banque d’ascenseurs et un ascenseur par puits.

Quelle serait la manière correcte de modéliser ceci dans un modèle orienté object?

Il y a d’abord une classe d’ascenseur. Il a une direction (haut, bas, stand, maintenance), un étage actuel et une liste de demandes d’étage sortingées dans la direction. Il reçoit une demande de cet ascenseur.

Ensuite, il y a une banque. Il contient les ascenseurs et reçoit les demandes des étages. Celles-ci sont programmées pour tous les ascenseurs actifs (non en maintenance).

La planification sera comme:

  • si disponible, choisissez un ascenseur pour cet étage.
  • Sinon, choisissez un ascenseur qui se déplace vers cet étage.
  • sinon, prenez 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 sol. S’il reçoit un appel. Et l’ascenseur est à cet étage, les portes s’ouvrent. Si c’est sur 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 un certain temps et ferme la porte (à moins que quelque chose ne les traverse. Ensuite, il supprime le sol de la liste de demandes et vérifie s’il y a une autre demande. Si c’est le cas, l’ascenseur commence à se déplacer. stand de l’Etat.
  • 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 plancher, 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 sol et ne bouge pas.
  • la porte se ferme. Fermé la porte si elles sont ouvertes.

EDIT: Certains ascenseurs ne commencent pas à bottom / first_floor esp. en cas de gratte-ciel.

min_floor & max_floor sont deux atsortingbuts supplémentaires pour Elevator.

J’ai vu beaucoup de 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” capable d’équilibrer la charge (par exemple, envoyer plus d’ascenseurs inactifs pour faire du lobbying dans la matinée). Si tel est le cas, la conception comprendra un sous-système complet avec un design vraiment amusant.

Un design complet est évidemment trop pour présenter ici et il y a beaucoup d’altenatifs. La largeur n’est pas claire non plus. Dans une interview, ils essaieront de comprendre comment vous penseriez. Cependant, voici certaines des choses dont vous auriez besoin:

  1. Représentation du contrôleur central (en supposant qu’il en existe un).

  2. Représentations des ascenseurs

  3. Représentations des unités d’interface de l’ascenseur (celles-ci peuvent être différentes d’un ascenseur à l’autre). De toute évidence, appelez également des boutons à chaque étage, etc.

  4. Représentations des flèches ou des indicateurs sur chaque étage (presque une “vue” du modèle d’ascenseur).

  5. Représentation d’un être humain et d’une cargaison (peut être important pour la prise en compte des charges maximales)

  6. Représentation du bâtiment (dans certains cas, certains étages peuvent être bloqués parfois, etc.)

The Art of Computer Programming Vol.1 de Donald Knuth 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

Voir:

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

lien

Chose à considérer lors de la conception du 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 fixe. Les passagers seront comptés lorsqu’ils quitteront l’ascenseur à leur étage de destination. L’étage de destination sera déterminé en utilisant un intervalle de Poisson “aléatoire”. Lorsque tous les passagers de l’ascenseur auront atteint leur étage de destination, l’ascenseur retournera dans le hall pour prendre plus de passagers.

La principale chose à craindre est de savoir comment vous prévenez 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 vous pouvez dissortingbuer 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 un ascenseur pour arriver à un endroit, alors il semble que ce soit simple puisque nous avons juste besoin de vérifier l’état de l’ascenseur, comme s’il montait ou descendait ou restait immobile. Mais si nous faisons qu’Elevator implémente Runnable, et vérifie et synchronise constamment une queue (linkedList). Une classe de contrôleur atsortingbuera le sol à placer dans la queue. Lorsque la queue est vide, la méthode run () attendra (queue.wait ()), lorsqu’un étage est assigné à cet ascenseur, il appellera queue.notify () pour activer la méthode run () et exécuter ( ) méthode appellera goToFloor (queue.pop ()). Cela compliquera le problème. J’ai essayé de l’écrire sur papier, mais je ne pense pas que cela fonctionne. Il semble que nous n’ayons pas vraiment besoin de prendre en compte les problèmes de concurrence ou de synchronisation, mais nous avons besoin d’utiliser une queue pour dissortingbuer le contrôle.

Toute suggestion?