BizRulesVocabularies

Projekt zakończony

Tomasz, Bochen, tomasz_bochen@o2.pl

:!:It is a common visual notation used in the Business_Process_Modeling that is a modeling/design problem in the Business_process_management. The BPMN is officially standarized by OMG. Some possible areas of investigation(at 1st sight):

  • input
    • relation between BPMN and UML, e.g. see Use of UML and Model Transformations for Workflow Process Definitions
    • how could we use Business_Process_Execution_Language
    • the general idea of workflow and tools such as yawl is worth digging in…
    • SBVR
  • output

Extended ARD.

Sprawozdanie

1. Getting started with SBVR ..

SBVR is an OMG specification that details how business rules and business vocabulary can be captured and specified in unambiguous terms.

SBVR is targeted at business rules and business vocabularies, including those relevant for usage in conjunction with those rules. Other aspects of business models also have to be developed, including business process and organization structure, which are being addressed by the OMG in RFPs concurrent with that for BSBR.

SBVR is an integral part of the OMG’s Model Driven Architecture (MDA). Picture below shows positioning of SBVR in Model-Driven Architecture.

sbvrinmda

SBVR is targeted at business rules and business vocabularies, including those relevant for usage in conjunction with those rules. Other aspects of business models also have to be developed, including business process and organization structure, which are being addressed by the OMG in RFPs concurrent with that for BSBR.

1.1. What is Semantics?

‘Semantics’ is “the meaning or relationship of meanings of a sign or set of signs” [Merriam-Webster Collegiate Dictionary]. In SBVR the signs can be of any form: words, phrases, codes, numbers, icons, sounds, etc.

SVBR includes two specialized vocabularies:

  • the SBVR „Vocabulary for Describing Business Vocabularies”, which deals with all

kinds of terms and meanings (other than meanings of Business Rules);

  • the SBVR „Vocabulary for Describing Business Rules”, which deals with the

specification of the meaning of business rules, and builds on the „Vocabulary for Describing Business Vocabularies”.

The two have been separated so that the „Vocabulary for Describing Business Vocabularies” could be used independently - for example, as a basis for vocabularies for business processes or organizational roles. The next two sections deal with the semantics of business vocabularies and the semantics of business rules.

1.2. What is a Business Vocabulary?

A business vocabulary contains all the specialized terms and definitions of concepts that a given organization or community uses in their talking and writing in the course of doing business.

Examples: process rate, order price, customer retention rate, Gold Level Support, Customer, Order, Order Item etc.

The vocabulary does not include the special SBVR syntax or other SBVR compliant syntaxes like in Rule Speak.

Rules are built using Vocabulary and the special SBVR syntax.

1.3. What is a Business Rule?

The SBVR follows a common-sense definition of 'business rule':

Business Rule: rule that is under business jurisdiction

'Under business jurisdiction' is taken to mean that the business can enact, revise and discontinue business rules as it sees fit. If a rule is not under business jurisdiction in that sense, then it is not a business rule. For example, the 'law' of gravity is obviously not a business rule. Neither are the 'rules' of mathematics.

Examining the question more closely, it is obvious that if rules are to serve as guides for conduct or action, they must also provide the actual criteria for judging and guiding that conduct or action. In other words, for the context of business rules (and probably in most other contexts), rules serve as criteria for making decisions. The SBVR’s interpretation of 'rule' therefore encompasses the sense of 'criteria' as given by authoritative dictionaries.

1.3.1. Rules and Formal Logic

Experts in this area recommended that the best treatment for the SBVR’s interpretation of rules would involve obligation and necessity claims.

Consequently, in SBVR, a Rule is „an element of guidance that introduces an obligation or a necessity”. The two fundamental categories of Rule are:

  1. Structural Rule (necessities): These are rules about how the business chooses to organize (i.e., 'structure') the things it deals with.

Structural Rules supplement definitions. For example (from EU-Rent):

Necessity: A Customer has at least one of the following:

  • a Rental Reservation.
  • an in-progress Rental.
  • a Rental completed in the past 5 years.
  1. Operative Rules (obligations): These are rules that govern the conduct of

business activity. In contrast to Structural Rules, Operative Rules are ones that can be directly violated by people involved in the affairs of the business. For example (from EU-Rent):

Obligation: A Customer who appears intoxicated or drugged must not be given possession of a Rental Car.

1.3.2. Rules, Fact Types and Concepts expressed by Terms

Informally, a fact type is an association („Association” is used here in its everyday, business sense - not the narrower, technical sense that would apply to a UML class model.) between two or more concepts; for example „Rental Car is located at Branch”. In SBVR, rules are always constructed by applying necessity or obligation to fact types. For example, the rule „A Rental must not have more than three Additional Drivers” is based on the fact type „Rental has Additional Driver”. By this means, SBVR realizes a core principle of the Business Rules Approach at the business level, which is that „Business rules build on fact types, and fact types build on concepts as expressed by terms.”

One important consequence of the SBVR’s approach in this regard is that concepts (including fact types) are distinct from rules, which are in a separate Compliance Point. This design permits SBVR’s support for concepts (including fact types) to be optionally used on its own for building business vocabularies.

1.4. Notations for Business Vocabulary+Rules

1.4.1. SBVR Structured English

It should be remembered that SBVR Structured English (presented in Appendix C,D) is just one of possibly many notations that can be used to express the SBVR Metamodel, and, as a notation, is nonnormative in the SVBR standard.

Two styles of SBVR Structured English are documented in this submission:

  1. Prefixed Rule Keyword Style
  2. Embedded (mixfix) Rule Keyword Style

The Prefix Style introduces rules by prefixing a statement with keywords that convey a modality. Examples of some of the prefixes are shown in the table below.

Operative Structural
It is obligatory that It is necessary that
It is prohibited that It is impossible that
It is permitted that It is possible that

The Embedded Style features the use of rule keywords embedded (usually in front of verbs) within rules statements of appropriate kinds. The table below shows a sample of embedded keywords used to form rules.

Operative Structural
… must … … always …
… must not … … never …
… may … … sometimes …

1.4.2. State

'State' is an important notion for business vocabularies and business rules. As far as business people are concerned, ‘state’ is a concept they can refer to and use in creating definitions, facts and rules. For example, in EU-Rent a car’s states would include: 'available', 'allocated to rental', 'on rental', 'damaged' and so on. The company uses these state names in defining business rules, e.g., „The car assigned to a walk-in rental must be the available car with the lowest odometer reading in the requested car group.” One way to express states is using unary predicates, e.g., „car is available”.

1.5. Business Modeller Editors

1.5.1. SBeaVeR

The SBeaVeR is a tool for modeling business vocabularies and business rules. It is an Eclipse based plugin, part of the Digital Business Ecosystem project.

1.5.1.1. SBeaVeR feature list

SBeaVeR key features are:

  • Business knowledge representation: SBeaVeR provides a tool for formalizing the semantics of business knowledge using the Structured English notation.
  • Portability: SBeaVeR is written in Java for portability and could be installed on many different operating systems without code changes. SBeaVeR
  • comes with all source code with EPL licence which can be modified or tailored to meet a user's specific needs.
  • Integration and Extensibility: SBeaVeR is based on Eclipse platform which allows to easily extend or integrate the tool by a user through the use of a well-defined framework.
  • Model validation: SBeaVeR includes a number of features to support the verification and validation of business models including semantic analysis of rule to determine possible inconsistencies.

From a functional point of view, SBeaVeR provides:

  • Presentation and user modification of SBVR Structured English business vocabularies and business rules.
  • Standard text editing operations (cut, copy, paste, find, replace).
  • Automatic syntax highlighting following the SBVR Structured English font styles.
  • Content assist to allow easy and fast creation of contents (automatic completion of known statements/words, automatic text formatting, collapse/expand).
  • Hierarchical navigation of vocabulary (multiple views).
  • Dictionary (at present we embed WordNet dictionary) support for synonyms, hypernyms, hyponyms, meronyms, definitions.
  • Mapping from in-memory Java representation of vocabulary and rules to logical representation.
  • XMI XML Schema serialization (following SBVR specs) allowing interchangeability of models between software tools.
1.5.1.2. Screenshots
  • Business rules editor

BusinessRulesEditor

  • Collapse/expand

  • Content assistant

contentassistant

  • Vocabulary editor

vocabularyeditor

  • Wordnet integration

wordnet_integration

  • XMI XML schema

xmi_xml_schema

1.5.2. Part of Model Development Tools (MDT)

The Model Development Tools (MDT) project focuses on modeling within the Modeling project. Its purpose is twofold:

  1. To provide an implementation of industry standard metamodels.
  2. To provide exemplary tools for developing models based on those metamodels.

The next release of MDT is tentatively scheduled for the end of June 2008. For the previous release, see New & Noteworthy.

SBVR provides a metamodel implementation and sample tools based on the adopted Semantics of Business Vocabulary and Business Rules (SBVR) OMG specification.

The objectives of the SBVR component are to provide:

  • an open source „reference” implementation of the SBVR specification
  • an EMF-based foundation on which business vocabulary and business rules modeling tools can be built
  • a basis for integrating and interchanging artifacts between business vocabulary and business rules tools
  • a forum for engaging the community in validation of the SBVR specification

In addition to an implementation of the SBVR metamodel, this component will include sample tools that aid in testing and validating the metamodel implementation, and that help SBVR newcomers to better understand its use and potential.

  • Project Explorer navigator view for business vocabularies and rules
  • Import business vocabulary from UML domain models
  • Code generation to Platform-Independent Model (PIM) technologies, such as UML and OCL

For more details on SBVR, see the Wiki.

Downloads coming soon!

2. Modelling 'thermostat' in SBVR

This is attempt to map 'thermostat', modelled in ARD, to SBVR.

This is the ARD model of 'thermostat':

ARDthermostat

All process of building this diagram is here

There are phrases of strucural language presented SBVR model of 'thermostat':

Vocabulary
  • office - local, where thermostat is installed
  • business hours (bizhrs) - time, when office is occupied
  • (nbizhrs) - time, when office isn't occupied
  • workday - Monday, Tuesday, Wednesday, Thursday, Friday
  • weekend - Saturday, Sunday
  • spring - March, April, May
  • summer - June, July, August
  • fall - September, October, November
  • winter - January, February, December
Rules
  • It is necessary, that in winter, on business hours, on workday, thermostat_settings is 25 degrees Celsius in office.
  • It is necessary, that in winter, beside business hours, on workday, thermostat_settings is 18 degrees Celsius in office.
  • It is necessary, that in winter, all weekend, temperature_settings is 18 degrees Celsius in office.
  • It is necessary, that in spring, on business hours, on workday, thermostat_settings is 20 degrees Celsius in office.
  • It is necessary, that in spring, beside business hours, on workday, thermostat_settings is 15 degrees Celsius in office.
  • It is necessary, that in spring, all weekend, thermostat_settings is 15 degrees Celsius in office.
  • It is necessary, that in summer, on business hours thermostat_settings is 24 degrees Celsius in office.
  • It is necessary, that in summer, beside business hours thermostat_settings is 27 degrees Celsius in office.
  • It is necessary, that in summer, all weekend, thermostat_settings is 27 degrees Celsius in office.
  • It is necessary, that in fall, on business hours thermostat_settings is 20 degrees Celsius in office.
  • It is necessary, that in fall, beside business hours thermostat_settings is 16 degrees Celsius in office.
  • It is necessary, that in fall, all weekend, thermostat_settings is 16 degrees Celsius in office.

3. Transformation of SBVR Business Design to UML Models

3.1. Introduction

Here is presented a methodology for transforming business designs written in OMG’s standard Semantics of Business Vocabulary and Rules (SBVR) framework, into a set of UML models. It involves the transformation of business vocabulary and rules written in SBVR’s ”Structured English” into a set of UML diagrams, which includes Activity Diagram(AD), Sequence Diagram(SD), and Class Diagram( CD). This transformation works by detecting the distinction between rules which will participate in the construction of Activity Diagram and rules which do not. These rules are imperative in nature. The work in the paper also includes the detection of activities embedded implicitly in those rules and establishment of sequence between those activities. These activities incur some action. We also detect their owner and refer to them as the doer of the action. This plays a very important role in the development of Class Diagrams.

3.2. SBVR toUMLActivity Diagram Mapping Rules

This section mainly deals with the mapping of SBVR components to UML Activity diagram components.

3.2.1. Initial Node

This is the start state of the activity diagram. It doesn’t play a very important role but significantly shows the starting point of a scenario. We have given it a default name ”start”.

3.2.2. Activity Node

As we have already discussed in section 3.3, the fact types having transitive verbs will be assumed as the activity node.

3.2.3. Activity Edge

An activity edge is a set of event, guard conditions and actions which allows the transition from one activity node to another activity node. An event is the trigger of the transition. Upon triggering the transition, the condition is checked, if the condition holds true, then the corresponding action occurs and brings another activity into existence. It is not necessary that a transition must have trigger. Transitions without the trigger is known as trigger less transitions. A typical SBVR operative rule may be written as:

upon event,

if <propositional expression 2>, then
<propositional expression 1>

But we are using the following format of operative business rules in SBVR

<propositional expression 1> [if <propositional expression 2>]

So, the mapping from these type of SBVR rules to UML AD will create the trigger less transitions. The propositional expression 2 will help to find out the guard condition and propositional expression 1 will help to find out the action.

  • Guard Condition: Assume an operative business rule like given below. The propositional expression 2 in
it is obligatory that each atm request exactly one password if a user inserts card

if clause refers to the fact type ’user inserts card’. Depending upon the fact type, we are creating a boolean variable like ’inserts card’. And the guard condition will become ’insert card == true’ as shown in Table 1. Fact Type Corresponding Boolean Variable Corresponding condition user inserts card inserts card inserts card = true atm request password request password request password = true

  • Action: These are the actions which should be invoked during the transition from one activity to another.

For example in the above rule, if a user inserts a card in the atm, then the atm will do an action ”request password”. What we are doing is taking the propositional expression 1 and find out the corresponding fact type. Merging of verb and last term of the fact type will create the name of the action like ”request password()”

3.2.4. ForkNode/JoinNode

  • ForkNode: This is a pseudo-state where one transition

is coming and multiple parallel transitions are going out of it. A SBVR rule like ”’it is obligatory that each atm print exactly one receipt and each atm eject the card if bank return badAccountmessage”’ represent the enforcement of two activities ”’atm print receipt”’ and ”’atm eject card”’ on the delivery of bad account message from the bank. This situation will generate the fork state. There will be an incoming transition 32 having the guard condition ”’return badAccountmessage == true”’ and two outgoing parallel transitions pointing toward activities ”’atm print receipt”’ and ”’atm eject card”’.

  • JoinNode: This is another pseudo-state where multiple

parallel transitions are coming and only one transition is outgoing. The generation of this state will be same as the above except there will be multiple guard conditions and only one outgoing transition.

3.2.5. ActivityGroup

The ActivityGroup in UML activity diagrams are generally known as swimlanes which basically represents who is doing the activity. The entity doing an activity will be referred as the giver of the activity. As we have already discussed that the representation of fact type(activity) can be of two type, active form and passive form. In a sentence having an active, transitive verb, the giver of the action of the verb is the subject of the sentence. In English, the ”giver” corresponds to the object filling the role of the first placeholder in the fact type form, e.g. ”customer” in ”customer places order.” If the fact type form is passive, e.g. ”order is placed by customer,” it is the reverse. These means the same thing. They are synonymous forms. Facts of either of these forms would be logically equivalent.

3.2.6. Activity Final Node

This is the point in an activity diagram where all the activities get end up. We are creating a default end state with the default name ”End”.

3.3. Mappin ARD 'thermostat' to Activity Diagram

There is attempt to map, moddeled in ARD, 'thermostat' to Activity Diagram

ad_themrostat

More about mapping SBVR model to UML diagrams, You can find in "Transformation of SBVR Business Design to UML Models"

4. Proposition of transformation ARD model to SBVR

4.1. Approach 1#

Creating diagram which shows all dependencies between SBVR vocabulary elements is often practice. The example of this diagram is below.

example_vocabulary

The way of building this diagram is like building class diagram in UML.

The 'thermostat' vocabulary diagram is presented below.

diagram1

When we try use, the same general rules, which were used to create ARD diagram to build class diagram the result of this operation is very similar to SBVR vocabulary diagram. It could be used to create way of mapping between ARD and SBVR vocabulary.

Thanks this approach we can try to build SBVR vocabulary. The Rules can be created also using 'general rules'.

4.2. Approach 2#

Looking at ARD diagram we try compose mapping rules to SBVR, but the result will be a bit different then original SBVR model presented in 3.2.

thermostatard

The operation block value is 'during business hours' or 'not during business hours'. The season value is 'summer' or 'autumn' or 'winter' or 'spring'.

So the first rules can be created are:

  • It is necessary, that in winter, on business hours thermostat_settings is 25 degrees Celsius in office.
  • It is necessary, that in winter, beside business hours thermostat_settings is 18 degrees Celsius in office.
  • It is necessary, that in spring, on business hours thermostat_settings is 20 degrees Celsius in office.
  • It is necessary, that in spring, beside business hours thermostat_settings is 15 degrees Celsius in office.
  • It is necessary, that in summer, on business hours thermostat_settings is 24 degrees Celsius in office.
  • It is necessary, that in summer, beside business hours thermostat_settings is 27 degrees Celsius in office.
  • It is necessary, that in fall, on business hours thermostat_settings is 20 degrees Celsius in office.
  • It is necessary, that in fall, beside business hours thermostat_settings is 16 degrees Celsius in office.

We can use the the last block and blocks level lower to create SBVR model.

It's hard to build mapping algorithm using only one ARD diagram, but this, I think, it's good point to create universal way of mapping from ARD to SBVR.

5. Literature

pl/miw/miw08_bizrulesvocabularies.txt · ostatnio zmienione: 2017/07/17 08:08 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0