Ступина А.А. Моделирование управляемых процессов. Лабораторный практикум

Подождите немного. Документ загружается.

дартов для разработки телекоммуникационных систем: SDL, MSC и т.д. Тре-

тье направление развивает структурные методологии разработки программ-

ного обеспечения: SADT, IDEF-стандарты, метод Йордана и т.д. В настоящее

время эти методологии прочно закрепились в области разработки информаци-

онных систем. Они являются эффективным средством анализа систем в целом

и успешно применяются.

Например, методология Real основывается, главным образом, на UML,

SDL, ROOM и отражает перечисленные интеграционные тенденции. Помимо

стандартных для объектно-ориентированного подхода черт в Real добавлены

дополнительные возможности, направленные на две специальные области

программного обеспечения – для информационных систем и для систем ре-

ального времени.

Real не претендует на то, чтобы покрыть все возможности программ-

ных продуктов соответствующих областей. Однако, учитывая современный

уровень развития локальных и глобальных информационных сетей и возрас-

тающую сложность программного обеспечения, в информационных системах

все большую популярность приобретает технология клиент-сервер, т.е. мно-

гие информационные системы приобретают ярко выраженный событийно-

ориентированный аспект, который глубоко проработан в методологиях разра-

ботки программного обеспечения систем реального времени. С другой сторо-

ны, большие распределенные системы реального времени нуждаются в хране-

нии, доступе и передаче не только управляющих сигналов и данных трафика,

а, как правило, и огромного количества информации (например, тарификаци-

онной и аутентификационной). Методология Real подходит для разработки

программного обеспечения обеих областей, но наиболее эффективна для их

пересечения.

Разработка программного обеспечения систем реального времени

в методологии Real

Основное назначение Real применительно к системам реального време-

ни – проектирование сложной управляющей логики с последующей возмож-

ностью автоматической генерации кода. Методология не ориентирована спе-

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

непосредственно с ним контактирующего (драйверов устройств и т.п.), а так-

же сетевых протоколов нижнего уровня, но для этих задач она подходит при-

мерно в той же, степени, как и UML.

Как показывает практика, прямые ветки сложных алгоритмов достаточ-

но удобно и наглядно определять с помощью сценариев. На начальных этапах

разработки системы нужно четко определить логику всех взаимодействий.

При этом правила поведения системы в ошибочных ситуациях в большинстве

случаев можно доработать позднее. По сценариям можно сгенерировать STD-

или SDL-диаграммы и продолжить создание спецификаций уже в этом стиле,

учитывая все допустимые варианты поведения системы.

В терминах Real основной структурной единицей системы реального

времени является объект. Объекты взаимодействуют друг с другом через ин-

терфейсы. Под взаимодействием понимается посылка сообщений, вызов ме-

тодов и обращение к атрибутам интерфейса. Поскольку в последнее время все

большее число систем реального времени становятся распределенными и се-

тевыми, понятие интерфейса приобретает особую важность. Интерфейсы Real

сильно отличаются от портов (gate) SDL (составом, способом связи с класса-

ми) и интерфейсов UML (составом, способом связи с классами, способом

изображения), а также интерфейсов в ROOM (составом и способом изображе-

ния).

В системах реального времени важную роль играют абстракции точек

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

в модель классов Real был добавлен из ROOM специальный элемент – порт.

Компонента программного обеспечения, определенная в виде класса с

портами и интерфейсами, может иметь конечно-автоматное поведение, опи-

сываемое в терминах поведенческой модели Real. Поведенческая модель, в

свою очередь, представляется двумя альтернативными нотациями: первая

основана на варианте STD, представленном в ROOM, вторая — на расширен-

ном конечном автомате SDL. С помощью STD-нотации удобно определять

поведение компонент системы на ранних этапах разработки: множество мел-

ких деталей можно временно убрать из поля зрения. В то же время на SDL-

диаграммах можно наглядно изобразить мельчайшие подробности алгорит-

мов.

Эта возможность становится полезной на поздних этапах проектирова-

ния. При этом информацию, изображенную на STD-диаграммах, можно ”за-

грузить” на SDL-диаграммы, таким образом, результаты ранних этапов при

переходе к более формальной спецификации не будут потеряны. В рамках

Real, STD и SDL нотации предназначены для описания единой поведенческой

модели, так что всегда возможно и обратное - загрузка на STD-диаграмму ре-

зультатов работы с SDL-редактором. На поведенческую модель Real сильно

повлияла технология SDL/PLUS 20: так же не используются типы данных и

выражения SDL, но применяется более гибкая стратегия связи с языками реа-

лизации вместо заранее фиксированного языка.

Использование специальной событийно-ориентированной методологии

разработки программного продукта поможет улучшить стройность организа-

ции прикладного приложения и, в целом, хорошо отразится на надежности

создаваемой системы реального времени.

Пакет «NVS-Designer» для автоматизированного формирования

мультиверсионного ПО

Одним из направлений интенсификации производства ПО является ори-

ентация средств его создания на специалиста проблемной области. Существу-

ет ряд отечественных и зарубежных систем, в которых акцент смещается на

инструментальные средства сборки программного продукта из программных

модулей на основе формализованного описания вычислительного процесса.

Это большая группа систем, реализующих аппарат спецификаций, техноло-

гии планирующего типа, поддерживаемые, например, диалоговыми маршрут-

ными системами, Р-технология и др.

Планирование средств системы реального времени состоит, в том числе

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

вания средств. И в качестве исходных данных формируется вектор временной

развертки технологического цикла управления (ТЦУ)

t = (t

, t

, … t

где t

– момент задействования того или иного компонента структуры для вы-

полнения задачи, находящейся в i-й вершине графа ТЦУ.

Вектор временной развертки однозначно определяет взаимосвязи по

передаче управления между компонентами структуры. Так как выбор момен-

тов включения компонент вычислительной системы является решающим фак-

тором определения всей динамики процесса, то здесь возможна определенная

оптимизация. От этого выбора зависит, будет ли реализован ТЦУ и если бу-

дет, то, за какое время и с каким качеством.

Общее описание

«NVS Designer» – представляет собой среду проектирования систем

управления, построенных на принципах методологии мультиверсионного

программирования.

Пакет реализован с использованием среды визуального программирова-

ния Borland C++Builder 3.0 на платформе операционной системы Windows

95/98. Программный код написан с использованием подхода объектно-ориен-

тированного программирования, что позволило реализовать в приложении

наибольшую модульность.

Приложение реализовано с использованием основных достоинств опе-

рационной системы Windows 95/98: графический интерфейс пользователя,

многозадачность, модульность и т.д.

В версию 1.0 данного программного продукта входят следующие свой-

ства:

– проектирование системы по одной из двух формулировок построения

мультиверсионных систем управления

– возможность варьирования всех параметров системы;

– представление структуры системы в виде вектора булевых перемен-

ных (вектор участия);

Рис. 4.1. Окно выбора типа структуры

системы

– оптимизация структуры системы с использованием методов псевдобу-

левой оптимизации;

– возможность задания постановки оптимизационной задачи по усмот-

рению пользователя;

– графическое представление данных, позволяющее наблюдать за про-

цессом оптимизации в реальном времени и др.

– наличие следующих оптимизационных процедур: метод полного

перебора, случайный перебор, различные алгоритмы схемы метода изменяю-

щихся вероятностей (СПА, МСПА, СПАБО, МСПАБО) с независимой гене-

рацией компонент вектора вероятностей, в том числе с использованием непа-

раметрического восстановления целевой функции, традиционные схемы слу-

чайного поиска, различные модификации локального поиска, секущие алго-

ритмы;

– возможность сохранения и восстановления данных в виде файлов осо-

бого формата (файлы *.nvs);

– функция быстрой загрузки файлов, с которыми приходилось работать

ранее;

– возможность добавления оптимизационных процедур в виде про-

граммных модулей без изменения программного кода оболочки (и вообще го-

воря, возможность использования таких модулей, написанных для NVS

Designer, для программного решения (реализации) любых задач псевдобуле-

вой оптимизации).

Работа с «NVS Designer»

Для того чтобы создать новый проект в меню «File» выберите пункт

«New…» или на панели инструмен-

тов нажми- те кнопку – появится

окно выбо- ра типа системы. Предлага-

ется на вы- бор два типа структуры си-

стемы (рис. 4.1). Выбрав, например,

формули- ровку №1, перед вами по-

явится бланк описания системы

управле- ния, построенной с исполь-

зованием данной формулировки под-

хода мультиверсионного про-

граммирования.

Главное окно программы состоит из двух страниц: «System parameters»

(параметры системы) и «System structure optimization» (оптимизация структу-

ры системы). В нижней части окна расположена таблица, содержащая компо-

ненты вектора участия, и панель, содержащая информацию о размерности

вектора участия, стоимости и надежности системы, а также информацию о

том, удовлетворяет ли структура системы предъявленным к ней на этапе по-

становки задачи условиям (рис. 4.2).

Рис. 4.2 Главное окно программы

На странице «System parameters» находится информация о структуре

системы: число задач; число базовых модулей (классов типовых задач); число

версий для каждого из типовых модулей; принадлежность задач системы

классам и характеристики версий типовых модулей (надежность и

стоимость). Для формулировки №2 на этой странице будут расположены до-

полнительные элементы управления. Многие параметры системы взаимозави-

симы, поэтому, изменяя, например, число задач в системе, автоматически из-

меняется размерность вектора участия, число столбцов в таблице, описываю-

щей вектор участия и число столбцов и значения ячеек в таблице, которая

описывает вектор принадлежности задач классам.

Страница «System structure optimization» содержит информацию о зада-

че построения оптимальной структуры системы управления. Пользователь

может задать метод вычисления функции надежности (для методов безуслов-

ной оптимизации предлагается метод штрафных функций) и условия, предъ-

являемые к системе управления: «хотя бы одна версия в каждом модуле»,

«нечетное число версий в каждом модуле» и «стоимость системы не должна

превышать имеющегося бюджета». Пользователь имеет возможность задать

величину бюджета. Окно «System structure optimization» представлено на рис.

4.3.

На этой странице также имеются две кнопки «X={000…00}» и

«X={111…11}», которые выполняют функции: соответственно «система с ну-

левой структурой» (ни одному модулю не поставлена в соответствие ни одна

версия) и «система с полным набором» (в составе каждого модуля имеются

все возможные версии).

Рис. 4.3. Страница «System structure optimization»

Пожалуй, основными элементами управления на странице «System

structure optimization» являются выпадающий список оптимизационных алго-

ритмов и кнопки «Optimize » (Оптимизировать) и «Stop » (Стоп), выпол-

няющие функции соответственно запуска и преждевременного

При сохранении проекта система запоминает параметры структуры

проектируемой систем, в том числе и величину бюджета.

При работе в системе проектирования пользователь варьирует разные

параметры. При изменении параметров в строке состояния появляется помет-

ка «Modified» (изменен). После сохранения документа пометка «Modified» в

строке состояния исчезает.

Для того чтобы сохранить данные о системе достаточно в меню «File»

выбрать пункт «Save» или нажать кнопку . Если проект не был загружен из

какого-либо файла до этого - программа спросит название файла, в котором

следует сохранить данные о системе.

Работу в системе проектирования рассмотрим на примере системы

управления, построенной согласно формулировке №2, так как формулировку

№1 можно рассматривать как упрощение формулировки №2.

На странице «System parameters» главного окна приложения имеются

элементы управления, позволяющие изменять следующие параметры систе-

мы: число базовых модулей (классов задач); число версий в каждой из базо-

вых модулей; характеристики версий базовых модулей (надежность и стои-

мость); число задач в системе; число программных модулей в каждой из задач

Рис. 4.4. Выбор класса

Рис. 4.5. Параметры системы

системы; принадлежность программных модулей отдельных задач системы

базовым классам.

Таким образом, пользователь в первую очередь задает два главных па-

раметра системы: число задач в системе и число классов задач. При измене-

нии значения некоторых параметров системы, автоматически изменяются па-

раметры, на которые повлияло данное изменение.

После того, как было введено число классов задач, следует ввести ха-

рактеристики каждого из классов: число версий, доступных для решения за-

дачи данного класса и параметры каждой из версий. В верхней таблице вво-

дятся значения числа версий каждого класса.

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

в выпадающем списке, расположенном ниже таблицы с данными о классах,

выбрать номер класса (4.4). Значения в нижней таблице изменятся и станут

равными параметрам версий, решающих задачи указанного класса. Для изме-

нения параметров версий необходимо выделить соответствующую ячейку та-

блицы и ввести новое значение.

Правее описанных данных на странице находятся параметры конкрет-

ной системы: число задач в ней и т.д. Варьирование этих данных производит-

ся так же как и варьирование данных, описывающих библиотеку базовых мо-

дулей (рис. 4.5).

Изменяя описанные выше параметры, поль-

зователь тем самым изменяет и размерность век-

тора участия, стоимость системы и ее надеж-

ность. Но надежность и стоимость системы в пер-

вую очередь зависят от ее структуры, которая

описывается при помощи вектора участия. Имен-

но поэтому в программу введена функция «руч-

ного» редактирования вектора участия. Выделив

некоторую ячейку вектора, пользователь может

ввести единицу или ноль, что будет соответство-

вать участию или отсутствию некоторой мультиверсии в структуре системы

управления. Меняя эти величины, пользователь может видеть, что автомати-

чески меняются параметры стоимости и надежности системы. Окно для «руч-

ного» редактирования вектора участия представлено на рис. 4.6.

Страница «System structure optimization» содержит элементы управле-

ния, необходимые для решения задачи построения оптимальной структуры

системы управления, основываясь на информации, введенной на странице

«System parameters».

Рис.4.6. Редактирование вектора участия

Рис. 4.7. Ограничения

Рис. 4.8. Информация о

соблюдении условий

Рис. 4.9. Оптимизационные алгоритмы

На данной странице в первую очередь пользователь может выбрать ме-

тод, которым будет просчитываться целевая функция оптимизационной зада-

чи. Это может быть просто функция надежности системы от ее структуры или

один из вариантов функции надежности со штрафами. Метод штрафных

функций внедрен в пакет с целью использования оптимизационных процедур,

решающих задачи безусловной оптимизации.

Пользователь также может выбрать ограниче-

ния, налагаемые на целевой функционал. Он может

включить/отключить действие одного из трех типов

ограничений: «хотя бы одна версия в каждом

модуле», «нечетное число версий в каждом модуле» и

«стоимость системы не должна превышать имеюще-

гося бюджета» (рис. 4.7). Чтобы реализовать это поль-

зователь должен щелкнуть мышкой на соответствующем условии.

Одновременно с изменениями условий и вида целевой функции меня-

ются значения параметров, расположенные внутри панели в нижней части

главного рабочего окна приложения. В зависимости от того, удовлетворяет ли

структура системы поставленным ограничениям,

внизу панели будет изображаться надпись

«Condition is satisfied» (условие выполняется),

выполненная в черном цвете или «Condition is

not satisfied» (условие не выполняется) – в крас-

ном цвете (рис.4.8).

Основным элементом на странице «System

structure optimization» является выпадающий спи-

сок оптимизационных алгоритмов (рис.4.9). В списке перечислены подклю-

ченные алгоритмы псевдобулевой оп-

тимизации. Подключение алгоритма

организуется написанием отдельного

модуля и никаким образом не влияет

на программный код самой оболочки

пакета. В модуле, содержащем описа-

ния оптимизационных процедур, на-

ходятся все параметры алгоритмов, в том числе и их названия. Поэтому без

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

Щелкнув по выпадающему списку методов оптимизации, пользователь

может выбрать один из них. На странице появится панель алгоритма. Описа-

ние панели алгоритма также входит в состав модуля оптимизационных мето-

дов.

В настоящей версии программного продукта доступны следующие оп-

тимизационные процедуры:

– метод полного перебора;

Рис. 4.10. Панель метода

полного перебора

– алгоритмы схемы МИВЕР с независимым распределением вероятно-

стей;

– алгоритмы схемы МИВЕР с независимым распределением вероятно-

стей для задач безусловной оптимизации;

– различные вариации алгоритмов схемы МИВЕР, в том числе с исполь-

зованием непараметрического оценивания функционала

– случайный перебор,

– алгоритмы направленного случайного поиска,

– алгоритмы метода локального поиска,

– секущие алгоритмы.

На панели алгоритма отображается инфор-

мация о параметрах алгоритма и информация,

описывающая работу алгоритма в реальном вре-

мени (рис. 4.10). Например, на панели метода

полного перебора в реальном времени отобража-

ются следующие параметры: номер итерации (i);

значения элементов вектора, в котором в данный

момент просчитывается значение функционала;

минимальное значение функционала среди уже

просмотренных точек области определения целе-

вой функции (Fmin); значения компонент векто-

ра из числа уже просмотренных, при котором значение целевой функции

обратилось в Fmin (Xmin), а также на панели отображается шкала прогресса

алгоритма (процент просмотренных точек).

Перед тем как запустить алгоритм оптимизации из схемы МИВЕР,

пользователь должен задать параметры алгоритма. В выпадающем списке

пользователь должен выбрать метод пересчета вектора вероятностей (по

умолчанию выбирается ARSA – СПА), в строках редактирования установить

значения параметров R и r алгоритма.

Затем нажатием кнопки «Optimize » пользователь может запустить

оптимизационную процедуру. После этого на панели отобразится величина,

характеризующая процент точек, в которых будет просчитано значение целе-

вой функции, от числа точек из множества булевых переменных

. В про-

цессе действия алгоритма оптимизации на панели метода в реальном времени

будет отображаться следующая информация (рис. 4.11):

– номера итераций (i – общий цикл, k – внутренний цикл, j – цикл гене-

рации векторов);

– число сгенерированных векторов;

– число обращений к целевой функции;

– шкалы общего прогресса алгоритма и прогресса по внутреннему цик-

лу;

– значения компонент вектора вероятностей, представленные в виде

диаграммы;

– максимальные и минимальные значения целевой функции среди про-

считанных на очередном этапе работы алгоритма и векторы, при которых

функционал принимает эти значения.

Оптимизационный процесс может быть прерван в любой момент време-

ни нажатием кнопки «Stop ».

В дальнейшем планируется дополнить пакет следующими свойствами:

– переход к современному однодокументному интерфейсу пользователя

(Single Document Interface);

– представление структуры системы управления в графическом виде;

– включение в задачу проектирования системы управления временных

и ресурсных требований (ограничений);

– пополнение библиотеки оптимизационных процедур;

– реализация абсолютной модульности (реализация оптимизационных

процедур не в одном, а в нескольких подключаемых модулях, что позволит

облегчить подключение алгоритмов);

– введение параметров оболочки;

– развитие файлов оперативной документации (on-line help).

По завершении работы алгоритма на панели отображается решение и

значение целевой функции в полученном векторе (рис. 4.12). Также в соответ-

ствии с полученным решением обновляется информация в таблице значений

компонент вектора участия и на панели, описывающей надежность и стои-

мость системы.

Рис. 4.11. Панель алгоритмов схемы МИВЕР с независимым

распределением вероятностей.