Применение сетей петри в разработке многопоточного программного обеспечения с ограниченными разделяемыми ресурсами на примере центров дистанционного управления и контроля

Выводы State Space (Статистика) Status: Full Nodes: 33093 Arcs: 149580 Пространство состояний модели вычислено полностью и содержит 33093 узла и 149580 дуг. Свойства обратимости Home Markings All Dead Markings None Все маркировки являются «домашними» - мо­дель обратима. «Мертвые» маркировки отсут­ствуют – в модели нет тупиков. Свойства живучести Dead Transition Instances None Live Transition Instances All «Мертвых» переходов нет. Все переходы «живые». Во время сеанса связи возникают все события. Свойства ограниченности – верхние и нижние границы: числовые и мультимножеств Best Integer Bounds (Upper,Lower), Best (Upper,Lower) Multiset Bounds IDackRec 1 0 End 3 0 Ringing 2 0 ………………………… IDackRec 1`(1,(1,1))++1`(2,(1,1)) LineBusy 1`1++1`2 ………………………… Сеть ограниченная, с границами равными 3 –для места End, 2 – для места Ringing, 1 – для места IDackRec и т.д., что соответствует исход­ным данным. На основании данных верхних границ мультимножеств мест делаем вывод о наличии в местах меток в соответствии с пра­вилами функционирования модели. Fairness Properties (справедливость срабатывания переходов) Busy Just DialN Impartial MeetMeTone Fair End No Fairness Справедливость срабатываемости перехода Busy обоснована, перехода Impartial – объек­тивна, MeetMeTone – доказана, а перехода End – и остальных переходов не доказана. Несмотря на широкие возможности пакета «CPN Tools», ввод исходных данных и вывод результатов значительно замедляет процесс. Кроме того, пакет имеет ограничение на размер пространства состояний. Для преодоления этого ограничения, повышения эффективности моделирования и, как следствие, ана­лиза, предлагается набор программных решений. Он позволяет легко манипу­лировать исходными данными для создания их различных комбинаций при по­мощи таблицы Microsoft Excel и получать автоматически набор текстовых файлов, которые загружаются в модель при помощи кодовых сегментов (рис.1). Помимо автоматизации это позволяет решить проблему «взрыва» пространства состояний, легко управляя его сложностью при масштабировании модели. Рис.1. Компоненты технологии инициализации модели Результаты представленного во втором разделе исследования и предло­женные технологические и программные решения обеспечивают разработчика эффективным автоматизированным инструментом создания надежного ПО. В третьем разделе предлагается итерационная методика для этапа ана­лиза многопоточного ПО с ограниченными разделяемыми ресурсами, основан­ная на создании и аттестации (validation) набора UML-диаграмм данного этапа с помощью раскрашенных иерархических сетей Петри. Шаг 1. На диаграмме вариантов использования отразить функциональ­ное назначение системы (в процессе сбора требований). Шаг 2. На диаграммах последовательности детализировать критичные ва­рианты использования. Шаг 3. На диаграмме процессов отразить процесс и все необходимые по­токи для проектируемого многопоточного программного модуля. Шаг 4. На диаграммах деятельности отразить последовательность выпол­нения действий процессом и потоками, а также их взаимодействие при использовании критических ресурсов с учетом элементов синхронизации. Шаг 5. Диаграммы деятельности преобразовать в раскрашенную иерархи­ческую сеть Петри с помощью определенного набора правил. Шаг 6. Исследовать правильность функционирования модели путём выпол­нения прогона (simulation) с использованием различных комбинаций исходных данных по различным последовательностям выполнения. При обнаружении ошибки выполнить переход на шаг 4,3,2,1 в зависимости от типа ошибки. Шаг 7. Анализ корректности набора отчетов о полном пространстве со­стояний с различными комбинациями исходных данных. При обнаружении ошибки выполнить переход на шаг 4,3,2,1 в зависимости от типа ошибки. Шаг 8. Выполнить этап проектирования с помощью полученного набора UML-диаграмм. Шаги 1 и 2 широко используются в разработке ПО, и их применение в ра­боте не рассматривается. На третьем шаге методики предлагается шаблон диа­граммы процессов (рис. 2). Как и все последующие диаграммы, она ориентиро­вана на ЦДУК. Количество потоков ожидания зависит от количества каналов (устройств) связи. Количество потоков опроса зависит от количества управляе­мых устройств, но при большом интервале между сеансами связи (опросами), достаточном для опроса всех устройств, может использоваться один поток. Рис.2. Шаблон диаграммы процессов службы управления и контроля Рис.3. Детализация деятельности потока слежения и передачи команд На четвертом шаге методики на диаграммах деятельности детализиру­ются особенности алгоритмической реализации каждого потока. Предлагается использовать траекторию объектов для отображения критических секций, фла­гов, семафоров и других элементов синхронизации работы параллельных пото­ков с указанием места взятия и отдачи ресурса для ка­нала передачи, соединения с БД и флага работы службы (рис. 3). Ресурс с множеством экземпляров помечается как Multiple instances для отличия объектов с единич­ными и множественными экземплярами, учета этой особенности при преобра­зовании в сеть Петри и выборе элемента синхронизации доступа к ресурсу. Предложенные шаблоны UML-диаграмм для ЦДУК и правила их по­строения являются новым результатом, готовым к практическому применению. На пятом шаге диаграммы деятельности преобразуются в раскрашенную иерархическую сеть Петри, реализуемую в пакете CPN Tools. Элементы диа­грамм деятельности преобразуются в соответствующие эквиваленты сети Петри. Известные правила преобразования диаграмм деятельности в ординар­ную сеть Петри были систематизированы, и на их основе предложены четыре правила преобразования основных элементов диаграммы деятельности и соз­даны ещё три правила для преобразования элементов синхронизации многопо­точного приложения и выделения процессов и потоков в страницы сети Петри. Рис.4. Страница службы управления и контроля Пример применения предложенных правил проиллюстрирован на рис.4 для главной страницы модели службы контроля и управления. Флаг работы службы bWorking реализован как место слияния, так как он используется для синхронизации потоков. Такое решение предлагается применять для всех эле­ментов синхронизации и ссылок на общие данные объекта класса «родителя» и классов «потомков». Работа потоков, инициализации и останова отражена в виде составных переходов с соответствующими подстраницами. На шестом и седьмом шаге работа с сетью Петри выполняется с различными комбинациями исходных данных. «Прогон» модели позволяет разработчику лучше понять функционирование системы и выявить очевидные ошибки. Далее выполняется генерация отчета по полному пространству состояний и по результатам его анализа принимается решение о правильности модели. Приведенные в данном разделе примеры страниц сети Петри имеют свою практическую ценность и могут быть использованы в качестве шаблонов при анализе требований к службе управления и контроля. Использование предло­женных страниц инициализации и завершения службы, в дополнение к основ­ным страницам сети Петри, позволяет провести тщательное исследование вари­антов поведения системы при различных комбинациях исходных требований. В четвёртом разделе предлагается итерационная методика для этапа проектирования многопоточного ПО с ограниченными разделяемыми ресур­сами, основанная на создании и аттестации набора UML-диаграмм проекта с помощью раскрашенных иерархических сетей Петри. Шаг 1. Создать диаграмму классов с учетом процессов и по­токов, отображенных на диаграмме процессов, реализуемых как активные классы. Задача запуска потока работы с управляемыми объектами при создании экземпляра класса и его останова при завершении работы программного модуля (удалении экземпляра класса) возлагается на активный класс. Шаг 2. Создать диаграмму состояний для каждого класса, отражающую последовательность состояний, в которые попадает класс при его создании, уда­лении и вызове его методов с учетом использования элементов синхронизации потоков, доступа к ресурсам и флагов, влияющих на ход выполнения методов. Шаг 3. Отобразить на диаграмме последовательности взаимодействие классов с указанием вызовов конструкторов, деструкторов, методов классов. Шаг 4. Преобразовать каждую диаграмму состояний в страницу раскра­шенной иерархической сети Петри с помощью определенного набора правил. Шаг 5. Объединить все полученные страницы раскрашенной иерархиче­ской сети Петри в единую сеть с помощью страницы связки, реализуемой на основании диаграммы последовательности. Шаг 6. Исследовать правильность функционирования модели в процессе выполнения прогона (simulation) модели по различным последовательностям выполнения. При обнаружении ошибки выполнить переход на шаг 4,3,2,1 в за­висимости от типа ошибки. Шаг 7. Проанализировать корректность отчета о полном пространстве со­стояний модели. При обнаружении ошибки выполнить переход на шаг 4,3,2,1 в зависимости от типа ошибки. Шаг 8. Выполнить автоматическую генерацию проекта и реализацию кода на основании созданного и аттестованного набора UML-диаграмм проекта. Применение методики проиллюстрировано на примере разработки ПО ЦДУК. На первом шаге в качестве шаблона диаграммы классов службы управ­ления и контроля предлагается диаграмма, представленная на рис.5. Класс CControlService создает и удаляет набор экземпляров класса CDevice, пре­доставляющего интерфейс доступа к управлению устройством связи, приемом и передачей данных в виде функций: SendData(…) – отправить данные, GetData(…) – получить данные и т.д. На класс CDevice ложится задача син­хронизации доступа к разделяемым ресурсам: каналам приема/передачи уст­ройства связи и соединению с базой данных для чтения и записи данных. Класс CDevice является контейнером для активных классов CThread1 и CThread2, реализующих логику работы с объектами управления. Применение данной архитектуры предоставляет разработчику системы удобный механизм синхронизации и управления процессом создания и уничтожения объектов. Рис.5. Диаграмма классов службы управления и контроля ЦДУК На втором шаге каждая функция класса создается как составное состоя­ние с детализацией ключевых моментов в выполнении функций, связанных с синхронизацией потоков, созданием и удалением объектов классов. Предлагае­мая диаграмма состояний класса CControlService (рис.6) построена с учетом максимальной приближенности к исходному коду функций класса. Рис.6. Исходная диаграмма состояний класса CControlService Разработанный набор UML-диаграмм является новым результатом, гото­вым к практическому применению, и может быть использован в качестве шаб­лона при разработке ПО ЦДУК. Его состав является базовым и достаточным для автоматической генерации проекта и реализации кода функций, выпол­няющего синхронизацию потоков, создание и удаление классов. Четвертый шаг методики выполняется в два этапа с помощью предла­гаемого в работе набора правил, которые, в отличие от метода формализации UML-диаграмм сетью Петри, предложенного в работах S.M. Shatz и Z.Hu (2003-2006), учитывают особенности проектирования и реализации многопо­точных приложений, особенности пакета CPN Tools. Дополнительно предла­гается выполнять следующие действия: 1) список событий для классов предста­вить в виде таблицы (событие, связанные с событием классы и описание собы­тия); 2) для уменьшения пространства состояний модели исключить состояния, не участвующие в синхронизации потоков, передаче управления, создании и уда­лении классов, разделении критических ресурсов; 3) при создании двух (и более) экземпляров класса показывать создание одного экземпляра, а наличие других при необходимости моделировать в сети Петри с помощью дополнительных цветов меток; 4) каждый переход ассоциировать с событием, при этом вызовы ме­тодов классов, представленные в виде вызова функций, заменить генерируе­мыми для соответствующих классов событиями, а если метод класса использу­ется несколькими функциями, то в событие добавляется параметр, который указывает на вызвавшую данное событие функцию. Рис.7. CPN страница класса CControlService Представленные техноло­гии описания событий, их параметров и построения промежуточных диаграмм состояний позволяют значительно упростить и ускорить моделирование. Созданные правила для преобразования элементов синхронизации мно­гопоточного приложения и организации структуры сети Петри позволяют, в от­личие от упомянутого в шаге 4 подхода, отразить особенности функционирова­ния многопоточного объектно-ориентированного ПО, работающего с ограни­ченными разделяемыми ресурсами. Полученная путем их применения CPN страница класса CControlService приведена на рис. 7. Место bWorking яв­ляется местом слияния страницы класса CControlService и активных классов. Указанный вариант реализации (на пятом шаге) места-накопителя InternalLinking как места слияния и использование условий ограничений на переходах inside позволяет значительно упростить страницу связки или во­все отказаться от её использования в отличие от упомянутого подхода. На шестом и седьмом шаге выполняется работа с сетью Петри. Произво­дится «прогон» модели и генерация отчета по пространству состояний. В слу­чае отсутствия расхождений свойств модели с требованиями к ПО выполняется автоматическая генерация проекта и реализация кода на основе созданного и проверенного набора UML-диаграмм проекта. Приведенные примеры страниц сети Петри имеют свою практическую ценность и могут быть использованы разработчиками систем в качестве шаб­лона при моделировании проектов служб управления и контроля. Предлагаемая методика позволяет создать проект на языке UML и дока­зать правильность функционирования спроектированных классов разрабаты­ваемого многопоточного ПО, обеспечив тем самым надежность его функцио­нирования. Применение методики продемонстрировано на примере проекта службы управления и контроля ЦДУК, имеющем несо­мненную практическую ценность как шаблона (типичного образца проектиро­вания). В пятом разделе продемонстрировано применение результатов, получен­ных в разделах 2, 3, 4 при разработке ПО ЦДУКТ и ДЦ БРЗ. Применение в процессе разработки ПО предложенной в разделе 3 мето­дики позволило представить алгоритмы управления и контроля в виде набора UML-диаграмм, провести их исследо­вание и анализ различных аспектов. На ос­новании предоставленных разработчиками управ­ляемого оборудования требований, в виде словесного описания и блок-схем алгоритмов обмена данными, были сформулированы требования к ПО и проверены с помощью сетей Петри. Предложен и проверен набор UML-диаграмм этапа ана­лиза. Приведена полная модель от диаграммы вариантов использования и диа­грамм последовательности важных прецедентов до реализованных в CPN Tools страниц сети Петри модели службы управления и контроля. На основа­нии её анализа сделано заключение об отсутствии проблем в функционирова­нии алгоритмов работы, построенных в соответствии с требованиями к ПО и согласованных с заказчиком, позволяющее использовать эти алгоритмы для проектирова­ния и реализации ПО. В частности, в основу ПО ЦДУКТ была заложена много­уровневая архитектура «клиент-сервер», позволяющая быстро и легко реализовывать любую конфигурацию – от локального варианта для небольшой таксофонной сети до корпоративной информационной системы. Непосредственное моделирование и анализ протокола связи и логики функционирования с помощью сети Петри по­зволило тщательно исследовать все особенности сеанса связи таксофонов и ЦДУКТ и реализовать в проекте оптимальную архитектуру сервера сбора дан­ных и алгоритмы. Применение методики, предложенной в разделе 3, позволило провести всестороннее исследование алгоритмов работы в рамках архитектуры с учетом требований к многопоточному программному модулю управления и контроля, выявить ошибки в требованиях к системе и получить алгоритмы, готовые к реализации в функциях классов. Модели, полученные на этапе сбора требования и анализа, послужили ос­новой для фазы проектирования. В данном разделе представлены и описаны UML-диаграммы проекта службы управления и контроля и модель сети Петри, разработанные автором в соответствии с методикой раздела 4. Описан процесс разработки ПО на этапе проектирования. Приведена диаграмма классов, список событий классов службы управления и контроля, диаграммы состояний классов и страницы реализованной в CPN Tools модели сети Петри с описанием особенностей реализации диаграмм и модели, и результаты анализа сети Петри. Применение предложенной в разделе 4 методики позволило проверить важные для безотказной работы службы управления и контроля свойства модели, отра­жающей функционирование многопоточного программного модуля, представ­ленного в виде набора UML-диаграмм проекта, и обеспечить правильность и стабильность его функционирования. На основе диаграмм проекта с помощью CASE средства «Rational Rose 2003» была выполнена генерация каркаса кода проекта службы управления и контроля для инструментальной среды Visual C++ 6.0 и реализация кода. В Приложениях даны основные определения и свойства раскрашенных сетей Петри, приведены рекомендации по повышению эффективности модели­рования и анализа в пакете CPN Tools и модели ПО ДЦ БРЗ, представлены акты о внедрении результатов диссертационной работы.

Похожие:

	Методические рекомендации по разработке индивидуальных учебных планов... Рекомендовано к печати учебно-методическим советом Института непрерывного образования		Программа по формированию навыков безопасного поведения на дорогах... ОС, сред и систем программирования, и практическим навыкам создания и использования эффективного программного обеспечения для управления...
	Тематический план Введение. Предмет курса и его связь со смежными... Целью изучения дисциплины является получение общих представлений о содержании и тенденциях развития базовых информационных технологий...		Формирование конкурентной стратегии на предприятиях сферы услуг (на... Охватывает в совокупности финансовые и нефинансовые показатели деятельности предприятий сферы услуг (на примере розничных торговых...
	Доклад «О состоянии и проблемах осуществления государственного, муниципального контроля» ...		2 2 Ключевые вопросы сопровождения программного обеспечения 152 Программная инженерия и сущность инженерного подхода к созданию программного обеспечения 9
	Государственное образовательное учреждение высшего професионального образования В настоящее время невозможно отрицать потребность системы образования в средствах обеспечения дистанционного обучения. Внедрение...		Программа текущего контроля успеваемости студентов по пм02 Разработка,... Осударственного образовательного стандарта (далее – фгос) по специальности среднего профессионального образования (далее – спо) 09....
	Применение программного обеспечения «skype» в развитии коммуникативных...		План работы на декабрь 2010 года Участие в работе учебного (модульного) очно-дистанционного семинара по теме «Информационно-коммуникационные технологии на основе...
	История развития методологии тестирования при разработке программного обеспечения” Санкт Петербургский государственный университет информационных технологий механики и оптики		Алгоритмы безопасного перехода в сетях петри для лицензионной защиты программных систем Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей
	Дипломная работа посвящена программной реализации и экспериментальному... Дипломный проект посвящен разработке программного комплекса для оптимизации размещения устройств регулирования напряжения в электроэнергетике...		Рабочая программа учебной дисциплины технологии разработки программного обеспечения Охватывает данный подход? Какие модели используются в качестве функциональных спецификаций при структурном подходе? Какие характеристики...
	Рабочая программа дисциплины Целью дисциплины является изучение принципов и методов аппаратного и программного обеспечения систем управления технологическим оборудованием...		Реферат Данная работа посвящена разработке программного обеспечения... В главе 1 рассмотрены задачи автоматизации процессов Оператора связи, а также важность вопроса обеспечения автоматизированного тестирования...