Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Приложения по написанию / 3 Бизнес правила.docx
Скачиваний:
47
Добавлен:
29.06.2020
Размер:
90.01 Кб
Скачать

Вычисления

Пятый класс бизнес-правил определяют вычисления (computations), преобразующие существующие данные в новую информацию с использованием математических формул и алгоритмов. Многие вычисления выполняются по внешним для предприятия правилам, например, по формулам удержания подоходного налога. Ниже дано несколько примеров вычислительных бизнес-правил, выраженных в текстовой форме.

  • плата за доставку по суше в пределах страны для заказов весом свыше 2 фунтов составляет 4,75 доллара плюс 12 центов за полную или неполную унцию;

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

  • цена единицы товара снижается на 10% при заказе от 6 до 10 единиц, на 20% — при заказе от 11 до 20 единиц и на 30% — при заказе свыше 20 единиц.

Представление деталей вычислений на обычном языке может быть многословным и запутанным. Как вариант, их можно представить в символьной форме, например, в виде математического выражения или таблицы правил, — такое представление прозрачнее и проще в сопровождении. Таблица 2 представляет правило предоставления скидок в более понятной форме.

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

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

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

Скидка, %

DISC-1

1—5

0

DISC-2

6—10

10

DISC-3

11—20

20

DISC-4

свыше 20

30

Внимание! При написании бизнес-правил требований следите, чтобы границы диапазонов не перекрывались. Очень легко по невнимательности определить диапазоны как 1–5, 5–10 и 10–20, что привносит неоднозначность, потому что непонятно, в какой диапазон попадают значения 5 и 10.

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

Поскольку бизнес-правила зачастую влияют на множество приложений, организациями следует управлять этими правилами на корпоративном уровне, а не на уровне проектов. Для начала достаточно простого каталога бизнес-правил. Если вы используете средство управления требованиями, можете хранить бизнес-правила в виде требований при условии, что они доступны из всех ваших проектов разработки ПО. Большим организациям, а также компаниям, деловые операции и информационные системы которых в значительной степени регулируются и управляются бизнес-правилами, следует создать базу данных таких правил. Некоторые системы управления бизнес-правилами содержат механизмы, позволяющие автоматизировать реализацию правил в приложениях. Группа Business Rules Group (2012) публикует список продуктов для управления бизнес-правилами. По мере того, как вы при работе над приложением определяете новые правила, добавляйте их в каталог, а не вписывайте в документацию конкретного приложения или, что еще хуже, только в его код. Серьезную опасность представляет неправильное управление и соблюдение правил, относящихся к безопасности, защите, финансам и выполнению требований законодательства и регулирующих органов.

Не надо делать свой каталог бизнес-правил более сложным, чем необходимо. Используйте простейшую форму документирования правил; это гарантирует, что команда разработчиков сможет эффективно использовать их. За хранилище правил должны отвечать бизнес-подразделения, а не ИТ-отдел или команда проекта.

По мере приобретения опыта выявления и документирования бизнес-правил стоит подумать о применении структурированных шаблонов для определения правил разных типов (Ross, 1997; von Halle, 2002). В этих шаблонах описываются образцы ключевых слов и разделов, позволяющих единообразно структурировать правила. Кроме того, они упрощают хранение правил в БД, серийных инструментах для управления бизнес-правилами или в подсистеме управления правилами. Наборы взаимосвязанных правил можно также представлять с помощью таких средств, как дерева или таблицы принятия решений (особенно, в случае сложной логики) и матрицы разрешений. Для начала попробуйте использовать простой формат документирования правил, показанный в табл. 4 (Kulak и Guiney, 2004).

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

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

Определение Тип правила

правила

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

ORDER-5

Если клиент заказал книгу автора, написавшего несколько книг, перед оформлением заказа нужно предложить приобрести другие книги того же автора

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

Статичное

Маркетинговая политика XX

ACCESS-8

Во всех изображениях вебсайта должен быть альтернативный текст для использования устройствами электронного чтения, применяемыми слабовидящими пользователями

Ограничение

Статичное

Стандарты ADA для дизайна с расчетом на ограниченные возможности

DISCOUNT-13

Размер скидки вычисляется на основе размера заказа согласно данным табл. BR060.

Вычисление

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

Корпоративная ценовая

политика

ХХХ

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

Столбец «Тип правила» указывает, чем является правило: фактом, ограничением, активатором операции, выводом или вычислением. Поле «Статичное или динамическое» указывает, насколько вероятно изменение правила с течением времени. Эта информация нужна разработчикам. Если они будут знать, что определенные правила могут меняться, то смогут так структурировать ПО, чтобы изменившуюся функциональность или данные можно было легко обновить. Порядок исчисления налога на прибыль меняется по крайней мере раз в год. Если разработчик разместит информацию о расчете налога в таблице или базе данных, а не жестко пропишет ее в коде, будет намного проще изменить значения при необходимости. Можно спокойно документировать законы природы, такие как вычисления, основанные на законах термодинамики, а «человеческие» законы намного более переменчивы.

Законы эшелонирования

Системы управления воздушным движением (ATC) гарантируют минимальное эшелонирование (то есть интервалы) между самолетами по четырем видам направлений: вертикальное, продольное, боковое и временное — это нужно для предотвращения столкновений. Бортовая авионика, пилоты, диспетчеры на земле и сама система ATC должны собирать информацию о траектории движения и скорости из сотен источников, чтобы вовремя спрогнозировать, когда два самолета могут сблизиться на опасное расстояние. Многие бизнес-правила определяют минимальные интервалы эшелонирования. Эти правила динамичны: они периодически меняются вместе с изменениями в технологиях (например, вместе с заменой радаров системой GPS), а также меняются нормативные документы. Это подразумевает, что система должна уметь регулярно адаптироваться к новым правилам, проверять согласованность и полноту правил, а также переключаться на новые правила одновременно с пилотами и диспетчерами. В одном проекте системы ATC текущий набор правил жестко прописали в коде, считая, что они статичны. Потребовалась серьезная переделка, когда заинтересованные лица осознали необходимость регулярных изменений в этих жизненно важных для безопасности правилах.

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