Прецедентная модель бизнеса с помощью языка моделирования uml описывает

1. Классификация моделей

Часть 2. Моделирование
Тема 2.1. Требования к моделям бизнес-процессов
Классификация моделей
Модель есть отображение (представление) объекта, системы или понятия в
некоторой форме, отличной от формы их реального существования
Модели
Из реальных объектов
(макеты, тренажеры)
Математические
закономерности
не учитывают
временной параметр
Реальные
Абстрактные
Формальные
Семантические
Статические
Динамические
Созданные средствами
мышления
Сохраняется смысл
(схемы, диаграммы)
отображают поток
событий

2. Состав модели бизнеса

Часть 2. Моделирование
Тема 2.1. Требования к моделям бизнес-процессов
Состав модели бизнеса
1. Функция компании во внешнем мире: описание окружения, основные
бизнес-процессы, а также взаимодействие процессов с окружением
2. Описание бизнес-процессов, отдельных шагов процессов (функций,
работ, операций).
3. Описание объектов, участвующих в выполнении бизнес-процессов
или обрабатываемых, создаваемых бизнесом и отношений между
объектами.
Требования к методологиям моделирования бизнеса:
• методология должна позволять строить понятные и обозримые модели;
• лучше использовать интегрированную методологию;
язык описания модели должен быть выразителен, но достаточно
формализован;
желательно, чтобы методология поддерживалась инструментальными
компьютерными системами

3. Объектно-ориентированный язык UML

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Объектно-ориентированный язык UML
Язык UML был разработан для создания моделей информационных систем (ИС)
с целью их последующей реализации в виде объектно-ориентированных программ.
Все представления о модели сложной системы фиксируются в виде диаграмм специальных графических конструкций (схем, графов).
Имеется 8 основных типов диаграмм UML, отражающих различные аспекты:
процессы, выполняемые системой (предоставляемые пользователю сервисы),
последовательность выполняемых системой алгоритмических операций,
структуру программных объектов (состав атрибутов и процедур),
их взаимодействие (обмен сообщениями) и т.д.
В технологии РБП язык UML применяется не только и не столько для создания ИС,
сколько для анализа и перепроектирования бизнес-процессов:
вместо моделей процессов ИС строятся модели бизнес-процессов,
вместо программных объектов в моделях отражаются объекты бизнес-процессов
(исполнители, продукция, услуги и т.д.),
вместо окружения ИС (пользователей ИС) моделируется окружение бизнеса
(поставщики, партнеры, клиенты).

4. Прецедентная модель бизнес-процесса

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Прецедентная модель бизнес-процесса
Внешняя диаграмма – диаграмма вариантов использования
(Use Case Diagram )
продукт
Распространитель
Актор
Маркетинг и
сбыт
сырье
Производство
Поставщик
продукт
Продажа
продукта
Клиент
проект
Партнер
Разработка
продукта
сервис
Сервисное
обслуживание
Прецедент

5. Прецедентная модель бизнес-процесса

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Прецедентная модель бизнес-процесса
Прецедентом (вариантом использования) в UML называется законченная
совокупность действий моделируемой системы, начинающаяся при
получении стимула извне и заканчивающаяся предоставлением некоторого
продукта или сервиса актору – пользователю системы .
Экземпляр прецедента – конкретный прецедент,
класс прецедентов — обобщенный прецедент.
Акторами (субъектами) в модели бизнеса являются элементы окружения –
клиенты, партнеры, поставщики.
Класс акторов описывает общие характеристики некоторого типа акторов,
экземпляр – характеристики конкретного актора.
Между прецедентами и акторами могут быть установлены отношения
коммуникации (communicate).
Они отражают взаимосвязи прецедентов с окружением (материальные,
энергетические и информационные потоки).

6. Поток событий прецедента

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Поток событий прецедента
Поток событий — описание прецедентов последовательностью шагов
Поток событий прецедента «Продажа продукта»:
1. Продавец получает заявку клиента
2. Если в заявке указан готовый продукт, то Продавец проверяет наличие
продукта на складе. Если продукта нет в наличии, прецедент заканчивается.
Если продукт есть на складе, то прецедент продолжается с шага 6.
3. Если в заявке указывается заказной продукт, то Продавец формирует заказ и
передает его Изготовителю продукта.
4. Изготовитель изготавливает продукт в соответствии с требованиями клиента и
сообщает о готовности Продавцу.
5. Изготовитель отправляет продукт на Склад.
6. Продавец сообщает Клиенту о готовности продукта и принимает от Клиента
оплату.
7. Продавец сообщает Отправителю количество продукта и адрес клиента и
заказывает транспорт.
8. Отправитель получает продукт со склада и доставляет его клиенту.

7. Диаграмма деятельности (Activity diagram)

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Диаграмма деятельности (Activity diagram)
Получить заявку
Проверить заявку
Указан готовый продукт
Указан заказной продукт
Проверить
наличие на складе
Нет продукта
Передать заказ
изготовителю
Изготовить продукт
имеется
Отправить на склад
Принять оплату
Заказать транспорт
Доставить продукт

8. Структурирование прецедентов

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Структурирование прецедентов
Первый способ — использовании отношения включения (include).
Диаграмма вариантов использования
<include>
Получить заявку
Проверить заявку
Указан готовый
продукт
Проверить
наличие на
складе
Указан заказной
продукт
Передать заказ
изготовителю
Изготовить
продукт
Нет
продукта
имеется
Отправить
на склад
Клиент
Диаграмма
деятельности
прецедента
«Продажа
продукта»
Продажа продукта
Исполнение заказа
Получить заявку
Диаграмма
деятельности
прецедента
«Исполнение
заказа»
Проверить заявку
Указан готовый продукт
Проверить
наличие на складе
Нет
продукта
Указан
заказной
продукт
Исполнение
заказа
имеется
Принять оплату
Принять оплату
Заказать транспорт
Заказать транспорт
Доставить продукт
Доставить продукт
Передать заказ
изготовителю
Изготовить
продукт
Отправить на
склад

9. Структурирование прецедентов

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Структурирование прецедентов
Второй способ — использовании отношения обобщения (generalization)
Диаграмма деятельности
прецедента «Продажа
готового продукта»
Диаграмма вариантов
использования
Диаграмма деятельности
прецедента «Продажа
заказного продукта»
Клиент
Получить заявку
на готовый
продукт
Проверить
наличие на
складе
Нет
продукта
имеется
Принять оплату
Получить заявку
на заказной
продукт
Передать заказ
изготовителю
Изготовить
продукт
Отправить на
склад
Принять оплату
Заказать
транспорт
Заказать
транспорт
Доставить
продукт
Доставить
продукт
Продажа готового
продукта
Диаграмма деятельности
прецедента «Продажа
готового продукта»
Получить заявку
на готовый
продукт
Проверить
наличие на
складе
Нет
продукта
имеется
Общий вид
продаж
Общий вид
продаж
Диаграмма
деятельности
прецедента «Общий
вид продаж»
Принять
оплату
Заказать
транспорт
Доставить
продукт
Продажа заказного
продукта
Диаграмма деятельности
прецедента «Продажа
заказного продукта»
Получить заявку на
заказной продукт
Передать заказ
изготовителю
Изготовить продукт
Отправить на склад
Общий вид
продаж

10. Объектная модель бизнес-процесса

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Объектная модель бизнес-процесса
Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для
реализации прецедентов и каким образом они взаимодействуют.
Объекты представляют участников процессов (исполнителей, менеджеров) и
различного рода сущности (продукцию, предметы, задачи и т.д.).
Участники процессов называются активными объектами, сущности – пассивными.
Классы объектов описывают общие характеристики некоторого типа объектов,
экземпляры описывают характеристики конкретного объекта.
Выделяют следующие категории (роли) объектов:
1. Интерфейсные (Boundary) – активные объекты, взаимодействующие с
окружением, т.е. с акторами. Примеры – Продавец, Регистратор, Секретарь..
2. Управляющие (Control) – активные объекты, участвующие в выполнении
процессов, но не имеющие контакта с окружением. Примеры – Разработчик
продукции, Изготовитель, Менеджер проекта..
3. Объекты-сущности (Entity) – пассивные объекты, которые обрабатываются
бизнесом. Примеры – Продукция, Заказ, Извещение.

11. Статическая диаграмма взаимодействия

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Статическая диаграмма взаимодействия
Диаграмма кооперации (Collaboration Diagram)
2: передача заказа
Продавец /и
1: подача заявки
5: сообщение
6: оплата
10: доставка
создает
3: сообщение о
готовности
использует
создает
использует
Заказ /с
7: заказ
транспорта
Клиент
Изготовитель /у
4: отправка
продукта
Продукт /с
доставляет
хранит
8: запрос
Отправитель /и
Склад /у
9: отгрузка
— отношение сообщения (message)
— отношение связи (link)

12. Динамическая диаграмма взаимодействия

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Динамическая диаграмма взаимодействия
Диаграмма последовательности (Sequence Diagram)
Продавец
Изготовитель
Склад
Отправитель
Клиент
Подача
заявки
Передача заказа
Сообщение о
готовности
Сообщение
Оплата
Отправка
продукта
Заказ транспорта
Запрос
Отгрузка
Доставка продукта

13. Описание объектов

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Описание объектов
Описание объекта состоит из 2х частей: описание свойств и поведения.
Для описания свойств используется диаграмма классов (Class diagram)
Отношение
обобщения
Атрибуты
Заказ
Документ
Клиент: Class
Продукт: Class
<include>
Отношение
включения
Клиент
ФИО: String
Адрес: String
Номер: Integer
Дата: String
<include>
Продукт
Наименование: String
Количество: Integer
Цвет: String

14. Описание объектов

Часть 2. Моделирование
Тема 2.2. Моделирование бизнеса на языке UML
Описание объектов
Описание поведения объекта заключается в выявлении всех его обязательств
Продажа заказного продукта
Продавец
подача заявки
сообщение
оплата
передача заказа
сообщение о
готовности
Все виды продаж
Продавец
подача заявки
заказ транспорта
запрос на склад
Продажа готового продукта
Продавец
подача заявки
сообщение
оплата
запрос на склад
сообщение о
наличии
заказ транспорта
передача заказа
сообщение
оплата
сообщение о
готовности
сообщение о
наличии
заказ транспорта

15. IDEF0-модель бизнес-процесса

Часть 2. Моделирование
Тема 2.2. Моделирование по методологии IDEF
IDEF0-модель бизнес-процесса
Диаграмма А-0 «Продажа заказного продукта»
Сроки
( )
Заявка
Инструкции
( )
Продажа
заказного
продукта
Деньги
Материалы
Транспорт
Оборудование
Продавец
Изготовитель
Отправитель
Склад
Доставленный
продукт

16. IDEF0-модель бизнес-процесса

Часть 2. Моделирование
Тема 2.2. Моделирование по методологии IDEF
IDEF0-модель бизнес-процесса
Диаграмма первого уровня
I1
заявка
I3
I2
Получить
заявку
А1
материалы
деньги
M1
продавец
заказ
адрес клиента
описание продукта
готовый продукт
Изготовить и
информация о
хранить
выполнении
продукт
А2
Получить
оплату
А3
M5
оборудование
M3
M2 склад
изготовитель
информация
об оплате
Доставить
продукт
А4
M4
отправитель
доставленный
продукт
M5
транспорт
O1

17. Функционально-стоимостной анализ бизнес-процесса

Часть 2. Моделирование
Тема 2.2. Моделирование по методологии IDEF
Функционально-стоимостной анализ
бизнес-процесса
Функционально-стоимостной анализ (ФСА, Activity Based Costing — ABC)
позволяет проанализировать себестоимость бизнес-процессов
Стоимостные объекты — выходы функциональных блоков IDEF0-модели.
Стоимость выходов равна стоимости выполнения соответствующей функции.
Стоимость выполнения функции определяется через стоимость используемых
ресурсов, представленных как входные дуги, дуги управления и механизмов
График работ
Сырье
Изготовление
изделия
Ресурсы
Оборудование
Персонал
Готовое
изделие
Стоимостной
объект

18. Функционально-стоимостной анализ бизнес-процесса

Часть 2. Моделирование
Тема 2.2. Моделирование по методологии IDEF
Функционально-стоимостной анализ
бизнес-процесса
Определение стоимости родительского блока через стоимости дочерних блоков
Рабочая сила = 6500
Оборудование = 3000
Материалы = 2500
Общая стоимость = 12000
Изготовление
изделия
Рабочая сила = 3000
Оборудование = 1500
Материалы = 2500
Общая стоимость = 7000
Изготовление
деталей
Рабочая сила = 2000
Оборудование = 1000
Материалы = 0
Общая стоимость = 3000
Сборка
изделия
Контроль
качества
Рабочая сила = 1500
Оборудование = 500
Материалы = 0
Общая стоимость = 2000
Центры
стоимости

Статья написана на основе лекций «Моделирование и анализ бизнес-процессов» профессора Томского государственного университета систем управления и радиоэлектроники, Силич Марии Петровны.

Классификация моделей

Понятие модели

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

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

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

Модель внешнего вида часов

Структурная схема часов

Виды подобия: прямое (макет, фотография), косвенное (подобие по аналогии), условное (на основе соглашений).

Процесс моделирования имеет свойство динамичности: модели развиваются, уточняются, переходят одна в другую.

Классификация моделей

Познавательные (объяснительные) модели отражают уже существующие объекты.

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

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

Материальные модели построены из реальных объектов.
Абстрактные модели — это идеальные конструкции, выполненные средствами мышления, сознания.

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

Детерминированные модели отражают процессы и явления, не подверженные случайностям.
Стохастические – отражают случайные процессы, описываемые вероятностными характеристиками и статистическими закономерностями.

Формализованные модели могут не иметь смысловой интерпретации.
В содержательных моделях сохраняется семантика моделируемого объекта.

Языки описания моделей

Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические.

Графические модели (схемы, диаграммы, графики, чертежи) – наглядны.
Нотация — система условных обозначений (знаков) и правил их использования, принятая в конкретной методологии.

Требования к нотации:

• простота — простой знак предпочтительнее сложного;
• наглядность — хотя бы отдаленное сходство с оригиналом;
• индивидуальность — достаточное отличие от других обозначений;
• однозначность — нельзя обозначать одним символом различные объекты;
• определенность — четкие правила использования модели;
• учет устоявшихся традиций.

Содержание модели бизнеса

В модели бизнеса отражают:

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

Методы моделирования бизнеса

Структурные методы

Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.

Принципы структурного подхода:

• «разделяй и властвуй» — разбиение сложных проблем на множество меньших задач, легких для понимания и решения;
• иерархическое упорядочивание – организация составных частей проблемы в иерархические древовидные структуры.

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

Наибольшее распространение получили методологии:

• IDEF0 – функциональные модели, основанные на методе SADT;
• IDEF1X – диаграммы данных «сущность-связь» (ERD);
• IDEF3 — диаграммы потоков работ (Work Flow Diagrams);
• DFD — диаграммы потоков данных (Data Flow Diagrams).

Методы объектно-ориентированного моделирования

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

Наиболее известные методы:

• Booch’93 Г. Буча,
• OMT Дж. Румбаха
• OOSE А. Джекобсона
• UML (Unified Modeling Language) – на основе Booch’93, OMT, OOSE

Главным структурообразующим элементом является объект.
В программировании объект — это структура, объединяющая данные и процедуры.
В модели бизнеса объекты – это участники бизнес-процесса (активные объекты) и пассивные объекты (материалы, документы), над которыми выполняют действия активные объекты.

Методы имитационного моделирования

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

Наиболее распространенные методы:

• сети Петри и раскрашенные сети Петри (CPN, Colored Petri Nets);
• GPSS (General Purpose Simulating System) – унифицированный язык имитационного моделирования;
• SIMAN (SIMulation ANalysis) – язык визуального моделирования.

Интегрированные методы

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

• ARIS (Architecture of Integrated Information System) позволяет отражать в единой интегрированной модели: оргструктуры, функции, данные, процессы. Использует множество типов моделей.
• G2 — методология создания динамических интеллектуальных систем позволяет моделировать процессы с использованием знаний эксперта.
• BRM (Business Rules Management) – методология управления бизнес-правилами.

Структурные методологии

Методология IDEF0

Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.
IDEF0-модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).

Основные элементы модели:

• Функциональный блок (Activity) – преобразование (активность);
• Выходы (Output) – результат преобразования;
• Входы (Input) — объекты, которые преобразуются в Выходы;
• Управление (Control) — информация, как происходит преобразование;
• Механизм (Mechanism) – объекты, осуществляющие преобразование.

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

Таким образом, IDEF0-модель состоит из набора иерархически связанных диаграмм
На диаграмме блоки соединяются дугами: выходные дуги одних блоков могут являться входами (управлением, механизмом) других.
Дуги с одним свободным концом имеют источник или получатель вне диаграммы. Для обозначения внешних дуг используются буквы:

• I (Input),
• C (Control),
• O (Output) и
• M (Mechanism).

Типы связей между блоками:
Выход-вход

Выход-управление

Выход-механизм

Обратная связь по управлению

Обратная связь по входу

Методология IDEF3

IDEF3-модели используются для документирования технологических (информационных) процессов, где важна последовательность выполнения процесса

Выделяют четыре элемента IDEF3-модели:
Единица работы — отображают действия, процессы, события, этапы выполнения работ. Единица работы может иметь только один вход и один выход

Ссылки (Referents):
необходимые элементы для выполнения процесса (сырье, материалы);
результат процесса (изделие);
активаторы процесса (клиент, поставщик).

Связи (Links), которые бывают двух типов:
передают действия от одной единицы работ к другой

соединяют ссылку с единицей работ (активируют единицу работ)

Перекрестки (Junctions) – элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса.
Бывают двух видов:
перекрестки слияния – Fan-in

перекрестки ветвления – Fan-out

Типы перекрестков

Асинхронное И (Asynchronous AND)
выходной процесс запустится, если завершились все входные процессы

после завершения входного процесса запустятся все выходные процессы

Синхронное И (Synchronous AND)
выходной процесс запустится, если завершились одновременно все входные процессы

после завершения входного процесса запустятся все выходные процессы, причем запустятся одновременно

Асинхронное ИЛИ (Asynchronous OR)
выходной процесс запустится, если завершится один или несколько входных процессов

после завершения входного процесса запустятся один или несколько выходных процессов

Синхронное ИЛИ (Synchronous OR)
выходной процесс запустится, если завершились один или несколько входных процессов, причем завершились одновременно

после завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно

Исключающее ИЛИ (XOR, Exclusive OR)
выходной процесс запустится, если завершился только один входной процесс

после завершения входного процесса запустится только один выходной процесс

Пример IDEF3

Правила создания перекрестков

1. Каждому перекрестку слияния должен предшествовать перекресток ветвления.
2. Перекресток слияния «И» не может следовать за перекрестком ветвления типа синхронного, асинхронного или исключающего «ИЛИ».
3. Перекресток слияния типа исключающего «ИЛИ» не может следовать за перекрестком ветвления типа «И».
4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
5. Перекресток не может быть одновременно перекрестком слияния и ветвления. В ситуации, когда необходимо одновременно осуществить слияние и разветвление потоков работ, вводится каскад перекрестков.

Правило относительно единиц работ

В блок может входить и из блока может выходить только одна связь последовательности. Для отображения множества входов и выходов используются перекрестки.
Разрешается множественная декомпозиция работ:
для одной и той же работы может быть создано несколько диаграмм декомпозиции (для описания разных вариантов реализации работы).

Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.

Методология DFD

Диаграммы потоков данных DFD позволяют эффективно и наглядно описать процессы документооборота и обработки информации.
Используются две нотации: Йордана и Гейна-Сарсона

Типы структурных элементов (в нотации Гейна-Сарсона):
1. Процессы (функции, операции, действия), которые обрабатывают и изменяют информацию. Процессы показывают, каким образом входные потоки данных преобразуются в выходные

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

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

4. Внешние сущности — определяют внешние элементы, которые участвуют в процессе обмена информацией с системой. Внешние сущности изображают входы в систему (источники информации) и/или выходы из системы (приемники информации). Примеры: заказчик, персонал, поставщик, клиент, склад, банк

Пример:

Язык UML был разработан для создания моделей информационных систем (ИС) с целью их последующей реализации в виде объектно-ориентированных программ.
Все представления о модели сложной системы фиксируются в виде диаграмм -специальных графических конструкций (схем, графов).
Имеется 8 основных типов диаграмм UML, отражающих различные аспекты: процессы, выполняемые системой (предоставляемые пользователю сервисы), последовательность выполняемых системой алгоритмических операций,
структуру программных объектов, их взаимодействие (обмен сообщениями) и т.д.

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

Прецедентная модель бизнеса

Отражает основные бизнес-процессы, их взаимодействие с окружением.
Начинается с построения внешней диаграммы (вариантов использования — Use Case Diagram), показывающей, как бизнес виден извне

Актор (действующее лицо, business actor) — субъект окружения бизнеса. Примеры акторов: Клиент, Покупатель, Поставщик, Партнер, Акционер, Заказчик.

Прецедент (вариант использования, business use case) — относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному актору .
Примеры прецедентов: Производство продукта Продажа продукта, Сервисное обслуживание, Разработка продукта, Маркетинг и сбыт.

Экземпляр (реализация) прецедента – конкретный вариант хода событий класс прецедентов — обобщенный прецедент.

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

Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate).
Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки)
Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend).

Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.

В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов

Поток событий прецедента

Поток событий — описание прецедентов последовательностью шагов

Поток событий прецедента «Продажа продукта»:

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

Диаграмма деятельности (Activity Diagram)

Элементы диаграммы деятельности

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

Структурирование прецедентов

Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
1. Выделение фрагментов
Если из описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент. Между выделенным прецедентом и базовым устанавливается отношения включения (include).
Иногда используют отношение расширения (extend). Оно устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.

2. Обобщение
Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский). Между каждым из частных прецедентов и родительским устанавливается отношение обобщения (generali-zation).

Объектная модель бизнес-процесса

Раскрывает внутреннее устройство бизнеса: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют.
Классы объектов модели бизнеса:
активные — исполнители процессов (стереотип business worker), например, Продавец, Изготовитель, Разработчик;

пассивные — сущности (стереотип business entity), например, Продукт, Заказ, Счет.

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

Классы и объекты

Класс – некоторый тип объектов (множество похожих объектов),
Экземпляр – конкретный объект (представитель класса).

Объекты имеют:
имя (через двоеточие может быть указано имя класса)
свойства — описываются с помощью атрибутов
поведение — представляется с помощью операций

У объектов одного класса состав атрибутов и операций одинаков.
Они отличаются значениями атрибутов, т.к. экземпляры классов описывают характеристики конкретного объекта.

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

Динамическая диаграмма взаимодействия

Прецедент «Продажа заказного продукта»:
Продавец получает заявку клиента
Продавец формирует заказ и передает его Изготовителю продукта.
Изготовитель изготавливает продукт.
Изготовитель отправляет продукт на Склад и сообщает о готовности Продавцу.
Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату.
Продавец сообщает Отправителю адрес клиента и заказывает транспорт.
Отправитель получает продукт со склада и доставляет его клиенту.

Элементы диаграммы последовательности

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

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

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

Статическая диаграмма взаимодействия

Диаграмма кооперации (Collaboration Diagram)

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

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

Для структурирования классов используются отношения обобщения и включения

Описание объектов

Спецификация объекта состоит из описания свойств (атрибутов) и поведения (обязательств, операций).

Интегрированная методология ARIS

Методология ARIS (Architecture of Integrated Information System) разработана в 1990-х годах профессором А.-В. Шеером

Для каждого из этих представлений можно построить несколько типов моделей (в ARIS 5.0 общее количество типов диаграмм — 130)

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

• организационные модели — структура организации (иерархия подразделений и должностей);
• функциональные модели — иерархия функций (целей), выполняемых в организации;
• информационные модели — структура информации, необходимой для реализации функций системы;
• модели процессов/управления — комплексный взгляд на реализацию деловых процессов в рамках системы

Организационная схема

К организационным моделям относится Организационная схема (Organizational chat).
Основные типы объектов этой модели:

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

Дерево функций

К функциональным моделям относится Дерево функций (Function Tree).

Используется только один тип объекта — функция (работа, действие, этап в рамках процесса).
На верхнем уровне функции представляют собой бизнес-процессы. Детализация функций образует иерархическую структуру.
Самый нижний уровень представляют базовые функции (которые уже не могут быть разделены на составные элементы).

Событийная цепочка процесса

К моделям процессов/управления относится Диаграмма eEPC (extended Event driven Process Chain)

Основные типы объектов:

Элементы диаграммы eEPC

• Функция – некоторое (шаг процесса). С функцией могут быть связаны: исполнители, входные и выходные документы, программное обеспечение и т.д.
• Событие — какое-либо завершенное состояние объекта, которое влияет на дальнейший ход процесса. С одной стороны события являются стимулом к выполнению функций, с другой – их результатом.
• Логические операторы (И, ИЛИ, XOR) показывают разветвления в потоке процесса.

Примеры:

Интеграция моделей

Взаимосвязь моделей ARIS обеспечивается с помощью двух механизмов: интеграции и детализации
1. Механизм интеграции
Благодаря хранению объектов в едином репозитории (специальной базе данных).
При создании нового объекта в репозитарии появляется отдельная запись, задающая описание объекта.
Объект можно скопировать из одной модели и вставить в другую с помощью команд Copy/Paste.

Детализация моделей

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

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

Инструментальные средства

Возможности инструментальных средств

• визуальное моделирование, позволяющее формировать графическую модель (в виде диаграмм, блок-схем, графов) в интерактивном режиме с использованием визуальных средств;
• проверка моделей – проверка соблюдения синтаксических и семантических правил построения моделей, определенных в используемой методологии моделирования;
• анализ построенных моделей – возможность просчитать стоимостные и временные характеристики процессов, проверить гипотезы «что, если …», выявить логические ошибки и т.д.;
• документирование – вывод представленной в моделях информации в виде текстовых описаний, содержащихся в файлах заданного формата;
• интеграция различных информационных систем – возможность обмениваться информацией о моделируемых процессах между различными приложениями;
• автоматическое создание компонент информационных систем – например, автоматическая кодогенерация (создание компьютерных программ), генерация баз данных на основе введенных моделей и диаграмм.

Использованная литература

1. Национальный исследовательский Томский политехнический университет. Томск. Силич М.П. 2016. 75 с. Презентация к лекции.

12. Этапы проектирования ИС с применением UML

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств – диаграмм. На этапе создания концептуальной модели для описания бизнес-деятельности используются модели бизнес-прецедентов и диаграммы видов деятельности, для описания бизнес-объектов – модели бизнес-объектов и диаграммы последовательностей. На этапе создания логической модели ИС описание требований к системе задается в виде модели и описания системных прецедентов, а предварительное проектирование осуществляется с использованием диаграмм классов, диаграмм последовательностей и диаграмм состояний. На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания. Ниже приводятся определения и описывается назначение перечисленных диаграмм и моделей применительно к задачам проектирования ИС (в скобках приведены альтернативные названия диаграмм, использующиеся в современной литературе). Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это обобщенная модель функционирования системы в окружающей среде. Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента. Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams). Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое. Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами. Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п. Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС. Диаграммы развертывания (диаграммы размещения, deployment diagrams) – модель физической архитектуры системы, отображает аппаратную конфигурацию ИС. На рис. 12.1 показаны отношения между различными видами диаграмм UML. Указатели стрелок можно интерпретировать как отношение «является источником входных данных для…» (например, диаграмма прецедентов является источником данных для диаграмм видов деятельности и последовательности). Приведенная схема является наглядной иллюстрацией итеративного характера разработки моделей с использованием UML. Рис. 12.1.  Взаимосвязи между диаграммами UML Ниже приводятся описания последовательных этапов проектирования ИС с использованием UML.

Разработка модели бизнес-прецедентов

Модель бизнес-прецедентов
описывает бизнес-процессы с точки зрения
внешнего пользователя, т.е. отражает
взгляд на деятельность организации
извне.

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

Исполнитель (Действующее лицо, Actor) –
личность, организация или система,
взаимодействующая с ИС; различают
внешнего исполнителя (который использует
или используется системой, т.е. порождает
прецеденты деятельности) и внутреннего
исполнителя (который обеспечивает
реализацию прецедентов деятельности
внутри системы). На диаграмме исполнитель
представляется стилизованной фигуркой
человека.

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

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

Ассоциация – связь между двумя элементами
модели. На диаграмме представляется
линией.

Обобщение – связь между двумя элементами
модели, когда один элемент (подкласс)
является частным случаем другого
элемента (суперкласса). На диаграмме
представляется стрелкой.

Агрегация – отношение между элементами
модели, когда один элемент является
частью другого элемента (агрегата). На
диаграмме представляется стрелкой с
ромбовидным концом.

Для иллюстрации этапов
разработки проекта использованы
адаптированные материалы проекта ИС
медицинского центра (рис.
12.2). Назначение
ИС – автоматизация ведения и использования
клинических записей о пациентах. В
настоящее время эта работа производится
вручную персоналом центра. На рис.
12.2 представлена
общая модель деятельности центра в виде
диаграммы прецедентов. Прецедент
«Обслуживание пациента»
реализуется через множество других,
более ограниченных прецедентов (рис.
12.3), отражающих
детализацию представления функционирования
центра.

Рис.
12.2.  Общая диаграмма
деятельности медицинского центра по
обслуживанию пациента

Рис.
12.3.  Модель
бизнес-прецедентов, составляющих
обслуживание пациента

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

• прецедент должен описывать,
  ЧТО
  нужно делать, а не КАК;

• прецедент должен описывать
  действия с точки зрения ИСПОЛНИТЕЛЯ;

• прецедент должен возвращать
  исполнителю некоторое СООБЩЕНИЕ;

• последовательность действий
  внутри прецедента должна представлять
  собой одну НЕДЕЛИМУЮ
  цепочку.

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

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

Рис.
12.4.  Диаграмма видов
деятельности для прецедента «Оказание
медицинской помощи»

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

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

Диаграмма подходит для описания действий
как внешнего, так и внутреннего специалиста
центра.

Этап завершается после
разработки диаграмм видов деятельности
для всех выделенных в модели
бизнес-прецедентов.
Естественно, на последующих этапах
анализа и проектирования будут выявлены
какие-то важные подробности в описании
деятельности объекта автоматизации.
Поэтому разработанные на данном этапе
модели будут еще неоднократно
корректироваться.

Соседние файлы в папке Лекции

• #
• #
• #
• #
• #
• #
• #
• #
• #

Разработка модели бизнес-прецедентов

Модель бизнес-прецедентов описывает бизнес-процессы с точки зрения внешнего пользователя, т.е. отражает взгляд на деятельность организации из вне.

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

Исполнитель (Действующее лицо, Actor) – личность, организация или система, взаимодействующая с ИС; различают внешнего исполнителя (который использует или используется системой, т.е. порождает прецеденты деятельности) и внутреннего исполнителя (который обеспечивает реализацию прецедентов деятельности внутри системы). На диаграмме исполнитель представляется стилизованной фигуркой человека.

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

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

Ассоциация – связь между двумя элементами модели. На диаграмме представляется линией.

Обобщение – связь между двумя элементами модели, когда один элемент (подкласс) является частным случаем другого элемента (суперкласса). На диаграмме представляется стрелкой.

Агрегация – отношение между элементами модели, когда один элемент является частью другого элемента (агрегата). На диаграмме представляется стрелкой с ромбовидным концом.

Для иллюстрации этапов разработки проекта использованы адаптированные материалы проекта ИС медицинского центра [
рис.
12.2]. Назначение ИС – автоматизация ведения и использования клинических записей о пациентах. В настоящее время эта работа производится вручную персоналом центра. На
рис.
12.2 представлена общая модель деятельности центра в виде диаграммы прецедентов. Прецедент » Обслуживание пациента » реализуется через множество других, более ограниченных прецедентов (
рис.
12.3), отражающих детализацию представления функционирования центра.

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

• прецедент должен описывать, ЧТО нужно делать, а не КАК ;
• прецедент должен описывать действия с точки зрения ИСПОЛНИТЕЛЯ ;
• прецедент должен возвращать исполнителю некоторое СООБЩЕНИЕ ;
• последовательность действий внутри прецедента должна представлять собой одну НЕДЕЛИМУЮ цепочку.

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

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

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

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

Диаграмма подходит для описания действий как внешнего, так и внутреннего специалиста центра.

Этап завершается после разработки диаграмм видов деятельности для всех выделенных в модели бизнес-прецедентов. Естественно, на последующих этапах анализа и проектирования будут выявлены какие-то важные подробности в описании деятельности объекта автоматизации. Поэтому разработанные на данном этапе модели будут еще неоднократно корректироваться.

UML (Unified Modeling Language — унифицированный язык моделирования) — это тип нотации, используемый для визуализации, определения, конструирования и документирования компонентов программных и непрограммных систем.

Краткая история

История создания языка программирования берет свое начало в 1967 году при появлении языка SimulaF67: он существенно отличается от современного, однако задает базовые идеи, которые существуют и сегодня. Официальное создание UML началось в 1994 году и первая версия 0.8 получила статус пробной.

В 1995 году концепция была расширена и дополнена языком OOSE. Таким образом повилась версия 0.9, с которой началось полноценное развитие UML, имеющего стратегическое значение для бизнеса.

Первая официальная всемирная версия UML появилась в январе 1997 года. Язык UML стал основой моделирования для различных классов систем и их программного обеспечения. Нотация начала применять объектно-ориентированные методы, обрела концептуальный, логический и физический уровни моделирования систем.

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

Плюсы и минусы методологии

Среди ключевых преимуществ модели выделим следующие характеристики:

1. UML — это объектно-ориентированный язык, поэтому методы, с помощью которых описываются результаты анализа и проектирования являются семантически идентичными к методам программирования на ключевых ОО-языках, используемых в современных технологиях.
2. С помощью UML можно описать ситуацию или ключевую задачу с различных точек зрения и аспектов поведения системы.
3. UML диаграммы простые в восприятии: прочитать схему и ознакомится с ее синтаксисом сможет даже работник, не имеющих специальных знаний в области программирования и постройки бизнес-моделей (речь идет о стандартных схемах с 20-40 условными обозначениями).
4. UML минимизирует процент возможных ошибок при создании бизнес-процесса. Например, она исключает несогласованность параметров дополнительных программ или изменение основных атрибутов.
5. Любой этап бизнес-процеса может быть использован повторно в уже существующем или новом проекте организации.
6. UML можно применять не только для решения вопросов программной инженерии, но и для введения собственных текстовых и графических стереотипов.
7. В отличие от аналогичных нотаций, UML стремительно развивается и получает широкое распространение в построении моделей различных сферах бизнеса.

Как и другие нотации, UML имеет недостатки:

1. Многие программисты используют современную версию нотации UML 2.0. Она характеризуется высокой избыточностью языка, содержит множество диаграмм и конструкций, которые не всегда важны при создании модели бизнес-процесса.
2. Применение объектно-ориентированного подхода требует наличия знаний о предметной области и методах анализа на языке программирования. Крупные проекты могут включать свыше 100 условных обозначений. В таком случае в команде должны быть специалисты, владеющие определенным уровнем квалификации и умеющие отходить от традиционных подходов к работе.

Типы сущностей

Нотации UML — это ключевые элементы для моделирования и визуализации бизнес-процессов. Если цель изображена некорректно, выбраны неправильные и малоэффективные обозначения, то модель считается бесполезной и не содержательной.

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

Структурные

Структурные сущности — это имена существительные, представленные в статистической части модели: они соответствуют как концептуальным, так и физическим элементам системы. Среди основных структурных элементов выделают:

• Классы используются для представления объектов (требуют ответственных и имеют конкретные свойства). Диаграмма визуально разделена на четыре части: верхняя позиция (1) называет класс, вторая — отображает его атрибуты и основные инструменты, третья — детализирует операции и процессы, конечная — содержит дополнительную информацию и является необязательной.
• Объекты (экземпляр класса) — процессы, являющиеся фактической реализацией класса. Графически изображены как предшественники, единственное отличие в том, что название дополнительно подчеркивается.
• Интерфейсы используются для описания функционала по соответствующим требованиям. Интерфейс является своеобразным шаблоном, в котором расписаны этапы бизнес-процессов без их фактической реализации. На схеме отображается кружком с соответствующим названием, указанным под обозначением.
• Сотрудничество — это условное обозначение ответственности: отвечает за распределение задач в группе и назначении ответственных, чьи имена будут вписаны внутри круга с пунктирным контуром.
• Случаи использования подразумевают ситуации, для которых применимы функциональные возможности высокого уровня системы. Графически вариант использования прописывается под фигурой с обозначением сотрудничества.
• Актер — внутренняя или внешняя сущность, которая используется для описания внутренних или внешних задач бизнес-процесса. Актер взаимодействует с системой и может быть обозначен на любом этапе схемы.
• Нотация начального состояния — отображает начало бизнес-процесса; конечная государственная запись — конец процесса и соответственно результат.
• Компонент — представляет объект системы, для которого была создана диаграмма UML. Графически отображается в виде прямоугольника, в котором указан исполнитель и название задачи.
• Нотация активного класса — представляет параллельность задач в системе и изображается в формате квадрата, разделенного на три блока: 1 — название класса, 2 — параллельные требования системы, требующие описания, 3 — операции и процессы.
• Узел обозначает физический компонент системы (использование сети, серверов или оборудования). На схеме представлен в виде куба, в котором указано название узла и исполнитель.

Поведенческие

К данном классу относятся динамические и составляющее модели UML — глаголы, описывающие поведение модели во времени и пространстве. Рассмотрим основные поведенческие сущности:

• Взаимодействие — это обмен сообщениями между двумя объектами или компонентами UML системы в рамах конкретного контекста для достижения определенной цели. Может быть последовательным (диаграмма последовательности) или совместным (диаграмма сотрудничества).
• Автомат — тип поведения, описывающий различные состояния компонента и их последовательности в жизненном цикле (ответе на определенные ситуации) бизнес-процесса. Состояние может быть активным, неактивным или любым другим в зависимости от контекста ситуации.

Группирующие

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

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

Аннотационные

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

Рассмотрим основные типы аннотационных сущностей:

• Примечание — это ключевой элемент, используемый для снабжения диаграмм комментариями или ограничениями, выраженными в виде неформального или формального текста. Графически отображено в виде прямоугольника с информацией, необходимой информации о системе.
• Зависимость применяется для отображения зависимых элементов и направлений между двумя элементами системы. На схемах представлена пунктирной стрелкой, где стрелка — это независимый элемент, а ее конец — наоборот, зависимый по отношению к ситуации.
• Ассоциация предоставляет информацию об отношениях между двумя элементами системы и характеризует общее количество элементов, применимых в диаграмме UML. Графически ассоциация отображена в виде пунктирной линии со стрелкой (или без), где оба конца представляют элементы, кратность которых представлена на концах схемы.
• Обобщение — это наследование родительских и дочерних отношений объектно-ориентированного мира между двумя элементами в системе. Графически отображается в виде стрелки с полым наконечником, где конец — это доминирующий, а начало — исполнительный элемент.

Виды диаграмм, используемых в Unified Modeling Language

В языке UML представлено 12 диаграмм, обуславливающих статистическую, поведенческую и физическую деятельность компонентов систем. Рассмотрим доступные и актуальные в современных бизнес-процессах диаграммы:

1. Диаграмма прецедентов (Use-case diagram). В основе — Actor (исполнитель), который устанавливает логические связи между ролями и прецедентами и Use case (сам прецедент), демонстрирующий какой именно процесс исполняется.
2. Диаграмма классов (Class diagram) представляет собой набор статических и декларативных элементов модели, имеющие общие атрибуты и операции. Диаграмма имеет наиболее полное и развернутое описание связей в программном коде, функциональности и информации об отдельных классах.
3. Диаграмма активностей (Activity diagram) отображает динамические аспекты поведения и общее представление о работе системы в формате блок-схемы. Диаграмма необходима для описания бизнес-процессов, взаимодействия нескольких систем, логики процедур и потоков работ, особенно при переходе от одной деятельности к другой.
4. Диаграмма последовательности (Sequence diagram) описывает поведенческие аспекты системы, вид сообщений и уточняет прецедентов. Необходима для отображения взаимодействия объектов в динамике и во времени, подразумевает обмен сообщениями в рамках конкретного сценария.
5. Диаграмма развёртывания (Deployment diagram) отображает графическое представление инфраструктуры, а именно распределение компонентов системы по узлам и маршруты их соединений. Диаграмма организовывает компоненты и решает второстепенные задачи, связанные с определенным аспектом бизнес-процесса.

Упрощение моделирования с помощью программного обеспечения

Для упрощения моделирования доступны разнообразные инструменты моделирования UML, а также разработанные ПО. Среди всех доступных возможностей, следует выделить IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner и Dia. Они обладают хорошим функционалом и широким спектром инструментов для построения диаграмм и рациональным распределением задач между исполнителями.

Вне зависимости от выбранного ПО, необходимо учитывать, что язык UML основывается на общих принципах моделирования, которыми не следует пренебрегать:

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

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

Для чего используется техника креативности

Определить функциональные требования к системе.

Описать типичные взаимодействия между пользователями системы и самой системой и предоставить описание процесса её функционирования.

План действий

В разделе «Описание» изучите основной набор символов диаграммы прецедентов, необходимый для того, чтобы уметь читать диаграммы.

После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм прецедентов.

Замечания (описание)

Здесь представлен основной набор символов диаграммы вариантов использования (прецедентов) , необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы вариантов использования системы (ВИС) самостоятельно!

Термин	Изображение	Описание
Сценарий	Вся диаграмма вариантов использования (ВИС)	Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы.
Актер		Актер (actor) представляет собой некую роль, которую пользователь играет по отношению к системе.
Прецедент		Обозначает выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам.
include (включает)		Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй.
Граница системы		Позволяет обозначить границы систем или подсистем.

Как применять технику креативности

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

Важно помнить, что прецеденты представляют взгляд на систему со стороны. А раз так, то не ждите какого -либо соответствия между прецедентами и классами внутри системы.
Чем больше прецедентов на диаграмме, тем менее ценной кажется диаграмма прецедентов. Несмотря на то что в языке UML ничего не говорится о тексте прецедентов, именно текстовое содержание прецедентов является основной ценностью этой технологии.

Большая опасность прецедентов заключается в том, что разработчики делают их очень сложными и застревают на них. Обычно чем меньше вы делаете, тем меньший вред можете нанести. Если у вас немного информации, то получится короткий, легко читаемый документ, который явится отправной точкой для вопросов. Если информации слишком много, то вряд ли кто-то вообще будет ее изучать и пытаться понять.

Как научиться

Пример использования

Прецеденты – это технология определения функциональных требований к системе. Работа прецедентов заключается в описании типичных взаимодействий между пользователями системы и самой системой и предоставлении описания процесса ее функционирования. Вместо того чтобы описывать прецеденты в лоб, я предпочитаю подкрасться к ним сзади и начать с описания сценариев. Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы. Поэтому при наличии онлайнового магазина, основанного на веб-сайте, мы можем использовать сценарий «Покупка товара» (Buy a Product), в котором происходит следующее.

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

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

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

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

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

Прецеденты считаются важной частью языка UML. Однако удивительно то, что определение прецедентов в UML довольно скудное. В UML ничего не говорится о том, как определять содержимое прецедента.
Все, что описано в UML, – это диаграмма прецедентов, которая показывает, как прецеденты связаны друг с другом. Но почти вся ценность прецедентов как раз в их содержании, а диаграмма имеет ограниченное значение.

Содержимое прецедентов

Не существует стандартного способа описания содержимого прецедента; в разных случаях применяются различные форматы. На рис. 9.1 показан общий стиль использования. Вы начинаете с выбора одного из сценариев в качестве главного успешного сценария (main success scenario). Сначала вы описываете тело прецедента, в котором главный успешный сценарий представлен последовательностью нумерованных шагов. Затем берете другой сценарий и вставляете его в виде расширения (extension), описывая его в терминах изменений главного успешного сценария. Расширения могут быть успешными – пользователь достиг своей цели, как в варианте 3a, или неудачными, как в варианте 6a.

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

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

Расширение внутри прецедента указывает условие, которое приводит к взаимодействиям, отличным от описанных в главном успешном сценарии (main success scenario, MSS), и устанавливает, в чем состоят эти отличия. Расширение начинается с имени шага, на котором определяется это условие, и предоставляет краткое описание этого условия.
Следуйте этому условию, нумеруя шаги таким же образом, что и в главном успешном сценарии. Заканчивайте эти шаги описанием точки возврата в главный успешный сценарий, если это необходимо.

Структура прецедента – это отличный инструмент для поиска альтернатив главного успешного сценария. На каждом шаге спрашивайте:
«Что может еще произойти?» и в частности «Что может пойти не так?»

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

Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй. Не существует стандартного способа показать в тексте включение прецедента, но я думаю, что подчеркивание, которое предполагает гиперссылку, работает прекрасно, а во многих инструментах действительно будет гиперссылкой. Так, на рис. 9.1 первый шаг включает шаблон «просматривает каталог и выбирает товары для покупки».

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

Наряду с шагами сценария можно вставить в прецедент дополнительную общую информацию.
• Предусловие (pre-condition) описывает действия, обязательно выполняемые системой перед тем, как она разрешит начать работу прецедента. Это полезная информация, позволяющая разработчикам не проверять некоторые условия в их программе.
• Гарантия (guarantee) описывает обязательные действия системы по окончании работы шаблона ответа. Успешные гарантии выполняются после успешного сценария; минимальные гарантии выполняются после любого сценария.
• Триггер (trigger) определяет событие, инициирующее выполнение прецедента.

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

Диаграммы прецедентов

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

Лучше всего обдумывать диаграмму прецедентов с помощью графической таблицы, показывающей их содержимое. Она напоминает диаграмму контекста, используемую в структурных методах, поскольку она показывает границы системы и ее взаимодействие с внешним миром. Диаграмма прецедентов показывает актеров, прецеденты и отношения между ними:
• Какие актеры выполняют тот или иной прецедент
• Какие прецеденты включают другие прецеденты
В языке UML помимо отношения «include» (включает) есть и другие типы отношений между прецедентами, например отношение «extend» (расширяет). Настоятельно рекомендуем его избегать. Слишком часто разработчики целыми командами надолго погружались в рассмотрение различных отношений между прецедентами, понапрасну растрачивая силы. Лучше уделяйте больше внимания текстовому описанию прецедента; именно в этом заключается истинная ценность этой технологии.

Прецеденты и возможности (или пожелания)

Во многих подходах возможности системы применяются для описания требований к системе; в экстремальном программировании (Extreme Programming) возможности системы называются пожеланиями пользователя. Общим является вопрос о том, как установить соответствие между возможностями и прецедентами.

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

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

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс «Как зарабатывать на фрилансе».

Перейти на страницу курса