1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom
.pdfМоделирование бизнес-процессов и спецификация требований 2 5 1
Ч/> Rationait Rose:^. |
В*шт!$»Ш!Ш$мШ^ |
м\Ш.Ш |
ШШ т t*^ |
mtfi^ ^M^f^ Eejsttrt I^H Ш-Ш v^Now Ши |
|
|
|
: Регистратор |
|
: Пассажир |
|
Пассажир предъявляет'^
билет регистратору. Регистратор
подтверждает
правильность билета. Регистратор
оформляет багаж.
Регистратор резервирует место для пассажира. Регистратор печатает посадочный талон. Регистратор выдает пассажиру
посадочный талон и
квитанцию на багаж.
1:Оформить посадочный талЬн()
2:Проверить правильность билета()
3:Оформить багажО
:<-
4: Зарезервировать местоО
5: Напечатать посадочный талон()
6: Принять посадочный Талон и квитанцию()
i^j^ |
_ |
j |
ш
Рис. 3.13. Диаграмма последовательности для основного сценария Business Use Case «Пройти регистрацию»
На данной диаграмме ассоциации между классами-исполните лями отражают наличие взаимодействия между реальными испол нителями (Регистратором и Координатором багажа). Ассоциации между классами-исполнителями и классами-сущностями показы вают, какими именно объектами манипулируют конкретные ис полнители (Регистратор имеет дело с Багажом и Багажной биркой, а Координатор багажа — только с Багажом). Ассоциации между классами-сущностями отражают различные структурные связи (к одному месту багажа прикрепляется одна багажная бирка).
Кроме диаграммы классов, модель бизнес-анализа может включать:
•Диаграммы последовательности (и кооперативные диафаммы), описывающие сценарии Business Use Case в виде после довательности обмена сообщениями между объектами-
2 5 2 |
Глава 3 |
действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора его операций. Пример диаграммы последовательности, описывающей основной сценарий 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)
•*• Оформить посадочный талонО
+Принять багажО
+Проверить правильность билетаО
+Оформить багажО
+Зарезервировать местоО
1+ Напечатать посадочный талонО
«business worker»
Координатор багажа (from Business Analysis Model)
«business entity»
Багаж
(from Business Analysis Model)
<<business entity»
Багажная бирка (from Business Analysis Model)
Ш
Ч-
зау^п^гг
Рис. 3.14. Модифицированная диаграмма классов модели бизнес-ана лиза с операциями
Моделирование бизнес-процессов и спецификация требований 2 5 3
' V Rational Rose - Biisiness-mo<teiz.rtwr'^:f А С ^ Ш У ; » ! ^
/^ |
Зака1атк |
Л |
/ |
создать |
\ |
Новый saxas: |
|
|
|
|
|
Зака» |
|
|
|
||||||
V |
продусты |
У" |
^ |
|ака< |
У |
|
|
|
|
|
|
|
|
|
|
|
[Создан] |
|
|
|
|
|
|
|
|
|
|
/'Приобрести |
Л |
|
|
|
|
|
|
|
|
|
1^ |
продукты |
J |
|
|
|
|
|
|
|
|
|
Доставить |
|
Выполненный |
|
|
|
|
|
|
|
( |
|
>ака»: Заказ |
|
|
|
|
|
|
|
|
продукты |
|
|
||
|
|
|
|
|
|
[[Выполнен] |
)1 |
|||
/Произвести Л ^ |
|
|
|
|
|
|
Выставить |
|||
V |
оплату |
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 : ШШШЁ^^жШМлШ.^^^
1 |
|
,.^| |
|
|
ж |
R |
Q Вшши Шф'Ст^ Model |
|
1 |
Э |
Business Use^Case Diagram |
1 |
Ш •Щ Пдссджир |
|
1 |
Ш ^ |
Рукоетигель туристической гр5рты |
1 |
\$ О* |
3aperv4GTpi^xs5STto гр«^пг^ |
|
Ш О |
Пройти рвгистраи»«о |
ZШ " ^ As$odatbns
ВСи Log»alView ГС'С|Ап«И<5 Model
В d Ви^юе^хАпаИЬ Model
В |
СЗ Business и«е'Са«е Redizaiioiu |
, |
В О «Ьише$« use^as© realfealbn» Прс^ирегистрацию |
л |
$
Л"
|
|
'" ^ |
Щ |
SequenceDiagf^n |
|
|
|
|
|
Associations |
|
|
|||
] |
Ф |
S |
А©ид/м*^й |
^ |
|
||
|
Ш S |
Б^аж |
|
|
|||
|
^ |
Q |
Багажная биужа |
|
|
||
|
Ё1 Q |
Билет |
|
|
|
||
|
Ш ® |
Координате^ багажа |
V ' |
1 |
|||
|
Ш ® |
Регистратор |
^ 1 |
||||
|
Ш Q |
Рейс |
|
||||
|
Ш |
" ^ |
Associations |
||||
i l „ — „ |
- . |
. |
•,•„, |
-., п.: „,:,: , - . ; , у_| |
±1^ |
1 |
|
Рис. 3.16. Пример структуры бизнес-модели
Моделирование бизнес-процессов и спецификация требований 255
Методика моделирования Rational Unified Process обладает следующими достоинствами:
•модель бизнес-процессов строится вокруг участников про цессов (заинтересованных лиц) и их целей, помогая выя вить все потребности клиентов организации. Нетрудно за метить, что такой подход в наибольшей степени применим для организаций, работающих в сфере оказания услуг (тор говые организации, банки, страховые компании и т.д.);
•моделирование на основе вариантов использования способ ствует хорошему пониманию бизнес-модели со стороны за казчиков.
Однако следует отметить, что при моделировании деятель ности крупной организации, занимающейся как производством продукции, так и оказанием услуг, необходимо применять раз личные методики моделирования, поскольку для моделирования производственных процессов более предпочтительным является процессный подход (например, метод Eriksson-Репкег).
3.3.2. ПРИМЕР ИСПОЛЬЗОВАНИЯ ОБЪЕКТНООРИЕНТИРОВАННОГО ПОДХОДА
В данном примере используется методика Rational Unified Process, описанная в предьщущем подразделе.
Постановка задачи
Перед руководителем информационной службы университе та ставится задача разработки автоматизированной системы ре гистрации студентов на дополнительные платные курсы. Систе ма должна позволять студентам регистрироваться на курсы и просматривать свои табели успеваемости с персональных компь ютеров, подключенных к локальной сети университета. Профес сора должны иметь доступ к системе, чтобы указать курсы, кото рые они будут читать, и проставить оценки за курсы.
В настоящее время в университете функционирует база дан ных, содержащая всю информацию о курсах (каталог курсов). Ре гистрация на курсы происходит следующим образом: в начале каждого семестра студенты могут запросить у регистратора ката лог курсов, содержащий список курсов, предлагаемых в данном семестре. Информация о каждом курсе должна включать имя
256 |
Глава 3 |
профессора, наименование кафедры и требования к предвари тельному уровню подготовки (прослушанным курсам).
Студент может выбрать 4 курса в предстоящем семестре. В до полнение к этому каждый студент может указать 2 альтернатив ных курса на тот случай, если какой-либо из выбранных им кур сов окажется уже заполненным или отмененным. На каждый курс может записаться не более 10 и не менее 3 студентов (если менее 3, то курс будет отменен). В каждом семестре существует период времени, когда студенты могут изменить свои планы (добавить или отказаться от выбранных курсов). После того, как процесс ре гистрации некоторого студента завершен, регистратор направляет информацию в расчетную систему, чтобы студент мог внести пла ту за семестр. Если курс окажется заполненным в процессе реги страции, студент должен быть извещен об этом до окончательно го формирования его личного учебного плана. В конце семестра студенты могут просмотреть свои табели успеваемости.
Создание модели бизнес-процессов
Действующие лица:
•Студент — записывается на курсы и просматривает свой табель ус певаемости.
•Профессор - выбирает курсы для преподавания и ставит оценки за курсы.
•Расчетная система - получает информацию по оплате за курсы.
•Каталог курсов - база данных, содержащая информацию о курсах.
Варианты использования:
Исходя из потребностей действующих лиц, выделяются следующие варианты использования (Business Use Case):
•Зарегистрироваться на курсы;
•Просмотреть табель успеваемости;
•Выбрать курсы для преподавания;
•Проставить оценки.
Диафамма вариантов использования для модели бизнес-процессов показана на рис. 3.17.
Пример спецификации Business Use Case «Зарегистрироваться на курсы»:
Наименование:
Зарегистрироваться на курсы.
Краткое описание:
Моделирование бизнес-процессов и спецификация требований |
2 5 7 |
%^ Rational Rose>^:ссм1г5ёгёдй;1(Е1Щ1ЯШШ1^Ш|Ш |
|
^ ^d»t Vjew Щгт^ ^Qm^ gt^porl; ^ w r y X<jols , ^stdhlns vjfintlow j:|elp |
^ i S J i S J |
Зарегистрироваться на курсы расчетная система
Студент
Просмотреть табель успеваемости
Каталог курсов
Выбрать курсы для преподавания
Профессор |
Проставить оценки |
Рис. 3.17. Диаграмма вариантов использования для модели бизнес-процессов
Данный Business Use Case позволяет студенту зарегистрироваться на предлагаемые курсы в текущем семестре. Студент может изменить свой выбор, если изменение выполняется в установленное время в начале се местра.
Основной сценарий:
1.Студент приходит к регистратору и просит зарегистрировать его на предлагаемые курсы или изменить свой график курсов.
2.В зависимости от запроса студента, выполняется один из подчи ненных сценариев (создать график или изменить график).
Подчиненный сценарий «Создать график»:
1.Регистратор выполняет поиск в каталоге доступных в настоящий момент курсов и выдает студенту их список.
2.Студент выбирает из списка 4 основных и 2 альтернативных курса.
258 |
Глава 3 |
3.Регистратор формирует график студента.
4.Выполняется подчиненный сценарий «Принять график».
Подчиненный сценарий «Изменить график»:
1.Регистратор находит текущий график студента.
2.Регистратор выполняет поиск в каталоге доступных в настоящий момент курсов и выдает студенту их список.
3.Студент может изменить свой выбор курсов, удаляя или добавляя конкретные курсы.
4.После выбора регистратор обновляет график.
5.Выполняется подчиненный сценарий «Принять график».
Подчиненный сценарий «Принять график»:
1.Для каждого выбранного студентом курса регистратор подтверж дает выполнение студентом предварительных требований (прохождение определенных курсов), факт открытия предлагаемого курса и отсутствие конфликтов графика.
2.Регистратор вносит студента в список каждого выбранного пред лагаемого курса. Курс фиксируется в графике.
Альтернативные сценарии.
Не выполнены предварительные требования, курс заполнен или имеют место конфликты графика.
Если во время выполнения подчиненного сценария «Принять фафик» регистратор обнаружит, что студент не выполнил необходимые предварительные требования, или выбранный им предлагаемый курс заполнен (уже записалось 10 студентов), или имеют место конфликты графика (два или более курсов с совпадающим расписанием), то он предлагает студенту изменить свой выбор курсов либо отменить форми рование графика и вернуться к нему позже.
Система каталога курсов недоступна:
Если во время поиска в каталоге курсов окажется, что невозможно установить связь с системой каталога курсов, то регистрацию придется прервать и дождаться восстановления связи.
Регистрация на курсы закончена:
Если в самом начале выполнения регистрации окажется, что регист рация на текущий семестр уже закончена, то процесс завершится.
Создание модели бизнес-анализа
Исполнители,
• Регистратор — формирует учебный план и каталог курсов, записы вает студентов на курсы, ведет все данные о курсах, профессорах, успеваемости и студентах.
Сущности.
•Студент.
•Профессор.
•График студента (список курсов).
Моделирование бизнес-процессов и спецификация требований 25 9
•Курс (в профамме обучения).
•Конкретный курс (курс в расписании).
Диаграмма классов для модели бизнес-анализа, описывающей 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» |
«Business Entity» |
Студент |
Предлагаемый курс |
(from Business Analysis Model) |
(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
циональные и нефункциональные. Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Нефункциональ ные требования описывают атрибуты системы (технические ха рактеристики) и ее окружения.
Для выявления требований используются (в различных соче таниях) следующие методы:
•собеседование (интервьюирование);
•анкетирование;
•моделирование и анализ бизнес-процессов (далее будет рас смотрена методика перехода от объектной бизнес-модели к системным требованиям);
•сессии по выявлению требований (мозговой штурм);
•создание и демонстрация пользователям работающих про тотипов приложений (для выявления замечаний и дополни тельных требований).
Собеседование — наиболее часто используемый и обычно наи более полезный метод выявления требований. При использова нии интервью может быть поставлено несколько целей, таких, как выяснение, проверка и толкование фактов, формирование заинтересованности, привлечение пользователей к работе, сбор предложений и мнений. Но метод собеседования требует для эф фективного контакта хороших навыков общения с людьми, име ющими различные ценности, приоритеты, мнения, побуждения и индивидуальные особенности. Преимущества метода собеседо вания заключаются в следующем:
•опрашиваемое лицо может свободно и открыто отвечать на вопросы и почувствовать себя участником проекта;
•лицо, проводящее собеседование, может наблюдать за пове дением опрашиваемого лица, изменять ход опроса, пере формулировать или иначе строить вопросы во время собесе
дования.
Недостатки метода собеседования:
•метод трудоемкий и дорогой, поэтому может оказаться не практичным;
•успех собеседования зависит от навыков общения лица, проводящего собеседование, и от желания опрашиваемых лиц участвовать в интервью.