И. А. СПИЦИНА К. А. АКСЕНОВelar.urfu.ru/bitstream/10995/48968/1/978-5-7996-2038-7... · 2019-06-24 · И. А. СПИЦИНА К. А. АКСЕНОВ МУЛЬТИАГЕНТНЫЙ

И. А. СПИЦИНАК. А. АКСЕНОВ

МУЛЬТИАГЕНТНЫЙ МЕТОД АНАЛИЗА И СИНТЕЗА ИНФОРМАЦИОННЫХ СИСТЕМ

Учебное пособие

9 7 8 5 7 9 9 6 2 0 3 8 7

I SBN 579962038 - 0

Министерство образования и науки Российской ФедерацииУральский федеральный университет

имени первого Президента России Б. Н. Ельцина

И. А. Спицина, К. А. Аксенов

Мультиагентный метод анализа и синтеза

информационных систем


Рекомендовано методическим советомУральского федерального университета

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

09.04.01 — Информатика и вычислительная техника

ЕкатеринбургИздательство Уральского университета

2017

УДК 004.8(075.8)ББК 32.813я73 С71

Рецензенты:кафедра «Высшая и прикладная математика» Уральского государствен‑ного университета путей сообщения (завкафедрой проф., д‑р физ.‑мат. наук Г. А. Тимофеева);доц., канд. техн. наук В. Ф. Ярчук (начальник программно‑технологиче‑ского отдела ООО «ТЭКСИ‑Консалтинг»).Научный редактор — проф., д‑р техн. наук Л. Г. Доросинский

Спицина, И. А.С71 Мультиагентный метод анализа и синтеза информационных систем :

учебное пособие / И. А. Спицина, К. А. Аксенов. — Екатеринбург : Изд‑во Урал. ун‑та, 2017. — 92 с.

ISBN 978‑5‑7996‑2038‑7Отражены аспекты принятия решений при разработке информационных си‑

стем. Основное внимание уделено построению модели информационной систе‑мы с использованием автоматизированных средств поддержки принятия решений. Рассмотрены методы разработки организационно‑технических систем и представ‑лен анализ существующих CASE‑средств. Предназначено для студентов дневной и дистанционной форм обучения направления 09.04.01 — Информатика и вычис‑лительная техника (магистр), модуль «Применение аналитики и графики в инфор‑мационных системах (ИС)».

Библиогр.: 23 назв. Табл. 4. Рис. 46.УДК 004.8(075.8)ББК 32.813я73

Учебное издание

Спицина Ирина Александровна, Аксенов Константин Александрович

МультИАгентный Метод АнАлИзА И СИнтезА ИнфорМАцИонных СИСтеМ

Редактор И. В. КоршуноваВерстка О. П. Игнатьевой

Подписано в печать 17.04.2017. Формат 70×100/16. Бумага писчая. Печать цифровая. Гарнитура Newton.Уч.‑изд. л. 5,0. Усл. печ. л. 7,4. Тираж 50 экз. Заказ 70

Издательство Уральского университетаРедакционно‑издательский отдел ИПЦ УрФУ

620049, Екатеринбург, ул. С. Ковалевской, 5. Тел.: 8 (343)375‑48‑25, 375‑46‑85, 374‑19‑41. E‑mail: [email protected]

Отпечатано в Издательско‑полиграфическом центре УрФУ620075, Екатеринбург, ул. Тургенева, 4. Тел.: 8 (343) 350‑56‑64, 350‑90‑13. Факс: 8 (343) 358‑93‑06

E‑mail: press‑[email protected]

ISBN 978‑5‑7996‑2038‑7 © Уральский федеральный университет, 2017

3

Оглавление

Список основных сокращений ................................................................................... 5

Предисловие ................................................................................................................ 6

1. Процесс системного анализа при разработке информационных систем ............. 91.1. Этапы системного анализа при разработке информационных систем .......... 9

1.1.1. Организационно‑технические системы .............................................. 101.1.2. Моделирование автоматизируемых процессов ................................... 111.1.3. Реинжиниринг бизнес‑процессов ........................................................ 14

1.2. Риски, связанные с разработкой информационных систем, и пути их снижения ................................................................................................... 151.3. Методологические и теоретические основы поддержки принятия решений, моделирования и разработки информационных систем ............. 17

1.3.1. Применение имитационного моделирования при разработке программного обеспечения .................................................................. 171.3.2. Использование систем искусственного интеллекта при разработке информационных систем ..................................................................... 181.3.3. Применение мультиагентного подхода ............................................... 19

1.4. Обзор и сравнительный анализ существующих систем поддержки принятия решений в области разработки информационных систем (CASE‑средств) .............................................................................................. 21

1.4.1. Классификация CASE‑средств ............................................................ 211.4.2. Описание CASE‑средств ...................................................................... 221.4.3. Критерии сравнения функциональных возможностей CASE‑средств ........................................................................................ 261.4.4. Сравнительный анализ CASE‑средств ................................................. 27

2. Метод поддержки принятия решений при разработке информационных систем для предметной области мультиагентных процессов преобразования ресурсов ................................................................................................................. 29

2.1. Требования к модели и методу поддержки принятия решений при разработке информационных систем .................................................... 292.2. Выбор модели представления бизнес‑процессов ......................................... 302.3. Выбор модели представления знаний ........................................................... 322.4. Построение модели разработки информационной системы ....................... 35

4

2.4.1. Концептуальная модель предметной области мультиагентных процессов преобразования ресурсов .................................................... 352.4.2. Концептуальная модель предметной области информационных систем .................................................................................................... 42

2.5. Метод разработки информационных систем ................................................ 462.6. Методика оценки эффективности работы метода разработки информационных систем .............................................................................. 68

3. CASE‑средство BPsim.SD ..................................................................................... 713.1. Функциональные возможности пакета BPsim.SD ........................................ 713.2. Описание CASE‑средства BPsim.SD ............................................................. 72

3.2.1. Общая структура CASE‑средства BPsim.SD ........................................ 723.2.2. Создание диаграмм ............................................................................... 743.2.3. Подсистема моделирования пользовательского интерфейса ............. 79

3.3. Описание агента интеграции BPsim.MAS и BPsim.SD ................................. 813.4. Методика использования пакета BPsim ........................................................ 82

Заключение ............................................................................................................... 87

Библиографический список ..................................................................................... 90

5

Список основных сокращений

BPMN (Business Process Model and Notation) — нотация и модель бизнес‑процессов

CASE (Computer Aided Software Engineering) — автоматизированная разработка ПО

UML (Unified Modeling Language) — унифицированный язык моделирования

БД – база данныхБЗ – база знанийБП – бизнес‑процессИА – интеллектуальные агентыИИ – искусственный интеллектИМ – имитационное моделированиеИС – информационная системаИТ – информационные технологииКГ – концептуальный графКМПО – концептуальная модель предметной областиЛПР – лицо, принимающее решениеМАС – мультиагентные системыМЛВ – машина логического выводаМППР – мультиагентные процессы преобразования ресурсовООП – объектно‑ориентированный подходОТС – организационно‑технические системыПИ – пользовательский интерфейсПО – программное обеспечениеППР – поддержка принятия решенияРБП – реинжиниринг бизнес‑процессовСДМС – система динамического моделирования ситуацийСМО – системы массового обслуживанияСППР – система поддержки принятия решенийСУБД – система управления базами данныхТЗ – техническое заданиеФК – фрейм‑концептЭС – экспертная система

6

Предисловие

У чебное пособие посвящено методу поддержки принятия ре‑шений в области создания информационных систем на ос‑нове мультиагентного подхода. Объектом автоматизации вы‑

ступает организационно‑техническая система, которая представляет собой совокупность организационной структуры и находящихся в ее распоряжении технических средств, т. е. совместно рассматривается человек и информационная система. Разработка ИС является меро‑приятием с высокой степенью риска. Согласно исследованиям, толь‑ко 22 % проектов, длящихся более двух лет, завершаются в установлен‑ный срок. Одна из причин такого явления — это искажение и потеря информации о разрабатываемой ИС и особенностях процесса в цепоч‑ке ее передачи пользователь — аналитик — разработчик. Техническое задание должно являться связующим звеном между ними. Однако оно недостаточно полно отражает предметную область ОТС (в части про‑цессов согласования и принятия решений), а также не решает вопрос увязывания ожиданий пользователя с требованиями к ИС. Из всего ТЗ пользователю понятен раздел, описывающий функции системы, с ИС пользователь отождествляет визуальный пользовательский интерфейс.

Успешность разработки ИС во многом определяется проработанно‑стью методологического подхода, используемого в процессе проекти‑рования. При этом следует отметить следующие моменты. Во‑первых, существующие методики и инструментальные средства не дают единой модели информационной системы как с точки зрения разработчика, так и пользователя — предметного специалиста. Во‑вторых, для ОТС характерны процессы принятия решений, которые предполагают ра‑боту со знаниями, формализуются сценариями и в ряде случаев пред‑полагают согласование решений. Существующие методики не позво‑ляют в комплексе решать вопросы формализации и информатизации процессов принятия решений. В‑третьих, для анализа, совершенство‑

7

вания и реинжиниринга бизнес‑процессов в ОТС используются сред‑ства имитационного и мультиагентного моделирования. Однако при‑менение данных средств на этапах автоматизации и информатизации до сих пор ограничено в силу двух причин: во‑первых, затраты на раз‑работку имитационной модели; во‑вторых, отсутствие возможностей использовать полученные результаты и знания на этапах автоматиза‑ции. Эффект от информатизации будет намного выше, если решать задачу автоматизации совместно с задачей совершенствования БП.

Большой вклад в рассматриваемую тему внесли работы следую‑щих исследователей: К. А. Аксенова, Д. В. Александрова, Б. Боэма, Г. Буча, А. М. Вендрова, К. Гейна, С. Л. Гольдштейна, В. И. Горо‑децкого, Г. Н. Калянова, О. В. Карсаева, Б. И. Клебанова, М. Мин‑ского, Е. Г. Ойхмана, Э. В. Попова, Дж. Рамбо, У. Ройса, Т. Сарсо‑на, П. О. Скобелева, А. Ю. Филипповича, М. Хаммера, Дж. Чампи, А. Н. Швецова, N. R. Jennings, M. J. Wooldridge.

В настоящее время существуют различные подходы к разработке. Структурный подход (IDEF0, DFD) позволяет описать разрабаты‑ваемую систему в виде иерархии взаимосвязанных функций. Такое представление понятно аналитику и пользователю. Для анализа уз‑ких мест и динамических характеристик используется имитационное моделирование. При описании модели разрабатываемой системы, c точки зрения разработчика, применяют объектно‑ориентированный подход (язык UML). Экспертные системы закрывают вопросы, свя‑занные с описанием знаний и сценариев принятия решений. Исполь‑зование мультиагентных систем позволяет автоматизировать про‑цессы согласования решений и взаимодействие лиц, принимающих решения. Функции ЛПР выполняют программные агенты. Каждый из них в отдельности не закрывает всех вопросов, возникающих при автоматизации процессов ОТС. В связи с этим актуальным является анализ существующих динамических моделей процессов ОТС и мо‑делей архитектуры информационных систем, а также создание на их основе метода ППР, совмещающего в себе эти подходы, и програм‑много обеспечения для его реализации — системы поддержки при‑нятия решений.

Идея учебного пособия заключается в интеграции методов и ин‑струментальных средств ситуационного, мультиагентного, имитацион‑ного и экспертного моделирования с целью повысить эффективность принятия решений при ситуационном управлении преобразованием ресурсов.

8

Структура предлагаемого материала выглядит следующим образом.Пособие состоит из трех глав, заключения и списка литературы.В пособии обоснована необходимость автоматизации процесса при‑

нятия решений, приведен обзор методов моделирования мультиагент‑ных процессов преобразования ресурсов, рассмотрены системы, близ‑кие по функциональности к системам динамического моделирования ситуаций, и выполнен их сравнительный анализ, определены требо‑вания к СППР при разработке ИС. Излагаются принципы построе‑ния метода и СППР при разработке ИС, приведено описание данной системы, а также описаны принципы работы с ней.

Авторы благодарны Е. Ф. Смолий за оказанную неоценимую по‑мощь при разработке и отладке СППР семейства BPsim. За предостав‑ленную экспериментальную базу благодарим ООО «НПП “Системы автоматизации поддержки бизнеса”».

Авторы также благодарят всех аспирантов и студентов Ураль‑ского федерального университета имени первого Президента Рос‑сии Б. Н. Ельцина, принявших участие в отладке метода и сбора дан‑ных для эксперимента.

9

1. Процесс системного анализа при разработке информационных систем

1.1. Этапы системного анализа при разработке информационных систем

О сновная проблема, возникающая при разработке информа‑ционной системы — это сложность понимания сразу всей системы в целом. Для решения этой проблемы целесообраз‑

но применять системный анализ. Такой подход позволяет получить целостное представление об объекте автоматизации и разрабатыва‑емой ИС. Проведение системного анализа объекта автоматизации при разработке информационных систем можно разделить на следу‑ющие этапы:üопределение и назначение объекта автоматизации;üопределение целей разрабатываемой системы;üанализ состояния внутренней и внешней среды автоматизируе‑

мого объекта и прогноз их изменений;üпостроение и анализ моделей автоматизируемых процессов;üразработка новых моделей автоматизируемых процессов с уче‑

том проблем, диагностированных на предыдущем этапе;üразработка модели ИС;üразработка и внедрение полученной системы.Разработка ИС идет в тесном сотрудничестве пользователей, анали‑

тиков и разработчиков. Первые являются специалистами в предмет‑ной области. Вторые получают знания от первых и формулируют тре‑бования к разрабатываемой ИС. Разработчики реализуют полученные требования в виде готового продукта.

Далее рассмотрим некоторые этапы подробнее.

10

1.1.1. Организационно-технические системы

Под объектом автоматизации в работе рассматриваются организа‑ционно‑технические системы, которые представляют собой совокуп‑ность организационной структуры и находящихся в ее распоряжении технических средств, т. е. совместно рассматривается человек и инфор‑мационная система. Современные исследователи выделяют следую‑щие особенности ОТС: многопараметричность, иерархичность, веро‑ятностное поведение, сложность структуры и алгоритмов поведения.

Процессы, протекающие в ОТС, можно разделить на три группы:üпроизводственные и бизнес‑процессы — процессы, связанные

с основной деятельностью предприятия;üпроцессы согласования;üпроцессы принятия решений.При автоматизации производственных и БП предприятия аналитики,

опрашивая пользователей, получают информацию о структуре и функ‑циях ОТС, строят модель БП и при необходимости дорабатывают ее. Таким образом, знания пользователя, обработанные аналитиком, пре‑образуются в техническое задание на разрабатываемую систему.

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

Процессы принятия решений имеют свои особенности [9]. Прежде всего, данные задачи сложно описать алгоритмически. Решения при‑нимаются по определенным сценариям, для описания которых целе‑сообразно использовать базы знаний и технологии экспертных систем. При автоматизации деятельности лица, принимающего решение, воз‑можно использование программных интеллектуальных агентов. Следо‑вательно, для таких процессов ИС должна включать систему поддерж‑ки принятия решений, которая поможет ЛПР на основе имеющейся информации правильно определить проблему и выбрать оптимальное решение. Следует отметить, что не все алгоритмы и сценарии поведе‑ния поддаются полной формализации. В некоторых случаях требует‑ся непосредственное участие ЛПР.

На рис. 1.1 показаны особенности автоматизации ОТС.Автоматизация каждой группы процессов, протекающих в ОТС,

имеет свои особенности. Существующие подходы к разработке, каж‑дый в отдельности, не закрывают всех вопросов, возникающих при этом. Следовательно, целесообразно совмещать эти методы при раз‑работке информационных систем.

11

Сообщения

Принятие решений

Процессы согласования

Бизнес-процессы

Экспертные системы /интеллектуальные агенты

Машина логического вывода /модель поведения

Рабочая памятьБЗ/БД

Операция1 Операция n

Общая база знаний

Мульти-агентные системы

...

WorkFlow системы

Агент 2Агент 1

Рис. 1.1. Особенности автоматизации ОТС

1.1.2. Моделирование автоматизируемых процессов

Замещение одного объекта другим в целях получения информации о важнейших свойствах объекта‑оригинала с помощью объекта‑моде‑ли называется в учебниках моделированием. Для одной и той же си‑стемы можно построить несколько моделей, каждая из которых опре‑деляет конкретный аспект системы. При этом используются разные наборы диаграмм и документов.

Успешное решение задачи разработки информационной системы невозможно без четкого представления бизнес‑процессов, протека‑ющих на автоматизируемом предприятии. Поэтому, прежде всего, необходимо построить бизнес‑модель, отражающую автоматизируе‑мые процессы и необходимые для них ресурсы.

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

12

üмодели «AS‑IS» («Как есть»), которые отражают существующие бизнес‑процессы предприятия;

üмодели «AS‑TO‑BE» («Как будет»), которые показывают представ‑ления о новых процессах и технологиях работы предприятия.

Переход от модели «AS‑IS» к модели «AS‑TO‑BE» происходит бла‑годаря реинжинирингу (см. параграф 1.1.3). Далее на основе моделей «AS‑TO‑BE» строятся модели разрабатываемой ИС. Наличие моделей информационной системы также положительно сказывается на доку‑ментировании проекта, поскольку принимаемые проектные решения становятся более наглядными. Состав моделей, используемых в каж‑дом конкретном проекте, и степень их детализации зависят от следу‑ющих факторов [12]:üсложность разрабатываемой системы;üнеобходимая полнота ее описания;üзнания и навыки участников проекта;üвремя, отведенное на разработку.Поскольку проектирование и моделирование тесно связаны друг

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

1.1.2.1. Структурные методы анализа

Структурным анализом называется метод исследования системы, начинающийся с ее общего обзора, который затем детализируется, приобретая иерархическую структуру со все большим числом уров‑ней [12]. Его основные характеристики:üразбиение системы на уровни абстракции с ограничением числа

элементов на каждом уровне;üограниченный контекст, включающий лишь существенные

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

модели. Наиболее распространенными являются:üфункциональная модель SADT (IDEF0), которая описывает

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

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

13

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

üдиаграммы потоков данных DFD, которые описывают передачу информации между функциональными процессами;

üспецификация BPMN (англ. Business Process Model and Notation, нотация и модель бизнес‑процессов) позволяет описать БП в виде последовательности объектов потока управления с возможно‑стью задания циклических действий [5].

В семейство IDEF входят и другие модели, которые не так широко используются. Следует отметить методологию онтологического ис‑следования сложных систем IDEF5. Она позволяет описать правила и ограничения, которые представляют состояние системы, с исполь‑зованием словаря терминов [13].

Можно выделить следующие положительные черты структурных методов:üграфические диаграммы позволяют наглядно представить струк‑

туру системы;üвизуальное моделирование доступно неспециалистам в области

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

ции системы с разной степенью подробности.При разработке ИС целесообразно использовать диаграммы по‑

токов данных DFD [12], поскольку этот метод хорошо согласуется со средством моделирования данных (модель «сущность‑связь»). Хра‑нилища данных, описываемые на диаграммах DFD, являются осно‑вой для построения модели «сущность‑связь».

1.1.2.2. Объектно-ориентированные методы анализа и проектирования ПО

IDEF4 — методология построения объектно‑ориентированных си‑стем. Средства IDEF4 позволяют наглядно отображать структуру объ‑ектов и заложенные принципы их взаимодействия. Это позволяет ана‑лизировать и оптимизировать сложные объектно‑ориентированные системы.

Язык UML — широко используемый в настоящее время метод объ‑ектно‑ориентированного анализа [12]. Язык UML (версия 2.0) пред‑ставляет собой набор из 13 диаграмм [7], которые позволяют описать разрабатываемую информационную систему с двух сторон: логиче‑

14

ском/физическом и статическом/динамическом. Для описания стати‑ческих частей системы используются следующие диаграммы: классов, объектов, компонентов и развертывания. Для описания динамической составляющей ИС используются диаграммы прецедентов, последова‑тельности, кооперации, состояний и деятельности.

Широкое применение языка UML во многом связано с возможно‑стью расширения его существующих элементов, что позволяет созда‑вать новые языки для использования в конкретной предметной об‑ласти на основе UML. В своей работе авторы используют следующие диаграммы:üвариантов использования (предназначены для определения мно‑

жества функций, которые будет выполнять ИС);üпоследовательности (объекты ИС взаимодействуют между собой

путем передачи сообщений друг другу; эти диаграммы позволя‑ют описать последовательность передачи сообщений между объ‑ектами);

üклассов (позволяют создавать логическое представление системы, т. е. описать иерархию классов, а также методы и их свойства).

Моделирование БП является важной составляющей разработки ИС. Существуют структурные и объектно‑ориентированные мето‑ды анализа и проектирования ПО. Каждый из них имеет свои досто‑инства и недостатки. Для получения наибольшего эффекта ставится и решается задача интеграции этих методов для задачи разработки ИС.

1.1.3. Реинжиниринг бизнес-процессов

Современное предприятие имеет довольно сложную структуру и алгоритмы работы. На начальном этапе разработки ИС необходи‑мо удостовериться в том, что организация существующих БП позво‑ляет работать предприятию оптимально, и если это не так, то внести соответствующие изменения. Для этого используется реинжиниринг бизнес‑процессов — фундаментальное переосмысление и радикальное перепроектирование БП для достижения коренных улучшений в ос‑новных показателях деятельности предприятия [22]. Целью РБП яв‑ляется системная реорганизация всех потоков предприятия (матери‑альных, финансовых и информационных), которая должна привести к упрощению организационной структуры, перераспределению и ми‑нимизации использования различных ресурсов, сокращению сроков

15

реализации потребностей клиентов. Все это в конечном итоге позво‑лит повысить качество работы предприятия [18].

Наиболее распространенным средством моделирования динами‑ческих процессов (переходов из одного состояния в другое, из одной ситуации в другую) является имитационное моделирование и, в част‑ности, дискретно‑событийное.

Также в имитационном моделировании используется мультиагент‑ный подход. При этом поведение системы определяется как результат деятельности многих агентов. Для построения мультиагентной моде‑ли необходимо определить поведение отдельных агентов и взаимоот‑ношения между ними.

Для анализа, совершенствования и реинжиниринга БП в ОТС ис‑пользуются средства имитационного и мультиагентного моделирова‑ния, что повышает эффективность автоматизации.

Итак, были рассмотрены этапы разработки информационной си‑стемы, предшествующие написанию технического задания. Этот до‑кумент является связующим звеном между участниками ИТ‑проекта. От качества описания каждой группы процессов, протекающих в ОТС, зависит результат разработки информационной системы. Решение за‑дачи автоматизации совместно с задачей совершенствования БП по‑зволяет повысить эффект от внедрения ИС.

1.2. Риски, связанные с разработкой информационных систем, и пути их снижения

Разработка ИС сопровождается определенными рисками [11]. Пе‑речислим некоторые из них:

1. Сроки выполнения этапов могут отставать от графика проекта или бюджет проекта будет существенно превышен, что может приве‑сти к закрытию проекта до завершения, следовательно, ИС даже не бу‑дет разработана.

2. Низкое качество внедренной ИС может привести к отказу от ее использования.

3. Разработанная ИС теряет свою полезность после нескольких лет эксплуатации, поскольку количество недостатков и стоимость внесе‑ния изменений увеличивается настолько, что становится проще и де‑шевле разработать новую систему, чем поддерживать существующую.

16

4. В процессе эксплуатации ИС выясняется, что она не решает необ‑ходимых задач предприятия, а это может быть следствием изначаль‑но неточной постановки задачи или изменений БП в ходе разработки ИС, которые не учитывались.

5. В процессе эксплуатации ИС выясняется, что она имеет множе‑ство функций, не используемых заказчиком, а действительно полез‑ные в системе не реализованы.

6. В течение жизненного цикла ИС происходит почти полное об‑новление команды разработчиков. Недостаточное документирова‑ние системы не позволяет новым сотрудникам успешно модернизи‑ровать ИС.

Проекты, длящиеся более двух лет, являются довольно рискован‑ными [1]. На рис. 1.2 показан процент успешных проектов в зависи‑мости от их длительности и характеристик (завершенность в срок, уло‑жились в бюджет и т. п.).

Рис. 1.2. Процент успешных проектов в зависимости от их длительности и характеристик

17

В настоящее время создание ИС рассматривается как формализо‑ванный процесс, который должен соответствовать определенным стан‑дартам и нормативным документам [12]. Создаются различные мето‑ды и технологии разработки ИС, которые позволяют снизить риски, связанные с ее разработкой, увеличить производительность участни‑ков ИТ‑проекта, улучшить качество разрабатываемой системы за счет повышения управляемости процесса создания ИС и своевременного учета изменившихся требований к системе.

Следует отметить, что эффективность применения этих методов и технологий напрямую связана с наличием программного средства, обеспечивающего автоматизацию этапов — CASE‑сродство (Computer Aided Software Engineering — компьютерно‑ориентированная про‑граммная инженерия).

Метод разработки включает в себя:üопределенную последовательность этапов разработки;üперечень нотаций (графических и текстовых средств), использу‑

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

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

ПО позволяет уменьшить возможные риски, а наличие CASE‑средств, которые их поддерживают, — повысить эффективность использова‑ния метода разработки программного обеспечения.

1.3. Методологические и теоретические основы поддержки принятия решений, моделирования и разработки

информационных систем

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

Принятие решения о внедрении на предприятии единой ИС связа‑но со многими трудностями. Можно выделить следующие основные проблемы, возникающие при этом:üналичие нескольких несвязанных ИС, решающих узкие проблемы;üнеоптимальные БП, которые не позволяют эффективно работать

предприятию;

18

üсложность прогнозирования характеристик работы ИС (скорость обработки запросов к базе данных, скорость передачи данных по сети и т. п.).

Для решения первой проблемы необходимо спроектировать новую БД для единой ИС и перенести в нее накопленные данные.

Наиболее эффективным путем решения второй проблемы является построение модели существующих БП и проведение их РБП. Имита‑ционное моделирование на этом этапе существенно помогает в ана‑лизе такой сложной системы, как современное предприятие.

Имитационная модель описывает законы функционирования каж‑дого элемента системы и их взаимосвязи. В результате имитационно‑го эксперимента по исходным данным можно получить сведения о со‑стоянии БП в определенные моменты времени. Это позволяет оценить характеристики системы и лучше понять, как разработать систему, удовлетворяющую заданным критериям оценки эффективности. Для получения достоверных и точных результатов ИМ при небольших за‑тратах машинного времени необходимо осуществлять планирование экспериментов.

Для прогнозирования характеристик работы ИС можно расширить имитационную модель так, чтобы она включала в себя не только опи‑сание автоматизируемых БП, их статистические характеристики, та‑кие как время обработки заявки (документа), время простоя в очереди, количественные характеристики процессов, а также временные и ко‑личественные характеристики транзакций в ИС. Эксперименты с та‑кой имитационной моделью позволят до реализации готовой ИС по‑лучить представление о ее производительности, требования к скорости и интенсивности обработки заявок (документов) и транзакций в БД.

Применение ИМ при разработке ИС целесообразно как на этапе анализа автоматизируемых БП в целях их оптимизации, так и перед разработкой ИС для прогнозирования характеристик ее работы.

1.3.2. Использование систем искусственного интеллекта при разработке информационных систем

Использование искусственного интеллекта при разработке ИС пе‑реводит этот процесс на качественно новый уровень, поскольку по‑зволяет автоматизировать не только рутинные операции, но и процесс принятия решений при создании ИС. Для этого инструментарий, под‑

19

держивающий процесс разработки, должен включать в себя ЭС. По‑скольку невозможно полностью исключить человека из процесса раз‑работки ИС, то современные исследователи предлагают использовать диалоговые ЭС.

В БЗ интеллектуальной СППР в области разработки ПО (CASE‑средстве) должны храниться факты и правила, полученные от экспер‑тов предметной области, а также профессиональные знания разработ‑чиков. Использование такой СППР позволит решать практические задачи, возникающие в процессе разработки ИС.

Развитие информационных технологий определило повышенное внимание к интегрированному использованию ИС и ЭС в части ав‑томатизации деятельности ЛПР. Такие системы могут быть использо‑ваны в задачах, для решения которых требуется взаимодействие цело‑го ряда экспертов предметной области. Использование БЗ и машины логического вывода в ИС позволят автоматизировать поиск решения, к которому мог бы прийти в аналогичной ситуации эксперт.

Учет большого объема данных, знаний экспертов‑специалистов, формирование ответа на основании некоторого аналога процесса рас‑суждений, диалог с пользователем — все это делает ЭС тем инструмен‑том, который позволит сделать более интеллектуальным процесс соз‑дания ИС и автоматизировать работу ЛПР.

1.3.3. Применение мультиагентного подхода

Мультиагентные системы представляют собой новое направление развития искусственного интеллекта, которое сформировалось на ос‑нове результатов исследований современных ученых в области распре‑деленных компьютерных систем, сетевых технологий решения про‑блем и параллельных вычислений.

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

Агент — это аппаратная или программная сущность, способная дей‑ствовать в интересах достижения целей, поставленных перед ней вла‑дельцем и (или) пользователем [8]. Агенты описываются также рядом свойств, которые характеризуют понятие агента. Обычно агент обла‑дает набором следующих свойств: адаптивность, автономность, со‑трудничество, способность к рассуждениям, коммуникативность, мо‑бильность.

20

Следует отметить, что агенты могут быть отнесены к следующим типам: реактивные, интеллектуальные, гибридные.

Реактивный агент принимают решения на основе знаний «ситуа‑ция‑действие». Интеллектуальный агент решает поставленные перед ним задачи, исходя из своих целей и используя общие ограниченные ресурсы и знания о внешнем мире. Гибридный агент сочетает в себе возможности первых двух.

Интеллектуальная МАС представляет собой множество интеллек‑туальных агентов, распределенных в сети. Они отслеживают необхо‑димые данные и взаимодействуют друг с другом для достижения по‑ставленных перед ними целей. Можно выделить несколько важных причин взаимодействия агентов: совместимость целей (общая цель), отношение к ресурсам, необходимость привлечения недостающего опыта, взаимные обязательства.

С точки зрения программирования, агенты представляют собой ПО, которое способно действовать самостоятельно от лица пользо‑вателя. При создании МАС может использоваться архитектура «кли‑ент‑сервер».

Введение программных агентов в ИС позволит в некоторой степени упростить работу пользователей, поскольку агенты смогут отслеживать состояния системы и предлагать определенные решения.

Важной проблемой при разработке ИС является получение знаний экспертов в определенной предметной области. Эти знания большей частью не формализованы, а поэтому недоступны другим людям. Удач‑ное решение этой проблемы — добавление в создаваемую ИС общей БЗ и разработка агентов, которые на основе этих знаний будут пред‑лагать решения определенных проблем в автоматизируемой области. Таким образом, проектируемая ИС расширяется до интеллектуальной СППР, которая выполняет определенные формализованные функции пользователей и оказывает поддержку при решении задач организа‑ционно‑технического управления.

Также мультиагентный подход может быть применен при разработ‑ке распределенных ИС. В этом случае каждый узел системы представ‑ляет собой программного агента со своими ресурсами. Их кооперация обеспечивает функционирование системы в целом.

Перечислим следующие требования к методу разработки ИС:üвозможность разработки модели лица, принимающего решения,

представленного интеллектуальным агентом;üвозможность описания сценариев принятия решения ИА.

21

1.4. Обзор и сравнительный анализ существующих систем поддержки принятия решений в области разработки

информационных систем (CASE-средств)

1.4.1. Классификация CASE-средств

В современные CASE‑средствах реализована поддержка разно‑образных технологий проектирования ИС. К ним можно отнести простые средства анализа и документирования, а также полномас‑штабные средства автоматизации, охватывающие весь жизненный цикл ПО.

Этапы анализа и проектирования являются наиболее трудоемки‑ми при разработке ИС, поэтому использование CASE‑средств позво‑ляет повысить качество принимаемых технических решений и облег‑чить подготовку проектной документации.

На рынке программных средств в настоящее время представле‑но большое количество различных CASE‑средств. Одни из них — до‑статочно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, другие — мощные дорогостоящие системы, поддерживающие процесс разработки ПО, начиная от фор‑мулирования требований и заканчивая внедрением.

По мнению современных авторов, к CASE‑средствам относят лю‑бое программное средство, автоматизирующее ту или иную совокуп‑ность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:üмощные графические средства для описания и документирова‑

ния ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

üинтеграция отдельных компонент CASE‑средств, обеспечиваю‑щая управляемость процессом разработки ИС;

üиспользование специальным образом организованного храни‑лища проектных метаданных.

Наиболее используемыми CASE‑средствами являются CA Erwin Modeling Suite, Rational Suite, ARIS Toolset, Power Designer и Borland Together Designer, BizAgi BPM Suit, ELMA BPM (в следующем подраз‑деле приводится их описание).

22

1.4.2. Описание CASE-средств

1.4.2.1. CA ERwin Modeling Suite

CA Erwin Modeling Suite (URL: http://www.interface.ru) — комплект инструментов фирмы CA Technologies, которые в полной мере обеспе‑чивают решение всех задач анализа, проектирования, генерации, те‑стирования и сопровождения информационных систем. Кратко опи‑шем продукты, входящие в этот пакет.

Process Modeler (ранее BPwin) — инструмент визуального модели‑рования бизнес‑процессов. Дает возможность представить любую де‑ятельность или структуру в виде модели. Process Modeler поддержива‑ет три нотации моделирования: IDEF0, IDEF3 и DFD.

Erwin Data Modeler (ERwin) позволяет проектировать, документи‑ровать и сопровождать БД и хранилища данных. ERwin поддержива‑ет следующие СУБД: СУБД DB2 для LUW и z/OS, СУБД SQL Server 2008 и СУБД Teradata 13.0, Oracle, Interbase, Ingres.

Component Modeler (Paradigm Plus) — средство для моделирования компонентов ПО и генерации объектного кода приложений на основе созданных моделей. Интегрирован с Process Modeler, что дает допол‑нительные возможности при работе с функциональными моделями. Component Modeler обеспечивает полную поддержку UML, поддер‑живает синхронизацию проектирования и реализации приложения. Component Modeler поддерживает генерацию программного кода и об‑ратный инжиниринг программных сборок Microsoft.NET (C# и Visual Basic), Microsoft Visual J++ и Microsoft Visual C++.

Таким образом, CA Erwin Modeling Suite позволяет описывать мо‑дель БП в нотациях IDEF0, IDEF3, DFD, разрабатывать модель дан‑ных и архитектуру ПО с поддержкой различных СУБД. Для анализа и оптимизации БП предлагается использовать функционально‑стои‑мостной анализ. В настоящее время данный пакет особое внимание уделяет моделированию.

1.4.2.2. Продукты компании IBM Rational

Продукты компании IBM Rational (URL: http://www.interface.ru) представляет собой комплекс инструментальных средств, поддержи‑вающих весь жизненный цикл разработки ПО, и интегрирован с IBM

23

Rational Unified Process (RUP). Технически RUP оформлена в виде раз‑мещенной на Web базы знаний, которая снабжена поисковой системой.

CASE‑средство IBM Rational Software Architect предоставляет разра‑ботчику следующие возможности: анализ и проектирование ПО с по‑мощью UML, анализ и контроль структуры приложений Java, подготов‑ка проектной документации. Его компоненты основаны на технологии Eclipse. Расширение Simulation позволяет провести имитационное моделирование поведения ПО на основе UML‑диаграмм деятельно‑сти, последовательности, коммуникации или диаграммы состояний. Rational Software Architect поддерживает генерацию программного кода и обратный инжиниринг: Microsoft Visual Studio 2010 и.NET Frame‑work 4 для C# и VB. NET, Java и C++.

Технология создания ПО, реализованная в IBM Rational, также мо‑жет применяться для проектирования пользовательского интерфейса. Разработка ПИ основана на концепции сценариев вариантов исполь‑зования (use‑case story board) и представляет собой модель взаимодей‑ствия пользователя с ПИ. Такой подход позволяет качественно оце‑нить предложенные решения прежде, чем реальный интерфейс будет спроектирован и реализован.

IBM Rational Rose Data Modeler представляет собой средство моде‑лирования данных в нотации ER.

Продукты компании IBM Rational уделяют внимание разработке архитектуры организации и программного обеспечения, управлению жизненным циклом созданной информационной системы, не затра‑гивая вопросов, связанных с моделированием данных.

ARIS ToolsetИнтегрированная среда ARIS Toolset (URL: http://consulting.ru)

представляет собой комплекс инструментов:üдля проектирования и управления предприятием;üмоделирования, анализа и оценки бизнес‑процессов;üдокументирования бизнес‑процессов в соответствии с требова‑

ниями международных стандартов;üразработки, внедрения и сопровождения ИС.Методология моделирования и проектирования ИС, реализован‑

ная в этой системе, основывается на совокупности различных мето‑дов моделирования, отражающих разные взгляды на проектируемую систему (организация, функции и цели, данные, продукты и услуги, процессы). При построении моделей в ARIS Toolset можно использо‑

24

вать как собственные методы моделирования ARIS, так и известные языки моделирования, например UML, BPMN.

Интегрированная среда ARIS Toolset занимается имитационным моделированием БП, их анализом, совершенствованием и оптими‑зацией, есть возможность использовать нотацию ER для разработки модели данных. Вопросы, касающиеся разработки архитектуры ПО, решаются с помощью других приложений, с которыми у ARIS есть интеграция.

Power DesignerPower Designer (URL: http://www.interface.ru) представляет собой

CASE‑средство фирмы Sybase и имеет модульную архитектуру. Power Designer имеет следующие возможности:üструктурное моделирование бизнес‑процессов;üконцептуальное и физическое проектирование и генерация БД

(поддерживает более 60 СУБД);üобъектно‑ориентированный анализ и моделирование данных

с использованием UML;üинтеграция с ведущими средами разработки (Eclipse, Microsoft

Visual Studio, Power Builder).Power Designer поддерживает моделирование данных, статическое

моделирование БП и приложений. Напрямую не затрагивает следую‑щие вопросы: управление требованиями и конфигурациями ПО; ими‑тационное моделирование.

Borland Together 2008Borland Together (URL: http://www.interface.ru) представляет собой па‑

кет программ фирмы Micro Focus/Borland. Он предназначен для созда‑ния моделей, представляющих собой схему бизнес‑процессов, структу‑ру данных и архитектуру приложений и предприятия. Borland Together состоит из следующих программ: Borland Together Designer, Borland Together Designer Community Edition и Borland Together Developer.

Borland Together предоставляет следующие возможности:üвизуальное моделирование метамоделей для определенной пред‑

метной области;üмоделирование бизнес‑процессов с использованием нотаций

Business Process Modeling, BPMN;üразработка проектов графических моделей программных прило‑

жений в нотации языка UML;

25

üразработка логических диаграмм данных «сущность‑связь» в но‑тации ER и IDEF1x;

üпрямое и обратное проектирование для ведущих СУБД (Oracle, DB2, Sybase, MS SQL Server);

üгенерирование документации;üгенерирование программного кода для Java, C++ и C#;ü распознавание шаблонов проекта исходного кода.Borland Together 2008 является CASE‑средством, которое автома‑

тизирует процесс разработки ПО на этапах моделирования БП, созда‑ния диаграмм «сущность‑связь» с возможностью генерации структуры БП, моделирования ПО, заканчивающееся генерированием програм‑много кода.

BizAgi BPM SuitСистема BizAgi BPM Suit (URL: http://www.b‑k.ru/products/bizagi)

представляет собой платформу для автоматизации БП. Для моделиро‑вания БП используется приложение BizAgi Process Modeler, которое использует нотацию BPMN. BizAgi Studio позволяет преобразовать описанный БП в работающее приложение без участия программиста. Модель находится в хранилище сервера, интерпретируется и выпол‑няется через Web‑приложение на BizAgi BPM Server. Этот сервер по‑зволяет анализировать различные показатели выполнения БП в целях выявления проблемных мест и их улучшения.

Важно сделать замечания относительно функционала приложе‑ний, разрабатываемых с помощью BizAgi, и моделируемых процес‑сов: 1) функциональность приложений относится к классу Workflow; 2) моделирование касается только организационных процессов.

Система BizAgi BPM Suit относится к классу систем управления БП и позволяет разрабатывать проблемно‑ориентированные приложе‑ния класса WorkFlow, с возможностями аналитики и контроля. Дан‑ная система не поддерживает проектирование архитектуры более ши‑рокого класса ПО.

ELMA BPM SuiteELMA BPM Suite (URL: http://crm74.ru) включает в себя приложе‑

ние для управления показателями БП и управление БП. В программе «Дизайнер ELMA» проводится моделирование БП с использованием нотации BPMN. Спроектированная модель хранится на сервере при‑ложения. Далее происходит выполнение БП, причем можно запускать

26

на исполнение несколько экземпляров одного и того же БП. Пользо‑ватель получает информацию о задачах, которые ему необходимо вы‑полнить, в виде страниц в браузере. Система автоматически форми‑рует задачи для каждого сотрудника при выполнении БП. С помощью специальных приложений осуществляется мониторинг и контроль БП.

Система управления БП ELMA BPM Suite позволяет разработать внутренний портал предприятия для управления его работой. Кроме того, предлагаются готовые решения для электронного документообо‑рота, управления проектами. ELMA не поддерживает UML и проек‑тирование широкого класса ПО, имитационное моделирование про‑цессов.

1.4.3. Критерии сравнения функциональных возможностей CASE-средств

Для сравнительной оценки функциональных возможностей CASE‑средств предлагается следующий набор критериев:üнотации, используемые при описании бизнес‑процессов и архи‑

тектуры ИС (IDEF0, DFD, UML, BPMN);üиспользование имитационного моделирования для анализа, со‑

вершенствования и оптимизации БП;üпроектирование ПО на основе имитационной модели БП. Дан‑

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

üразработка моделей лиц, принимающих решения;üописания сценариев принятия решений ЛПР;üпроектирование пользовательского интерфейса, разработка ма‑

кета (предварительного прототипа) пользовательского интер‑фейса;

üконвертация одних диаграмм в другие, при этом для построе‑ния новых диаграмм используется информация, уже отражен‑ная в первых диаграммах;

üпроектирование структуры БД;üвозможность генерации исполняемого кода;üгенерация технической документации к проектируемой ИС. По‑

скольку информация по проекту хранится в единой БД и автома‑тически обновляется при внесении в него изменений, то в любой момент имеется возможность автоматически создавать актуаль‑ную техническую документацию.

27

1.4.4. Сравнительный анализ CASE-средств

Ниже приводится сравнение программных продуктов ARIS Toolset, Power Designer, Borland Together Designer, Продукты IBM Rational, CA ERwin Modeling Suite, BizAgi и Elma в области проектирования ПО (см. таблицу). Они являются наиболее распространенными сре‑ди пользователей — разработчиков программных систем.

Сравнение CASE-средств

Критериисравнения

Продукты IBM

Rational

CA ERwin Modeling

Suite

ARIS Toolset

Power Desig‑

ner

Borland Together Designer

Biz‑ Agi Elma

Поддерж‑ка IDEF0, DFD Нет Да Да Нет Нет Нет Нет

Поддержка UML Да Да Да Да Да Нет НетПоддержка BPMN Нет Нет Да Нет Да Да Да

ИМ БП Нет Нет Да Нет Нет Да НетПроектирова‑ние ПО на основе ИМ БП

Нет Нет Нет Нет Нет Да Да

Разработка моде‑ли ЛПР Нет Нет Нет Нет Нет Да Да

Описание сцена‑рия принятия ре‑шений ЛПР

Нет Нет Нет Нет Нет Да Нет

Проектирование ПИ Нет Нет Нет Нет Нет Да Нет

Конвертация ди‑аграмм Нет Нет Нет Нет Нет Нет Нет

Проектирование структуры БД Да Да Да Да Да Нет Нет

Генерация тех‑документации к создаваемой ИС

Да Да Да Да Да Да Нет

В пакете CA ERwin Modeling Suite отсутствуют средства имитаци‑онного моделирования бизнес‑процессов, но есть возможность экс‑портировать модель в систему моделирования Arena.

ARIS Toolset, помимо указанных нотаций, использует большое ко‑личество других нотаций (диаграммы Чена, Object Modeling Technique).

28

Следует отметить, что большое количество нотаций требует дополни‑тельных знаний от аналитика для их использования. В пакете ARIS Toolset имеется адаптированный движок моделирования, к недостат‑кам которого можно отнести отсутствие поддержки моделирования систем массового обслуживания.

Power Designer и Borland Together Designer прежде всего являют‑ся средствами для разработки UML‑диаграмм и генерирования про‑граммного кода, они не предоставляют возможностей для анализа и имитационного моделирования процессов. Рассмотренные систе‑мы класса BPM подходят для разработки узкого класса систем.

Все рассмотренные продукты можно разделить на четыре группы:üсистемы, охватывающие весь жизненный цикл программного

обеспечения (продукты IBM Rational, CA ERwin Modeling Suite);üсистемы, автоматизирующие разработку программного обеспе‑

чения (Power Designer и Borland Together Designer);üсистемы анализа и имитационного моделирования бизнес‑про‑

цессов (ARIS Toolset);üсистемы управления бизнес‑процессами (BizAgi и Elma).Поскольку в работе рассматриваются задачи автоматизации процес‑

сов организационно‑технических систем, то наилучшими вариантами представляются системы третьей группы (ARIS Toolset).

К недостаткам описанных CASE‑средств можно отнести следующее:üотсутствует интеграция структурного и объектно‑ориентирован‑

ного подхода;üотсутствие интеллектуальности процесса проектирования (не ре‑

шена задача автоматического перехода к проектированию одних диаграмм на основе других);

üуправление бизнес‑процессами только определенного класса си‑стем (Workflow);

üотсутствие пакетов для имитационного моделирования бизнес‑процессов, а следовательно, и возможности использовать ин‑формацию из модели при проектировании информационной системы.

В следующей главе описывается новый метод поддержки принятия решений при разработке информационных систем и CASE‑средство, которые устранили эти недостатки.

29

2. Метод поддержки принятия решений при разработке информационных систем для предметной области мультиагентных

процессов преобразования ресурсов

2.1. Требования к модели и методу поддержки принятия решений

при разработке информационных систем

Р ассмотрим разработку ИС предметной области мультиагент‑ных процессов преобразования ресурсов. На основе прове‑денного анализа методологических и теоретических основ

поддержки принятия решений, моделирования и разработки ИС (см. подглаву 1.3) и CASE‑средств (см. параграф 1.4.4) сформулиру‑ем требования к методу поддержки принятия решений в области раз‑работки ИС.

Метод ППР при разработке ИС должен обеспечивать автоматиза‑цию процесса создания ИС для предметной области организацион‑но‑технических систем. Таким образом, можно выделить следующие требования:üвыбор методики системного анализа и модели для формализа‑

ции процессов ОТС. При этом будем учитывать наличие ЛПР, которые могут быть представлены в виде ИА;

üИМ для проверки модели «Как будет» на этапе реинжиниринга БП и оценки производительности ИС;

üинтеллектуальная разработка ИС, включающая функциональ‑ный и объектно‑ориентированный анализ, моделирование ПИ, формирование исполняемого кода ИС.

30

Рассмотрим принципы построения интеллектуальных СППР в об‑ласти разработки ПО (CASE‑средств). Структура такой системы вклю‑чает в себя диалоговую ЭС, состоящую из базы знаний, БД, механизма логического вывода, а также блок объяснения полученных решении, блок обучения (адаптация ЭС к изменяющейся действительности), блок понимания, блок ведения, пополнения и корректировки БЗ.

В подглаве 2.2 проведено сравнение различных моделей БП и вы‑брана одна для представления ППР. Задача выбора модели представ‑ления знаний о предметной области решается в подглаве 2.3.

2.2. Выбор модели представления бизнес-процессов

Математические модели дискретных процессов для представления ППР: сети Петри, расширенные сети Петри, системы массового обслу‑живания, модели системной динамики — не обеспечивают всех тре‑бований для моделирования ППР. Поэтому математическая модель ППР была расширена аппаратом мультиагентных систем [9].

Динамическая модель МППР [10] включает процессы (PR), опера‑ции (Op), ресурсы (RES), команды управления (U), средства (MECH), источники (Sender) и приемники ресурсов (Receiver), перекрестки (Junction), параметры (P), агенты (Agent). Отдельно выделены инфор‑мационные типы ресурсов: сообщения (Message) и заявки на выпол‑нение операции (Order). Описание причинно‑следственных связей между элементами преобразования и ресурсами задается объектом «связь» (Relation).

i‑я операция (Opi) представлена следующей структурой:Opi = <f, RESini, RESouti, MECHi>,

где f — функция, которую реализует i‑я операция;RESini — входные ресурсы для выполнения i‑й операции;RESouti — выходные ресурсы для выполнения i‑й операции:RESouti = f (RESini);MECHi –механизмы для выполнения i‑й операции.Здесь RESini ={RESini1, RESini2, …, RESinik} — множество входных

ресурсов;RESouti ={RESouti1, RESouti2, …, RESoutim} — множество выходных

ресурсов.Семантика процесса преобразования ресурса показана на рис. 2.1.

31

Операция(преобразователь)Ресурс

Ресурс/ Средство

Ресурс

Команда

ВХОД ВЫХОД

СРЕДСТВО

УПРАВЛЕНИЕ

Рис. 2.1. Семантика процесса преобразования ресурса

Результаты сравнения математических моделей дискретных про‑цессов приведены в табл. 2.1.

Таблица 2.1результаты сравнения математических моделей дискретных процессов

Характеристики Сети Петри

Расширен‑ные сети

ПетриСМО

Модели системной динамики

Модель МППР

Учет временных характери‑стик Нет Да Да Да Да

Возможность учета различ‑ных типов ресурсов Нет Да Да Нет Да

Моделирование конфликтов на общих средствах Нет Нет Да Нет Да

Модель ЛПР (ИА) Нет Нет Нет Нет Да

Полученную математическую модель МППР предлагается исполь‑зовать в качестве модели описания БП. К преимуществу модели МППР относится возможность использования моделей ЛПР.

При разработке CASE‑средств важно выбрать модель представле‑ния знаний (для реализации семантики перехода от объектов автома‑тизируемого процесса к объектам предметной области ИС). Эта зада‑ча решается в подглаве 2.4.

32

2.3. Выбор модели представления знаний

Рассмотрим существующие в настоящее время в литературе спосо‑бы представления знаний. При анализе учитываются следующие тре‑бования:üнаиболее простой и естественный переход от неформализован‑

ных знаний и представлений к формальным моделям для описа‑ния БП и ИС, наглядность представления информации для поль‑зователя;

üудобство представления иерархических данных, поскольку пред‑метные области МППР и ИС образуют иерархию;

üпростота добавления новых знаний;üтехническая реализация выбранной модели должна быть доста‑

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

üвозможность использования языка UML в качестве визуального языка представления знаний (объектно‑ориентированный анализ).

1-й способ. Представление знаний в виде продукций или правил и их интерпретатор, определяющий когда и какое правило применяется

В продукционную модель достаточно просто добавлять новые зна‑ния, поскольку любая продукция может размещаться в любом месте модели. Механизм вывода в этом способе хорошо сочетается с проце‑дурным подходом в программировании.

В качестве недостатков можно указать следующее: неудобно реали‑зовывать иерархическую структуру, ненаглядное представление знаний и неэффективный процесс вывода, поскольку в общем случае необхо‑димо проверить применимость всех правил.

2-й способ. Представление знаний в виде семантической сетиВ литературе дается следующее определение семантической сети.

Семантическая сеть — это ориентированная графовая структура, каж‑дая вершина которой отображает некоторое понятие (объект, процесс, ситуацию), а ребра графа соответствуют отношениям типа «это есть», «принадлежать», «быть причиной», «входить в», «состоять из», «быть как» и аналогичным между парами понятий.

Можно указать следующие достоинства данного способа: нагляд‑ность представления знаний для пользователей, семантическая модель

33

хорошо сочетается с иерархическими знаниями. К недостаткам мож‑но отнести сложность реализации механизма вывода.

3-й способ. Представление знаний в виде фреймовОпределение фрейма дал М. А. Минский. Он определил фрейм

как структуру данных для представления стереотипных ситуаций [2]. Фреймовая модель представления знаний задает основу описания класса объектов и удобна для описания структуры и характеристик однотипных объектов (процессов, событий), описываемых фрей‑мами — специальными ячейками (шаблонами понятий) фреймовой сети (знания).

Фрейм состоит из слотов, которые представляют собой различные характеристики объекта (атрибуты), и наполнителей (значения этих атрибутов и процедуры, выполняющиеся при изменении данных фрей‑ма). У каждого фрейма есть специальный слот, который хранит наи‑менование сущности, которую он представляет. Также, фрейм можно рассматривать как узел некоторой сети. Связи могут быть следующих типов: экземпляр‑класс и класс‑суперкласс.

Фреймовое представление знаний достаточно наглядно подходит для представления иерархических знаний, хорошо сочетается с объ‑ектно‑ориентированным подходом, поэтому переход от описания зна‑ний к программной реализации информационной системы происходит достаточно просто. К недостаткам фреймовой модели можно отнести сложность внесения изменений в иерархическую структуру данных.

Сочетание семантических сетей и фреймов позволяет минимизиро‑вать недостатки этих двух способов с сохранением достоинств.

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

Швецов А. Н. [23] предложил совместить фреймоподобные струк‑туры с конструкциями концептуальных графов J. F. Sowa [4]. Фрейм‑концепт состоит из следующих частей:üимя фрейма является уникальным идентификатором, позволя‑

ющим однозначно определить фрейм;üинформация о применении фрейм‑концепта представляет со‑

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

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

34

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

üструктура слотов состоит из структуры концептов и структуры атрибутов.

Для установления логической организации предметной области фрейм‑концепты соединяются в структуры концептуальных графов. Концептуальный граф — это двудольный граф, имеющий два типа вер‑шин: вершины концептов, или концептуальные вершины, и верши‑ны концептуальных отношений.

Достоинства фреймово‑семантического подхода: эффективно реа‑лизует иерархическое представление данных, хорошо сочетается с объ‑ектно‑ориентированным подходом. В настоящее время уже решена за‑дача технической реализации данной модели представления знаний на уровне реляционной базы данных [9].

Сравнительный анализ рассмотренных моделей представления зна‑ний показан в виде табл. 2.2.

Таблица 2.2Сравнение различных моделей представления знаний

Требования к модели Продукции Семантические сети Фреймы ФК и КГ

ШвецоваНаглядность Нет Да Да ДаПредставление иерархиче‑ских данных Нет Да Да Да

Простота добавления новых знаний Да Нет Нет Да

Согласованность с ООП Нет Нет Да ДаИспользование UML Нет Нет Да ДаОписание ИА Нет Нет Нет Да

Выбор фреймово‑семантической модели представления знаний дает следующие преимущества:üсогласованность фреймово‑семантической модели с концепцией

объектно‑ориентированного программирования обосновывает применение объектных языков программирования при разработ‑ке базы знаний и минимизирует затраты на создание програм‑много обеспечения;

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

35

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

На основе выбранной модели представления знаний в парагра‑фе 2.4.1 описывается концептуальная модель предметной области мультиагентных процессов преобразования ресурсов, а концептуаль‑ная модель предметной области проектирования информационных систем описана в параграфе 2.4.2.

2.4. Построение модели разработки информационной системы

2.4.1. Концептуальная модель предметной области мультиагентных процессов преобразования ресурсов

Основываясь на модели бизнес‑процессов, выбранной в подгла‑ве 2.3, можно построить следующую фреймово‑семантическую модель мультиагентных процессов преобразования ресурсов (рис. 2.2) [16].

При автоматизации процессов предприятия любому преобразовате‑лю соответствует функция обработки данных, однонаправленная или двунаправленная (генерация, прием, передача, изменение, удаление).

Агент управляет объектами процесса принятия решений, выпол‑няя следующие действия:üанализирует внешние параметры (текущую ситуацию);üдиагностирует ситуацию, обращается к базе знаний, в случае

определения соответствующей ситуации агент пытается найти решение (сценарий действий) в базе знаний или выработать его самостоятельно;

üпринимает решение;üопределяет или переопределяет цели;üконтролирует достижение целей;üделегирует цели своим и чужим объектам процесса преобразова‑

ния ресурсов, а также другим агентам;üобменивается сообщениями.Архитектура агента мультиагентных процессов преобразования ре‑

сурсов основана на гибридной архитектуре InteRRaP и представлена на рис. 2.3.

36

Рис.

2.2

. Сем

анти

ческ

ая с

еть

МП

ПР

Вызы

вает

МП

ПР

Пре

обра

зова

тели

Аге

нты

Ресу

рсы

Пар

амет

ры

Опе

раци

и

Ист

очни

ки

Про

цесс

ы

При

емни

ки

Пер

екре

стки

Соо

бщен

ия/

ком

анды

Заяв

ки

Сре

дств

а

Час

ть-ц

елое

Час

ть-ц

елое

Час

ть-ц

елое

Час

ть-ц

елое

Час

ть-ц

елое

Упр

авля

ет

Исп

ольз

ует

Нас

ледо

вани

е

Нас

ледо

вани

е

Мод

ель

пове

дени

я

Пра

вила

ан

ализ

а си

туац

ии

Дей

стви

я аг

енто

в

Реш

ения

Про

дукц

ион-

ная

БЗ

Дей

стви

я

Сос

тоит

из

Ини

циир

уют

Ини

циир

уют

поис

к ре

шен

ия

Ана

лизи

рую

тсо

стоя

ние

Нас

ледо

вани

е

Кор

рект

ирую

т

Изм

еняю

т со

стоя

ние

ресу

рсов

и с

редс

тв,

целе

й и

пара

мет

ров,

стру

ктур

у М

ПП

Р,м

арш

руты

заяв

ок

Цел

и аг

енто

вС

осто

ит и

з

Час

ть-ц

елое

Фре

ймов

ая

БЗ

Ини

циир

уют

поис

к ре

шен

ия

Час

ть-ц

елое

37

МАС

Модель мира агента(преобразователи, агенты,

ресурсы, средства, параметры,цели)

Подсистема имитационного моделирования

Внутреннее поведение(диаграмма активности)

Интерфейс с внешним миром

Логический вывод по СБЗ

(диаграмма последователь-

ности)

Стратегическая база знаний

(СБЗ) (фреймы)

Планирующая подсистемаРеактивная подсистема

Логический вывод по ТБЗ

(прямой вывод)

Тактическая база знаний (ТБЗ)(продукции)

Модель мира агентаСенсоры

Эффекторы

Эффекторы

Сенсоры

Рис. 2.3. Архитектура агента МППР

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

Определим свойства и методы фрейм‑концептов предметной об‑ласти МППР. ФК перечисляются по мере их усложнения и согласно принципу «от общего к частному». В скобках у ФК указывается назва‑ние родительского ФК, если такой есть.

фК «ресурс»Свойства:üидентификатор (ID_RES);üназвание ресурса (RES_Name);üтип ресурса (kind);üтекущее значение ресурса (RESt);üмаксимально возможное значение ресурса (RESmax);üначальное значение ресурса (RES0);üконечное значение ресурса (REST);üцена единицы ресурса (Cost);üвремя начала моделирования (t0);üединица измерения ресурса (Metric_R).

38

Рис.

2.4

. Мод

ель

ОТС

Ист

очни

к1

Про

цесс

1

При

емни

к1Ре

сур-

сы 1

и

2

Ресу

р-сы

5

и 6

Упр

ав-

лени

е 1

и 2

Пар

амет

р1

БЗ А

гент

а 1

Мех

а-ни

змы

1

и 2

Аге

нт 1

Опе

раци

я2О

пера

ция3

Упр

ав-

лени

е1

БЗ А

гент

а 2

Мех

а-ни

зм1

Ресу

рс1

Ресу

рс2

Ресу

рс3

Мех

а-ни

зм2

Упр

ав-

лени

е2Ре

сурс

5

Ресу

рс6

Ресу

рс4

БЗ А

гент

а 3

Соо

бщен

ия

Аге

нт 2

Аге

нт 3

39

Методы:üсуммарное приращение ресурса за интервал времени (Hsuminc_t);üсуммарное уменьшение ресурса за интервал времени (Hsumdec_t);üстоимость ресурса (Cost_sum);üприращение ресурса в текущий момент времени (Hinc);üуменьшение ресурса в текущий момент времени (Hdec).

фК «Команда» (ресурс)Свойства:üидентификатор (ID_Cmd);üназвание ресурса (Cmd_Name);üтип команды (kind);üотправитель (Msender);üполучатель (Mresiver);üтекст сообщения (text);üприоритет (prior);üпризнак обработки (read);üвремя создания (Tcreate);üвремя ожидания в очереди (Twait).

фК «заявка» (ресурс)Свойства:üидентификатор (ID_Order);üназвание ресурса (Order_Name);üзаказываемый объем работ (count);üвыполненный объем работ (real);üпризнак блокировки заявки (lock);üимя элемента, обрабатывающего заявку (Owner);üимя блока, создавшего заявку (Parent);üприоритет заявки (prior);üвремя создания заявки (Tcreate);üвремя ожидания заявки в очереди (Twait).

фК «Средство» (ресурс, операция)Свойства:üидентификатор (ID_Mech);üназвание ресурса (Mech_Name);üтип команды (kind);üтекущее количество свободных средств (Mecht);

40

üвсего средств (Mechall);üвремя создания (Tcreate);üсостояние средства (Status);üединоразовые затраты ресурсов при начале преобразования

(RESin);üединоразовые затраты ресурсов при окончании преобразования

(RESout);üрасход ресурсов в единицу времени (RESuse);üединоразовые затраты ресурсов при захвате средства другой опе‑

рацией (RESlock);üединоразовые затраты ресурсов при освобождении (RESunlock);üзатраты ресурсов при возникновении и устранении поломки

(RESother);üпериодичность возникновения поломки (Tother);üначальная цена единицы средства (Cost);üсуммарное время использования средства (Tmech_use);üсуммарное время простоя средства (Tmech_stand).Методы:üдействие по запуску средства в момент начала преобразования (Amin);üдействие по остановке средства в момент окончания преобразо‑

вания (Amout);üдействие по выполнению преобразования (Amuse);üдействие по остановке средства в момент прерывания преобра‑

зования (Amlock);üдействие по запуску средства в момент продолжения преобразо‑

вания (Amunlock);üдействие по устранению поломки (Amother);üпроизводительность средства в единицу времени (product).Операция является наиболее общим элементом МППР, осталь‑

ные (источники, приемники, перекрестки) содержат усеченный набор свойств и методов, поэтому приведем только описания ФК «Опера‑ция». У ФК «Источник» есть только множество выходов. У ФК «При‑емник» есть только множество входов. У ФК «Перекресток» есть мо‑дель его поведения.

фК «операция» (Преобразователь)Свойства:üмножество входов (IN);üмножество выходов (OUT);

41

üмножество ресурсов, необходимых для прерывания операции (RESlock);

üмножество ресурсов, необходимых для продолжения выполнения операции, остановленной в результате прерывания (RESunlock);

üцели операции (GOp);üсредства преобразования (MECH);üсостояние операции (Status);üдлительность выполнения преобразования (time);üприоритет операции (prior);üтип приоритета (kind_prior);üпризнак запрета прерывания (break_off).Методы:üфункция, реализуемая операцией (f);üCa

message– условие наличия необходимых входных сообщений;üCa

order– условие наличия необходимых входных заявок;üCa

in– условие наличия необходимых входных ресурсов;üCa

out — условие учета ограничений выхода;üCa

mech — условие готовности необходимых средств;üCa

status — условие готовности к исполнению;üCa

time — условие запуска по времени;üActionin

Message — захват входного сообщения;üActionin

Order — захват входных заявок;üActionin

RES — захват входных ресурсов;üActionin

MECH — захват средств;üActionout

Message — формирование выходных сообщений;üActionout

Order — формирование выходных заявок;üActionout

RES — формирование выходных ресурсов;üActionout

MECH — освобождение захваченных средств.

фК «Агент»Свойства:üидентификатор (ID_Agent);üназвание агента (Agent_Name);üцели агента (GAgent);üприоритет агента (prior);üбаза знаний агента (KBAg);üколичество входящих сообщений (Messin_count);

42

üколичество исходящих сообщений (Messout_count);üсценарий поведения (SPA);üмножество управляемых объектов МППР (Control_objects);üмножество агентов «начальников» (AU);üмножество подчиненных агентов (AD).Методы:üанализ мира (Analize);üдиагностирование ситуаций (Diagnost);üпоиск решения (Search);üобработка целей;üконтроль достижения целей;üделегирование целей;üобмен сообщениями;üвзаимодействие с БЗ и БД.

фК «Параметр»Свойства:üидентификатор (ID_Param);üназвание параметра (Param_Name);üтекущее значение параметра (Pt);üначальное значение параметра (P0);üописание параметра (desc), плановое значение (plan).

Метод — функция вычисления параметра (f).Таким образом, в данном подразделе описаны основные ФК КМПО

предметной области МППР.

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

Предлагаемая КМПО ИС позволяет показать структуру ИС и взаи‑мосвязи между всеми ее составляющими [19]. На первом уровне фрей‑мово‑семантической сети находятся узлы, соответствующие програм‑мному обеспечению и базе данных ИС. Поскольку при моделировании и разработке ИС используют функциональный и объектно‑ориентиро‑ванный подходы (см. параграф 1.1.2), то она также содержит ФК эле‑ментов моделирования архитектуры ПО, включая ФК следующих ди‑аграмм: функциональных (IDEF0), потоков данных (DFD) (рис. 2.5)

43

и диаграмм языка UML (прецедентов, последовательностей и классов, рис. 2.6–2.8). Эти стандарты не включают в себя описание конкрет‑ных реализаций операций, тем не менее соответствующие ФК содер‑жат методы, аналогичные методам ФК «Операция». Это позволяет со‑хранить данную информацию при переходе от модели МППР к модели ИС, а затем использовать ее при подготовке программных модулей.

DFD

Функция Внешняя сущность

Хранилище данных

Поток данных

Часть-целое Часть-целое

Часть-целое Часть-целое

Выполняет Взаимодействует

Преобразует

Рис. 2.5. Семантика DFD‑диаграммы

Диаграмма прецедентов

Роль Прецедент

Часть-целоеЧасть-целое

Выполняет /участвует

Рис. 2.6. Семантика диаграммы прецедентов

Диаграмма последовательности

Роль Метод


Управляет Класс /объект Инициирует

Часть-целое

Рис. 2.7. Семантика диаграммы последовательности

Диаграмма классов

Класс Отношение между

классами


Экземпляр класса Объект

Связывает

Рис. 2.8. Семантика диаграммы классов

44

Определим структуру фрейм‑концептов.1. Фрейм‑концепты DFD‑диаграммы

фК «функция»Свойства:üИдентификатор (ID_F);üназвание (F_Name);üмножество входов (IN);üмножество выходов (OUT).Метод — функция преобразования (f).

фК «Внешняя сущность»Свойства:üидентификатор (ID_Ex);üназвание внешней сущности (Ex_Name);üцели внешней сущности (ExG);üприоритет внешней сущности (Exprior).

фК «хранилище данных»Свойства:üидентификатор (ID_DS);üназвание хранилища данных (DS_Name);üструктура хранилища данных (DS_Structure).

фК «Поток данных»Свойства:üидентификатор (ID_DF);üназвание потока данных (DF_Name);üтип потока данных = {Select, Insert, Delete, Update, Unknown}

(DF_kind);üтекущее значение потока данных (DFt);üмаксимально возможное значение потока данных (DFmax);üначальное значение потока данных (DF0);üконечное значение потока данных (DFT);üцена единицы потока данных (DF_Cost);üединица измерения потока данных (DF_Metric_R).

45

2. Фрейм‑концепты диаграммы прецедентов

фК «роль»Свойства:üидентификатор (ID_R);üназвание роли (R_Name);üцели роли (RG);üприоритет роли (Rprior).

фК «Прецедент»Свойства:üидентификатор (ID_UC);üназвание (UC_Name).Методы:üфункция преобразования (UC_f);üусловие запуска (UC_Ca).

3. Фрейм‑концепты диаграммы классов

фК «Класс»Свойства:üидентификатор (ID_class);üназвание (Class_Name);üдругие свойства, определяются предметной областью.Методы класса определяются предметной областью.

фК «объект»Представляет собой экземпляр соответствующего класса, его свой‑

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

фК «отношение между классами»Возможны следующие типы отношений [12]:üассоциации — произвольная взаимосвязь;üобобщение — взаимосвязь между классом‑родителем и классом‑

потомком;üагрегация — взаимосвязь между классом‑контейнером и клас‑

сом‑частью;üкомпозиция — агрегация, при которой с уничтожением класса‑

контейнера уничтожаются все его классы‑части;

46

üзависимость — взаимосвязь между классами, при которой одному или нескольким классам требуются другие классы для их специ‑фикации или реализации;

üреализация — взаимосвязь между классами, при которой один класс представляет некоторую спецификацию, а другой — его реализацию.

Свойства:üидентификатор (ID_rl);üназвание (Rl_Name);üтип отношения (Rl_type);üмножество начальных классов (Beg_classes);üмножество конечных классов (End_classes).Предлагаемый метод поддержки принятия решений в области мо‑

делирования и разработки информационных систем должен решать задачу перехода от концептуальной модели предметной области муль‑тиагентных процессов преобразования ресурсов к концептуальной мо‑дели предметной области разработки информационных систем. Этот метод изложен в следующей подглаве.

2.5. Метод разработки информационных систем

Рассмотрим последовательность действий, позволяющих перейти от концептуальной модели предметной области мультиагентных про‑цессов преобразования ресурсов к концептуальной модели предметной области разработки информационных систем (ФК DFD‑диаграммы и ФК UML‑диаграмм). Для описания семантики переходов между раз‑личными моделями БП и ИС используется диаграмма состояния объ‑екта (стандарта IDEF5) [13].

ресурс (RES)Ресурс в ИС может представлять собой переменную: RESini→VARi, RESoutk→VARk,

где RESini — i‑й входной ресурс; VARi — i‑я переменная; RESoutk — k‑й выходной ресурс.

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

47

Ресурс

Строка

ввода

Поле

ввода

Таблица

Перемен

- ная

Файловая

перемен

- ная

Набор

данных

Запись

в

файле

Запись

в

таблице

Проектирование

ПИ

Написание

кода

Проектирование

хранилищ

а

Точка

принятия

решения

Рис.

2.9

. Сем

анти

ка п

ерех

ода р

есур

са в

эле

мент

ы И

С

48

Возможны следующие варианты: простой тип, пользовательский тип, массив (на уровне переменных кода), таблица (на уровне базы данных). Семантика перехода ресурса в элементы информационной системы приведена на рис. 2.9. Семантика перехода ресурса в объек‑ты диаграмм показана на рис. 2.10.

Преобразовать в DFD Преобразовать в UML- диаграмму классов

Ресурс

Поток данных

Хранили- ще

данных

Класс Ресурс

Рис. 2.10. Семантика перехода ресурса в объекты диаграммы

Сценарий перехода ресурса можно представить схемой (рис. 2.11).

Преобразователь (Tr)К преобразователю относятся процессы, источники, приемники

и перекрестки. Преобразователь как функция преобразования вход‑ных ресурсов в выходные может быть реализован в виде функции (ПО), которая выполняет обработку данных в памяти или на уровне файлов, или хранимой процедуры базы данных:

Tri→Funci, Tri→StoredProci,где Tri — преобразователь;

Funci — функция ПО;StoredProci — хранимая процедура.При необходимости следует предусмотреть наличие элементов ПИ

для определения условий начала преобразования. Входными параме‑трами для функции или ХП будут входные ресурсы, а выходными па‑раметрами — выходные ресурсы. Таким образом, определив на 1‑м этапе ресурсы, тем самым зададим типы параметров функций или ХП.

49

В процессе интеллектуального моделирования и разработки ПО мож‑но предоставить возможность описать алгоритм выполнения опера‑ции на алгоритмическом языке или T‑SQL.

Семантика перехода преобразователя в объекты информационной системы приведена на рис. 2.12.

Семантика перехода ресурса в объекты диаграмм показана на рис. 2.13.

Переход от КМПО мультиагентных процессов преобразования ресурсов к КМПО информационной системы при работе с преоб‑разователем определяется результатом перехода соответствующих ресурсов.

ДА

Нужно ли постоянно

хранить информацию o ресурсе?

Информация o ресурсе будет хранится в БД?

Проектирование таблицы для

хранения ресурса

Проектирование файла для хранения

ресуса

Сохранение ресурса в переменной

Выбор типа переменной

НЕТ

НЕТ

ДА

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

отображение ресурса

Рис. 2.11. Блок‑схема перехода ресурса

50

Таблица

Строка вводаПреобра-

зователь

Функции

Проектирование ПИНаписание кода Проектирование структуры БД

ХП

Точка принятия решения

Рис. 2.12. Семантика перехода преобразователя в объекты ИС

Преобра-зователь Функция

Преобразовать в DFD

Преобразовать в UML- диаграмму

классов

Класс Преобра-зователь

Преобразовать в UML- диаграмму

прецедентов

Преце-дент

Рис. 2.13. Семантика перехода преобразователя в объекты диаграммы

Сценарий перехода преобразователя к элементам информацион‑ной системы показан на рис. 2.14. Написание алгоритма преобразо‑вания ресурса в предлагаемом методе возможно уже на уровне проек‑тирования модели информационной системы.

Средства (MECH)Средствами выполнения операций могут быть различные техниче‑

ские устройства, которыми оборудовано рабочее место человека, на‑пример контроллеры, датчики, компьютер, принтер, сканер. Инфор‑мация об их характеристиках, полученная в процессе проектирования, идет в раздел «Технические требования к ПО». В некоторых ситуаци‑ях оператора этих устройств тоже можно рассматривать как средство. При моделировании и разработке ИС необходимо учитывать характе‑ристики процессов обработки и передачи данных, так как в конечном итоге они оказывают влияние на характеристики основного процесса.

51

Рис. 2.14. Блок‑схема перехода преобразователя

Моделирование элементов ПИ

Преобразование на уровне БД?

Определяем входящие ресурсы преобразователя

Определяем исходящие ресурсы преобразователя

Написание ХПНаписание

пользовательской функции

НЕТ

Необходимо хранить информацию о преобра-

зовании в БД?

Создание таблиц БД

ДА

ДА

НЕТ

52

При разработке человеко‑машинных программных комплексов при решении вопросов защиты информации средствам устанавливаются в соответствие определенные роли и назначаются права доступа к тем или иным объектам и функциям ИС. Таким образом, наблюдается ана‑логия с ресурсом. Поэтому за основу схемы проектирования средств взята схема проектирования ресурса.

Параметры (P)Параметры (P) — это некоторая демонстрация пользователю харак‑

теристик протекания процесса или операции. В простейшем случае — это компонент «полоса прогресса», демонстрирующий как долго про‑цесс еще будет работать. Также это может быть некоторое значение, вычисляемое по формуле, например какая‑то характеристика ресур‑са. Следовательно, пользователь должен определить формулу и спо‑соб отображения параметра (график, текстовое поле):

Pk→ <Componentk, Fk>,

где Pk — k‑й параметр; Componentk — k‑й визуальный компонент ПИ; Fk — k‑я функция ПО.

Семантика перехода параметра представлена на рис. 2.15.

Элемент ПИ

Параметр Функция

Проектирование ПИНаписание кода Проектирование структуры БД

Таблица

Рис. 2.15. Семантика перехода параметра

Сценарий перехода параметра показан на рис. 2.16.

53

Определить ресурс, состояние которого отображает параметр

Написать функцию вычисления параметра

Определить визуальный компонент, отображающий

значения параметра

Рис. 2.16. Блок‑схема перехода параметра

Агенты (Agent)Агенту соответствует модель ЛПР, имеющая сложную структуру.

При ее построении используют подходы искусственного интеллекта (например, в основе модели может лежать алгоритм или сценарий по‑ведения, реализованный в виде ЭС; она включает в себя машину ло‑гического вывода, базу знаний, правила и рабочую память). С точки зрения ИС агент представляет собой программную сущность, у кото‑рой при необходимости имеется ПИ, функции, описывающие сцена‑рий работы агента, и таблица для хранения БЗ агента. Возможна реа‑лизация сценария на уровне БД в виде ХП. Семантика перехода агента в элементы ИС приведена на рис. 2.17.

Написание кода Проектирование ПИ

Агент

Функция

Элементы ПИ

Проектирование хранилища

ХП

Таблица

Рис. 2.17. Семантика перехода агента в элементы ИС

Семантика перехода агента в объекты диаграмм приведена на рис. 2.18. С помощью диаграммы последовательности моделиру‑ется сценарий поведения агента.

54

Преобразовать в DFDПреобразовать

в UML-диаграмму классов

Агент

Внешняя сущность

Функция

Класс Агент

Преобразовать в UML-диаграмму

прецедентов

Преце-дент

Роль

Рис. 2.18. Семантика перехода агента в объекты диаграмм

Рассмотрим сценарий перехода агента в объекты ИС (рис. 2.19).

Проектирование ПИ для агента

Описание сценария принятия решений

агента

Проектирование таблицы для

хранение БЗ агента

Реализация сценария в виде функции или ХП

Рис. 2.19. Блок‑схема перехода агента

Далее приводится метод ППР разработки ИС предметной области МППР, состоящий из пяти следующих этапов [19]:

1. Разработка ИС начинается с обследования предметной области и построения имитационной модели МППР «Как есть».

2. На втором этапе проводятся имитационные эксперименты с моде‑лью «Как есть» в целях выявления узких мест в организации процессов. По результатам моделирования строится модель МППР «Как будет».

3. На третьем этапе осуществляется построение модели ИС на ос‑новании данных из модели МППР.

55

Каждая операция из модели МППР, которую необходимо автома‑тизировать в ИС, преобразуется в функцию DFD‑диаграммы. На ди‑аграмме классов создается базовый класс операций, для каждой опе‑рации — экземпляр базового класса.

Все ресурсы, используемые в автоматизируемых операциях, преоб‑разуются в потоки данных DFD‑диаграммы, причем входные ресур‑сы i‑й операции становятся входными потоками i‑й функции DFD‑диаграммы, а выходные ресурсы — выходными потоками i‑й функции DFD‑диаграммы. На диаграмме классов создается базовый класс ре‑сурса, для каждого ресурса — экземпляр базового класса.

Для всех ресурсов модели необходимо создать хранилища данных на DFD‑диаграмме. На UML‑диаграмме классов создается базовый класс для хранилища данных.

Все агенты из модели МППР, которые будут реализованы програм‑мно, преобразуются во внешние сущности DFD‑диаграммы. На диа‑грамме классов создается базовый класс агента, для каждого агента — экземпляр базового класса. На основании данных из DFD‑диаграммы создаются диаграммы прецедентов. Каждая внешняя сущность пре‑образуется в актера соответствующей диаграммы прецедентов, а свя‑занные с ней функции — в прецеденты.

Преобразование агента рассмотрим на примере агента с одним пра‑вилом («если» a > b, «то» a = a ‑ b). Элементы памяти, необходимые для хранения переменных, преобразуются в хранилища данных DFD‑диаграммы, правила «если» и «то» — в операции. В результате получа‑ем DFD‑диаграмму, представленную на рис. 2.20.

Проверка выполнения условия «если» правила

Выполнение условия «если», приводящего

к изменению РП

РП.a

РП.b

РП.результат выполнения

Выполнение действия

«то»

Моделирование выполнения правила с задержкой

по времениt t0

Tend

Рис. 2.20. Пример DFD‑диаграммы для реактивного агента с одним правилом

56

Рис.

2.2

1. Д

иагр

амма

пои

ска р

ешен

ия И

А пр

оект

иров

ания

ИС

при

кон

верт

ации

аген

та н

а про

дукц

иях

Правило

Если

ТоПравила

для

выполнений

Подсистема объяснения

Ресурсы

Средства

Заявки

1.

2.

, у которых выполняется часть «если

»

Фиксация ситуации

и текущ

его шага поиска

Запрос

инф

ормации о ресурсах

Результат запроса

Запрос

инф

ормации о средствах

Запрос

инф

ормации о заявках



3. Форми

рование п

равила

для

вып

олнения

4. Ситуация диагностирована

5. Разрешение

конфликтов

Фиксация конф

ликтов

правил и протокола разреш

ения

конфл

иктов,

а такж

е текущего шага поиска

6. Правила

готовы

к выполнению

7. Применение правил

8. Выполнение

части

«то»

и фиксация изменений в рабочей памяти

Изменение

инф

ормации о ресурсах

Подтверждение изменений

Изменение

инф

ормации о средствах

Изменение

инф

ормации о заявках



Фиксация результатов вы

поления правил

и изменений

в рабочей

памяти,

а такж

е текущего шага поиска

9. Правило

выполнилось

10. П

ереход

на

шаг

111

. Завершение

работы

Агент

Диагностика

ситуации

Поиск

правил

57

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

Формулы, содержащиеся в условиях «если» и «то» правил агента пе‑реходят в описание метода соответствующего класса. На рис. 2.21 пред‑ставлена диаграмма поиска решения ИА проектирования ИС при кон‑вертации агента на продукциях. Отметим следующее:üресурсы, средства и заявки представляют собой рабочую па‑

мять;üесли на шаге 2 ни одна ситуация не диагностирована, то проис‑

ходит завершение работы.База знаний ИА проектирования ИС представляет собой описание

объектов МППР и ИС.На основании данных из DFD‑диаграммы создаются диаграммы

прецедентов. Каждая внешняя сущность преобразуется в актера соот‑ветствующей диаграммы прецедентов, а связанные с ней функции — в прецеденты.

Атрибуты классов, соответствующих внешним сущностям, позво‑ляют определить структуру таблиц ER‑диаграммы.

4. На четвертом этапе система дорабатывается разработчиками, строится диаграмма последовательности и моделируется пользова‑тельский интерфейс.

5. Для решения вопроса о размещении экземпляров концептов пред‑метной области по базам знаний агентов рассмотрим стандартную за‑дачу размещения с дискретным пространством решений, многократ‑но описанную в литературе.

Найти min z = i

m

j

n

ij ijc x= =ее

1 1

при ограничениях j

n

ij ija x=е

1

≥ 1, i = 1, …, m,

xij = (0,1), i = 1, …, m; j = 1, …, n,где m — количество экземпляров концептов предметной области; n — количество агентов; cij — коэффициент, показывающий величину за‑трат на размещение i‑го экземпляра концепта у j‑го агента; xij — коэф‑фициент, показывающий принадлежность концепта агенту:

x

i

jij =1, если �й экземпляр концепта

расположен у �го агеента,

0, иначе;

м

нп

оп

aij — коэффициент, определяющий потребность j‑го агента в i‑м кон‑цепте:

58

a

i

jij =1, если �й экземпляр концепта

нужен �му агенту,

0, иначе.

м

нп

оп

Таким образом, необходимо размесить экземпляры концептов по базам знаний агентов с минимальными затратами. Коэффициен‑ты cij определяются экспертами и позволяют линейно упорядочить агентов по стоимости размещения экземпляров концептов с учетом стоимости разработки распределенной ИС и ее эксплуатации. В ра‑боте данная задача не рассматривается.

Постановка, приведенная для задачи размещения концептов по ба‑зам знаний агентов, имеет свою особенность. В имитационной моде‑ли БП имеется информация о том, какому агенту какие экземпляры концептов необходимы. Данная информация используется в ограни‑чении задачи. По сути, известны допустимые варианты размещения концептов, среди которых нужно выбрать минимальный по затратам. Если потребности агентов в концептах достаточно обособлены друг от друга, то число возможных вариантов решения существенно со‑кращается по сравнению с полным перебором возможных вариантов.

Поскольку рассматриваемая задача решается в рамках автоматиза‑ции бизнес‑процессов, то в сравнении с классической задачей необ‑ходимо учитывать, что действия агентов являются составной частью автоматизируемого бизнес‑процесса и должны укладываться в опре‑деленные временные рамки max

БПT — максимальное время выполнения бизнес‑процесса. Следовательно, к ограничениям необходимо доба‑вить ограничение на время выполнения бизнес‑процесса (TБП), кото‑рое в общем случае будет иметь вид

TБП ≤ maxБПT .

Рассмотрим решение этой задачи для случая разработки системы ве‑дения реестров. Пусть необходимо разместить 5 (пять) реестров между 3 (тремя) агентами. Законодательно существует ограничение на выпол‑нение операции — 3 дня. В случае нарушения сроков могут быть предъ‑явлены существенные штрафы. Особенность данной системы состо‑ит в том, что не все агенты равноправны. Один из них, центральный офис, должен хранить у себя все 5 реестров, а остальным двум агентам нужен доступ только к тем реестрам, с которыми они работают. Экс‑пертные оценки затрат на размещение концептов предметной обла‑сти по базам знаний приведены ниже.

59

Экспертные оценки затрат на размещение

Концепты Агенты1 2 3

1 2 1 12 2 1 13 2 1 14 2 1 15 2 1 1

Постановка задачи:

min z = i j

n

ij ijc x= =ее

1

5

1

при ограниченииa11 + a21 + a31 + a41 + a51 ≥ 1,a12 + a22 ≥ 1,a23 + a33 + a43 ≥ 1,xj = (0,1), j = 1, …, 5,TБП ≤ 3.Для наглядности представим ограничения в табличной форме:

на пересечении i‑й строки и j‑го столбца стоит 1, если aij = 1.

Представление значений aij в виде таблицы

Агенты Концепты1 2 3 4 5

1 1 1 1 1 12 1 1 0 0 03 0 1 1 1 0

Рассмотрим возможные варианты решений.1-й вариант. Размещение всех экземпляров концептов в централь‑

ном офисе. В таблице представлены значения xij и целевой функции z для 1‑го варианта.

решение для 1-го варианта

Агенты Концептыz1 2 3 4 5

1 1 1 1 1 1102 0 0 0 0 0

3 0 0 0 0 0

60

Все остальные варианты размещения приводят к дублированию концептов предметной области, поскольку по условию у центрально‑го офиса обязательно должны быть все реестры. Для примера рассмо‑трим несколько вариантов размещения с дублированием.

2-й вариант. В таблице представлены значения xij и целевой функ‑ции z для 2‑го варианта.



1 1 1 1 1 1142 1 1 0 0 0

3 0 0 1 1 0




1 1 1 1 1 1142 1 0 0 0 0

3 0 1 1 1 0




1 1 1 1 1 1122 1 1 0 0 0

3 0 0 0 0 0

Современный уровень развития информационных технологий по‑зволяет реализовать такую информационную систему с соблюдением временных ограничений на БП.

Поскольку специфика БП такова, что длительные простои в работе ИС могут привести к существенным штрафам, то необходимо оценить уровень надежности системы. Непосредственный расчет вероятностей

61

отказов и сбоев в сложной и многокомпонентной распределенной си‑стеме не представляется возможным.

Эксплуатационная надежность серверов и аппаратуры ИС оцени‑вается обычно суммарными временами простоя в течение календар‑ного года. Эти данные фиксируются в логах и могут быть легко про‑анализированы.

Для повышения надежности системы целесообразно использовать резервирование (резервирование замещением с ненагруженным резер‑вом). Тогда в случае отказа основной системы подключается резервная, значительно более дешевая в эксплуатации и соответственно менее на‑дежная. Очевидно, что система с ненагруженным резервом и надеж‑ным переключением дает повышение общей надежности на порядок против отсутствия резервирования.

На рис. 2.22 представлена схема БП в том случае, когда БЗ распо‑ложена в центре. В этом случае

TБП = t_обработкиА1 + t_обработкиЦентр + t_передачиЦентр‑А1,

где t_обработкиА1 — время работы агента1, включая человеко‑машин‑ное участие; t_обработкиЦентр — время работы Центра, включая чело‑веко‑машинное участие; t_передачиЦентр‑А1 — время передачи резуль‑татов работы из Центра агенту1.

Агент 1 Центр

1

3 2

Рис. 2.22. Схема БП в случае расположения БЗ в Центре

Рассмотрим теперь возможные варианты резервирования системы.1-й вариант. Размещение концептов, необходимых для работы аген‑

та у него (рис. 2.23). В этом случае

TБП = t_обработкиА1 + t_передачиА1‑Центр + + t_обработкиЦентр + t_передачиЦентр‑А1,

где t_обработкиА1 — время работы агента1, включая человеко‑машин‑ное участие; t_передачиА1‑Центр — время передачи результатов работы из агента1 в Центр; t_обработкиЦентр — время работы Центра, вклю‑чая человеко‑машинное участие; t_передачиЦентр‑А1 — время передачи результатов работы из Центра агенту1.

62


1

434

Рис. 2.23. Схема БП в случае размещения БЗ в Центре и дублирования концептов у агентов

При отсутствии 2–3 дня возможности обмена информацией между агентом и Центром возможно TБП > TБП

max. Следовательно, резервиро‑вание БЗ у агента может не решить проблемы.

2-й вариант. Размещение концептов, необходимых для работы аген‑та у него, и резервный способ передачи сообщений в Центр (рис. 2.24).


1

434

резерв

резерв

Рис. 2.24. Схема БП в случае распределенной ИС, дублирования концептов у агентов и резервного способа передачи сообщений в Центр

В этом случае при сбоях в обмене информацией между Центром и агентом1 используется резервный способ доставки информации:

TБП = t_обработкиА1 + t_передачиА1‑Центр + + t_обработкиЦентр + t_передачиЦентр‑А1,

где t_обработкиА1 — время работы агента1, включая человеко‑ машинное участие; t_передачи_резА1‑Центр — время передачи результа‑тов работы из агента1 в Центр резервным способом; t_обработкиЦентр — время работы Центра, включая человеко‑машинное участие; t_передачи_рез Центр‑А1 — время передачи результатов работы из Цен‑тра агенту1 резервным способом.

Следовательно, для рассматриваемой задачи необходимо резерви‑ровать базу знаний агента и разрабатывать резервный способ переда‑чи данных.

63

Анализ архитектурных решений человеко‑машинной распределен‑ной системы до начала процесса кодирования позволяет снизить риск отказа такой системы в процессе эксплуатации [20].

В табл. 2.3 приведено соответствие элементов МППР элементам ИС [19].

Таблица 2.3Соответствие элементов МППр элементам ИС

Эле‑менты МППР

Элементы DFD

Элементы UML диаграммы Элементы ИС

преце‑дентов

клас‑сов

последова‑тельности ПИ код уровень

БД

Ресурс

Поток данных,

хранили‑ще дан‑

ных

Нет КлассКласс, па‑раметр ме‑

тода

Поле вво‑да, таблица

Пере‑менная, файло‑

вая пере‑менная, таблица

Табли‑ца

Преоб‑разова‑

тельФункция Преце‑

дент

Метод клас‑

саМетод

Строка ввода, та‑

блицаФункция ХП

Агент Внешняя сущность Актер Класс Актер,

класс

Интер‑фейс про‑граммного

модуля

Код про‑грам‑много

модуля

Табли‑цы, ХП

Таким образом, предложенный метод позволяет преобразовать КМПО МППР в КМПО ИС.

Следует отметить, что на сегодняшний момент предлагаются ме‑тоды разработки ИС так или иначе затрагивающие анализ процессов ОТС. Кратко рассмотрим их.

Метод П. о. СкобелеваМетод П. О. Скобелева предназначен для создания МАС оператив‑

ной обработки информации для поддержки процессов принятия ре‑шений. В качестве модели ОТС предлагается модель сети потребно‑стей и возможностей (ПВ‑сеть) предприятия [17]. При этом каждое предприятие представляется в виде сети агентов потребностей и воз‑можностей. Метод решает задачу взаимодействия этих агентов в про‑цессе принятия решений.

Метод разработки П. О. Скобелева включает в себя следующие этапы: описание предметной области МАС; описание классов аген‑

64

тов и правил принятия решений; описание протоколов взаимодей‑ствия агентов; типов и структуры сообщений; программная реали‑зация агентов.

Данный метод реализован в виде набора компонентов для разработ‑ки мультиагентных систем — MagentaToolkit [14]. Настройка системы под конкретную предметную область обеспечивается с помощью ин‑струмента для создания онтологий. Инструментарий предназначен для разработки МАС, связанных с планированием и распределением ресурсов. Он не занимается вопросами анализа и реинжиниринга БП.

Метод о. В. Карсаева и В. И. городецкогоМетод О. В. Карсаева и В. И. Городецкого базируется на методо‑

логии Gaia и среде MASDK [6], поддерживающей ее использование. Он предназначен для разработки прикладных многоагентных систем.

Метод состоит из десяти этапов, выполняемых в определенной по‑следовательности [21]. Результаты каждого этапа определяют после‑довательность выполнения следующих этапов. Решения, описанные на одних этапах, являются исходными данными для выполнения по‑следующих этапов. Укрупненно метод может быть описан в виде пяти стадий.

Первая стадия «Проектирование прикладной МАС» включает в себя два этапа:üанализ предметной области;üописание онтологии предметной области.Результатом этапа анализа предметной области является задача

идентификации классов агентов и сопоставления им ролей. Распре‑деление ролей между классами агентов определяет, какие классы аген‑тов на дальнейших этапах разработки будут обеспечивать решение определенных задач.

Вторая стадия «Проектирование классов агентов» занимается опи‑санием трех компонент, образующих структуру агента:üмодель поведения агента;üмодели сервисов;üментальная модель.На этой стадии идет только описание агентов с помощью диаграмм

с использованием объектно‑ориентированного подхода.Написание программного кода происходит на третьей стадии. При

этом описываются сервисные функции. После этого происходит ав‑томатическая генерация программного кода классов агентов.

65

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

На последней стадии происходит развертывание агентов в сети.Таким образом, метод О. В. Карсаева и В. И. Городецкого не позво‑

ляет описать статические и динамические БП, а следовательно, не за‑нимается вопросами их анализа и реинжиниринга.

Метод А. н. ШвецоваПредложенный А. Н. Швецовым метод относится к разработке

корпоративных интеллектуальных систем поддержки принятия ре‑шений [23]. На первоначальном этапе большое внимание уделяется описанию структурного, логического и поведенческого аспектов функ‑ционирования ОТС. На этапе формализации строятся структурно‑ло‑гическая модель, база знаний, топологическая и объектная модели. Да‑лее разрабатывается прототип системы и ее промышленный вариант. В данном методе основной упор делается на извлечение и формали‑зацию знаний о предметной области.

Данный метод реализован в виде программного пакета DISIT (Distributed Intellectual System Integrated Toolkit). Он предназначен для разработки МАС, основан на следующих принципах:üописание модели предметной области с использованием фрейм‑

концептов;üописание поведения агентов в виде продукций.В данном инструментальном пакете последовательно выполняют‑

ся следующие этапы метода:üпредставление модели предметной области;üнаполнение модели логикой взаимоотношений фрейм‑концептов

и их атрибутов;üвыделение интеллектуальных агентов и определение их поведе‑

ния с учетом системных ограничений;üтрансляция полученной концептуальной модели предметной об‑

ласти в структурно‑логическую модель МАС;üразмещение интеллектуальных компонент и агентов в корпора‑

тивной сети.Таким образом, метод А. Н. Швецова не позволяет описать стати‑

ческие и динамические БП, а следовательно, не занимается вопроса‑ми их анализа и реинжиниринга.

66

Метод д. В. АлександроваАлександровым Д. В. предложен метод моделирования распределен‑

ных систем управления БП предприятия [10]. При анализе предметной области предлагается использовать структурно‑функциональный под‑ход. Имитационные модели разработаны на аппарате раскрашенных сетей Петри. По результатам имитационного моделирования предлага‑ются рекомендации по совершенствованию БП, а при необходимости проведение тактического реинжиниринга, заключающегося в добав‑лении (удалении) функций, сотрудников, в перераспределении функ‑ций между сотрудниками, переводе сотрудников из одного структур‑ного подразделения в другое и т. п. Затем идет реализация агентного приложения для автоматизации выполнения БП. Также метод пред‑полагает использование ИМ для мониторинга БП предприятия.

Для сравнительной оценки методов разработки информационных систем (табл. 2.4) предлагается следующий набор критериев:üмодель процессов организационно‑технической системы, кото‑

рая должна описывать статические и динамические бизнес‑про‑цессы, а также модель лица, принимающего решение;

üсредства анализа процессов, включающие в себя организацион‑ный реинжиниринг, анализ «узких мест»;

üвозможность использования данных из модели организацион‑но‑технической системы при разработке ИС;

üиспользование структурного и объектно‑ориентированного под‑ходов;

üрезультаты автоматизации (бизнес‑процессы, согласование ре‑шений, процесс принятия решений — использование МЛВ).

Таблица 2.4Сравнение методов разработки ИС


МетодыСкобе‑

леваГородецкого,

КарсаеваШве‑цова Александрова Новый

1. Модель процесса ОТС:

статический бизнес‑процесс

ПВ‑сети

Да

Нет

Нет

Нет

Нет

Раскрашенные сети Петри

Да

Модель МППР

Да

динамический биз‑нес‑ процесс

Нет Нет Нет Нет Да

модель ЛПР Да Да Да Нет Да

67


МетодыСкобе‑

леваГородецкого,

КарсаеваШве‑цова Александрова Новый

2. Средства анализа процессов:

реинжиниринг орга‑низационный

Нет Нет Нет Да Нет

анализ «узких мест» Нет Нет Нет Нет Да3. Разработка ИС:

на основе модели ОТС в части дина‑мических БП

Нет Нет Нет Нет Да

на основе модели ОТС в части ЛПР Да Да Да Нет Да

структурный подход Нет Нет Нет Да Да

ОО подход Да Да Да Нет Да4. Результаты автома‑тизации:

бизнес‑процессы Да Да Да Да Дасогласование реше‑ний Да Нет Да Нет Да

ППР — использова‑ние МЛВ Нет Нет Да Нет Да

Существующие методы не полностью решают задачу разработки ИС, затрагивающую анализ процессов ОТС. Они не учитывают дина‑мику БП, недостаточно уделяют внимание анализу «узких» мест, не ис‑пользуют информацию из модели процессов ОТС в части динамиче‑ских БП для разработки ИС. Предлагаемый метод решает эти задачи. Кроме того, метод уделяет внимание вопросу надежности человеко‑машинной распределенной системы в условиях ограничений по сро‑кам выполнения бизнес‑процессов.

Окончание табл. 2.4

68

2.6. Методика оценки эффективности работы метода разработки информационных систем

Оценим эффективность работы предложенного метода проектиро‑вания ПО. Одним из главных критериев оценки является время вы‑полнения проекта по созданию ПО — ТПО. Оно складывается из вре‑мени выполнения каждого этапа проекта и времени перехода между этапами. На практике на разных этапах разработки участвуют разные специалисты, поэтому требуется адаптация результатов предыдущего этапа для специалистов следующего этапа, поэтому и возникает вре‑мя перехода между ними:

ТПО = Тобсл + Тформ + Тмодел + Тпроект + Тразр + Тпереход,

где Тобсл — время проведения обследования (1‑й этап); Тформ — время формализации БП, т. е. время построения модели; Тмодел — время про‑ведения моделирования и реинжиниринга; Тпроект — время проектиро‑вания ПО; Тразр — время разработки ПО; Тпереход — суммарное время, затрачиваемое при переходе от одного этапа проекта к другому:

Т Т Т Тi jпереход переход

обсл формпереходформ модел

перехо ® ®= + +®дд

модел проектпереходпроект разр ® ®+ Т ,

где Т i jпереход® — время перехода между i‑м и j‑м этапами.

Время проведения обследования Тобсл и время перехода между 1‑м и 2‑м этапами Т переход

обсл форм® не зависит от того, использовался или нет предлагаемый метод.

В процессе разработки ИС строятся DFD‑диаграммы и диаграм‑мы языка UML. Следовательно, время проектирования складывает‑ся из двух составляющих:

Тпроект = ТDFD + ТUML+ Т DFD UMLпереход

® ,

где ТDFD — время построения всех DFD‑диаграмм; ТUML — время постро‑ения модели архитектуры ПО в виде UML‑диаграмм; Т DFD UML

переход® — вре‑

мя перехода от построения DFD‑диаграмм к UML‑диаграммам. (На практике связано с передачей знаний от аналитика БП к архитек‑тору ПО.) Время построения одной DFD‑диаграммы определяется ко‑личеством функциональных блоков и потоков данных. Следовательно,

69

ТDFD = ∑ (ntбл + mtпоток),

где n — количество функциональных блоков; tбл — время рисования одного блока; m — количество потоков данных; tпоток — время рисова‑ния одного потока.

В предложенном методе используют следующие три вида UML‑диаграмм: прецедентов, последовательности и классов. Значит,

ТUML = ТUC + ТInt + ТClass,

где ТUC — время построения всех диаграмм прецедентов; ТInt — время построения всех диаграмм последовательности; ТClass — время постро‑ения всех диаграмм классов.

Время построения одной диаграммы прецедентов, в общем слу‑чае, зависит от количества вариантов использования ПО. При ее ав‑томатической генерации на основе данных из DFD‑диаграммы эта зависимость незначительна по сравнению с ручным моделировани‑ем. Следовательно, при использовании предложенного метода время построения одной диаграммы прецедентов можно считать величиной постоянной (tUC), тогда ТUC = ∑tUC.

При использовании предлагаемого метода Т DFD UMLпереход

® будет суще‑ственно меньше за счет процесса автоматизации моделирования. При использовании метода снижается человеческий фактор потери части информации при переходе от одной модели к другой.

В описанном методе предлагается автоматически генерировать за‑готовки программных модулей, описывающих классы и формы ПИ. Следовательно, время, затраченное на переход от этапа проекти‑рования к этапу разработки ПО Т переход

проект разр® , сокращается по сравнению с другими методами.

Анализ предложенного метода показывает, что он позволяет умень‑шить следующие показатели: Т DFD UML

переход® , ТUC, Т переход

проект разр® .

Вывод по главе 2Во второй главе было проведено исследование предметной об‑

ласти МППР и описаны основные объекты КМПО МППР, а также предметной области ИС и построена КМПО ИС. Разработаны мо‑дель и метод в области создания ИС, которые отличаются от суще‑ствующих:

70

üметодикой системного анализа и моделью для формализации МППР, при этом учитывается наличие ЛПР, которые могут быть представлены в виде ИА;

üИМ для проверки модели «Как будет» на этапе реинжиниринга БП и оценки производительности ИС;

üинтеллектуальностью разработки ИС, включающей функцио‑нальный и объектно‑ориентированный анализ, моделирование ПИ, формирование исполняемого кода ИС.

Анализ надежности архитектурных решений при автоматизации процессов ОТС в условиях ограничений по срокам выполнения БП особенно эффективен для географически распределенной системы.

Предложенный метод ППР разработки ИС мультиагентных про‑цессов преобразования ресурсов позволяет уменьшить время, затра‑чиваемое на переход от функционального моделирования к объек‑тно‑ориентированному, а также от проектирования к разработке ПО.

71

3. CASE-средство BPsim.SD

3.1. Функциональные возможности пакета BPsim.SD

B Psim.SD представляет собой CASE‑средство автоматизации процесса проектирования DFD, IDEF0 диаграмм, UML‑диаграмм прецедентов, последовательности и классов, а так‑

же пользовательского интерфейса разрабатываемой информацион‑ной системы [19].

В рамках процесса моделирования архитектуры информационной системы BPsim.SD предлагает пользователю следующие возможности:üописание бизнес‑процессов, автоматизируемых разрабатываемой

ИС, с помощью диаграмм стандарта DFD. Диаграммы DFD де‑композируемы до любого уровня детализации. Автоматическое создание DFD‑диаграмм на основе модели мультиагентных про‑цессов преобразования ресурсов;

üописание функций, выполняемых пользователями системы в рамках автоматизируемых процессов, с помощью диаграмм прецедентов. Допускается построение диаграмм прецедентов с «нуля», т. е. создание новой диаграммы, или с помощью авто‑матизированного конвертирования из диаграммы DFD, в ко‑торой выбранным из списка существующих на диаграмме DFD внешним сущностям ставятся в соответствие актеры, а функци‑ям — прецеденты. Полученные конвертированием диаграммы редактируемы. Допускается строить неограниченное количество диаграмм прецедентов для каждой диаграммы DFD;

üдля каждого прецедента, выполняемого пользователем, может быть дано описание последовательности элементарных опера‑ций в системе (для этого предназначены диаграммы последова‑

72

тельности, которые могут быть созданы для любой функции ди‑аграммы прецедентов), частичная автоматизация этого процесса (разработчику предлагается перенести на диаграмму последова‑тельности выбранных актеров с диаграммы прецедентов). Для каждого объекта диаграммы последовательности определяется один из четырех типов по принадлежности к определенному па‑кету (границы, актеры, управление, бизнес‑объекты);

üсоздание диаграммы классов и сопоставление объектов диа‑граммы последовательности (кроме границ) с классами этой диаграммы;

üпроектирование визуальных форм моделируемого программно‑го обеспечения (границ диаграммы последовательности): разме‑щение на форме компонентов, привязка к компонентам методов и свойств классов и сохранение моделей форм в форматах .dfm и .pas, передача в дальнейшем данных модели программисту для импорта в среду Delphi и дальнейшей проработки алгоритмов;

üформирование отчетов о созданном проекте с изображениями спроектированных диаграмм и форм, вывод отчетов на печать и экспорт в текстовый редактор Word;

üсохранение проекта на сервере и загрузка с сервера MS SQL Server для редактирования.

3.2. Описание CASE-средства BPsim.SD

3.2.1. Общая структура CASE-средства BPsim.SD

CASE‑средство BPsim.SD (SD) состоит из трех подсистем: создание DFD‑диаграмм, UML‑диаграмм, моделирование пользовательско‑го интерфейса. Структура BPsim.SD представлена на рис. 3.1. Модель МППР строится в BPsim.MAS — мультиагентной системе динамиче‑ского моделирования ситуаций. Для преобразования модели мульти‑агентных процессов преобразования ресурсов в модель информаци‑онной системы используется диалоговая программа‑помощник.

Более подробно подсистемы рассмотрены в следующих подглавах.После ввода идентификационных данных пользователя и установ‑

ления соединения с сервером открывается главная форма системы (рис. 3.2).

73

BPsim.SD

Подсистема разработки

DFD-диаграмм


UML- диаграмм


UML- диаграмм прецедентов


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


UML- диаграмм классов

Подсистема моделирования

ПИ

BPsim.MAS

BPsim.MSSДиалоговая программа-помощник

Рис. 3.1. Структура CASE‑средства BPsim.SD

Рис. 3.2. Главная форма BPsim.SD

Главная форма состоит из следующих частей:üзаголовок, отражающий информацию о текущем проекте (назва‑

ние, авторы, дата и время создания);

74

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

üпанели инструментов, дублирующие основные команды главно‑го меню (на них располагаются инструменты создания и редак‑тирования диаграмм классов);

üобласть создания диаграммы, в которой происходит непосред‑ственное создание и редактирование диаграмм классов;

üстрока состояния, отображающая информацию о текущем состо‑янии подключения к выбранному серверу БД.

3.2.2. Создание диаграмм

После создания нового проекта в области панели инструментов ав‑томатически активизируются кнопки с объектами диаграммы DFD (рис. 3.3).

Поток данныхВнешняя сущностьХранилище данныхФункцияУказатель мыши

Рис. 3.3. Панель инструментов диаграммы DFD

Для размещения объекта в области диаграммы необходимо щел‑кнуть на соответствующей кнопке панели инструментов и в том ме‑сте диаграммы, куда требуется поместить объект.

Для соединения объектов потоками данных необходимо выбрать со‑ответствующий объект в панели инструментов и навести курсор мыши на соединяемые объекты.

В контекстном меню Тип потока данных можно выбрать один из 5 типов (рис. 3.4).

Рис. 3.4. Типы потоков данных

75

Все размещенные на диаграмме DFD функции заносятся в дерево проекта. Переименование объектов вызывается из контекстного меню объекта или соответствующего элемента дерева. Для потоков данных, хранилищ данных и внешних сущностей открывается дополнительное окно (рис. 3.5), позволяющее выбрать имя из списка уже существую‑щих в данном проекте.

Рис. 3.5. Форма Переименование потока данных

Для создания декомпозиции диаграммы необходимо в контекстном меню декомпозируемой функции выбрать пункт Декомпозиция. За‑тем в открывшемся окне необходимо указать первоначальное количе‑ство элементов (функций) в декомпозиции (рис. 3.6).

Рис. 3.6. Форма Создание декомпозиции

После нажатия на кнопку ОК автоматически создается новая ди‑аграмма, содержащая указанное количество функций. В дерево про‑ектов эти функции помещаются в качестве потомков элемента — де‑композируемой функции.

76

Создать диаграмму прецедентов можно с помощью конвертирова‑ния из диаграммы DFD в соответствии с разработанной методикой. При этом функции диаграммы DFD заменяются на функции диаграм‑мы прецедентов, а внешние сущности — на актеров.

Для запуска процесса конвертирования необходимо нажать кноп‑ку Конвертировать на панели инструментов (рис. 3.7).

Рис. 3.7. Стандартная панель инструментов

В появившемся окне (рис. 3.8) выбираются существующие на дан‑ной диаграмме функции и внешние сущности, которые необходимо отобразить на диаграмме прецедентов. При необходимости сохранить связи между этими объектами устанавливается соответствующий флаг внизу окна.

Рис. 3.8. Форма Конвертирование в диаграмму прецедентов

В результате конвертирования в дереве проектов появляется соот‑ветствующий узел со списком существующих на диаграмме прецеден‑тов функций.

77

Разрешается создавать новую или редактировать существующую диаграмму с помощью панели инструментов диаграммы прецеден‑тов (рис. 3.9).

Рис. 3.9. Панель инструментов диаграммы прецедентов

Редактировать диаграмму прецедентов нужно аналогично редакти‑рованию диаграмм DFD.

Диаграмма последовательности может быть создана для любой функции диаграммы прецедентов из ее контекстного меню. В открыв‑шемся окне (рис. 3.10) необходимо из списка выбрать существующих актеров, которые будут помещены на диаграмму последовательности.

Рис. 3.10. Форма Создание диаграммы последовательности

После создания диаграммы соответствующий узел добавляется в де‑рево проектов и активизируется панель инструментов для редактиро‑вания данной диаграммы (рис. 3.11).

78

Рис. 3.11. Панель инструментов диаграммы последовательности

Редактирование диаграммы последовательности осуществляется аналогично редактированию диаграмм DFD.

Сохранение проекта на сервере осуществляется через пункт глав‑ного меню Сохранить проект или с помощью кнопки на стандарт‑ной панели инструментов (см. рис. 3.2).

Для перехода на диаграмму классов необходимо выбрать соответ‑ствующий пункт главного меню или воспользоваться панелью инстру‑ментов. Редактирование диаграммы классов выполняется с помощью панели инструментов, приведенной на рис. 3.12.

Рис. 3.12. Панель инструментов диаграммы классов

Для размещения объекта в области диаграммы необходимо щел‑кнуть на соответствующей кнопке панели инструментов и в том ме‑сте диаграммы, куда требуется поместить объект.

Двойной щелчок на созданном классе или выбор пункта Свойства контекстного меню открывают окно для ввода информации об этом классе (рис. 3.13). Окно содержит 3 вкладки:üвкладка Общие (задаются имя и описание класса);üвкладка Свойства (задаются свойства класса с указанием имени,

типа данных и вида доступа);üвкладка Методы (задаются методы класса с указанием имени,

типа возвращаемого значения, вида доступа и входных параме‑тров).

79

а б в

Рис. 3.13. Форма Параметры класса: а — Общие; б — Свойства; в — Методы

3.2.3. Подсистема моделирования пользовательского интерфейса

Моделирование пользовательского интерфейса возможно при на‑личии в проекте диаграммы последовательностей и созданного на ней объекта‑границы. В контекстном меню объекта‑границы выбирается пункт Форма. У каждой границы может быть только одна форма, по‑этому по нажатии на соответствующий пункт меню откроется или но‑вая форма, или уже созданная.

Менеджер пользовательских форм вызывается из контекстного меню объекта Границы диаграммы последовательности (рис. 3.14).

Рис. 3.14. Контекстное меню объекта Границы диаграммы последовательности

Графический интерфейс менеджера форм приведен на рис. 3.15.

80

Рис. 3.15. Форма Менеджер пользовательских форм и прототип формы

Менеджер форм содержит следующие элементы:üдерево входных и выходных классов проекта со списками доступ‑

ных свойств и методов этих классов;üпанель визуальных компонентов, размещаемых пользователем

на проектируемой форме;üпанель свойств компонентов, помещенных на форму.Если ни один компонент не выбран, то на панели опций выводят‑

ся свойства проектируемой формы.Для спроектированной формы файлы *.pas и *.dfm формируются

с помощью кнопки Сохранить форму на диск и сохраняются на ком‑пьютере в указанном месте. В дальнейшем эти файлы могут быть от‑крыты в Delphi для дальнейшей доработки.

Пример спроектированной формы Расписание экзаменов при‑веден на рис. 3.16.

81

Рис. 3.16. Спроектированная в BPsim.SD форма составления расписания экзаменов

3.3. Описание агента интеграции BPsim.MAS и BPsim.SD

Агент интеграции BPsim.MAS и BPsim.SD доступен пользователям системы BPSim.MAS (меню Общие/Агенты). На начальном этапе появляется форма, позволяющая выбрать необходимую модель пред‑метной области (рис. 3.17).

Рис. 3.17. Форма первого этапа конвертации моделей

82

После этого предлагается отобрать операции модели (рис. 3.18).

Рис. 3.18. Форма второго этапа конвертации моделей

На следующем этапе агент последовательно конвертирует элементы модели МППР в соответствующие элементы модели ИС (см. табл. 2.3).

3.4. Методика использования пакета BPsim

В процессе бизнес‑моделирования и проектирования ПО предмет‑ной области МППР используются следующие пакеты программ (URL: http//www.bpsim.ru):üBPsim.MAS (мультиагентная система динамического моделиро‑

вания ситуаций);üBPsim.MSS (интеллектуальная система технико‑экономическо‑

го проектирования);üBPsim.SD (CASE‑средство).Методика бизнес‑моделирования и проектирования ПО предмет‑

ной области МППР в стандарте IDEF0 показана на рис. 3.19.По результатам обследования БП аналитик с помощью BPsim.MAS

создает модель БП предприятия «Как было», проводит моделирование и, если это необходимо, строит модель «Как будет». Результаты моделирова‑ния позволяют обосновать предложенные изменения в модели бизнеса. Результирующая модель «Как будет» конвертируется в DFD‑диаграммы пакета BPsim.SD, учитываются только те процессы, которые будут ав‑томатизированы. Этот пакет используется для проектирования ИС.

83

Рис.

3.1

9. М

етод

ика б

изне

с‑мо

дели

рова

ния

и пр

оект

иров

ания

ПО

84

На основе данных DFD‑диаграмм могут быть получены UML‑диаграммы прецедентов, а также шаблоны классов и диаграмм после‑довательности, заготовка структуры БД. Затем архитектор ПО строит диаграммы последовательностей и классов, а разработчик ПИ — ша‑блоны форм. Данные заготовки будущей ИС могут быть преобразо‑ваны в программный код, который дорабатывается программистами.

Программная реализация интеграции BPsim.MAS и BPsim.SD воз‑можна благодаря тому, что данные этих двух продуктов хранятся в еди‑ной БД. Конвертацию информации из одной системы в другую осу‑ществляют диалоговые программные агенты‑помощники.

Агенты‑помощники, входящие в состав пакета BPsim, выполняют следующие функции:üосуществляют передачу информации между программными про‑

дуктами в рамках комплексного решения единой задачи;üоблегчают работу непрограммирующего пользователя в процес‑

се ознакомления с продуктами семейства BPsim;üреализуют функцию проверки на этапах создания модели МППР,

проектирования КМПО ИС.DFD‑диаграмма, отражающая последовательность действий аген‑

та‑помощника при конвертации модели МППР в модель ИС, пред‑ставлена на рис. 3.20.

Преимущество метода интеграции программных продуктов при по‑мощи агентов‑помощников заключается в возможности для непро‑граммирующего пользователя комплексно решать задачи моде‑лирования бизнеса и разработки ИС. Кроме того, интеграция дает возможность существенно упростить и ускорить работу аналитиков и проектировщиков.

Применение метода и BPsim.SD для проектирования различных ИС представлено в [3, 15, 19].

Данная методика и продукты линейки BPsim позволяют комплек‑сно решать задачи моделирования бизнеса, технико‑экономического проектирования, моделирования архитектуры ИС и разработки про‑тотипа приложения, что в итоге позволяет существенно упростить и ускорить работу аналитиков, а также повысить качество готового ПО за счет автоматизации некоторых этапов и сокращения влияния человеческого фактора.

85

Рис.

3.2

0. D

FD‑д

иагр

амма

пре

обра

зова

ния

моде

ли М

ПП

Р в

моде

ль И

С

Табл

ица

моде

лей

Код

мод

ели

Шаг

0. В

ыбо

рмо

дели

Шаг

1. П

реоб

‑ра

зова

ние о

пе‑

раци

йШ

аг 2

. Пре

обра

‑зо

вани

е рес

урсо

в

Шаг

3. С

озда

ние

хран

илищ

дан

‑ны

х

Шаг

4. П

реоб

ра‑

зова

ние а

гент

ов Шаг

5. П

о‑ст

роен

ие E

R‑

диаг

рамм

ы

Пол

ьзо‑

вате

ль

Код

мод

ели

Код

мод

ели

Код

мод

ели

Код

мод

ели

Мод

ель

ИС

Табл

ица

опер

аций

Табл

ица

ресу

рсов

Табл

ица

аген

тов

86

Выводы по главе 3Решение задачи интеграции имитационного, экспертного, ситуа‑

ционного и мультиагентного моделирования, а также функциональ‑ного и объектно‑ориентированного подхода позволило реализовать СППР в области разработки ИС BPsim.SD.

В третьей главе дано подробное описание возможностей BPsim.SD: функциональная и объектно‑ориентированная разработка информа‑ционных систем, моделирование интерфейса пользователя. Приво‑дится методика использования пакета BPsim и описания агента‑по‑мощника для преобразования модели МППР в модель ИС.

87

Заключение

1. Определен перечень характеристик и проведен сравнительный анализ наиболее распространенных CASE‑средств: ARIS Toolset, Power Designer, Borland Together Designer, продукты IBM Rational, CA Erwin Modeling Suite, BizAgi и Elma. Обследованные системы имеют ряд недо‑статков: отсутствие интеллектуальности процесса проектирования — не решена задача автоматического перехода к проектированию одних диаграмм на основе других; не позволяют на основе динамической мо‑дели процессов организационно‑технической системы (МППР) по‑строить модель информационной системы.

2. Разработаны требования к моделям и методу поддержки при‑нятия решений: динамическое моделирование МППР, содержащих модели интеллектуальных агентов, представляющих лиц, принима‑ющих решение; имитационное моделирование для проверки модели «Как будет» на этапе реинжиниринга бизнес‑процессов; интеллекту‑альное проектирование информационных систем, включающее функ‑циональный и объектно‑ориентированный анализ, проектирование интерфейса пользователя, формирование исполняемого кода инфор‑мационной системы и структуры базы данных.

3. Решена задача системного анализа предметной области органи‑зационно‑технических систем: выявлены три характерных класса про‑цессов — бизнес‑процессы, процессы согласования и принятия ре‑шений. Определены разрывы в модели знаний, возникающие между пользователем, аналитиком и разработчиком, приводящие к ошибкам при автоматизации организационно‑технических систем.

4. В результате проведения анализа существующих моделей дина‑мических бизнес‑процессов и процессов принятия решений (сети Петри, расширенные сети Петри, системы массового обслуживания, мультиагентные процессы преобразования ресурсов) и знаний (про‑

88

дукционная модель, семантическая сеть, фреймовая модель, фрей‑мово‑семантическая модель) были выбраны следующие модели. Для решения поставленной задачи в качестве модели организационно‑тех‑нической системы предложено использовать динамическую модель мультиагентных процессов преобразования ресурсов К. А. Аксенова, поскольку она наиболее полно отвечает следующим требованиям: учет временных характеристик, возможность учета различных типов ресур‑сов, моделирование конфликтов на общих средствах, наличие модели интеллектуального агента (лица принимающего решение). Выбранная фреймово‑семантическая модель представления знаний А. Н. Швецо‑ва имеет следующие преимущества: эффективно реализует иерархи‑ческое представление данных, хорошо сочетается с объектно‑ориен‑тированным подходом в программировании.

5. Разработан метод поддержки принятия решений при проектиро‑вании информационных систем предметной области ОТС, который отличается от существующих:üприменением на этапе обследования предметной области муль‑

тиагентного имитационного моделирования для анализа процес‑сов организационно‑технических систем;

üрассмотрением разрабатываемой распределенной информаци‑онной системы в виде мультиагентной системы;

üприменением фреймово‑семантической модели представления знаний на основе фрейм‑концептов и концептуальных графов в целях формализации знаний о предметных областях разработ‑ки информационных систем и ОТС;

üинтеграцией структурного и объектно‑ориентированного под‑ходов, мультиагентного подхода для решения задачи поддерж‑ки принятия решений при автоматизации процессов организа‑ционно‑технических систем;

üпреобразованием мультиагентной имитационной модели ОТС в основу модели архитектуры информационной системы и ее элементов, представлением архитектуры в виде структурных диа‑грамм и диаграмм объектно‑ориентированного подхода для обе‑спечения эффективного взаимодействия между специалистами‑предметниками и ИТ‑специалистами;

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

89

6. На основе моделей и метода поддержки принятия решений в об‑ласти создания информационных систем разработаны:üинтерфейсы системы поддержки принятия решений, ориенти‑

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

обеспечение проблемно‑ориентированного пакета BPsim.SD;üтехнология работы с BPsim.SD.7. Разработанная система поддержки принятия решений BPsim.SD

отличается от существующих:üинтеграцией структурного и объектно‑ориентированного подхо‑

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

üвозможностью конвертировать структурные диаграммы в диа‑граммы объектно‑ориентированного подхода;

üвозможностью создания модели поведения программного агента;üвозможностью создания прототипа форм пользовательского ин‑

терфейса непрограммирующим пользователем.

90

Библиографический список

1. Colin J. Neill. Laplante Requirements Engineering: The State of the Practice / Colin J. Neill and Phillip A. // IEEE Software. 2003. Novem‑ber/December. P. 40–45.

2. Minsky M. A framework for Representing Knowledge in The Psychol‑ogy of Computer Vision / M. Minsky; P. H. Winston (ed.). [S. l.]: Mc‑Graw‑Hill, 1975. P.76.

3. Multi‑agent approach for the metallurgical enterprise information sys‑tem development / Aksyonov K. A. [et al.]//24th Int. Crimean Confer‑ence “Microwave & Telecommunication Technology” (CriMiCo’2014). 7–13 September, Sevastopol. Sevastopol, 2014. Vol. 1. P.437–438.

4. Sowa J. F. Knowledge Representation: Logical, Philosophical and Com‑putational Foundations / Sowa J. F. Pacific Grove, CA: Brooks / Cole Publishing Co., 2000. 594 p.

5. Stephen A. White. BPMN Modeling and Reference Guide / Ste‑phen A. White, Derek Miers. [S. l.] : Future Strategies Inc., 2008. 226 p.

6. Support for Analysis, Design and Implementation Stages with MASDK / Gorodetsky V. [et al.] // LNCS. 2009. 5386. P. 272–287.

7. UML — The Unified Modeling Language [Электронный ресурс] // Unified Modeling Language : [сайт]. URL: http://www.uml.org (дата обращения: 12.05.2016).

8. Wooldridge M. Intelligent Agents: Theory and Practice/Wooldridge M., Jennings N. // The Knowledge Engineering Review. 1995. Vol. 10, № 2. P. 115–152.

9. Аксенов К. А. Теория и практика средств поддержки принятия ре‑шений : монография / К. А. Аксенов. Saarbrucken (Germany): LAP LAMBERT Academic Publishing GmbH & Co. KG, 2011. 341 с.

10. Александров Д. В. Консалтинг при информатизации организаций : учеб. пособие / Д. В. Александров, Д. Н. Фадин. Владимир : Изд‑во Владим. гос. ун‑та, 2006. 72 с.

91

11. Бек Кент. Экстремальное программирование / Бек Кент. СПб. : Питер, 2002. 224 с.

12. Вендров А. М. Проектирование программного обеспечения эконо‑мических информационных систем / А. М. Вендров. М. : Финан‑сы и статистика, 2005. 544 с.

13. Верников Геннадий. Стандарт онтологического исследова‑ния IDEF5 [Электронный ресурс] / Г. Верников.//Верников.ру: [сайт]. URL: http://vernikov.ru/krisis/item/31— idef5.html (дата об‑ращения: 15.05.2016).

14. Инструментальные средства для разработки мультиагентных си‑стем промышленного масштаба [Электронный ресурс] / Скобе‑лев П. О. [и др.] // СамНЦ РАН : [сайт]. URL: http://www.ssc.smr.ru/media/ipuss_conf/06/5_01.pdf (дата обращения: 15.06.2016).

15. Разработка автоматизированной системы анализа, моделирования и принятия решений для металлургического предприятия на ос‑нове мультиагентного подхода / Аксенов К. А. [и др.] // Автома‑тизация в промышленности. 2014. № 7. С. 49–53.

16. Разработка методов, моделей и алгоритмов проектирования инфор‑мационных систем для предметной области процессов преобразо‑вания ресурсов: отчет по проекту № 01.2.007 08048‑/ООО «НПП «Системы автоматизации поддержки бизнеса»; Рук. К. А. Аксенов; П. П. Березовский, 2007. 55 с. Исполн.: И. А. Спицина, Е. Ф. Смо‑лий [и др.].

17. Скобелев О. П. Открытые мультиагентные системы для оператив‑ной обработки информации в процессах принятия решений : ав‑тореф. дис. … д‑р техн. наук / Скобелев О. П. Самара, 2003. 35 с.

18. Смирнова Г. Н. Проектирование экономических информацион‑ных систем / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. М. : Финансы и статистика, 2001. 510 с.

19. Спицина И. А. Метод поддержки принятия решений при разработ‑ке информационных систем на основе мультиагентного подхода : дис. … канд. техн. наук: 05.13.10 / И. А. Спицина. Новосибирск : ФГОБУ ВПО СибГУТИ, 2015. 166 с.

20. Спицина И. А. Численный анализ задержек в синхронной ин‑формационной системе [Электронный ресурс] / И. А. Спицина, А. Л. Крохин // Междунар. научн.‑техн. интернет‑конф. «Инфор‑мационные системы и технологии» (2013 год). URL: http://isit‑conf.gu‑unpk.ru/conferences/2/materials/index/415 (дата обраще‑ния: 10.06.2015).

92

21. Технология разработки прикладных многоагентных систем в ин‑струментальной среде MASDK [Электронный ресурс] / Городец‑кий В. И. [и др.] // СПИИРАН. 2006. Т. 1, вып. 3. URL: http://www.proceedings.spiiras.nw.ru (дата обращения: 15.06.2016).

22. Хаммер М. Реинжиниринг корпорации (манифест революции в бизнесе) / М. Хаммер, Дж. Чампи. СПб. : С.‑Петербург. ун‑т, 1997. 332 c.

23. Швецов А. Н. Модели и методы построения корпоративных интел‑лектуальных систем поддержки принятия решений : дис. … д‑ра техн. наук: 05.13.01 / А. Н. Швецов. СПб., 2004. 461 с.

И. А. СПИЦИНАК. А. АКСЕНОВ

МУЛЬТИАГЕНТНЫЙ МЕТОД АНАЛИЗА И СИНТЕЗА ИНФОРМАЦИОННЫХ СИСТЕМ


9 7 8 5 7 9 9 6 2 0 3 8 7

I SBN 579962038 - 0

Documents

И. А. СПИЦИНА К. А. АКСЕНОВelar.urfu.ru/bitstream/10995/48968/1/978-5-7996-2038-7... · 2019-06-24 · И. А. СПИЦИНА К. А. АКСЕНОВ МУЛЬТИАГЕНТНЫЙ