Это первая из двух статей серии, в которой определяется природа бизнес-правил и отношение этих правил к моделям IBM Industry Models. В частности, в этой статье описываются этапы развертывания моделей IBM Industry Models, на которых выполняется анализ и проектирование правил, а также способы идентификации и управления правилами. Во второй статье этой серии обсуждается введение этих структур анализа и проектирования в среду управления правилами ILOG для разработки полных наборов правил.
Что такое модели IBM Industry Models?
Модели IBM Industry Models - это набор взаимосвязанных моделей, которые соответствуют разным аспектам анализа и проектирования приложений, систем хранения данных или решений интеграции для определенной сферы деятельности. Модели состоят из набора базисных моделей, которые в свою очередь поддерживают набор детальных моделей, ориентированных на конкретную задачу или сферу моделирования.
Базисные модели помогают определить рамки проекта и выявить зависимости между отдельными проектами, которые без них было бы легко упустить. В дополнение к этому базисные модели составляют фундамент, на котором строятся все прочие предложения Industry Model, обеспечивая лексикон стандартных бизнес-терминов, гарантирующий согласованность между моделями набора. Получаемые модели удовлетворяют потребности доменов процессов, служб и данных соответственно в процессах, UML-сервисах и ER-моделях.
Модели Industry Models сфокусированы на формировании детального бизнес-контента. Каждая модель является итогом многолетней разработки в организациях по всему миру крупных моделей масштаба предприятия, которые впоследствии можно использовать для ускоренной реализации проектов. Модели предполагают настройку и расширение в ходе таких проектов, для чего требуется специальная методология настройки и управления моделями.
Для каждой отрасли предлагаются свои базисные модели, обеспечивающие согласованность в рамках наборов моделей и обеспечивающие точку входа для моделей. Модели состоят из набора определений, в первую очередь детализирующих концептуальные бизнес-функции и действия, используемые по всему набору моделей.
На основе этих базисных моделей строится набор проблемно-ориентированных моделей, которые распространяют эти определения на домены процессов, служб и хранилищ данных. На рисунке 1 показаны конкретные модели, которые обсуждаются в этой статье.
Рисунок 1. Модели IBM Industry Models
Бизнес-правила фигурируют в разных местах этого набора моделей, в частности, в сфере анализа процессов. Одни формы правил неявно присутствуют в определении типов действий в модели и декларируются в моделях отношений между элементами (entity relationship - ER) и UML для типов действий моделируемого домена. Другие формы правил детализируют допустимые изменения в этих типах действий, декларируются как ограничения внутри определений сервисов, задают модели переходов. Мы рассмотрим также правила, которые влияют на управление структурами бизнес-логики. Эти правила обычно встречаются внутри структур процессов или сервисов в моделях анализа процессов и сервисов.
Рисунок 2. Источники правил для моделей Industry Models
Это порождает определенный набор способов получения правил. Вот компоненты моделей Industry Models, в которых обычно возникают правила, которые необходимо описывать:
- Правила, относящиеся к бизнес-процессам или действиям: Эти правила относятся к логике управления внутри модели бизнес-процесса, оказывая влияние на ветвление и последовательность выполнения бизнес-задач. Такие правила обычно возникают на этапе анализа внутри моделей процессов и требуют формализации для составления блок-схемы процесса (например, BPEL) или логики приложения.
- Правила, относящиеся к сервисам: Эти правила относятся к исполнению логики сервисов и тесно связаны с правилами, относящимися к бизнес-процессам и действиям. Следовательно, эти правила также часто возникают в процессе анализа; однако они требуют дальнейшего анализа в рамках модели бизнес-объекта до их формализации в рамках спецификаций сервисов внутри IDM.
- Правила, относящиеся к информации: Эти правила относятся к информации, соотношениям между информацией и разрешенным состояниям информации. Правила этого типа возникают в процессе информационного анализа либо как часть модели бизнес-объекта, либо при логическом моделировании данных. Эти правила могут быть формализованы внутри спецификаций сервисов для установления контроля над информационными структурами или внутри самой информационной платформы.
Все эти типы правил необходимо идентифицировать, анализировать и проектировать структурированным образом, с сохранением их отношения к артефактам модели, в которой они созданы, и артефактам модели, на которую они ссылаются или с которой работают. Это требует определенного метода поддержки анализа и проектирования бизнес-правил, определенного набора форматов, в которых эти правила могут вводиться, и формализованных отношений между этими правилами и артефактами других моделей. Введение этих правил и управление ими имеют большое значение, поскольку они составляют неотъемлемую часть определения требований, анализа и проектирования систем программного обеспечения независимо от того, будут ли эти правила в конечном итоге реализованы в механизме правил, аппаратном или программном, или формализованы в виде ручных процедур. Эти правила дополняют структуры данных, процессы и сервисы Industry Models, позволяя составить полную картину бизнес-требований.
Бизнес-правило - это оператор, который определяет или ограничивает тот или иной аспект деятельности. Цель бизнес-правила - управлять некоторым аспектом деятельности или влиять на него посредством наложения структуры.
Термин бизнес-правило чрезвычайно широк и требует дальнейшей классификации. В рамках настоящей статьи мы будем иметь дело с четырьмя разными формами бизнес-правил:
- Бизнес-термины: Бизнес-термин - это фундаментальная форма бизнес-правила. Посредством определения терминов формализуют способы описания концепта участниками процесса. Традиционно термины собираются в бизнес-глоссарий или как концепты в рамках модели (такой, как модель ER). Примером бизнес-термина может служить клиент, который для наших целей определяется как "Роль, играемая стороной, которая рассматривается как получатель услуг или продуктов от моделируемой организации или одного из ее подразделений, либо является потенциальным получателем таких услуг или продуктов".
- Факты: Структура бизнеса может быть описана в виде фактов, которые связывают бизнес-термины между собой. Факты могут принимать форму выражений естественного языка или задания атрибутов, отношений или обобщений внутри формальной модели. Примером факта может служить выражение "у клиента есть адрес".
- Деривация: Деривация описывает, как информацию в одной форме можно преобразовать в информацию в другой форме посредством логических выводов или математических расчетов. В случае логических выводов факт получают при помощи логической индукции или дедукции. Математические расчеты выводят факты в соответствии с определенными математическими алгоритмами. Примеры дериваций: "два клиента с одним и тем же адресом, именем, фамилией и датой рождения - это один и тот же клиент" (логический вывод) или "средняя рентабельность клиента равна суммарной рентабельности всех клиентов, деленной на число клиентов" (математический расчет).
- Ограничения: Если факты описывают отношения между типами в рамках данной сферы деятельности, то ограничения описывают ограничения в этой сфере. Они влияют на бизнес-термин (предмет) через правила соответствия, обычно факты. Правилом соответствия называется правило, которое допускает ограничение. Пример ограничения: "клиент должен иметь единственный юридический адрес". Предметом этого ограничения является клиент. Правило соответствия (факт) состоит в том, что у клиентов есть адреса.
Определив эти четыре формы бизнес-правил, можно обсудить значение "правил" и то, как эти правила соотносятся друг с другом. Однако разные участники цикла определения требований, анализа и проектирования выражают правила с разной степенью формализации и структуризации.
Бизнес-пользователи обычно выражают правила абсолютно неформально, пользуясь естественным языком и группируя множество правил в одном утверждении (например, "…потенциальных клиентов необходимо проверять на кредитоспособность и идентифицировать…"). Будем называть такие неформальные определения "формулировками бизнес-правил". Бизнес-пользователи также часто выражаются языком бизнес-политик, например, "мы имеем дело только с кредитоспособными и проверенными клиентами". Политики и правила, хотя они тесно связаны, представляют собой разные конструкции. Бизнес-политики часто объединяют разные бизнес-правила, которые задают общее направление или составляют контекст для бизнес-правил.
Обычно аналитики разбивают правила на отдельные элементарные составляющие - определения правил, которые нельзя дробить дальше, не потеряв при этом какую-то бизнес-информацию. Одна формулировка бизнес-правила часто порождает множество взаимосвязанных элементарных бизнес-правил. Хотя элементарные бизнес-правила тоже выражаются на естественном языке, они обычно более формализованны и точны; они нормализуют определение правила, исключая пересечение между взаимосвязанными формулировками правил.
Затем разработчики правил могут взять эти элементарные правила и выразить их в формате, специфическом для целевой среды. Если предполагается использовать какой-либо механизм обработки правил, то этот формат обычно соответствует данному механизму. Заметим, что одно и то же элементарное бизнес-правило может провозглашаться несколькими формальными формулировками правил, каждая из которых имеет собственный тип формальных выражений. Это выражение не обязательно связано с внешней средой исполнения правил или механизмом обработки правил, часто правила бывают "жестко запрограммированы" в логике приложений или же просто исполняются сотрудниками организации.
Рисунок 3. Степени формализации бизнес-правил
Цикл работы организации с моделями Industry Models включает этапы планирования, формулирования требований, анализа и проектирования при разработке решений, отвечающих бизнес-требованиям. Чтобы формализовать эти этапы, в дополнение к моделям был определен план действий с набором методологических принципов. Например, в области SOA этот план предписывает организации определить рамки проекта, проанализировать бизнес-процессы, выявить сервисы и так далее в соответствии с циклом разработки. (План действий входит в состав Industry Models.)
Рисунок 4. Настройка Industry Models
Этот план действий служит общим руководством к действию для группы проектировщиков, использующих модели, но он сфокусирован на решении конкретных задач идентификации, анализа и проектирования многократно используемых сервисов. Ясно, что это не единственное направление анализа и проектирования, которое надо рассматривать. Необходимо рассмотреть также анализ и проектирование таких элементов, как интерфейс пользователя, поведение персонала и, конечно, бизнес-правила.
Рисунок 5. Совокупность потоков анализа и проектирования
Цель настоящей статьи - описать соответствующие потоки анализа и проектирования бизнес-правил в контексте IBM Industry Models.
Опыт показывает, что если проект не абсолютно оригинальный, кроме анализа сверху вниз производится одновременный анализ снизу вверх уже написанных программ и бизнес-логики. Код, электронные таблицы, таблицы баз данных и т.п. анализируются и превращаются в элементарные бизнес-правила, а также потенциально абсолютно новые конструкции данных. Затем результаты этого анализа согласовываются с результатами анализа сверху вниз, чтобы получить более полную картину.
Представление бизнес-правил в виде сервисов исключает многие трудности, связанные с вариациями в синтаксисе выражения правил и поддержке механизмов реализации правил. Поиск определения многократно используемых сервисов для реализации элементарных правил позволяет выразить эти правила в виде Web-сервисов на языке WSDL, избавляя потребителя правил от трудностей, связанных со способом реализации этих правил. Вот почему описываемый в настоящей статье подход позволяет сохранить строгое соответствие между элементарными правилами и частями бизнес-модели, от которой они отталкиваются. Многие бизнес-правила могут отображаться на бизнес-действия, которые в свою очередь направляют определение бизнес-сервисов.
Рисунок 6. Определение сервисов правил
Сохранение этой связи обеспечивает средства для анализа и определения сервисов, содержащих правила, независимым от самих определений способом. Кроме того, эти правила затем применяются к многократно используемым бизнес-объектам, выведенным из IDM, вместо того чтобы позволить каждому правилу работать со своим собственным специфическим набором данных и специфическим представлением платформ. Готовый, согласованный набор интерфейсов WSDL, через которые можно приводить в действие правила, позволяет реализовать эти правила при помощи широкого спектра технологий, не вынуждая потребителей этих правил адаптироваться к множеству разных методов.
Бизнес-политики - это неформальные выражения бизнес-процессов, обычно сформулированные бизнес-пользователями для управления бизнесом в целом. Эти определения политик, как правило, появляются на ранней стадии анализа и часто получают дополнительное детальное выражение в ходе анализа бизнес-процесса. Сами политики редко провозглашаются как бизнес-правила; обычно они играют роль руководящих принципов, внутри которых выражаются правила.
Рисунок 7. Пример бизнес-политики
Формулировки бизнес-правил содержат дополнительные детали, необходимые для соблюдения бизнес-политики. Это тоже неформальные утверждения, выраженные непосредственно участниками бизнес-процесса. Формулировки бизнес-правил часто содержат множество отдельных инструкций, которые тесно связаны между собой и часто трудно поддаются разбиению на элементарные бизнес-правила.
Формулировки бизнес-правил обычно тесно связаны с действиями внутри бизнес-процесса, поэтому нужна возможность выявлять действие или действия внутри процесса, к которому относится набор формулировок бизнес-правил. Это помогает установить четкую связь между этими действиями в ходе бизнес-процесса и правила, необходимые для его поддержки. Несмотря на эту взаимосвязь между бизнес-правилами и бизнес-действиями, которые вызывают их применение, фактический вызов этих правил происходит посредством бизнес-сервисов. План настройки моделей Industry Models говорит нам, что большинство бизнес-действий является кандидатами в сервисы. Это же относится и к бизнес-правилам - бизнес-действия, которые предполагают применение формулировок бизнес-правил, реализуются через бизнес-сервисы. Фактически такие сервисы являются воплощением этих правил, часто внутри механизма реализации правил. Такое отделение процессов от правил при помощи сервисов означает, что сервисы, содержащие правила, не работают со структурами данных процессов. Как любые другие сервисы, они имеют входные и выходные структуры данных. Связь между процессом и собственно правилом осуществляется через интерфейс сервиса.
Рисунок 8. Пример выражения правила
Элементарные бизнес-правила - это формализованные формулировки, высказанные на естественном языке, вне зависимости от какого-либо специфического синтаксиса правил. Преобразование этих элементарных правил в заданный синтаксис правил приводит к составлению операторов правил. Заметим, что каждый набор операторов правил - это лишь один из возможных способов выражения заданного набора бизнес-правил, который зависит от используемого для их выражения синтаксиса. Резонно предположить, что каждое конкретное правило в разное время может быть выражено во многих форматах и что множество типов операторов правил может использоваться параллельно. Синтаксис, используемый в операторах правил, в большой мере зависит от целевой среды исполнения. Диапазон выбора широк - от компилируемых языков до динамических механизмов контроля правил. В последующих главах этой статьи исследуется несколько таких возможных вариантов.
Рисунок 9. Пример оператора правила
Ввод формулировок политик и правил
Заказчикам Industry Models знакомы рекомендации Industry Models Customization Roadmap, в которых подчеркиваются преимущества текстовых определений требований в процессе анализа. В них приводится пример шаблона для таких требований, часть которого показана в таблице 1. (Этот шаблон входит в состав Industry Models.)
Таблица 1. Документальное описание действий
| Бизнес-правила | Определение любых конкретных правил, относящихся к действию. Часто оно приводится в виде списка или набора условных операторов "если… то", описывающих, как должно выполняться действие. |
| Критические факторы успеха | Определение возможных предварительных условий или факторов успеха, которые должны выполняться для успешного совершения данного действия. Оно часто приводится в виде списка. Это определение может включать описание новых областей, которые в новом процессе будут обрабатываться иначе. |
| Ограничения | Определение любых известных ограничений процесса. Оно может включать законодательные или регулятивные требования в отношении этого действия. |
| Зависимости | Определение любых логических блоков или других процессов, от которых зависит реализация этого действия. Сюда входят изменения политики и организационные решения, которые должны приниматься с целью реализации действия. |
| Нефункциональные требования | Определение любых дополнительных требований, которые не включены непосредственно в бизнес-определение этого действия, но все же влияют на успешный результат, таких как ключевые показатели произвдительности и требования по технической поддержке систем предприятия. |
Целью этого шаблона является поощрение задания текстовых требований полуструктурированным способом, чтобы с ними могли впоследствии работать аналитики. Документы, основанные на этих шаблонах, могут создаваться и храниться вместе с формальными моделями, обеспечивая ввод требований, необходимых для того, чтобы направлять потоки анализа и проектирования.
Требования на основе правил в RequisitePro
Управление такими полуструктурированными требованиями может осуществляться в разных системах; множество полезных возможностей предоставляет IBM Rational RequisitePro. RequisitePro может встраиваться в качестве плагина на базе Eclipse в инструментарии IBM WebSphere Business Modeler (WBM) или Rational Software Architect (RSA) и позволяет отображать структурированные документы с требованиями на элементы модели. В результате информацию формулировок бизнес-политик и бизнес-правил можно вводить в текстовой форме и отображать непосредственно на бизнес-действия и UML-структуры, к которым они относятся.
Рисунок 10. Формулировки политик и правил в RequisitePro
Можно также устанавливать отношения между этими типами требований. Например, бизнес-политики можно связывать с операторами бизнес-правил, которые поддерживают эти политики, как показано на рисунке 11.
Рисунок 11. Связь между политиками и формулировками бизнес-правил в RequisitePro
Эти типы требований могут связываться не только друг с другом, но и с элементами бизнес-модели, к которой они относятся. Например, в контексте банковских услуг бизнес-политика "…мы работаем только с полностью кредитоспособными и проверенными клиентами…" может быть выражена в виде документального требования, отображенного на бизнес-процесс "Предоставление банковского продукта", который работает с документированным набором требований клиента и выдает предложение в соответствии с этими требованиями. Аналогично, формулировку бизнес-правила "…потенциальные клиенты должны быть проверены на кредитоспособность и идентифицированы…" можно отобразить на действие Анализ отношений с клиентом в рамках того же бизнес-процесса. Это обеспечивает средства для задания не только приведенных здесь упрощенных примеров, но и сложных формулировок политик и правил, связанных с бизнес-контекстами, в которых они применяются. В RequisitePro можно легко определять шаблоны клиентов, добавляя свойства в соответствии с требованиями организации для лучшего ввода необходимых правил и управления этими правилами. Однако для выбора правильного направления лучше начинать с документов Industry Models Activity Description Documents.
Отметим, что применение RequisitePro для управления формулировками бизнес-политик и бизнес-правил хорошо согласуется с текущими рекомендациями по инструментарию для Industry Models. Например, есть документированные процедуры для управления областью применения, а также функциональными и нефункциональными требованиями, связанными с моделями, которые используются в RequisitePro. Эти рекомендации в сочетании с описанными выше средствами управления формулировками политик и правил позволяют связать эти элементы с определенными проектами и бизнес-целями как в Rational Software Architect (RSA), так и в WebSphere Business Modeler (WBM).
В этой статье описывается природа бизнес-правил и их соотношение с моделями IBM Industry Models. Затем обсуждаются методы ввода требований для бизнес-правил и степени формализации этих требований. В следующей статье этой серии полученные результаты и структуры правил будут использованы в ILOG BRMS для полного описания наборов правил, применяемых в ходе бизнес-процесса или исполнения приложения.