Построение диаграмм потоков данных нулевого и последующих уровней

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

Результаты представлены на рис. 3.6—3.9.

Описание накопителей данных и пример спецификации про­цесса приведены ниже.

Накопитель данных: пациенты

Номер_пациента

Фио

Адрес

Телефон

Дата_рождения

Группа_крови

Страхование⁰

Накопитель данных: приемы

Номер_приема

Номер_пациента

Дата_приема

Рис. 3.6. Диаграмма потоков данных нулевого уровня

Дата_выписки

Номср_палаты

Накопитель данных: курсы лечения

Номер_приема

Номср_врача

Рис. 3.7. Диаграмма потоков данных первого уровня для процесса 1

Наименование_заболевания

ПРИМЕЧАНИЕ

Дата

Время

Примечание

Рис. 3.8. Диаграмма потоков данных второго уровня для процесса 1.1

Накопитель данных: врачи

Номер_врача

Имя_врача

Адрес

Телефон

Дата_рождения

Специализация

Номер_кабинета

Рабочий_телефон

Спецификация процесса: Зарегистрировать пациента

BEGIN

GET Фио и Дата_рождения

FIND пациент

IF пациент найден THEN

DISPLAY данные пациента

Рис. 3.9. Диаграмма потоков данных первого уровня для процесса 2

ELSE

GET Адрес

DETERMINE Номер_пациента

INSERT пациент

ENDIF

PRINT подтверждение

END

Рис. 3.10. Уточненный вариант концептуальной модели данных

Уточнение концептуальной модели данных

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

Результат представлен на рис. 3.10.

3.3.

ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД

К МОДЕЛИРОВАНИЮ БИЗНЕС-ПРОЦЕССОВ

 

3.3.1.

МЕТОДИКА МОДЕЛИРОВАНИЯ

RATIONAL UNIFIED PROCESS

 

Объектно-ориентированный подход к моделированию биз­нес-процессов с использованием языка UML реализован в техно­логии Rational Unified Process. Методика моделирования, являю­щаяся составной частью данной технологии, предусматривает построение двух моделей:

· модели бизнес-процессов (Business Use Case Model);

· модели бизнес-анализа (Business Analysis Model).

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

Business Actor (действующее лицо бизнес-процессов) — это не­которая роль, внешняя по отношению к бизнес-процессам орга­низации. Потенциальными кандидатами в действующие лица, бизнес-процессов являются:

· акционеры;

· заказчики;

· поставщики;

· партнеры;

· потенциальные клиенты;

· местные органы власти;

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

· внешние системы.

Список действующих лиц составляется путем ответа на следу­ющие вопросы:

Кто извлекает пользу из существования организации?

Кто помогает организации осуществлять свою деятельность?

Кому организация передает информацию и от кого получает?

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

Это определение подобно общему определению бизнес-процесса, по имеет более точный смысл. В терминах объектной мо­дели Business Use Case представляет собой класс, объектами кото­рою являются конкретные потоки событий в рамках описывае­мою бизнес-процесса.

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

Каждый Business Use Case отражает цель или потребность некоторого действующего лица. Например, если рассмотреть процесс регистрации пассажиров в аэропорту (рис. 3.11[22]), то его основным действующим лицом будет сам Пассажир, главная цель которого в данном процессе — пройти регистрацию. Эта цель моделируется в виде Business Use Case с наименованием «Пройти регистрацию». Другим действующим лицом является Руководитель туристической группы, регистрирующий группу пассажи­ров. Стереотипы связей явно показывают роль действующих лиц по отношению к вариантам использования.

Рис. 3.11. Диаграмма вариантов использования для процесса регистрации

пассажиров в аэропорту

 

Описание Business Use Case представляет собой специфика­цию, которая, подобно обычному варианту использования, сос­тоит из следующих пунктов:

· наименование;

· краткое описание;

· цели и результаты (с точки зрения действующего лица);

· описание сценариев (основного и альтернативных);

· специальные требования (ограничения по времени выпол­нения или другим ресурсам);

· расширения (исключительные ситуации);

· связи с другими Business Use Case;

· диаграммы деятельности (для наглядного описания сцена­риев при необходимости).

Пример спецификации Business Use Case:

Наименование — пройти регистрацию.

Краткое описание — данный Business Use Case реализует процесс регистрации пассажира на рейс.

Цели — получить посадочный талон и сдать багаж.

Основной сценарий.

1. Пассажир встает в очередь к стойке регистратора.

2. Пассажир предъявляет билет регистратору.

3. Регистратор подтверждает правильность билета.

4. Регистратор оформляет багаж.

5. Регистратор резервирует место для пассажира.

6. Регистратор печатает посадочный талон.

7. Регистратор выдает пассажиру посадочный талон и квитанцию на багаж.

8. Пассажир уходит от стойки регистратора.

Альтернативные сценарии.

За. Билет неправильно оформлен — регистратор отсылает пассажи­ра к агенту по перевозкам.

4а. Багаж превышает установленный вес — регистратор оформляет доплату.

Специальные требования - время регистрации не должно превышать одной минуты.

Описание Business Use Case может сопровождаться целью процесса, которая, так же, как и в методе Eriksson-Penker, моделируется с помощью класса со стереотипом «goal», а дерево целей изображается в виде диаграммы классов.

Для каждого Business Use Case строится модель бизнес-анализа - объектная модель, описывающая реализацию бизнес-процесса и терминах взаимодействующих объектов (бизнес-объектов — Business Object), принадлежащих к двум классам, — Business Worker и Business Entity.

Business Worker (исполнитель) — активный класс, представля­ющий собой абстракцию исполнителя, выполняющего некото­рые действия в рамках бизнес-процесса. Исполнители взаимодействуют между собой и манипулируют различными сущностя­ми, участвуя в реализациях сценариев Business Use Case. На диаг­рамме классов UML исполнитель представляется в виде класса со стереотипом «business worker». Например, если рассмотреть Business Use Case «Пройти регистрацию», можно определить в нём двух исполнителей — Регистратора и Координатора багажа.

Business Entity (сущность) — пассивный класс, не инициализирующий никаких взаимодействий. Объект такого класса может участвовать в реализациях различных Business Use Case. Сущ­ность является объектом различных действий со стороны испол­нителей. Понятие Business Entity аналогично понятию сущности в модели ERM, за исключением того, что в ERM не определяется поведение сущности, а в объектной модели сущность может иметь набор обязанностей. На диаграмме классов UML сущность представляется в виде класса со стереотипом «business entity». Например, в Business Use Case «Пройти регистрацию» можно оп­ределить следующие сущности: Билет, Рейс, Авиалиния, Багаж, Багажная бирка.

Модель бизнес-анализа может состоять из диаграмм разных типов. В состав модели обязательно должна входить диаграмма классов, содержащая исполнителей и сущности. Пример такой диаграммы для Business Use Case «Пройти регистрацию» приве­ден на рис. 3.12.

Рис. 3.12. Диаграмма классов модели бизнес-анализа

 

Рис. 3.13. Диаграмма последовательности для основного сценария

Business Use Case «Пройти регистрацию»

На данной диаграмме ассоциации между классами-исполнителями отражают наличие взаимодействия между реальными испол­ин гелями (Регистратором и Координатором багажа). Ассоциации между классами-исполнителями и классами-сущностями показывают, какими именно объектами манипулируют конкретные ис­полнители (Регистратор имеет дело с Багажом и Багажной биркой, а Координатор багажа - только с Багажом). Ассоциации между классами-сущностями отражают различные структурные связи (к одному месту багажа прикрепляется одна багажная бирка).

Кроме диаграммы классов, модель бизнес-анализа может включать:

· Диаграммы последовательности (и кооперативные диаграм­мы), описывающие сценарии Business Use Case в виде после­довательности обмена сообщениями между объектами действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора его операций. Пример диаграммы последовательности, описывающей основной сценарий Business Use Case «Пройти регистрацию», приве­ден на рис. 3.13. Модифицированная диаграмма классов мо­дели бизнес-анализа с операциями приведена на рис. 3.14.

· Диаграммы деятельности с потоками объектов и «плава­тельными дорожками», описывающие взаимосвязи между сценариями одного или различных Business Use Case. При­мер такой диаграммы для процесса заказа товаров в торго­вой компании приведен на рис. 3.15.

· Диаграммы состояний, описывающие поведение отдельных бизнес-объектов (например, для сущности «Багаж» можно описать переходы между состояниями «Определен вес», «Зарегистрирован», «Находится на транспортере» и т.д.).

Рис. 3.14. Модифицированная диаграмма классов модели

бизнес-ана­лиза с операциями

 

Рис. 3.15. Диаграмма деятельности для процесса заказа товаров

Методика моделирования Rational Unified Process предусматривает специальное соглашение, связанное с группировкой структурных элементов и диаграмм бизнес-модели. Это соглашение включает следующие правила:

· Все действующие лица, варианты использования и диаграм­мы вариантов использования для бизнес-процессов поме­щаются в пакет с именем Business Use Case Model.

· Все классы и диаграммы моделей бизнес-анализа помеща­ются в пакет с именем Business Analysis Model.

· Если моделируется деятельность более чем одного подраз­деления организации, то совокупность всех классов-испол­нителей и классов-сущностей из моделей бизнес-анализа для различных Business Use Case разделяется на пакеты, со­ответствующие этим подразделениям. Этим пакетам прис­ваиваются наименования подразделений (например, Бухгалтерия, Отдел доставки и т.п.) и стереотип «organization unit» (организационная единица).

· Диаграммы модели бизнес-анализа, относящиеся к конк­ретному Business Use Case (диаграммы классов, последова­тельности, деятельности и состояний) помещаются в коопе­рацию (см. подразд. 2.6) с именем данного Business Use Case и стереотипом «business use-case realization» (реализация биз­нес-процесса). Все кооперации помещаются в пакет с име­нем Business Use Case Realizations.

Пример структуры бизнес-модели для процесса регистрации пассажиров в аэропорту приведен на рис. 3.16.

Рис. 3.16. Пример структуры бизнес-модели

 

Методика моделирования Rational Unified Process обладает следующими достоинствами:

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

· моделирование на основе вариантов использования способ­ствует хорошему пониманию бизнес-модели со стороны за­казчиков.

Однако следует отметить, что при моделировании деятель­ности крупной организации, занимающейся как производством продукции, так и оказанием услуг, необходимо применять раз­личные методики моделирования, поскольку для моделирования производственных процессов более предпочтительным является процессный подход (например, метод Eriksson-Penker).

3.3.2.

ПРИМЕР ИСПОЛЬЗОВАНИЯ