Что такое бизнес правила
Бизнес-правила
Бизнес-правила представляют собой специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении. Эти правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл. Нередко они изменяются от страны к стране, от отрасли к отрасли, и даже от бизнеса к бизнесу. В качестве примера бизнес-правила в банковском деле можно привести закон, по которому о любой сделке, превышающей сумму 10 000 долларов наличными, государство должно ставится в известность. Несомненно, данное бизнес-правило необходимо принимать во внимание при создании банковской системы вложения/снятия наличных денег.
Бизнес-правила существуют на разных уровнях. Некоторые из них оказывают влияние на всю систему, и многие системы, на самом деле, целиком создаются лишь для того, чтобы ввести в действие бизнес-правила. Бизнес-правила также могут значительно различаться по размерам области влияния. Но, не смотря на это, все бизнес-правила имеют одно общее свойство: они управляют некоторой составляющей бизнеса. По определению, бизнес-правило есть ограничение, применяемое по отношению к человеку, бизнесу, составляющей бизнеса или действию. Далее речь пойдет о некоторых подробностях, характерных для унифицированных языков моделирования.
Большинство бизнес-правил представляет собой простую проверку достоверности, например, обеспечение соответствия почтовых индексов с индексами, имеющимися у штатов США.
В общем случае существует три типа правил. К первому типу принадлежат правила вывода.
Правило вывода (derivation rule) преобразует полученную информацию в возвращаемые значения. Например, скидки на товары можно вычислить с помощью специального алгоритма, учитывающего размер заказа, рекламную поддержку и значимость клиента, которому будут поставляться товары. Правила этого типа допускают изменения, и поэтому, прежде чем с ними можно было работать, их требуется выделить.
Правило ограничения (constraint rule) проверяет значения транзакции или операции на непротиворечивость. Например, чтобы заказчик получил письмо, почтовый индекс на письме должен соответствовать индексу штата, в котором проживает заказчик. Эти правила могут использоваться для изучения взаимосвязей между объектами, например, когда все клиенты имеют адресующие объекты в интернет-магазине видеоаппаратуры. Кроме того, они могут применяться вместе с Булевыми результатами. Если они не истинны, то мы не сможем продолжить или завершить операцию.
Наконец, существуют инвариантные правила. Инвариантные правила (invariant rules) проверяют множественные изменения и обеспечивают непротиворечивость итоговых результатов. Например, баланс сберегательного счета должен быть равен предыдущему балансу плюс сумма прихода или минус сумма расхода. Если у вас что-то не сходится, значит, ваша система теряет деньги, и пришло время поднять исключение на более высокий уровень.
Бизнес-правила в БД представляют собой условия того, что данные соответствуют предметной области.
Бизнес-правила можно разделить на элементарные и расширенные.
· Элементарные правила ограничивают значения конкретного атрибута или агрегата атрибутов через ограничения домена.
· Расширенные правила выражаются в виде некоторой зависимости между атрибутами.
Ограничения могут быть статическими или динамическими. Статические ограничениядолжны выполняться для каждого состояния базы данных. Динамические ограничения проявляются при переходе базы данных из одного состояния в другое. Например, при повышении заработной платы служащего новое значение должно быть больше старого.
Ограничения могут найти свое выражение:
· при описании атрибутов отношений в концептуальной схеме;
· в запросе к базе данных;
· процедуре базы данных;
· в правиле (в триггере).
Процедуры базы данных создаются проектировщиком базы данных и дополняют СУБД. В различных СУБД они носят название хранимых, присоединенных, разделяемых и т. д. В системах с архитектурой «клиент-сервер» использование процедур баз данных позволяет значительно снизить трафик сети. Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры.
Структурные ограничения реализуются процедурой нормализации, использующей функциональные зависимости, действующие между сущностями и атрибутами.
Правило (триггер) – программа для наблюдения за ситуацией, возникающей при изменениях в базе данных. Правило придается таблице базы данных и применяется при выполнении над ней операций включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы. Применение правила заключается в проверке условия, при наступлении истинности которого вызывается указанная внутри правила процедура базы данных. Правила (так же, как и процедуры баз данных) хранятся независимо от прикладных программ.
Словарь данных
Словарь данных – термин может иметь одно из близких по смыслу значений, относясь к базам данных и СУБД:
· документ, описывающий базу данных или комплект баз данных
· целый компонент СУБД, необходимый для определения её структуры
· часть подпрограммного ПО, расширяющее или подменяющее встроенные словари данных СУБД
Словарь данных содержит информацию об источниках, форматах и взаимосвязях между данными, их описания, сведения о характере использования и распределении ответственности. Словарь данных можно рассматривать как вспомогательную базу данных, в которой хранится информация об основной базе данных.
Пользователи баз данных и разработчики приложений могут получить выгоду от единого стандартизированного документа словаря данных, который перечисляет организацию, содержимое, соглашения по одной или более баз данных. Это обычно включает в себя имена и описания различных таблиц и полей в каждой базе данных, дополнительные детали такие, как тип и длина каждого элемента данных. Не существует универсального стандарта, описывающего уровень детализации в подобном документе, но есть основное описание метаданных о структуре базы данных, а не о самих данных. Документ словаря данных также может включать в себя дополнительную информацию, описывающую кодирование элементов данных. Одним из преимуществ хорошо спроектированного документа словаря данных является то, что он помогает упорядочить структуру базы данных или большого комплекса распределенных баз данных.
Словарь данных в СУБД Oracle это набор таблиц, которые содержат следующую информацию:
· Имена пользователей сервера Oracle
· Уровни привилегий пользователей
· Имена объектов базы данных
dBase – семейство широко распространённых систем управления базами данных, а также язык программирования, используемый в них. Самая первая СУБД этого семейства называлась dBase II и была выпущена в 1980 году компанией Ashton-Tate под CP/M, позже появились версии для Apple II, Apple Macintosh, UNIX, VMS и IBM PC под DOS. Версия для PC вместе с пришедшими ей на смену dBase III и dBase IV были несколько лет одной из самых распродаваемых программ. Долгое время dBase не портировали под Microsoft Windows, в результате чего в этой нише у программы оказались сильные конкуренты — Paradox, Clipper, FoxPro и Microsoft Access.
Название «dBase II» предложил рекламный агент. По его мнению, оно звучало весьма респектабельно с технической точки зрения и, кроме того, содержало тонкий намек на то, что это некая новая и, видимо, улучшенная версия своего предшественника — системы dBase.
Конечно, никакого предшественника, который следовало бы улучшить, не было и в помине, однако система dBase II действительно имела ощутимые преимущества по сравнению с другими программами, ориентированными на решение данного класса задач.
Благодаря простоте в использовании, нетребовательности к ресурсам компьютера и, что не менее важно, грамотной маркетинговой политике компании-производителя этот продукт приобрел немалую популярность, а с выходом следующих его версий — dBase III и dBase III Plus (1986 г.), оснащенных весьма комфортной по тем временам средой разработки и средствами манипуляции данными, быстро занял лидирующие позиции среди настольных СУБД и средств создания использующих их приложений.
Хранение данных в dBase основано на принципе «одна таблица — один файл» (эти файлы обычно имеют расширение *.dbf). MEMO-поля и BLOB-поля (доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах. При этом в ранних версиях этой СУБД требовалась специальная операция реиндексирования для приведения индексов в соответствие с текущим состоянием таблицы.
Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase-подобных СУБД, частично совместимых с dBase по форматам данных. Например, весьма популярная некогда СУБД FoxBase (разработанная Fox Software, Inc. и ныне принадлежащая Microsoft) использовала формат данных dBase для таблиц, однако форматы для хранения MEMO-полей и индексов были своими собственными, несовместимыми с dBase.
После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase, приобрел набор дополнительных возможностей, характерных для средств разработки этой компании и для имевшейся у нее другой настольной СУБД — Paradox. Среди этих возможностей были специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования BDE API и SQL Links.
Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет
Что такое бизнес-правила и BRMS на примере Red Hat Decision Manager
В жизни людей окружает куча правил и рекомендаций: на красный ехать нельзя, надо мыть руки перед едой, детей водить в школу к первому уроку. Таких же правил полно и в бизнесе: отпуск не больше Х дней в году, клиенту с плохой кредитной историей займ отклонить и так далее.
Если у вас много информационных систем и таких правил — то BRMS must have. Что это такое, как работает на примере конкретной BRMS читайте в этой статье
Что такое бизнес-правила, BRMS и в чем польза применения
BRMS — это программа через которую можно создавать и управлять правилами централизованно. Бизнес-правила — это то, как компания принимает решение. Представьте, что у нас есть предприятие, которое регулирует правила проезда умных машин в городе на светофорах.
Бизнес-правило светофора выглядит так:
Когда выходит новый закон, что теперь надо ехать на красный, мы меняем таблицу правила и ВСЕ машины продолжают ехать нормально.
Получается, польза BRMS:
Примеры правил
Почему бы просто не заставлять программистов переписывать код
Одно дело когда 1С-ка генерирует счета-фактуры с НДС, другое дело — когда вы банк с 40 информационными системами и 110 000 заявок на кредиты в день.
В первом случае подождать пару дней, пока поменяют алгоритм расчёта, нормально. Во втором случае изменения в 40 системах программисты будут делать год и убыток от кредитов составит десятки тысяч долларов.
Поэтому BRMS нужен когда:
Анализ бизнес-правил: техника BABOK®Guide для документирования операций и разработки требований
В этой статье рассмотрим, что такое бизнес-правила, какие они бывают, зачем их определять, анализировать и документировать при описании процессов, а также спецификации требований. Анализ бизнес-правил как техника BABOK®Guide и метод фиксации особенностей предметной области при разработке технического задания (ТЗ).
Что такое бизнес-правила: определение BABOK®Guide и примеры
Анализ бизнес-правил является одной из 50 техник BABOK®Guide и используется для выявления, определения, описания, проверки и организации ежедневных операций, а также условий принятия операционных решений. Если бизнес-правила являются основанием для принятия решений, с ними можно дальше работать в технике «Анализ решений», структурировав в виде таблицы или дерева, что мы рассмотрим в следующий раз. А сегодня сфокусируемся именно на технике «Анализ бизнес-правил» (Business Rules Analysis).
Бизнес-правила не стоит путать с организационными (деловыми) политиками, область действия которых шире чем у правил и направлена больше на предприятие в целом, чем на отдельные процессы и управленческие решения. Бизнес-правило — это конкретная проверяемая директива как условие или критерий управления поведением/процессом или принятия рутинных (операционных) решений. Оно всегда практически осуществимо, контролируемо и не требует дополнительной интерпретации для применения в бизнесе. BABOK выделяет 2 категории бизнес-правил:
Штурм BABOK за 5 дней: подготовка бизнес-аналитиков к экзамену на сертификат CBAP/CCBA (IIBA® Endorsed Сourse, 40 PD)
Код курса
Ближайшая дата курса
Длительность обучения
40 ак.часов
Стоимость обучения
75 000 руб.
Бизнес-правила напрямую связаны с бизнес-требованиями. Например, есть бизнес-требование «Выиграть войну (стать победителем)». Связанные с ним определительные бизнес-правила могут звучать так: «Выигрывает в войне, т.е. становится победителем тот, кто захватил всю территорию противника» и «Дата окончания войны фиксируется в акте капитуляции от проигравшей стороны». А поведенческое бизнес-правило в этом кейсе может быть таким: «Проигравший должен выплатить денежную контрибуцию победителю в течение месяца после окончания войны».
Как анализировать бизнес-правила: рекомендации BABOK®Guide
BABOK отмечает, что техника анализа бизнес-правил включает следующие действия:
Все эти действия направлены на то, чтобы сделать бизнес-правила явными, конкретными, ясными, доступными и централизованными. Если по результатам сбора информации из явных и неявных источников бизнес-аналитику необходимо сформулировать правило самостоятельно, BABOK®Guide рекомендует придерживаться следующих принципов:
Бизнес-правила в среде разработки и моделирования
Бизнес-правила представляют собой специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении. Эти правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл. Нередко они изменяются от страны к стране, от отрасли к отрасли, и даже от бизнеса к бизнесу. В качестве примера бизнес-правила в банковском деле можно привести закон, по которому о любой сделке, превышающей сумму 10 000 долларов наличными, государство должно ставится в известность. Несомненно, данное бизнес-правило необходимо принимать во внимание при создании банковской системы вложения/снятия наличных денег.
Бизнес-правила существуют на разных уровнях. Некоторые из них оказывают влияние на всю систему, и многие системы, на самом деле, целиком создаются лишь для того, чтобы ввести в действие бизнес-правила. Бизнес-правила также могут значительно различаться по размерам области влияния. Но, не смотря на это, все бизнес-правила имеют одно общее свойство: они управляют некоторой составляющей бизнеса. По определению, бизнес-правило есть ограничение, применяемое по отношению к человеку, бизнесу, составляющей бизнеса или действию. Далее речь пойдет о некоторых подробностях, характерных для унифицированных языков моделирования.
Бизнес-требования
Большинство бизнес-правил обнаруживаются в процессе накопления требований. При этом появляется естественное желание добавить еще одну секцию в описания сценариев использования и в нее добавлять бизнес-правила. Однако если бизнес-правило по своему существу не принадлежит к функции, описанной сценарием использования, то оно обычно охватывает несколько сценариев. Так в приведенном выше примере бизнес-правило 10 000 долларов будет охватывать сценарии «Вложение наличных денег» и «Снятие наличных денег».
Каждый из этих сценариев может «запустить» правило 10000 долларов и привести его в действие. В конце концов, вы можете сказать, что это правило лучше внести в каждый сценарий. Тем более что большинство сценарных шаблонов имеют раздел для бизнес-правил. Но что будет, если правительство изменит правило 10000 долларов на правило 15000 долларов? Тогда вам придется изменить это правило в обоих сценариях использования.
Некоторые бизнес-правила действительно являются частью сценария использования. Они приводят к условиям исключения, которые должны обратиться к этому сценарию для возобновления процесса. Например, чтобы клиент банка мог вложить большую сумму наличных денег, от него может потребоваться информация об их происхождении. Такая информация должна потенциально рассматриваться как часть сценария использования. И она, безусловно, будет его частью, если от ее содержания зависит, положит клиент свои деньги в банк или нет.
Типы правил
В общем случае существует три типа правил. К первому типу принадлежат правила вывода [Francis 2003]. Правило вывода (derivation rule) преобразует полученную информацию в возвращаемые значения. Например, скидки на товары можно вычислить с помощью специального алгоритма, учитывающего размер заказа, рекламную поддержку и значимость клиента, которому будут поставляться товары. Правила этого типа допускают изменения, и поэтому, прежде чем с ними можно было работать, их требуется выделить.
Наконец, существуют инвариантные правила [Francis 2003]. Инвариантные правила (invariant rules) проверяют множественные изменения и обеспечивают непротиворечивость итоговых результатов. Например, баланс сберегательного счета должен быть равен предыдущему балансу плюс сумма прихода или минус сумма расхода. Если у вас что-то не сходится, значит, ваша система теряет деньги, и пришло время поднять исключение на более высокий уровень.
Рис. 1. Быть работником (employee) как сотрудничество
Эти правила могут относиться как к свойствам, так и к сотрудничествам [Nicola 2002]. Нередко свойства одной системы являются сотрудничествами другой. Например, если одна система может моделировать идею «быть работником», исходя из сотрудничества (см. рисунок 1), то другая система может моделировать эту же идею, исходя из свойства (см. рисунок 2). Реализация (implementation) является независимым типом правил.
Изображение правил
Бизнес-правила можно изобразить на диаграммах сценариев использования, если они применяются к состоянию или роли на макроуровне. Эти правила могут фигурировать в качестве начальных и конечных условий, появиться в потоке событий или альтернативных потоках и исключениях. Бизнес-правила, используемые в перечисленных областях, обычно служат целью, задаваемой сценарием использования (например, «Плата за аренду видеосистемы»). Совокупность инвариантных бизнес-правил представляет собой начальные условия сценариев использования.
Существует также огромное количество других бизнес-правил, применяемых к классу, атрибуту или операции. Такие бизнес-правила могут фигурировать в качестве ограничений на диаграмме класса (например, правило на рис. 1). Ограничения выделяются скобками и выступают как часть метода, связи или как примечания к классу. Обычно ограничения задаются в Object Constraint Language (язык ограничения объектов, OCL), хотя в большинстве случаев большой строгости и не требуется.
Рис. 2. Быть работником (employee) как атрибут
Реализация
Большинство продуктов с модельной архитектурой Model Driven Architecture (MDA) использует язык OCL для порождения программной логики. При разработке приложений в среде MDA важную роль играет преобразование бизнес-правил в ограничения на диаграммах класса. Эта логика преобразуется с языка OCL платформенно-независимой модели (Platform Independent Model, PIM) на язык высокого уровня платформенной модели (Platform Specific Model, PSM). Платформенная модель может быть языком программирования, таким как Java, C#, C++ или Delphi.
Бизнес-правила находят широкое применение в компонентах языка Java, что позволяет управлять ими и настраивать под постоянно меняющиеся условия ведения бизнеса. Эти компоненты имеют собственные интерфейсы, позволяющие использовать бизнес-логику для достижения желаемых результатов. Существуют эффективные стратегии определения способа запуска, фильтрации и объединения этих компонентов.
Однако, каким бы образом вы не собирались реализовывать свои бизнес-правила, включая их в требования и модели, это будет самым трудным этапом работы. Бизнес-правила требуют огромного объема знаний. Поэтому на этом этапе разработки любой системы желательно привлекать специалистов высокой квалификации из разных областей знаний. Изменение бизнес-правил и появление новых часто становится причиной того, что новые системы приходят на смену старым.
Заключение
Библиография
[Francis 2003] Francis, Tim, et al. Professional IBM WebSphere 5.0 Application Server, Wrox, 2003
[Nicola 2002] Nicola, Jill, Mark Mayfield, and Mike Abney, Streamling Object Models, Prentice Hall, 2002 Фрагмент в The Coad Letter 89
[1] Unified Modeling Language (Унифицированный язык моделирования)
Бизнес-правила
Бизнес-правила – набор условий, которые управляют деловым событием, чтобы оно происходило так, как нужно для предприятия (или клиента).
Содержание
Клиенты формулируют правила, определяя все возможные и допустимые условия делового события, а также условия, которые недопустимы или нежелательны. Эти правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл. В качестве примера бизнес-правила в банковском деле можно привести закон, по которому о любой сделке, превышающей сумму 10 000 долларов наличными, государство должно ставится в известность. Бизнес-правила существуют на разных уровнях. Некоторые из них оказывают влияние на всю систему, и многие системы, на самом деле, целиком создаются лишь для того, чтобы ввести в действие бизнес-правила. Бизнес-правила также могут значительно различаться по размерам области влияния. Все бизнес-правила имеют одно общее свойство: они управляют некоторой составляющей бизнеса.
Классификация бизнес-правил
Преимущества построения систем с использованием подхода на основе бизнес-правил
Применение подхода на основе бизнес-правил
Существует, по крайней мере, три пути применения проектного подхода на основе бизнес правил:
использовать подход на основе бизнес-правил не только применительно к требованиям. Он также желает создать систему, в которой логика исполнения бизнес правил будет отделена от остальной части системы;