1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

Моделирование бизнес-процессов и спецификация требований 2 4 1

Администрирование	Прием
	нового
приема пациентов	больного

Администрирование врачей и пациентов

	Запрос	Курс
		лечения
	Отчет о пациентах
	для администрации
	больницы	Отчет
		по
		истории
	Обзор	болезни
	курсов	Т t
	лечения
	Администрация	Администрирование
	больницы
		курсов лечения

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

Дата_выписки Номер_палаты

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

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

242

Глава 3

		Новый
	Данные о пациенте	пациент
		больницы
Регистра­
ционная		Данные
карта
		о
		специалисте
1.1		1.2
		:<J
Обслужить	Пациенты	Зарегистрировать
пациента		пациента

1.3

1.4

Зарегистрировать Подготовить отчет врача

о пациентах

Запрос

Отчет о пациентах для администрации больницы

База данных системы приема

I Администрация больницы

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

Наименование_заболевания ПРИМЕЧАНИЕ Дата Время

Примечание

Моделирование бизнес-процессов и спецификация требований 2 4 3

	Данные о пациенте	1.1.1
		Зарегистрировать
		данные о пациенте

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

Пациенты

Регистрационная

карта

1.1.2

Оформить

регистрационную

карту

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

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

Номер_врача Имя__врача Адрес Телефон Дата_рождения

Специализация Номер_кабинета Рабочий_телефон

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

BEGIN

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

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

244

Глава 3

2.1	Курс
Зарегистрировать	лечения
курс лечения		Врач
	Запрос	Отчет
	на получение	по истории
	истории болезни	болезни

Подготовить отчет по истории болезни

Подготовить обзор курсов лечения

Обзор Администрация курсов больницы лечения

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

ELSE

GET Адрес

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

INSERT пациент

ENDIF

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

END

Моделирование бизнес-процессов и спецификация требований 2 4 5

Пациент

HoMgp пациента Фио

Адрес

Телефон Дата_роходения Группа^крови Страховая_компания Номер_страховки

Прием

	(1,1) Номер,приема	(0.N)
		Включает
	Дата_приема
	Дата_выписки
	Номер_палаты	Х1Л1
	(1,1)	Курс лечения
		Наименование
		заболевания
		Время
		Примечание

Врач

Номер врача Имя_врача Адрес Телефон Дата_рождения Специализация

Номер_ка6инета Рабочий__телефон

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

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

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

Результат представлен на рис. 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 (действующее лицо бизнес-процессов) - это не­ которая роль, внешняя по отношению к бизнес-процессам орга­ низации. Потенциальными кандидатами в действующие лица бизнес-процессов являются:

•акционеры;

•заказчики;

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

•партнеры;

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

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

Моделирование бизнес-процессов и спецификация требований 2 4 7

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

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

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

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

Кто помогает организации осуществлять свою деятельность? Кому организация передает информацию и от кого получает? Business Use Case (вариант использования с точки зрения биз­

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

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

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

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

^ Примеры моделей, связанных с применением технологии Rational Unified Process, здесь и далее приводятся в среде CASE-средства Rational Rose.

2 4 8		Глава 3
4^ RatiortarRos^ f ВШйШ^-шос1е1лк1Г- fOs« C^sfe Oliii	;^-д<^:Д	.Jtelii
Шш Idlk ^m Ir^m^ |row$e"t«por6''"^ry 1<«й$	Ш-Ы M^^i^w |1ф	jsJjSliSi

Пройти регистрацию

^'чй

Руководитель	Зарегистрировать группу
туристической группы
	I .	Ш

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

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

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

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

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

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

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

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

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

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

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

Моделирование бизнес-процессов и спецификация требований 2 4 9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для каждого Business Use Case строится модель бизнес-анализа

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

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

Business Entity (сущность) — пассивный класс, не инициирую­ щий никаких взаимодействий. Объект такого класса может

250

Глава 3

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

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

4> Rational Rose - Busihes^^modeljindl «^|Ш$«]ИайгатгЙ1Ш1ШШш

| ij Ob fdit' ^ ^ ш ^ jFQjuna^' ^mm -- Em^tf" ^»rf	Xoofe^'"- j ^ * 3 & W ^ \ p i ^ ^ Ц ф >
«business worker»	«business worker»
Регистратор	Координатор багажа
(from Business Analysis Model)	(from Business Analysis Model)

«business entity»

Багаж

(from Business Analysis Model)

^ J

«business entity»

Багажная бирка

(from Business Analysis Model)

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