1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

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

•каждая функция должна быть инициирована событием и должна завершаться событием;

•в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.

На рис. 3.2 показано применение различных объектов ARIS при создании модели бизнес-процесса.

		Цаииые no
		отгрузке CO
		склада
provides input for		lies on
Входящий	creates output to	Исходящий
документ 1		документ 1

Событие 1

Ю-Склад

Рис. 3.2. Фрагмент модели бизнес-процесса

Из рис. 3.1 и 3.2 видно, что бизнес-процесс в нотации еЕРС представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в еЕРС визуально не отражается. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возло­ жено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвле­ ние и слияние бизнес-процесса. Для получения информации о

232

Глава 3

реальной длительности процессов необходимо использовать дру­ гие инструменты описания, например фафики Ганта в системе MS Project.

3.2.4. МЕТОД ERICSSON-PENKER^

Метод Ericsson-Penker представляет интерес прежде всего в связи с попыткой применения языка объектного моделирования UML (изначально предназначенного для моделирования архи­ тектуры систем ПО) в рамках процессного подхода к моделиро­ ванию бизнес-процессов. Это стало возможным благодаря нали­ чию в UML механизмов расширения (см. подразд. 2.5.8). Авторы метода создали свой профиль UML для моделирования бизнеспроцессов, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации.

Метод использует четыре основные категории бизнес-модели.

•Ресурсы — различные объекты, используемые или участвую­ щие в бизнес-процессах (люди, материалы, информация или продукты). Ресурсы структурированы, взаимосвязаны и подразделяются на физические, абстрактные, информаци­ онные и человеческие.

•Процессы — виды деятельности, изменяющие состояние ре­ сурсов в соответствии с бизнес-правилами.

•Цели — назначение бизнес-процессов. Цели могут быть раз­ биты на подцели и соотнесены с отдельными процессами. Цели достигаются в процессах и выражают требуемое состо­ яние ресурсов. Цели могут быть выражены в виде одного или более правил.

•Бизнес-правила — условия или офаничения выполнения процессов (функциональные, поведенческие или структур­ ные). Правила могут диктоваться внешней средой (инструк­ циями или законами), или могут быть определены в преде­ лах бизнес-процессов. Правила могут быть определены с использованием языка OCL, который является частью стан­ дарта иML.

Основной диафаммой UML, используемой в данном методе, является диафамма деятельности (см. подразд. 2.5.5). Процесс в

^ Eriksson, Hans-Erik and Penker, Magnus «Business Modeling with UML: Business Patterns at work». Wiley Computer Publishing, 2000.

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

самом простом виде может быть описан как множество деятельностей. Метод Eriksson-Penker представляет образец процесса на диафамме деятельности (рис. 3.3) в виде деятельности со стерео­ типом «process» (в качестве основы данного образца использова­ но представление процесса в методе IDEFO, расширенное за счет введения цели процесса). Процесс использует входные ресурсы и формирует выходные ресурсы, показанные в виде объектов со стереотипом «resourse», соединенных с процессом связями зави­ симости. Ресурсы, ифающие в методе IDEFO роли «управления» и «механизма», также соединены с процессом связями зависи­ мости со стереотипами «supply» и «control». Цель процесса пока­ зана как объект со стереотипом «goal».

«resourse»

Out; aQlass

«control»

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

Полная бизнес-модель включает множество представлений, подобных представлениям архитектуры ПО. Каждое представле­ ние выражено в одной или более диафаммах. Диафаммы могут иметь различные типы и изображать процессы, правила, цели и ресурсы во взаимодействиях друг с другом. Метод Eriksson-Penker использует четыре различных представления бизнес-модели:

•концептуальное представление — структура целей и проблем (дерево целей, представленное в виде диафаммы объектов);

234

Глава 3

•представление процессов - взаимодействие между процес­ сами и ресурсами (в виде набора диаграмм деятельности);

•структурное представление — структура организации и ре­ сурсов (в виде диафамм классов). В качестве примера одной из моделей этого представления можно привести образец Employment из подразд. 2.6;

•представление поведения — поведение отдельных ресурсов и детализация процессов (в виде диафамм деятельности, состояний и взаимодействия).

3.2.5. ПРИМЕР ИСПОЛЬЗОВАНИЯ ПРОЦЕССНОГО ПОДХОДА

В данном примере используется методика Йордона, описан­ ная в подразд. 3.2.2.

Постановка задачи

Администрация больницы заказала разработку ИС для отдела приема пациентов и медицинского секретариата. Новая система предназначена для обработки данных о врачах, пациентах, прие­ ме пациентов и лечении. Система должна выдавать отчеты по запросу врачей или администрации.

Во время обследования составлено следующее описание дея­ тельности рассматриваемых подразделений.

Перед приемом в больницу проводится встреча пациента и врача. Врач информирует отдел приема пациентов об ожидаемом приеме больного и передает о нем данные. Пациент может быть принят в больницу более чем один раз, но если пациент ранее не лечился в больнице, то ему присваивается регистрационный но­ мер и записываются его данные (фамилия, имя и отчество паци­ ента, адрес и дата рождения). Пациент должен быть зарегистри­ рован в системе до приема в больницу.

Через некоторое время врач оформляет в отделе приема паци­ ентов прием больного. При этом определяется порядковый но­ мер приема и запоминаются данные приема пациента. После этого отдел приема посылает сообщение врачу для подтвержде­ ния приема больного. В это сообщение включаются регистраци­ онный номер пациента и его фамилия, порядковый номер прие­ ма, дата начала лечения и номер палаты.

В день приема пациент сообщает в отдел приема о своем при­ бытии и передает данные о себе (или изменения в данных). Отдел

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

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

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

При необходимости врач запрашивает в медицинском секре­ тариате историю болезни пациента, содержащую данные о курсах лечения, полученных пациентом. История болезни представля­ ется в виде табл. 3.1.

После окончания курсов лечения лечащий врач принимает решение о выписке пациента. Когда пациент выписывается, он

				Таблица 3.1
		История болезни пациента
	История болезни		Дата: 01-02-1998
	1 Данные с 01-01-1992 по 01-02-1998
	Номер пациента: 1 ФИО:		Дата рождения: 15-07-55
	732	Иванов СП.
	Номер приема:	Дата приема:	Палата: 4
	|б49	06-07-1992
	Заболевание: перелом ноги		Врач: Петров П,С., хирург
		Дата	Время	Примечание
		06-07-1992	12.00	Наложен гипс
		20-07-1992	14.00	Состояние хоро­
				шее
		22-07-1992	10.00	Лечение закон­
				чено

236			Глава 3
			Продолжение
Заболевание: ОРЗ		Врач: Иванов А.С., терапевт
	Дата	Время	Примечание
	10-07-1992	10.00	Назначена тера­
			пия
	15-07-1992	10.00	Состояние удов­
			летворительное
	20-07-1992	10.00	Состояние хоро­
			шее
	25-07-1992	10.00	Выписан
Номер приема:	Дата приема:	Палата: 8
711	12-04-1993
Заболевание: сердечный приступ		Врач: Сидоров И.И., кардиолог
	Дата	Время	Примечание

сообщает об этом в отдел приема. Отдел приема регистрирует данные о выписке, включая дату выписки, и дает пациенту справку об окончании пребывания в больнице.

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

Администрация больницы может запросить отчет о пациен­ тах. В запросе указывается интервал времени (начальная и конеч­ ная даты). Отчет должен представляться в следующей форме (табл. 3.2).

Администрация больницы запрашивает также обзор заболе­ ваний за последнюю неделю каждый понедельник в 9.00.

Описание контекста системы приема пациентов в больниц построение начальной контекстной диаграммы

Построим начальную контекстную диафамму потоков дан­ ных в нотации Гейна ~ Сэрсона (рис. 3.4). Нарисуем нулевой

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

Таблица 3.2

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

			Отчет 0 пациентах
	Данные с 01-12-1997 по 01-02-1998
				Дата	Страхо­	Номер
	Номер	ФИО	Адрес Телефон		вая ком­
				рождения		страховки
					пания

процесс и присвоим ему имя системы (Система приема пациен­ тов). Поскольку моделируется деятельность отдела приема паци­ ентов и медицинского секретариата, внешними сущностями яв­ ляются Врач, Пациент и Администрация больницы. Нарисуем внешние сущности и соединим их с нулевым процессом посред­ ством потоков данных.

Спецификация структур данных

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

Пометим символами «*», «°» и «|» все структуры и элементы данных типа «итерация», «условное вхождение» и «альтернатива» соответственно.

После объединения структур и элементов данных в более крупные структуры для каждого потока данных должна быть сформирована структура данных.

Примеры спецификации структур данных.

ОТЧЕТ^ПО^ИСТОРИИ^БОЛЕЗНИ Текущая_дата Начальная_дата Конечная_дата СТРОКА_ПАЦИЕНТА

Номер__пациента Фио Дата_рождения

238

Глава 3

Данные о враче

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

НПациент к

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

карта

Справка о выписке	Система приема
	пациентов	QT^^^T ПО И9Т9РИИ ^ят^т)
		Запрос на получение
		истории болезни

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

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

Рис. 3.4. Начальная контекстная диаграмма

СТРОКА_ПРИЕМА* Номер_приема /* порядковый номер приема нового боль­ ного V

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

СТРОКА_КУРСА__ЛЕЧЕНИЯ* Наименование_заболевания Имя_врача Специализация

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

СТРОКА_РЕЗУЛЬТАТОВ_ЛЕЧЕНИЯ* Дата Время

Примечание

ИНФОРМАЦИЯ.ОТ^ВРАЧА

Прием_нового_больного Данные_о_враче Новый_пациент_больницы Запрос_на_получение__истории_болезни Курс_лечения

ОТЧЕТ^О^ПАЦИЕНТАХ

Текущая__дата Начальная_^ата Конечная_дата

СТРОКА_ПАЦИЕНТА* Номер_пациента Фио Адрес Телефон

Дата__рождения СТРАХОВАНИЕ^ Страховая_компания Номер_страховки

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

Выделим и нарисуем сущности для каждого класса объек­ тов данных в системе приема пациентов. Рассмотрим каждую возможную пару сущностей и установим существование связи между ними. Нарисуем диаграмму «сущность-связь». Присво­ им наименование каждой связи и зададим ее характеристики (рис. 3.5).

Предлагается ответить самостоятельно на следующие воп­ росы:

1.Почему мощность связи между Пациентом и Приемом, Приемом и Курсом лечения, Врачом и Курсом лечения рав­ на О, а не 1?

2.Почему отсутствует связь между Врачом и Пациентом?

240

Глава 3

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

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

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

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

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

Накопитель данных: пациенты Номер_пациента Фио Адрес Телефон

Дата_рождения Группа__крови Страхование^

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