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

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

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

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

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

• в каждую функцию не может входить более одной стрелки,

«запускающей» выполнение функции, и выходить не более

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

функции.

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

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

Входящий

документ 1

Событие 1

provides input for

creates output to

Цаииые no

отгрузке

склада

lies on

Исходящий

документ 1

Ю-Склад

Рис.

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

Из рис. 3.1 и 3.2 видно, что бизнес-процесс в нотации еЕРС

представляет собой поток последовательно выполняемых работ

(процедур, функций), расположенных в порядке их выполнения.

Реальная длительность выполнения процедур в еЕРС визуально

не отражается. Это приводит к тому, что при создании моделей

возможны ситуации, когда на одного исполнителя будет возло-

жено выполнение двух задач одновременно. Используемые при

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

ние и слияние бизнес-процесса. Для получения информации о

232

Глава

реальной длительности процессов необходимо использовать дру-

гие инструменты описания, например фафики Ганта в системе

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.

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

самом простом виде может быть описан как множество деятель-

ностей. Метод Eriksson-Penker представляет образец процесса на

диафамме деятельности (рис. 3.3) в виде деятельности со стерео-

типом «process» (в качестве основы данного образца использова-

но представление процесса

методе IDEFO, расширенное за счет

введения цели процесса). Процесс использует входные ресурсы и

формирует выходные ресурсы, показанные в виде объектов со

стереотипом «resourse», соединенных с процессом связями зави-

симости. Ресурсы, ифающие в методе IDEFO роли «управления»

и «механизма», также соединены с процессом связями зависи-

мости со стереотипами «supply» и «control». Цель процесса пока-

зана как объект со стереотипом «goal».

«resourse»

Out; aQlass

«control»

Рис.

3.3.

Диаграмма деятельности для

процесса

Полная бизнес-модель включает множество представлений,

подобных представлениям архитектуры ПО. Каждое представле-

ние выражено в одной или более диафаммах. Диафаммы могут

иметь различные типы и изображать процессы, правила, цели и

ресурсы во взаимодействиях

друг с

другом.

Метод Eriksson-Penker

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

• концептуальное представление

—

структура целей и проблем

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

234

Глава

• представление процессов - взаимодействие между процес-

сами и ресурсами (в виде набора диаграмм деятельности);

• структурное представление

—

структура организации и ре-

сурсов (в

виде

диафамм классов).

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

из моделей этого представления можно привести образец

Employment из подразд. 2.6;

• представление поведения

—

поведение отдельных ресурсов

и детализация процессов (в виде диафамм деятельности,

состояний и взаимодействия).

3.2.5.

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

ПОДХОДА

данном примере используется методика Йордона, описан-

ная в подразд. 3.2.2.

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

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

ИС

для отдела

приема пациентов и медицинского секретариата. Новая система

предназначена для обработки данных о врачах, пациентах, прие-

ме пациентов и лечении. Система должна выдавать отчеты по

запросу врачей или администрации.

Во время обследования составлено следующее описание дея-

тельности рассматриваемых подразделений.

Перед приемом в больницу проводится встреча пациента и

врача. Врач информирует отдел приема пациентов об ожидаемом

приеме больного и передает о нем данные. Пациент может быть

принят

больницу более чем один раз, но если пациент ранее не

лечился в больнице, то ему присваивается регистрационный но-

мер и записываются его данные (фамилия, имя и отчество паци-

ента, адрес и дата рождения). Пациент должен быть зарегистри-

рован в системе до приема в больницу.

Через некоторое время врач оформляет

отделе приема паци-

ентов прием больного. При этом определяется порядковый но-

мер приема и запоминаются данные приема пациента. После

этого отдел приема посылает сообщение врачу для подтвержде-

ния приема больного.

это сообщение включаются регистраци-

онный номер пациента и его фамилия, порядковый номер прие-

ма, дата начала лечения и номер палаты.

день приема пациент сообщает

отдел приема о своем при-

бытии и передает

данные

о себе (или изменения

данных).

Отдел

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

приема проверяет и при необходимости корректирует данные о

пациенте. Если пациент

не

помнит свой регистрационный номер,

то выполняется соответствующий запрос. После регистрации па-

циент получает регистрационную карту, содержащую фамилию,

имя и отчество пациента, адрес, дату рождения, номер телефона,

группу крови, название страховой компании и номер страховки.

Во время пребывания в больнице пациент может лечиться у

нескольких врачей; каждый врач назначает один или более кур-

сов лечения, но каждый курс лечения назначается только одним

врачом. Данные о курсах лечения передаются в медицинский

секретариат, который занимается координацией лечения паци-

ентов, регистрируются и хранятся там. Данные включают номер

врача, номер пациента, порядковый номер приема, название

курса лечения, дату назначения, время и примечания.

При необходимости врач запрашивает в медицинском секре-

тариате историю болезни пациента, содержащую данные

курсах

лечения, полученных пациентом. История болезни представля-

ется в виде табл. 3.1.

После окончания курсов лечения лечащий врач принимает

решение о выписке пациента. Когда пациент выписывается, он

Таблица 3.1

История болезни пациента

История болезни

Дата: 01-02-1998

Данные с 01-01-1992 по 01-02-1998

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

732

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

|б49

ФИО:

Иванов СП.

Дата приема:

06-07-1992

Заболевание: перелом ноги

Дата

06-07-1992

20-07-1992

22-07-1992

Дата рождения: 15-07-55

Палата: 4

Врач: Петров П,С., хирург

Время

12.00

14.00

10.00

Примечание

Наложен гипс

Состояние хоро-

шее

Лечение закон-

чено

236

Глава 3

Продолжение

Заболевание: ОРЗ

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

711

Дата

10-07-1992

15-07-1992

20-07-1992

25-07-1992

Дата приема:

12-04-1993

Заболевание: сердечный приступ

Дата

Врач: Иванов А.С., терапевт

Время

10.00

Палата: 8

Примечание

Назначена тера-

пия

Состояние удов-

летворительное

Состояние хоро-

шее

Выписан

Врач: Сидоров И.И., кардиолог

Время

Примечание

сообщает об этом в отдел приема. Отдел приема регистрирует

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

справку об окончании пребывания в больнице.

Врач передает данные о себе и изменения в данных в отдел

приема. Данные о враче включают номер врача, фамилию, имя и

отчество, адрес, дату рождения, домашний телефон, специализа-

цию,

номер кабинета, рабочий телефон.

Администрация больницы может запросить отчет о пациен-

тах.

запросе указывается интервал времени (начальная

конеч-

ная даты). Отчет должен представляться в следующей форме

(табл. 3.2).

Администрация больницы запрашивает также обзор заболе-

ваний за последнюю неделю каждый понедельник

9.00.

Описание контекста системы приема пациентов

больнице и

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

Построим начальную контекстную диафамму потоков дан-

ных в нотации Гейна ~ Сэрсона (рис. 3.4). Нарисуем нулевой

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

Таблица 3.2

Отчет

пациентах

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

Данные с 01-12-1997 по 01-02-1998

Номер ФИО Адрес Телефон

Дата

рождения

Страхо-

вая ком-

пания

Номер

страховки

процесс и присвоим ему имя системы (Система приема пациен-

тов).

Поскольку моделируется деятельность отдела приема паци-

ентов и медицинского секретариата, внешними сущностями яв-

ляются Врач, Пациент и Администрация больницы. Нарисуем

внешние сущности и соединим их с нулевым процессом посред-

ством потоков данных.

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

Определим состав потоков данных и подготовим исходную ин-

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

Пометим символами «*», «°» и «|» все структуры и элементы

данных типа «итерация», «условное вхождение» и «альтернатива»

соответственно.

После объединения структур и элементов данных в более

крупные структуры для каждого потока данных должна быть

сформирована структура данных.

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

ОТЧЕТ^ПО^ИСТОРИИ^БОЛЕЗНИ

Текущая_дата

Начальная_дата

Конечная_дата

СТРОКА_ПАЦИЕНТА

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

Фио

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

238

Глава 3

Н Пациент к

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

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

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

карта

Справка о выписке

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

пациентов

QT^^^T

ПО

И9Т9РИИ ^ят^т)

Запрос на получение

истории болезни

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

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

больницы

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

больницы

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

СТРОКА_ПРИЕМА*

Номер_приема /* порядковый номер приема нового боль-

ного V

Дата_приема

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

СТРОКА_КУРСА__ЛЕЧЕНИЯ*

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

Имя_врача

Специализация

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

СТРОКА_РЕЗУЛЬТАТОВ_ЛЕЧЕНИЯ*

Дата

Время

Примечание

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

Прием_нового_больного

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

Новый_пациент_больницы

Запрос_на_получение__истории_болезни

Курс_лечения

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

Текущая__дата

Начальная_^ата

Конечная_дата

СТРОКА_ПАЦИЕНТА*

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

Фио

Адрес

Телефон

Дата__рождения

СТРАХОВАНИЕ^

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

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

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

Выделим и нарисуем сущности для каждого класса объек-

тов данных в системе приема пациентов. Рассмотрим каждую

возможную пару сущностей и установим существование связи

между ними. Нарисуем диаграмму «сущность-связь». Присво-

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

(рис.

3.5).

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

росы:

Почему мощность связи между Пациентом и Приемом,

Приемом и Курсом лечения, Врачом и Курсом лечения рав-

на

О,

а не 1?

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

240

Глава 3

Рис.

3.5.

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

Построение

диаграмм потоков данных

нулевого

последующих

уровней

Декомпозируем начальную контекстную диаграмму Деком-

позируем сложные процессы и проверим соответствие различных

уровней модели процессов. Опишем накопители данных посред-

ством структур данных. Опишем процессы нижнего уровня пос-

редством спецификаций.

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

Описание накопителей данных и пример спецификации про-

цесса приведены ниже.

Накопитель

данных:

пациенты

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

Фио

Адрес

Телефон

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

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

Страхование^

Накопитель

данных:

приемы

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

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

Дата_приема