Приветствую, UML2.RU!

Попал вчера на интересный документ о бизнес-требованиях и попытался перевести. Помогите пожалуйста уточнить перевод!
Все подробности, сцылки, явки по адресу:
http://nvoynov.blogspot.com/2008/04/blog-post_2322.html

Вижу интерес какой-то есть, но не вижу конструктивных замечаний ... Так все хорошо или так все плохо?

Николай,

Сейчас у меня лично времени совсем нет ... На след. неделе постараюсь посмотреть и ответить.

Спасибо, bas! Я тут еще взялся за http://www.businessrulesgroup.org/first_paper/br01c0.htm
Кажется тоже полезная штука, но до конца пока не ясно. Освоил где-то 25-30%, может к след. неделе  созреет основная часть.

Николай,

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

В общем замечания такие:

Rules are a first-class citizen of the requirements world.

Правила - это элита мира требований
     

Article 2.    Separate From Processes, Not Contained In Them

Статья 2. Отделены от процессов, а не заключены в них   

2.1. Rules are explicit constraints on behavior and/or provide support to behavior.

Правила - это четкие ограничения поведения и\или обеспечивают поддержку поведения
     

2.2. Rules are not process and not procedure.  They should not be contained in either of these.

2.2. Правила не являются процессом или процедурой. Они не должны быть включены в эти понятия.   

2.3. Rules apply across processes and procedures.  There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

2.3. Правила применяются между процессами и процедурами. Должен быть один последовательный свод правил, который полностью верен во всех соответствующих областях бизнес-деятельности.

3.1. Rules build on facts, and facts build on concepts as expressed by terms.

3.1. Правила опираются на факты, а факты опираются на концепции, выраженные в терминах.

3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.

3.2. Термины выражают бизнес-концепции; факты утверждают эти концепции, правила ограничивают и поддерживают эти факты.

4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.

4.1. Правила должны выражаться в описательных предложениях на естественном языке бизнеса.
     

4.3. A set of statements is declarative only if the set has no implicit sequencing.

4.3. Набор высказываний декларативный, только если набор не подразумевает последовательность.

4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.

     
4.4. Любые утверждения о том, что правила требуют других конструкций, помимо терминов и фактов, означают предположения о реализации.

4.5. A rule is distinct from any enforcement defined for it.  A rule and its enforcement are separate concerns.

4.5. Правило не зависит от каких-либо воздействий, определенных для него. Правило и его воздействие - отдельные проблемы.
     

Article 5.    Well-Formed Expression, Not Ad Hoc

Статья 5. Правильно-сформированные выражение, а не подсказки

5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.

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

5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.

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

5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.

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

Article 6.    Rule-Based Architecture, Not Indirect Implementation

Статья 6. Архитектура основанная на правилах, а не наоборот
     

6.2. Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.

     
6.2. Непосредственно выполнение правил - например, в движке правил, - это лучшая реализация, чем перевод правил в какую-то процедурную форму.

6.4. Rules are based on truth values.  How a rule’s truth value is determined or maintained is hidden from users.

6.4. Правила основаны на истинных значениях. Какие истинные значения правил определены или поддержаны скрыто от пользователей.
     

7.1. Rules define the boundary between acceptable and unacceptable business activity.

7.1. Правила определяют границу между приемлемой и неприемлемой бизнес-деятельностью.
     

7.2. Rules often require special or selective handling of detected violations.  Such rule violation activity is activity like any other activity.

7.2. Правила часто требуют особой или выборочной обработки обнаруженных исключений. Такие исключительные действия - это действия такие же как и другие.

7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.

7.3. Для обеспечения максимальной согласованности и повторного использования, обработка исключительных действий должна быть отделена от нормальных бизнес-действий.

8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.

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

10.1.   Business rules are a vital business asset.

10.1. Бизнес-правила являются жизненно важных бизнес-сущностью.
     
и вездее надо заменить деловой на бизнес ИМХО

сырой - гугл плюс мало времени и знаний
спасибо за исправления! собственно больше хотелось затеять дискуссию о реализации бизнес-правил, т.е. манифест скорее скрытых намек и подвох

Ну главная идея высказанная здесь, что:
1. БПр - это не алгоритм (последовательность действий), а выражения - "если выполняется такое-то условие, то делаем то-то"
2. Должны быть сформулированы в терминах бизнеса и понятны ему. Отсюда вопрос - Вигерс их относит к ПТ, а тут больше разговор о БТ?!
3. Должны быть четко сформулированы и согласованы м\у собой
4. БПр - это основные требования и на основе их можно написать движок, кот. будет исполнять БПр. Но здесь не понятно как можно описать все требования с помощью БПр? Для меня это всегда были вспомогательные требования.

В общем эти ребята (авторы) как по мне тоже немного не туда пошли. Но тут http://www.businessrulesgroup.org/first_paper/br01c0.htm они дают интересную предметную область - сплошные правила ... опять же много "сырого перевода" http://nvoynov.blogspot.com/2008/04/blog-post_6495.html - смотреть приложение с описанием предметной области.

Сейчас немного копаю Drools - хочу попробовать реализовать на нем эту предметную область.

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