3.3. Практические задания
Тема: Построение модели бизнес процессов в Rational Rose
Задание 1. Построить модель бизнес процессов в соответствие с примером
Постройте модель бизнес процессов в Rational Rose в соответствие с примерами на рис. 3.17- 3.23.
Порядок построения потока работ при построении бизнес процессов в Rational Rose должен включать следующие шаги:
Запустите Rational Rose.
Поименуйте диаграмму функций Main в папке Use Case View окна просмотра элементов модели как: Все модели в разделе Use Case View.
Откройте диаграмму функций Все модели в разделе Use Case View.
Поле диаграммы функций Все модели в разделе Use Case View поименуйте аналогичным образом.
На поле диаграммы функций Все модели в разделе Use Case View поместите два пакета 1. Цели кредитования и 2. Бизнес процессы кредитования как представлено на рис. 3.17.
В пакет 1. Цели кредитования поместите класс и поименуйте его как представлено на рис. 3.18. Поименуйте название поля диаграммы и изображение иконки диаграммы в окне просмотра элементов модели как 1. Цели кредитования.
В пакет 2. Бизнес процессы кредитования поместите пакеты 2.1. Кредитование юридических лиц в рублях, 2.2. Кредитование юридических лиц в валюте, 2.3. Кредитование физических лиц в рублях, 2.4. Кредитование физических лиц в валюте как представлено на рис. 3.21. Поименуйте название поля диаграммы и изображение иконки диаграммы в окне просмотра элементов модели как 2.Бизнес процессы кредитования как представлено на рис. 3.19.
В пакеты 2.1. – 2.4 поместите изображения бизнес процесса, цели, которую он поддерживает, бизнес роли, как представлено на рис. 3.20.-3.23. Не забудьте именование поля диаграмм и изображение иконок диаграмм в окне просмотра элементов.
Сохраните модель.
Задание 2. Построить модель бизнес процессов
Постройте модель бизнес процессов в Rational Rose для процессов международных расчетов Банка.
Процессы международных расчетов в Банке подразделяются на:
международный перевод;
аккредитивы;
гарантии;
инкассо.
Все процессы инициирует клиент Банка. Все процессы независимы друг от друга.
4. Разработка моделей потоков работ
Цели занятия:
научиться разрабатывать модели потока работ;
понять место данной модели при определении функций разрабатываемой системы на этапе определения требований к системе.
4.1. Цель моделирование потока работ
Как указывалось выше, реализация бизнес процессов по RUP описывается с использованием различных объектных моделей бизнеса или моделей анализа бизнеса. Диаграмма деятельности (activity diagram) языка UML используется в бизнес моделировании для отображения потока работ рассматриваемого бизнес процесса. По модели потока работ определяются виды деятельности, подлежащие автоматизации, то есть бизнес требования. На основе бизнес требований в дальнейшем на этапе определения требований будут определяться функции разрабатываемой системы.
4.2. Использование диаграммы деятельности для разработки модели
потока работ
Для разработки модели потока работ или, по другому, модели описания бизнес процессов должна использоваться диаграмма деятельности языка UML (activity diagram).
Для разработки модели потока работ следует использовать следующие элементы диаграммы деятельности:
начальное состояние (start state);
конечное состояние (end state);
деятельность (activity);
состояние (state);
переход (state transition);
решение (decision);
горизонтальные синхронизаторы (horizontal synchronization);
вертикальные синхронизаторы (vertical synchronization);
разделительные линии (swim lane);
объект (object);
поток объектов (object flow);
заметка.
При построении модели потока работ используется нотация диаграммы деятельности, поддерживаемая Rational Rose, которая отличается от нотации этой же диаграммы изложенной в описании UML OMG.
Начальное состояние на диаграмме (start state) должно обозначаться черным маленьким кружком, с которым может быть связано название, например, «начало».
Конечное состояние (end state) должно обозначаться большим черным кружком внутри круга, с которым может быть связано название, например, «конец». Пример начального (start state) и конечного состояния (end state) представлен на рис. 4.1.
Рис. 4.1. Пример начального (start state) и конечного состояния (end state)
Диаграмма деятельности (activity diagram) должна иметь только одно начальное состояние. Конечных же состояний может существовать множество.
Новые начальные состояния могут быть только на диаграммах, декомпозирующих отдельные виды деятельности.
Для отображения деятельности (activity), которая декомпозируется, можно использовать различные ее обозначения, например, как представлено на рис. 4.2. и 4.3.
Рис. 4.2. Пример элемента «деятельность» (activity), которая декомпозируется
Рис. 4.3. Пример элемента «деятельность» (activity) со стереотипом <<Декомпозирована>>
Элемент «деятельность» (activity) должен использоваться собственно для описания определенной деятельности субъекта или объекта, или группы субъектов или группы объектов (обобщенная деятельность). С этим элементом должно быть связано наименование. Наименование должно отражать цель элемента деятельности. Для наименования деятельности могут быть использованы отглагольные существительные, например, регистрация сделок в журнале.
Элементарная «деятельность» (activity) должна использоваться для описания одного действия, например, формирование отчета сделок, передача тикетов, получение тикетов.
Нельзя в одном элементе деятельность (activity) указывать несколько видов деятельности, например, формирует отчет по сделкам и регистрирует сделки в журнале.
Если описывается автоматизированная деятельность, то следует отдельно описать деятельность пользователя системы и соответствующую ей деятельность системы, как функции действующих лиц пользователя и системы.
Элемент состояние (state) обозначается прямоугольником с закругленными углами. Пример элемента «состояния» (state) представлен на рис. 4.4.
Рис. 4.4. Пример элемента состояние (state)
Элемент «состояние» (state) может использоваться для описания определенных состояний какого-либо субъекта или объекта. С этим элементом должно быть связано имя. Имя должно отражать состояние субъекта или объекта. Состояние должно именоваться в зависимости от контекста.
Переход (state transition) должен использоваться для описания связи между элементами диаграммы «деятельность» (activity), «состояние» (state). Переход (state transition) обозначается сплошной линией со стрелкой. Стрелка указывает на следующее действие или состояние. Пример элемента переход (state transition) представлен на рис. 4.5.
Рис. 4.5. Пример элемента «переход» (state transition)
Переход (state transition) может иметь имя, связанное с событием, его вызвавшим. Событием называется любое происшествие, которое может быть причиной изменения состояния субъекта или объекта, или перехода от одного вида деятельности к другому виду. События могут вызывать некоторые действия. Одному событию соответствует ровно одно действие. Переход может происходить по условию.
Для отображения условий может использоваться элемент решение (decision). Элемент решение (decision) обозначается в виде ромба. Пример обозначения решения (decision) представлен на рис. 4.6.
Рис. 4.6. Пример элемента решения (decision)
Разделительные линии (swim lane) следует использовать для разделения поля диаграммы на части, например, с целью отображения на диаграммах, ответственных за выполнение определенных действий. Пример разделительной лини (swim lane) представлен на рис. 4.7.
Рис. 4.7. Пример разделительной линии (swim lane)
Синхронизаторы (synchronization) должны использоваться для отражения деятельностей, выполняемых параллельно или множественного выбора. Пример использования синхронизаторов (synchronization) для отображения деятельностей, выполняемых параллельно, представлен на рис. 4.8, для отображения множественного выбора – на рис. 4.9.
Рис. 4.8. Пример горизонтальных синхронизаторов (synchronization)
для отображения деятельностей, выполняемых параллельно
Рис. 4.9. Пример горизонтальных синхронизаторов (synchronization)
для отображения множественного выбора
Объекты (objects) на диаграммах деятельности должны использоваться для изображения действующих лиц бизнес процесса или ролей и различных сущностей, которыми манипулируют эти лица или роли.
Объект может иметь состояние.
Объект должен связываться с деятельностью с использованием элемента поток объектов (object flow) (прерывистая стрелка).
Поток объектов имеет направление.
Если объект по отношению к деятельности является входным, то поток объектов проводится от объекта к деятельности, если выходным – то от деятельности к объекту.
На рис. 4.10 представлен пример объекта, входного потока объектов и деятельности.
Рис. 4.10. Пример деятельности со входным объектом
Для объекта, отображающего действующее лицо или роль бизнес процесса, поток объектов должен быть направлен к деятельности, которую он выполняет, как представлено на рис. 4.11.
Рис. 4.11. Пример действующего лица и его деятельности
Имя объекта должно задаваться исходя из контекста. Имя объекта должно задаваться как имя объекта : имя класса объекта.
Элемент заметка может использоваться для различных комментариев. Пример заметки для описания подразделения, в котором выполняется определенная деятельность, представлен на рис. 4.12.
Рис. 4.12. Пример заметки для описания подразделения,
в котором выполняется определенная деятельность
Заметки следует прикреплять к элементам диаграммы деятельности (activity diagram) с использованием пунктирной линии (anhor note to item).
В RUP существуют следующие рекомендации по разработке модели потока работ с использованием диаграммы деятельности (activity diagram).
Модель потока работ разрабатывается в два этапа.
В начале разрабатывается модель, отображающая основные виды деятельности (macro activity) по описываемому бизнес процессу в целом.
Далее каждая деятельность декомпозируется с использованием другой диаграммы деятельности. Поле этой диаграммы может разбиваться на части с использованием разделительных линий (swim lane), где разделительные линии могут представлять работников участвующих в бизнес процессе или подразделения.
Построение диаграммы с основными видами деятельности рекомендуется проводить таким образом, чтобы в дальнейшем каждому основному виду деятельности можно было сопоставить на этапе определения требований к системе модуль, компоненту или подсистему в разрабатываемой системе.
Однако для построения распределенных систем более удобным является использование следующих разделительных линий:
входная/выходная информация;
деятельность;
роль;
подразделение;
должность;
бизнес правило.
В разделе деятельность следует отражать шаги бизнес процесса или деятельность процесса.
В разделе входная/выходная информация – входные/выходные бизнес сущности, связанные с шагом бизнес процесса, в разделе роль – роль, ответственную за выполнение шага бизнес процесса, в разделе должность и подразделения – должности действующих лиц бизнес процесса и подразделения предприятия, связанные с шагом бизнес процесса, в разделе бизнес правила - описание бизнес правил или ссылки на модели бизнес правил для рассматриваемого шага бизнес процесса.
Такое использование разделительных линий обусловлено тем, что на основе видов деятельности, отображающих шаги бизнес процесса, будут определяться функции системы, на основе входных/выходных сущностей будет разрабатываться интерфейса пользователя, альбом входных/выходных форм, БД, классы, реализующие соответствующие функции. Информация о ролях, должностях и подразделениях будет использована при рассмотрении вопросов, связанных с разграничением доступа. На основе бизнес правил будут определяться ограничения, накладываемые на функции системы.
Для изображения входной/выходной информации и роли должен использоваться элемент объект с соответствующим состоянием (object).
Для изображения шага бизнес процесса должен использоваться элемент деятельность(activity).
Для изображения подразделений, должностей, ссылок на бизнес правила – заметки (note).
Роли, входная и выходная информацию должны связываться с деятельностью через потоки объектов (object flow).
Роли, подразделения должны связываться между собой через связь - пунктирная линия (anhor note to item), прикрепляющую заметки к элементам диаграммы.
На рис. 4.13 представлен пример диаграммы деятельности, используемой для декомпозиции обобщенной деятельности.
Рис. 4.13. Декомпозиция обобщенной деятельности
На рис. 4.14 представлен пример основных шагов процесса кредитования, на рис. 4.15 – детальное описание шага Предварительное ознакомление с клиентом и его хозяйственной деятельностью и целью кредитования.
Рис. 4.14. Основные шаги процесса кредитования юридических лиц в валюте
Рис. 4.15. Детальное описание шага процесса кредитования Предварительное ознакомление с клиентом
и его хозяйственной деятельностью и целью кредитования
|
Скачать 2.1 Mb.