1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom
.pdfМоделирование бизнес-процессов и спецификация требований 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. Диаграмма классов модели бизнес-анализа