RE: (ROSE) UML and Business Rules
Title: RE: (ROSE) UML and Business Rules Stephen wrote "the only place to capture (document) business rules is through the requirements". I should have emphasised that our integration of ReqPro and Softlaw's expert rulebase system is done exactly that way. We start with a legal document (hopefully in Word) and mark each clause as a ReqPro requirement. We decide if the clause needs to be modelled and record our decision using ReqPro attributes. If the clause needs modelling, we translate it into a set of statements which may be evaluated to find out if the clause is met. For example, a clause 911B might be "a person who operates in this jurisdiction requires a licence unless ...". We would create statements such as "clause 911B is satisfied", "the person operates in this jurisdiction", "the person requires a licence", "the person has a licence". The statements are written into the source document, added to ReqPro as database requirements, and traced to the clause requirement. (They are ReqPro database requirements because they may be re-used in multiple locations in multiple source documents). The statements are also copied to the rulebase, which does some fancy English parsing to produce alternatives like "the person does not require a licence", "the person might require a licence", "does the person have a licence?". The rules themselves are captured in the expert system, and can be viewed in English by lawyers, managers, etc, as follows 236: Clause 911B is satisfied if: option 1: 70: The person operates in this jurisdiction; and 77: The person requires a licence; and 3313: The person has a licence; ~236: If this is not the case, then it will be concluded that clause 911B is not satisfied. Some statements, such as "the person has a licence" cannot be determined from rules, but need to be captured in a database. We use ReqPro attributes to indicate which table it belongs to, and all the controls to position it in our data entry system, where it might appear as "do you have a licence?" A nice outcome (which unexpectedly lopped three man months of work from the project) is that we could hyperlink each statement to every clause using it, by accessing the ReqPro traceability links. So the end-user can find out why we are asking that particular question, and all its legal contexts! Cheers Richard Brand -- Manager Business Systems APIR Systems Pty Ltd Unit 2/39 Jardine Street Kingston ACT 2604 phone 61 2 6260 6035 fax 61 2 6260 6037 mobile 0418 568 358
RE: (ROSE) UML and Business Rules
All, It could be (and it is quite possible) that I am going mad but I still think we are missing the point. my view is - the only place to capture (document) business rules is through the requirements. To elaborate, the business rules can be documented in use cases, supplementary use cases, UML, mathematical representation, rules database or any other method we can come up with but, business rules are captured through the requirements. This does not mean we cannot discover other business rules as we go through the elaboration of the system but it does mean if new business rules are discovered they are captured through the requirement mechanism. Once the business rules have been captured they are elaborated throughout the design process using the BOM, relationships, OCL and all the tools at our command. As an aside if we do not capture business rules through the requirements how do we test them? Regards Stephen Baynes System Architect -Original Message- From: Lyalin, David S. [mailto:[EMAIL PROTECTED]] Sent: 26 August 2002 22:25 To: 'Baker, Bryon'; '[EMAIL PROTECTED]' Cc: Buhtz, Greg; Baynes, Steve; 'Bennett Simon'; 'Richard Howlett'; 'Les Munday'; 'Eric D. Tarkington'; 'eleadsolutions'; 'Romuald Restout'; '[EMAIL PROTECTED]'; 'Charles Edwards'; '[EMAIL PROTECTED]'; 'G H Smith'; 'Kennedy, Patrick'; Lyalin, David S. Subject: RE: (ROSE) UML and Business Rules Bryon, Thank you for your response. A couple of issues that I would like ask you to clarify: 1. Your statement: "The important thing to remember is that you want to get to writing code some day. Don't spend all your time arguing on where to put the business rules" indicates that you view the main goal of business modeling as to support software development. Actually, business modeling is not necessarily directly connected to IT development. It is often used to document a business (or consensus about business practices), to serve as a blueprint for business improvement and re-engineering, to support training, etc. These, "non-IT" applications of a business model have great value for the business. Your position regarding role of the business modeling explains a reason for the problem that I described earlier in this thread: "Major efforts with Rose development are directed towards enhancing design-related and code generation tasks at the expense of analysis-related tasks." I do believe that this is a strategic miscalculation and it put the future of Rose as business modeling tool in question. 2. Would be interesting to know your view on the following fundamental question: "Is UML sufficient for business modeling?" My answer is - yes. Your answer would help to clarify Rational positioning as a Business modeling tool further. Other vendors describe Rose as a tool for software development with "light" business modeling capabilities? Are you agree? (I hope, you don't). Can you see Rose competing on the arena of Business Modeling Tools? 3. Business rules. I don't think that this issue deserve the "light" treatment. When business rule changes, the change has to be propagated from a single place down to all places where it used. Approach that you described does not allow this. Again, I'll re-post a question from this thread, hoping that you can comment on it: Two schools of thought relate to business rules: A. UML/RUP - a good reference source would be "Guidelines: Business Rules" section of RUP B. Business Rules community, like: http://www.businessrulesgroup.org/brghome.htm http://www.businessrulesforum.com/ http://www.brsolutions.com/index.shtml It looks like these two approaches exist in different worlds. The question is - could UML-based business model be complemented and benefit from the second approach (which is well developed and has many followers)? Thank you. David Lyalin -Original Message- From: Baker, Bryon [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 11:08 AM To: 'Lyalin, David S.'; '[EMAIL PROTECTED]' Cc: Buhtz, Greg Subject: RE: (ROSE) UML and Business Rules Folks, I am not subscribed to this list, but I was informed of this thread through one of our Tech Support folk. In particular this comment was what prompted him to email me: >Thank you to everybody who participated in very interesting discussions >on the subjects of "UML and Business Rules" & "Business Modeling with UML". >...the fact that nobody from Rational Corp. addressed these issues are >disturbing. I afraid that Rational is missing the whole point about >business modeling and has no strategy on this matter. If so - the >future of Rose as a business modeling tool would be in question. >Again, thank you for sharing your thoughts " The reason
RE: (ROSE) UML and Business Rules
Title: RE: (ROSE) UML and Business Rules Bryon recently wrote "Business rules are captured in a single artifact if you simply have too many to manage. (For example, an application that had a single use case for assessing social security eligibility had over 32,000 business rules imposed by the government.)" In our latest compliance project, our 'artifact' is a complete rulebase developed using Softlaw Corporation's legal expert system. The rulebase uses a sort of boolean logic (values true, false plus an additional "unsure") and has impressive natural language capabilities to assist users at run time (and lawyers during development!) understand what is going on. Our users can run compliance scenarios arising from government regulation of the Australian Financial Services Industry. The rulebase has 1,300 logic rules derived primarily from legislation and regulation. Our database is designed to store complex industry relationships which are mapped to contribute some 3,000 facts which may be needed by the 1,300 rules, in any given senario. The facts used by the rulebase have been tightly integrated with ReqPro, initially to manage the rulebase development. The integration now is so tight that our data entry screens are generated directly from ReqPro requirements! See http://programs.rational.com/success/Success_StoryDetail.cfm?ID=247 for more details. The development team has been around 10 people. For comparison, an Australian social security eligibility system, using the same expert system but without ReqPro, currently has about 160 developers and has, I believe, some 7,000 facts and 4,000 logic rules. Happy to provide more information off-line Richard Brand -- Manager Business Systems APIR Systems Pty Ltd Unit 2/39 Jardine Street Kingston ACT 2604 Australia phone 61 2 6260 6035 fax 61 2 6260 6037 mobile 0418 568 358
RE: (ROSE) UML and Business Rules
Comments inline -Original Message- From: Lyalin, David S. [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 3:25 PM To: 'Baker, Bryon'; '[EMAIL PROTECTED]' Cc: Buhtz, Greg; 'Baynes, Steve'; 'Bennett Simon'; 'Richard Howlett'; 'Les Munday'; 'Eric D. Tarkington'; 'eleadsolutions'; 'Romuald Restout'; '[EMAIL PROTECTED]'; 'Charles Edwards'; '[EMAIL PROTECTED]'; 'G H Smith'; 'Kennedy, Patrick'; Lyalin, David S. Subject: RE: (ROSE) UML and Business Rules Bryon, Thank you for your response. A couple of issues that I would like ask you to clarify: 1. Your statement: "The important thing to remember is that you want to get to writing code some day. Don't spend all your time arguing on where to put the business rules" indicates that you view the main goal of business modeling as to support software development. Actually, business modeling is not necessarily directly connected to IT development. It is often used to document a business (or consensus about business practices), to serve as a blueprint for business improvement and re-engineering, to support training, etc. These, "non-IT" applications of a business model have great value for the business. Your position regarding role of the business modeling explains a reason for the problem that I described earlier in this thread: "Major efforts with Rose development are directed towards enhancing design-related and code generation tasks at the expense of analysis-related tasks." I do believe that this is a strategic miscalculation and it put the future of Rose as business modeling tool in question. [brb]I'll rephrase my comment. "You do not want to get stuck in analysis paralysis." I stand by my point that business rules are captured in many different places. There is no rule that says they are better documented in one place versus another. It is a case-by-case decision. 2. Would be interesting to know your view on the following fundamental question: "Is UML sufficient for business modeling?" My answer is - yes. Your answer would help to clarify Rational positioning as a Business modeling tool further. Other vendors describe Rose as a tool for software development with "light" business modeling capabilities? Are you agree? (I hope, you don't). Can you see Rose competing on the arena of Business Modeling Tools? [brb]The UML is certainly sufficient for business modeling. Rose is "light" in business modeling capabilities from the point of view that it does not provide any of the simulation for activity-based costing that many other tools provide. I believe Ensemble used to have an Add In for that - but I do not know if you can still buy it. If you ignore the simulation feature set then I would argue that Rose is equal to or better than most of them because the notation and process for doing business modeling is elaborative instead of decompositive (is that a word? :) Your models reflect reality; are easier to develop; and understand. 3. Business rules. I don't think that this issue deserve the "light" treatment. When business rule changes, the change has to be propagated from a single place down to all places where it used. Approach that you described does not allow this. Again, I'll re-post a question from this thread, hoping that you can comment on it: Two schools of thought relate to business rules: A. UML/RUP - a good reference source would be "Guidelines: Business Rules" section of RUP B. Business Rules community, like: http://www.businessrulesgroup.org/brghome.htm http://www.businessrulesforum.com/ http://www.brsolutions.com/index.shtml It looks like these two approaches exist in different worlds. The question is - could UML-based business model be complemented and benefit from the second approach (which is well developed and has many followers)? [brb]I shall have to get back to you on this as I am unfamiliar with these web sites. As an aside I do think that Ericsson and Penker have an excellent discussion on business rules in their book Business Modeling with the UML that you should look at also. Thank you. David Lyalin -Original Message- From: Baker, Bryon [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 11:08 AM To: 'Lyalin, David S.'; '[EMAIL PROTECTED]' Cc: Buhtz, Greg Subject: RE: (ROSE) UML and Business Rules Folks, I am not subscribed to this list, but I was informed of this thread through one of our Tech Support folk. In particular this comment was what prompted him to email me: >Thank you to everybody who participated in very interesting discussions >on the subjects of "UML and Business Rules" & "Business Modeling with UML". >...the fact that nobody from Rational Corp. addressed these issues are >d
RE: (ROSE) UML and Business Rules
Bryon, Thank you for your response. A couple of issues that I would like ask you to clarify: 1. Your statement: "The important thing to remember is that you want to get to writing code some day. Don't spend all your time arguing on where to put the business rules" indicates that you view the main goal of business modeling as to support software development. Actually, business modeling is not necessarily directly connected to IT development. It is often used to document a business (or consensus about business practices), to serve as a blueprint for business improvement and re-engineering, to support training, etc. These, "non-IT" applications of a business model have great value for the business. Your position regarding role of the business modeling explains a reason for the problem that I described earlier in this thread: "Major efforts with Rose development are directed towards enhancing design-related and code generation tasks at the expense of analysis-related tasks." I do believe that this is a strategic miscalculation and it put the future of Rose as business modeling tool in question. 2. Would be interesting to know your view on the following fundamental question: "Is UML sufficient for business modeling?" My answer is - yes. Your answer would help to clarify Rational positioning as a Business modeling tool further. Other vendors describe Rose as a tool for software development with "light" business modeling capabilities? Are you agree? (I hope, you don't). Can you see Rose competing on the arena of Business Modeling Tools? 3. Business rules. I don't think that this issue deserve the "light" treatment. When business rule changes, the change has to be propagated from a single place down to all places where it used. Approach that you described does not allow this. Again, I'll re-post a question from this thread, hoping that you can comment on it: Two schools of thought relate to business rules: A. UML/RUP - a good reference source would be "Guidelines: Business Rules" section of RUP B. Business Rules community, like: http://www.businessrulesgroup.org/brghome.htm http://www.businessrulesforum.com/ http://www.brsolutions.com/index.shtml It looks like these two approaches exist in different worlds. The question is - could UML-based business model be complemented and benefit from the second approach (which is well developed and has many followers)? Thank you. David Lyalin -Original Message- From: Baker, Bryon [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 11:08 AM To: 'Lyalin, David S.'; '[EMAIL PROTECTED]' Cc: Buhtz, Greg Subject: RE: (ROSE) UML and Business Rules Folks, I am not subscribed to this list, but I was informed of this thread through one of our Tech Support folk. In particular this comment was what prompted him to email me: >Thank you to everybody who participated in very interesting discussions >on the subjects of "UML and Business Rules" & "Business Modeling with UML". >...the fact that nobody from Rational Corp. addressed these issues are >disturbing. I afraid that Rational is missing the whole point about >business modeling and has no strategy on this matter. If so - the >future of Rose as a business modeling tool would be in question. >Again, thank you for sharing your thoughts " The reason you saw no reply from anyone within Rational is probably because no one in the product group responsible for business modeling is on this forum. They are more likely on the RUP forum. The lack of response was certainly not because we have no strategy. I personally receive about 100 emails per day and subscribing to and responding to all the forums would be another full time job for me. So enough with the reasons why you never got a reply - on with the reply. :-) The whole thread was quite long and I gleaned the following questions/comments from my quick read through it: 1. UML and business rules - are they complimentary? 2. What are business rules? 3. Where do you capture them? 4. How do you describe them? 5. What is Rational's commitment to business modeling? 1. Are the UML and business rules complimentary? Business rules have traditionally been defined in simple text. The UML is just another form that you can use to express the rule. The benefit of using the UML is that it can reduce ambiguity. So the UML is just a way to express the business rule. (I fact, to absolutely define a business rule that cannot be misinterpreted you would use some form of mathematical equation. OCL provides that capability.) 2. A business rule, as defined by RUP, is a declaration of policy or condition that must be satisfied within the business. It is something that may be imposed on a business by a regulatory authority, or something the business decides must be done/conformed to. 3. You can, and do, capture b
RE: (ROSE) UML and Business Rules
Folks, I am not subscribed to this list, but I was informed of this thread through one of our Tech Support folk. In particular this comment was what prompted him to email me: >Thank you to everybody who participated in very interesting discussions >on the subjects of "UML and Business Rules" & "Business Modeling with UML". >...the fact that nobody from Rational Corp. addressed these issues are >disturbing. I afraid that Rational is missing the whole point about >business modeling and has no strategy on this matter. If so - the >future of Rose as a business modeling tool would be in question. >Again, thank you for sharing your thoughts " The reason you saw no reply from anyone within Rational is probably because no one in the product group responsible for business modeling is on this forum. They are more likely on the RUP forum. The lack of response was certainly not because we have no strategy. I personally receive about 100 emails per day and subscribing to and responding to all the forums would be another full time job for me. So enough with the reasons why you never got a reply - on with the reply. :-) The whole thread was quite long and I gleaned the following questions/comments from my quick read through it: 1. UML and business rules - are they complimentary? 2. What are business rules? 3. Where do you capture them? 4. How do you describe them? 5. What is Rational's commitment to business modeling? 1. Are the UML and business rules complimentary? Business rules have traditionally been defined in simple text. The UML is just another form that you can use to express the rule. The benefit of using the UML is that it can reduce ambiguity. So the UML is just a way to express the business rule. (I fact, to absolutely define a business rule that cannot be misinterpreted you would use some form of mathematical equation. OCL provides that capability.) 2. A business rule, as defined by RUP, is a declaration of policy or condition that must be satisfied within the business. It is something that may be imposed on a business by a regulatory authority, or something the business decides must be done/conformed to. 3. You can, and do, capture business rules anywhere. There is no rule (pun intended) as to where you should capture them. You should just do whatever makes sense. In fact you probably don't even realise that you are capturing business rules all the time in many places. For example: a) Business rules are captured in your use cases every time you write step 1, 2, 3 - otherwise you would say: "perform the steps in any order". The order specified is actually a business rule. b) Business rules are captured in the BOM every time you define a sequence of interactions. You are describing the internal sequence that must occur to deliver the business value to the customer. Performing them out of sequence would not deliver the correct value. c) Business rules are captured in the business domain model by associations between business entities. d) Business rules are captured in the special requirements section of the use-case specification if they apply to a single use case. e) Business rules are captured in the supplementary specification if they apply to multiple use cases. d) Business rules are captured in a single artifact if you simply have too many to manage. (For example, an application that had a single use case for assessing social security eligibility had over 32,000 business rules imposed by the government.) The important thing to remember is that you want to get to writing code some day. Don't spend all your time arguing on where to put the business rules. 4. You can describe business rules as simple text at one extreme or use OCL at the other extreme. The more critical a system (e.g. some one may die if you get it wrong) the more important it is to define everything more formerly - not just business rules. 5. I am not permitted to discuss any futures but I can say this: "watch this space". Rational is certainly committed to business modeling and you will see good things in the future. Regards Bryon -Original Message- From: Lyalin, David S. [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 8:30 AM To: '[EMAIL PROTECTED]' Subject: (ROSE) UML and Business Rules 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/suppo
Re: (ROSE) UML and Business Rules
Hi, <> Ellen Gottesdiener's point is that we need to be concerned with defining and managing business rules. Part of her practice centers around managing business rules and the application of the business rules approach. Rules certainly need to be *traced* to requirements, such as use cases - but not included in them. Lets say business rule BR1 impacts many use cases. If BR1 were to be included (buried) within each of these use cases, you would have to repeat the same logic over and over again. Business rules need to managed on their own terms. I like the idea of going from a particular use case step, to the decision(s) that step requires the business to make, to statements that enforce the result of the decisions made by business (business rules). -Richard - Original Message - From: "G H Smith" <[EMAIL PROTECTED]> To: "rose_forum" <[EMAIL PROTECTED]> Sent: Friday, August 16, 2002 4:29 AM Subject: RE: (ROSE) UML and Business Rules > > > > Hi all > > I'm just getting back up to speed again with current use case thinking > after spending some time at the other end of the project lifecycle and I am > reading this thread with interest. > > A few days ago, I read a article in "The Rational Edge" entitled "Ten Ways > Project Teams Misuse Use Cases" by Ellen Gottesdiener. Number six in the > misguided list is "Don't Be Concerned with Defining Business Rules" and is > all about putting the business rules at the heart of the use cases. It > seems a sensible place to put them to me. > > http://www.therationaledge.com/content/jun_02/t_misuseUseCases_eg.jsp > > > Graham > > -- > Graham Smith email: [EMAIL PROTECTED] > Principal Software Engineer phone: +44 (0)1245 275028 > Marconi Mobile (UK) Ltd > New Street, Chelmsford, Essex, CM1 1PL > > > * 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: > *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: *Body: unsubscribe rose_forum *
Re: RE: (ROSE) UML and Business Rules
After reading the opinions to date it looks pretty much split down the middle. My take is that there are Business Rules and there are business rules. Business rules that determine your preconditions and postconditions for a use case should be entered into your use case. Business rules that are described by an OCL like notation should not go into your use cases, because you have not defined the attributes upon which the business rules operate yet. So why not both? Put a general description of the business rule in your use case, Precondition: The account must have a balance greater than the sum being withdrawn in order for this use case to occur. Clarify this with the OCL example, (that I am not goint to try and repeat because I have deleted the replies that pointed out all of the many mistakes that I made) in your Analysis model. You might even like to add traceability back to the use case. Les. > Hi all > > I'm just getting back up to speed again with current use case thinking > after spending some time at the other end of the project lifecycle and I am > reading this thread with interest. > > A few days ago, I read a article in "The Rational Edge" entitled "Ten Ways > Project Teams Misuse Use Cases" by Ellen Gottesdiener. Number six in the > misguided list is "Don't Be Concerned with Defining Business Rules" and is > all about putting the business rules at the heart of the use cases. It > seems a sensible place to put them to me. > > http://www.therationaledge.com/content/jun_02/t_misuseUseCases_e g.jsp > > > Graham > > -- > Graham Smith email: [EMAIL PROTECTED] > Principal Software Engineer phone: +44 (0)1245 275028 > Marconi Mobile (UK) Ltd > New Street, Chelmsford, Essex, CM1 1PL > > > * 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: > *Body: unsubscribe rose_forum > * > > > Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag * 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: *Body: unsubscribe rose_forum *
RE: (ROSE) UML and Business Rules
Hi all I'm just getting back up to speed again with current use case thinking after spending some time at the other end of the project lifecycle and I am reading this thread with interest. A few days ago, I read a article in "The Rational Edge" entitled "Ten Ways Project Teams Misuse Use Cases" by Ellen Gottesdiener. Number six in the misguided list is "Don't Be Concerned with Defining Business Rules" and is all about putting the business rules at the heart of the use cases. It seems a sensible place to put them to me. http://www.therationaledge.com/content/jun_02/t_misuseUseCases_eg.jsp Graham -- Graham Smith email: [EMAIL PROTECTED] Principal Software Engineer phone: +44 (0)1245 275028 Marconi Mobile (UK) Ltd New Street, Chelmsford, Essex, CM1 1PL * 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: *Body: unsubscribe rose_forum *
RE: (ROSE) UML and Business Rules
Eric, I think I may have under emphasised the main point here. All I am saying is when cutting the code the developer should rely on the results of the design not the use case. Therefore the developer has no need to see the use case. Regards Stephen Baynes -Original Message- From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]] Sent: 16 August 2002 04:58 To: ROSE_FORUM Subject: Re: (ROSE) UML and Business Rules > Romauld, one thing I would not expect is for the developers to read > the use case. This is for the analysts, designers and architects. I > accept most people will be multi skilled but I would not expect > someone in their developer role to ever need to see a use case (doesn't > mean they can't see them just they should not have a need to see them). > > Regards > Stephen Baynes Most developers get a huge boost from being able to see the larger picture. I would definitely make sure that my implementers know the use cases that they are realizing. -Eric * 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: *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: *Body: unsubscribe rose_forum *
Re: (ROSE) UML and Business Rules
> Romauld, one thing I would not expect is for the developers to read > the use case. This is for the analysts, designers and architects. I > accept most people will be multi skilled but I would not expect > someone in their developer role to ever need to see a use case (doesn't > mean they can't see them just they should not have a need to see them). > > Regards > Stephen Baynes Most developers get a huge boost from being able to see the larger picture. I would definitely make sure that my implementers know the use cases that they are realizing. -Eric * 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: *Body: unsubscribe rose_forum *
Re:(ROSE) UML and Business Rules
This is a topic that will probably be expanding in the near future. Take a look at a thread named "Business Rules vs. Use Case Name" on the RUP forum (accessible via the page in Rational listing newsgroups). I forget if it is in the June or July archive. There is interesting and related stuff there. Also there is a rumor that there will be a announcement from Knowledge Partners (Barbara von Halle) and Rational the first Monday of the Rational User Conference related to the integration of the Business Rules Approach with RUP. * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * * 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: *Body: unsubscribe rose_forum *
Re: (ROSE) UML and Business Rules
Hi David, <<1. What is the best CASE tool for Business Modeling?>> What aspects of the business are being modeling and why? Who will assume ownership over the business model - business or IT? <<2. What would be possible problems/risks with the choice of Rose by Rational as a tool for Business Modeling?>> I'm sure most agree that Rose by itself is not sufficient. For example, a glossary of terms specific to the business is one of the most important artifacts of any business analysis effort. ReqPro rather than Rose fits the bill when it comes to handling text-related aspects of the business analysis. Its ability to trace one thing to another is especially important. So from a Rational-only perspective Analyst Studio provides a more rounded solution than Rose does on its own for business modeling. However before discussion of business modeling tools can really proceed, the approach taken to modeling business must be carefully considered. Object-orientation is great, but business rules need to be modeled and managed separately. This paves the way for many of the rules to be executed by a rules engine (program code generated from the rule specifications). Here's an example of what I mean: http://www.corticon.com/html/so_platform.html In a nutshell, business analysts can use tools to help them enter well-formed rules into a repository. The automation here has to do with the formation of rule statements, ensuring consistency between rules, tracing and so on. This is the automation of rule specification activities in other words. Business naturally owns this model, since it is expressed in terms they already understand. IT owns the models that handle the implementation of the rules, be they object-models, relational database designs etc. Regards, -Richard - Original Message - From: "Lyalin, David S." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "'Baynes, Steve'" <[EMAIL PROTECTED]>; "'Bennett Simon'" <[EMAIL PROTECTED]>; "'Richard Howlett'" <[EMAIL PROTECTED]>; "'Les Munday'" <[EMAIL PROTECTED]>; "'Eric D. Tarkington'" <[EMAIL PROTECTED]>; "'eleadsolutions'" <[EMAIL PROTECTED]>; "'Romuald Restout'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "'Charles Edwards'" <[EMAIL PROTECTED]> Sent: Thursday, August 15, 2002 9:28 AM Subject: RE: (ROSE) UML and Business Rules > > I am re-submitting another posting that did not show up on the forum. Thank > you. > > -Original Message- > From: Lyalin, David S. > Sent: Friday, August 09, 2002 10:10 AM > To: '[EMAIL PROTECTED]' > Cc: Lyalin, David S. > Subject: Business Modeling with Rational Rose > > > These are some points from the recent discussion with my clients regarding > CASE tools for Business Modeling. > > 1. What is the best CASE tool for Business Modeling? > The brief version of my answer - today it is Rose by Rational Corp. because: > a) Tool is established well in a modeling community and it has largest > market share. Good chance that the company will be around for a "reasonable" > time length. > b) Same tool can be used for software development and for business modeling > c) Rose is UML-oriented and, again, the same standard could be use > throughout the software development and business modeling > > 2. What would be possible problems/risks with the choice of Rose by Rational > as a tool for Business Modeling? > My impression is: > a) Rational has no defined strategy on the subject: it does not look like > Rational Corp. positioning its Rose modeling tool for Business Modeling. All > public statements from Rational regarding Business Modeling are very vague. > > b) Major efforts with Rose development are directed towards enhancing > design-related and code generation tasks at the expense of analysis-related > tasks. On practice it means that product lacks features that are important > for Business Modeling (as example, obvious deficiencies with the visual > aspects of diagrams). > > Still, it would be logical to use Rose for the Business Modeling today - for > reasons stated in section 1. The concern is that without defined strategy > and focused efforts from Rational, role of the Rose as a Business Modeling > tool could diminish dramatically. > > Your comments and opinions would be appreciated. > > 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] >
RE: RE: (ROSE) UML and Business Rules
OCL is suitable for programmers. I agree with Richard that OCL would not be the best way to communicate with business-oriented (non-technical) people. RUP "Guidelines: Business Rules" states that "...this (OCL) formal type of language may be difficult to interpret for many of your stakeholders, so a more natural language style may be preferable". This is a very realistic and practical statement! David Lyalin -Original Message- From: Richard Howlett [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 8:56 PM To: [EMAIL PROTECTED] Subject: Re: RE: (ROSE) UML and Business Rules Hi Les, <> 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 i
RE: (ROSE) UML and Business Rules
I am re-submitting another posting that did not show up on the forum. Thank you. -Original Message- From: Lyalin, David S. Sent: Friday, August 09, 2002 10:10 AM To: '[EMAIL PROTECTED]' Cc: Lyalin, David S. Subject: Business Modeling with Rational Rose These are some points from the recent discussion with my clients regarding CASE tools for Business Modeling. 1. What is the best CASE tool for Business Modeling? The brief version of my answer - today it is Rose by Rational Corp. because: a) Tool is established well in a modeling community and it has largest market share. Good chance that the company will be around for a "reasonable" time length. b) Same tool can be used for software development and for business modeling c) Rose is UML-oriented and, again, the same standard could be use throughout the software development and business modeling 2. What would be possible problems/risks with the choice of Rose by Rational as a tool for Business Modeling? My impression is: a) Rational has no defined strategy on the subject: it does not look like Rational Corp. positioning its Rose modeling tool for Business Modeling. All public statements from Rational regarding Business Modeling are very vague. b) Major efforts with Rose development are directed towards enhancing design-related and code generation tasks at the expense of analysis-related tasks. On practice it means that product lacks features that are important for Business Modeling (as example, obvious deficiencies with the visual aspects of diagrams). Still, it would be logical to use Rose for the Business Modeling today - for reasons stated in section 1. The concern is that without defined strategy and focused efforts from Rational, role of the Rose as a Business Modeling tool could diminish dramatically. Your comments and opinions would be appreciated. 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: *Body: unsubscribe rose_forum *
RE: RE: (ROSE) UML and Business Rules
Title: RE: RE: (ROSE) UML and Business Rules Alternatively post condition self.balance+self.Overdraft-self.withdrawal <=0 -Original Message-From: Bennett Simon [mailto:[EMAIL PROTECTED]]Sent: 15 August 2002 10:53To: [EMAIL PROTECTED]; 'Les Munday'Subject: RE: RE: (ROSE) UML and Business Rules Hi Les I think you've got a couple of things mixed up in your OCL. (I've made similar mistakes myself.) You can set an invariant that will apply to instances of a class at all times: context BankAccount inv: self.balance >= 0 or you can set pre and postconditions on an operation: context BankAccount::withdraw_money(amount : Money) pre: balance >= 0 post: balance - amount >= 0 Incidentally, after the operation has been completed, then the value of balance will be the one after amount has been withdrawn from it, so you don't need to say post: balance - amount >= 0 just post: balance >= 0 so I'd be tempted to put the constraint in the pre-condition pre: balance - amount >= 0 i.e. you can't withdraw the money if you haven't got that much in the account, though that seems to be pre-judging the result of the operation and I'm not sure it's quite right. You can reference the value before the operation using the '@pre' operator, e.g. balance@pre in the post-condition refers to the balance at the start of the operation. This enables you to compare before and after values within the same OCL post-condition. Steve Baynes raises an interesting point about inheritance. If you are going to override a constraint in a subclass, you need to name it so that it is possible to tell that the constraint on the subclass is intended to override the constraint on the superclass and is not an addtional constraint. context BankAccount inv withdrawalLimit: self.balance >= 0 context BankAccount::withdraw_money(amount : Money) pre beforeWithdrawalOK: balance - amount >= 0 post afterWithdrawalOK: balance >= 0 can be overridden by: context BankAccount inv withdrawalLimit: self.balance >= overdraftLimit context BankAccount::withdraw_money(amount : Money) pre beforeWithdrawalOK: balance - amount >= overdraftLimit post afterWithdrawalOK: balance >= overdraftLimit Personally, I would associate OCL rules with whatever they apply to. Initially, this constraint might apply to the use case 'Customer withdraws money from account', but later we might recognise that the constraint is either an invariant of the BankAccount class or a pre- or post-condition on the withdraw_money(amount : Money) operation. For system and user acceptance testing purposes, it's useful to know that it applies to the use case, for unit testing, it's useful to know that it applies to the class or operation. There may be other constraints on the use case that are the responsibilities of other classes or operations. Simon - Simon Bennett, Systems Architect, GEHE AG Ext. 2406, (+44)(0)24 7643 2600 (Switchboard), (+44)(0)24 7643 2406 (Direct) > -Original Message- > From: Les Munday [mailto:[EMAIL PROTECTED]] > Sent: 14 August 2002 22:08 > To: [EMAIL PROTECTED] > Subject: Re: RE: (ROSE) UML and Business Rules > ... > > 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. DISCLAIMER The information contained in this e-mail is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply e-mail and then delete it from your system. Please do not copy it or use it for any other purposes, or disclose the content of the e-mail to any other person or store or copy the information in any medium. The views contained in this e-mail are those of the author and not necessarily those of GEHE Group companies.
RE: RE: (ROSE) UML and Business Rules
Title: RE: RE: (ROSE) UML and Business Rules Hi Les I think you've got a couple of things mixed up in your OCL. (I've made similar mistakes myself.) You can set an invariant that will apply to instances of a class at all times: context BankAccount inv: self.balance >= 0 or you can set pre and postconditions on an operation: context BankAccount::withdraw_money(amount : Money) pre: balance >= 0 post: balance - amount >= 0 Incidentally, after the operation has been completed, then the value of balance will be the one after amount has been withdrawn from it, so you don't need to say post: balance - amount >= 0 just post: balance >= 0 so I'd be tempted to put the constraint in the pre-condition pre: balance - amount >= 0 i.e. you can't withdraw the money if you haven't got that much in the account, though that seems to be pre-judging the result of the operation and I'm not sure it's quite right. You can reference the value before the operation using the '@pre' operator, e.g. balance@pre in the post-condition refers to the balance at the start of the operation. This enables you to compare before and after values within the same OCL post-condition. Steve Baynes raises an interesting point about inheritance. If you are going to override a constraint in a subclass, you need to name it so that it is possible to tell that the constraint on the subclass is intended to override the constraint on the superclass and is not an addtional constraint. context BankAccount inv withdrawalLimit: self.balance >= 0 context BankAccount::withdraw_money(amount : Money) pre beforeWithdrawalOK: balance - amount >= 0 post afterWithdrawalOK: balance >= 0 can be overridden by: context BankAccount inv withdrawalLimit: self.balance >= overdraftLimit context BankAccount::withdraw_money(amount : Money) pre beforeWithdrawalOK: balance - amount >= overdraftLimit post afterWithdrawalOK: balance >= overdraftLimit Personally, I would associate OCL rules with whatever they apply to. Initially, this constraint might apply to the use case 'Customer withdraws money from account', but later we might recognise that the constraint is either an invariant of the BankAccount class or a pre- or post-condition on the withdraw_money(amount : Money) operation. For system and user acceptance testing purposes, it's useful to know that it applies to the use case, for unit testing, it's useful to know that it applies to the class or operation. There may be other constraints on the use case that are the responsibilities of other classes or operations. Simon - Simon Bennett, Systems Architect, GEHE AG Ext. 2406, (+44)(0)24 7643 2600 (Switchboard), (+44)(0)24 7643 2406 (Direct) > -Original Message- > From: Les Munday [mailto:[EMAIL PROTECTED]] > Sent: 14 August 2002 22:08 > To: [EMAIL PROTECTED] > Subject: Re: RE: (ROSE) UML and Business Rules > ... > > 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. DISCLAIMER The information contained in this e-mail is confidential and is intended for the recipient only. If you have received it in error, please notify us immediately by reply e-mail and then delete it from your system. Please do not copy it or use it for any other purposes, or disclose the content of the e-mail to any other person or store or copy the information in any medium. The views contained in this e-mail are those of the author and not necessarily those of GEHE Group companies.
RE: RE: (ROSE) UML and Business Rules
Les, I would certainly put this in a use case. This is why the use case template has pre and post conditions. Pre condition for this use case the customers balance must be greater than or equal to 0 Post condition the customers balance must be greater than or equal to 0 This can then be extended by the use of overdrafts etc... This I can give to the customer with some expectation that they will understand it. Once the customer has accepted the business rule then I will model using OCL exactly as you have done. Regards Stephen Baynes -Original Message- From: Les Munday [mailto:[EMAIL PROTECTED]] Sent: 14 August 2002 22:08 To: [EMAIL PROTECTED] 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" > > , > "'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
Re: RE: (ROSE) UML and Business Rules
Hi Les, <> 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: >
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" > > , > "'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 th
Re: 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. > Can't disagree with the interpretation of business rules, but a little clarification of the above might help. What is an analysis model? It is a model of the requirements. Therefore it IS the requirements. An analysis model contains classes, states, activities, events even sequence diagrams if that's your prefrence. So why is this not an excellent place to put your business rules? Les. > -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: > > *Body: unsubscribe rose_forum > > > > * > > > > > > > > > > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag > > * 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: > *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: > *Body: unsubscribe rose_forum > * > > > Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag * 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: *Body: unsubscribe rose_forum *
RE: (ROSE) UML and Business Rules
I am glad that my original posting generated an interesting discussion. Eric pointed to the key issues regarding industry standards, techniques, and tools for the business rules. Two schools of thought relate to business rules: 1. UML/RUP - a good reference source would be "Guidelines: Business Rules" section of RUP 2. Business Rules community, like: http://www.businessrulesgroup.org/brghome.htm http://www.businessrulesforum.com/ http://www.brsolutions.com/index.shtml It looks like these two approaches exist in different worlds. The question is - could UML-based business model be complemented and benefit from the second approach? Thank you. David Lyalin -Original Message- From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 12:40 PM To: [EMAIL PROTECTED] Subject: Re: (ROSE) UML and Business Rules I'm still looking for industry standards that enable us to decide issues like this. Which tools do we use to model business rules? What are business rules? Does the BOM (Business Object Model) *explicitly* capture all the business rules? Is there one BOM for the system, or one BOM per business area (for example: sales, accounting, warehousing) within the system? Responding to Steven Baynes: The need for a thing is not the same as the thing. A use case may capture requirements that motivate the creation of business rules, without stating the rules, themselves. What are business rules, exactly? The matter is unsettled. Responding to Les Munday (And how could I resist?): I find it surprising that you visualize business rules being about "attributes and relationships between attribut[e]s", and that you see them as flexible. Surely business rules must be in the domain of business activity, which is a set of mandatory and banned behaviour in a particular instance of a business. This looks to me like the right material for use cases. The point about flexibility is a good warning. The client wants flexibility when he has not clearly visualized the system. He may not want to clearly visualize the system. Your mission, if you choose to accept it, is to implement the fuzzy system that the client vaguely visualizes. It is impossible (or at least, highly unlikely), and you should not accept. -Eric "Baynes, Steve" wrote: > > 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: *Body: unsubscribe rose_forum * **
RE: (ROSE) UML and Business Rules
Stephen, 1) There was no "guesswork" involved. The exception was documented in that manner, as a result of working with the customers in eliciting the requirements of the system. If some of the rules that I had related to the generic exception were not handled by the described behavior, then that would have been a requirements error. That would have been caught during reviews (knock on wood) with the customers, and addressed through correcting the traceability, or actually describing it as its own exception in the use case. (Remember, I am not saying you can't, only don't hinder the readability of the use case) 2)As far as communicating business rules, I generated views of the rules and reviewed them with the customer along with the use cases. 3) The use case is not the only artifact for communicating with the customer. There are prototypes, non functional requirements, scope documents, test plans, etc. Of course, the requirements contained in the documents relate to 1 or more use cases. 4) If you are not using a tool, then either I would document the rules as a section within a use case, or could have a standalone document of rules, and have references made by them in the use case text. Whatever works. Please consider purchasing a tool like req pro. I am currently involved on a project that uses a document only approach, and the management of the requirements has been a challenge, as well as other problems, that could be eliminated through the use of a tool. 5) You also had a question about the capturing of rules outside the use case mechanism in Req Pro. I don't know if this will answer it, but all I did was to simply use a separate requirement type of BR, and assign specific attributes that would apply to rules. For example, one of the characteristics of the project was a gas transportation system that was deployed on different pipelines. The pipelines had rule differences, so I used an attribute of "Pipeline" or "Applies To" (can't remember specifically) and assigned the appropriate value. Hope this helps, Jim >= Original Message From "Baynes, Steve" <[EMAIL PROTECTED]> = >Jim, in my opinion I think you have just described a very good case of an >include use case. > >I see a number of issues here in not making it a use case. >1. you have "guessed" that the actions are the same every time (this does >not mean you are wrong but it does imply an understanding of the business >and the solution). Nothing wrong with this approach but it is surprising >how many exceptions to the business rule occur. >2. the use case is the only artefact for communicating with the customer so >how so you communicate this business rule? > >I am very interesting in how you capturing business rules outside the use >case mechanism in requisite pro. > >Regards >Stephen Baynes > >-Original Message----- >From: eleadsolutions [mailto:[EMAIL PROTECTED]] >Sent: 14 August 2002 15:49 >To: Baynes, Steve; rose_forum; Les Munday >Subject: RE: (ROSE) UML and Business Rules > > >Stephen, > >I disagree with your statement about business rules "must be captured in the > >use cases". What really needs to happen is that business rules must be >captured, but can be traced to use case flow of events, or exceptions, >instead >of documenting them directly in a use case document. > >I have worked on a project where I described generic exceptions, and related > >the business rules to it using Requisite Pro. For example, I had something >like "Invalid Contract" exception. There were many ways that you could have >an >invalid contract, but the system responded in the same manner to these >errors. > >(i.e., The system displays an error message, blah blah blah) The business >rules that triggered this exception were either entered as database only >rules, or were described in legacy documentation. Rather than >duplicate/reenter this information, I imported the legacy document into RP, >tagged the appropriate text as a business rule, and related it to the >appropriate exception or flow of events. > >I am not saying that you can't document rules in the use case. But remember, > >one of the key benefits of applying use cases on a project, is that they are > >great way to communicate the behavioral requirements of a system. We should >not hinder this by exceptions which are so bloated because we have >documented >every rule in it. > >Hope this helps, >Jim McAllister >eLead Solutions, Inc. >cell#: 713-582-5725 >email [EMAIL PROTECTED] > > > >>= Original Message From "Baynes, Steve" <[EMAIL PROTECTED]> = >>All, The need for business rules must be captured in the use cases. Us
Re: (ROSE) UML and Business Rules
I'm still looking for industry standards that enable us to decide issues like this. Which tools do we use to model business rules? What are business rules? Does the BOM (Business Object Model) *explicitly* capture all the business rules? Is there one BOM for the system, or one BOM per business area (for example: sales, accounting, warehousing) within the system? Responding to Steven Baynes: The need for a thing is not the same as the thing. A use case may capture requirements that motivate the creation of business rules, without stating the rules, themselves. What are business rules, exactly? The matter is unsettled. Responding to Les Munday (And how could I resist?): I find it surprising that you visualize business rules being about "attributes and relationships between attribut[e]s", and that you see them as flexible. Surely business rules must be in the domain of business activity, which is a set of mandatory and banned behaviour in a particular instance of a business. This looks to me like the right material for use cases. The point about flexibility is a good warning. The client wants flexibility when he has not clearly visualized the system. He may not want to clearly visualize the system. Your mission, if you choose to accept it, is to implement the fuzzy system that the client vaguely visualizes. It is impossible (or at least, highly unlikely), and you should not accept. -Eric "Baynes, Steve" wrote: > > 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: *Body: unsubscribe rose_forum *
RE: (ROSE) UML and Business Rules
Title: RE: (ROSE) UML and Business Rules Romauld, can you elaborate why business rules for password validity or rules regarding name unicity are better captured using the object model? I accept they will be modelled in the object model, but the requirement must be captured using the use case. Regards Stephen Baynes -Original Message-From: Romuald Restout [mailto:[EMAIL PROTECTED]]Sent: 14 August 2002 15:57To: 'Baynes, Steve'; Les Munday; '[EMAIL PROTECTED]'Subject: RE: (ROSE) UML and Business Rules Hi all, I personally think you are both (Steve and Les) right and wrong at the same time. Some business rules apply to attributes and relationships between those attributes as state Les. For instance business rules for password validity or rules regarding name unicity. In this case, these rules are best captured and documented within an object model. However there are some other rules that are not related to business objects. For instance, how you determine that an individual is eligible for a loan, or what is the next expected action in a business workflow depending on an operational context. These business rules are best captured within use-cases. My $0.02 Romuald Restout Software Architect, Recruitsoft P: 418.524.5665, x 232 E: [EMAIL PROTECTED] W: http://www.recruitsoft.com/ -Original Message- From: Baynes, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 5:15 AM 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: > * Body: unsubscribe rose_forum > * > > > Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag * 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: * Body: unsubscribe rose_forum * *
RE: (ROSE) UML and Business Rules
Jim, in my opinion I think you have just described a very good case of an include use case. I see a number of issues here in not making it a use case. 1. you have "guessed" that the actions are the same every time (this does not mean you are wrong but it does imply an understanding of the business and the solution). Nothing wrong with this approach but it is surprising how many exceptions to the business rule occur. 2. the use case is the only artefact for communicating with the customer so how so you communicate this business rule? I am very interesting in how you capturing business rules outside the use case mechanism in requisite pro. Regards Stephen Baynes -Original Message- From: eleadsolutions [mailto:[EMAIL PROTECTED]] Sent: 14 August 2002 15:49 To: Baynes, Steve; rose_forum; Les Munday Subject: RE: (ROSE) UML and Business Rules Stephen, I disagree with your statement about business rules "must be captured in the use cases". What really needs to happen is that business rules must be captured, but can be traced to use case flow of events, or exceptions, instead of documenting them directly in a use case document. I have worked on a project where I described generic exceptions, and related the business rules to it using Requisite Pro. For example, I had something like "Invalid Contract" exception. There were many ways that you could have an invalid contract, but the system responded in the same manner to these errors. (i.e., The system displays an error message, blah blah blah) The business rules that triggered this exception were either entered as database only rules, or were described in legacy documentation. Rather than duplicate/reenter this information, I imported the legacy document into RP, tagged the appropriate text as a business rule, and related it to the appropriate exception or flow of events. I am not saying that you can't document rules in the use case. But remember, one of the key benefits of applying use cases on a project, is that they are great way to communicate the behavioral requirements of a system. We should not hinder this by exceptions which are so bloated because we have documented every rule in it. Hope this helps, Jim McAllister eLead Solutions, Inc. cell#: 713-582-5725 email [EMAIL PROTECTED] >= Original Message From "Baynes, Steve" <[EMAIL PROTECTED]> = >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
RE: (ROSE) UML and Business Rules
Title: RE: (ROSE) UML and Business Rules Hi all, I personally think you are both (Steve and Les) right and wrong at the same time. Some business rules apply to attributes and relationships between those attributes as state Les. For instance business rules for password validity or rules regarding name unicity. In this case, these rules are best captured and documented within an object model. However there are some other rules that are not related to business objects. For instance, how you determine that an individual is eligible for a loan, or what is the next expected action in a business workflow depending on an operational context. These business rules are best captured within use-cases. My $0.02 Romuald Restout Software Architect, Recruitsoft P: 418.524.5665, x 232 E: [EMAIL PROTECTED] W: http://www.recruitsoft.com/ -Original Message- From: Baynes, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 5:15 AM 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: > * Body: unsubscribe rose_forum > * > > > Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag * 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: * 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: * Body: unsubscribe rose_forum *
RE: (ROSE) UML and Business Rules
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" , "'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 discussion
RE: (ROSE) UML and Business Rules
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: | > *Body: unsubscribe rose_forum | > | | * | > | > | > | | | | Get your own "800" number | Voicemail, fax, email, and a lot more | http://www.ureach.com/reg/tag | | * 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: | *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: | *Body: unsubscribe rose_forum | * * Rose Forum is a public venue for ideas
RE: (ROSE) UML and Business Rules
Stephen, I disagree with your statement about business rules "must be captured in the use cases". What really needs to happen is that business rules must be captured, but can be traced to use case flow of events, or exceptions, instead of documenting them directly in a use case document. I have worked on a project where I described generic exceptions, and related the business rules to it using Requisite Pro. For example, I had something like "Invalid Contract" exception. There were many ways that you could have an invalid contract, but the system responded in the same manner to these errors. (i.e., The system displays an error message, blah blah blah) The business rules that triggered this exception were either entered as database only rules, or were described in legacy documentation. Rather than duplicate/reenter this information, I imported the legacy document into RP, tagged the appropriate text as a business rule, and related it to the appropriate exception or flow of events. I am not saying that you can't document rules in the use case. But remember, one of the key benefits of applying use cases on a project, is that they are great way to communicate the behavioral requirements of a system. We should not hinder this by exceptions which are so bloated because we have documented every rule in it. Hope this helps, Jim McAllister eLead Solutions, Inc. cell#: 713-582-5725 email [EMAIL PROTECTED] >= Original Message From "Baynes, Steve" <[EMAIL PROTECTED]> = >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: >> *Body: unsubscribe rose_forum >> > >* >> >> >> > > > >Get your own "800" number >Voicemail, fax, email, and a lot more >http://www.ureach.com/reg/tag > >* 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]
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: > *Body: unsubscribe rose_forum > * > > > Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag * 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: *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: *Body: unsubscribe rose_forum *
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: > *Body: unsubscribe rose_forum > * > > > Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag * 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: *Body: unsubscribe rose_forum *