Hi Les,
<<Hence my belief that object models are the best place for business rules. (Feel free to tell me that 1+1 does not equal 3 if you wish.)>> Business has (and always will) express itself through business rules - aren't they important enough to be modeled on their own? A business rule constrains how the business operates. To be effective, these constraints need to be expressed in their simplest form - as atomic statements that would not be meaningful if decomposed any further. These rule statements can made even more precise by using templates to reduce the ambiguity that comes with the use of human language. Atomic rule statements can be combined to create rule sets... The terms used in a business rule statement have to be used consistently throughout the 'rule population' and therefore must be defined. This the purpose of the so-called 'term' or 'fact model'. The fact model can be illustrated using UML to show associations between terms/entities. This is very similar to the business object model, except these business objects are light-weight and contain mostly structural rules such as for cardinality. All the other rule specifications are separated out and managed in a 'rule model'. In the rule model, rule statements are traced to the policy or regulations they enforce and to the parties responsible for maintaining them. As well, the places where a rule is implemented is traced. If this traceablity does not exist, the business may need to 'mine' their information systems to uncover the rules (undocumented and scattered about in code or in people's heads). That is, if they have decided that managing their business rules provides competitive advantage. To sum up, a business rule repository might be the best place to store rules, and a business rules approach the best way to model and manage them. Tony Morgan's book on business rules provides the table structure for creating your own rules repository using Access. http://www.amazon.com/exec/obidos/ASIN/0201743914/qid%3D1029371058/sr%3D11-1 /ref%3Dsr%5F11%5F1/103-5478617-3763027 Regards, -Richard PS As far as OCL goes, the Object Management Group (OMG) which controls the evolution of OCL is integrating business rules with their Model Driven Architecture (MDA). I believe OCL is more suited to representing rules at a low level, and will not be used by business analysts per se. ----- Original Message ----- From: "Les Munday" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 14, 2002 5:08 PM Subject: Re: RE: (ROSE) UML and Business Rules > > I know that I mentioned class diagram in my original response, > but what I actually said was that business rules could be > captured in a business object model. > > Second point is that I don't distinguish between the BOM and > the analysis model, so hopefully that lets me off the > statements that I made in the reply I made prior to this. > > [As an aside I wrote that previous reply without realizing that > so much interest had been generated by this thread.] > > In my limited experience of business modeling, I have been led > to understand that the Object Constraint Language was invented > specifically for the purpose of writing business rules. > > Most examples I see of the OCL in use, and all of my experience > of OCL, depict OCL expressions as attachments to object models. > Hence my belief that object models are the best place for > business rules. (Feel free to tell me that 1+1 does not equal 3 > if you wish.) > > Looking at the RUP recommendations and I see OCL used on state > diagrams, activity diagrams and object diagrams. All of these > could equally be used within an object model or a use case > model. I prefer object model for reasons that I think were > stated previously (mainly because we do not describe data > within use cases). > > So to address to poser set in this email. "A customer cannot > withdraw money from their account if the balance is <= 0" > > Class Customer has relationship to BankAccount with > attributes 'balance', and operation 'withdraw_money(amount)'. > Operation withdraw_money has constraint > > context Account inv: > pre: balance >= 0 > post: balance - amount >= 0 > > Excuse my OCL, but I think that this says that in order to > withdraw money your balance must be greater than zero and after > the amount has been withdrawn your balance must still be > greater than zero. > > Hands up how many people would put this constraint in a use > case. > Hands up how many think it would be better placed in an object > model. > > Les. > > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag > > > ---- On Wed, 14 Aug 2002, [EMAIL PROTECTED] ([EMAIL PROTECTED]) > wrote: > > > > > > > A large amount of business rules cannot be reflected in a > class diagram. > > Take for example the following rule: A customer cannot > withdraw money from > > their account if the balance is <= 0. How would I reflect > this rule in a > > class diagram? > > > > Regards, > > Walter Howard > > > > > > "Do you think," he asked, "if I go to the Emerald City with > you, that Oz > > would give me some brains?" - The Scarecrow, The Wizard of Oz > > > > > > > > > > > "Charles > Edwards" > > > > > <charles.edwards@proces > To: "'Baynes, Steve'" <[EMAIL PROTECTED]>, > > "'Les Munday'" > > swave.com> > <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > > > > Sent by: > cc: > > > > owner-rose_forum@ration > Subject: RE: (ROSE) UML and Business Rules > > > > > al.com > > > > > > > > > > > > > > > 08/14/2002 09:34 > AM > > > > Please respond > to > > > > > "Charles > Edwards" > > > > > > > > > > > > > > > > > > > > > > > > > On a recent project we found it useful to capture the > business rules > > separately (I like the idea of attaching them to the Business > Object > > Model - as per Les) one reason for this is that sometimes > many use cases > > could refer to one business rule or you end up cluttering up > the use > > cases with many business rules and they detract form the > essence of the > > Use Case. > > > > However we found it was good to uniquely name them and link > the name > > references to the actual business rules. > > > > Regards > > ____________________________________________ > > Charles Edwards > > > > www.elearningwave.com - elearning site > > www.processwave.net - Information Portal > > > > > > | -----Original Message----- > > | From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] > > | On Behalf Of Baynes, Steve > > | Sent: 14 August 2002 10:15 > > | To: Les Munday; '[EMAIL PROTECTED]' > > | Subject: RE: (ROSE) UML and Business Rules > > | > > | > > | All, The need for business rules must be captured in the > use cases. > > Use > > | cases are the requirements documents. The implementation > of the > > business > > | rules will flow throughout the rest of the analysis, design, > > | implementation > > | and testing. > > | > > | Business rules may be driven by object state transition, the > > | inter-relationship between objects etc. This means no > single > > artefact, > > | other than use cases, can capture the need for these rules. > > | > > | This is all "in my opinion". I look forward to some > different > > views... > > | > > | Regards > > | Stephen Baynes > > | > > | -----Original Message----- > > | From: Les Munday [mailto:[EMAIL PROTECTED]] > > | Sent: 13 August 2002 22:24 > > | To: '[EMAIL PROTECTED]' > > | Subject: Re: (ROSE) UML and Business Rules > > | > > | > > | > > | Since I think of business rules as generally applying to > > | attributes and relationships between attributs, and since we > > | don't reference attributes within use cases, I would not > > | recommend stating business rules in use cases. > > | > > | I also think of business rules as being flexible, much more > so > > | than I want my use cases to be. > > | > > | So my expectation would be to see business rules described > by a > > | business object model. I think that they attach quite > nicely to > > | the attributes and relationships in the class diagram. > > | > > | Much better place than use cases, IMO. > > | > > | Les. > > | > > | > > > | > UML and Business Rules - are these two things > complementary? > > | > Some people believe that when you use UML/Use Cases you > don't > > | need > > | > business rules techniques to capture business policies, > > | regulations, > > | > restrictions, etc. > > | > - since it got captured in use cases anyway. > > | > Other people think that UML is not sufficient for these > > | purposes. > > | > > > | > What is your approach to this? > > | > > > | > Thank you. > > | > > > | > David Lyalin > > | > > > > ************************************************************************ > * Rose Forum is a public venue for ideas and discussions. > * For technical support, visit http://www.rational.com/support > * > * Post or Reply to: [EMAIL PROTECTED] > * Subscription Requests: [EMAIL PROTECTED] > * Archive of messages: > * http://www.rational.com/support/usergroups/rose/rose_forum.jsp > * Other Requests: [EMAIL PROTECTED] > * > * To unsubscribe from the list, please send email > * To: [EMAIL PROTECTED] > * Subject: <BLANK> > * Body: unsubscribe rose_forum > ************************************************************************* > ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
