Modélisation d'un ascenseur à l'aide D'une analyse et D'une conception orientées objet [fermé]
Il y a un ensemble de questions qui semblent être couramment utilisées dans les interviews et les cours en matière de conception et d'analyse orientées objet. C'est l'un d'entre eux; malheureusement, mon professeur de POO au collège n'a jamais vraiment donné de réponse, et je me demandais donc.
Le problème est le suivant: concevoir un ensemble de base d'objets / méthodes à utiliser pour simuler une banque d'ascenseur. 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 soit à l'étage inférieur 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 arbre.
Quelle serait la bonne façon de modéliser cela dans un modèle orienté objet?
7 réponses
D'abord, il y a une classe d'ascenseur. Il a une direction (Haut, Bas, Support, entretien), 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 prévus 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 qui se déplace à cet étage.
- sinon choisir un ascenseur debout sur 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. Si elle est sur un autre étage, il se déplace dans ce direction.
- 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 laps de temps et ferme la porte (à moins que quelque chose ne se déplace à travers eux. Ensuite, il supprime le sol 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 le stand 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 à bottom / first_floor esp. en cas de gratte-ciel.
Min_floor & max_floor sont deux attributs supplémentaires pour Elevator.
Donald Knuth L'Art de la Programmation Informatique, Vol.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) "Information Structures", The Art of Computer Programming Vol. 1 pp. 302-308
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 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 pour faire du lobbying 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 pensez. 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.
Les Représentations des flèches ou des indicateurs sur chaque étage (presque une " vue " du modèle d'ascenseur).
-
Représentation d'un homme et d'une cargaison (peut être important pour la prise en compte des charges maximales)
Représentation du bâtiment (dans certains cas, certains étages peuvent parfois être bloqués, etc.)
Chose à considérer tout en concevant 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 de 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 comme ils quittent l'ascenseur à leur plancher de destination. Le plancher de destination sera déterminé à l'aide d'un intervalle de Poisson" aléatoire". Lorsque tous les passagers de 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 notifier 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 un ascenseur d'arriver à un endroit, alors il semble que ce sera simple puisque nous avons juste besoin de vérifier les états de l'ascenseur, comme est-ce qu'il se déplace vers le haut ou vers le bas, ou encore debout. Mais si nous rendons L'implémentation D'Ascenseur exécutable, et 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 (file d'attente.wait ()), lorsqu'un étage est affecté à cet ascenseur, il appelle la file d'attente.notify() pour réveiller la méthode run (), et la méthode run() appellera gotofloor (file d'attente.pop()). Cela rendra le problème est trop compliqué. J'ai essayé de l'écrire sur papier, mais ne le pense pas travail. Il semble que nous n'ayons pas vraiment besoin de prendre en compte la concurrence ou le problème de synchronisation ici, mais nous devons en quelque sorte utiliser une file d'attente pour distribuer le contrôle.
Une suggestion?