Имитационная модель перекрестка с двухфазным светофорным регулированием
КУРСОВАЯ РАБОТА
Имитационная модель
перекрестка с двухфазным светофорным регулированием
Введение
логический программный имитационный перекресток
Предмет исследования:
Реализация параллельного моделирования работы светофорных
объектов с жестким методом управления и адаптивным. Параллельное моделирование
и визуализация позволяют в процессе выполнения следить за работой алгоритмов.
Статистика по очередям доступна так же и после выполнения моделирования и в
процессе моделирования. Приводятся основные результаты моделирования
перекрестков двух типов управления.
Объект исследования: управление светофорным объектом системы.
Субъекты исследования: программный продукт регулирования
светофорным объектом системы.
Общая постановка задачи и цели. За последние годы в нашей
стране и за рубежом интенсивно ведутся работы по созданию сложных
автоматизированных систем с применением управляющих ЭВМ, средств автоматики,
телемеханики, диспетчерской связи и телевидения для управления движением в
масштабах крупного района или целого города. Опыт эксплуатации таких систем
убедительно свидетельствует об их эффективности в решении транспортной
проблемы.
Задачи исследования:
Прежде чем начать разработку, создание и внедрение любой
дорогостоящей системы, необходимо удостовериться в её необходимости.
) Создать моделирование, которое позволяет оценить
возможности той или иной системы, в данном случае разрабатывались программы
моделирования дорожных перекрёстков, использующих различные методы управления.
Моделирование основывается на теории массового обслуживания.
) Перекрёсток можно представить как систему с четырьмя
обслуживающими приборами и четырьмя потоками заявок (рис. 1). Время задержки в
обслуживающих устройствах зависит от времени зелёных и красных фаз светофора, а
так же времени переходного процесса. Интенсивность потоков на дорогах меняются
не только в течении суток, но и носят случайный характер в целом.
) Для проведения моделирования, следует написать программу, в
которой можно изменять параметры системы, а именно средние значения
интенсивности входных потоков и длительность фаз светофора.
Рис.
1. Схема моделирования перекрестка
Так
же стоить отметить недостатки жесткого метода управления светофорным объектом.
)
Работа вхолостую, когда определённому направлению открыт зелёный, а машин по
этому направлению нет. В то время как на других направлениях машины стоят перед
красным сигналом светофора.
)
По направлению был открыт зелёный, который через некоторое время сменился на
красный, в тоже время не все машины с данного направления успели проехать
перекрёсток. И более того, частая смена фаз светофора не позволяет автомобилю
пересечь перекрёсток в два и менее приёма. Автомобиль приближается к
перекрёстку рывками, путём остановок и новых движений. Последнее ухудшает
экологию города, ведёт к перерасходу горючего, снижает моторесурс автомобиля,
увеличивает аварийность перед перекрёстком.
)
Анализ исследуемых процессов. Несогласованность длительности включенной фазы с
истинной интенсивностью потока по направлению снижает пропускную способность
перекрёстка и ведёт к пробкам, которые вредно действуют на психическое
состояние водителей и их здоровье. Последнее напрямую связано с аварийностью.
)
Описание процесса работы перекрёстка. Работа светофоров, регулировщиков.
Интервал времени переключения цветов на светофоре, интенсивность автомобилей.
5) Имитационное моделирование перекрестка.
Целью
работы: разработка программного средства параллельно моделирующего работу
жёсткого и адаптивного управления светофорным объектом.
Цель
для заказчика: повышение эффективности бизнес процесса.
Цель
для исполнителя: получение нового опыта, дополнительного опыта для
какого-нибудь инструмента, которым исполнитель владеет.
Ожидаемый
результат исследования:
Визуальное программирование - способ создания программы для
ЭВМ путём манипулирования графическими объектами вместо написания её текста.
Визуальное программирование часто представляют как следующий этап развития
текстовых языков программирования. Наглядным примером может служить утилита
Визуальный Pascal, где редактируются графические объекты и одновременно
отображается соответствующий текст программы. В последнее время визуальному
программированию стали уделять больше внимания - в связи с развитием мобильных
сенсорных устройств (КПК, планшеты), когда использование клавиатуры не очень
удобно.
Необходимо различать:
1. графический язык программирования - который прежде
всего язык программирования (со своим синтаксисом)
2. визуальные средства разработки - как правило, под
ними подразумевают средства проектирования интерфейсов или какую либо
CASE-систему для быстрой разработки приложений или SCADA-систему для
программирования микроконтроллеров.
3. языки визуального программирования могут быть
дополнительно классифицированы в зависимости от типа и степени визуального
выражения, на следующие типы:
· языки на основе объектов, когда визуальная
среда программирования предоставляет графические или символьные элементы,
которыми можно манипулировать интерактивным образом в соответствии с некоторыми
правилами;
· языки, в интегрированной среде разработки
которых на этапе проектирования интерфейса применяются формы, с возможностью
настройкой их свойств. Примеры: Delphi и C++ Builder фирмы Borland, С#
· языки схем, основанные на идее «фигур и
линий», где фигуры (прямоугольники, овалы и т.п.) рассматриваются как субъекты
и соединяются линиями (стрелками, дугами и др.), которые представляют собой
отношения.
1.
Аналитическая часть
1.1
Анализ предметной области
Предметная область-область деятельности в реальном мире,
которая дает понять, в каких условиях нужно работать
На протяжении длительного времени ведутся исследования по
созданию сложных автоматизированных систем с применением управляющих ЭВМ,
средств автоматики, телемеханики, диспетчерской связи и телевидения для
управления движением в масштабах крупного района или
целого города.
На интенсивность движения автомобильного транспорта и
распределение транспортных потоков по участкам уличной сети оказывают влияние
такие факторы:
1) топологические характеристики, отражающие геометрическую
структуру УДС и параметры ее отдельных элементов (например, ширина в проезжей
части, конфигурация перекрестков, транспортных развязок);
2) факторы, связанные собственно с организацией движения
(одностороннее движение, запреты маневров на перекрестках, запреты движения
грузового транспорта);
) факторы, обусловленные наличием светофорного
регулирования (схемы пофазного разъезда и параметры светофорного регулирования,
характеристики регулируемых направлений, наличие координированного управления
светофорными объектами);
) характеристики дорожного покрытия, отражающие его
состояние и влияющие на условия и скорость движения транспорта;
) факторы, связанные с наличием пешеходных потоков и
организацией движения пешеходов (дислокация нерегулируемых и регулируемых
пешеходных переходов, наличие пешеходных ограждений);
) факторы, связанные с движением маршрутного
общественного транспорта (интенсивность движения маршрутных автобусов и
троллейбусов, дислокация остановок трамваев при расположении трамвайного
полотна в одном уровне с проезжей частью и частота движения трамваев);
) факторы, связанные с парковкой транспортных средств
на проезжей части, создающей помехи движению транспортного потока.
Очевидно, что учесть все многообразие этих факторов
экспертным путем для построения прогнозных распределений потоков можно лишь для
небольших участков УДС. Оптимизация автоматизированного управления в сложных
схемах организации движения требует создания и использования компьютерных моделей.
1.2
Анализ вариантов решения задач
Структурная
схема модели представлена на рисунке 2. Она включает в себя генерацию
автомобилей, буфер перекрестка, карту перекрестка, сигналы светофора,
графическое отображение и сбор статистики.
Рис.
2. Структура модели
Перекрестки улично-дорожной сети при исследовании времени
движения автомобилей целесообразно разбить на две группы:
регулируемые перекрестки;
нерегулируемые перекрестки.
На перекрестках данных видов существуют различные условия
движения транспортных средств. Функционирующие технические средства
регулирования дорожного движения определяют порядок движения транспортных
средств, которые в свою очередь могут влиять на режим движения автомобиля.
Кроме того, каждую из этих групп перекрестков необходимо разбить на подгруппы в
зависимости от направления движения автомобиля:
с движением прямо;
ожидание на светофоре;
Необходимость создания этих подгрупп обосновывается тем, что
в зависимости от направления движения автомобиля происходит различное
количество ответвлений, слияний и пересечений транспортного потока, в котором
он двигается, и конфликтующих транспортных потоков. Наименьшие помехи для
движения наблюдаются при ответвлениях. Они могут вызывать лишь некоторое снижение
скорости движения автомобиля при выходе его из транспортного потока прямого
направления. Значительно большие помехи возникают при слиянии транспортных
потоков. Кроме замедления движения автомобиля появляется и опасность
столкновения, что также накладывает определенный отпечаток на режим движения
автомобилей. Наибольшие сложности связаны с пересечением, так как вероятность
столкновения здесь наиболее значительна.
1.3 Обоснование выбора компонентов решения
На последующем шаге появляется необходимость в выделении
причин разных групп, воздействие которых на время движения автомобиля нужно
исследовать.
При отборе включенных на рассмотрение причин соблюдать
последующие условия:
список охватываемых исследованием причин нужно доказать
теоретически;
список обязан включать в себя важные причины, оказывающие
немаловажное воздействие на модифицирование объекта; - список не следует делать
слишком обширным, но он должен описывать функцию, по возможности, во всех
аспектах;
факторы не должны находиться между собой в функциональной
связи, так как существование функциональной и близких к ней связей между
факторами показывают, что они характеризуют одну и ту же сторону изучаемого
явления. Включать в модель из двух связанных факторов нужно тот, который
оказывает в уравнении регрессии наибольшее влияние;
требуется установить область определения факторов;
необходимо учитывать условия изменения факторов во времени.
С использованием этих рекомендаций были выбраны факторы,
оказывающие наибольшее влияние на время движения автомобилей.
В качестве параметров, характеризующих автомобиль, можно
выделить следующие:
ширина автомобиля;
удельная мощность двигателя;
количество людей в салоне автомобиля.
Ширина автомобиля может влиять на возможность его
маневрирования в транспортном потоке. Удельная мощность двигателя может
выступать в качестве фактора, характеризующего динамические качества
автомобиля. Количество людей в салоне определяет полную массу автомобиля, что в
свою очередь влияет на скорость его движения.
В качестве параметров, характеризующих водителя, можно
принять:
возраст водителя;
водительский стаж.
Опыт и мастерство водителя так же влияют на скорость движения
автомобилей. В качестве показателей, оценивающих эти качества, можно
использовать возраст водителя и его водительский стаж. Первый показатель может
определять продолжительность фаз функционального состояния организма водителя,
а второй - определяет уровень мастерства вождения.
Ряд факторов, характеризующих дорожные условия движения
автомобилей, может быть общим для участков маршрута и перекрестков, а другие
будут различные в виду особенностей движения на этих элементах трассы маршрута.
К общим факторам можно отнести следующие:
расстояние видимости дорожного покрытия;
коэффициент сцепления колеса с дорогой.
Условия видимости, существенно влияющие на скорость движения,
возможно оценить расстоянием видимости дорожного покрытия. Коэффициент
сцепления, определяемый типом и состоянием покрытия дороги, также существенно
влияет на скорость движения автомобилей.
К факторам, характеризующим дорожные условия движения
автомобилей на участке маршрута, можно отнести:
длину участка;
количество полос движения в направлении следования;
скорость транспортного потока в направлении следования;
интенсивность движения транспортных средств в направлении
следования.
Для перекрестков можно выделить следующие факторы, характеризующие
условия движения:
количество полос движения на основной дороге;
количество полос движения на пересекаемой дороге;
интенсивность движения на основной дороге;
интенсивность движения на пересекаемой дороге.
Количество полос движения на основной и пересекаемой дороге
определяют геометрические размеры перекрестка, которые также влияют на
возможность маневрирования при движении на перекрестке. Интенсивность движения
на перекрестке, как и в случае участка маршрута, может определять возможность
возникновения помех движению автомобиля.
Для регулируемых перекрестков дополнительно целесообразно
выделить еще два фактора:
длительность цикла светофорного регулирования;
длительность зеленого сигнала светофора в направлении
движения автомобиля.
Данные факторы могут определять вероятность преследования
автомобиля через перекресток на разрешающий сигнал светофора. Все факторы,
рассмотренные ранее и принятые для исследования, составляют только часть группы
дорожных факторов. Оставшуюся часть факторов конкретизировать достаточно сложно
ввиду случайности их возникновения. Это транспортные «пробки», пешеходные
переходы, трамвайные остановки и другие случайно возникающие помехи. Данные
факторы будут определять закон распределения фактической скорости движения
автомобиля на участке маршрута и перекрестке.
Участки маршрута следования автомобилей между перекрестками
можно дифференцировать по условиям движения на следующие составляющие: участки
с двухсторонним движением; участки с односторонним движением.
Дадим определения используемых ниже терминов.
Дорога-особая территория для движения автомобилей, пешеходов
и соблюдения Правил дорожного движения (ПДД).
Полоса движения - часть дороги, предназначенная для движения
автомобилей в одном ряду.
Дорожная разметка (разметка) - особые обозначения, нанесенные
на поверхность дороги и предназначенные для организации движения.
Пешеходный переход-элемент дорожной разметки, обозначающий
территорию пешеходного перехода.
Дорожный знак - графическое или текстовое обозначение,
предназначенное для явного указания правил движения.
Регулировщик - специально подготовленный специалист, жесты
или действия которого служат указанием участникам дорожного движения.
Светофор - техническая конструкция, позволяющая управлять
движением посредством цветовых и символьных обозначений.
Перекресток - пересечение двух и более дорог.
Сопряжение - место слияния двух и более дорог.
Развязка - несколько сопряжений дорог, позволяющих
автомобилям изменить направление движения. Схема видов пересечения дорог
представлена на рис. 1.
Рис. 2 - Схема видов сопряжения и систем управления движением
на пересечениях дорог
Рассмотрим пересечение двух автомобильных дорог. Каждая
дорога состоит из двух проезжих частей, а каждая проезжая часть, в свою
очередь, имеет 2 полосы движения: одна - для поворота налево, другая - для
движения прямо и на право. Предположим, что на перекрестке разрешен проезд в
любом из направлений (прямо, налево, направо), а светофоры работают в
двухфазном режиме (рис. 2).
Рисунок 2 - Режимы работы светофоров на перекрестке:
а - 1-я фаза; б - 2-я фаза
Во время работы светофоров в первой фазе (рис. 2, а) движение
разрешено по проезжим частям S и N. При этом автомобили, двигающиеся по правой
полосе, могут беспрепятственно продолжать движение прямо. Во время работы
светофоров во второй фазе (рис. 2, б) движение разрешено по проезжим частям W и
E. Направления движения по полосам и правила проезда перекрестка аналогичны
первому случаю.
Схема расположения объектов на перекрестке представлена на
рисунке 3.
Рис. 3 - Схема расположения объектов на перекрестке
2.
Проектирование программного продукта
Множество публикаций посвящено обсуждению организации проекта
разработки, и данный текст не претендует на детальное рассмотрение этой
области. Данный раздел включен в статью только для того, чтобы помочь
аналитикам осознать роль и место моделирования данных в процессе работы над
проектом.
Большинство компаний руководствуется какой-либо методологией,
которая очерчивает выбранный жизненный цикл для направления процесса
разработки. Как правило, на концептуальном уровне большинство придерживается
сходной последовательности шагов:
Определение проблемы
Анализ требований
Концептуальное проектирование
Детальное проектирование
Реализация
Тестирование
2.1.
Концептуальная, логическая и физическая модели данных
Концептуальная модель (англ. conceptual model)
- это модель, представленная множеством понятий и связей между ними,
определяющих смысловую структуру рассматриваемой предметной области или ее
конкретного объекта.
Концептуальная модель - модель предметной области, состоящей
из перечня взаимосвязанных понятий, используемых для описания этой области,
вместе со свойствами и характеристиками, классификацией этих понятий, по типам,
ситуациям, признакам в данной области и законов протекания процессов в ней.
(Толковый словарь по искусственному интеллекту) [1]
Созданную концептуальную модель необходимо отразить в
какую-либо компьютерно-ориентированную модель как на Рис. 4, т.е. построить
логическую модель данных. К настоящему времени известны три типа логических
моделей.
Рис. 4 - Концептуальная модель
Иерархическая логическая модель. Модель этого типа жестко
структурирована, т.е. взаимосвязь между объектами внутри модели подчинена
строгому ранжиру (Рисунок 5). Подчинение объектов разделено на уровни. На
первом уровне представлен один главный объект, которому подчиняются объекты
второго уровня.
Рис. 5 - Логическая иерархическая модель
Причем объект первого уровня не может напрямую управлять
объектом третьего уровня. Управление объектом третьего уровня возможно только
через объект второго уровня. Также запрещены взаимосвязи на одном уровне. По
принципу иерархической модели строят различные картотеки, каталоги, реестры и
т.д.
Основными достоинствами таких моделей является их простота и
наличие только заранее определенных связей между сущностями. Если связи между
сущностями носят разветвленный, неупорядоченный характер, то создание
иерархической модели становится весьма трудным и проблематичным.
Сетевая логическая модель. Сетевая модель более
демократична. В ней отсутствует понятие главного и подчиненного объекта
(рисунок 6). Любой объект модели в одно и то же время может выступать и как
главный, и как подчиненный, т.е. иметь любое количество взаимосвязей в любом
направлении. Здесь допустимы связи на одном уровне. С практической точки зрения
сетевая модель представляет собой совокупность двух- или трехзвенных
иерархических моделей, иногда называемых «наборами», которые соединяются между
собой. Сетевая модель сложна в создании и управлении, более громоздка, чем
иерархическая модель. Единственная ее положительная черта - отображение
произвольных связей между сущностями.
Рис. 6 - Логическая сетевая модель
Реляционная логическая модель. В реляционной модели
объекты представлены в виде таблиц (двумерных массивов). Причем таблицей могут
отображаться не только объекты, но и связи. Каждая таблица в реляционной теории
называется отношением. [2]
Физические модели баз данных определяют способы
размещения данных в среде хранения и способы доступа к этим данным, которые
поддерживаются на физическом уровне. Исторически первыми системами хранения и
доступа были файловые структуры и системы управления файлами (СУФ), которые
фактически являлись частью операционных систем. СУБД создавала над этими
файловыми моделями свою надстройку, которая позволяла организовать всю
совокупность файлов таким образом, чтобы она работала как единое целое и
получала централизованное управление от СУБД. Однако непосредственный доступ
осуществлялся на уровне файловых команд, которые СУБД использовала при
манипулировании всеми файлами, составляющими хранимые данные одной или нескольких
баз данных. [3]
2.2
Концепции достижения цели
Основополагающим этапом проектирования любой информационной
системы является выполнение корректной оценки предметной области решаемой
задачи и выбор концепции анализа и проектирования. Фактически речь идет об
определении одной из концепций системного анализа, которая будет применяться
при моделировании системы. Значимость указанного процесса заключается в
изначальном естественном введении ограничений на получаемые результаты -
адекватность модели реальной системе, точность получаемых результатов,
возможности «расширения» существующей модели и переноса ее шаблона на новые
объекты (моделируемые системы) и т.д. Появление ограничений обусловлено,
естественным образом, идеологическими возможностями той или иной концепции.
Неудачный выбор концепции (именно «неудачный», о
«неправильном» выборе речь даже не идет) способен повлечь максимальные
«издержки» на всех последующих этапах разработки информационной системы.
Информационная система - модель системы реального мира,
реализованная посредством аппаратных и программных средств.
Концепция анализа и проектирования - метод построения модели
предметной области при создании информационной системы. Заключается в
моделировании объектов, процессов, взаимодействий и т.д. в целях решения
некоторой задачи. Следует отметить, что концепции программирования являются
частными случаями концепций анализа и проектирования,
их главное предназначение - получение программной реализации
моделей систем, объектов, процессов и логики.
В силу ряда обстоятельств (развитие технологий баз данных и
объектно - ориентированных языков программирования высокого уровня,
взаимопроникновение и интеграция современных CASEтехнологий и т.д.) большинство
современных сред проектирования и моделирования в значительной степени
объединяют логико-ориентированную и ориентированную на правила концепции.
Объектно
- ориентированная концепция решения задачи.
При использовании объектно-ориентированной концепции для
решения задачи, описанной в рассматриваемом примере, потребуется выделить
объекты и определить их параметры, методы, а также события системы.
Дополнительно при построении рабочей модели необходимо будет
определить ряд новых свойств объектов. Основные объекты (дорога, разметка,
светофор, транспортное средство) были выделены выше. Там же были приведены их
свойства.
Таблица 1. Объекты исследования и их свойства
|
Объект
|
Свойство
|
|
Дорога
|
Тип поверхности
Тип участка Тип полосы Координаты
|
|
Разметка
|
Назначение Тип
линии Координаты
|
Состояние Режим
управления Рабочий цикл
|
|
Транспортное
средство
|
Тип Состояние
Направление движения Скорость
|
Логико-ориентированная
концепция решения задачи.
Данная методология позволяет ориентироваться не на абстракции
класс / объект или процесс / поток, а на описание правил поведения и логики
достижения цели. Вспомним, что не были учтены некоторые значимые параметры,
факторы и процессы системы и отдельных ее элементов, поэтому рассмотрим
ситуацию с более сложной задачей. Таким образом, возникают дополнительные
требования к модели и ее новые свойства.
. Интенсивность потоков в различных направлениях может быть
различна.
. Интенсивность потоков в различных направлениях может быть
различна в разное время суток - присутствует суточная сезонность.
. Автомобили обладают индивидуальными характеристиками:
максимальная скорость, максимальное ускорение, ускорение торможения, масса,
износ тормозов, износ двигателя и т.д.
. Водители отличаются стилем вождения, скоростью реакции,
потенциалом нарушения правил и т.д.
. На перекрестке могут быть установлены светофоры с
дополнительными сигналами (отдельные блоки на направления движения - стрелки,
пешеходные светофоры и т.д.), регулирующие знаки и нанесена дорожная разметка.
. В качестве подсистемы управления может выступать человек
или автоматика.
. Присутствует влияние окружающей среды (сухо, дождь, снег,
гололед и т.д.).
. Возможно интеллектуальное управление работой светофоров на
основе анализа текущей ситуации, прогнозирования ее развития и последующего
изменения алгоритма работы элементов управления.
. Идет накопление статистики о работе системы (движении
транспорта, очереди автомобилей, среднем времени ожидания у перекрестка и т.д.)
и ее отображение.
Рассмотрение нескольких концепций анализа и проектирования в
рамках решения одной и той же задачи позволило выявить несколько существенных
вопросов, возникающих при построении информационных систем. Основные
вопросы-создание эффективных масштабируемых моделей предметной области,
корректный выбор концепции в соответствии с требованиями, предъявляемыми к системе.
Можно констатировать, что универсальной концепции не существует. Каждая из
рассмотренных концепций обладает как положительными, так и отрицательными
сторонами по таким критериям, как затраты на проектирование, точность
получаемых результатов, адекватность получаемой модели реальной системе и т.д.
Основная задача проектировщика - с самого начала создать такое представление о
решаемой задаче и о сущности предметной области, которые в дальнейшем позволят
сделать верный выбор методологии анализа и проектирования. Обоснованное и
корректное использование концепций и применение соответствующего им
инструментария позволяет избежать ошибок на последующих стадиях реализации
проектов.
2.3
Функциональные требования к программному продукту
Требования к программному обеспечению - совокупность
утверждений относительно атрибутов, свойств или качеств программной системы,
подлежащей реализации. Создаются в процессе разработки требований к
программному обеспечению, в результате анализа требований.
Требования могут выражаться в виде текстовых утверждений и
графических моделей. В классическом техническом подходе совокупность требований
используется на стадии проектирования ПО. Требования также используются в
процессе проверки ПО, так как тесты основываются на определённых требованиях.
Этапу разработки требований, возможно, предшествовало
технико-экономическое обоснование, или концептуальная фаза анализа проекта.
Фаза разработки требований может быть разбита на выявление требований (сбор,
понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ
(проверка целостности и законченности), спецификация (документирование
требований) и проверка правильности.
Системные требования к данному программному продукту:
1. Microsoft Windows 98, 2000, and XP, Vista
2. Место на диске: 2 Mb
. 256 Mb RAM
. Процессор не менее 1.6 Ghz
3.
Описание программной реализации
3.1
Дерево модулей и функций
Выявление состава функций, их иерархии и выбор языка общения
(например, языка типа «меню») позволяет разработать структуру сценария диалога,
дающего возможность определить состав кадров диалога, содержание каждого кадра
и их соподчиненность.
Модель дерева функций относится к функциональному
представлению и предназначена для описания иерархической структуры функций
(включая статические связи между ними) бизнес-процессов предприятия. Функция -
это задача, операция или действие, которые выполняются над объектом для
достижения одной или нескольких целей.
Модель перекрёстка можно изобразить при помощи дерева
вызовов. Оно обеспечивает графическое представление потока исполнения
приложения и помогает выявить критические функции и временные затраты в
приложении. Профилирование дерева вызовов предусматривает графическое
высокоуровневое и алгоритмическое представление выполнения программы на основе
инструментирования двоичных исполнимых файлов, используемого для сбора данных о
последовательности вызовов функций. В данной модели необходимо сопоставить
движение машин по перекрёстку, переключениям сигналов светофоров при помощи
установки на форму таймеров.
3.2 Тестирование
Обеспечение качества ПО включает в себя ряд процессов,
наиболее очевидным из которых является тестирование. Процесс тестирования
программного обеспечения призван устранить ошибки работы ПО, особенно
касающиеся целостности и защищенности информации.
Тестирование web-приложений имеет много общего с
тестированием операционных систем для настольных компьютеров. Необходимо
протестировать стандартную функциональность, конфигурацию и совместимость. Но
тестирование web-приложений - это более сложный процесс, потому как трудности
приумножены всеми распределенными компонентами системы, взаимодействующими с
приложением.
Для того чтобы понять правильно ли работает приложение
необходимо:
пронаблюдать за графическими процессами происходящими на
форме. Если нарушений не выявлено, то делаем вывод что приложение работает
правильно;
определить требования к данному программному продукту:
5. Microsoft Windows 98, 2000, and XP, Vista
6. Место на диске: 2 Mb
. 256 Mb RAM
. Процесор не менее 1.6 Ghz
Заключение
Большинство отечественных публикаций по методике расчета
пересечений мало предназначены для исследования случаев их функционирования в
условиях насыщения движения, в то время как результаты имитационного
моделирования являются наиболее наглядными в случае насыщенного движения.
Имитационное
моделирование динамики транспортного потока, имитирующее движения каждого
отдельного автомобиля позволяет визуально и количественно оценивать
эффективность решений направленных на улучшение организации движения.
Применение этих моделей позволяет оценить динамику скорости движения, задержки
на перекрестках, длины и динамику образования очередей или заторов и другие
характеристики движения.
Список
информационных источников
1. Концептуальная
модель. (2014, октябрь 17). Википедия, свободная энциклопедия. Retrieved 15:46,
мая 20, 2015 from http://ru.wikipedia.org/? oldid=57946713.
2. Логические
модели. (2014, март 23). БАЗЫ ДАННЫХ образовательный сайт. Retrieved
11:44, мая 20, 2015
http://bazydannyh.ru/Teoriya_baz_dannyh/Logicheskie_modeli/index.html
3. Физические
модели БД. (2012, октябрь 10). Интуит. Retrieved 15:21, мая 21, 2015 from
http://www.intuit.ru/studies/courses/1001/297/lecture/7415
4. Моделирование
работы перекрестков различных типов управления с визуализацией процесса. (2012,
ноябрь 22) Брестский государственный технический университет, Республика
Беларусь Retrived 20:02, мая 20, 2015 from http://mia.univer.kharkov.ua/19/30242.pdf
5. Имитационная
модель перекрестка. (2014, июнь 01). Институт проблем управления им. В.А.
Трапезникова РАН, г. Москва Retrieved 17:33, мая 20, 2015 from
http://cmm.ipu.ru/sites/default/cmm12cd/CD/Papers/EfremovKuznecovLegovich_pdfed_.pdf
6. Моделирование
работы перекрестков различных типов управления с визуализацией процесса (2015,
февраль 01). Retrieved 18:02, февраль 1, 2015 from Моделирование проезда
перекрестка http://lib.tr200.net/v.php? id=582578&sp=1
Приложение
Приложение 1 - Листинг кода
unit Unit1;
interface
, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, ExtCtrls;
= class(TForm): TImage;: TTimer;:
TTimer;Timer2Timer (Sender: TObject);Cars;Timer1Timer (Sender:
TObject);FormCreate (Sender: TObject);
{Private declarations}
{Public declarations};
: TForm1;:array [0..55] of array [0..4] of
integer;:TBitmap;, St2, St3, St4, TimeOut, z, t:integer;: Boolean;
{$R *.dfm}
TForm1. FormCreate (Sender: TObject);: integer;:=
TBitmap. Create;. Width:= Image1. Width;. Height:= Image1. Height;. Canvas.
Brush. Color:= clgreen;. Canvas. Rectangle (0, 0, Image1. Width, image1.
Height);. Canvas. Brush. Color:= clblack;. Canvas. Rectangle (221, 0, 291,
511);. Canvas. Rectangle (0, 221, 511, 291);. Canvas. Pen. Color:= clwhite;.
Canvas. MoveTo (256, 221);. Canvas. LineTo (256, 0);. Canvas. MoveTo (221,
256);. Canvas. LineTo (0, 256);. Canvas. MoveTo (256, 291);. Canvas. LineTo
(256, 511);. Canvas. MoveTo (291, 256);. Canvas. LineTo (511, 256);. Canvas.
Pen. Color:= clblack;. Canvas. Brush. Color:= clolive;. Canvas. Ellipse (185,
300, 200, 315);. Canvas. Ellipse (315, 195, 330, 210);. Canvas. Brush. Color:=
clolive;. Canvas. Ellipse (200, 180, 215, 195);. Canvas. Ellipse (300, 320,
315, 335);:= true;. Enabled:= false;i:= 0 to 55 do[i, 2]:= 0;;:= 0;;:= 800;;;
TForm1. Cars;: integer;i:= 0 to 55 doAvto [i, 2]
= 0 then[i, 2]:= random(4) + 1;Avto [i, 2] = 1 then begin[i, 0]:= 235;[i, 1]:=
0;[i, 4]:= 1;. Enabled:= true;;;Avto [i, 2] = 2 then begin[i, 0]:= 0;[i, 1]:=
275;[i, 4]:= 1;. Enabled:= true;;;Avto [i, 2] = 3 then begin[i, 0]:= 275;[i,
1]:= 511;[i, 4]:= 1;. Enabled:= true;;;Avto [i, 2] = 4 then begin[i, 0]:=
511;[i, 1]:= 235;[i, 4]:= 1;. Enabled:= true;;;;;;;TForm1. Timer1Timer (Sender:
TObject);Move = true then. Canvas. Brush. Color:= clyellow;. Canvas. Ellipse
(200, 180, 215, 195);. Canvas. Ellipse (300, 320, 315, 335);. Canvas. Ellipse
(185, 300, 200, 315);. Canvas. Ellipse (315, 195, 330, 210);. Canvas. Brush.
Color:= clyellow;. Canvas. Ellipse (200, 180, 215, 195);. Canvas. Ellipse (300,
320, 315, 335);. Canvas. Ellipse (185, 300, 200, 315);. Canvas. Ellipse (315,
195, 330, 210);;;
TForm1. Timer2Timer (Sender: TObject);:
integer;(TimeOut);TimeOut = 80 then:= 0;. Enabled:= false;;;i:= 0 to 55 doAvto
[i, 4] = 1 thenAvto [i, 2] = 1 then(Avto[i, 1]);Avto [i, 1] = 235 then[i, 2]:=
random(1) + 1;;(Avto [i, 2] = 2) then(Avto[i, 0]);Avto [i, 0] = 235 then[i,
2]:= random(1) + 2;;(Avto [i, 2] = 3) then(Avto[i, 1]);Avto [i, 1] = 275
then[i, 2]:= random(1) + 3;;(Avto[i, 2] = 4) then(Avto[i, 0]);Avto [i, 0] = 275
then[i, 2]:= random(1);Avto [i, 2] = 0 then Avto [i, 2]:= 4;;;;Move = true
then(Avto [i, 2] = 2) and (Avto [i, 0] = St2) then:= St2 - 25;[i, 4]:= 0;;(Avto
[i, 2] = 4) and (Avto [i, 0] = St4) then:= St4 + 25;[i, 4]:= 0;;;Move = False
then(Avto [i, 2] = 1) and (Avto [i, 1] = St1) then:= St1 - 25;[i, 4]:= 0;;(Avto
[i, 2] = 3) and (Avto [i, 1] = St3) then:= St3 + 25;[i, 4]:= 0;;;. Canvas.
Brush. Color:= clgray;. Canvas. Rectangle (Avto[i, 0] - 5, Avto [i, 1] - 5,
Avto [i, 0] + 5, Avto [i, 1] + 5);(Avto [i, 0] > 511) or (Avto [i, 0] <
0) or (Avto [i, 1] > 511) or (Avto [i, 1] < 0) then[i, 2]:= 0;;. Image1.
Picture. Bitmap:= BGround;Move = true then. Canvas. Brush. Color:= clgreen;.
Canvas. Ellipse (170, 300, 185, 315);. Canvas. Ellipse (330, 195, 345, 210);. Canvas.
Brush. Color:= clred;. Canvas. Ellipse (200, 300, 215, 315);. Canvas. Ellipse
(300, 195, 315, 210);. Enabled:= true;. Canvas. Brush. Color:= clmaroon;.
Canvas. Ellipse (200, 165, 215, 180);. Canvas. Ellipse (300, 335, 315, 350);.
Canvas. Brush. Color:= cllime;. Canvas. Ellipse (200, 195, 215, 210);. Canvas.
Ellipse (300, 305, 315, 320);. Canvas. Brush. Color:= clolive;. Canvas. Ellipse
(200, 180, 215, 195);. Canvas. Ellipse (300, 320, 315, 335);. Canvas. Brush.
Color:= clred;. Canvas. Ellipse (200, 165, 215, 180);. Canvas. Ellipse (300,
335, 315, 350);. Enabled:= true;. Canvas. Brush. Color:= cllime;. Canvas.
Ellipse (170, 300, 185, 315);. Canvas. Ellipse (330, 195, 345, 210);. Canvas.
Brush. Color:= clolive;. Canvas. Ellipse (185, 300, 200, 315);. Canvas. Ellipse
(315, 195, 330, 210);. Canvas. Brush. Color:= clmaroon;. Canvas. Ellipse (200,
300, 215, 315);. Canvas. Ellipse (300, 195, 315, 210);. Canvas. Brush. Color:=
clgreen;. Canvas. Ellipse (200, 195, 215, 210);. Canvas. Ellipse (300, 305,
315, 320);;z = 800 thenMove = true then:= false;Move:= true;:= 200;:= 200;:=
310;:= 310;i:= 0 to 55 do Avto [i, 4]:= 1;:= 0;;:= z + 1;;
.
, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, ExtCtrls;
= class(TForm): TTimer;: TImage;: TTimer;: TTimer;Timer2Timer
(Sender: TObject);Machine;Timer1Timer (Sender: TObject);FormCreate (Sender:
TObject);
{Private declarations}
{Public declarations};
=record, Y, NaprPryam, Kurs2, NX, NY,
DvigStop:integer;;
: TForm1;:array [0..55] of TMyCar;:TBitmap;, z,
t:integer;:TBitMap;, yel: Boolean;, St2, St3, St4:integer;
{$R *.dfm}
TForm1. FormCreate (Sender:
TObject);:integer;:=TBitmap. Create;. Width:=Image1. Width;. Height:=Image1.
Height;. Canvas. Brush. Color:=clblack;. Canvas. Rectangle (0,0, Image1. Width,
image1. Height);. Canvas. Brush. Color:=clgreen;. Canvas. Rectangle
(0,0,267,266);. Canvas. Rectangle (333,0,600,266);. Canvas. Rectangle
(0,332,267,600);. Canvas. Rectangle (333,332,600,600);. Canvas. Pen.
Color:=clwhite;. Canvas. MoveTo (300,264);. Canvas. LineTo (300,0);. Canvas.
MoveTo (263,300);. Canvas. LineTo (0,300);. Canvas. MoveTo (300,336);. Canvas.
LineTo (300,600);. Canvas. MoveTo (340,300);. Canvas. LineTo (600,300);.
Canvas. Pen. Color:=clblack;. Canvas. Brush. Color:=clolive;. Canvas. Ellipse (235,340,250,355);.
Canvas. Ellipse (355,245,370,260);. Canvas. Brush. Color:=clolive;. Canvas.
Ellipse (263,247,248,232);. Canvas. Ellipse (340,355,355,370);:=true;:=false;.
Enabled:=false;i:= 0 to 55 do begin[i].NaprPryam:=0;;:=0;;:=800;;
;
TForm1. Machine;, j:integer;i:= 0 to 55 do
beginMyCar[i].NaprPryam=0 then:=random(4);j=1 then
begin[i].X:=280;[i].Y:=0;[i].NaprPryam:=1;[i].Kurs2:=random(4)+1; //
[i].NX:=0;[i].NY:=1;[i].DvigStop:=1;. Enabled:=true;;;j=2 then
begin[i].X:=0;[i].Y:=320;[i].NaprPryam:=2;[i].Kurs2:=random(4)+1; //
[i].NX:=1;[i].NY:=0;[i].DvigStop:=1;. Enabled:=true;;;j=3 then
begin[i].X:=320;[i].Y:=600;[i].NaprPryam:=3;[i].Kurs2:=random(4)+1; //
[i].NX:=0;[i].NY:=-1;[i].DvigStop:=1;. Enabled:=true;;;j=4 then
begin[i].X:=600;[i].Y:=280;[i].NaprPryam:=4;[i].Kurs2:=random(4)+1; //
[i].NX:=-1;[i].NY:=0;[i].DvigStop:=1;. Enabled:=true;;;;;
TForm1. Timer1Timer (Sender: TObject);time = true
then. Canvas. Brush. Color:=clyellow;. Canvas. Ellipse (263,247,248,232);.
Canvas. Ellipse (340,355,355,370);. Canvas. Ellipse (235,340,250,355);. Canvas.
Ellipse (355,245,370,260);. Canvas. Brush. Color:=clyellow;. Canvas. Ellipse
(263,247,248,232);. Canvas. Ellipse (340,355,355,370);. Canvas. Ellipse
(235,340,250,355);. Canvas. Ellipse (355,245,370,260);;;
TForm1. Timer2Timer (Sender:
TObject);:integer;:=s+1;s=80 then:=0;. Enabled:=false;;;i:=0 to 55 do begin
(MyCar[i].X=280) and (MyCar[i].Y=280) and
(MyCar[i].NaprPryam=1) and (MyCar[i].Kurs2=2)
then // пооврот вверхней машины в право[i].NX:=-1;[i].NY:=0;;(MyCar[i].X=320)
and (MyCar[i].Y=280) and
(MyCar[i].NaprPryam=4) and (MyCar[i].Kurs2=1)
then[i].NX:=0;[i].NY:=-1;;
(MyCar[i].X=280) and (MyCar[i].Y=320) and
(MyCar[i].X=320) and (MyCar[i].Y=320) and
(MyCar[i].NaprPryam=3) and (MyCar[i].Kurs2=4)
then[i].NX:=1;[i].NY:=0;;time=true then(MyCar[i].NaprPryam=2) and
(MyCar[i].X=St2) then:=St2-25;[i].DvigStop:=0;;(MyCar[i].NaprPryam=4) and
(MyCar[i].X=St4) then:=St4+25;[i].DvigStop:=0;;;time=False
then(MyCar[i].NaprPryam=1) and (MyCar[i].Y=St1)
then:=St1-25;[i].DvigStop:=0;;(MyCar[i].NaprPryam=3) and (MyCar[i].Y=St3)
then:=St3+25;[i].DvigStop:=0;;;
MyCar[i].DvigStop=1
then[i].X:=MyCar[i].X+MyCar[i].NX;[i].Y:=MyCar[i].Y+MyCar[i].NY;;. Canvas.
Brush. Color:=clgray;. Canvas. Rectangle (MyCar[i].X-5, MyCar[i].Y-5,
MyCar[i].X+5, MyCar[i].Y+5); // Машинки(MyCar[i].X>600) or (MyCar[i].X<0)
or
(MyCar[i].Y>600) or (MyCar[i].Y<0) then
MyCar[i].NaprPryam:=0; // Если машина заехала за край то направление задается
заново
end;. Image1. Picture. Bitmap:=Mybmp;time=true
then. Canvas. Brush. Color:=clgreen;. Canvas. Ellipse (220,340,235,355); // левый правый светофоры (зеленый выкл сигнал)
Mybmp. Canvas. Ellipse (370,245,385,260);. Canvas.
Brush. Color:=clred;. Canvas. Ellipse (250,340,265,355); // левый правый свеетофоры
(красный вкл сигнал)
Mybmp. Canvas. Ellipse (340,245,355,260);.
Enabled:=true;. Interval:=11500;. Canvas. Brush. Color:=clmaroon;. Canvas.
Ellipse (263,262,248,247); // нижний верхний светофоры (красный выкл сигнал). Canvas.
Ellipse (340,340,355,355);. Canvas. Brush. Color:=cllime;. Canvas. Ellipse (263,232,248,217); // нижний верхний
светофоры (зеленый вкл сигнал)
Mybmp. Canvas. Ellipse (340,370,355,385);.
Canvas. Brush. Color:=clolive;. Canvas. Ellipse (263,247,248,232); // верхний и нижний
светофоры (желтый выкл сигнал)
Mybmp. Canvas. Ellipse (340,355,355,370);.
Canvas. Brush. Color:=clred;
Mybmp. Canvas. Ellipse (263,262,248,247); // нижний верхний
светофоры (красный вкл сигнал)
Mybmp. Canvas. Ellipse (340,340,355,355);.
Interval:=11500;. Enabled:=true;. Canvas. Brush. Color:=cllime;. Canvas.
Ellipse
(220,340,235,355); //
левый правый светофоры (зеленый вкл сигнал)
Mybmp. Canvas. Ellipse (370,245,385,260);.
Canvas. Brush. Color:=clolive;. Canvas. Ellipse (235,340,250,355);. Canvas.
Ellipse (355,245,370,260); // левый правый светофоры (желтый выкл сигнал). Canvas.
Brush. Color:=clmaroon;
Mybmp. Canvas. Ellipse (250,340,265,355); // левый правый
светофоры (красный выкл сигнал)
Mybmp. Canvas. Ellipse (340,245,355,260);.
Canvas. Brush. Color:=clgreen;. Canvas. Ellipse (263,232,248,217); // нижний верхний
светофоры (зеленый выкл сигнал)
Mybmp. Canvas. Ellipse (340,370,355,385);;z=800
thentime=true then:=false;time:=true;:=250;:=250;:=350;:=350;i:= 0 to 55 do
MyCar[i].DvigStop:=1;:=0;;:=z+1;;