n1

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

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

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

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

Событие 1

Ю-Склад

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

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

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

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

«resourse»

Out; aQlass

«control»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.2

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

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

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

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

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

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

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

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

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

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

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

НПациент к

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

карта

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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