Modélisation d'un ascenseur à l'aide de l'analyse et de la conception orientées objet [fermé]

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'analyse orientées objet. C'est l'un d'eux; Malheureusement, mon professeur de POO à l'université n'a jamais vraiment donné de réponse, et je me suis donc posé la question.

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 les besoins de l'argumentation, supposons que notre immeuble a 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 bâtiment soit au rez-de-chaussée, soit 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 banque d'ascenseurs et un ascenseur par cage.

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

Il y a d'abord une classe d'ascenseur. Il a une direction (haut, bas, stand, entretien), un étage actuel et une liste de demandes d'étage triées dans le sens. 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 prévus pour tous les ascenseurs actifs (pas en maintenance).

La planification sera comme:

• si disponible, choisissez un ascenseur debout pour cet étage.
• sinon choisissez un ascenseur qui se déplace à 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é à un étage. S'il reçoit un appel. Et l'ascenseur est à cet étage, les portes s'ouvrent. S'il se trouve à 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 l'étage de la liste des demandes et vérifie s'il y a une autre demande. Si tel est le cas, l'ascenseur recommence à bouger. Sinon, il entre dans le stand de l'état.
• Bas: comme vers le 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 ramenées à la banque.
• porte ouverte. Ouvre les portes si un ascenseur est à un étage et ne bouge pas.
• la porte se ferme. Fermé la porte si elles sont ouvertes.
  

EDIT: Certains ascenseurs ne démarrent pas en bas / premier étage esp. en cas de gratte-ciel.

min_floor et max_floor sont deux attributs supplémentaires pour Elevator.

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 de l'information", L'art de la programmation informatique Vol. 1 pages 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 inactifs au lobby le matin). Si tel est le cas, la conception comprendra un sous-système complet avec un design vraiment amusant.

Un design complet est évidemment trop à présenter ici et il existe de nombreuses alternatives. L'ampleur n'est pas non plus claire. Dans une interview, ils essaieront de comprendre comment vous penseriez. Cependant, voici quelques-unes des choses dont vous auriez besoin:

1. Représentation du contrôleur central (en supposant qu'il y en ait 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). Evidemment aussi des boutons d'appel à chaque étage, etc.

4. Représentations des flèches ou indicateurs à chaque étage (presque une «vue» du modèle d'ascenseur).

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

6. 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

lien

Réponse détaillée:

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

Points à 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 quittent l'ascenseur à leur é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 prendre plus de passagers

La principale préoccupation 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 pour qu'un ascenseur se rende à un endroit, alors il semble que ce sera simple car nous devons juste vérifier l'état de l'ascenseur, comme s'il monte ou descend, ou s'il est immobile. Mais si nous faisons en sorte qu'Elevator implémente Runnable, vérifions et synchronisons constamment une file d'attente (linkedList). Une classe de contrôleur attribuera à quel étage aller 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 appellera queue.notify () pour réveiller la méthode run (), et exécutera ( ) appelle goToFloor (queue.pop ()). Cela rendra le problème trop compliqué. J'ai essayé de l'écrire sur papier, mais je ne pense pas que cela fonctionne. Il semble que nous n'avons pas vraiment besoin de prendre en compte les problèmes de concurrence ou de synchronisation ici,

Toute suggestion?