Re: RE: (ROSE) UML and Business Rules

2002-08-16 Thread Les Munday


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

2002-08-15 Thread Lyalin, David S.


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

2002-08-15 Thread Baynes, Steve
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

2002-08-15 Thread Bennett Simon
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

2002-08-15 Thread Baynes, Steve


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

2002-08-14 Thread Richard Howlett


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

2002-08-14 Thread Les Munday


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

2002-08-14 Thread Les Munday



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