Вигерс Карл. Разработка требований к программному обеспечению

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

Правила бизнеса

Согласно определению Business Rules Group

(1993),

«бизнес-правило —

это положение, определяющее или ограничивающее какие-либо

сто-

роны бизнеса; его назначение — защитить структуру

бизнеса,

контро-

лировать или влиять на его операции». Целые методологии разработа-

ны специально для

создания

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

применения в автоматизированных системах (Ross,

1997;

von

Hall'ii,

2002). Если вы не создаете систему, которая в значительной степени

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

гия вам не нужна. Достаточно выявить и задокументировать относя-

щиеся к вашей системе правила и связать их с конкретными

функцио-

нальными требованиями,

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

таксономии (схем

классификации)

(Ross,

2001;

Morgan, 2002; von Halle,

2002). Простейшая из них (рис. 9-1), из пяти типов бизнес-правил, го-

дится в большинстве случаев. Шестая категория — термины: важные

для бизнеса слова, фразы и аббревиатуры. Их удобно хранить в

слова-

ре. Вести согласованный свод бизнес-правил гораздо важнее при раз-

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

ровать. Давайте рассмотрим различные типы бизнес-правил, с которы-

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

Факты

Ограничения

Активаторы

операций

Рис.

9-1.

Простая таксономия бизнес-правил

Факты

Факты (facts) — это всего лишь верные утверждения о бизнесе. За-

частую они описывают связи и отношения между важными бизнес-

терминами. Факты также называют инвариантами — неизменными

истинами о сущности данных и их атрибутах. Бизнес-правила во

мно-

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

ние обычно не преобразуются напрямую в функциональные

требова-

ния к ПО. Сведения о сущности данных, важных для системы, иногда

Глава 9. Игра по правилам

163

применяют в моделях данных,

создаваемых

аналитиком или архитек-

тором БД (подробнее о моделировании данных — в главе

11).

Вот примеры фактов:

1 на каждый химический контейнер нанесен уникальный штрих-код;

оплачивается доставка каждого заказа;

i каждый элемент заказа содержит данные о химикате, его

качестве,

размере контейнера и числе контейнеров;

1 стоимость билетов не возвращается, если покупатель изменяет

маршрут;

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

Ограничения

Ограничения (constraints) — определяют, какие операции может выпол-

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

часто применяются при описании ограничивающего бизнес-правила:

должен, не должен, не может и только. Например, в таких комбинациях:

I договор о займе человека младше

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

из его родителей или законный опекун;

I постоянный посетитель библиотеки может отложить для себя до

книг;

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

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

месяцев он прошел

обучающий курс работы с опасными соединениями;

1 все программы должны соответствовать правительственным поста-

новлениям, касающимся использования их людьми с ослабленным

зрением;

I в корреспонденции не может отображаться больше 4 цифр номера

социального страхования гражданина;

I экипажи коммерческих авиарейсов должны каждые 24 часа отды-

хать не менее 8 часов.

Так много ограничений

У проектов по разработке ПО множество разных ограничений. Менеджеры проекта

должны соблюдать расписание, а также лимиты по персоналу и бюджету. Эти огра-

ничения уровня проекта фиксируются в плане

управления

проектом по разработке

ПО. Ограничения уровня продукта на проектирование и реализацию, уменьшающие

доступные разработчику возможности, записаны в спецификации требований к ПО

или спецификации архитектуры. Многие бизнес-правила налагают ограничения на

164

Часть II. Разработка требований к ПО

деловые

операции. Когда бы эти ограничения ни были отражены в функциональных

требованиях к ПО, следует указать соответствующие правила в качестве обоснова-

ния всех производных требований.

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

оп-

ределяющие порядок доступа к информационным системам. Обычно

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

менять,

можно ли применять старые пароли и т.д. Все эти ограниче-

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

вилами. Ввод каждого такого правила в конкретный код упрощает

об-

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

например

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

до

30 дней.

Как мне отказали

Недавно я хотел заказать, используя часть моих

«миль

постоянного клиента» авиа-

компании

Ry-By-Night

Airlines, билет для моей жены Крис. Когда я

попытался

сде-

лать это, сервер FlyByNight.com

сообщил

мне, что из-за возникшей ошибки выдача

билета невозможна, и предложил немедленно позвонить по номеру 800-FLY-NITE.

Менеджер по бронированию, который поднял трубку, сообщил, что авиакомпания

не может оформить премиальный билет за налетанные мной мили по обычной или

электронной

почте, поскольку у меня и Крис разные фамилии. Для получения билета

мне пришлось ехать в кассу аэропорта и предъявлять удостоверение личности.

Данный инцидент вызван следующим ограничивающим бизнес-правилом: «Если фа-

милия пассажира отличается от фамилии лица, оформляющего премиальный билет

за налетанные

мили,

лицо, оформляющее билет, должно получить его лично». По-

видимому, основание для этого бизнес-правила - предотвращение мошенничества.

ПО

Web-узла Ry-By-Night исправно реализует данное

правило,

но создает неудобст-

ва клиентам. Вместо того, чтобы сообщить мне о правиле, касающемся разных фа-

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

преждение об ошибке. В результате мы с менеджером компании

Fly-By-Night

по

бронированию потратили время на ненужный телефонный разговор. Плохо проду-

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

и,

следова-

тельно, отрицательно скажутся на вашем бизнесе.

Активаторы операций

Правило, при определенных условиях приводящее к выполнению ка-

ких-либо действий,

называется

активатором операции (action en-

abler). Человек может выполнять эти действия вручную. Как вариант,

Глава 9. Игра по правилам

165

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

функциями,

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

вий реализует нужную модель поведения. Условия, определяющие вы -

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

цию значений

«истина»

«ложь»,

выполняющихся для нескольких от-

дельных условий. Таблица решений, такая, как в главе

11,

— это

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

операции

бизнес-правил расширенной логики. Выражение вида «Если

<некото~

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

событие>,

то

<что-тс

произойдет>»,

— это ключ, который описывает активатор операции.

Вот несколько примеров таких бизнес-правил:

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

следует предложить запросившему химикат лицу;

I если срок хранения контейнера с химикатом истек, об этом необхо-

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

тейнер;

1 в последний день квартала должны генерироваться отчеты для

Управления по безопасности труда и Агентства по защите окружаю-

щей среды

охранении

и использовании химикатов в этом квартале;

I если клиент заказал книгу автора, написавшего несколько книг, кли-

енту следует предложить другие книги этого автора, прежде чем

принять заказ,

Выводы

Выводы (inference), иногда его еще называют предположительным

знанием,

— это правило, устанавливающее новые реалии на основе

достоверности определенных условий. Вывод создает новый факт на

основе других фактов или вычислений. Выводы зачастую записывают

в формате «если — то», применяемом также при записи бизнес-пра-

вил, активирующих операции; тем не менее, раздел «то» вывода за-

ключает в себе факт или предположение, а не действие. Вот несколько

примеров выводов:

i если платеж не поступил в течение 30 календарных дней с момента

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

если поставщик не может поставить заказанный товар в течение пя-

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

ным;

166

Часть

II.

Разработка требований к ПО

I считается, что срок хранения контейнеров с химикатами,

разлагаю-

щимися на взрывоопасные составляющие, истекает через один год

даты изготовления;

химикаты с токсичностью агента LD50 ниже 5 мг на килограмм

мас-

сы мыши считаются опасными.

Вычисления

Компьютеры осуществляют вычисления, и поэтому один из

классов

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

(computations),

выполняемые

с использованием математических формул и алгоритмов. Многие

вь-

числения выполняются по внешним для предприятия

правилам,

например по формулам удержания подоходного налога. В отличие сг

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

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

требова-

ния к ПО, правила вычислений в той форме, в которой они выражены,

можно рассматривать в качестве требований к ПО. Ниже в текстовой

форме дано несколько примеров бизнес-правил для вычислений;

к&к

вариант, их можно представить в символьной форме, например в виде

математического выражения. Представление таких правил в виде

таб-

лицы (табл.

9-1)

гораздо

понятнее,

чем длинный список сложных

тек-

стовых выражений:

цена единицы товара снижается на 10% при заказе от 6 до 10

еди-

ниц, на 20% — при заказе от

до 20 единиц и на 30% — при

заказе

свыше 20 единиц;

i плата за доставку по суше в пределах страны для заказов весом

свыше 2 фунтов составляет

34,75

плюс

центов на унцию или

ее

часть;

1 комиссия за операции с ценными бумагами, осуществлявшиеся в

интерактивном режиме, составляет $12 при числе акций от 1 до

5000. Комиссия за операции, осуществлявшиеся через специали-

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

акц^й

от 1 до 5000. При числе акций свыше 5000 комиссия составляет по-

ловину указанной суммы;

1 общая стоимость заказа вычисляется как сумма стоимостей всех

заказанных товаров, за вычетом скидок на количество,

плюс

госу-

дарственные и местные налоги, действующие в округе, куда будет

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

страховой сбор.

Глава 9. Игра по правилам

157

Таблица

9-1.

Использование таблицы для вычислений,

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

Идентификатор

DISC-1

DISC-2

DISC-3

DISC

-4

Количество приобретаемых единиц товара

1-5

6-10

11-20

свыше

Скидка,

Отдельное

вычисление

может включать множество элементов.

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

ство, налог с продаж, стоимость доставки и страховой сбор. Это пра-

вило запутанно и сложно для понимания. Чтобы избавиться от данного

недостатка, пишите свои бизнес-правила на элементарном уровне, а

не

объединяйте

множество деталей в одно правило. Сложное правило

может ссылаться на используемые в нем отдельные правила. Это сде-

лает их краткими и простыми. Кроме того, так вы сможете повторно

использовать их и комбинировать различными способами. Чтобы пи-

сать вычисления и активирующие операции бизнес-правила на эле-

ментарном уровне, не используйте в левой части конструкции «если —

то» логику «или», а в правой части этой же конструкции — логику «и»

(von Halle,

2002}.

К элементарным бизнес-правилам, влияющим на вы-

числение общей стоимости из примера выше, относятся правила вы-

числения скидки из табл.

9-1,

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

1 если адрес доставки находится в штате, где действует налог на про-

дажи, то он вычисляется исходя из общей стоимости заказанных то-

варов с учетом скидки;

1 если адрес доставки относится к округу, где действует налог на про-

дажи, то он вычисляется исходя из общей стоимости заказанных то-

варов с учетом скидки;

1 страховой сбор составляет 1 % от общей стоимости

заказанных

то-

варов с учетом скидки;

i налог на продажи не взимается со стоимости доставки;

1 налог на продажи не взимается со страхового сбора.

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

нейшая их детализация невозможна. В конечном итоге вы, скорее все-

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

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

вания.

168

Часть II. Разработка требований к ПО

Документирование бизнес-правил

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

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

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

стого каталога бизнес-правил. Большим организациям, а также ком-

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

значительной степени регулируются и управляются

бизнес-правила-

ми, следует создать БД таких правил. Если ваш каталог правил уже не

помещается в файле текстового процессора или редактора электрон-

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

реализации

правил в ваших приложениях, вам наверняка

пригодятся

коммерческие средства управления правилами. Группа Business

Rukis

Group публикует список продуктов для управления бизнес-правилами

на странице http://www.businessrulesgroup.org/brglink.htm. По мере

того, как вы при работе над приложением определяете новые

правили,

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

приложения или, что еще хуже, только в его код. При

неправильном

управлении и выполнении правила, относящиеся к безопасности, за-

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

вятся опасными для вас.

Ловушка Не пытайтесь сделать свой каталог бизнес-правил более сложным,

чем необходимо.

Используйте

простейшую форму документирования правил; это

гарантирует, что команда разработчиков сможет эффективно использовать их.

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

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

нов для определения правил разных типов

{Ross,

1997;

von Halle,

2002). В этих шаблонах описываются образцы ключевых слов и разде-

лов, позволяющих согласованно структурировать правила. Кроме

то-

го, они упрощают хранение правил в БД, коммерческих

инструментах

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

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

показанный в табл. 9-2 (Kulak и Guiney, 2000).

Как видно из этой таблицы, присвоив каждому правилу

идентифи-

катор, вы сможете отслеживать, от какого правила происходит то или

иное функциональное требование. Поле «Тип правила»

указывает,

чем

является правило: фактом, ограничением, активатором операции,

ВЫЕЮ-

дом или вычислением, Поле «Статичное или динамическое»

указывает,

Глава 9. Игра по правилам

169

насколько вероятно изменение правила с течением времени. Источни-

ками правил могут быть корпоративные политики, политики менедж-

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

правительственные постановления, а также имеющийся код ПО и оп-

ределения БД.

Таблица 9-2. Пример каталога бизнес-правил

Иденти-

фикатор

ORDER-

Определение

правила

Пользователь

может

запросить вещество из

я.

правила

Ограничение

Статичное или Источник

динамическое

Статичное Корпоратив-

ная политика

DISC-13

списка

химикатов

первого

уровня

опасности, только

если за последние 12 ме-

сяцев он прошел обучаю-

щий курс по работе с опас-

ными соединениями

Размер скидки вычисляет-

ся на основе размера зака-

за согласно

данным

табл.

9-1

Вычисление Динамическое Корпоратив-

ная политика

Бизнес-правила

и требования

Просто задавая пользователем вопрос: «Что представляют собой ва-

ши

бизнес-правила?»,

практически невозможно получить нужную ин-

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

требованиях, задавая при сборе требований вопрос пользователям:

«Чего вы хотите?» В зависимости от приложения бизнес-правила ино-

гда создаются по ходу работы, а иногда — в процессе обсуждения тре-

бований, Зачастую заинтересованные в проекте лица уже знают, какие

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

работчиков будет работать в рамках, определяемых этими правилами,

Комплексный процесс выявления бизнес-правил описан Barbara von

Halle (2002).

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

ресоваться обоснованием требований и ограничений, выдвигаемых

пользователями. Нередко выясняется, что они определяются бизнес-

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

170

Часть II. Разработка требований к ПО

которые определяют прочие артефакты и модели требований

(Gottes

diener,

2002). На рис, 9-2 показано несколько возможных

источников

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

функцио

нальных

требований).

Кроме того, здесь перечислены некоторые

во

просы,

которые может

задавать

аналитик участникам семинара

при

обсуждении различных проблем и объектов. Следует

задокументиро

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

люде^

подтвердить их правильность и предоставить недостающие данные.

Политики

Почему

это

необходимо

делать

именно в такой форме?

Чего требует

правительство?

Х-

Бизнес-правила

Как взаимосвязаны

элементы

данных

Решения

предпринять

Yfl

ewcTB

y°uy«

лиц

дальше?

в результате чего Что может

произойти,

изменяется состояние объекта? а что - нет?

\_-

.^^

Как

система

узнает,

что

делать

дальше?

Решения

системы

Рис. 9-2. Выявление бизнес-правил с помощью разнообразных вопросов

Идентифицировав и задокументировав

бизнес-правила,

определи-

те, какие из них необходимо реализовать в программном продукте.

Некоторые правила определяют варианты использования и функцио-

нальные требования, которые их реализуют. Рассмотрим три правила.

% Правило № 1 (активатор

операции).

«Если

срок хранения контей-

нера с химикатом истек, об этом необходимо уведомить

лицо,

у ко-

торого в данный момент находится контейнер».

1 Правило № 2

(вывод).

«Считается, что срок хранения контейнеров

с химикатами, разлагающимися на взрывоопасные составляющие,

истекает через один год с даты изготовления».

Глава 9. Игра по правилам

171

Правило № 3

(факт).

«Эфир может спонтанно образовывать взры-

воопасную

перекись».

Эти правила

определяют

вариант

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

известный, как

«Известить владельца химиката об истечении срока хранения». Одно

из функциональных требований для данного варианта

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

таково: «Система должна по электронной почте уведомить об владель-

ца контейнера с химикатом об истечении срока хранения

химиката».

Связи между функциональным требованием и породившими его

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

используя атрибут «Источник», указывают правила в качестве источ-

ников функционального требования (подробнее — в главе

18);

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

соответ-

ствующими бизнес-правилами в матрице

связей

(подробнее — в

главе 20).

Правила ссылочной целостности данных зачастую реализуют в виде

триггеров и хранимых процедур БД. Такие правила описывают опера-

ции по обновлению, вставке и удалению данных, которые должна вы-

полнять система в результате наличия отношений между сущностями

данных (von Halle, 2002). Например, если клиент отменил заказ, систе-

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

входящих в этот заказ.

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

требования весьма похожи. Тем не менее правила — это внешние по-

ложения политики, которые требуется реализовать в ПО; следователь-

но,

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

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

нию, какие необходимо реализовать в нем и как именно.

Вспомним ограничивающее правило для системы контроля химика-

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

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

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

делить соответствующие этому правилу функциональные требования в

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

ном режиме или нет. Если да, система может просто просмотреть за-

пись об обучении пользователя и решить, принять или отклонить его за-

прос. Если записи в интерактивном режиме недоступны, система может

временно сохранить запрос на химикат и по электронной почте обра-

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

не подтвердит запрос. Правило одинаково для обеих ситуаций, однако

функциональные требования к ПО — действия, предпринимаемые сис-

172

Часть II. Разработка требований к ПО