Разработка программы для реализации редактора временных графов синхронизации
Математическое моделирование дискретно-событийных динамических систем как одно из направлений науки теории управления. Анализ отличительных особенностей графического интерфейса реализованного программного редактора временных графов синхронизации.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 29.06.2016 |
Размер файла | 830,7 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru
Размещено на http://www.allbest.ru
Введение
Математическое моделирование дискретно-событийных динамических систем является относительно молодым направлением науки теории управления. Разработка математического аппарата активно шла в 80-х годах, и хотя проблемой занимались как советские учёные, так и французские, именно теория французов продолжила развитие и на данный момент является одним из базовых инструментов моделирования дискретно-событийных динамических систем (Discrete-Event Dynamic Systems, DES).
Под дискретно-событийными системами подразумеваются динамические асинхронные системы, изменение состояния которых происходит под воздействием событий, возникающих в дискретные промежутки времени. В современном мире примерами таких систем могут служить гибкие производственные системы (Flexible Manufacturing Systems, FMS), системы контроля трафика, различные вычислительные среды и т.п.
Событием называется начало или конец какой-либо активности, например, для FMS это начало или завершение работы над деталью, для многопоточной вычислительной среды это начало или завершение потока вычислительного процесса.
Данная работа ориентирована, в первую очередь, на аналитический подход к моделированию дискретно-событийных систем, так как при таком подходе предоставляется возможность производить анализ статически, выполняя, например, символьные вычисления в линейной алгебре, без симуляции построенной модели и траты циклов процессора. Такой метод анализа является перспективным, согласно обзору наиболее востребованных аналитических методик моделирования DES.
Примеры вопросов, ответы на которые можно получить мгновенно при таком подходе:
§ В данном временном промежутке, сколько раз произойдёт событие заданного типа?
§ В какой момент времени событие заданного типа произойдёт в N-ный раз?
§ При наличии информации о графике подачи ресурсов на вход заданной системы, вычислить информацию о графике получения готовой продукции на выходе заданной системы;
§ Обратная задача: если установлено самое позднее допустимое время получения готовой продукции на выходе, рассчитать самое позднее возможное время подачи ресурсов на вход;
§ А также: если ресурсы на входе всегда доступны, рассчитать длительность производственного цикла и темп. Заодно вычисляется информация о критических путях (critical paths) и узких местах (bottlenecks) системы.
Программное средство, разрабатываемое в данной работе, призвано объединить два метода моделирования DEDS -- первый, классический, это сети Петри, а точнее их подкласс -- временные сети Петри. Второй метод -- специальной аппарат идемпотентной алгебры (алгебра диоидов), с использованием которого нелинейная в обычной алгебре модель может быть представлена в линейном виде, к которому применимы классические методы линейной алгебры. Их дуализм будет рассмотрен нами позже, после описания каждого метода по-отдельности это станет очевидным.
Основной акцент в программе и в данном документе сделан на двух главных составляющих инструмента -- редакторе временных сетей Петри, позволяющем задать модель системы, а также редакторе входных данных, позволяющем задать информацию о событиях, возникающих на входах системы. Сами символьные вычисления в специальной алгебре выполняются при помощи сторонней библиотеки, разработанной французами -- авторами теории. Допускается рассматривать данное программное средство как оболочку, призванную упростить взаимодействие специалистов с данной библиотекой.
1. Методы и инструменты моделирования
1.1 Обоснование выбранного метода
При дизайне системы согласно требованиям или при оптимизации существующей необходимо ввести модель, позволяющую не только представлять знания о свойствах и поведении системы, но и имеющую инструменты для предсказания производительности разрабатываемой системы. На данный момент существует множество техник моделирования и анализа дискретно-событийных динамических систем (DEDS), хорошую подборку известных методов можно найти в источниках работы-обзора. Методы делятся на две категории -- аналитические и имитационные, при выборе подходящего метода важно учитывать то, что чем точнее модель соответствует процессам, тем меньше свойств можно вычислить аналитически. На данный момент самой распространённой техникой является компьютерное моделирование (computer simulation), что относится к имитационному подходу и имеет существенные недостатки: во-первых, из требования повышенной точности модели вытекает трудоёмкость вычислений, во-вторых, мы не всегда можем понимать, как изменение параметров системы влияет на показатели вроде стабильности и производительности -- например, достигли ли мы локального максимума производительности или абсолютного? Поэтому активно разрабатываются аналитические подходы, позволяющие использовать математические модели и алгебраические инструменты при решении задач моделирования, поскольку к таким моделям могут быть применены эффективные оценочные алгоритмы и могут быть установлены точные причины влияния параметров системы на её свойства.
В самом же обзоре рассмотрены самые эффективные методы из набора аналитических, в частности это аппарат сетей Петри, позволяющий, с одной стороны, графически смоделировать модель, более-менее адекватную процессу, а с другой, такой аппарат хорошо подходит для обработки алгоритмами в программах. Другой метод, использующий специальную идемпотентную алгебру max-plus, подразумевающую замену обычного сложения на операцию , а операцию произведения на обычный +, используется для особого класса дискретно-событийных систем, которые представляются нелинейно в обычной алгебре, но могут быть смоделированы линейно в алгебре max-plus. Последователем алгебры max-plus является другая диоидная алгебра, min-max, с историей которой можно ознакомиться по ссылке. Далее в работе речь идти будет именно об этом варианте.
Учитывая степень проработанности теоретической базы, возможность применения подкласса сетей Петри для графического моделирования системы вместе с ней, а также существование программной реализации основных вычислительных алгоритмов, ориентирование программного продукта на использование в первую очередь именно с этими методами является целесообразным.
1.2 Сети Петри и классификация
Сеть Петри это двудольный направленный граф с маркировкой, ребра которого задают причинно-следственные отношения «события-условия» и именуются дугами. Первый тип вершин -- позиции -- представляют условия, а второй тип вершин -- переходы -- представляют события. Динамика сетей задаётся при помощи маркировки позиций фишками.
На рис. 1 и 2 представлен пример сети Петри, до и после срабатывания перехода. В классических сетях Петри при срабатывании перехода по всем входящим дугам из позиций снимается по одной фишке, а во все позиции по исходящим дугам помещается по одной фишке. Переход срабатывает только тогда, когда во всех входящих позициях есть минимум одна фишка.
Рисунок 1. Сеть Петри, до срабатывания перехода
Рисунок 2. Сеть Петри, после срабатывания перехода
Временные сети Петри.
Временные сети Петри -- это такой подкласс сетей Петри, в которых допустимо помимо фишек маркировать вершины параметром временной задержки (holding time). В данной работе рассматривается временная задержка только для позиций. Когда фишка попадает в позицию с задержкой , должно пройти тактов, прежде чем фишка сможет участвовать в активации перехода и покинуть позицию. Пример простой очереди представлен на рис. 3: событие означает начало работы с клиентом, срабатывает только при выполнении двух условий -- кто-то ждёт в очереди (фишка в соответствующей позиции) и активность кассы, что обусловлено дугой активации . сработает, когда фишка клиента пребудет достаточное время в кассе, то есть два тика. После завершения работы с клиентом, по дуге активации фишка готова будет активировать .
Вход системы и выход для наглядности показаны другим цветом.
Рисунок 3. Модель окошка кассы, построенная временной сетью Петри
Временные графы синхронизации.
В англоязычной литературе используется термин Timed Event Graphs (TEG) и наиболее точный перевод может быть именно таким. Итак, временные графы синхронизации это подкласс временных сетей Петри, предназначенный, как следует из названия, для моделирования лишь явлений синхронизации в системе. Отличает этот класс от вышеописанного дополнительное условие, гарантирующее, что каждая позиция имеет ровно одну исходящую дугу и ровно одну входящую (SISO). Это делает модель непригодной для описания явлений одновременности, исключает возможность возникновения конфликтов и тупиков (deadlocks). Но зато данный вариант может быть описан специальной диоидной алгеброй, при чём состояние системы в любой момент времени может быть вычислено при помощи линейных методов.
1.3 Алгебра диоидов
Множество D с двумя заданными на нём операциями (плюс) и (умножение) называется диоидом, если выполнены следующие аксиомы:
§ Ассоциативность.
§ Коммутативность сложения.
§ Левая дистрибутивность (умножение не обязано быть коммутативным).
§ Только левая, поскольку умножение не обязано быть коммутативным.
§ Существование нулевого элемента и единицы ( и соответственно).
§ Поглощающий нуль.
§ Идемпотентность сложения ().
Поэтому иначе можно сказать, что диоид это идемпотентное полукольцо, но из-за сходства с моноидами, где операция одна, авторы назвали эту структуру диоидом.
Далее возьмём множество двоичных значений и обозначим как множество всех степенных рядов с неизвестными и , двоичными коэффициентами и степенями из , с двумя заданными операциями и .
Таким образом, множество всех степенных рядов вида:
где , является диоидом. Существует отображение .
Замыкание Клини (“звёздочка”) определяется как бесконечная сумма:
где:
.
Для уравнения верно, что:
§ Частным решением является ;
§ Если является решением, то ;
1.4 Информация о событиях
Когда мы говорим о типе события, для временных графов синхронизации подразумеваются события срабатывания переходов и тип ассоциируется с именем сработавшего перехода. Для перехода мы рассматриваем “фрагменты информации” о событиях как целочисленные пары . Во временном графе синхронизации фрагменты информации переносятся от входящих переходов к исходящим, на каждом переходе происходит объединение фрагментов информации. Принцип объединения продемонстрирован на рис. 4 и 6, до срабатывания перехода и после, соответственно.
Рисунок 4
Рисунок 5. Объединение информации
Очевидно, что после срабатывания перехода, в соответствии с правилами работы сети, информация со входящих дуг объединяется по принципу и , где и это информация, представленная фишками и задержкой соответствующих позиций в определённый момент времени.
Возвращаясь к алгебре диоидов, определим операции и :
(1)
Таким образом, объединение информации теперь можно выполнять при помощи методов линейной алгебры на множестве диоидов. При использовании умножения, и задают сдвиг, например сдвиг по времени: сдвинет информацию, доступную при срабатывании перехода , на 6 временных тиков. Знак умножения, как и в обычной алгебре, можно опустить.
Пары чисел , при условии, что все события пронумерованы целыми числами, интерпретируются как «событие с номером случилось не раньше времени » или «на момент времени , номер последнего случившегося события не больше ».
При объединении информации некоторые фрагменты могут быть полностью доминировать над другими. Для наглядности представим юго-восточные конусы на декартовой плоскости на рис. 6. представьте точку , тогда по формуле (1):
Возвращаясь к определению множества , которое представляет все возможные ряды, в том числе с избыточной информацией. Поэтому авторы теории фильтруют при помощи отношения эквивалентности так, чтобы в итоговом фактормножестве остались лишь неубывающие ряды без избыточной информации (рис. 8). Обозначается как -- читается min max gd.
Рисунок 6. Конусы и на плоскости раздельно
Рисунок 7. Доминирование после объединения
Рисунок 8. Объединение без доминирования
1.5 Сравнение аналогов
Поскольку конечной целью работы был редактор сетей Петри, интегрированный с внешней библиотекой алгебраических вычислений, было рациональным рассмотреть существующие редакторы сетей Петри, пригодные для модификаций и дополнения недостающим функционалом.
Некоторые варианты отклонялись сразу же, по причине недоступности исходного кода или из-за использованного стека технологий -- например, .NET, Java, в сочетании с неудобными интерфейсами. Если в случае .NET о кроссплатформенности не может идти и речи, то в случае с Java трудности могут возникнуть при интеграции библиотеки libminmaxgd[10, 16], реализованной на C++. Особенно, если учитывать качество исполнения этих существующих решений. Фактически, проблемы у всех одни и те же, но некоторые программы можно выделить как более-менее пригодные к использованию, хотя, к сожалению, миссии данной работы они посодействовать никак не смогут.
Petri Net Toolbox.
Популярное расширениедля MATLAB, обладает хорошим набором функционала, поддерживаются разные типы (т.е. наборы правил) сетей Петри, имеется интеграция с алгебраическим аппаратом max-plus, что приближает это решение к целям данной работы. Но плагин является платным, исходный код недоступен. Сам MATLAB также является платным и довольно большим комплексом программ, что отметает данный вариант. Во-вторых, использовать данный плагин без модификаций невозможно, скриншот программы представлен на рис. 9.
Рисунок 9. Petri Net Toolbox
PIPE v4.3.
Пожалуй, самое проработанное решение из доступных, разрабатывалось с 2003 по 2011 год разными специалистами из разных университетов, некоторые интегрируют это решение с MATLAB. Данный редактор выполнен качественно, большинство опций интерфейса (рис. 10) работают, сама программа стабильна -- установка и запуск прошли гладко, работе ничего не мешает. К недостаткам данного приложения можно отнести:
Интерфейс и управление слишком перегружены, а редактирование сети осуществляется исключительно при помощи мыши. На 10 позиций, 10 дуг и 10 переходов пришлось 120 нажатий мыши. При этом скопировать уже созданную структуру невозможно.
Слишком общий подход. Нельзя выбрать конкретный набор правил организации сети, то есть система автоматически предлагает подкрутить вес дуги, разрешает делать позициям несколько входящих дуг и так далее.
В то же время, некоторые опции оказываются недоступными или проработаны недостаточно хорошо -- каждый элемент автоматически снабжается видимой подписью, хотя в большинстве случаев важна именно маркировка, а не имя. Позициям нельзя назначать временную задержку.
Навигация по полотну затруднена, полотно ограничено слева-сверху, значит сеть при росте может упереться в край и нужно будет сдвигать;
У программы проседает производительность даже на относительно небольших сетях, что при наличии процессора Intel i5 (1.7GHz) ставит под сомнение оптимальность реализации;
При желании, список можно было бы продолжить, но ключевая цель программы -- облегчить пользователю работу с алгебраическими инструментами, выполнена по всем признакам недостаточно хорошо.
Рисунок 10. PIPE в действии
Romeo.
Ещё одно популярное решение для построения и верификации сетей Петри. К программе написано несколько инструментов для интеграции с другими проектами, но сама программа обладает недостаточным качеством исполнения, устаревшим подходом к разработке графического интерфейса (используются Tcl/Tk). Более того, в отличие от предыдущего решения функционала здесь меньше, но стабильность программы страдает -- при осуществлении бытовых операций иногда возникают неприятные внутренние ошибки (рис. 11 и 12). Кстати, код написан частично на французском, поэтому модифицировать его для своих нужд де-факто не удастся. Положительным моментом является наличие возможности копировать отдельные участки сети, идея хорошая.
Рисунок 11. Romeo в действии
Рисунок 12. Или нет
После рассмотрения как и отрицательных, так и положительных сторон у существующих решений, а также после согласования требований научным руководителем, был составлен список функциональных требований, которым должна удовлетворять создаваемая программа.
Графическое задание временной сети Петри. Возможность добавлять элементы сети, соединять дугами, устанавливать начальную маркировку позиций с указанием задержки и фишек, снабжать элементы сети именами/комментариями. Полотно должно быть условно-бесконечным без ограничения перемещения в любую из 4х сторон, должно обладать возможностью масштабировать отдельно взятые участки относительно произвольного центра. Поддержка формирования и расформирования изолированных групп элементов, с целью скрыть детали реализации участков сети и для создания множества участков сети с единой конфигурацией. Поддержка копирования участков сети и групп с сохранением настроек дуг (контрольные точки для кривых) и настроек внешнего вида элементов (комментарии, ориентация, и т.д.). Должна иметься возможность снятия скриншота как минимум видимой области с последующим сохранением в файл. Возможность сохранять созданную сеть в файл и загружать из файла.
Редактор информации о входящем потоке событий. Как в графическом режиме (расстановка конусов на плоскости), так и при помощи символьного описания элементов . Добавление точек, выделение точек, перемещение точек, применения замыкания Клини к выделенной коллекции точек, отображение информации для каждого перехода (входы системы) в отдельном слое. Этот же редактор в режиме read-only должен обеспечивать просмотр информации о событиях на выходе системы.
Интеграция с библиотекой символьных вычислений в диоидной алгебре и разработка с учётом необходимости подключения дополнительных модулей в дальнейшем.
2. Технологии, Архитектура, алгоритмы программы
2.1 Стек технологий
При выборе стека технологий основное внимание уделялось следующим факторам, в порядке убывания значимости:
§ Кроссплатформенность;
§ Поддержка взаимодействия с нативными библиотеками (C/C++);
§ Современные средства для создания графических интерфейсов пользователя с поддержкой аппаратного ускорения отрисовки;
§ Хорошая известность в сообществе разработчиков, то есть наличие хорошей документации и решений к часто встречающимся проблемам (не всегда тривиальным).
Qt Framework и QtQuick.
Единственным решением, которое проходит по всем поставленным критериям, является Qt Framework, на текущий момент самое полноценный инструмент для кроссплатформенной разработки. Последняя мажорная (5ая) версия предоставляет большое количество полезных возможностей.
Во-первых, есть QtQuick, позволяющий описывать интерактивные пользовательские интерфейсы с нетривиальной логикой при помощи декларативного языка разметки QML. QML использует подмножество JavaScript для логики интерфейса, вроде привязки действий к событиям, выполнения различных функций, обращения к модели данных и так далее.
Во-вторых, в последних минорных версиях значительно улучшилась поддержка интеграции с нативными компонентами родительской OS, таким образом, не смотря на полностью самостоятельный интерфейс (с самостоятельно нарисованными кнопками), у разработчика есть возможность вызвать нативный диалог сохранения файла или разместить на форме нативно выглядящие кнопки и флажки.
В-третьих, не смотря на возможность интеграции системных компонент, разрабатываемое с применением технологии QtQuick приложения является полностью независимым от платформы и может быть запущено под Windows, OSX, Linux, iOS, Android и так далее. К сожалению, QtQuick и JS не подходят для написания сложных вычислительных процессов, которые должны работать максимально быстро и эффективно расходовать память. Поэтому в части QtQuick реализовано лишь “лицо” программы.
Go lang.
Основная же часть кода написана на статически типизированном, компилируемом, высокопроизводительном языке программирования Go от компании Google, который стал доступен общественности совсем недавно, в 2011 году. Причиной этому послужили несколько факторов, например разработка с использованием Qt Framework идёт на C++, когда дело доходит до внутренних механизмов прикладного приложения. C++, несомненно, имеет множество преимуществ с технической точки зрения, но на практике всё перекрывается чрезмерной низкоуровневостью языка, медленной скоростью компилятора, запутанным стандартом и взамен C++ не даёт ничего, что могло бы дать прикладному приложению с графическим интерфейсом какое-либо преимущество.
С языком Go ситуация другая. Сам язык разрабатывался с учётом опыта других языков программирования, вбирая в себя только то, что прошло проверку временем и доказало свою эффективность. Отличительными чертами Go являются прагматичность, малый размер стандарта, заморозка API стандартной библиотеки, быстрая скорость компиляции, runtime-производительность на уровне Java или C++, возможность низкоуровневых вызовов и компоновки с объектными файлами, полученными в результате компиляции C/C++.
В отличие от других языков программирования, легковесные потоки являются одним из базовых примитивов языка. Для синхронизации процесса выполнения различных частей программы между собой и для обмена данными в языке применяются каналы. Эти возможности активно использовались при разработке приложения.
Go-qml.
В компании Canonical с 2012 года планомерно идёт перевод нескольких крупных проектов с Python на Go, и одновременно c этим Qt Framework является базой для многих клиентских разработок Canonical, начиная от библиотек интеграции с обачными сервисами, заканчивая прикладными приложениями рабочего стола. Важность и возможность взаимодействия Go и Qt сыграли свою роль и усилиями сотрудника компании появился инструмент go-qml, позволяющий производитеь операции с Qt-объектами и реализующий необходимые «мосты» для запуска QtQuick с логикой на стороне Go. Таким образом, выбранный стек технологий позволяет создать пользовательское приложение, одинаково работающее на трёх основных OS, использующее самый продвинутый инструментарий разработки GUI и один из современных и перспективных языков для внутренней логики.
2.2 Архитектура и компоненты
Приложение разрабатывается в соответствии с паттерном проектирования Model-View-Presenter (MVP), который является производным от Model-View-Controller (MVC) и предназначается для использования при написании приложений с графическим интерфейсом. Особенности такого подхода заключаются в следующем:
§ Модель полностью изолирована и является исключительно предметно-ориентированной. Фактически, модель можно использовать в отрыве от интерфейса, например при встраивании в другой инструмент;
§ Presenter извлекает данные из модели и форматирует их для отображения в представлении. В данном случае из внутреннего представления модели сети Петри генерируются наборы графических примитивов, которые рисуются покоординатным способом на стороне отображения, без учёта предметной области. В то же время Presenter занимается обработкой пользовательских событий, поступающих из отображения -- нажатие мышкой, нажатие клавиши и так далее. После обработки события Presenter изменяет модель;
§ Отображение отвечает за пользовательский интерфейс -- отрисовки окна, формы, кнопок и других элементов приложения в операционной среде. Здесь также обрабатываются события, поступающие от операционной среды и в зависимости от типа передаются Presenter'у. Отображение ничего не знает о предметной области, но тем не менее логика пользовательского интерфейса реализуется частично на его стороне (JavaScript, QtQuick).
Иллюстрация находится на рисунке 13.
Рисунок 13. Model-View-Presenter
Компоненты на стороне Go.
Исходя из поставленных задач и списка необходимого функционала, приложение поделено на следующие компоненты (пакеты):
tegview -- изолированный пакет редактора сети Петри, внутри построен при помощи паттерна MVP, на Go написаны Model и Presenter. Первое окно программы создаётся именно на основе этого модуля. Из окна tegview может вызываться открытие других окон tegview для групп и открываемых файлов.
planeview -- изолированный пакет редактора входных данных, реализует отображение конусов на плоскости и их редактирование, написан по подобию tegview, используется паттерн MVP, на Go написаны Model и Presenter. Из окна tegview вызывается открытие окон planeview.
render -- пакет с типами графических примитивов и методами для работы с ними.
geometry -- пакет с типами геометрических примитивов и методами для работы с ними.
dioid -- пакет для работы с диоидной алгеброй. Включает в себя парсер выражений вида «g3d2 + g4d7 + g3d4 x (g1d2)*», обёртку над библиотекой libminmaxgd, декларацию типов для внутреннего представления элементов алгебры.
workspace -- пакет для управления набором открытых окон, реализован с целью контролировать максимальное количество открытых одновременно окон (существует намеренное ограничение в go-qml, при необходимости можно обойти), также обеспечить корректное завершение приложения после закрытия последнего окна.
util -- пакет вспомогательных утилит: реализация стека, генератор UUID, конвертер hex-представления цвета из формата RGB в ARGB.
Компоненты на стороне QtQuick/QML
TegView -- реализация вида, компонент унаследован от QtQuick-компонента ApplicationWindow. Содержит инструментальную панель, панель статуса, полотно с отображением модели (сеть Петри).
PlaneView -- аналогично TegView. Содержит инструментальную панель, панель статуса, текстовое поле для редактирования элементов степенного ряда, панель выбора активного слоя и изменения видимости других, область менеджера слоёв.
Plane -- менеджер слоёв на декартовой плоскости. Каждый слой отображает модель (коллекцию точек) в виде конусов на плоскости, по ТЗ эти слои должны накладываться друг на друга. Содержит корневой слой (отображающий координатную сетку, оси, подписи) и коллекцию слоёв, построенных по модели в Presenter'е.
PlaneLayer -- отображение слоя. Содержит полотно и методы, рисующие графические примитивы из кешированной коллекции. Коллекция кешируется на стороне QML/JavaScript из-за особенностей управления памятью при передачи объектов из Go в QML. В любом случае, без него новые данные будут заменять старые прямо в процессе отрисовки, что неправильно.
XButton, XToggle -- самостоятельная реализация кнопки (с поддержкой иконок) и кнопки-выключателя.
2.3 Геометрические алгоритмы
Поворот точки относительно центра на заданный угол:
X = o.X + (p.X-o.X) * cos(angle) - (p.Y-o.Y) * sin(angle)
Y = o.Y + (p.X-o.X) * sin(angle) + (p.Y-o.Y) * cos(angle)
где o.X, o.Y -- координаты центра поворота, p.X, p.Y -- координаты исходной точки, angle -- угол. Алгоритм применяется при повороте стрелки направления дуги вокруг центра позиции.
Точка на окружности с заданным отступом:
angle := math.Atan2(x-c.X, y-c.Y)
dX := (c.r + distance) * math.Sin(angle)
dY := (c.r + distance) * math.Cos(angle)
где c.X, c.Y, c.r -- координаты центра и радиус окружности, distance -- отступ от дуги окружности; x,y -- координаты направляющей точки. В сочетании с предыдущим алгоритмом позволяют ориентировать указатель дуги как показано на рис. 14.
Рисунок 14. Поворот стрелки в заданном точкой направлении, с заданным отступом от дуги окружности
Проверка пересечения двух прямоугольников:
RectA.X1 < RectB.X2 && RectA.X2 > RectB.X1 &&
RectA.Y1 < RectB.Y2 && RectA.Y2 > RectB.Y1
где RectA, RectB -- заданные прямоугольники. Используется при выделении элементов (рис. 15).
Рисунок 15. Пересечение прямоугольной части перехода инструментом выделения
Проверка пересечения двух отрезков на плоскости:
x0, y0, x1, y1 := p0.X, p0.Y, p1.X, p1.Y
x2, y2, x3, y3 := p2.X, p2.Y, p3.X, p3.Y
sx1 := x1 - x0
sy1 := y1 - y0
sx2 := x3 - x2
sy2 := y3 - y2
s := (-sy1*(x0-x2) + sx1*(y0-y2)) / (-sx2*sy1 + sx1*sy2)
t := (sx2*(y0-y2) - sy2*(x0-x2)) / (-sx2*sy1 + sx1*sy2)
if s >= 0 && s <= 1 && t >= 0 && t <= 1 {
return true
}
где p0, p1 -- концы первого отрезка; p2, p3 -- концы второго. Используется при удалении дуг методом “отрезания” огибающих ломанных. На рис. 16 дуга будет удалена, на рис. 17 -- нет.
Рисунок 16. Удаление дуги
Рисунок 17. Отрезки не пересекаются
3. Особенности реализации
3.1 Пример с tegview
¦ L-- qml
¦ +-- tegrender.js
¦ L-- tegview.qml
+-- tegview
¦ +-- controller.go
¦ +-- model.go
¦ +-- renderer.go
¦ L-- view.go
Здесь, если брать модель MVP, роль Presenter распределена по файлам controller.go, view.go и renderer.go. Модель описана в файле model.go, а отображение выполнено на QML и JavaScript в файлах tegrender.qml и tegrender.js соответственно. Находится в соседней ветке (для возможности работать с QML в отдельном редакторе QtCreator).
§ view.go -- точка входа, отвечает за окно с редактором. Создаёт пустую модель, создаёт экземпляр контроллера, загружает QML файлы и отображает в окне QtQuick-сцену. Создаёт два отдельных потока -- в одном следит за изменениями в модели, во втором -- запускает процесс рендеринга при получении изменений в первом потоке. То есть, обработка изменений модели задействует дургое ядро, отличное от того, на котором запущен GUI-поток;
§ model.go -- представляет собой модель участка сети Петри (вся сеть целиком -- тоже участок), хранит наборы позиций, переходов, групп (в каждой группе -- своя дочерняя модель), набор выделенных элементов, набор информаци о событиях на входе (набор степенных рядов, ассоциированных с каждым из входов системы);
§ render.go -- генерирует набор буферов с графическими примитивами по модели. Внешний вид отображаемой сети Петри зависит от состояния модели, конечно, но в большей степени он задан в процедурах рендера. На данном этапе рендер генерирует примитивы совместимые с API Context2D у Canvas в QtQuick. Нет технических преград дополнить рендер возможностью генерировать примитивы совместимые с OpenGL и SVG.
§ controller.go -- в отдельном потоке получает пользовательский ввод, в зависимости от нажатых клавиш, состояния модели, состояния контроллера выполняет операции над моделью. Также здесь определён специальный объект, видимый из отображения. Через него контроллер считывает некоторые важные параметры отображения (например, коэффициент масштабирования сцены, который вычисляется средствами QtQuick и JavaScript). Также у отображения есть возможность напрямую вызывать публичные методы контроллера, например метод, отвечающий за открытие нового окна (используется в качестве обработчика события нажатия кнопки в интерфейсе приложения).
§ tegview.qml -- декларативное описание интерфейса приложения, немного логики на JavaScript, в основном это привязки обработчиков к событиям. При получении сигнала от контроллера о том, что новый буфер графических примитивов готов для отрисовке на полотне, создаёт кэш на стороне JavaScript.
§ tegview.js -- итерирует элементы кэша и непосредственно выполняет отрисовку графических примитивов в соответствии с параметрами.
Редактор точек на плоскости фактически унаследован от редактора сети Петри, общий принцип взаимодействия компонент одинаков. Конкретные отличия стоит сравнивать в коде. Например, вместо одного слоя в редакторе используется несколько слоёв, поэтому код контроллера и QML части значительно увеличился в объёмах.
3.2 Графический интерфейс программы
Рисунок 18. Графический интерфейс реализованного редактора временных графов синхронизации
дискретный графический интерфейс программный
Рисунок 19. Графический интерфейс реализованного редактора информации о событиях на входах системы
Заключение
Результатом выполнения задания является реализованный редактор временных графов синхронизации (класс временных сетей Петри), соответствующий задачам, поставленным в постановке задачи. Редактор информации о событиях с поддержкой вычислений в диоидной алгебре. Произведена интеграция обоих компонент в виде общей прикладной программы с возможностями строить модель любой сложности и смотреть зависимость значений на выходе от значений на входе.
Как и упоминалось в начале этой работы, результат может быть использован как замена существующим решениям для редактирования сетей Петри, а интеграция с математическим аппаратом диоидной алгебры может служить хорошим примером такой интеграции. Здесь стоит сделать акцент на том, что это интерфейс для “боевой” вычислительной библиотеки и вполне “боевой” редактор временных сетей Петри, то есть после выявления и исправления существующих недочётов, программа способна лечь рядом со “взрослыми” изделиями для решения задач в данной области применения.
Помимо улучшения документации и исправления недочётов, в данном направлении есть ещё задачи, над которыми следует продолжить работу. Так, на данный момент отрисовка сети происходит в программном режиме на растровой поверхности довольно медленного полотна. Здесь напрашивается аппаратное ускорение и использование OpenGL, но из-за нестабильности связки Go+QML+OpenGL на данном этапе этот вопрос был отложен. Помимо отображения сети в программе, следовало бы добавить возможность сохранять построенную сеть в виде дерева SVG, что позволит добавлять построенные графы напрямую в научно-технические работы, свёрстанные в LaTeX. Соответствующий код для этого уже подготовлен, но из-за разности API у Canvas2D и у SVG требуется дополнительное время на тестирование, чтобы внешний вид совпадал в обоих случаях.
Помимо сохранения в виде картинок, дополнительной задачей является сохранения сети в распространённые форматы, пригодные для импорта в среды вроде MATLAB, Scilab и им подобным. Например, для некоторых существующих аналогов имеются скрипты для конвертации, которые пользуются спросом, но реализованная в данной работе программа сохраняет исключительно в свой формат и пока к интеграции не готова.
Литература
1. Авдошин С.М. Оптимизация гибких производственных систем // 1987.
2. Лескин А.А. Алгебраические модели гибких производственных систем // 1986.
3. Baccelli F.L. и др. Synchronization and linearity. Wiley New York, 1992.
4. Ben-Naoum L. и др. Methodologies for discrete event dynamic systems: A survey // Journal A. 1995. Т. 36. № 4. С. 3-14.
5. Bonet P. и др. Platform Independent Petri net Editor 2.
6. Bonet P. и др. PIPE v2. 5: A Petri net tool for performance modelling // Proc. 23rd Latin American Conference on Informatics (CLEI 2007). , 2007.
7. Cohen G. и др. A linear-system-theoretic view of discrete-event processes and its use for performance evaluation in manufacturing // Automatic Control, IEEE Transactions on. 1985. Т. 30. № 3. С. 210-220.
8. Cohen G. и др. Algebraic tools for the performance evaluation of discrete event systems // Proceedings of the IEEE. 1989. Т. 77. № 1. С. 39-85.
9. Cohen G., Gaubert S., Quadrat J.-P. Max-plus algebra and system theory: where we are and where to go now // Annual Reviews in Control. 1999. Т. 23. С. 207-219.
10. Cottenceau B. и др. Data processing tool for calculation in dioid // Proceedings of WODES'2000, Workshop on Discrete Event Systems., 2000.
Размещено на Allbest.ru
Подобные документы
Изучение особенностей растровых и векторных графических редакторов. Создание графического редактора: выбор языка программирования, разработка структуры программы и алгоритма работы. Описание интерфейса программы. Руководство программиста и пользователя.
курсовая работа [1,3 M], добавлен 28.07.2013Разработка и реализация графического редактора сетей Петри. Описание программы, которая позволяет создавать новые сети путем добавления позиций и переходов, соединяя их определенным образом. Основы построения систем автоматизационного проектирования.
курсовая работа [2,6 M], добавлен 21.06.2011Особенности создания ряда игровых приложений, логической игры. Программное обеспечение простейшего калькулятора, генератора функций. Разработка элементов интерфейса простейшего графического редактора, электронной записной книжки, текстового редактора.
методичка [788,7 K], добавлен 24.10.2012Основные понятия и определения теории графов: теоремы и способы задания графа, сильная связность графов. Построение блок-схем алгоритма, тестирование разработанного программного обеспечения, подбор тестовых данных, анализ и исправление ошибок программы.
курсовая работа [525,6 K], добавлен 14.07.2012Изучение основных алгоритмов генерации различных видов фракталов. Выбор языка и среды программирования. Характеристика структурных элементов растрового графического редактора фракталов. Описание интерфейса приложения, порядок редактирования изображений.
курсовая работа [1,2 M], добавлен 04.04.2014История возникновения, основные понятия и теоремы теории графов. Способы предоставления графов в компьютере. Матрица смежности, инциденций, списки смежности и массив дуг. Программа определения кратчайшего пути в графах. Язык программирования Delphi.
курсовая работа [823,5 K], добавлен 24.11.2010Функции программного интерфейса операционной системы Windows, предназначенные для работы с семафорами. Средства синхронизации Win32 АРI, основанные на использовании объектов исполнительной системы с дескрипторами. Проблемы при использовании семафоров.
реферат [67,4 K], добавлен 06.10.2010Основные понятия теории графов. Ценность системного подхода. Представления операций во времени. Структурно-лингвистическое (знаковое) моделирование. Формы и средства графического представления информации. Методы формализованного представления систем.
курсовая работа [2,2 M], добавлен 15.06.2015Возникновение информатики во второй половине XX столетия. Теория графов. Понятие и терминология теории графов. Некоторые задачи теории графов. Математическая логика и теория типов. Теория вычислимости и искусственный интеллект.
реферат [247,4 K], добавлен 15.08.2007Функционально-структурная организация персонального компьютера. Операционная система Windows. Функции стандартизации программы графического редактора Paint. Рисование геометрических объектов и оформление рисунков с помощью графического редактора Paint.
курсовая работа [680,1 K], добавлен 03.12.2008