Учебники / Силич М.П. МиАБ. Учебник
.pdfОбъектно-ориентированный язык моделирования UML |
91 |
Каждый шаг (событие) прецедента представляет собой некоторое действие, переводящее прецедент в новое состояние. В свою очередь, новое состояние прецедента является стимулом для выполнения следующего шага (события). Таким образом, прецедент рассматривается как машина состояний-событий.
Поток событий прецедента может быть представлен в виде
диаграммы деятельности (Activity diagram), являющейся под-
диаграммой прецедента. Данный вид диаграммы имеет некоторое сходство со структурной схемой алгоритма [21]. На рис. 3.15 приведены условные обозначения основных элементов диаграммы.
а |
б |
в |
г |
д |
е |
Рис. 3.15. Элементы диаграммы деятельности:
а— начальное состояние; б — конечное состояние;
в— действие; г — переход; д — ветвление; е — синхронизация
На рис. 3.16 приведен пример диаграммы, иллюстрирующий ход событий прецедента «Продажа продукта», описанного выше. Процесс начинается с начального состояния и переходит от одного действия к другому, заканчиваясь конечным состоянием. В ходе выполнения процесса могут возникать ветвления на альтернативные потоки. В этом случае ставится знак ветвления в виде ромба, имеющего одну входящую стрелку и две или более выходящих. Для каждой из выходящих стрелок указывается соответствующее условие, при котором выполняется данный переход. Кроме того, процесс может иметь параллельные потоки действий. Для разделения на параллельные потоки либо слияния параллельных потоков используется символ синхронизации.
Описание потока событий прецедента, отображаемое на диаграмме деятельности, может быть очень сложным и запутанным, содержать различные альтернативные потоки событий, в том числе достаточно редкие и исключительные, выполняемые лишь при определенных условиях. Поэтому чтобы упростить
92 |
Глава 3. Моделирование бизнес-процессов |
описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования.
Получить заявку
Указан готовый продукт |
Указан заказной продукт |
|
Проверить наличие |
Передать заказ изготовителю |
|
|
|
|
на складе |
|
|
|
Изготовить продукт |
|
Сообщить о готовности |
Отправить на склад |
Продукт имеется
Принять оплату
Нет продукта Заказать транспорт
Доставить продукт
Рис. 3.16. Диаграмма деятельности прецедента «Продажа продукта»
Первый способ структурирования сложных прецедентов заключается в использовании отношения включения (include). Если из общего описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент и между ним и исходным прецедентом устанавливается отношение включения. Поток событий включенного прецедента «встраивается» в поток событий базового прецедента, т. е. когда экземпляр базового прецедента в процессе своего выполнения достигает точки
Объектно-ориентированный язык моделирования UML |
93 |
включения, выполняется последовательность шагов включенного прецедента, после чего продолжается выполнение исходного прецедента. Например, из прецедента «Продажа продукта» можно выделить фрагмент, содержащий последовательность действий, выполняемую только в том случае, если клиент в заявке указывает заказной продукт. Представим этот фрагмент в виде отдельного прецедента «Исполнение заказа». На диаграмме вариантов использования (см. рис. 3.14) между прецедентами «Продажа продукта» и «Исполнение заказа» устанавливается отношение включения. Для прецедента «Исполнение заказа» создается собственная диаграмма деятельности (рис. 3.17).
|
Получить заявку |
|
Указан готовый продукт |
||
|
Указан |
|
|
заказной |
|
Проверить |
продукт |
|
наличие |
Вызов прецедента |
|
на складе |
||
«Исполнение заказа» |
||
|
||
Продукт |
|
|
имеется |
Принять оплату |
|
продукта |
||
Заказать транспорт |
||
|
||
Нет |
Доставить продукт |
|
|
а
Передать заказ изготовителю
Изготовить продукт
Сообщить |
Отправить |
о готовности |
на склад |
б
Рис. 3.17. Структурирование модели посредством отношения включения:
а— диаграмма деятельности прецедента «Продажа продукта»;
б— диаграмма деятельности прецедента «Исполнение заказа»
При этом на диаграмме деятельности прецедента «Продажа продукта» вместо извлеченного фрагмента размещается действие, осуществляющее вызов прецедента «Исполнение заказа».
94 |
Глава 3. Моделирование бизнес-процессов |
Частным случаем структурирования с помощью выделения фрагментов является использование отношения расширения (extend). Данное отношение устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях.
Второй способ структурирования сложных прецедентов основан на использовании отношения обобщения (generalization). Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский) и установить между ним и исходными отношение обобщения. В этом случае общее поведение описывается только один раз. Описания конкретных прецедентов (потомков) содержат только дополнительные шаги (или модифицированные шаги), которых нет в обобщенном описании. Например, с прецедентом «Продажа продукта» могут быть связаны его потомки — прецеденты «Продажа мебели», «Продажа компьютера», которые отличаются в деталях от родительского прецедента. При этом на диаграмме вариантов использования необходимо отразить отношения обобщения (см. рис. 3.14), а в диаграммах деятельности прецедентов-потомков можно осуществлять вызов родительского прецедента, описывающего шаги, оставшиеся без изменений.
3.3.3. Объектная модель бизнеса
Прецедентная модель иллюстрирует функции бизнеса (биз- нес-процессы) и его окружение. Однако для более полного понимания бизнеса такого описания недостаточно. Необходима модель, показывающая кем, с помощью чего реализуются прецеденты. Объектная модель раскрывает внутреннее устройство бизнеса, а именно: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют. Объектную модель бизнеса называют также моделью бизнесанализа (Business Analysis Model). Основным понятием модели бизнес-анализа является понятие объекта. Объекты модели
Объектно-ориентированный язык моделирования UML |
95 |
бизнеса представляют людей, участвующих в выполнении процессов, и различного рода сущности, которые обрабатываются или создаются бизнесом (продукцию, предметы, задачи и т.д.). Участники процессов (исполнители) называются активными объектами, сущности — пассивными.
Похожие объекты группируются в классы. Класс — это множество объектов, связанных общностью свойств и поведения. Каждый конкретный объект рассматривается как экземпляр некоторого класса. Например, объекты, соответствующие конкретным служащим, могут быть объединены в класс Служащий.
Объекты обладают свойствами и поведением. Свойства объекта описываются с помощью характеристик, называемых атрибутами. При этом состав атрибутов одинаков для всего класса, различные экземпляры одного класса отличаются лишь набором конкретных значений атрибутов. Например, класс Служащий может иметь атрибуты: ФИО, Стаж, Квалификация и т.д. Разные объекты данного класса будут иметь разные значения этих атрибутов. Причем значения атрибутов могут изменяться со временем.
Поведение определяет действия объекта и его реакцию на запросы от других объектов. Поведение представляется с помощью набора операций, которые может выполнять объект. Примеры операций класса Служащий: Принять заказ, Оформить договор, Принять оплату и т. д.
Для отображения взаимосвязей между классами используется диаграмма классов (Class diagram). На рис. 3.18 представлены условные обозначения основных элементов диаграммы классов модели бизнес-анализа.
Notes
Clerk Account
а |
б |
в |
г |
д |
е |
Рис. 3.18. Элементы диаграммы классов объектной модели бизнеса:
а— исполнитель; б — сущность; в — ассоциация; г — зависимость;
д— обобщение; е — примечание
96 |
Глава 3. Моделирование бизнес-процессов |
Как правило, используются классы со стереотипом business worker (исполнитель) и business entity (сущность). На рис. 3.19
представлен пример диаграммы классов, построенной для прецедента «Продажа продукта».
<<communicate>>
|
Продавец <<uses>> |
<<uses>> |
Изготовитель |
|
<<communicate>> |
|
<<communicate>> |
Служащий |
<<uses>> Заказ |
Продукт |
<<uses>> |
<<uses>> |
|
||
|
|
|
|
|
<<communicate>> |
|
|
|
Отправитель |
|
Склад |
Рис. 3.19. Диаграмма классов для прецедента «Продажа продукта»
На диаграмме отражены классы исполнителей, выполняющих прецедент (Продавец, Исполнитель, Склад, Отправитель), а также классы объектов-сущностей, используемых в ходе выполнения прецедента (Заказ, Продукт). Между классами исполнителей установлены отношения коммуникации (ассоциации со стереотипом communicate), отражающие их взаимодействие. Между классами объектов-сущностей, как правило, отношения коммуникации не устанавливаются. Класс сущности может быть связан с классом исполнителя отношением использования (ассоциации со стереотипом uses), в случае если исполнитель некоторым образом использует сущность. Например, Продавец создает Заказ, Изготовитель использует Заказ для получения описания продукта, Отправитель использует Заказ для получения информации о том, куда доставлять продукт. Соответствующие отношения использования представлены на рис. 3.19.
Объектно-ориентированный язык моделирования UML |
97 |
На диаграмме классов могут быть отражены также отношения структурирования — обобщения и включения. Так, на рис. 3.19 показаны отношения обобщения между абстрактным классом Служащий и более конкретными классами Продавец, Отправитель.
Для каждого класса создается спецификация, в которой указывается состав атрибутов и обязательств (операций).
Для того чтобы отразить последовательность взаимодействия объектов во время выполнения бизнес-процессов, используется
диаграмма последовательности (Sequence diagram). На рис. 3.20
представлена диаграмма прецедента «Продажа продукта» (его реализация для случая заказного продукта).
Каждый объект, участвующий в реализации прецедента, изображается в верхней части диаграммы в виде прямоугольника, от которого вниз проведена линия («линия жизни»). Внутри прямоугольника записывается имя объекта, следом через двоеточие может быть указано имя класса. Вся запись подчеркивается, что является признаком объекта, отличающим его от класса.
Продавец |
|
Изготовитель |
|
Склад |
|
Отправитель |
|
|
|
|
|
|
|
Клиент
Подача заявки |
Оформление |
|
|
|
|
|
|
|
заказа |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Передача заказа |
|
|
|
|
|
|
|
|
|
|
Изготовление |
|
|
|
|
Сообщение |
|
продукта |
|
|
||
|
Отправка |
|
|
||||
|
о готовности |
|
|
||||
Сообщение |
|
|
продукта |
|
|
||
Оплата |
|
|
|
|
|
|
|
|
|
|
|
Заказ |
|
|
|
|
|
|
транспорта |
|
Запрос |
||
|
|
|
|
|
|
|
Отгрузка |
|
|
Доставка продукта |
|
|
|
||
|
|
|
|
|
|
|
|
Рис. 3.20. Диаграмма последовательности прецедента «Продажа продукта»
98 |
Глава 3. Моделирование бизнес-процессов |
Если в прецеденте участвуют акторы, они также могут быть отражены на диаграмме. Объекты-сущности обычно не представлены на данной диаграмме, так как они не осуществляют взаимодействия.
Между объектами (акторами) устанавливаются отношения сообщений (message), отражающие аналогично отношениям коммуникации передачу информации (или некоторый материальный поток) между объектами. Сообщение изображается отрезком горизонтальной линии со стрелкой, проведенной от линии жизни объекта (актора), посылающего сообщение, до линии жизни объекта (актора), получающего сообщение. При этом прием сообщения инициирует выполнение определенных действий тем объектом, которому сообщение передано.
Сообщения должны быть упорядочены по времени: первое сообщение изображается вверху диаграммы, следующее — ниже, следующее — еще ниже и т. д. Таким образом, ось времени в диаграмме идет сверху вниз. Однако она не связана с метрикой и служит только для идентификации порядка взаимодействия, т. е. расстояние между взаимодействиями (сообщениями) на диаграмме не имеет ничего общего с интервалами времени между событиями.
Анализ диаграммы последовательности помогает выявить все обязательства активного объекта. Так, из диаграммы, представленной на рис. 3.20, можно определить, что к обязательствам объекта Продавец относятся: Прием заявки, Оформление заказа, Передача заказа Изготовителю, Прием сообщения о готовности продукта, Сообщение клиенту о готовности продукта, Прием оплаты, Заказ транспорта. Данные операции должны быть внесены в спецификацию соответствующего класса Продавец.
Взаимодействие объектов может быть показано и на диа-
грамме кооперации (Collaboration diagram). Она является стати-
ческой моделью, поэтому на ней не может быть представлена последовательность взаимодействий.
Язык имитационного моделирования SIMAN |
99 |
3.4.Язык имитационного моделирования SIMAN
SIMAN является гибким дискретно-событийным языком моделирования и анализа деятельности предприятий. Он распространяется вместе с инструментальным средством имитационного моделирования Arena, которое позволяет формировать модель на языке SIMAN, воспроизводящую процесс функционирования системы во времени, а также осуществлять многократные испытания модели с разными входными данными.
Целями имитационного моделирования могут быть: выявление «узких» мест моделируемых бизнес-процессов; прогнозирование возможных сценариев развития процессов; сравнение различных вариантов реализации системы.
Имитационное моделирование в ряде случаев гораздо менее затратное, чем проведение экспериментов с реальными системами. Тем более что иногда эксперименты на реальных системах в принципе невозможны. Моделирование позволяет изучить длительный интервал функционирования системы в сжатые сроки или, наоборот, изучить более подробно работу системы в развернутый интервал времени [22].
В основе языка SIMAN лежит математический аппарат систем массового обслуживания, дополненный рядом требований, таких как гибкость моделей, возможность задания стохастических параметров процесса, возможность обработки статистических данных, создание разнообразных отчетов по результатам моделирования.
Имитационная модель на языке SIMAN включает следующие основные элементы [20, 23]:
процессы (Process) — работы, операции, действия;
ресурсы (Resource), выполняющие процессы, — персонал (продавцы, клерки, рабочие) или оборудование (станки, компьютеры);
сущности (Entity), обрабатываемые процессами, — заказы, документы, заготовки изделий, клиенты и т. д.;
100 |
Глава 3. Моделирование бизнес-процессов |
очереди (Queue) из ожидающих обработки сущностей, образующиеся перед процессами, которые в данный момент заняты.
Процессы отображаются в виде схемных модулей. Для процессов разного типа используются разные графические обозначения. На рис. 3.21 приведены обозначения некоторых процессов.
а |
б |
в |
г |
д |
Рис. 3.21. Графические модули языка SIMAN: а — |
модуль Create; |
б— модуль Dispose; в — модуль Process; г — модуль Decide;
д— модуль Assign
Модуль Create (рис. 3.21, а), или Источник, создает сущности, обрабатываемые в системе. Он имитирует, например, прибытие клиентов в банк или в магазин, поступление документов (заказов, чеков), начало изготовления продукции на производственной линии. Скорость поступления сущностей от Источника обычно задается статистической функцией.
Модуль Process (рис. 3.21, в) является основным модулем процесса обработки в имитационной модели. Он имитирует, например, обслуживание клиентов, обработку документов или деталей, выполнение заказов. Время обработки сущности в процессе (производительность процесса) обычно задается статистической функцией.