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

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

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

Ч/>

Rationait

Rose:^.

В*шт!$»Ш!Ш$мШ^

ШШ т t*^

mtfi^

^M^f^ Eejsttrt I^H Ш-Ш v^Now Ши

м\Ш.Ш

: Регистратор

Пассажир предъявляет'^

билет регистратору.

Регистратор

подтверждает

правильность билета.

Регистратор

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

Регистратор

резервирует место для

пассажира.

Регистратор печатает

посадочный талон.

Регистратор выдает

пассажиру

посадочный талон и

квитанцию на багаж.

: Пассажир

Оформить посадочный талЬн()

Проверить правильность билета()

3: Оформить багажО

:<-

Зарезервировать местоО

5: Напечатать посадочный талон()

6: Принять посадочный Талон и квитанцию()

i^j^

_ j

Рис.

3.13.

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

Use Case «Пройти регистрацию»

На данной диаграмме ассоциации между классами-исполните-

лями отражают наличие взаимодействия

между

реальными испол-

нителями (Регистратором и Координатором багажа). Ассоциации

между классами-исполнителями и классами-сущностями показы-

вают, какими именно объектами манипулируют конкретные ис-

полнители (Регистратор имеет дело

Багажом

Багажной биркой,

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

—

только с Багажом). Ассоциации между

классами-сущностями отражают различные структурные связи (к

одному месту багажа прикрепляется одна багажная бирка).

Кроме диаграммы классов, модель бизнес-анализа может

включать:

• Диаграммы последовательности (и кооперативные диафам-

мы),

описывающие сценарии Business Use Case

виде после-

довательности обмена сообщениями между объектами-

252

Глава

действующими лицами

объектами-исполнителями. Такие

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

модели обязанности

каждого исполнителя

виде набора его операций. Пример

диаграммы последовательности, описывающей основной

сценарий Business Use Case «Пройти регистрацию», приве-

ден на

рис.

3.13.

Модифицированная диафамма классов мо-

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

рис.

3.14.

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

потоками объектов

«плава-

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

сценариями одного или различных Business Use Case. При-

мер такой диаграммы для процесса заказа товаров

торго-

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

рис.

3.15.

• Диаграммы состояний, описывающие поведение отдельных

бизнес-объектов (например, для сущности «Багаж» можно

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

«Зарегистрирован», «Находится на транспортере» и т.д.).

•с> Rational Rose

Bustne«s-modetmd|

- Ш^е* ;Р1адг«Ш:8^*1лш^^^

jJBl'i'y

^й<!^

Ш^

fami ira«i$y Sfiporl; liSi^y :jwly

''ШШ-

«business worker»

Регистратор

(from Business Analysis Model)

•*•

Оформить посадочный талонО

+ Принять багажО

+ Проверить правильность билетаО

+ Оформить багажО

+ Зарезервировать местоО

Напечатать посадочный талонО

<<business entity»

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

(from Business Analysis Model)

зау^п^гг

«business worker»

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

(from Business Analysis Model)

«business entity»

Багаж

(from Business Analysis Model)

Ч-

Рис.

3.14.

Модифицированная

диаграмма классов модели

бизнес-ана-

лиза с

операциями

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

' V Rational Rose - Biisiness-mo<teiz.rtwr'^:f

АС^ШУ;»!^

/^ Зака1атк Л

V продусты У"

/ создать \

|ака<

Новый saxas:

Зака»

[Создан]

/Произвести Л^

V оплату J^-

/'Приобрести Л

продукты J

(

Доставить

продукты

Выполненный

>ака»: Заказ

[[Выполнен]

Выставить

счет клиенту

Счет:

Счет

Обработать \

1теж J

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

Методика моделирования Rational Unified Process предусмат-

ривает специальное соглашение, связанное с группировкой

структурных элементов

диаграмм бизнес-модели. Это соглаше-

ние включает следующие правила:

•

Все

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

диаграм-

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

щаются в пакет

именем Business Use Case Model.

• Все классы и диаграммы моделей бизнес-анализа помеща-

ются в пакет с именем Business Analysis Model.

• Если моделируется деятельность более чем одного подраз-

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

нителей и классов-сущностей из моделей бизнес-анализа

для различных Business Use Case разделяется на пакеты, со-

ответствующие этим подразделениям. Этим пакетам прис-

ваиваются наименования подразделений (например. Бух-

254

Глава 3

галтерия, Отдел доставки и т.п.) и стереотип

«organization

unit»

(организационная единица).

• Диаграммы модели бизнес-анализа, относящиеся к конк-

ретному Business Use Case (диаграммы классов, последова-

тельности, деятельности и состояний) помещаются

коопе-

рацию (см. подразд. 2.6) с именем данного Business Use Case

и стереотипом

«business use-case realization»

(реализация биз-

нес-процесса). Все кооперации помещаются в пакет с име-

нем Business Use Case Realizations.

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

пассажиров в аэропорту приведен на

рис.

3.16.

л|

Л"

|?^!1ШШШ

.Р^ЙШ

- :Biisifte^-ma«l«l

1.^**^1

: ШШШЁ^^ж

R Q Вшши Шф'Ст^ Model

1 Э Business

Use^Case

Diagram

1 Ш •Щ Пдссджир

1 Ш ^ Рукоетигель туристической гр5рты

1 \$ О* 3aperv4GTpi^xs5STto гр«^пг^

Ш О

Пройти

рвгистраи»«о

Ш "^ As$odatbns

В Си Log»alView

ГС'С|Ап«И<5 Model

В d Ви^юе^хАпаИЬ Model

В СЗ Business и«е'Са«е Redizaiioiu

, В О «Ьише$« use^as© realfealbn» Прс^и

Щ SequenceDiagf^n

'" ^ Associations

] Ф S А©ид/м*^й

Ш S Б^аж

^ Q Багажная биужа

Ё1 Q Билет

Ш ® Координате^ багажа

Ш ® Регистратор

Ш Q Рейс

Ш "^ Associations

il„—„-..

•,•„, -., п.: „,:,: , - . ;, у

ШМлШ.^^^

регистрацию

,.^|

' 1

^ 1

±1^

Рис. 3.16. Пример структуры бизнес-модели

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

Методика моделирования Rational Unified Process обладает

следующими достоинствами:

• модель бизнес-процессов строится вокруг участников про-

цессов (заинтересованных лиц) и их целей, помогая выя-

вить все потребности клиентов организации. Нетрудно за-

метить, что такой подход в наибольшей степени применим

для организаций, работающих в сфере оказания услуг (тор-

говые организации, банки, страховые компании и т.д.);

• моделирование на основе вариантов использования способ-

ствует хорошему пониманию бизнес-модели со стороны за-

казчиков.

Однако следует отметить, что при моделировании деятель-

ности крупной организации, занимающейся как производством

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

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

для

моделирования

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

процессный подход (например, метод Eriksson-Репкег).

3.3.2.

ПРИМЕР ИСПОЛЬЗОВАНИЯ ОБЪЕКТНО-

ОРИЕНТИРОВАННОГО ПОДХОДА

В данном примере используется методика Rational Unified

Process, описанная в предьщущем подразделе.

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

Перед руководителем информационной службы университе-

та ставится задача разработки автоматизированной системы ре-

гистрации студентов на дополнительные платные курсы. Систе-

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

просматривать свои табели успеваемости с персональных компь-

ютеров, подключенных к локальной сети университета. Профес-

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

рые они будут читать, и проставить оценки за курсы.

В настоящее время в университете функционирует база дан-

ных, содержащая всю информацию

курсах (каталог

курсов).

Ре-

гистрация на курсы происходит следующим образом: в начале

каждого семестра студенты могут запросить у регистратора ката-

лог курсов, содержащий список курсов, предлагаемых в данном

семестре. Информация о каждом курсе должна включать имя

256 Глава 3

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

тельному уровню подготовки (прослушанным курсам).

Студент может выбрать 4 курса в предстоящем семестре.

до-

полнение к этому каждый студент может указать 2 альтернатив-

ных курса на тот случай, если какой-либо из выбранных им кур-

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

может записаться не более 10 и не менее 3 студентов (если менее

то курс будет отменен). В каждом семестре существует период

времени, когда студенты могут изменить свои планы (добавить

или отказаться от выбранных курсов). После того, как процесс ре-

гистрации некоторого студента завершен, регистратор направляет

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

ту за семестр. Если курс окажется заполненным в процессе реги-

страции, студент должен быть извещен об этом до окончательно-

го формирования его личного учебного плана. В конце семестра

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

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

Действующие

лица:

• Студент

—

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

певаемости.

• Профессор - выбирает курсы для преподавания и ставит оценки

за курсы.

• Расчетная система - получает информацию по оплате за курсы.

• Каталог курсов - база данных, содержащая информацию о курсах.

Варианты

использования:

Исходя из потребностей действующих лиц, выделяются следующие

варианты использования (Business Use Case):

• Зарегистрироваться на курсы;

• Просмотреть табель успеваемости;

• Выбрать курсы для преподавания;

• Проставить оценки.

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

показана на рис. 3.17.

Пример спецификации Business Use Case «Зарегистрироваться на

курсы»:

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

Зарегистрироваться на курсы.

Краткое

описание:

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

Rational Rose >^ :ссм1г5ёгёдй;1(Е1Щ1ЯШШ1^Ш|Ш

^ ^d»t

Vjew

Щгт^ ^Qm^

gt^porl;

^wry

X<jols , ^stdhlns vjfintlow j:|elp ^iSJiSJ

Студент

Зарегистрироваться на курсы расчетная

система

Просмотреть табель

успеваемости

Каталог курсов

Выбрать курсы для преподавания

Профессор Проставить оценки

Рис. 3.17.

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

для

модели

бизнес-процессов

Данный Business Use Case позволяет студенту зарегистрироваться на

предлагаемые курсы

текущем семестре. Студент может изменить свой

выбор, если изменение выполняется

установленное время в начале се-

местра.

Основной

сценарий:

Студент приходит к регистратору и просит зарегистрировать его

на предлагаемые курсы или изменить свой график курсов.

2. В

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

ненных сценариев (создать график или изменить график).

Подчиненный сценарий «Создать

график»:

Регистратор выполняет поиск в каталоге доступных в настоящий

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

Студент выбирает

из

списка

основных

и 2

альтернативных курса.

258 Глава 3

Регистратор формирует график студента.

Выполняется подчиненный сценарий «Принять график».

Подчиненный сценарий «Изменить

график»:

Регистратор находит текущий график студента.

Регистратор выполняет поиск в каталоге доступных в настоящий

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

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

конкретные курсы.

После выбора регистратор обновляет график.

Выполняется подчиненный сценарий «Принять график».

Подчиненный сценарий «Принять

график»:

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

дает выполнение студентом предварительных требований (прохождение

определенных курсов), факт открытия предлагаемого курса и отсутствие

конфликтов графика.

Регистратор вносит студента в список каждого выбранного пред-

лагаемого курса. Курс фиксируется в графике.

Альтернативные

сценарии.

Не

выполнены предварительные

требования,

курс

заполнен

или имеют

место

конфликты

графика.

Если во время выполнения подчиненного сценария «Принять фа-

фик» регистратор обнаружит, что студент не выполнил необходимые

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

заполнен (уже записалось 10 студентов), или имеют место конфликты

графика (два или более курсов с совпадающим расписанием), то он

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

рование графика и вернуться к нему позже.

Система

каталога курсов

недоступна:

Если во время поиска в каталоге курсов окажется, что невозможно

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

прервать и дождаться восстановления связи.

Регистрация

на

курсы

закончена:

Если в самом начале выполнения регистрации окажется, что регист-

рация на текущий семестр уже закончена, то процесс завершится.

Создание модели бизнес-анализа

Исполнители,

• Регистратор

—

формирует учебный план и каталог курсов, записы-

вает студентов на курсы, ведет все данные о курсах, профессорах,

успеваемости и студентах.

Сущности.

• Студент.

• Профессор.

• График студента (список курсов).

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

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

259

• Курс

(в

профамме обучения).

• Конкретный курс (курс

расписании).

Диаграмма классов

для

модели бизнес-анализа, описывающей

Business Use Case «Зарегистрироваться

на

курсы», приведена на

рис.

3.18.

^' Rational Rose -^Шиг^ШтШ^^ШШШШтШШШШ

\'Ш

i^ W^

Fsitn^at it»iy$e

^t»t^

Qpery

Jpci^

i^lm ^^4<m Hdp

«Business Worker»

Регистратор

(from Business Analysis Model)

«Business Entity»

Студент

(from Business Analysis Model)

«Business Entity»

Предлагаемый курс

(from Business Analysis Model)

+АльтернативиЬ1й

0..2

«Business Entity»

График

(from Business Analysis Model)

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

3.4.

СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ

К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ^

3.4.1.

ОСНОВЫ СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ

К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

ПО является составной частью

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

1.5).

качестве

повторения отметим, что все требования

ПО делятся

на

функ-

Методической основой данного подраздела является технология

Rational Unified Process.

260 Глава 3

циональные и нефункциональные.

Функциональные требования

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

учета ограничений, связанных с ее реализацией.

Нефункциональ-

ные требования

описывают атрибуты системы (технические ха-

рактеристики) и ее окружения.

Для выявления требований используются (в различных соче-

таниях) следующие методы:

• собеседование (интервьюирование);

• анкетирование;

• моделирование и анализ бизнес-процессов (далее

будет

рас-

смотрена методика перехода от объектной бизнес-модели к

системным требованиям);

• сессии по выявлению требований (мозговой штурм);

• создание и демонстрация пользователям работающих про-

тотипов приложений (для выявления замечаний

дополни-

тельных требований).

Собеседование —

наиболее часто используемый и обычно наи-

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

нии интервью может быть поставлено несколько целей, таких,

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

заинтересованности, привлечение пользователей к работе, сбор

предложений и мнений. Но метод собеседования требует

для

эф-

фективного контакта хороших навыков общения

людьми, име-

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

и индивидуальные особенности. Преимущества метода собеседо-

вания заключаются в следующем:

• опрашиваемое лицо может свободно и открыто отвечать на

вопросы и почувствовать себя участником проекта;

• лицо, проводящее собеседование, может наблюдать за пове-

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

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

дования.

Недостатки метода собеседования:

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

практичным;

• успех собеседования зависит от навыков общения лица,

проводящего собеседование, и от желания опрашиваемых

лиц участвовать в интервью.