View
224
Download
1
Category
Tags:
Preview:
Citation preview
“Semantics of Business Vocabulary & Business Rules”
Business Rules Team Update
OMG Boston
June, 2005
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 2
Agenda
Current Status Changes since March 2005 submission Alignment with other OMG developments Vote for revised submission date
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 3
SBVR Current Status
Approx. 400 criticisms and suggestions received, since March submission. Welcomed by BRT – will simplify finalization Approx 80% addressed Of these, about 65% accepted, 10% rejected,
25% discussed/adapted/negotiated Too many loose ends for June submission Aiming for September
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 4
Topics
Feedback resolved – examples: Position wrt MDA & other BEIDTF RFPs Formal Logic Alignment with ODM
Feedback still open Linguistic v Logic view
W3C interest – submission & EU-Rent
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 5
What will SBVR do?SBVR supports realisation of the ‘Business Rules Mantra’:
Noun Concepts
Define Concepts
Fact TypesAssociate Concepts to Define Fact Types
BusinessRules
Base Business Rules on Fact Types
Vo
cab
ula
ry Develop Vocabularies to represent them(starting with terms for the concepts)
… to describe businesses, not the IT systems that serve them
“Rules are built on Facts. Facts are built on Terms.”
… in language understandable by business people
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 6
Overview of SBVR
Sub-communities may use different natural languages
and specialized vocabularies
Community
Concepts (including Fact Types) and Business Rules
Body of Shared Meanings
Representation of Body of Shared Meanings in Business Vocabulary
Business Representation
Abstract formulation of semantics
Semantic Formulation
First-Order Predicate Logic with some (limited)
extensions
Formal Logic
usesshares
structuredas
representedas
underpinsunderpins
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 8
A view of a system that focuses on the environment of the system, and the requirements for it. The details of the structure and processing are hidden or as yet undetermined A CIM is sometimes called a domain model. It is specified with a vocabulary that is familiar to the practitioners of the domain in question .
A view of a system that focuses on its operation while hiding the details necessary for a particular platform. It shows that part of the complete specification that does not change from one platform to another.It may be expressed in a general purpose modeling language, or a language specific to the area in which the system will be used..
A view of a system that combines the specifications in the PIM with the details that specify the system uses a particular type of platform.
Model-Driven Architecture (MDA)
Computation-Independent Model
(CIM)
Platform-Independent Model
(PIM)
Platform-Specific Model (PSM)
Three model-based views of a system, with transformations between themNote that this is not a model of a business - but of an information system that supports a business
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 9
Business Model / MDA Models
In a business model: “customer” (for example) is a role that people play in interacting
with the business. “a customer” is a person playing that role Business rules are for people; they can be broken and need
enforcement; they are actionable, but not necessarily automatable
In MDA models: “customer” is (usually) an abstraction that models the real-world
customer, such as a class in a UML model or a view defined in a database schema.
In some contexts, the business model view of “customer” does appear, e.g. as the user in a Use Case model
Rules are automatable, and will be enforced automatically in the implemented system
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 10
Model Driven Architecture (MDA)
Computation Independent Model
Platform Independent Model
Platform Specific Model
Business Model
Positioning of Business Model
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 11
Model Driven Architecture (MDA)
Computation Independent Model
Platform Independent Model
Platform Specific Model
Business Model
Positioning of BEIDTF RFPs
BPDM
OSM
BMM
SBVR
Production Rules
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 12
Business Model
SBVR
Model Driven Architecture (MDA)
Separation of Vocabulary?
Computation Independent Model
Platform Independent Model
Platform Specific Model
BPDM
OSM
BMM
Business Rules
Business Vocabulary
Production Rules
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 13
Model Driven Architecture (MDA)
Computation Independent Model
Platform Independent Model
Platform Specific Model
Business Model
Common Vocabulary?
Business Process
Organization Structure
Business Motivation
Business Rules
Business Vocabulary
Full support
Partial support
Production Rules
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 14
Future Integration
The BEIDTF has approached business modelling by issuing a number of separate RFPs, without any overall architecture This is not a criticism – sometimes it’s the only practicable way to
make progress At some points in the future, the results will have to be integrated
into a coherent whole The Business Motivation Model may provide the basis for an
“umbrella” under which the BEIDTF specifications can be aligned Creating a common business vocabulary specification would be
an important step In the meantime, there are a few “fuzzies” at the edges of SBVR,
where it will have to be aligned with responses to other BEIDTF RFPs The Business Process Definition Metamodel is probably the most
significant
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 16
Formal Logic Basis of SBVR
Documented in an Appendix to the submission, as the “Authoritative Source” In language directed at logicians May be repositioned for final submission
Aligned with “Common Logic” – draft standard 24707, currently being fast-tracked by ISO
Validated with Pat Hayes, consultant to ISO on Common Logic
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 17
SBVR Purpose
Captures business facts and business rules that may be expressed either informally or formally.
Business rule expressions are formal only if they are expressed purely in terms of: fact types in the pre-declared schema for the business
domain certain logical/ mathematical operators, quantifiers etc.
Formal rules are transformed into a logical formulation that is used for exchange with other rules-based software tools.
Informal rules may be exchanged as un-interpreted comments.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 18
SBVR Model (1)
Describes a business domain, and is comprised of: a conceptual schema (fact structure) a population of ground facts.
A business domain (universe of discourse) comprises those aspects of the business that are of interest
The schema declares: the relevant fact types (kinds of ground fact, e.g. Employee
works for Department) the relevant business rules (typically constraints or
derivation rules).
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 19
Facts
A fact is a proposition taken to be true by the business.
Population facts are restricted to elementary and existential facts.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 20
Structural Business Rules
Constraint: A static constraint imposes a restriction on what fact populations are
possible or permitted, for each fact population taken individually e.g. Each Employee was born on at most one Date.
A dynamic constraint imposes a restriction on transitions between fact populations e.g. a person’s marital status may change from single to married, but not from
divorced to single Derivation:
Either, how a fact type may be derived from one or more other fact types e.g. Person1 is an uncle of Person2 if Person1 is a brother of some Person3
who is a parent of Person2 Or, how a noun concept (object type) may be defined in terms of other object
types and fact types e.g. Each FemaleAustralian is a Person who was born in Country ‘Australia’
and has Gender ‘Female’
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 21
What is a Fact?
In SBVR: a proposition taken to be true by the business the business members are prepared to act as if they
believed the proposition is true; their attitude toward the proposition is one of epistemic commitment.
Does not require any special interpretation of logical operators, or use of epistemic or doxastic logic.
Logical connectives (and, or, not, if-then etc.) may be interpreted like truth functional operators (conjunction, disjunction, negation, material implication etc.) in 2-valued classical logic.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 22
Elementary Facts
An elementary fact is a declaration: Either, that an object has a property (e.g. The Country
named ‘Australia’ is large) Or, that one or more objects participate in a relationship
(e.g. The Prime Minister named ‘John Howard’ was born in the Country named ‘Australia’)
where the fact cannot, without information loss, be split into simpler facts with the same objects.
Multiple fact type readings using different predicates, possibly based on different orderings of the individuals, are considered to express the same fact if they mean the same.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 23
Existential Facts
An existential fact is used to simply assert the existence of an individual. E.g. there is a Country that has the CountryCode
‘US’.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 24
Denotation of Individuals
Individuals are typically denoted by definite descriptions. “The President named ‘Mary McAleese’” is treated as
shorthand for “The President who has the PresidentName ‘Mary McAleese’
Proper names may be used if they function as individual constants in the business domain.
Lexical individuals denote themselves (e.g. the country code ‘US’).
Individual constants may also be introduced as abbreviations of definite descriptions.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 25
Open/Closed World Semantics
Closed world semantics: all relevant facts are known (either as base facts or derivable). if a proposition cannot be proved true, it is
assumed to be false - negation by failure, since failure to find a fact implies its negation.
Open world semantics: knowledge may be incomplete: if a proposition and its negation are both absent, it
is unknown whether the proposition is true.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 26
SBVR – Open or Closed?
An SBVR model of any given business domain is restricted to propositions of interest to that domain.
If a proposition is not relevant, it is not included as a fact there, but not assumed to be false; it is simply dismissed from consideration.
For any business domain, there is a finite set of object types and fact types (typed predicates), and any object type or fact type outside this set is simply disregarded.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 27
SBVR – Open or Closed?
It is a practical issue whether knowledge pertaining to the population of a given fact type is complete or not, since this may impact how the business derives other facts (e.g. negations) or how it reacts to query results (e.g. whether to treat “not” as “not the case” or merely “not known to be the case”
For any given schema, the business might have complete knowledge about some parts and incomplete knowledge about other parts.
In practice, a mixture of open and closed world assumptions may apply.
We use the term “local closure” (or “relative closure”) for the application of the closed world assumption to just some parts of the overall schema.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 28
Business Rules
Structural Business Rules: use two alethic modal operators: it is necessary that … it is possible that …
Operative Business Rules: use two deontic modal operators: it is obligatory that … it is permitted that …
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 29
Structural Business Rules
Structural business rules (static constraints) are treated as alethic necessities by default, where each state of the fact model corresponds to a possible world
Pragmatically, the rule is understood to apply to all future states of the fact model, until the rule is revoked or changed.
For the model theory, the necessity operator is omitted from the formula. Instead, the rule is merely tagged as a necessity.
For compliance with Common Logic, such formulae can be treated as irregular expressions, with the modal necessity operator treated as an uninterpreted symbol
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 30
Normalization
If a modal operator is embedded later in the rule formulation, we try to “normalize” the formula by moving the modal operator to the front, using transformation rules such as
p Oq .. O(p q)
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 31
Normalisation Problems
In rare cases, a formula for a business rule might contain an embedded modality that cannot be eliminated by transformation.
For such cases, we could: Retain the modal operator in the rule formulation
and adopt the formal semantics of a particular modal logic.
Moving the embedded operators down to domain-level predicates (e.g. “is necessary”),
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 32
Operative Business Rules
If the rule includes exactly one deontic operator, e.g. O (obligation), and this is at the front, then the rule may be formalized as Op, where p is a first-order formula that is tagged as obligatory.
In SBVR, this tag is assigned the informal semantics: it ought to be the case that p (for all future states of the fact
model, until the constraint is revoked or changed) From a model-theoretic perspective, a model is an interpretation
where each non-deontic formula evaluates to true, and the model is classified as: a permitted model if the p in each deontic formula (of the form
Op) evaluates to true otherwise the model is a forbidden model (though still a model).
This approach removes any need to assign a truth value to expressions of the form Op.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 33
Embedded Deontic Modality
A formula for a static business rule might contain an embedded deontic modality that cannot be eliminated by transformation.
The business user can express the rule at a high level using embedded deontic operators
Where possible the formula is transformed to a first-order formula without modalities by replacing the modal operators by predicates at the business domain level.
These predicates (e.g. is forbidden) are treated like any other predicate in the domain, except that: Their names are reserved They are given some basic additional formal semantics to capture the
deontic modal negation rules: it is not obligatory that it is permitted that it is not the case that (~Op P~p); it is not permitted that it is obligatory that it is not the case that (~Pp O~p). These rules entail an exclusion constraint between the predicates is forbidden
and is permitted.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 34
Dynamic Operative Rules
Dynamic constraints apply restrictions on possible transitions between business states: compare one state to the next (e.g. salaries must never
decrease) compare states separated by a given period (e.g. invoices
must be paid within 30 days of being issued) Should be normalized for interchange between
tools: For each Invoice, if that Invoice was issued on Date1 then
it is obligatory that that Invoice is paid on Date2 where Date2 <= Date1 + 30 days
Normalized (moving deontic operator to the front): It is obligatory that each Invoice that was issued on Date1 is paid on Date2 where Date2 <= Date1 + 30 days
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 35
Dynamic Constraints - Issues
What rules licensed the normalization? Need an equivalence rule: p Oq .. O(p q).
Capturing the formal semantics in an appropriate logic (e.g. a temporal or dynamic logic). Possibilities include provide a temporal package that may be
imported, in order to provide a first-order logic solution.
adopt a temporal modal logic Final decision deferred
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 36
Higher-order Logic
SBVR can be used with: first-order logic higher-order logic restricted to Henkin semantics
Decision to use higher-order logic affects: categorization schemes un-normalized structures crossing levels/metalevels within the same model.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 37
Henkin Semantics
Restricts quantifiers to range over only individuals and those predicates/functions that are specified in the Body of Shared Meanings, where the n-ary predicates/functions (n > 0) range over a fixed set of n-ary relations/operations.
Retains some first-order properties (e.g. completeness, compactness) that are lost in the standard interpretation of higher-order logic.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 38
Common Logic (ISO 24707)
Common Logic: adopts the Henkin restriction on quantifier ranges does not adopt the comprehension axiom: for
each property there exists a set of elements having that property (sometimes expressed as “every formula defines a set”)
is open to extensions that adopt restricted versions of the comprehension axiom.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 39
SBVR and Set Comprehension
SBVR uses set comprehensions to define projections, as a way to specify result sets. E.g. given the fact type Employee(EmpNr) works for
Company(Name), the query “Who works for EU-Rent?” corresponds to the set comprehension:{x:Employee | y:Company; z:CompanyName (x works for y & y has z & z = ‘EU-Rent’)}
SBVR’s use of set comprehension is restricted: Any SBVR expression that defines a set must ultimately be
expressible only in terms of predefined base fact types, which must be either elementary or existential, and some basic logical operators (e.g. &)
SBVR’s “is an instance of” predicate caters for set membership, but is constrained to be irreflexive SBVR’s formation rules do not permit expressions of the form x
x (so avoiding Russell’s paradox)
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 40
OMG Ontology Definition Metamodel (ODM)
Alignment with ODM
UML 2.0
RDF Schema
Entity Relationship
OWL
Topic Maps
Common Logic
Met
amo
de
ls g
rou
nd
ed i
n
SBVR
Common Logic
+
Common Logic(ISO 24707)
Formal Logic basis of SBVR
Currently going through ISO “Fast
Track” process
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 42
The SBVR Specification (1)
SBVR specifies a metamodel for defining business vocabularies and business rules one aspect of a business model: others include
business policy, business process, geography and logistics, organization responsibilities
The SVBR metamodel, and specific models produced using it, are MOF/XMI compliant They can be stored and managed in repositories They can be interchanged as XML files
This is the OMG’s major focus, although Business Rule Management is the subject of a separate RFP
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 43
The SBVR Specification (2)
SBVR models must be worth interchanging The SVBR “vocabulary and rules for defining
business vocabulary and business rules” has to guide different practitioners, using different methodologies and tools, into producing consistent models It could not be just “everything is a thing” and “thing is
related to thing”, leaving practitioners to invent their own local semantics
Tools and methodologies will be neededThe BRT has addressed this in SBVR
The OMG will leave this to the industry - tool vendors, consultants and trainers
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 44
The SBVR Specification (3)
SBVR models must provide a rigorous basis for transformation to MDA-compliant IT specifications
The transformations are unlikely to be fully automated in the foreseeable future Many specification and design choices will need decisions
from both business and technical people Guidance and tools will be needed to support them
The OMG will be concerned with this in the future, when more of its business-oriented specifications
have been delivered and integrated
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 45
What could you do with an SBVR model?
If the tools were available: Send it to other parts of your company, or to close partners Store it in your repository, as guidance for your business and:
Manage it over time, as your business vocabulary and rules change
Validate and verify its content Use it as a basis for creating consistent, focused guidance for
different groups of people in your company, business partners, customers, suppliers …
Use it as input (with suitable tool support for transformation) to you IT specifications: Business applications Workflow
Wait for other aspects of business modelling to be realised in SBVR tools
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 46
Purpose of Templating
Fact Type templates provide patterns that are frequently encountered in practice Patterns for structures to capture meaning, not the form of
words (although particular methodologies might choose to do that)
They support consistency of methodology: they provide structure for knowledge elicitation they act as a checklist for content even when processes are different, the results are more
likely to be consistent when interchanged – of they were not included
If they were not included, practitioners would have to define equivalent semantics (SBVR is extensible), but would not all do so the same way.
OMG BEIDTF 20 June 2005 © 2005 Business Rules Team 47
Summary
Formal Logic Basis satisfactorily defined, aligned with ISO Common Logic
ODM alignment agreed in principle About 70 – 80 feedback points to be resolved
Some discussions needed with individuals Wider interest in SBVR– Semantic Web,
OASIS Requesting revised submission date for
Atlanta meeting (August 2005)
Recommended