Как сложную релейную схему преобразовать в мир ООП

[RAFA91]

Добрый день !

Если на форуме есть программисты железнодорожники , то поймут о чем речь.

В общем нужно релейную систему управления движения поездов на станции преобразовать в технологию ООП.

В этой системе есть функционально законченные релейные блоки, которые за что-то отвечают.

Стрелки, светофоры, участки.

Проблемы описать каждый блок в виде класса, труда не составляет.

Основная проблема заключается в разработке взаимодействия обьектов этих классов с точки зрения ООП.

При определенном маршруте взаимодействуют, определенные обьекты.

Может кто подкинет разумные идейки , как это можно правильно реализовать.

Нюансов очень много, поэтому задача не совсем простая.

[evg_m]

Маршрут ЕСТЬ объект
ЗНАЮЩИЙ о ВСЕХ своих "элементарных" (и не очень) объектах и О ПРАВИЛЬНОМ их состоянии для своей готовности.
значит он может
УЗНАТЬ их состояние,
ПРИНЯТЬ решение о возможности/невозможности продолжения работы
и ПОВЛИЯТЬ на это состояние в соответствии со СВОИМИ требованиями.

Объекты В СВОЮ очередь могут ОТКАЗАТЬСЯ принимать состояние указанное маршрутом, если ОНО(новое состояние) почему либо неприемлемо и могут (или должны?) УВЕДОМИТЬ об этом МАРШРУТ.

готовность маршрута == правильное состояние ВСЕХ его подсистем(объектов)!!!

Объект (НЕ МАРШРУТ) имеет право знать
в КАКОЙ МАРШРУТ он включен(он ВЕДЬ только один(или НОЛЬ) в любой момент времени)
и МОЖЕТ(ОБЯЗАН) уведомить маршрут о ЛЮБОМ КРИТИЧНОМ СВОЕМ изменении (с указанием КТО(какой объект) изменился).
Маршрут в свою очередь рассмотрев эти изменения принимает решения об изменении СВОЕГО состояния.

по окончании работы маршрут ОБЯЗАН (в случае если объекты хранят данных о маршруте) УВЕДОМИТЬ все объекты о завершении (потребовать(!) удаления своих ссылок, а не удалЯть их самому).

[RAFA91]

В общем я мыслил так.

Прописую все возможные маршруты на станции в какой-то контейнер.

Что является элементами маршрута.

1. стрелки
2. участки.
3. светофоры

В свою очередь стрелки входят в конкретные участки.
Маршрут ограждается светофором.
Светофор открывается на разрешающие показание только когда маршрут готов с
проверкой условий безопасности.

Хрен его знает как это все увязать. Как работает система вроде знаю.

Пускай у меня есть на все обьекты указатели.

[Utkin]

Я бы выбрал агентную модель, когда каждый элемент сам себе объект и в какой-то квант времени опрашивается их состояние. Вообще в AnyLogic есть готовый набор для железнодорожного моделирования. А для своего функционала есть возможность заюзать Ява. У меня курсач как раз по жд был в AnyLogicе.

Если на форуме есть программисты железнодорожники

Конечно, а еще:
программисты-проктологи
программисты-дворники
программисты-летчики

Основная проблема заключается в разработке взаимодействия обьектов этих классов с точки зрения ООП.

Один объект вызывает методы другого. В чем проблема-то? Можно глобальный объект, который "будет знать" от кого кому что отправлять. Где-нибудь во внешнем файле делаются связи - типа объект1 связь объект2, а глобальный объект тупо исполняет и выводит состояние системы.

[RAFA91]

да не. надо решить эту проблему без этих прог.

На освоение этой проги уйдет куча времени, чем найдется альтернативное решение.

[Utkin]

На освоение этой проги уйдет куча времени, чем найдется альтернативное решение.

Ну дело Ваше (там еще есть набор готовых моделек для обучения). Ну все остальное в силе - есть куча объектов с независимым состоянием и есть главный дирижер оркестра, который работает по бумажке. Примерно так можно.

[RAFA91]

Благодарю за краткий обзор этой проги - но это не то.

Надо в голове придумать альтернативное решение

[Utkin]

Благодарю за краткий обзор этой проги - но это не то.

Я счас не про программу писал, а про то, как это сделать своими руками и вообще как в принципе часто это делается. То что Вы хотите называется имитационное моделирование, у него есть несколько способов создания моделей. Под каждую задачу обычно выбирается соответствующая модель. Под Ваш случай наиболее подходит агентное моделирование - то что написано в предыдущем посте.

[RAFA91]

мне нужна идея в виде человеческого набора слов и все без этих стимуляторов.

по большему счету типов обьектов не так то и много .

много только их в количественном виде.

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

маршрутов очень много и к каждому присуши свои особенности.

- размыкание

- замыкание

- контроль

- безопасность

и т.д.

ох и сложная задача

[Utkin]

ох и сложная задача

Чего там блин сложного?
Вся система срабатывает как сумма показателей каждого объекта (например). То есть если хотя бы один объект говорит "нет" значит система не готова.
Давайте один объект возьмем. Например стрелка. У нее 2 состояния - открыто/закрыто (или право/лево, пофиг). Одно состояние разрешает, другое запрещает движение, верно? Вы же не поедите туда куда не надо по маршруту? Цепочка всех этих состояний характеризует в целом как "маршрут готов" или "ехать нельзя". Ну вот создаете класс "диспетчер", его задача отправлять запрос о состоянии объектов. Эти состояния он например сравнивает с текстовым файлом (где например написано - стрелка влево или состояние машиниста "трезв"). Вот он как диспетчер суммирует все показания. Как только есть отклонение, значит ехать нельзя.

все без этих стимуляторов.

Без стимуляторов нельзя. Умные дядьки много курили всякой разной травы, изобретали всевозможные велосипеды с турбореактивными двигателями и пробовали все виды грабель, вил и костылей. И внезапно все давно продумали и испробовали. Вы вместо того чтобы взять выводы, хотите пройти по их пути и в результате все равно придти к их выводам (а иначе модель не получится). Так нафига? Это дураки учатся на своих ошибках, а умные должны учиться на чужих. И потом шествие по их пути затратное по времени дело, а прочитать и понять выводы намного быстрей и безопасней (для модели).