Моделирование лифта с использованием объектно-ориентированного анализа и проектирования [закрыто]

Существует ряд вопросов, которые обычно используются в интервью и на уроках, когда дело доходит до объектно-ориентированного проектирования и анализа. Это один из них; к сожалению, мой профессор ООП в колледже так и не дал ответа, и мне было интересно.

Проблема заключается в следующем: спроектировать базовый набор объектов / методов, которые будут использоваться для моделирования банка лифтов. Каковы объекты и их атрибуты / методы?

Ради аргумента давайте предположим, что наше здание имеет двадцать этажей; нижний этаж - вестибюль, а второй этаж соединен с парковкой (поэтому люди будут входить / выходить из здания на нижнем или втором этаже). Есть один банк лифтов, который обслуживает все этажи; Есть три шахты лифта в банке лифта, и один лифт на шахту.

Каков будет правильный способ моделировать это в объектно-ориентированной модели?

Сначала есть лифт класса. Он имеет направление (вверх, вниз, стенд, обслуживание), текущий этаж и список запросов этажей, отсортированных по направлению. Он получает запрос от этого лифта.

Тогда есть банк. Он содержит лифты и получает запросы от этажей. Они запланированы для всех активных лифтов (не в обслуживании).

Планирование будет таким:

• если возможно, выберите стоящий лифт для этого этажа.
• еще выберите лифт, движущийся на этот этаж.
• еще выбрать стоящий лифт на другом этаже.
• еще подберите лифт с самой низкой нагрузкой.

Каждый лифт имеет набор состояний.

• Техническое обслуживание: лифт не реагирует на внешние сигналы (только на собственные сигналы).
• Стенд: лифт закреплен на полу. Если он получает звонок. И лифт на том этаже, двери открыты. Если он находится на другом этаже, он движется в этом направлении.
• Вверх: лифт движется вверх. Каждый раз, когда он достигает пола, он проверяет, нужно ли ему остановиться. Если это так, он останавливается и открывает двери. Он ждет определенное количество времени и закрывает дверь (если кто-то не проходит через них. Затем он удаляет этаж из списка запросов и проверяет, есть ли еще один запрос. Если это так, лифт снова начинает двигаться. Если нет, он входит в государственный стенд.
• Вниз: как вверх, но в обратном направлении.

Есть дополнительные сигналы:

• тревога. Лифт останавливается. А если он на полу, двери открыты, список запросов очищается, запросы возвращаются в банк.
• дверь открыта. Открывает двери, если лифт находится на полу и не движется.
• дверь закрывается. Закрытые двери, если они открыты.
  

РЕДАКТИРОВАТЬ: Некоторые лифты не начинаются с нижней / first_floor esp. в случае с небоскребами.

min_floor и max_floor - это два дополнительных атрибута для лифта.

Дональд Кнут, «Искусство компьютерного программирования», том 1, демонстрирует лифт и структуры данных. Кнут представляет очень подробное обсуждение и программу.

Кнут (1997) "Информационные структуры", Искусство компьютерного программирования, вып. 1 с.302-308

Я видел много вариантов этой проблемы. Одно из главных отличий (которое определяет сложность) заключается в том, существует ли какая-то централизованная попытка создать «умную и эффективную систему», которая бы обеспечивала балансировку нагрузки (например, отправлять больше неработающих лифтов в лобби утром). Если это так, то дизайн будет включать в себя целую подсистему с действительно интересным дизайном.

Полный дизайн, очевидно, слишком много, чтобы представить здесь, и есть много альтернатив. Ширина также не ясна. В интервью они попытаются выяснить, как вы думаете. Однако вот некоторые вещи, которые вам понадобятся:

1. Представление центрального контроллера (при условии, что есть один).

2. Представления лифтов

3. Представления интерфейсных блоков лифта (они могут отличаться от лифта к лифту). Очевидно также кнопки вызова на каждом этаже и т. Д.

4. Изображения стрелок или индикаторов на каждом этаже (почти «вид» модели лифта).

5. Представление человека и груза (может быть важно для учета максимальных нагрузок)

6. Представление здания (в некоторых случаях, поскольку некоторые этажи могут быть заблокированы время от времени, и т. Д.)

Видеть:

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

ссылка на сайт

Подробный ответ:

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

Что следует учитывать при проектировании лифтовой системы,

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

Каждое нажатие кнопки приводит к запросу лифта, который должен быть обслужен. Каждый из этих запросов отслеживается в глобальном месте

Количество лифтов в здании будет определяться пользователем. Здание будет содержать фиксированное количество этажей. Количество пассажиров, которые могут поместиться в лифте, будет фиксированным. Пассажиры будут учтены при выходе из лифта на этаже их назначения. Этаж назначения будет определяться с использованием «случайного» интервала Пуассона. Когда все пассажиры в лифте достигнут этажей своего назначения, лифт вернется в вестибюль, чтобы забрать больше пассажиров

Главное, о чем нужно беспокоиться, это как бы вы уведомили лифт о том, что он должен двигаться вверх или вниз. а также, если вы собираетесь иметь централизованный класс для управления этим поведением и как вы могли бы распределить контроль.

Кажется, что это может быть очень просто или очень сложно. Если мы не берем параллелизм или время, чтобы лифт добирался до одного места, то кажется, что это будет просто, поскольку нам просто нужно проверить состояния лифта, например, движется ли он вверх или вниз или стоит на месте. Но если мы заставим Elevator реализовать Runnable и постоянно проверять и синхронизировать очередь (connectedList). Класс Controller назначит, какой этаж идти в очереди. Когда очередь пуста, метод run () будет ждать (queue.wait ()), когда этаж назначен этому лифту, он вызовет queue.notify (), чтобы разбудить метод run (), и запустить ( ) вызовет метод goToFloor (queue.pop ()). Это сделает проблему слишком сложной. Я пытался написать это на бумаге, но не думаю, что это работает. Кажется, что нам не нужно принимать во внимание проблему параллелизма или синхронизации,

Любое предложение?