CC BY
31
Системный анализ и управление
УДК 519.816:519.876.5
К.А. Аксенов, И.И. Шолина, Е.М. Сафрыгина
РАЗРАБОТКА И ПРИМЕНЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ СИСТЕМЫ МОДЕЛИРОВАНИЯ И ПРИНЯТИЯ РЕШЕНИЙ ДЛЯ МУЛЬТИАГЕНТНЫХ ПРОЦЕССОВ ПРЕОБРАЗОВАНИЯ РЕСУРСОВ
Применение ситуационных моделей в управлении процессами способствует повышению эффективности и качества принимаемых решений, сокращению времени процесса принятия решений (ППР), более рациональному использованию имеющихся ресурсов. Создание систем динамического моделирования ситуаций (СДМС) — одно из перспективных направлений развития систем ППР (СППР). Сегодня наблюдается существенный интерес к области мультиагентных систем (MAC), специфика которых заключается в наличии сообществ взаимодействующих агентов, отождествляющихся с лицами, принимающими решения (ЛПР). Важной областью применения мультиагентных технологий является моделирование. Подходы к проектированию MAC разделяют на две группы: I) базирующиеся на объектно-ориентиро-ванных (ОО) методах (ООМ) и технологиях; 2) использующие традиционные методы инженерии знаний [1].
В методологиях первой группы разрабатываются расширения ООМ и технологий для проектирования MAC. Существует ряд CASE-средств, поддерживающих ООМ разработки информационных систем (ИС) (Paradigm Plus, Rational Rose). Средство имитационного моделирования (ИМ) MAC AnyLogic использует ОО-язык описания поведений агентов UML-RT. Вторая группа методологий строится на расширении традиционных методов инженерии знаний. Актуальна задача разработки СДМС на основе ОО-технологий.
Особенности мультиагентных процессов
преобразования ресурсов (МППР) в организационно-технических системах (ОТС)
Анализ различных процессов преобразования ресурсов (производственных, организационно-технических и бизнес-процес-сов (БП)) позволяет выделить следующие их особенности:
1. Объекты ОТС характеризуются сложностью структуры и алгоритмов поведения, мно-гопараметричностью, что, естественно, приводит к сложности их моделей; это требует при их разработке построения иерархических модульных конструкций, а также использования описания внутрисистемных процессов [2].
2. На самых нижних уровнях процесс может быть предстаален с точностью до элементарных операций преобразования ресурсов [3].
3. В ОТС оказывается довольно сложно оценить параметры потоков информации, установить определенные и нормированные структуры данных с целью принятия решений. Для систем такого типа характерно вероятностное поведение, вызываемое воздействием множества объективных и субъективных факторов, таких, как высокая изменчивость источников и адресатов информации, номенклатуры и форм представления документов; слабая формализованное^ маршрутов и методов обработки информации внутри организации; недостаток квалифицированных специалистов в области информационных технологий (ИТ). Отсюда вытекает потребность в интеллектуальной
системе ППР, которая бы взяла на себя все формализованные функции исполнителей и оказала существенную поддержку при решении трудноформализуемых задач. Организационные задачи но многих случаях не имеют точных алгоритмов решения, а разрешаются в рамках некоторых сценариев, которые в общих чертах хорошо известны исполнителям, но в каждой конкретной ситуации могут изменяться. Такие сценарии весьма трудно описать алгоритмическими моделями; более адекватными оказываются модели представления знаний, позволяющие менять правила поведения и осуществлять логические выводы на основании содержания базы знаний (БЗ) [2].
В следующем разделе описывается состояние СДМС МП ПР.
Состояние систем динамического моделирования ситуаций
Анализ состояния в области СДМС показывает, что сегодня не существует систем, ориентированных на процессы преобразования ресурсов. Ближайшими по
функциональности аналогами являются средства имитационного и экспертного моделирования: экспертная система (ЭС) реального времени G2; система мультиагент-ного имитационного моделирования (ИМ) AnyLogic; средство моделирования БП ARIS; система ИМ Arena; СДМС BPsim2 и система технико-экономического проектирования BPsim3. Был проведен сравнительный анализ данных систем (см. таблицу) на соответствие таким требованиям, как: I) проектирование концептуальной модели предметной области (КМПО); 2) описание знаний о предметной области и вывод на знаниях; 3) описание иерархических, динамических процессов преобразования ресурсов; 4) наличие языков описания ситуаций, команд; 5) построение мультиагентных моделей (наличие сообществ интеллектуальных агентов (ИА), обладающих моделью поведения и знаниями); 6) интеграция ИМ, ЭС и ситуационного управления (СУ); 7) интеграция с методикой сбалансированных показателей (Balanced ScoreCard (BSC)): 8) применение OOM; 9) поддержка русского языка.
Сравнительный анализ СДМС
Номер п/п Параметр ARIS С2 AnyLogic Arena Bpsim2/3
1 Проектирование КМПО Нет Нет Нет Нет +
2 Язык описания процессов преобразования ресурсов
2.1 Ресурсы, средства, преобразователи, иерархические БП + + + + +
2.2 Описание целей системы: в виде графа + + Нет Нет +
в виде BSC + Нет Нет Нет +
3 Язык описания команд Нет + Нет Нет +
4 11остросние модели MAC
4.1 Элемент АГЕНТ Нет Нет + Нет +
4.2 Модели поведения агентов Нет Нет + Нет +
4.3 Ваза знаний агента Нет Нет Нет Нет +
4.4 Язык обмена сообщениями Нет Нет Нет Нет +
5 ИМ + + + + +
6 Экспертное моделирование Нет + Нет Нет +
7 Ситуационный подход Нет + Нет Нет +
8 ОО подход
8.1 Использование языка UML + Нет Нет Нет +
8.2 ОО-программирование Нет + + Нет +
8.3 ОО-ИМ Нет + + Нет +
8.4 Связь КМПО и ОО-ИМ Нет Нет Нет Нет Нет
9 Стоимость 50 70 4,8 11 4
Анализ показал, что наибольшей функциональностью ОО СППР обладают продукты линейки BPsim. Функции проектирования КМ ПО и построения муль-тиагентных моделей, содержащих ИА, рассмотренные системы не поддерживают, за исключением систем BPsim2/3. Методику BSC поддерживают системы BPsim2 и ARIS, но ARIS не поддерживает интеграцию ИМ и BSC. К достоинствам пакетов AnyLogic и G2 можно отнести использование языков высокого уровня, благодаря чему пакеты могут предоставлять разработчику моделей серьезный уровень функциональности. Анализ применения ОО-технологий в СДМС показал следующие результаты: I) визуальный язык моделирования UML используется только в системах ARIS и BPsim3, в AnyLogic используются только диаграммы состояний;
2) ОО-программирование наиболее полно используется в системах G2 и AnyLogic;
3) переход от стадии системного анализа (СА, проектирования КМ ПО) к ОО ИМ ни одна из систем не поддерживает (данная функциональность позволила бы конечным пользователям создавать собственные предметные библиотеки, ориентированные на их задачи и специфику процессов). Таким образом, в качестве основы для создания полнофункционалыюй ОО СППР выбраны продукты линейки BPsim. В СДМС используются средства ИМ, ЭС и ситуационного моделирования (СМ) [3]. При решении задач моделирования, анализа и синтеза ОТС и БП применяются следующие методы: ИМ, ситуационного моделирования (СМ) и ЭС. Дня описания ОТС с точки зрения ППР динамической составляющей БП, ЭС, СМ и MAC может быть использована теория МППР [3]. Разработка СППР требует выбора или создания математического обеспечения: в следующих разделах решается задача построения архитектуры MAC МППР.
Модель мультиагентного процесса преобразования ресурсов
Динамическая модель процесса преобразования ресурсов [4| разработана, на основе следующих математических схем: се-
тей Петри, систем массового обслуживания, моделей системной динамики. Данная модель взята за основу и расширена И А [3]. Модель МППР [3] разработана на основе интеграции ИМ, ЭС, СМ и MAC. Основными объектами модели МППР являются (рис. 1): операции (Ор), ресурсы (Res), команды управления (U), средства (Mech), процессы (/V), источники (Sender) и приемники ресурсов (Receiver), перекрестки (Junction), параметры (Р), агенты (А) или модели ЛПР. Описание причинно-следственных связей между элементами преобразования и ресурсами задается объектом "связь" (Relation). Существование агентов предполагает наличие ситуаций (Situation) и решений (Décision). Модель МППР представлена в виде
M — <Name, desc. О, {Relation}, Aself>,
где Name и desc — имя модели и ее описание; О — объекты (элементы), ресурсы, средства, преобразователи, сигналы, заявки, цели, параметры, агенты, сообщения; Relation — связи; AselJ'— собственные атрибуты модели.
Агенты управляют объектами процесса преобразования. Агент выполняет следующие действия: 1) анализирует внешние параметры (текущую ситуацию); 2) диагностирует ситуацию, обращается к БЗ. В случае определения соответствующей ситуации агент пытается найти решение в БЗ или выработать его самостоятельно; 3) вырабатывает решение; 4) определяет и контролирует достижение целей; 5) обменивается сообщениями.
Для построения ядра ИМ был использован аппарат продукционных систем. Определена структура продукционной системы МППР в виде
PS = <Rps. Bps, Ips>,
где Rps = {RES(t)} u {MECH(t)) u {U(t)} и{Ш}-текушее состояние ресурсов, средств, команд управления, целей (рабочая память); Bps — множество правил преобразования ресурсов и действий агентов (база знаний); Ips — машина вывода, состоящая из планировщика и машины логического вывода по базе знаний (БЗ) агентов.
Алгоритм имитатора состоит из следующих основных этапов: I) определения
о
Л
А, (Агент)
Sender 1 (Источник)
Pr1 (Процесс)
Receiver 1 (Приемник)
Ор2 (Операция)
»(tfes^
Junction1 (Перекресток)
ОрЗ
'es1(
ил
\ , 1 Ор4
1 *
Рис. 1. Объекты модели МППР
текущего момента времени SysTime-min7\;
jeRULE
2) обработки действий агентов; 3) формирования очереди правил преобразования; 4) выполнения правил преобразования и изменения состояния рабочей памяти. Для диагностирования ситуаций и выработки команд управления имитатор обращается к модулю ЭС.
Для описания иерархической структуры МППР [3] были использованы системные графы высокого уровня интеграции [5]. Важное значение при построении архитектуры мультиагентной ОО СППР оказывает выбор и реализация архитектуры MAC.
Расширение модели МППР архитектурой InleRRaP
Различают два основных класса архитектур агентов: I) архитектура "интеллектуального агента", которая базируется на принципах и методах искусственного интеллекта, т. е. систем, основанных на знаниях (deliberative agent architecture — архитектура разумного агента); 2) архитектура "реактивного агента", основанная или на пове-
дении (reactive architecture), или на реакции системы на события внешнего мира. Сейчас среди разработанных архитектур не существует такой, о которой можно сказать, что она является чисто поведенческой или основана только на знаниях. Любая из разработанных архитектур — гибридная и имеет черты от архитектур обоих типов.
За основу архитектуры МППР взята InteRRap-архитектура (как наиболее соответствующая предметной области) — множество вертикально упорядоченных уровней, связанных через общую структуру управления и использующих общую базу знаний [6]. Архитектура состоит из блоков: интерфейса с внешним миром, реактивной подсистемы, планирующей подсистемы, подсистемы кооперации с другими агентами и иерархической базы знаний. Интерфейс с внешним миром определяет возможности агента по восприятию объектов или событий внешнего мира, воздействия на него и средства коммуникации. Реактивная подсистема использует базовые возможности агента по реактивному поведению, а так-
же частично использует знания агента процедурного характера. Она базируется на понятии "фрагмента поведения" как некоторой заготовки реакции агента на некие стандартные ситуации. Компонента, ответственная за планирование, содержит механизм планирования, позволяющий строить локальные планы агента (планы, не связанные с кооперативным поведением). Компонента, ответственная за кооперацию агентов, участвует в конструировании планов совместного поведения агентов для достижения некоторых общих целей или выполнения своих обязательств перед другими агентами, а также выполнения соглашений.
В соответствии с обшей концепцией 1теЯЯаР-архитектуры модель агента МППР представлена четырьмя уровнями.
1. Модель внешней среды соответствуют следующим элементам МППР: преобразователям, ресурсам, средствам, параметрам, целям. Внешняя среда выполняет следующие функции: генерирует задания, осуществляет передачу сообщений между агентами, обрабатывает команды агентов (выполняет преобразование ресурсов), изменяет текущее состояние внешней среды (переводит ситуацию в ситуацию 5„+|).
2. Компоненты интерфейса с внешним миром и реактивного поведения реализованы в виде базы продукционных правил агента (тактической БЗ) и машины логического вывода (алгоритма имитатора).
3. Компонента реактивного поведения выполняет следующие задачи: 1) получает из внешней среды задания: 2) помещает задание в стек целей; 3) упорядочивает цели в стеке в соответствии с применяемой стратегией ранжирования целей; 4) выбирает верхнюю цель из стека; 5) просматривает базу знаний; 6) если найдено соответствующее правило, передает управление процедуре (преобразователю ресурсов) из внешней среды; 7) если правило не найдено, формирует запрос для модуля локального планирования.
4. Уропенъ локального планирования предназначен для поиска эффективных решений в сложных ситуациях (например, когда для достижения поставленной цели требуется выполнить несколько шагов или
существует несколько альтернативных путей достижения поставленной цели). Компонента локального планирования реализована на основе фреймовой ЭС (представляет собой стратегическую БЗ). В качестве средства формализации знаний используется подход на основе фрейм-концептов и концептуальных графов [2].
Проектирование КМ ПО и базы знаний (БЗ) локального планирования агента реализовано на основе расширения диаграммы классов языка UML. Семантически это представление может быть интерпретировано как реализация полного графа поиска решения, содержащая все возможные пути достижения некоторой цели. Механизм логического вывода по данной БЗ реализован через диаграмму поиска решений, построенной на основе диаграммы последовательности [7]. Каждое решение в БЗ представляет собой план действий агента. Каждый план состоит из набора правил из базы реактивного компонента. На основе найденного решения происходит обновление текущего плана агента. Перебор всех вариантов, содержащихся в БЗ, формирует библиотеку планов агента.
Если агент в ходе обработки задания или сообщения, полученного из внешней среды, сталкивается с отсутствием соответствующего правила в своей базе (например, "выбрать вариант дальнейшего развития событий из нескольких существующих"), то модуль реактивного поведения формирует запрос к планировщику с указанием цели (т. е. задания, которое требуется выполнить, или состояния внешней среды, которое требуется получить). Планировщик формирует список планов, отбирает из них оптимальный в соответствии с заданными критериями и алгоритмами оценки, декомпозирует планы, определяет значения параметров, необходимых для имитационного моделирования, и затем передает необходимую информацию компоненту реактивного поведения.
В следующем разделе на основе вышеизложенной модели МППР и архитектуры MAC представлены принципы разработки и технические решения созданной мульги-агентной ОО СППР процессов преобразования ресурсов.
Система поддержки принятия решений ВР81ш4
00 СППР ВР51ш4 реализована на основе интеграции СДМС ВР5пп2 и системы технико-экономического проектирования ВРятЗ.
В соответствии с обшей концепцией Мпе[ШаР-архитектуры модель агента представлена четырьмя уровнями. Компоненты интерфейса с внешним миром и реактивного поведения, как и собственно модель внешнего мира, реализованы в программном модуле ВРяш12. Уровень локального планирования реализован на базе модуля ЭС ВР5ЙТ13. Визуальный построитель механизма вывода оболочки ЭС реализован на основе диаграмм поиска решений (расширение диаграмм последовательности языка иМЬ) — рис. 2. Уровень кооперации реализуется на базе обоих модулей.
На блок-схеме (рис. 3) показано взаимодействие отдельных модулей в ходе работы агента в рамках интегрированного поля BPsim2 и BPsim3. Основные принципы и отдельные этапы работы агента приводились ранее, при описании концептуальной модели lnteRRaP-архитектуры.
ОО СППР BPsim4 обеспечивает выполнение следующих функций: проектирование КМ ПО; создание динамической модели МППР; динамическое моделирование; анализ результатов эксперимента; получение отчетов по моделям и результатам экспериментов. экспорт результатов экспериментов в MS Excel и MS Project.
Применение системы BPsini4
СППР BPsim4 использовалась на различных этапах разработки и внедрения единой информационной системы (ЕИС)
*
Рис. 2. Диаграмма поиска решения в СППР ВР51т4 "Подбор команд, планирование сроков
и затрат ИТ-проекта"
ВРБ1т2
Чтение сообщений
т
Преобразовать сооб-щение в цели и правила тактической БЗ
X
Поместить цели в стек
Обновление
тактической БЗ
♦
Переупорядочить цели Нет
в соответствии
с приоритетами 1 г
1 Выбрать первую цель
из стека
Обращение к тактической БЗ
Обращение к компоненту локального планирования
I
Найти решение с максимальной оценкой
1
Поиск решений в стратегической БЗ
ВРб^З
Формирование целей и правил активных действий для тактической БЗ
±
Формирование сообщения и отправка
Нет
Формирование модели мира
1 г
Передача управления внешней среде
1 г
Выполнени дейс е активных твий
С
Окончание
)
Рис. 3. Блок-схема работы НА
Уральского государственного технического университета — УПИ (УГТУ) начиная от стадии анализа учебного процесса и проведения реинжениринга и заканчивая оценкой эффективности внедрения отдельных модулей ЕИС.
В период с 2005 по 2007 год было проведено обследование учебного процесса УГТУ. Анализ показал, что учебный процесс частично автоматизирован, на 2005 год в УГТУ использовалось большое количество ИС (более 20) практически не связанных друг с другом. Анализ БП выполнялся с использованием структурного и объектно-ориентированного анализа, в модуле проектирования ИС [8] было построено более 60 диаграмм ЮЕЕО. В результате анализа выявлены следующие недостатки процессов "Ход сессии" и "Движение контингента" [8]: затруднен поиск нужной информации; наблюдается дублирование информации; отсутствие актуальной информации; не было возможности управлять и контролировать документооборот; большое количество рутинной бумажной работы. ИС реализованы на разных программно-аппаратных платформах, часть систем реализована на устаревших платформах, техническая поддержка которых уже не представляет смысла.
Модель "как будет" процесса "Ход сессии", Процесс "Ход сессии" включает в себя формирование экзаменационных и зачетных ведомостей, выдачу и регистрацию зачетных и экзаменационных листов, прием экзаменов и зачетов, формирование отчетов по аттестации студентов. В процессе "Ход сессии" задействованы сотрудники деканата, отдел АСУ, учебно-методическое управление (УМУ), планово-финансовое управление (ПФУ). Основная нагрузка ложится на сотрудников деканата, которые вводят исходную информацию и формируют отчеты по итогам сессии. Работу, связанную с формированием экзаменационных и зачетных ведомостей и контролем итогов сессии, выполняет отдел АСУ. Отделы УМУ и ПФУ предоставляют первоначальную информацию — учебные планы, стипендиальный фонд для распределения. Процесс "Ход сессии" сопровождается подготовкой большого количества бумажных докумен-
тов, что в свою очередь сильно замедляет своевременное распространение информации до заинтересованных лиц. Выявленные проблемы позволили сформулировать требования по совершенствованию и автоматизации данного процесса.
Было предложено внести изменения в процесс работы сотрудников деканата: бумажное заполнение семестровых журналов заменяется вводом данных в электронную версию семестрового журнала. Появление единой БД снимает проблему оперативного доступа к актуальной информации. Выдача экзаменационных листов регистрируется в электронном журнале, а отметки возврата и выдачи в семестровом журнале. Для ускорения идентификации документов используется штрих-кодирование.
Таким образом, совершенствование процесса "Ход сессии" (модель "как будет") позволит: формировать актуальную БД, автоматизировать выдачу и учет экзаменационных и зачетных листов, вводить результаты сдач и пересдач в электронный журнал, формировать приложение к диплому, академическую справку, отчеты по должникам и отчетов по ходу зачетов, параллельно работать с семестровым журналом сотрудникам.
Модель "как будет" процесса "Движение контингента". Процесс "Движение контингента" включает в себя формирование выписок в приказ, списочных приказов, сборных приказов по УГТУ. формирование различных справок. Основными участниками этого процесса являются сотрудники деканатов и личного стола студентов (ЛСС), деканы, проректор. Процесс организован так, что с момента получения сотрудником деканата первичных документов до момента изменения информации о студенте в БД и проводки приказа проходило в среднем от двух до четырех недель, также сотрудники выполняли много рутинной работы: сотрудники деканата формировали в разное время два схожих по содержанию документа: заявление (помогали студенту) и выписку в приказ. Данную информацию также вводили в ЛСС при формировании сводного приказа; проректор три раза просматривал и визировал схожие документы.
В результате анализа предложено: во время написания заявления студентом сотруднику деканата создавать его электронный аналог в единой БД;
отказаться от формирования выписки в приказ, всю необходимую информацию для издания приказа заносить в единую БД, следовательно, сбор виз проводить один раз: сотрудникам J1CC, работающим с электронной формой заявления, самим его корректировать (исчезнут потери времени на отправление документов в деканат для внесения изменений);
формировать и хранить дела студентов в электронном виде (история по студенту);
проректору подписывать только заявление и приказ по вузу;
в ИС отслеживать стадии прохождения документов:
ликвидировать функцию, не свойственную сотрудникам отдела АСУ — выполнение проводок приказа в базе данных;
списочный приказ в ИС формировать сотруднику деканата (затем с ним работает сотрудник JTCC).
По результатам обследования написано техническое задание (ТЗ) на ЕИС [9], содержащее требования и диаграммы, описывающие архитектуру системы. ТЗ содержит 25 DFD-диаграмм, 14 диаграмм прецедентов. 18 диаграмм последовательности и одну диаграмму классов.
Принятие решений при выборе варианта реализации ЕИС. В СППР BPsim4 на основе новой архитектуры MAC разработана модель агента (ЛПР), управляющего процессом разработки программного обеспечения (ПО) в УГТУ. Модель состоит из имитационной модели "Разработка ПО для учебного процесса" и моделей ППР. основная из которых — "Выбор пути реализации ЕИС вуза" (БЗ данной модели содержит информацию о сетях, программном и аппаратном обеспечении, ИС, ИТ-проек-тах, командах ИТ-специалистов).
Модуль ЭС требуется для разработки БЗ о проектных альтернативах и алгоритмов поиска эффективной альтернативы, имитационная модель предназначена для отслеживания хода выполнения отдельных этапов проекта, выявления ошибок и про-
тиворечий. допущенных на начальном этапе планирования, и разрешения возможных форс-мажорных ситуаций, возникающих в ходе управления проектом разработки и внедрения ЕИС. Имитационная модель (рис. 4) построена на основе спиральной модели жизненного цикла ПО в BPsim4.
Дискретно-событийная модель дополнена агентом (ЛПР), функцией которого является решение текущих оперативных задач управления моделируемым процессом, и задачей выбора варианта проекта. Обращаясь к модулю локального планирования, агент получает технико-экономические параметры нового варианта и обновляет параметры имитационной модели.
Процесс выбора варианта реализации ЕИС представляет собой многостадийную и многопараметрическую задачу принятия решения, включающую следующие этапы: анализ рахчичных предложений компаний-разработчиков ПО; выбор программно-аппаратной платформы; подбор и распределение ИТ-специалистов по этапам ЖЦ ПО.
На стадии формирования требований и анализа процессов вуза сгенерированы следующие возможные альтернативы проекта ЕИС:
разработка и внедрение ЕИС совместно с компанией NAUMEN;
собственная разработка ЕИС и ее внедрение;
внедрение решения "Университет" компании REDLAB;
внедрение решения IBS.
В рамках каждого варианта проекта возможен выбор различных характеристик отдельных этапов, формирующих проект (проектирование, программирование, тестирование, внедрение). Таким образом, стоит задача выбора наиболее эффективного по стоимости, срокам и функциональности решения с учетом текущей ситуации в вузе и прогноза развития.
Варианту самостоятельной разработки и внедрения ЕИС присущи следующие недостатки: большой риск (связан с отсутствием необходимого количества ИТ-специалистов и опыта участия в таком объемном проекте); затраты на приобретение средств разработки; непроизводственные затраты.
Число итераций
Ol О 2 ©3 О*
Менеджер проекта (ЛПР)
Установить счетчик числа оставшихся итераций
Время
pResI Количество аналитиков
0 I ———^ 5
4
pRes28 Количество архитекторов
0 i-------сг---5
2
pRes27 Количество программистов О,-JJ- 10
3
ХектиГОование ПО
iRes35 Количество тестцгавшиков
П - J"P
Внедрение ПО
Рис. 4. Имитационная модель разработки ПО в среде BPsim4
Решение IBS внедрено в Российской академии народного хозяйства (АНХ) и имеет средний уровень функциональности. Опытом внедрения и функциональностью обладает решение "Университет" компании RedLab (на базе ERP-системы SAP), но он является самым затратным. Результаты оценки стоимости и времени, необходимого на внедрение решений, представлены на рис. 5 и 6.
По результатам моделирования был выбран вариант разработки и внедрения ЕИС вместе с компанией №итеп; риски разделяются с ИТ-компанией, за счет привлечения квалифицированных специалистов и организации сплоченной команды проекта затраты на использование средств разработки минимальны (используется открытое ПО).
Результаты внедрения ЕИС. Данные модели процессов "Как будет" реализованы
мпн руб 300-,
Собственная Naumen разработка
Шщ
щш _
FfcdLab
АНХ
14
12 10 8 6 4 2
Длительность проекта, лет
Собственная rsfaumen разработка
Вт ' :
IBS
"■Щ'й
FfedLab
АНХ
Рис. 5. Стоимостные характеристики решений
Рис. 6. Длительность проекта
в программных модулях ЕИС и внедрены в УГТУ — УПИ. Благодаря совершенствованию и автоматизации процесса "Движение контингента" повысилась производительность: сотрудников деканата — на 27 %, а сотрудников ЛСС — на 29 %, т. е. более чем в три раза. Экономический эффект от внедрения предложенных моделей "как будет" и автоматизации процесса "Движение контингента" составляет 1027 гыс. руб. в год. Эффект достигнут за счет сокращения "лишних" петель и этапов процесса движения докумен-
тов. сокращения ввода дублирующей информации и снижения нагрузки на сотрудников деканатов и личного стола студентов.
Решение задачи интеграции имитационного. экспертного, ситуационного и мультиагентного моделирования, а также объектно-ориентированного подхода позволило реализовать объектно-ориентирован-ный метод моделирования и принятия решений МППР, а также ОО СППР ВР51ш4, которая используется в УГТУ.
СПИСОК ЛИТЕРАТУРЫ
1. Андрейчнков A.B., Андрейчикова О.Н.
Интеллектуальные информационные системы: Учебник. М.: Финансы и статистика. 2004. 424 с.
2. Швецов А.Н. Модели и методы построения корпоративных интеллектуальных систем поддержки принятия решений: Дис. ... д-ра техн. наук. СПб.. 2004. 461 с.
3. Аксенов К.А., Гончарова Н.В. Динамическое моделирование мультиагентных процессов преобразования ресурсов. Екатеринбург: ГОУ ВПО УГТУ-УПИ, 2006. 311 с.
4. Аксенов К.А. Исследование и разработка средств имитационного моделирования дискретных процессов преобразования ресурсов: Дис. ... канд. техн. наук / ГОУ ВПО "УГТУ — УПИ". Екатеринбург, 2003. 188 с.
5 Аврамчук Е.Ф.. Вавилов A.A., Емельянов C.B. и др. Технология системного моделирования. М.: Машиностроение. 1988. 520 с.
6. Jorg Р. Müller, Markus Pischel. The Agent Architecture InteRRap: Concept and Application / German Research Center for Artificial Intelligence (DFKI).
7. Аксенов К.А., Попов М.В., Смолнй Е.Ф., Доросинский Л.Г. Динамическая система моделирования и проектирования мультисервисных сетей связи "ВРч1тЗ" // Имитационное моделирование. Теория и практика: Матер, третьей Всерос. науч.-практ. конф. Санкт-Петербург / ФГУП ЦНИИ технологии судостроения. СПб., 2007. Т. 1. С. 253-257.
8. Результаты обследования и формирования требований на создание единой И С поддержки учебного процесса (с 15 мая 2005 года по 14 февраля 2006 года): Отчет по проекту *01200601073 / ГОУ ВПО "Уральский государственный технический университет — УПИ"; Руководитель работы А.К. Аксенов. Екатеринбург. 2006. 119 с.
9. Техническое задание на создание единой ин-(|юрмационной системы учебного процесса УГТУ — УПИ: Огчет по проекту'»01200601073 / ГОУ ВПО "Уральский государственный технический университет — УПИ"; Руководители работы А.К. Аксенов. А. Лукшин. Екатеринбург, 2006. 116 с.
УДК 51 7.977.5:553.982.2
О.М. Верхотурова
РАЗРАБОТКА ПОДХОДА К РЕШЕНИЮ ЗАДАЧИ ВЫДЕЛЕНИЯ ЕСТЕСТВЕННЫХ НЕСТРУКТУРИРОВАННЫХ ОБЪЕКТОВ НА ОСНОВЕ ДИСКРЕТНЫХ МОДЕЛЕЙ
Задача выделения объектов встречается в различных областях человеческой деятельности, в том числе в космических ис-
следованиях, нефтяной промышленности, медицине. Особый интерес представляет для естественных, неструктурированных
