Thanks for your interest in OPM. Indeed I hope to convince you that this is a very suitable candidate solution, developed over the past decade, to the problem of business modeling and rule formulating from many respects.
Here are the highlights of what makes it suitable:
1. Integration of structure and behavior (via objects and processes) in a single model prevent the model multiplicity problem.
2. That model is both graphical and textual. This provides powerful synergy and enables non-IT professionals who are experts in their domain to get involved in the process of business system modeling, of which rules are an integral part. The textual automatically generated interpretation - Object-Process Language (OPL) script is understandable to those processionals but is also input to compilation for implementation (code and DB) generation.
I will be giving a 4.5-day-long course on OPM at MIT's Summer Professional Institute. See
http://web.mit.edu/professional/summer/courses/computer/6.18s.html
I will be most delighted to see you there. My plan has been to come from Haifa directly to Boston (for 3 months) on July 1. Now I am not sure - it looks like I should really be at Orlando and take part in the Meeting.
As for your "desirements" - you have raised excellent points which I tried to respond to. Please see my responses below.
Best regards,
Dov
* There are different kinds of models, e.g. PIM, PSM. We need a business
rule modeling capability that can support, directly or through a
well-defined mapping, business modeling and system modeling, and, hence,
MDA. (Does business model = PIM, and system model = PSM?)
I think that indeed PIM must be a generic modeling approach that ignores current technologies and be based instead on foundations of ontology and General Systems Theory. Only this way can we model relieved of technical constraints of what can or cannot be with current platforms. OPM is just this. If needed, the PSM needs to evolve to cater to the requirements expressed by the PIM. This is definitely doable and in fact is happening, e.g. with Web Services.
* The paradigm for business modeling must be compatible with the system
modeling paradigm to support transformation of business models into system
models into implementations, a la MDA. This must be true for rules and the
information/data they operate on, as well as for the other constructs of a
business model.
I don't see a difference between business models and system models - a business system is a (specialization of) system (and BTW software system is too) and as such it has its structure and behavior aspects, reprehensible by objects and processes, intertwined to the extent that mandates the combination in a single model in order to be able to build the system model and communicate it to domain experts and peers.
* It is evident that business modeling includes process and activity
modeling, actors and collaborations, data and rules, independent of
implementation technology, expressed in a style that non-technical business
people can relate to. A truly meaningful discussion of rules needs to take
place in the context of a business modeling paradigm. The operative
challenge is to find a formulation for business rules that non-technical
business people are comfortable with, while retaining its needed formal
characteristics.
Exactly what OPM caters to.
* There are many kinds of rules, and rule hierarchies. Governing rules,
operating rules, structural rules, etc. Rules may be composed of many other
rules. We need to be able to describe these rule relationships.
I think that a concrete example would be most helpful. One option is to use Joaquin Miller's Gold Trading system, aimed at getting a handle on MDA application:
The example PIM is available at:
http://www.omg.org/cgi-bin/doc?ormsc/2002-05-01
It contains several rules but probably not as explicit and comprehensive as you would like to see for your purpose. If you could provide a sample "Problem Statement" document (preferably a real-life one) for the meeting this would help a lot to chew upon.
* Rule statements incorporate references to business data. A natural
language representation of rules, or close to it, is preferred in business
models, while maintaining formal correctness to the underlying data model
and data relationships implied by the rule statement.
This exactly the relation between the graphical OPD set mode and the corresponding OPL script.
* In analysis and design, business classes, attributes, and associations are
often derived from business rule statements. That is, the rule assumes the
existence of data it refers to. We need a way of expressing rules that will
enable the underlying data model to be derived, or that at least facilitates
creation of the data model. In doing this, alternative and ambiguous rule
terminology is problematic; the modeling capability needs to help manage
this.
The OPM model enables derivation of the underlying DB scheme (as I pointed out above).
* Business rules have different aspects that may need to be modeled:
Defining, or stating, the rule. Monitoring compliance/conformance to the
rule. Enforcing the consequences of attempted violation of the rule -- these
are the legislative, executive, and judicial responsibilities associated
with a rule. Different people, business organizations, and systems may be
responsible for each aspect. We need a metamodel for rules that we can use
to model these aspects.
This is why we need a system-theoretic, technology-independent approach.
* Business rules have responsible business owners, managers, and
implementers. Business rules change over time. Implementation of the rules
can change. Configurations of rules, relationships of rules to other rules,
can change. Rules in all their aspects need to be identified, located, and
managed. We need semantics to model the management of rules, as well as
modeling the expression of rules.
The same as above.
* Rules often have associated actions. Action semantics are applicable to
state actions, transformations, and activities, as well as rules. A single
language containing both predicate logic and action semantics is needed for
simplicity and generality.
Indeed. OPL does this. Consider for example the following sample OPL sentences taken form an ATM case study (bold are non-reserved words):
Bank Code Checking requires Consortium and Card Data.
Bank Code Checking determines whether Bank Code is valid.
Account Number Checking occurs if Bank Code is valid, otherwise Access Denying occurs.
Account Number Checking requires Bank and Card Data.
Account Number Checking determines whether Account Number is valid.
Cash Card Approving occurs if Account Number is valid, otherwise Access Denying occurs.
Cash Card Approving determines that Cash Card is valid.
Access Denying occurs either if Bank Code is not valid or if Account Number is not valid.
Access Denying determines that Cash Card is not valid.
* Two popular alternative approaches to implementing rules are emerging. One
is based on the use of constraints, derivation rules, and conditional
actions directly associated with classes, attributes, or associations. The
other is based on a network of predicate logic statements that reference the
data but are disassociated from it in implementation. The latter technique
employs so-called inference engines, commonly based on Charles Forgy's RETE
algorithm, and is particularly attractive where the rules change frequently,
and where there are many, often subtle, interactions between rules. We need
a business rule modeling capability that can support both of these forms of
rule implementation, and perhaps others as well.
I believe the can be done with OPM.
Dov
======================================================================
Hello Dov,
I have been watching with interest the email traffic on this topic today. Can you outline for me, please, what facilities OPM has to support business rules?
Are you planning to attend the Orlando meeting? I'm interested to learn more about OPM, and would enjoy meeting you. Are you in Haifa or Cambridge? (I'm an MIT alum.)
Here are some points of view and some "desirements" as fuel for discussion in Orlando, hopefully leading to some "requirements." I would enjoy hearing your response.
* There are different kinds of models, e.g. PIM, PSM. We need a business rule modeling capability that can support, directly or through a well-defined mapping, business modeling and system modeling, and, hence, MDA. (Does business model = PIM, and system model = PSM?)
* The paradigm for business modeling must be compatible with the system modeling paradigm to support transformation of business models into system models into implementations, a la MDA. This must be true for rules and the information/data they operate on, as well as for the other constructs of a business model.
* It is evident that business modeling includes process and activity modeling, actors and collaborations, data and rules, independent of implementation technology, expressed in a style that non-technical business people can relate to. A truly meaningful discussion of rules needs to take place in the context of a business modeling paradigm. The operative challenge is to find a formulation for business rules that non-technical business people are comfortable with, while retaining its needed formal characteristics.
* There are many kinds of rules, and rule hierarchies. Governing rules, operating rules, structural rules, etc. Rules may be composed of many other rules. We need to be able to describe these rule relationships.
* Rule statements incorporate references to business data. A natural language representation of rules, or close to it, is preferred in business models, while maintaining formal correctness to the underlying data model and data relationships implied by the rule statement.
* In analysis and design, business classes, attributes, and associations are often derived from business rule statements. That is, the rule assumes the existence of data it refers to. We need a way of expressing rules that will enable the underlying data model to be derived, or that at least facilitates creation of the data model. In doing this, alternative and ambiguous rule terminology is problematic; the modeling capability needs to help manage this.
* Business rules have different aspects that may need to be modeled: Defining, or stating, the rule. Monitoring compliance/conformance to the rule. Enforcing the consequences of attempted violation of the rule -- these are the legislative, executive, and judicial responsibilities associated with a rule. Different people, business organizations, and systems may be responsible for each aspect. We need a metamodel for rules that we can use to model these aspects.
* Business rules have responsible business owners, managers, and implementers. Business rules change over time. Implementation of the rules can change. Configurations of rules, relationships of rules to other rules, can change. Rules in all their aspects need to be identified, located, and managed. We need semantics to model the management of rules, as well as modeling the expression of rules.
* Rules often have associated actions. Action semantics are applicable to state actions, transformations, and activities, as well as rules. A single language containing both predicate logic and action semantics is needed for simplicity and generality.
* Two popular alternative approaches to implementing rules are emerging. One is based on the use of constraints, derivation rules, and conditional actions directly associated with classes, attributes, or associations. The other is based on a network of predicate logic statements that reference the data but are disassociated from it in implementation. The latter technique employs so-called inference engines, commonly based on Charles Forgy's RETE algorithm, and is particularly attractive where the rules change frequently, and where there are many, often subtle, interactions between rules. We need a business rule modeling capability that can support both of these forms of rule implementation, and perhaps others as well.
Kindest regards,
Stan Hendryx
Hendryx & Associates
505 S. Murphy Ave.
Sunnyvale, CA 94086
phone: 408 773-8089
mobile: 408 218-9455
Stan@HendryxAssoc.com
-----Original Message-----
From: Dov Dori [mailto:dori@ie.technion.ac.il]
Sent: Monday, May 27, 2002 11:11 AM
To: 'Daniel Duffy'; 'Stan Hendryx'; adtf@omg.org; ptc@omg.org;
dtc@omg.org; businessrules@omg.org; syseng@omg.org
Cc: I.Mayer@Springer.de
Subject: RE: Business Rules Working Group Meeting
I totally agree with Daniel about the "object-oriented straightjacket"
of trying to model systems in general and business rules (as part of
business systems) in particular without due consideration of the
processes that are an integral part of any system.
Object-Process Methodology (OPM) was developed with exactly this in
mind.
Natural and artificial systems alike exhibit three major aspects:
function (what these systems do), structure (how they are constructed),
and behavior (how they change over time). Since OPM does not make any
assumptions regarding the nature of the system in question, it can be
applied in any domain of human study or endeavor. In the case of
artificial systems, it provides a framework for the entire system's
lifecycle, from the early stages of requirement elicitation and
analysis, through further development and deployment, all the way to
termination and initiation of a new generation.
OPM combines formal yet simple graphics with natural language sentences
to express the function, structure, and behavior of systems in an
integrated, single model. The two description modes OPM uses are
semantically equivalent, yet appeal to two different parts of the brain,
the visual and the lingual. OPM is a prime vehicle for carrying out the
tasks that are involved in system development. It does so in a
straightforward, friendly, unambiguous manner. The design of OPM has not
been influenced by what current programming languages can or cannot do,
but rather, what makes the most sense. Due to the resulting
intuitiveness, OPM is communicable to peers, customers and implementers.
At the same time, the formality of OPM makes it amenable to computer
manipulation for automatically generating large portions of the
conceived system, notably program code and database schema.
A comprehensive treatment of OPM is provided in my book
Object-Process Methodology - A Holistic Systems Paradigm (by Springer,
450 pp with a CD-ROM) which is in print and will be available in a few
weeks.
I have proposed OPM as a basis for UML 2.
I suggest that OPM be taken seriously as a possible foundation for MDA
and OMG's Systems Engineering initiative.
Dov Dori
Technion, Israel Institute of Technology, and
Massachusetts Institute of Technology, dori@mit.edu
-----Original Message-----
From: omg-list-errors@emerald.omg.org
[mailto:omg-list-errors@emerald.omg.org] On Behalf Of Daniel Duffy
Sent: Monday, May 27, 2002 8:57 AM
To: Stan Hendryx; adtf@omg.org; ptc@omg.org; dtc@omg.org;
businessrules@omg.org; syseng@omg.org
Subject: RE: Business Rules Working Group Meeting
This is a very welcome development. Integrating UML and business rules
is long overdue. However, I am worried about the 'entry point' of the
project, alternatively known as assumptions. In my opinion, business
rules should be modelled independently of UML. Adopting the viewpoints
of extending UML to fit business models will not be optimal (I feel)
because we are then put into an object-oriented straightjacket. Objects
are not very useful in business modelling; processes and activities are
more important.
MDA is my opinion is too solution-orinted; the missing link is to define
notation for the business world.
Daniel Duffy
> -----Original Message-----
> From: Stan Hendryx [mailto:Stan@HendryxAssoc.com]
> Sent: 25 May 2002 18:31
> To: adtf@omg.org; ptc@omg.org; dtc@omg.org; businessrules@omg.org;
> syseng@omg.org
> Subject: Business Rules Working Group Meeting
>
>
> The Business Rules Working Group (BRWG) will be meeting on
> Monday, June 24,
> 900-1700, at the OMG Technical Meeting in Orlando. This is
> the first meeting
> of the working group. You are cordially invited to attend, and to
> participate in formulating RFP's for business rule extensions
> to the UML. If
> you have not yet registered for the meeting, registration
> information is
> attached.
>
>
> The BRWG was created by the ADTF in January 2002 to address
> the ability of
> the UML to include richer business rule semantics in models.
> Although the
> BRWG was chartered by the ADTF, its work is very applicable
> to many other
> domain and platform task forces and SIGs. All interested
> parties are invited
> and encouraged to participate in the BRWG.
>
> Business rule extensions to UML are proposed to address both
> a rich business
> rule expression capability and business rule management
> modeling capability.
> With such added capabilities, the UML would serve as a common
> language for
> modeling and model interchange, for both conceptual modeling
> of the business
> and for system modeling. Such a language capability is seen
> as an important
> enabling technology for MDA. With such an extended UML, it
> will be possible
> to create conceptual models of the business in a style non-technical
> business people can relate to, and that focus on the issues of primary
> concern to business people. These conceptual models can have
> the platform
> independent content business people need to include in an unambiguous
> description of their business policies, constraints, and other rules,
> together with related business information concepts, business process
> concepts, and business event concepts. The rule management language
> capabilities will permit rules and rule sets to be
> categorized, configured,
> changed, deployed and managed with easily modeled platform independent
> processes. With these extensions, platform independent
> models (PIMs) can be
> complete, correct, and consistent, and independently
> verifiable. With a
> common language for both conceptual and system modeling, MDA automated
> translations from PIM to platform specific model (PSM) to
> code would be
> facilitated, allowing separate development of model
> translators and PIMs,
> based on a common metamodel for PIMs and PSMs. Such is the
> vision of the
> BRWG.
>
> The objective of the June meeting is to define the scope and
> outline the
> content of requests for proposals for a business rule
> expression extension
> of UML and for a business rule management extension to UML.
> Such extensions
> would include both a UML Profile and a MOF model.
>
> Morning -- presentations from practitioners about the problem
> we are trying
> to solve with the UML extensions, and some solution approaches being
> discussed for rule expression and rule management.
>
> Afternoon -- working session to scope and outline the RFPs.
>
> By the end of the day, I hope we can achieve a consensus
> about answers to
> the questions, "What would a BR extension to UML be used
> for?" and "What
> features and capabilities are needed to use it effectively?"
> We need to get
> to a level of understanding that we can draft meaningful RFPs.
>
> You don't have to be an OMG member to participate in the
> BRWG, but you do
> have to be an OMG member to vote on proposals. OMG membership is open.
>
> If any of you have comments, suggestions, or agenda items you
> would like to
> communicate before the meeting, please feel to contact me.
>
> I look forward to seeing you in Orlando!
>
> Stan Hendryx,
> Chair, Business Rules Working Group
>
> Hendryx & Associates
> 505 S. Murphy Ave.
> Sunnyvale, CA 94086
> phone: 408 773-8089
> mobile: 408 218-9455
> Stan@HendryxAssoc.com
>