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 *************************************************************************
