Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Учебник по ТООМ - файл УП_ООМ_5.doc


Загрузка...
Учебник по ТООМ
скачать (4180 kb.)

Доступные файлы (1):

УП_ООМ_5.doc7283kb.30.03.2006 01:55скачать

УП_ООМ_5.doc

1   ...   5   6   7   8   9   10   11   12   13
Реклама MarketGid:
Загрузка...
^

7. Примеры использования UML для построения ИСППР



Переделать под онтологию


Основные задачи проекта


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

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

Простое приложение словаря создано на основе технологии ASP и демонстрирует наиболее фундаментальные особенности расширения языка UML, используемого для проектирования Web-приложений.


Use case diagram



Читатель –это любой пользователь, который просматривает информацию в словаре

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

Задача: находить элементы словаря терминов (слова и описания) по их первым символам

Задача: находить элементы словаря терминов (слова и описания) по ключевому слову или описанию

Задача: добавлять, изменять или удалять элементы словаря терминов (слова и описания)


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




Sequence diagram «Просмотр словаря»



  1. исполнитель переходит на главную страницу словаря

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

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

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

  5. исполнитель с помощью полосы прокрутки просматривает записи в словаре


Sequence diagram «Поиск в словаре»



  1. исполнитель переходит на главную страницу словаря

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

  3. читатель вводит слово или его часть в поле для ввода слова или его описания на форме. Затем читатель передает системе запрос на поиск.

  4. Система находит в словаре все записи, удовлетворяющие заданному на форме критерию. Возвращаются все слова, содержащие введенное в поле Слово значение, а также все записи, в разделе описания которых содержится значение, введенное в поле Описание.



Sequence diagram «Редактирование словаря»



  1. редактор, выполнив поиск и не найдя в словаре нужного слова, решает добавить его.

  2. редактор выбирает гиперссылку Новая запись на странице результаты поиска.

  3. система отображает форму с полями для ввода описания

  4. редактор вводит описание термина, чтобы добавить его в словарь

  5. .редактор передает описание в систему.

  6. система добавляет новую запись в базу данных словаря

  7. система возвращает управление на начальную страницу словаря.




Лекция 11. UML-модели систем реального времени

08.04.04


  1. ^

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


Модели представления метазнаний о процессах управления сложными объектами в проблемных ситуациях с использованием языка Unified Modeling Language

^

8.1. Разработка баз знаний на основе объектно-когнитивного анализа




Знания проявляются и накапливаются в общении и взаимодействии.

Разработка визуальных моделей баз знаний. Выявление отношений семантической сети с помощью визуальных моделей. Аппарат сетей Петри для разработки динамики взаимодействия агентов в процессе обмена сообщениями. Онтология мультиагентной интеллектуальной системы.

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


(глава 2 из книги «Проблемы управления сложными объектами в проблемных ситуациях на основе инженерии знаний»)


В соответствии с методологией объектно-ориентированного анализа и моделирования (рис. 2.10) необходимым этапом моделирования предметной области является анализ требований к разрабатываемой информационной системе, который подразумевает выделение процессов и требований и их формулировку в виде прецедентов. Прецедент в объектном моделировании (англ. – use case) представляет собой документ, описывающий последовательность событий, связанных с исполнителем, который для завершения требуемого процесса использует создаваемую систему. Это представление работы системы с точки зрения акторов (англ. – actors), то есть объектов, выполняющих в системе определенные функции [50]. По результатам анализа прецедентов создается модель (диаграмма) определения требований к системе, основными элементами которой являются прецедент (рисуется как овал), связанный с типичными пользователями – акторами. Диаграмма требований к информационной системе разрабатывается путем опроса экспертов – управляющих о приоритетах среди различных прецедентов использования, которые они идентифицировали. Горизонтальные связи показывают последовательность операций при исполнении прецедентов.

На рис. 2.11 показана модель анализа процесса управления в проблемных ситуациях. На приведенной диаграмме видно, что прецедент «Принятие решений» включает последовательность прецедентов – событий «Анализ ситуации», «Оценка», «Выбор альтернативы». В разрабатываемой ИСППР выполнение этих прецедентов автоматизируется на основе использования базы знаний. С использованием диаграммы требований создан сценарий разработки базы знаний (см. рис. 2.12).




Рис. 2.11. Модель анализа процесса управления в проблемных

ситуациях (диаграмма требований)


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




Рис. 2.12. Модель процесса проектирования базы знаний

(диаграмма требований)


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



Рис. 2.13. Диаграмма требований к системе поддержки принятия решений при предоставлении услуг региональной вычислительной сети





Рис. 2.14. Диаграмма действий для поиска решений в базе знаний


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

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

В языке UML действие изображается в виде прямоугольника с закругленными углами, переходы – в виде направленных стрелок, элементы выбора – в виде ромбов, линии синхронизации – в виде толстых горизонтальных или вертикальных линий. Секции делят диаграмму действий на несколько участков, чтобы показать, какой актор отвечает за выполнение действий на каждом участке. Для обозначения начального и конечного состояний в потоке управления используются специальные символы Start State и End State.

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

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


^ 14.2. Модели структуры информационной системы поддержки принятия решений


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

Диаграммы классов (англ. class diagrams). Диаграммы классов описывают статическую структуру классов. На детальном уровне (уровне спецификаций и уровне реализаций) диаграммы определяют структуру программных классов. Моделирование описания свойств объектов предметной области и отношений между объектами необходимо производить в соответствии с принципами абстракции, инкапсуляции, наследования, полиморфизма [37-42].

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

Агрегация – это такая абстракция, которая превращает связь между объектами в некоторый агрегированный объект более высокого уровня. Осуществляя такую абстракцию, мы можем игнорировать многие детали этой связи. Приведем пример агрегации из области эксплуатации вычислительных сетей: определенная связь между некоторым признаком пользователя (например, именем), паролем и датой может быть абстрагирована как объект "регистрация пользователя". Можно при этом мыслить о "регистрации", не задумываясь о всех деталях рассматриваемой связи, например о номере телефона провайдера, продолжительности предоставления услуг связи и других деталях.

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

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

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

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

В языке ^ UML определены 4 типа отношений: зависимость, ассоциация, обобщение, реализация.

Зависимость – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Ассоциация – структурное отношение, описывающее совокупность связей; связь – это соединение между объектами. Отношение обобщения – отношение «специализация/обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Реализация – это семантическое отношение между классификаторами.

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




^ Рис. 2.15. Диаграмма архитектуры информационной системы

поддержки принятия решений

Если система содержит большое количество классов, они могут быть объединены в пакеты (например, пакеты «^ База знаний», «Объекты сложной динамической системы», «Электронная инструкция» и другие). Пакет UML – это группировка любых элементов модели, используемая для наглядности иллюстрации архитектуры системы.

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


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


В соответствии с принципами моделирования процессов управления сложными динамическими системами в проблемных ситуациях разработан комплекс метамоделей представления и обработки знаний. Метамодели соответствуют содержимому пакетов архитектуры ИСППР, показанной на рис. 2.15. Так, пакет «База знаний» содержит классы «Правило», «Прецедент» и другие классы представления и обработки знаний.

Согласно объектному подходу предметная область процесса управления в проблемных ситуациях содержит правила принятия решений и прецеденты – конкретные объекты реального процесса, которые связаны отношениями обобщения (категория прецедентов - прецедент) зависимости (признак – мера сходства) и ассоциации (правило - прецедент). На рис. 2.16 показаны свойства этих классов и отношения между ними (фрагмент модели структуры классов базы знаний).




Рис. 2.16. Фрагмент модели структуры классов базы знаний



Рис. 2.17. Диаграмма классов, моделирующая структуру системы нечеткого вывода

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

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

Множественное наследование отображается через сетевую рекурсию, которая задает сеть отношений между экземплярами родительской и дочерней сущностей. Это случай, когда сущность находится сама с собой в отношении «многие ко многим».

На рис. 2.18 показана модель «сущность – связь» (англ. ^ Entity Relationship Diagram, ERD) в нотации IDEF1X [43], показывающая иерархию классов представления знаний в базе знаний.

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




^ Рис. 2.18. Иерархия классов представления знаний в базе знаний


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

На рис. 2.19 показана схема структуры базы правил, предназначенной для управления предоставлением сервисов сети Интернет, в том числе и в проблемных ситуациях. Выделенные классы правил образуют иерархию, соответствующую установленной иерархии объектов модели использования сервисов Интернет. На приведенной модели видно, что классы представления услуг Интернет (электронной почты, WWW и др.) подчинены классу контроля доступа в подсеть Интернет, а этим классам, в свою очередь, подчинены классы, управляющие более детальным предоставлением сервисов. Это означает, что в классах нижних уровней иерархии наследуются свойства классов, определенные в классах верхнего, «родительского» уровня (понятия, атрибуты и поведение классов объектов предметной области управления вычислительными сетями) в результате объектного моделирования.





Рис. 2.19. Пример иерархии классов правил и прецедентов в базе

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


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

Каждый класс может иметь атрибуты (свойства). Так, на рис.2.20 класс ^ Поиск ближайших прецедентов имеет атрибут результат поиска. Кроме того, каждый класс может иметь операции – некоторые действия, описывающие поведение объектов класса. Каждой операции соответствует метод - реализация этой операции для объектов данного класса.





Рис. 2.20. Фрагмент статической модели базы знаний для управления предоставлением сервисов услуг Интернет


На рис.2.20 класс Поиск ближайших прецедентов имеет методы инициализировать Поиск ( ), искать ( ), получить Значение Признака (), вычислить Сходство ( ), получить Решение (), отобразить Результат Поиска (), закончить Поиск (). Все объекты данного класса используют один и тот же экземпляр каждой операции (т.е. увеличение количества объектов некоторого класса не приводит к увеличению количества загруженного программного кода). Объект, из которого вызвана операция, передается ей в качестве ее неявного аргумента (параметра).

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

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

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

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

Особенности функционирования ИСППР в реальном времени:

  1. Работа с неполной, неточной и устаревающей информацией (достоверность получаемой информации уменьшается с течением времени, в связи с изменением состояния объекта управления под воздействием внешних факторов или других причин развивающейся проблемной ситуации);

  2. Обеспечение требования отказоустойчивости (работа системы не должна прекращаться из-за выхода из строя одной или нескольких информационных подсистем или отдельных элементов самой ИСППР);

  3. Возможность адаптивной реакции на незапланированные события (должны предусматриваться средства прерывания заданной программы после получения информации о незапланированных событиях. Системы должны обеспечивать оценку значимости событий и сосредоточивать свои ресурсы на информации о наиболее важных событиях);

  4. Гарантированное время реакции (должно обеспечиваться получение рекомендаций, в общем случае с оценкой их достоверности, за заданное время, которое можно варьировать).





Рис. 2.21. Информационные структуры алгоритма поиска

решений в базе знаний




Рис. 2.22. Пример диаграммы классов для системы, работающей

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


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


^ 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), в которых определяются все требуемые термины, повышающие степень понимания предметной области и исключающие риск разногласий при ее обсуждении. Согласованная трактовка терминов чрезвычайно важна в процессе разработки, особенно когда в нее вовлечены большие группы различных специалистов. Большинство абстракций из словаря системы динамически взаимодействуют друг с другом, образуя отношения ассоциации, обобщения, зависимости и другие. Выявление отношений синонимии между терминами описаний проблемных ситуаций, разработка глоссария служат основой для построения тезауруса предметной области.

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

1   ...   5   6   7   8   9   10   11   12   13



Скачать файл (4180 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации