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