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 >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/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum ************************************************************************* ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
