- •«Белгородский государственный национальный исследовательский университет»
- •Теория систем и системный анализ
- •Предисловие
- •Содержание
- •Тема 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-диаграммы с помощью уфо-модели.
- •Глоссарий
- •Список литературы
4.2.3. Пример uml-модели бизнес-системы
В качестве примера анализируемой и моделируемой бизнес-системы рассмотрим систему «Ресторан», аналогично примеру, использованному в работе [97]. В целях конкретизации задачи предполагается, что анализ и моделирование осуществляются с целью проектирования информационной системы поддержки реинжиниринга подобного вида организаций, которая должна использовать модель существующего бизнеса. Диаграммы выполнены с помощью инструментального пакета Rational Rose.
На рисунке 4.15 представлена внешняя модель (П-модель) бизнес-системы «Ресторан», описывающая функции ресторана по отношению к его клиентам и поставщикам. Данная модель является UML-диаграммой прецедентов или вариантов использования, выполненной с учетом отношений расширения и использования между прецедентами.
Рис. 4.15. - П-модель
(внешняя модель) бизнес-системы
«Ресторан».
На рисунках 4.16 и 4.17 представлена внутренняя модель (О-модель) бизнес-системы «Ресторан», описывающая типы объектов (классы) ресторана и взаимодействия между ними. Модель на рисунке 4.16 является UML-диаграммой классов для одного из вариантов использования бизнес-системы «Ресторан» (для прецедента «Обслуживание обеда/ужина»). Модель на рисунке 4.17 является UML-диаграммой кооперации между экземплярами (объектами) классов, представленных на диаграмме 4.16, т.е. для того же прецедента «Обслуживание обеда/ужина».
Рис. 4.16. - О-модель
(внутренняя модель) бизнес-системы
«Ресторан».
Диаграмма классов
для прецедента «Обслуживание обеда/ужина».
4.2.4. Пример модели информационного обеспечения бизнеса
Для обеспечения более глубокого понимания процесса объектного моделирования рассмотрим модель компьютеризированной системы организации товарооборота и обработки платежей, используемой в современных магазинах. Данная система, именуемая обычно терминальной системой розничной торговли, представляет собой устройство для считывания штрих-кода, подключенное к компьютеру, на котором функционирует программное обеспечение решающие задачи оформления продажи, денежных расчетов, связи с базой данных по товарам и т.д. Рассматриваемый пример с некоторыми исправлениями и уточнениями соответствует примеру, приведенному в работе [84]. Диаграммы выполнены с помощью инструментального пакета Rational Rose.
Рис. 4.17. - О-модель
(внутренняя модель) бизнес-системы
«Ресторан». Диаграмма
кооперации объектов для прецедента
«Обслуживание обеда/ужина».
На рисунке 4.18 представлена диаграмма прецедентов (вариантов использования) терминальной системы розничной торговли. Она показывает функции системы и взаимодействующих с ней людей (акторов), потребности (требования) которых выражены с помощью указанных прецедентов.
Рис. 4.18. - Диаграмма
прецедентов терминальной системы
розничной торговли.
В отличии от примера в работе [84], покупатели не рассматриваются в качестве акторов для моделируемой системы по той причине, что они фактически не взаимодействуют с данной компьютерной системой.
Ошибочного назначения акторов легко избежать, если построение диаграммы прецедентов начинать с выявления реально взаимодействующих с моделируемой системой людей или других систем (контекстных сущностей). При этом под взаимодействием следует понимать взаимодействие, которое может быть представлено в виде потока материальных или информационных элементов. Данное требование обусловлено тем, что только такое взаимодействие предъявляет к моделируемой системе реальные конкретные требования, в реализации которых и состоит процесс проектирования системы.
На рисунках 4.19 и 4.20 представлены диаграммы деятельности (активности) для прецедентов «Продать товар» и «Принять товар» соответственно. Данные диаграммы уточняют поток событий конкретного прецедента. Это уточнение необходимо для выявления классов и построения объектной модели.
В общем случае описание потока событий в прецеденте (в диаграмме деятельности) должно показывать начало и завершение прецедента, обрабатываемые в рамках прецедента сущности, а также исключительные ситуации, которые помечаются ссылками на другие прецеденты, которые расширяют данный прецедент или используются в нем. При этом разработка диаграммы прецедентов, уточняемой диаграммами деятельности (или текстовыми документами), должно осуществляться параллельно с разработкой диаграммы классов.
Рис. 4.19. - Диаграмма
деятельности для прецедента «Продать
товар».
Рис. 4.20. - Диаграмма
деятельности для прецедента «Принять
товар».
На рисунке 4.21 представлена диаграмма классов бизнес-процесса розничной торговли с использованием компьютерной терминальной системы. Эта диаграмма, в отличие от предыдущих, нуждается в некотором комментарии.
Рис. 4.21. - Диаграмма
классов для бизнес-процесса розничной
торговли с применение компьютерного
терминала.
Целью построения данной диаграммы является выявление и документирование типов «сущностей», с помощью которых может быть описана моделируемая система. Если есть необходимость (для обеспечения, например, лучшего взаимопонимания с заказчиком), то номенклатура этих сущностей может быть расширена до описания фрагмента соответствующей предметной области. Поэтому диаграмма классов представляет собой концептуальную модель предметной области и не является моделью собственно проектируемой системы. В связи с этим в виде диаграммы классов, как правило, в первую очередь, описываются сущности (абстракции), имеющие непосредственное отношение к предметной области (в данном случае розничной торговли), т.е. к бизнес-логике.
Отсутствие в арсенале ООА каких-либо конструктивных методов выявления абстракций, необходимых для решения задачи, вынуждает аналитиков и проектировщиков использовать опыт, интуицию и субъективные мнения о предметной области. Это и зафиксировано в представленной на рис. 64 диаграмме. Однако, по мнению автора, в ней представлены все сущности, функциональные свойства которых могут обеспечить реализацию прецедентов «Продать товар» и «Принять товар». Названные функциональные свойства представлены в виде операций классов. Они позволяют экземплярам этих классов (объектам) выполнять функции в соответствии с диаграммой деятельности самостоятельно, а также путем передачи друг другу сообщений (параметров) для вызова (инициализации) необходимых функций.
Данная диаграмма является воплощением специфики объектного подхода к моделированию, так как именно она представляет в распоряжение аналитиков и разработчиков естественное средство описания свойств составных частей будущей информационной (или организационной) системы – концептуальную классификационную модель сущностей предметной области и самой системы. Именно на основе информации, заложенной в данной диаграмме, осуществляются анализ и моделирование проектируемой (разрабатываемой) системы.
На рисунке 4.22мичы с представлена диаграмма кооперации, реализующая бизнес-процесс (прецедент) «Продать товар». Данная диаграмма уже является собственно моделью проектируемой системы, так как описывает функциональное взаимодействие объектов (экземпляров классов), обеспечивающее получение результатов, требуемых в рамках данного прецедента. Как видно из представленной диаграммы объекты, взаимодействуя между собой, обеспечивают реализацию потока событий в прецеденте «Продать товар». Это достигается путем сообщения (посылки) экземпляром Кассира необходимых параметров (Код товара, Количество товара, Деньги покупателя) объектам системы. Эти сообщения вызывают у объектов проводник: Элемент продажи, счетчик функционирование соответствующих методов. Все объекты, кроме того, умеют вызывать методы других объектов, в соответствии со свойствами, описанными в диаграмме классов. Эти вызовы в соответствии с проставленными номерами обеспечивают выполнение необходимых функций.
При этом необходимо иметь в виду, что нас, в первую очередь, интересует модель бизнес-логики этого прецедента, а не реализация программной системы. Это позволяет опустить некоторые дополнительные подробности языка моделирования (например: роли ассоциаций, идентификаторы объектов), используемые при детальном проектировании собственно программных систем.
Рис. 4.22. - Диаграмма
кооперации для прецедента «Продать
товар».
Диаграмма кооперации (рис. 4.22) может быть автоматически преобразована в Rational Rose в диаграмму последовательности. Результата такого преобразования представлен на рисунках 4.23 – 4.24.
Таким образом, объектно-ориентированная методология, использующая стандартный язык UML, предоставляет полезные средства анализа и моделирования как информационных, так и организационных систем. При этом используется три вида моделей, аналогичных по своему предназначению трем моделям технологии 3VM или стандартам IDEF [84, 105]:
Модель состояния, которая представляет статический взгляд на структуру и состав элементов системы. Основными средствами визуализации этой модели являются диаграммы классов и объектов.
Рис. 4.23. - Диаграмма
последовательности «Продать товар»
(начало).
Рис. 4.24. - Диаграмма
последовательности «Продать товар»
(окончание).
Модель поведения, которая представляет операционный взгляд на систему и показывает действия осуществляемые ее элементами. Основными средствами визуализации этой модели являются диаграммы прецедентов, деятельности, взаимодействия.
Модель изменения состояния, которая представляет динамический взгляд на систему и показывает эволюцию элементов во времени. Основными средствами визуализации этой модели являются диаграмма состояний.
В отличие от функциональной декомпозиции системных структурных методов при данном подходе используется объектная декомпозиция, учитывающая в определенной степени и поведение объектов. Однако, в основном, оно ориентировано на поведение элементов программных систем, что ограничивает возможности применения этой методологии для моделирования бизнес-процессов. Кроме того, как и в методах системного структурного анализа, в рамках объектно-ориентированного анализа отсутствуют реальные возможности имитации функционирования моделируемой системы.
Выводы
При разработке модели бизнеса как в ходе прямого, так и в ходе обратного инжиниринга, согласно рассматриваемой методологии, рекомендуется создавать две модели организации: внешнюю (П-модель) и внутреннюю (О-модель).
П-модель – средство как для описания требований к бизнесу, так и для представления наглядной картины того, что бизнес выполняет. Тем не менее, П-модель не дает ясной картины о внутреннем устройстве бизнеса. Она ничего не говорит о том, как различные виды деятельности реализуют бизнес-процессы.
О-модель описывает, как строится каждый бизнес-процесс предприятия из различных рабочих задач (внутренних процессов) и какие ресурсы он использует.
В бизнес-модели необходимо отображать: процессы, т.е. структурированный, измеряемый набор действий, осуществляемый для того, чтобы произвести определенный выход для конкретного клиента на рынке; ресурсы, т.е. как внутренний процесс реализуется при помощи человеческих или технических ресурсов и откуда эти ресурсы будут взяты; продукцию, которая должна иметь характеристики, описывающие, что с ней можно делать; потоки событий (входные данные из внешнего мира; действия (операции) процесса, которые он производит над исходными данными; потребляемые ресурсы; решения, которые будут приняты, и выход (результат), который процесс отправит во внешний мир.