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.
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:
kinds of terms and meanings (other than meanings of Business Rules);
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.
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:
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:
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:
Prefixed Rule Keyword Style
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
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
The Model Development Tools (MDT) project focuses on modeling within the Modeling project. Its purpose is twofold:
To provide an implementation of industry standard metamodels.
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':
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.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.
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
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
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”’.
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
4.1. Approach 1#
Creating diagram which shows all dependencies between SBVR vocabulary elements is often practice.
The example of this diagram is below.
The way of building this diagram is like building class diagram in UML.
The 'thermostat' vocabulary diagram is presented below.
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.
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:
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