Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Учебник по ТООМ.doc
Скачиваний:
298
Добавлен:
02.05.2014
Размер:
7.46 Mб
Скачать

Лекция 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рез., установленного для определенного класса проблемных ситуаций.

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