- •«Белгородский государственный национальный исследовательский университет»
- •Теория систем и системный анализ
- •Предисловие
- •Содержание
- •Тема 1. Системные исследования 9
- •Тема 2. Моделирование и анализ систем. Основные подходы 18
- •Тема 3. Технологии системного моделирования 50
- •Тема 4. Технология объектного моделирования и анализа 125
- •4.2. Требования к объектному моделированию бизнес-систем 151
- •4.3. Case-инструментарий объектного моделирования и анализа 170
- •Тема 5. Технология системно-объектного моделирования и анализа 182
- •Тема 6. Графический язык моделирования бизнес-процессов bpmn. 231
- •Тема 1. Системные исследования
- •1.1. Структура самостоятельного научного направления
- •1.2. Структура системных исследований
- •1.3. Эволюция системного подхода
- •Вопросы для повторения
- •Резюме по теме
- •Тема 2. Моделирование и анализ систем. Основные подходы
- •2.1. Традиционный системный подход
- •2.1.1. Особенности и проблемы традиционного системного подхода и системного анализа
- •2.1.2. Причины существования проблем традиционного системного подхода и системного анализа
- •2.2. Объектно-ориентированный подход
- •2.2.1. Особенности объектно-ориентированного подхода
- •2.2.2. Необходимость интеграции объектного и системного подходов
- •2.3. Системология – системный подход ноосферного этапа развития науки
- •2.3.1. Основные понятия
- •2.3.2. Системология – язык теории организации, логистики и инжиниринга бизнеса
- •2.3.3. Системологический и объектно-ориентированный подход
- •Вопросы для повторения
- •Резюме по теме
- •Тема 3. Технологии системного моделирования
- •3.1. Технология системно-структурного моделирования и анализа «3-View Modeling»
- •3.1.1. Диаграммы потоков данных: нормативная система; построение модели; словарь данных; спецификация процесса
- •Нормативная система
- •Построение модели
- •Словарь данных
- •3 {Болт} 7 – от 3 до 7 итераций
- •1 {Болт} – 1 и более итераций
- •Спецификация процесса
- •3.1.2. Диаграммы «сущность-связь»: нотация Чена; нотация Баркера; построение модели
- •Нотация Чена
- •Нотация Баркера
- •Построение модели
- •3.1.3. Диаграммы переходов состояний
- •3.2. Стандарты системного моделирования и анализа серии «Icam deFinition»
- •3.2.1. Стандарт функционального моделирования idef0
- •3.2.2. Стандарт информационного моделирования idef1
- •3.2.3. Стандарт моделирования баз данных idef1x
- •3.2.4. Стандарт моделирования сценариев idef3.
- •3.2.5. Стандарт моделирования онтологий idef5
- •3.3. Case-инструментарий системного моделирования и анализа
- •3.3.1. Назначение и возможности «AllFusion Process Modeler/bPwin»
- •3.3.2. Особенности «bPwin»
- •3.3.3. Недостатки инструментария системного моделирования
- •Вопросы для повторения
- •Резюме по теме
- •Тема 4. Технология объектного моделирования и анализа
- •4.1.1. Сущности: структурные; поведенческие; группирующие; аннотационные
- •Структурные сущности
- •Поведенческие сущности
- •Группирующие сущности
- •Аннотационные сущности
- •4.1.2. Отношения
- •4.1.3. Диаграммы
- •4.1.4. Процесс объектно-ориентированного моделирования/проектирования: начальная фаза; исследование; построение; внедрение; дополнительные средства
- •Начальная фаза проекта (Inception)
- •Исследование (Elaboration)
- •Построение (Construction)
- •Внедрение (Transition)
- •Дополнительные средства
- •4.2. Требования к объектному моделированию бизнес-систем
- •4.2.1. Внешняя модель бизнес-системы
- •4.2.2. Внутренняя модель бизнес-системы
- •4.2.3. Пример uml-модели бизнес-системы
- •4.2.4. Пример модели информационного обеспечения бизнеса
- •4.3. Case-инструментарий объектного моделирования и анализа
- •4.3.1. Назначение и возможности «ibm Rational Software Architect»
- •4.3.2. Интерфейс «ibm Rational Software Architect»
- •4.3.3. Представление модели в «ibm Rational Software Architect»: представление вариантов использования; логическое представление; представление компонент; представление размещения
- •Представление вариантов использования
- •Логическое представление
- •Представление компонент
- •Представление размещения
- •4.3.4. Недостатки инструментария объектного моделирования
- •Вопросы для повторения
- •Резюме по теме
- •Тема 5. Технология системно-объектного моделирования и анализа
- •5.1. Методология системно-объектного моделирования и анализа
- •5.1.1. Системологический подход «Узел-Функция-Объект»
- •5.1.2. Адаптивная нормативная система уфо-анализа
- •5.1.3. Классификация бизнес-систем
- •5.2. Процедура системно-объектного моделирования и анализа
- •5.2.1 Алгоритм уфо-анализа.
- •5.2.2. Примеры уфо-моделей.
- •5.3. Case-инструментарий системно-объектного моделирования и анализа
- •5.3.1. Назначение и возможности «ufo-toolkit»
- •5.3.2. Особенности функционирования «ufo-toolkit»
- •5.3.3 Технология представление моделей в «ufo-toolkit»
- •Торгово-закупочная деятельность
- •Вопросы для повторения
- •Резюме по теме
- •Тема 6. Графический язык моделирования бизнес-процессов bpmn.
- •6.1. Назначение и область применения.
- •6.2. Диаграммы бизнес-процессов (bpd).
- •6.2.1. Элементы потока.
- •6.2.2. Соединяющие элементы.
- •6.2.3. Зоны ответственности и артефакты.
- •6.2.4. Правила соединения Элементов потока.
- •6.3. Соотношение bpmn, xpdl, bpel, bpml.
- •6.3.1. Стандарты sgml и xml
- •6.3.5. Соотношение языков.
- •6.4. Case-инструментарий бизнес-моделирования в нотации bpmn.
- •6.4.1. Назначение и возможности.
- •6.4.2. Особенности функционирования и интерфейса.
- •6.4.3. Примеры моделей в нотации bpmn.
- •6.4.4. Недостатки моделирования в нотации bpmn.
- •Вопросы для повторения
- •Резюме по теме
- •Вместо заключения
- •Представление dfd-диаграммы с помощью уфо-модели
- •Представление idef0-диаграммы с помощью уфо-модели.
- •Представление bpmn-диаграммы с помощью уфо-модели.
- •Глоссарий
- •Список литературы
3.1.3. Диаграммы переходов состояний
Диаграммы переходов состояний (STD) предназначены для моделирования и документирования аспектов систем, зависящих от времени или реакции на событие. Они позволяют осуществлять декомпозицию управляющих процессов и описывают отношения между входными и выходными управляющими потоками для управляющего процесса-предка.
С помощью STD-диаграмм можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования. Моделируемая система в любой заданный момент времени находится точно в одном из конечного множества состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть точно определены. STD-диаграмма состоит из следующих объектов [20]:
Состояние – набор характеристик, описывающих условия устойчивости системы. Находясь в определенном состоянии и имея информацию о прошлой истории системы, можно определить очередное состояние в зависимости от текущих входных событий (потоков). Имя состояния должно отражать реальную ситуацию, в которой находится система, например, Нагревание, Охлаждение и т.п.
Начальное состояние – узел STD-диаграммы, являющийся стартовой точкой для начального системного перехода. STD-диаграмма имеет ровно одно начальное состояние, соответствующее состоянию системы после ее инсталляции (внедрения), но перед началом реальной работы, а также любое (конечное) число завершающих состояний.
Переход определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия (например, счетчик=999 или «кнопка нажата»). Следует отметить, что, вообще говоря, не все события необходимо вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние.
Таким образом, условие представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например, «пароль»=999, где Пароль - входной поток управляющего процесса-предка.
Кроме условия с переходом может связываться действие или ряд действий, выполняющихся, когда переход имеет место. То есть действие – это операция, которая может иметь место при выполнении перехода. Если действие необходимо для выбора выходного управляющего потока управляющего процесса-предка, то имя этого потока должно заключаться в кавычки, например:
«Введенная карта» = true, где Введенная карта – выходной поток управляющего процесса-предка.
Кроме того, для спецификации А-, Т-, E/D-потоков (см. табл. 3.1) имя запускаемого или переключаемого процесса также должно заключаться в кавычки, например:
А: «Получить пароль» – активировать процесс Получить пароль.
Фактически условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагировать определенным образом, изменяя свое состояние. При изменении состояния система обычно выполняет одно или более действий (например, для информационной системы: производит вывод, выдает сообщение на терминал, выполняет вычисления). Таким образом, действие представляет собой отклик, посылаемый во внешнее окружение, или вычисление, результаты которого запоминаются в системе (обычно в хранилищах данных, представленных на DFD-диаграмме, структура и содержание которых представлены на ERD-диаграмме), для того, чтобы обеспечить реакцию на некоторые из планируемых в будущем событий.
На STD-диаграмме состояния представляются узлами, а переходы – дугами (рис. 3.21). Условия (по-другому называемые стимулирующими событиями) идентифицируются именем перехода и возбуждают его выполнение. Действия или отклики на события привязываются к переходам и записываются под соответствующим условием. Начальное состояние на диаграмме должно иметь входной переход, изображаемый потоком из подразумеваемого стартового узла (иногда этот стартовый узел изображается небольшим квадратом и привязывается к входному состоянию).
Рис. 3.21. -
STD-диаграмма.
При построении STD-диаграммы рекомендуется [20] следовать перечисленным ниже правилам:
строить STD-диаграмму на как можно более высоком уровне детализации DFD-диаграммы;
строить как можно более простые STD-диаграммы;
по возможности детализировать STD-диаграммы;
использовать те же принципы именований состояний, событий и действий, что и при именовании процессов и потоков.
Применяются два способа построения STD-диаграмм. Первый способ заключается в идентификации всех возможных состояний и дальнейшем исследовании всех не бессмысленных связей (переходов) между ними. По второму способу сначала строится начальное состояние, затем следующие за ним и т.д. Результат (в обоих случаях) – предварительная STD-диаграмма, для которой затем осуществляется контроль состоятельности, заключающийся в ответе на следующие вопросы:
все ли состояния определены и имеют уникальное имя?
все ли состояния достижимы?
все ли состояния имеют выход?
(для каждого состояния) реагирует ли система соответствующим образом на все возможные условия (особенно на ненормальные)?
все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD-диаграмме?
В качестве примера рассмотрим диаграмму переходов состояний для системы управления лифтом (рис. 3.22). Для этого используем DFD-диаграммы этой системы (рис. 3.2 – 3.7).
В ситуации, когда число состояний и/или переходов велико, для проектирования STD-диаграммы могут использоваться таблицы или матрицы переходов состояний. Обе эти нотации позволяют зафиксировать ту же самую информацию, что и диаграммы переходов состояний, но в другом формате.
Матрица переходов состояний содержит по вертикали перечень состояний системы, из которых осуществляется переход, а по горизонтали – состояния, в которые осуществляется переход. При этом каждый элемент матрицы содержит соответствующие условия и действия, обеспечивающие переход из «вертикального» состояния в «горизонтальное». В качестве примера данного варианта матрицы переходов состояний приведена таблица 8, соответствующая диаграмме переходов состояний (рис. 21).
Рис. 3.22.
- STD-диаграмма
ECS.
В завершении рассмотрения технологии 3VM следует отметить, что описанные три вида диаграмм и набор дополнительных средств позволяют комплексно визуализировать, формализовать и документировать процессы и потоки в исследуемой системе. Данная технология является весьма полезным средством, однако, только в том случае, если в дальнейшем планируется автоматизация и разработка программных средств методами и языками процедурного программирования.
Таблица 3.5. Матрица переходов состояний ECS.
|
Занят (движется) |
Остановлен |
Пуст (стоит) |
Перегружен (стоит) |
Занят (движется) |
прибытие на незапланированный этаж |
прибытие на запланированный этаж |
|
|
Остановлен |
лифт готов к движению, «кнопки назначения нажаты» |
|
лифт готов к движению, но кнопки не нажаты |
«лифт перегружен» |
Пуст (стоит) |
«лифт вызван с другого этажа» |
«лифт вызван с текущего этажа» |
|
|
Перегружен (стоит) |
|
«нет перегрузки» |
|
Лифт готов, но перегружен |
Отсутствие средств представления характеристик объектов, реализующих процессы и потоки, делает невозможным применение данной технологии при объектно-ориентированной разработке информационной системы.
Выводы
Для решения сложных проблем используются методы системного анализа, предоставляющие в распоряжение аналитика визуальные графоаналитические средства для построения моделей бизнес-систем и бизнес-процессов.
Технология системно-структурного анализа 3VM позволяет представить модель системы в виде трех взаимосвязанных диаграмм: функциональной (потоков данных – DFD), информационной (сущность-связь – ERD), динамической (переходов состояний – STD).
Данная технология является весьма полезным средством в случае автоматизации и разработки программных средств методами и языками процедурного программирования. Применение данной технологии при объектно-ориентированной разработке информационной системы нецелесообразно.