Содержание к диссертации
Введение
1. Методологические и технологические особенности разработки многопоточного программного обеспечения: центрыдистанционного управления и контроля 16
1.1 Архитектура и особенности функционирования многопоточного программного обеспечения: центры дистанционного управления и контроля 18
1.2. Анализ подходов к разработке программного обеспечения 25
1.3. Методы обеспечения правильности моделей 31
1.4. Анализ возможностей применения сетей Петри на технологическом цикле разработки программного обеспечения 37
1.5. Постановка задачи диссертационного исследования 43
2. Применение классических и раскрашенных сетей петри в моделировании и анализе многопоточного программного обеспечения на примере центров дистанционного управления и контроля 44
2.1. Применение классических сетей Петри для моделирования и анализа функционирования многопоточного программного обеспечения 45
2.2. Применение раскрашенных сетей Петри для моделирования и анализа функционирования многопоточного программного обеспечения 54
2.3. Анализ свойств раскрашенной иерархической сети Петри при моделировании функционирования реальных систем 60
2.4. Применение компьютерных инструментов для моделирования и анализа раскрашенных иерархических сетей Петри 65
2.5. Выводы 72
Применение раскрашенных иерархических сетей петри на этапе анализа 73
3.1. Методика создания и аттестации UML-диаграмм этапа анализа : 74
3.2. Шаблон UML-диаграмм на этапе анализа 77
3.3. Преобразование набора UML-диаграмм этапа анализа в раскрашенную иерархическую сеть Петри 83
3.4. Исследование модели и анализ результатов 92
3.5. Выводы 95
Применение раскрашенных иерархических сетей петри на этапе проектирования 96
4.1. Методика разработки и проверки моделей 97
4.2. Шаблон UML-диаграмм проекта службы управления и контроля 100
4.3. Преобразование набора UML-диаграмм проекта в раскрашенную иерархическую сеть Петри 106
4.4. Моделирование и анализ 117
4.5. Выводы 120
Примеры использования сетей петри в разработке центров дистанционного управленияиконтроля 122
5.1. Центр дистанционного управления и контроля таксофонов . 123
5.2. Диспетчерский центр блоков релейной защиты 132
5.2.1. Применение методики создания и аттестации модели центра дистанционного управления и контроля на этапе анализа 132
5.2.2. Применение методики создания и аттестации модели проекта центра дистанционного управления и контроля 142
5.3. Выводы 155
Заключение 156
Список использованных источников
- Анализ подходов к разработке программного обеспечения
- Применение раскрашенных сетей Петри для моделирования и анализа функционирования многопоточного программного обеспечения
- Преобразование набора UML-диаграмм этапа анализа в раскрашенную иерархическую сеть Петри
- Преобразование набора UML-диаграмм проекта в раскрашенную иерархическую сеть Петри
Введение к работе
Актуальность темы. Основная задача разработчика многопоточного (mul-tithread) программного обеспечения (ПО) с ограниченными разделяемыми ресурсами - обеспечить надежность (стабильность, устойчивость к ошибке и восстанавливаемость) функционирования ПО. Примером данного класса ПО является центр дистанционного управления и контроля (ЦДУК), предназначенный для непрерывного дистанционного контроля и управления интеллектуальным оборудованием. Процесс разработки многопоточного ПО с разделяемыми ресурсами, такого как ПО ЦДУК - нетривиальная задача. Надежность его функционирования должна быть обеспечена еще до реализации кода, в процессе создания и проверки правильности моделей- важных артефактов разработки ПО [18], от сбора требований до реализации кода. В современной индустрии ПО, при разработке ПО ЦДУК, используется объектно-ориентированный подход к анализу и проектированию (ООАП) [59] с применением языка UML (Unified Modeling Language) [60]. Некорректное представление сложных алгоритмов и механизмов синхронизации на UML-диаграммах приводит к взаимным блокировкам потоков и другим проблемам при функционировании ПО. Подобные ошибки могут обнаруживаться только при очень специфичных условиях эксплуатации ЦДУК, например центра дистанционного управления и контроля таксофонов (ЦДУКТ) и диспетчерского центра блоков релейной защиты (ДЦ БРЗ). Их трудно, а иногда невозможно воспроизвести в условиях тестовой среды.
В языке UML и CASE (Computer Aided Software Engineering) средствах на его основе, например Rational Rose [78], нет собственных средств обоснования правильности и согласованности наборов диаграмм, поэтому наибольшее внимание уделяется методам и инструментам для преобразования UML-диаграмм в сети Петри и их анализа [1, 10, 14, 20-23, 26, 28, 33-35, 52, 67]. При этом предлагаются различные расширения сетей Петри для проверки отдельных видов диаграмм [14, 23, 26, 28, 52, 67]. В решениях для совокупности диаграмм проекта [10, 33, 34] не учитываются применение программных элементов синхрониза-
8 ции и другая специфика разработки объектно-ориентированного многопоточного приложения (в частности ЦЦУК). Отсутствует описание технологий применения профессиональных, свободно распространяемых пакетов моделирования раскрашенных иерархических сетей Петри [24, 39], например CPN Tools (Coloured Petri Net), предложений по автоматизации процесса и преодоления ограничений пространства состояний модели. Всё это делает весьма затруднительным применение указанных подходов в инженерии ПО. В известных автору работах не предлагаются шаблоны (типичные образцы проектирования) моделей и кода для проектирования многопоточных системных служб управления и контроля. Отсутствуют предложения по анализу требований к многопоточному ПО с помощью совокупности диаграммы процессов и диаграмм деятельности, детализирующих алгоритмы потоков с учётом используемых при реализации кода элементов синхронизации и аттестации (validation) данного набора диаграмм с использованием раскрашенных иерархических сетей Петри.
Цель и задачи работы. Разработка методик применения сетей Петри при аттестации наборов UML-диаграмм в процессе разработки многопоточного ПО с ограниченными разделяемыми ресурсами и их применение в разработке программного обеспечения центров дистанционного управления и контроля для обеспечения надежности его функционирования.
Для достижения поставленной цели решаются следующие задачи:
исследовать и определить набор UML-диаграмм и свойств сети Петри, необходимых и достаточных для обеспечения надежности функционирования создаваемого многопоточного ПО с ограниченными разделяемыми ресурсами;
разработать методику для этапа анализа многопоточного ПО с ограниченными разделяемыми ресурсами, основанную на создании и аттестации набора UML-диаграмм данного этапа с помощью раскрашенных иерархических сетей Петри и использовании средств автоматизации разработки программ;
разработать методику для этапа проектирования многопоточного ПО с ограниченными разделяемыми ресурсами, основанную на создании и аттеста-
ции набора UML-диаграмм проекта с помощью раскрашенных иерархических сетей Петри и использовании средств автоматизации разработки программ;
разработать набор шаблонов моделей и программных решений для повышения производительности моделирования и анализа при создании программ и преодоления ограничений компьютерного пакета моделирования;
разработать ПО ЦДУКТ и ДЦ БРЗ с применением предложенных методик, шаблонов и программных решений.
Методы исследования. Результаты исследования получены на базе аппарата сетей Петри и ООАП. При разработке ПО ЦДУКТ применялись отраслевые и международные стандарты, «Концепция Единой Таксофонной Карты России». При проектировании и реализации ПО ЦДУКТ и ДЦ БРЗ использовались CASE-технологии, инструментальные среды и пакеты моделирования.
Достоверность теоретических положений, лежащих в основе предложенных в диссертации методик, шаблонов (типичных образцов проектирования) и программных решений подтверждена сертификатами соответствия и результатами успешной эксплуатацией разработанных на их основе ПО ЦДУКТ и ДЦ БРЗ.
Научная новизна. Основные результаты диссертационного исследования, имеющие научную новизну, получены для класса объектно-ориентированного многопоточного ПО с ограниченными разделяемыми ресурсами и состоят в следующем:
определены необходимые и достаточные, в отличие от известных подходов, наборы UML-диаграмм и свойства сети Петри, что позволяет при разработке данного класса ПО в процессе моделирования и анализа применять для обеспечения надежности его функционирования раскрашенные иерархические сети Петри, которые в известных подходах либо не используются, либо при их эпизодическом использовании не учитываются особенности исследуемого класса ПО;
впервые разработаны методики для этапов анализа и проектирования данного класса ПО, основанные на создании и аттестации наборов UML-диа-
10 грамм с помощью раскрашенных иерархических сетей Петри и использовании средств автоматизации разработки программ, применение которых обеспечивает устранение ошибок и несогласованности набора UML-диаграмм, отражающего требования к разрабатываемому ПО, и гарантирует надежность функционирования спроектированных классов;
впервые разработаны наборы шаблонов UML-диаграмм (типичных образцов проектирования) и страниц раскрашенных иерархических сетей Петри модели многопоточной системной службы управления и контроля, применение которых на этапах анализа и проектирования позволяет значительно сократить время разработки ПО;
разработаны шаблоны и программные решения для повышения производительности моделирования в компьютерном пакете моделирования раскрашенных иерархических сетей Петри CPN Tools, отличающиеся простотой использования и модификации под модель любой сложности. Эти шаблоны и решения позволяют при помощи управления сложностью пространства состояний модели преодолевать ограничения на его размер;
разработано и успешно внедрено в эксплуатацию ПО ЦДУКТ и ДЦ БРЗ, отличающееся высокой эксплуатационной надежностью.
Практическая ценность и внедрение. В результате применения на фазах анализа и проектирования предлагаемых методик создания и аттестации наборов UML-диаграмм программист получает автоматически сгенерированный проект и готовые к реализации в функциях классов алгоритмы, правильность которых обеспечена с помощью анализа полного пространства состояний модели на надежность функционирования и соответствие требованиям. Предложенные методики, шаблоны и программные решения позволяют значительно ускорить и облегчить процесс изготовления программ данного класса и обеспечить надежность их функционирования. Предлагаемые методики органично вписываются в принятые в индустрии ПО подходы и методы разработки и готовы к применению в условиях реальной разработки.
Результаты диссертационной работы были использованы:
при проектировании и реализации ПО ЦЦУКТ, прошедшего успешную сертификацию на соответствие концепции «Единая Таксофонная Карта России» и эксплуатационные испытания в ЗАО «Санкт-Петербургские Таксофоны», и принятого в эксплуатацию СП«Сибирьтелеком» - НГТС в 2003 г.;
при проектировании и реализации ПО ДЦ БРЗ, которое поставляется с 2007 г. в комплекте с БРЗ, выпускаемыми ФГУП ПО «Север»;
в процессе обучения студентов АВТФ НГТУ.
На защиту выносятся следующие положения:
ліетодгіка для этапа анализа многопоточного ПО с ограниченными разделяемыми ресурсами, основанная на создании и аттестации набора UML-диаграмм данного этапа с помощью раскрашенных иерархических сетей Петри и использовании средств автоматизации разработки программ;
методика для этапа проектирования многопоточного ПО с ограниченными разделяемыми ресурсами, основанная на создании и аттестации набора UML-диаграмм проекта с помощью раскрашенных иерархических сетей Петри и использовании средств автоматизации разработки программ;
набор шаблонов моделей и программных решений для повышения производительности моделирования и анализа при создании программ и преодоления ограничений компьютерного пакета моделирования;
ПО Центра Дистанционного Управления и Контроля Таксофонов;
ПО Диспетчерского Центра Блоков Релейной Защиты.
Апробация работы. Основные результаты работы были представлены на Международном научно-техническом симпозиуме KORUS (Ульсан, 2000; Томск, 2001; Новосибирск, 2002), Международной научно-технической конференции "Информационные системы и технологии" (Новосибирск, 2000), Международной научно-технической конференции "Актуальные проблемы электронного приборостроения" (Новосибирск, 2000), Ежегодной международной сибирской школе-семинаре по электронным приборам и материалам EDM'2003 (Эрлагол, 2003), Международной научно-практической конференции «Электронные средства и системы управления» (Томск, 2004), IV Сибирском кон-
12 грессе по прикладной и индустриальной математике "ИНПРИМ-2000" (Новосибирск, 2000). Материалы диссертации обсуждались в 2003 г. в университете г. Айхштет (Германия) на «The 4th Advanced Course on Petri Nets», летней школе «IFAC Summer School on Control, Computing and Communication», проходившей в 2005 г. в Чешском техническом университете (г. Прага), объединенном научном семинаре отдела МОВВС ИВМ и МГ СО РАН, кафедры параллельных вычислительных технологий НГТУ и кафедры параллельных вычислений НГУ, объединенном научном семинаре АВТФ и ФПМИ НГТУ.
Публикации. Основные положения и результаты диссертационной работы опубликованы в 29 работах [44-48, 55, 56, 63-66, 81—98], в том числе: 5 — в изданиях, рекомендуемых ВАК РФ; 14 — в сборниках научных трудов; 7 — в материалах международных симпозиумов и конференций; 3 — в материалах российских конференций.
Структура и объём диссертации. Диссертация состоит из введения, пяти разделов, заключения, списка использованной литературы, включающего 117 наименований и приложений. Общий объем работы составляет 216 страниц, в том числе основное содержание изложено на 171 странице и включает 75 рисунков, 9 таблиц и приложения размещены на 44 страницах.
Во введении обоснована актуальность темы диссертации, сформулированы цель и задачи исследования, определены научная новизна и практическая ценность работы, дана общая характеристика полученных результатов, аннотируются основные положения работы.
Первый раздел посвящен методологическим и технологическим особенностям разработки и обеспечения надежности функционирования многопоточного ПО с ограниченными разделяемыми ресурсами на примере ПО ЦДУК. Определены назначение, структура, состав и задачи разработки данного класса систем, приведены характеристики и проблемы создания реальных систем. Проведен анализ процессов, подходов, моделей разработки систем и возможностей применения сетей Петри на технологическом цикле разработки ПО. Сфор-
13 мулированы задачи обеспечения правильности моделей и проанализированы методы их решения. В разработке исследуемого класса ПО предлагается использовать ООАП с применением языка UML и CASE-средства Rational Rose в соответствии с RUP, а для аттестации наборов UML-диаграмм на фазах анализа и проектирования использовать сети Петри. Актуальность проблемы аттестации UML-диаграмм подтверждается рядом публикаций. Это необходимо для обеспечения надежности ПО, так как в UML и CASE-средствах на его основе нет собственных средств аттестации наборов диаграмм. Приведены результаты анализа применимости различных расширений сетей Петри для моделирования и анализа различных аспектов системы на технологическом цикле разработки программного обеспечения. Рассмотрены проблемы проверки наборов UML-диаграмм с применением раскрашенных иерархических сетей Петри на этапах анализа и проектирования. Описаны достоинства и недостатки известных автору подходов. Сформулированы задачи диссертационного исследования.
Второй раздел посвящен анализу возможностей применения классических и раскрашенных сетей Петри в разработке многопоточного ПО с ограниченными разделяемыми ресурсами. Проанализирована и показана на примерах связь свойств и структуры сетей Петри с функционированием моделируемой системы на примере ЦДУК. Исследован и определён набор свойств сети Петри, обязательных для обеспечения надежности функционирования создаваемого ПО. Его применение продемонстрировано на примере моделирования и анализа взаимодействия таксофона и ЦДУКТ. Проанализированы возможности пакета моделирования CPN Tools, его ограничения и пути их преодоления. В качестве одного из вариантов преодоления ограничений пакета и управления сложностью полного пространства состояний модели предлагается решение с использованием шаблонных фрагментов сети Петри, таблицы Microsoft Excel и программных решений. Определен круг задач технологического цикла разработки ПО ЦДУК, решение которых с применением аппарата сетей Петри способствует обеспечению надежности функционирования разрабатываемого многопоточного ПО.
14 В третьем разделе предлагается итерационная методика для этапа анализа многопоточного ПО с ограниченными разделяемыми ресурсами, основанная на создании и аттестации набора UML-диаграмм данного этапа с помощью раскрашенных иерархических сетей Петри и использовании средств автоматизации разработки программ, которая в отличие от неформального подхода к анализу позволяет устранять ошибки и несогласованность требований к разрабатываемому ПО. На имеющем несомненную практическую ценность как шаблона для разработчиков систем примере службы управления и контроля абстрактного ЦДУК продемонстрировано применение и работоспособность предлагаемой методики, описано назначение UML-диаграмм на каждом шаге предлагаемой методики. Предложенные правила преобразования позволяют выполнять преобразование набора UML-диаграмм фазы анализа в раскрашенную иерархическую сеть Петри и обратно. Приведенные примеры страниц сети Петри имеют свою практическую ценность и могут быть использованы разработчиками систем в качестве шаблона при анализе требований к службе управления и контроля. Описана последовательность исследования модели, даны результаты интерпретации и анализа отчета выданного пакетом моделирования. Предложенный вариант дополнения страниц модели сети Петри страницами инициализации и завершения работы службы позволяет провести тщательное исследование вариантов поведения системы при различных комбинациях исходных требований.
В четвёртом разделе предлагается итерационная методика для этапа проектирования многопоточного ПО с ограниченными разделяемыми ресурсами, основанная на создании и аттестации набора UML-диаграмм проекта с помощью раскрашенных иерархических сетей Петри и использовании средств автоматизации разработки программ, которая в отличие от неформального подхода к разработке позволяет обеспечивать надежность функционирования спроектированных классов. На примере проекта службы управления и контроля ЦДУК имеющем несомненную практическую ценность как шаблона для разработчиков систем, продемонстрированы применение и работоспособность предлагаемой методики. Предложенные правила преобразования позволяют выполнять преоб-
15 разование набора UML-диаграмм проекта в раскрашенную иерархическую сеть Петри и обратно, включая составные и исторические состояния, что позволяет выполнять проверку правильности и согласованности диаграмм любой сложности с учетом особенностей стандартных программных элементов синхронизации потоков и применения пакета моделирования CPN Tools. Приведена раскрашенная иерархическая сеть Петри для проверки правильности и согласованности UML-диаграмм проекта службы управления и контроля. Дается описание страниц модели и последовательности исследования модели. Приведены результаты анализа отчета выданного пакетом моделирования.
В пятом разделе продемонстрировано применение предложенных в разделах 2, 3, 4 методик, шаблонов моделей, технологических и программных решений на примере разработки Центра Дистанционного Управления и Контроля Таксофонов и Диспетчерского Центра Блоков Релейной Защиты. Описан процесс разработки ЦДУКТ на этапе анализа с применением предложенной в разделе 3 методики. Описана архитектура и приведена диаграмма процессов модуля сбора данных. На диаграммах деятельности показана детализация потоков и приведено их описание. Модель, реализованная в CPN Tools, представлена в виде набора страниц раскрашенной иерархической сети Петри с описанием особенностей реализации и анализа. Описан процесс разработки ДЦ БРЗ на этапе анализа с применением предложенной в разделе 3 методики от построения диаграммы вариантов использования и диаграмм последовательности важных прецедентов до страниц сети Петри модели службы управления и контроля блоков релейной защиты. Описан процесс разработки ДЦ БРЗ на этапе проектирования с применением предложенной в разделе 4 методики. Приведена диаграмма классов, список событий классов службы управления и контроля, диаграммы состояний классов и страницы модели сети Петри, реализованной в CPN Tools, с описанием особенностей реализации диаграмм и модели.
В заключении перечислены основные результаты, состоящие в разработке двух методик и наборов правил преобразования необходимых и достаточных наборов UML-диаграмм этапов анализа и проектирования в раскрашенные ие-
рархические сети Петри для их аттестации, позволяющих автоматизировать разработку многопоточного ПО с ограниченными разделяемыми ресурсами, что позволяет получать надёжное ПО. Это выгодно отличает предложенные методики от известных подходов, где наборы UML-диаграмм и правила преобразования недостаточны или избыточны, либо аттестация UML-диаграмм не используется. К основному результату относятся разработанные шаблоны моделей, технологические и программные решений, а также ПО ЦДУКТ и ДЦ БРЗ.
В приложениях даны основные определения и свойства раскрашенных иерархических сетей Петри; предложены рекомендации по повышению эффективности моделирования и анализа в пакете CPN Tools; приведены модели диспетчерского центра блоков релейной защиты; представлены акты о внедрении результатов диссертационной работы.
Анализ подходов к разработке программного обеспечения
Для того чтобы правильно выбрать модели, методы и инструменты для анализа, проектирования, реализации ПО и организовать процесс его разработки, необходимо проанализировать все аспекты развития современных методов и технологий разработки. В данном разделе применительно к разработке программного обеспечения центров дистанционного управления и контроля проводится анализ: структурного подхода, выделяющего в предметной области данные, функции и процессы; объектно-ориентированного подхода, выделяющего в предметной области объекты с их атрибутами и функциями, и описывающего взаимодействие объектов в виде сообщений; компонентного подхода, в котором крупные функциональные блоки выделяют в компоненты.
Надежность функционирования многопоточного ПО с ограниченными разделяемыми ресурсами, такого как ПО ЦДУК, должна быть обеспечена еще до реализации кода, в процессе создания и проверки правильности моделей - важных артефактов разработки ПО [18], от сбора требований до реализации кода. Большое количество методов, рекомендаций и технологий, направленных на повышение результативности и эффективности деятельности разработчиков ПО, предлагается в рамках специальной дисциплины — инженерии программного обеспечения [58, 61, 75, 79, 97]. Значительный интерес представляют те, применение которых в конкретных проектах можно поставить на строгую систематическую основу с использованием средства для автоматизации разработки ПО (Computer Aided Software Engineering - CASE) [75, 78, 97].
Структурный подход [70] лежит в основе классификации программных изделий и шаблонов с точки зрения многократного использования и предписывает выделять при декомпозиции следующие фрагменты предметной области: данные - информационные образы предметов и концептуальных взаимосвязей предметной области; функции - преобразователи одних данных в другие; про-1[ессы — описания динамической организации обработки данных посредством функций.
В рамках структурного подхода для моделирования данных используют диаграммы «сущность-связь» (Entity-Relationship Diagram, ERD) [77]. Метод моделирования с их использованием зафиксирован в стандарте IDEF1X [61, 72, 75] и поддерживается CASE-средством ERwin [61, 75]. Структурное моделирование функций выполняется при помощи метода функционального проектирования SADT (Structured Analysis and Design Technique) [61], который зафиксирован в стандарте IDEFO [61, 72, 75] и поддерживается CASE-средством BPwin [61, 75]. При моделировании процессов применяются диаграммы потоков данных (Data Flow Diagrams - DFD) [61]. Они настолько привычны и понятны, что не подвергаются стандартизации, поэтому существует несколько разновидно стей нотации DFD. Одна из них поддерживается в BPwin. Хотя структурный подход с применением CASE-средств от Computer Associates [61, 75] помогает создавать ПО, отличающееся высоким качеством, его трудно использовать естественным образом в разработке ПО ЦДУК вследствие его сложности и ряда особенностей.
При разработке ПО ЦДУК необходимо учитывать тот факт, что практически у всех объектов предметной области данные и функции неразделимы. Например, канал сбора данных должен быть самодостаточным и включать все необходимые для проведения сеанса связи данные, отличимые от других каналов, и функции. Многие объекты имеют общую основу, и их частные случаи можно создавать небольшой модификацией обобщающего объекта. Например, устройства и протоколы работы с ними имеют много общего, а частные случаи и новые устройства и протоколы требуют лишь небольшой модификации.
Реализовать эти особенности естественным способом позволяет объектно-ориентированный подход (ООП) к разработке ПО с помощью инкапсуляции, наследования и полиморфизма.
Объектно-ориентированный подход [59] предписывает выделять объекты - минимальные автономные подобласти, в которых присутствуют данные (атрибуты) и функции (методы), вместо отдельного указания данных, функций и процессов. Среди статических взаимосвязей между объектами особо выделяется иерархическое классификационное отношение частное-общее, описываемое как наследование, причем применительно не к конкретным объектам, а к классам — типам объектов. Сами объекты вступают в такие отношения (ассоциации), как часть-целое (агрегация), использование и др. Взаимодействие объектов описывается в терминах обмена сообщениями между объектами. Для записи различных моделей, получающихся в результате объектной декомпозиции, применяется графический язык UML [60], позволяющий составлять диаграммы восьми типов, перечисленные в таблице 1.1.
Применение раскрашенных сетей Петри для моделирования и анализа функционирования многопоточного программного обеспечения
Многопоточное ПО с ограниченными разделяемыми ресурсами, в частно-, сти ПО ЦДУК, характеризуются сложностью алгоритмов и механизмов синхронизации потоков. При моделировании реальной системы классическая сеть Петри получается очень большой, что значительно затрудняет ее анализ. Дополнительной проблемой является невозможность моделирования многих аспектов объектно-ориентированных моделей, служащих основой для реализации. Например, события и методы класса могут иметь параметры, для отображения которых нужны метки сложных (составных) типов. Для решения данной проблемы и многих других при моделировании ПО применяют различные расширения сетей Петри [23, 30, 99], удовлетворяющие специфическим потребностям практически любой области применения инженерии ПО [9, 20, 21, 23, 35, 48], такие как высокоуровневые, объектно-ориентированные, временные, стохастические. Наиболее широкое применение среди разработчиков разнообразного ПО нашли раскрашенные сети Петри в силу естественности представления типов данных, используемых в программировании, возможности иерархического представления, обогащения временем для анализа производительности и под держки компьютерными пакетами моделирования [24, 39]. В данном разделе дается неформальное введение в раскрашенные сети Петри применительно к разработке ПО ЦДУК, рассматриваются раскрашенные иерархические сети Петри и их свойства, важные для анализа функционирования многопоточного ПО ЦДУК. Формальное определение раскрашенных (цветных) сетей Петри приведено в приложении 1.
Модель раскрашенных сетей Петри оперирует с метками различных цветов (типов). Понятие цвета маркера аналогично понятию типа в программировании и может быть как простым: BOOL, INT, STRING и т.д., так и составным (например (INT, STRING)) подобно структурам и классам. Функция цвета (типа) ограничивает множество цветов (значений типа) маркеров для каждого места. В раскрашенной сети Петри, представленной на рис.2.8, место «Receivers» имеет простой тип (цвет) Receiver порожденный от INT — целые числа. Четыре метки с номерами устройств приема от 1 до 4 в начальной маркировке места Receivers представлены в модели в виде мультимножества: Г1++Г2++ГЗ++Г4, где значения меток разделены ++, а перед знаком " указывается количество меток с данным цветом. Тип места Channels- Channel также порожденный от INT. Остальные места, и соответственно их метки, имеют составной тип. Тип места Devices - Device состоит из двух компонент: номера управляемого устройства -тип NUM (от INT) и номера протокола - тип Protocol. Тип места PreparingSet -это пара (Device, Receiver) — (устройство, устройство приема). Тип Session мест ID_sending, SetReceived и DataReceived - это тройка (Device, Receiver, Channel). В модели может быть объявлена переменная любого типа и так же, как в любом языке программирования, из переменных могут составляться выражения дуг, кодовых сегментов и функций «охраны» переходов. В сети Петри (рис.2.8) переменные d, г, с, dr имеют тип соответственно Device, Receiver, Channel, DR, a s,sl,s2 тип Session. Функции «охраны» переходов (условия срабатывания) позволяют переходу выполниться только при соблюдении дополнительных условий. В сети Петри (рис.2.8) переход Synchronize срабатывает только для устройства с протоколом №2, а переход SendData для устройств с протоколом, отлич ным от №2. Кодовые сегменты переходов являются важной дополнительной возможностью управления не только поведением сети, но и вводом/выводом данных в файл. Пример использования кодовых сегментов приведен в приложении 2.
В раскрашенной сети Петри, представленной на рис.2.8, моделируется пример обмена данными между управляемыми устройствами и ЦДУК по простейшему алгоритму. В данном примере протоколы с 1 по 4 являются идентичными, за исключением последнего этапа, где выполняется синхронизация данных для устройств с протоколом №2 и передача данных от устройств с другими протоколами. В реальных системах [90] обмен данными происходит одновременно по нескольким протоколам, каждый из которых имеет свой уникальный, довольно сложный алгоритм обмена данными, вьшолнение которого зависит от многих факторов. Моделирование подобной системы раскрашенной сетью Петри по изложенному выше (рис.2.8) принципу приведет к разрастанию сети до необозримых размеров и объему написания различных условий, соизмеримому с написанием программы. Для решения данных проблем применяются раскрашенные иерархические сети Петри [36]. Это позволяет [38, 86, 90-96] структурировать модель, упростить ее зрительное восприятие, тем самым упростив и ее анализ.
В раскрашенной иерархической сети Петри логически автономная часть модели заменяется составным переходом и реализуется в виде отдельной страницы сети Петри, которая позволяет более полно детализировать данный переход, не усложняя при этом саму сеть. Связь страниц осуществляется при помощи механизма портов - входных/выходных мест подстраницы составного перехода и сокетов - входных/выходных мест составного перехода на основной странице. Основная страница и подстраница перехода Protocol2 иерархической сети для нашего примера (рис.2.8) представлены на рис. 2.9 и 2.10. Страницы соединяются при помощи входного порта Connected и выходных портов Devices и Receivers подстраницы составного перехода (рис.2.10) и сокетов Connected, Devices и Receivers основной страницы (рис.2.9).
Преобразование набора UML-диаграмм этапа анализа в раскрашенную иерархическую сеть Петри
На пятом шаге диаграммы деятельности преобразуются в раскрашенную иерархическую сеть Петри, реализуемую в пакете CPN Tools. Элементы диаграмм деятельности преобразуются в соответствующие эквиваленты сети Петри. В литературе описывается ряд правил [26, 28, 67] по преобразованию диаграмм деятельности в ординарную сеть Петри. Для их применения в рамках поставленной задачи правила были систематизированы и на их основе развиты и предложены представленные ниже правила преобразования диаграмм деятельности в раскрашенную иерархическую сеть Петри R1-R4 и дополнены правилами R5-R7 для преобразования элементов синхронизации многопоточного приложения и выделения процессов и потоков в страницы сети Петри.
Предлагается [91] следующий набор правил преобразования диаграмм деятельности в раскрашенную иерархическую сеть Петри:
R1. Состояние ожидания преобразуется в место, а состояние действия преобразуется: в переход, начинающий действие; место, отражающее состояние выполнения действия; переход, завершающий выполнение действия.
R6. Семафор (для моделирования занятости конкретного ресурса из пула ресурсов) преобразуется в место с соответствующим количеством меток отличимых друг от друга цветов в начальной маркировке. Пример преобразования приведен на рис.3.10. Семафор «Канал связи» преобразуется в место «Channels» типа CHANNELS (colset CHANNELS = index с with 1..8;) - набора значений от 1 до 8 с начальной маркировкой CHANNELS.all() - все значения цветового множества. Когда потоку необходим канал для передачи команды и получения ответа, метка с произвольным (свободным) индексом извлекается из места и возвращается при завершении её использования. Для простого считающего семафора используются метки одного типа, а их количество в начальной маркировке равно числу ресурсов;
Пример преобразования приведен на рис.3.11. «Главный процесс», «Поток передачи» и «Поток слежения» реализованы в виде отдельных страниц. «Поток передачи» замещается страницей составного перехода DoSending, а «Поток слежения» замещается страницей составного перехода DoMonitoring. Наличие составных переходов на главной странице позволяет упростить восприятие модели и отобразить функциональность.
Рассмотрим применение предложенных правил на примере преобразования UML-диаграмм этапа анализа, представленных на рис.3.3-3.5 для службы управления и контроля абстрактного ЦДУК из раздела 3.1. На рис. 3.12-3.14 представлены страницы раскрашенной иерархической сети Петри, (соответствующие диаграммам на рис.3.3-3.5) реализованной в пакете CPN Tools.
Особенностью страницы службы управления и контроля (рис.3.12) является флаг работы службы bWorking, реализованный как место слияния, так как он используется для синхронизации потоков №1 и №2. Такое решение предлагается применять для всех глобальных переменных, элементов синхронизации нескольких потоков и ссылок на общие данные объекта класса «родителя» и классов «потомков». Составные переходы InitService и StopService используются соответственно для инициализации модели и очистки мест перед новым запуском и реализуются в соответствии с решениями, предложенными в приложении 2.
Рис.3.12. Страница службы управления и контроля После выполнения перехода InitService данные модели загружены и необходимые места сети Петри инициализированы. Далее последовательно срабатывают переходы Start_threadl и Start_thread2 запуска потоков Threadl и Thread2, выполняющих основную работу службы. После этого служба может быть в любое время остановлена срабатыванием перехода SetStop, так как в начальной маркировке место StopCommand имеет метку. При этом сбрасывается флаг работы службы bWorking, что является «командой» останова для потоков Threadl
Преобразование набора UML-диаграмм проекта в раскрашенную иерархическую сеть Петри
При преобразовании вызовов функций синхронизации и создании объектов класса критической секции предлагаются следующие упрощения: вызовы функций работы с семафором WaitForSingleObject (ChSemaphore, INFINITE) и ReleaseSemaphore(ChSernaphore,l, NULL) заменяются на соответствующие действия переходов WaitSemaphore и relSemaphore, а создание объектов класса CSAutolock (блокировка критической секции) и их уничтожение заменено на действия Lock и Unlock. Все эти действия будут преобразованы далее в специальные конструкции сети Петри.
Диаграмма состояний класса CThread2 Предлагается использовать составные состояния на промежуточных диаграммах для облегчения визуального восприятия модели и учета критических секций, необходимых для блокировки последовательности состояний и семафоров, ограничивающих доступ к пулу ресурсов. При этом каждая дуга, входящая в составное состояние, соединена с начальным состоянием составного перехода, а конечное состояние соединено с выходной дугой. Если переход, входящий в составное состояние и переход, исходящий из начального состояния составного перехода, генерируют события, то при упрощении необходимо указать генерацию двух событий или ввести новое промежуточное состояние. Данное правило применяется при отображении состояния, имеющего вьшолняемые действия или генерирующего события при входе или выходе из состояния, а также при наличии ситуаций: входной переход и переход от стартового состояния составного состояния отправляют события; переход от конечного состояния составного состояния и выходящий переход отправляют события. Это позволит избежать лишних временных затрат при переводе в CPN-модель. Таким образом значительно облегчается восприятие модели без нарушения правил преобразования сложных состояний, изложенных в [33].
Далее диаграмма состояний каждого класса реализуется как CPN страница в пакете CPN Tools. Для применения в рамках нашей задачи правила преобразования, изложенные в [33], были систематизированы, и на их основе развиты и предложены правила преобразования набора диаграмм состояний в раскрашенную иерархическую сеть Петри R5, R11, и дополнены правилами R6-R10 для преобразования элементов синхронизации многопоточного приложения, отражения особенностей функционирования системной службы и упрощения сети Петри. Предлагается производить преобразование по следующим правилам:
R1. Состояние отображается в место;
R2. Переход диаграммы состояний отображается в переход сети Петри;
R3. События отображаются в метки, которые будут храниться во входном месте и использоваться как условия срабатывания переходов, а действия в метки, которые будут генерироваться и сохраняться в месте, распределяющем события;
R4. Тип события состоит из трех компонент: событие, параметр и признак события: / — внутреннее или е - внешнее;
R5. Для каждой страницы создается место ED - место-накопитель меток-событий, из которого, при помощи условий переходов mln и mOut метки направляются в место входных событий класса IP или в место-накопитель внешних событий — IntemalLinking, являющегося местом слияния для всех страниц классов;
R6. Дополнительный фильтр событий может быть установлен добавлением цвета (параметра) в цвет (тип) событий;
R7. Считающий семафор, ограничивающий доступ к пулу ресурсов, отображается в место с начальным количеством меток, равным количеству ресурсов;
R8. Выполнение критической секции, блокирующей доступ в конструкторе и разблокирующей в деструкторе, моделируется с помощью изъятия/возврата метки в место сети Петри, отражающее соответствующую критическую секцию;
R9. Флаг работы службы реализуется как место слияния цвета BOOL, общее для всех использующих его потоков;
R10. Каждая внутренняя переменная, используемая для синхронизации завершения работы активного класса, отображается на CPN странице как место-переменная и используется как условие для срабатывания переходов опроса состояния класса и завершения работы;
R11. С помощью диаграммы последовательности страницы классов соединяются в единую модель . Для этого задаются условия срабатьшания перехода inside для каждого класса, что обеспечивает попадание в класс только его событий.
