Содержание к диссертации
Введение
Глава 1. Обзор средств моделирования трансопртных систем 9
1.1. Имитационное моделирование транспортных систем 9
1.1.1. Транспортные системы 9
1.1.2. Язык моделирования 10
1.2. Низкоуровневое моделирование транспортных систем 11
1.3. Применение агентного моделирования 12
1.4. Способы создания имитационных моделей транспортных систем 13
1.5. Средства моделирования общего назначения 15
1.5.1. Разработка моделей в среде RePAST 15
1.5.2. Разработка моделей в AnyLogic 6 16
1.6. Проблемно-ориентированные средства моделирования 18
1.6.1. Разработка моделей в VISSIM 18
1.6.2. Разработка моделей с помощью TransportLibrary AnyLogic 5 20
1.7. Сравнение подходов к разработке моделей транспортных систем 23
1.8. Выводы 25
Глава 2. Архитектура системы моделирования ТС 27
2.1. Обоснование выбора AnyLogic 6 27
2.2. Структура системы 28
2.3. Сценарий использования системы 30
2.4. Графический конструктор моделей 32
2.4.1. Представление модели в виде документа 34
2.4.2. Конструирование модели в графическом конструкторе 34
0г 2.4.3. Задание светофоров и направлений движения по полосам 39
2.4.4. Задание потоков 41
2.4.5. Модуль синтаксической проверки : 42
2.5. Модуль калибровки 43
2.6. Формирование среды обитания агентов 44
2.7. Исполнение модели 45
2.8. Результаты экспериментов 46
2.9. Расширяемость системы 48
2.10. Среда взаимодействия агентов 49
2.10.1. Общая структура среды взаимодействия агентов 49
2.10.2. Представление информации о дорожной сети в форме графа 50
2.10.3. Информация о приоритетах агентов 53
2.11. Выводы 53
Глава 3. Графический язык моделирования транспортных систем 55
3.1. Обоснование необходимости разработки языка 55
3.2. Анализ предметной области 56
3.3. Общая структура языка 59
3.4. Элементы языка 60
3.5. Правила композиции элементов языка 63
3.5.1. Основное правило композиции элементов языка 63
3.5.2. Дополнительные правила композиции 65
3.6. Формальное описание конструкций языка 68
3.7. Выводы 69
Глава 4. Программная реализация 71
4.1. Особенности программной среды AnyLogic 71
4.1.1. Общая структура среды моделирования AnyLogic 71
4.1.2. Активные объекты AnyLogic 75
4.1.3. Исполняющий модуль AnyLogic - обработка событий 75
4.1.4. Презентация - визуализация моделей AnyLogic 77
4.1.5. Эксперименты в AnyLogic 78
4.1.6. Библиотеки AnyLogic 79
4.1.7. Подключение внешних jar-файлов 80
4.2. Особенности реализации, обусловленные программной средой 81
4.3. Графический конструктор 82
4.3.1. Реализация светофорного регулирования 85
4.3.2. Реализация вспомогательных элементов конструктора 86
4.3.3. Генерация программной среды обитания агентов 89
4.4. Дополнительные возможности системы 90
4.4.1. Сериализация модели 90
4.4.2. Реализация отмены и повторения изменений 91
4.4.3. Остановка в заданное время 91
4.5. Библиотека пользовательского ввода 92
4.5.1. Требования к библиотеке 93
4.5.2. Классы библиотеки 94
4.5.3. Использование библиотеки 96
4.6. Выводы 97
Основные результаты работы 99
Список литературы 100
- Применение агентного моделирования
- Графический конструктор моделей
- Основное правило композиции элементов языка
- Генерация программной среды обитания агентов
Введение к работе
Актуальность исследования
Компьютерное моделирование становится распространенным средством анализа сложных систем. Современный рынок внедрения и сопровождения технологических систем часто требует разработки систем поддержки принятия стратегических и оперативных решений на основе имитационных моделей. Так, низкоуровневое имитационное моделирование (ИМ) все чаще применяется при принятии решений о проектировании и реорганизации транспортных систем1 (ТС).
Выделяют два подхода к разработке имитационных моделей транспортных систем: использование сред моделирования общего назначения и проблемно-ориентированных инструментов2.
Использование систем общего назначения предоставляет разработчикам больше возможностей, однако обладает рядом ограничений:
моделирование (например, в RePast, Simio) предполагает более глубокую декомпозицию моделируемого объекта, сведение его элементов и подсистем к сущностям используемого в инструменте языка моделирования, что мешает построить модель без привлечения специалистов по ИМ;
инструменты не содержат конструкционных элементов, необходимых для моделирования транспортных систем, из-за чего, например, в TransportLibrary AnyLogic 5 необходимо явно указывать траектории движения агентов.
Проблемно-ориентированные системы лишены этих недостатков, но их использование сопряжено с другими трудностями:
прикладные разработчики ограничены стандартным набором композиционных элементов (например, в Sidralntersection), расширение которого трудоемко и предполагает обращение к разработчикам инструмента;
невозможно исследовать ТС в составе моделей других организационно-технических систем;
1 Yafeng Yin, Henry X. Liu, Jorge A. Laval, Xiao-Yun Lu, Meng Li, Joshua Pilachowski, Wei-Bin
Zhang Development of an Integrated Microscopic Traffic Simulation and Signal Timing Optimization Tool /
University of California, Berkeley, 2007
2 ZOU Zhi-jun, YANG Dong-yuan An Object-oriented Development of Urban Traffic Simulation
Laboratory System / Journal of system simulation, vol. 14, no. 7, 2002, pp. 844-848
исследователи также ограничены в возможностях представления процессов
и результатов моделирования, не могут отойти от навязываемого системой
подхода.
Таким образом, представляется целесообразным совместить эти два подхода, создав расширяемую систему низкоуровневого агентного имитационного моделирования транспортных узлов, ориентированную с одной стороны на специалистов предметной области, а с другой - на профессионалов-имитационщиков, имеющих возможность расширять ее функциональность.
Основной проблемой при разработке требуемой системы на основе среды моделирования общего назначения является отсутствие проблемно-ориентированного языка моделирования. Именно этот язык и служит основой ориентированности на специалистов предметной области. Предметная ориентированность, с одной стороны, и расширяемость - с другой должны стать основными факторами, принимаемыми во внимание при декомпозиции предметной области«гранспортные системы).
Объектом исследования в данной работе является система низкоуровневого имитационного моделирования ТС и её язык.
Предметом исследования является внутренняя структура транспортных систем, формальное описание языка и архитектура программного комплекса для низкоуровневого моделирования ТС.
Цель и задачи работы
Целью работы является расширение сферы применения моделирования транспортных систем за счет создания проблемно-ориентированного средства на основе средства моделирования общего назначения.
Для достижения поставленной цели в работе решены следующие задачи:
Разработана структура системы низкоуровневого имитационного моделирования ТС.
Проведена декомпозиция предметной области «транспортные системы), выявлены её особенности с точки зрения структуры имитационных моделей.
Создан язык моделирования транспортных систем.
Создан графический редактор конструкций языка и программный интерфейс для выполнения агентных моделей транспортных систем.
Методы исследования
В ходе исследования применялись методы системного анализа, имитационного моделирования и теории графов. При программной реализации
системы моделирования использовались методы структурного и объектно-ориентированного программирования.
Научная новизна
В работе предложена новая структура расширяемой системы низкоуровневого имитационного моделирования ТС. Предложенная структура позволяет комбинировать преимущества проблемно-ориентированных инструментов и средств общего назначения. На основе предложенного способа декомпозиции разработан язык моделирования ТС. Также разработан новый программный комплекс для низкоуровневого моделирования транспортных систем.
Основные положения, выносимые на защиту
Структура системы низкоуровневого имитационного моделирования ТС, обеспечивающая расширяемость и ориентированность на специалистов в предметной области.
Метод декомпозиции транспортных систем, ориентированный на имитационное моделирование и позволивший систематизировать множество объектов транспортной инфраструктуры.
Язык моделирования и численные методы анализа структуры моделей транспортных систем.
Программный комплекс, состоящий из графического редактора моделей, программного интерфейса для исполнения агентных моделей транспортных систем и вспомогательных модулей.
Достоверность результатов
Достоверность результатов, полученных в работе, достигается корректностью применения методов системного анализа, однозначностью разработанных алгоритмов и подтверждается результатами компьютерного моделирования и тестирования разработанного программного комплекса. Результаты исследования обсуждались на российских и международных конференциях.
Теоретическая и практическая значимость
Проведенная декомпозиция предметной области «транспортные системы), и созданное формальное описание языка позволит использовать данные геоинформационных систем для построения имитационных моделей.
Разработан программный комплекс низкоуровневого имитационного моделирования транспортных систем, позволяющий анализировать свойства
существующих и проектируемых транспортных узлов. Комплекс совмещает достоинства средств моделирования общего назначения и проблемно-ориентированных инструментов. Созданный комплекс может быть использован в муниципальных образованиях, проектных организациях и консалтинговых компаниях, занимающихся проектированием и реорганизацией схем дорожного движения.
Апробация работы
Основные результаты исследования были апробированы на конференциях:
VII Международной конференции «Математическое моделирование физических, экономических, технических систем и процессов), Ульяновск, УлГУ, 2009;
Interactive Systems and Technologies: the Problems of Human-Computer Interaction, Ulyanovsk, ULSTU, 2009;
Четвертая всероссийская научно-практическая конференция по имитационному моделированию и его применению в науке и промышленности (ИММОД-2009), Санкт-Петербург, 2009;
Всероссийская конференция «Проведение научных исследований в области обработки, хранения, передачи и защиты информации) (ОИ-2009), Ульяновск, УлГТУ, 2009;
Winter Simulation Conference (Ph. D. Colloquium), Austin, TX, USA, 2009;
Информатика, моделирование, автоматизация проектирования. (ИМАП-2010), Ульяновск, 2010.
Личный вклад автора
Постановка задачи выполнена автором самостоятельно при методической поддержке научного руководителя. Создание программного комплекса, разработка языка и структуры системы, а также тестирование выполнены автором самостоятельно.
Публикации
Материалы диссертации опубликованы в 11 работах, из них 2 - в изданиях, рекомендуемых ВАК. Список публикаций приведен в конце автореферата.
Структура и объем диссертации
Применение агентного моделирования
Выделяют два подхода к разработке имитационных моделей транспортных систем: использование сред моделирования общего назначения и проблемно-ориентированных инструментов.
Использование систем общего назначения предоставляет разработчикам больше возможностей, однако обладает рядом ограничений: моделирование (например, в RePAST[73], Simio[43]) предполагает более глубокую декомпозицию моделируемого объекта, сведение его элементов и подсистем к сущностям используемого в инструменте языка моделирования, что мешает построить модель без привлечения специалистов по имитационному моделированию; инструменты не содержат конструкционных элементов, необходимых для моделирования движения автотранспорта, из-за чего, например, в TransportLibrary AnyLogic 5 [41] необходимо явно указывать траектории движения автомобилей.
Проблемно-ориентированные системы лишены этих недостатков, но их использование сопряжено с другими трудностями: прикладные разработчики часто ограничены стандартным набором композиционных элементов (например, в SidraIntersection[34]), расширение которого трудоемко и предполагает обращение к разработчикам инструмента; исследователи также ограничены в возможностях представления процессов и результатов моделирования, не могут отойти от навязываемого системой подхода. В настоящее время существуют несколько средств низкоуровневого моделирования транспортных систем:
VISSIM[35] - разработка немецкой фирмы PTV Systems. Позволяет строить низкоуровневые модели транспортных систем, состоящих из участков дороги, перекрестков любой формы, многоуровневых развязок. Основной особенностью является отображение трехмерной анимации в ходе моделирования.
Transmodeler [36] - разработка фирмы Caliper из США. Позволяет интегрировать модели транспортных систем с данными геоинформационных систем и предназначена в основном для моделирования движения по шоссе и сложным развязкам. Ориентирована на особенности дорожного движения в США.
SIDRA Intersection - разработка фирмы SidraSolutions. Позволяет моделировать поведение участников дорожного движения на перекрестках и прилегающих к ним территориях, обладает мощными средствами сбора и анализа статистики состояния модели.
Transport Library AnyLogic 5 - разработка отечественной компании Экс Джей Текнолоджис. Главной особенностью является возможность сочетать модели транспортной системы с другими имитационными моделями. Обладает богатыми возможностями настройки анимации.
RePAST - это среда агентного моделирования, основанная на платформе Eclipse. Она предоставляет разработчику модели исполняющий модуль, который управляет модельным временем и позволяет планировать и выполнять события модели. Обработчики событий модели могут быть заданы в форме диаграмм действий. RePAST содержит специальные расширения среды Eclipse, позволяющие визуально задавать отдельные места логики модели.
Среда RePAST не предусматривает специальных средств задания траекторий движения агентов в пространстве. Поэтому задавать траектории приходится с помощью языка программирования Java [16], что значительно усложняет разработку моделей транспортных систем.
Отсутствие каких-либо предопределенных функциональных блоков в среде делает её гибким средством разработки моделей, не ограничивая разработчиков теми или иными подходами. Однако воспользоваться предоставляемой гибкостью могут лишь специалисты, имеющие значительный опыт в программировании, так как большинство аспектов модели приходится разрабатывать на языке Java.
Существенным недостатком среды RePAST является отсутствие встроенных средств визуализации моделей. Визуальное представление модели также приходится программировать, то есть программно управлять геометрическими примитивами.
Ввиду того, что RePAST не обладает богатыми возможностями визуализации, но является гибким средством агентного моделирования он находит применение при разработке моделей больших клеточных автоматов, в которых делается упор на высокую производительность.
AnyLogic 6 [41] - это среда имитационного моделирования, поддерживающая несколько подходов к построению моделей. Она реализует некоторые универсальные языки моделирования - диаграммы состояний, диаграммы действий и др. В среде AnyLogic также поддерживается агентный подход к моделированию.
Разработка модели агента базируется на программном интерфейсе, предоставленным классом Agent. На уровне ядра системы поддерживается перемещение агентов вдоль прямых. Логика поведения агента может разрабатываться как с помощью языка программирования Java, так и с помощью визуальных средств. Программирование упрощено путем визуализации функций и переменных модели. Для того чтобы разработать модель транспортной системы, необходимо задать возможные траектории движения агентов в виде ломанных. Внешний вид фрагмента разрабатываемой модели представлен на рисунке 1.1.
Графический конструктор моделей
Графический конструктор содержит модуль синтаксической проверки. Основная часть модуля - процедура синтаксической проверки разрабатываемой пользователем модели. Внешне работа модуля синтаксической проверки проявляется в форме предупреждений о некорректностях в модели. Модуль может функционировать в двух режимах: Автоматическая проверка корректности конструкции при каждом её изменении. Такой режим может быть полезен при модификации существующих моделей транспортных систем, чтобы контролировать корректность вносимых в нее изменений.
Проверка синтаксиса конструкций по команде пользователя. Этот режим полезен на начальных этапах разработки моделей транспортных систем, так как в начале разработки модель содержит много некорректностей, устраняемых по мере её модификации.
Основной функцией модуля синтаксической проверки является проверка корректности модели перед запуском. Синтаксически некорректная модель не может быть запущена, о чем будет сообщено пользователю при- попытке запустить модель, если она содержит ошибки.
Следующим этапом моделирования является калибровка модели, сводящаяся в случае с мелкомасштабным моделированием транспортных систем к настройке параметров участников движения. В среде выбран агентный подход к моделированию [15], при котором поведение модели складывается из взаимодействия однотипных агентов (участников движения) между собой и со статической средой обитания агентов (совокупностью объектов транспортной инфраструктуры). Центральным элементом модели является класс агента, обладающий набором параметров. Каждый параметр характеризуется названием и функцией распределения, в общем случае зависящей от других параметров. Агент-участник движения является экземпляром класса агента с конкретным набором значений параметров, выбранных согласно заданным в классе распределениям. Таким образом, настройка параметров участников движения производится путем задания функций распределения значений параметров класса агента.
Для задания распределений параметров класса агента могут быть использованы как справочные данные, так и данные, полученные путем наблюдения за движением транспорта на контрольных участках дорог [60, 72].
После задания структуры модели и ее калибровки можно приступать к проведению экспериментов.
Формирование среды обитания агентов Модуль формирования среды обитания агентов преобразует модель транспортной системы, заданную пользователем в графическом конструкторе, во внутреннее представление, которое использует исполняющий модуль AL для запуска агентной модели (Рисунок 2.11).
Внутреннее представление - это совокупность программных сущностей, составляющих программную среду функционирования агентов имитационной модели. С точки зрения структуры эта среда представляет собой граф транспортной системы, вершинам и ребрам которого сопоставлена информация о соответствующих участках дорожной сети.
Преобразование конструкций графического языка в элементы среды обитания агентов является необходимым для запуска моделирования.
Запуск эксперимента переводит среду в режим исполнения модели, при котором отображается анимация, представляющая собой двухмерный план моделируемой системы с движущимися по ней автотранспортными средствами (рисунок 2.12). Во время исполнения модели исследователю доступны следующие действия: увеличение и уменьшение скорости моделирования (отношения количества единиц модельного времени к количеству единиц реального времени); остановка и возобновление моделирования; просмотр информации о каждом участнике движения, отображаемом на анимации; просмотр текущих данных о загрузке отдельных участков дорог и скорости движения на них.
После окончания эксперимента данные, собранные в ходе его выполнения, записываются в базу данных, из которой они могут быть экспортированы в приложения, предназначенные для их анализа и визуализации (например, MS Excel). В зависимости от настроек среды в течение моделирования могут собираться различные данные: среднее время нахождения участников движения на заданных участках. Система поддерживает два уровня сбора статистики: на первом уровне собирается общая информация об агентах (тип, маршрут, время жизни) и информация о прохождении агентами узлов дорожной сети (время и скорость прохождения). Высокоуровневая статистика позволяет оценить пропускную способность участков и среднее время движения агентов по маршруту.
Сбор статистики на низком уровне требует большого обмена данными с базой, что может значительно замедлить работу моделей. Поэтому в системе может активизироваться сбор низкоуровневой статистики лишь для отдельных агентов. Это позволит исследователям концентрировать свое внимание лишь на важных параметрах транспортной системы. На низком уровне в базу данных выводятся информация о скорости и ускорении агента за период его нахождения в системе с определенной дискретностью.
Эти данные позволяют рассчитывать средние скорости агентов на определенных участках, количество остановок, среднее ускорение агента и т.д. Агрегация накопленных данных как с помощью стандартных запросов к базе данных, так и с помощью внешних средств позволяет представить информацию о проведенном эксперименте в виде таблиц, графиков и диаграмм.
Одной из целей моделирования является сбор статистической информации о загруженности участков дорожной системы. Поэтому статистическую информацию, накапливаемую в модели, удобно представлять в виде характеристик некоторых участков дороги. Такой подход позволяет, например, легко визуализировать состояние транспортной системы. Таким образом, сущности, находящиеся в ребрах графа, содержат статистические данные о средней скорости агентов, проезжающих по участку.
Основное правило композиции элементов языка
Для создания системы моделирования была выбрана среда AnyLogic 6. Она, как и многие среды моделирования общего назначения, не включает в себя проблемно-ориентированных конструкционных блоков. В частности, в выбранной среде нет блоков, ориентированных на моделирование транспортных систем.
В то же время ориентация на специалистов в предметной области диктует необходимость разработки моделей с использованием блоков, отражающих сущности моделируемой системы. Это позволит разработчикам моделей не тратить ресурсы на излишнее абстрагирование при создании моделей и затем на конкретизацию абстрактной модели для ее визуализации. Кроме того, все проблемно-ориентированные средства моделирования, к использованию которых привыкли транспортные инженеры, включают в себя проблемно-ориентированные языки разработки моделей. На основании обзора проблемно-ориентированных языков были сформулированы требования к разрабатываемому языку, который позволит обеспечить легкое его использование специалистами в предметной области:
Так как язык разрабатывается в имитационной среде общего назначения, он имеет ряд отличий от подобных ему языков. Так, в отличие от существующих проблемно-ориентированных языков, разрабатываемый язык должен обладать следующими особенностями: Язык должен обеспечивать возможность реализации в среде общего назначения AnyLogic. Язык должен быть основан на некотором обобщенном описании абстрактного конструкционного элемента моделей транспортных систем. Эта особенность обеспечит расширяемость созданного языка, а общее описание абстрактного элемента языка послужит «мостом» между специалистами-имитационщиками и транспортными инженерами.
Таким образом, необходимость разработки языка обусловлена в первую очередь отсутствием реализации языков моделирования транспортных систем в инструментах моделирования общего назначения.
Разработка любой формальной системы, в частности, языка моделирования, начинается со структуризации предметной области, выделения основных сущностей и отношений между ними. Глубина декомпозиции предметной области «транспортные системы» зависит в первую очередь от масштаба моделирования. Например, при моделировании движения в масштабах города можно пренебречь индивидуальным поведением водителей и ограничиться агрегатными характеристиками транспортного потока, однако при моделировании отдельного транспортного узла агрегатных характеристик недостаточно.
Основные положения, принятые во внимание при декомпозиции предметной области «транспортные системы», ориентированной на имитационное моделирование, следующие: Учет масштаба моделирования, необходимости рассматривать поведение отдельных участников движения. Направленность на отделение активных, действующих элементов системы от пассивных, влияющих на моделирование посредством наложения ограничений на активные элементы. На основании этих положений предложены принципы структурной декомпозиции автотранспортных систем для мелкомасштабного агентного имитационного моделирования: Транспортная система состоит из двух основных элементов - множества отдельных взаимодействующих между собой участников движения и множества объектов транспортной инфраструктуры, воздействующих на участников движения.
Множество объектов транспортной инфраструктуры разбито на подмножества, каждому из которых соответствует определенная модель (тип алгоритма) поведения участников движения.
Декомпозиция транспортной системы предполагает выделение участков, обладающих сходными алгоритмами поведения участников движения. Такая декомпозиция позволяет выделить несколько типов структурных элементов транспортных систем: Тип «Участок дороги» включает участки дорог без пересечений, на которых поведение участников движения определяется выбором предпочтительной полосы движения и стремлением занять определенную полосу (или одну из определенных полос) в конце движения по участку.
Тип «Пересечение» объединяет различные пересечения дорог, где участники движения могут изменить направление движения. Поведение на пересечениях дорог определяется правилами проезда пересечений и, в частности, разрешенными направлениями и траекториями движения.
Тип «Сложный объект» составляют участки транспортной инфраструктуры, предполагающие сложные маневры на низкой скорости. К этой группе относятся, например, заправочные станции, парковки, пункты оплаты проезда по дорогам и другие подобные объекты. Отличительной особенностью элементов данного типа является сложная, часто уникальная конфигурация и наличие предусмотренных мест остановки автомобилей.
Эти типы объектов были выделены с помощью составления репрезентативной выборки транспортных узлов. Все участки выбранных транспортных узлов могли быть разбиты на подмножества соответствующих типов. Недостатком выделенных типов является излишне большой класс элементов, охватываемых типом «Сложный объект». Однако этот недостаток компенсируется тем, что основные исследуемые свойства (пропускная способность, время ожидания, плотность потока и т.п.) транспортных систем проявляются на участках дороги и пересечениях, в то время как парковки, объекты сервиса являются вспомогательными элементами, вносящими возмущения в поведения объекта исследования.
Основным отношением между участками транспортных систем является их примыкание друг к другу. И, как следствие, основным композиционным . правилом элементов является соответствие ширины дороги и количества полос движения в местах примыкания участков.
Генерация программной среды обитания агентов
В среде имитационного моделирования AnyLogic невозможно создавать объекты, которые могут изменять свой внешний вид во время проектирования моделей. Иными словами, все элементы языка AnyLogic являются статичными, и нет возможности программно управлять их поведением во время разработки (как, например, в MS Visio).
Для графических объектов AnyLogic имеется возможность определить поведение в режиме исполнения модели (runtime), поэтому было принято решение создавать графический конструктор на основе исполняющего модуля AnyLogic, а не среды разработки. Таким образом, оба режима работы созданной системы — режим разработки моделей и режим их исполнения реализуются с помощью исполняющего модуля AnyLogic.
При запуске модели среда AnyLogic создает новое Java-приложение, основным классом которого является эксперимент. Класс эксперимента — наследник базового класса Experiment, - он содержит информацию о текущем режиме работы системы и самой модели. AnyLogic предоставляет возможность обрабатывать события начала эксперимента и его завершения. При этом эксперимент хранит информацию об открытой модели (документе) в переменной document. Текущий режим функционирования системы определяется переменной rootMode. Общая схема работы системы показана на рисунке 4.3. Инициализация
Графический конструктор - одна из основных подсистем среды низкоуровневого транспортного моделирования. Работа по программной реализации графического конструктора составила значительную часть усилий, потраченных на реализацию системы в целом.
Исходя из места графического конструктора в общей архитектуре среды (раздел 2.2) а также выполняемых им функций, сформулированы основные требования к графическому конструктору: поддержка операций перетаскивания объектов; реализация возможности работы со специальными областями экрана — служебными маркерами и точками соединения; поддержка изменения смысла операций, производимых мышью, в зависимости от состояния клавиш-модификаторов; возможность добавления сколь угодно сложных графических конструкционных элементов; поддержка одиночного и группового выделения объектов и связанных с выделением операций.
Графический конструктор, как и вся разработанная система, полностью основан на среде моделирования AnyLogic и предназначен для задания структуры имитационных моделей транспортных систем. Таким образом, для наиболее успешной реализации графического конструктора необходимо максимально использовать возможности, предоставляемые средой AnyLogic. Прежде всего, представляется оправданным использование богатых возможностей AnyLoigc по созданию анимации объектов. Элементы графического конструктора представляют собой группы графических примитивов AnyLogic.
Основным методом разработки в AnyLogic является наследование от класса ActiveObject, предоставляющего базовую функциональность как для моделирования, так и для анимации. Таким образом, классы всех анимированных объектов являются наследниками класса ActiveObject. AnyLogic позволяет наследовать одни пользовательские классы от других, что позволяет строить иерархии классов.
Среда моделирования AnyLogic обеспечивает возможность задания динамических свойств графических примитивов, что позволяет создавать движущиеся, реагирующие на действия пользователей графические объекты. Однако возможности по обработке пользовательского ввода в среде AnyLogic ограничены. Например, среда не предоставляет возможностей по обработке движений мыши и нажатий клавиш на клавиатуре. Тем не менее, к моделям AnyLogic могут быть подключены любые программные модули, написанные на языке Java, что фактически расширяет возможности моделей до пределов возможностей языка высокого уровня Java.
С учетом возможностей и недостатков среды AnyLogic, а также на основе общих правил проектирования программного обеспечения предложена общая архитектура графического конструктора, которая приведена в нотации UML на рисунке 4.4
Точка положения конструкционного элемента. rotation Угол вращения конструкционного элемента. markers Множество служебных маркеров конструкционного элемента. Служебный маркер — область экрана, позволяющая путем манипуляций мыши изменять свойства конструкционного элемента. Один конструкционный элемент может иметь несколько служебных маркеров. connectionPorts Множество соединительных портов. Соединительный порт является вспомогательным элементом, обеспечивающим соединение конструкционных элементов. Один конструкционный элемент может иметь несколько соединительных портов.
Для упрощения настройки свойств конструкционных элементов была введена дополнительная сущность - служебный маркер - участок экрана, специальным образом обрабатывающий манипуляции мыши. Для корректной обработки действий пользователя была разработана иерархия приоритетов графических элементов конструктора, схематично показанная на рисунке 4.6. onLaneControlElementCli г onConstructionEleme
