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

Для описания динамики процесса управления в проблемных ситуациях используются следующие диаграммы поведения:

• диаграммы состояний,

• диаграммы активностей и

• диаграммы взаимодействия, состоящие из:

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

• диаграмм кооперации.

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

Диаграмма последовательности действий изображается в виде двухмерной схемы (в виде графа). По вертикали проходит временная ось, где течение времени происходит сверху вниз. По горизонтали указываются роли классов, которые представляют отдельные объекты взаимодействия. В языке UML объект на диаграмме последовательности выгладит как прямоугольник, содержащий подчеркнутое название объекта. Название объекта может состоять только из имени объекта, из имени объекта и его класса или только имени класса (анонимный объект). У каждой роли есть «линия жизни», идущая сверху вниз, отображающая тот период времени, в течение которого объект существует, и изображаемая на диаграмме вертикальной пунктирной линией. Во время вызова процедуры определенного объекта (активизации) его «линия жизни» изображается двойной линией.

Сообщение выглядит на диаграмме как стрелка, идущая от «линии жизни» одного объекта к «линии жизни» другого объекта. Стрелки организованы согласно временной последовательности сообщений.

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

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

Рис. 2.23. Диаграмма последовательности действий для повторного

использования решений

На рис. 2.24 показана диаграмма кооперации для поиска ближайших прецедентов.

Диаграммы прецедентов, диаграммы последовательности и кооперации, описывающие процесс управления более подробно, представляют регламент управления объектом “как должно быть”. В силу специфики рассматриваемой предметной области существует многообразие различных вариантов реального развития проблемных ситуаций, которое нельзя отобразить с помощью одной или даже нескольких альтернативных диаграмм. Кроме того, для формализации представления знаний требуется более широкий спектр выразительных возможностей для описания отношений между объектами, кроме поддерживаемых UML отношений зависимости, обобщения и ассоциации. Решением проблемы является использование интеллектуального анализа данных для классификации проблемных ситуаций в соответствии с типовыми решениями и сценариями их реализации. По результатам классификации производится динамическое планирование управления в проблемных ситуациях. План реализации решения моделируется в виде иерархии диаграмм последовательности действий, в которой диаграмма верхнего уровня моделирует общий, монотонный план управления в КС, а диаграммы действия нижнего уровня могут быть немонотонными (монотонность предполагает, что каждое действие по плану уменьшает различие между текущим состоянием объекта и целью управления).

Рис. 2.24. Диаграмма кооперации для поиска ближайших прецедентов

Модели анализа могут быть непосредственно подвергнуты сравнению с моделями реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области в объекты и классы информационной системы. Так, на рис. 2.24 показаны операции поведения класса «поиск ближайших прецедентов» на диаграмме классов и диаграмме взаимодействия.

Диаграмма состояний создается для классов с динамическим поведением. Моделирование динамики поведения классов основано на принципах теории конечных автоматов.

Состояние – это некоторое положение в жизни объекта, при котором он удовлетворяет определенному условию, выполняет некоторое действие или ожидает события. Диаграмма состояний (statechart diagram) показывает положение одиночного объекта, события или сообщения, которые вызывают переходы из одного состояния в другое, и действия, являющиеся результатом смены состояний.

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

С переходом между состояниями может быть связано условие (guard condition) и/или определенное действие (action). Переход может также вызывать событие (event). Действие – это поведение, проявляющееся при возникновении перехода. Событие – это сообщение, отправляемое другому объекту системы. Условие – булево выражение значений атрибутов, которое допускает переход, только если оно верно. И действие, и проверка условия представляют собой поведение объекта и обычно реализуются в виде операций.

Рис. 2.25. Диаграмма состояний ИСППР

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

Действия, сопровождающие переходы в определенное состояние, можно рассматривать как входные действия (entry action) для этого состояния. И наоборот, действия, сопровождающие переходы из данного состояния, являются для него выходными (exit action). Поведение, возникающее внутри состояния, называется деятельностью (activity). Деятельность начинается при входе в состояние и завершается или прерывается при выходе из него.

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

Модели процесса управления в проблемных ситуациях для предметной области управления распределенным динамическим объектом (на примере вычислительной сети) показаны на рис. 2.27 – 2.30. Диаграмма кооперации на рис. 2.27 является моделью передачи сообщений в подсистеме вычислительной сети архитектуры «клиент-сервер». На рис. 2.28 и 2.29 показаны модели взаимодействия оператора и ИСППР в процессе мониторинга состояний управляемого динамического объекта и обработки тревожных сигналов. В дополнение к диаграмме состояний ИСППР, моделирующей процесс поиска решений (рис. 2.23), приведен фрагмент диаграммы состояний по обработке сигналов тревоги (рис. 2.30).

Рис. 2.27. Диаграмма кооперации элементов вычислительной сети в процессе передачи сообщении

Рис. 2.28. Диаграмма кооперации в процессе мониторинга состояния объекта управления

Рис. 2.30. Фрагмент диаграммы состояний ИСПП

при обработке сигналов тревоги

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

Поэтому в качестве реализации структуры модели предложено использовать объектно-реляционную базу данных, способную изменять текущую структуру базы данных для фиксации знания, как текущего отношения между данными. Разработка такого подхода к формированию пространства знаний обеспечивает комплексную обработку большого объема информации с целью анализа проблемной ситуации и прогноза ее развития, а также принятия решений. Результаты визуального моделирования на языке UML были использованы для построения структуры объектной базы данных в системе объектно-реляционной СУБД Cache (см. раздел 5).

Заключительным этапом цикла разработки является программирование. UML– это принятый стандарт Рабочей группы по развитию стандартов объектного программирования (OMG), следовательно, по результатам моделирования модель в нотацииUMLпреобразуется практически в любую объектно-ориентированную нотацию программирования. Вышеприведенные модели разработаны с использованием выпущенного фирмойRational Softwareпрограммного пакетаRational Rose.

Программа Rational Rose, поддерживающая язык UML, содержит разные средства для генерации кода. Код формируется на основе информации, полученной из диаграмм, спецификаций и параметров, указанных в свойствах генерации кода для всех элементов каждого типа. Для совместной работы над проектом предусмотрена возможность публикации модели в виде Web – страниц, которые извлекаются автоматически из модели с использованием Web Publisher for Rational Rose.

При объектно-ориентированном подходе иерархия классов образует до некоторой степени основу программного приложения. Реализация информационной системы осуществляется с использованием систем программирования, в основу которых был положен объектно-ориентированный подход: С++, SmallTalk, Java, XML, Cache Object Script.

Как только первая версия информационной системы представляется потенциальным пользователям, часто возникают новые проблемы, которые требуют дополнительной разработки по корректировке системы, исправлению необнаруженных ранее проблем или завершению реализации некоторых возможностей, которые, возможно, были отложены. В результате оценки эффективности системы в соответствии с установленными критериями эффективности принимается решение, были ли достигнуты цели разработки, и возможно, запускается следующая итерация разработки. В современном подходе к разработке программного обеспечения Rational Unified Process (RUP) итерация – это законченный цикл разработки, приводящий к выпуску выполнимого изделия (внутренней или внешней версии) или подмножества конечного продукта, которое возрастает с приращением от итерации к итерации, чтобы стать законченной системой. Необходим итерационный подход, который позволяет увеличивать понимание проблемы через последовательные усовершенствования и с приращением конкретизировать эффективные решения. Этот подход обеспечивает лучшую гибкость в учете новых требований или тактических изменений в деловых целях, и позволяет проекту заранее идентифицировать и разрешать риски.

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

Разработка такого подхода к формированию пространства знаний обеспечивает комплексную обработку большого объема информации с целью анализа проблемной ситуации и прогноза ее развития, а также принятия решений. Результаты визуального моделирования на языке UML были использованы для построения структуры объектной базы данных в системе объектно-реляционной СУБД Cache (см.раздел 5).

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

Для всех моделей составляется словарь предметной области (англ. – glossary) или словарь моделей (англ. – model dictionary), в которых определяются все требуемые термины, повышающие степень понимания предметной области и исключающие риск разногласий при ее обсуждении. Согласованная трактовка терминов чрезвычайно важна в процессе разработки, особенно когда в нее вовлечены большие группы различных специалистов. Большинство абстракций из словаря системы динамически взаимодействуют друг с другом, образуя отношения ассоциации, обобщения, зависимости и другие. Выявление отношений синонимии между терминами описаний проблемных ситуаций, разработка глоссария служат основой для построения тезауруса предметной области.

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