Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

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

Администрирование

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

Администрирование

врачей и пациентов

Запрос

Отчет о пациентах

для администрации

больницы

Администрация

больницы

Обзор

курсов

лечения

Прием

нового

больного

Т t

Курс

лечения

Отчет

по

истории

болезни

Администрирование

курсов лечения

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

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

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

Накопитель

данных:

курсы лечения

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

Номер_врача

242

Глава 3

Регистра-

ционная

карта

Данные о пациенте

Новый

пациент

больницы

Данные

специалисте

1.1

Обслужить

пациента

Пациенты

Запрос

:<J

1.2

Зарегистрировать

пациента

1.4

Подготовить отчет

о пациентах

1.3

Зарегистрировать

врача

Отчет о пациентах

для администрации

больницы

База данных

системы приема

I Администрация

больницы

Рис.

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

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

ПРИМЕЧАНИЕ

Дата

Время

Примечание

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

Данные о пациенте

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

Моделирование бизнес-процессов

спецификация требований

245

Пациент

HoMgp пациента

Фио

Адрес

Телефон

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

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

Страховая_компания

Номер_страховки

(1,1)

Прием

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

Дата_приема

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

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

(1,1)

(0.N)

Включает

Х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

(действующее лицо бизнес-процессов) - это не-

которая роль, внешняя по отношению к бизнес-процессам орга-

низации. Потенциальными кандидатами в действующие лица

бизнес-процессов являются:

• акционеры;

• заказчики;

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

• партнеры;

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

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

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

• сотрудники подразделений организации, деятельность ко-

торых не охвачена моделью;

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

Список действующих

лиц

составляется путем ответа на следу-

ющие вопросы:

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

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

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

Business Use Case

(вариант использования с точки зрения биз-

нес-процессов) определяется как описание последовательности

действий (потока событий) в рамках некоторого бизнес-процес-

са, приносящей ощутимый результат конкретному действующе-

му

лицу

Это определение подобно общему определению бизнес-про-

цесса, но имеет более точный смысл.

терминах объектной мо-

дели Business Use Case представляет собой

класс,

объектами кото-

рого являются конкретные потоки событий в рамках описывае-

мого бизнес-процесса.

Данная методика концентрирует внимание в первую очередь

на

элементарных

бизнес-процессах. Такой процесс можно опре-

делить как задачу, выполняемую одним человеком в одном месте

в одно время в ответ на некоторое событие, приносящую конк-

ретный результат

переводящую данные в некоторое устойчивое

состояние (например, подтверждение платежа по кредитной кар-

точке).

Выполнение такой задачи обычно включает

от

пяти

до

де-

сяти шагов

может занимать от нескольких

минут до

нескольких

дней, но рассматривается как один сеанс взаимодействия

действующего лица с исполнителями.

Каждый Business Use Case отражает цель или потребность не-

которого действующего лица. Например, если рассмотреть про-

цесс регистрации пассажиров в аэропорту (рис. 3.11^), то его ос-

новным действующим лицом будет сам Пассажир, главная цель

которого

данном процессе

—

пройти регистрацию. Эта цель мо-

делируется в виде Business Use Case с наименованием «Пройти

регистрацию». Другим действующим лицом является Руководи-

^ Примеры моделей, связанных с применением технологии Rational

Unified Process, здесь и далее приводятся в среде CASE-средства Rational

Rose.

248 Глава 3

4^ RatiortarRos^ f ВШйШ^-шос1е1лк1Г- fOs«

C^sfe

Oliii

Шш Idlk ^m Ir^m^ |row$e"t«por6''"^ry 1<«й$ Ш-Ы

M^^i^w

|1ф jsJjSliSi

;^-д<^:Д

.Jtelii

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

^'чй

Руководитель

туристической группы

Зарегистрировать группу

. Ш

Рис.

3.11.

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

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

тель туристической группы, регистрирующий фуппу пассажи-

ров.

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

по отношению к вариантам использования.

Описание Business Use Case представляет собой специфика-

цию,

которая, подобно обычному варианту использования, сос-

тоит из следующих пунктов:

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

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

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

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

• специальные требования (офаничения по времени выпол-

нения или другим ресурсам);

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

• связи

другими Business Use Case;

• диафаммы деятельности (для наглядного описания сцена-

риев при необходимости).

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

Пример

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

Наименование —

пройти регистрацию.

Краткое описание —

данный Business Use Case реализует процесс ре-

гистрации пассажира на рейс.

Цели —

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

Основной

сценарий,

Пассажир встает

очередь к стойке регистратора.

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

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

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

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

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

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

багаж.

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.

Rational Rose - Busihes^^modeljindl

«^|Ш$«]ИайгатгЙ1Ш1ШШш

|ij Ob fdit'

^ш

jFQjuna^'

^mm

Em^tf"

^»rf

Xoofe^'"-

j^*3&W^\pi^^

Цф

«business worker»

Регистратор

(from Business Analysis Model)

«business worker»

Координатор багажа

(from Business Analysis Model)

«business entity»

Багаж

(from Business Analysis Model)

«business entity»

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

(from Business Analysis Model)

Рис.

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