RE: (ROSE) UML and Business Rules

2002-08-27 Thread Richard Brand
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

2002-08-27 Thread Baynes, Steve


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

2002-08-26 Thread Richard Brand
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

2002-08-26 Thread Baker, Bryon


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

2002-08-26 Thread Lyalin, David S.


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

2002-08-26 Thread Baker, Bryon


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

2002-08-17 Thread Richard Howlett


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

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: (ROSE) UML and Business Rules

2002-08-16 Thread G H Smith




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

2002-08-16 Thread Baynes, Steve


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

2002-08-15 Thread Eric D. Tarkington


> 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

2002-08-15 Thread Alan . Yezierski


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

2002-08-15 Thread Richard Howlett


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

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: (ROSE) UML and Business Rules

2002-08-15 Thread Lyalin, David S.


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

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 th

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
*




RE: (ROSE) UML and Business Rules

2002-08-14 Thread Lyalin, David S.


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

2002-08-14 Thread eleadsolutions


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

2002-08-14 Thread Eric D. Tarkington


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

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

2002-08-14 Thread Baynes, Steve


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

2002-08-14 Thread Romuald Restout
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

2002-08-14 Thread WHoward



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

2002-08-14 Thread Charles Edwards


On a recent project we found it useful to capture the business rules
separately (I like the idea of attaching them to the Business Object
Model - as per Les) one reason for this is that sometimes many use cases
could refer to one business rule or you end up cluttering up the use
cases with many business rules and they detract form the essence of the
Use Case.

However we found it was good to uniquely name them and link the name
references to the actual business rules.

Regards

Charles Edwards

www.elearningwave.com  - elearning site
www.processwave.net  - Information Portal


| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
| On Behalf Of Baynes, Steve
| Sent: 14 August 2002 10:15
| To: Les Munday; '[EMAIL PROTECTED]'
| Subject: RE: (ROSE) UML and Business Rules
| 
| 
| All, The need for business rules must be captured in the use cases.
Use
| cases are the requirements documents.  The implementation of the
business
| rules will flow throughout the rest of the analysis, design,
| implementation
| and testing.
| 
| Business rules may be driven by object state transition, the
| inter-relationship between objects etc.  This means no single
artefact,
| other than use cases, can capture the need for these rules.
| 
| This is all "in my opinion".   I look forward to some different
views...
| 
| Regards
| Stephen Baynes
| 
| -Original Message-
| From: Les Munday [mailto:[EMAIL PROTECTED]]
| Sent: 13 August 2002 22:24
| To: '[EMAIL PROTECTED]'
| Subject: Re: (ROSE) UML and Business Rules
| 
| 
| 
| Since I think of business rules as generally applying to
| attributes and relationships between attributs, and since we
| don't reference attributes within use cases, I would not
| recommend stating business rules in use cases.
| 
| I also think of business rules as being flexible, much more so
| than I want my use cases to be.
| 
| So my expectation would be to see business rules described by a
| business object model. I think that they attach quite nicely to
| the attributes and relationships in the class diagram.
| 
| Much better place than use cases, IMO.
| 
| Les.
| 
| >
| > UML and Business Rules - are these two things complementary?
| > Some people believe that when you use UML/Use Cases you don't
| need
| > business rules techniques to capture business policies,
| regulations,
| > restrictions, etc.
| > - since it got captured in use cases anyway.
| > Other people think that UML is not sufficient for these
| purposes.
| >
| > What is your approach to this?
| >
| > Thank you.
| >
| > David Lyalin
| >
| 
| 
| > * Rose Forum is a public venue for ideas and discussions.
| > * For technical support, visit http://www.rational.com/support
| > *
| > * Post or Reply to: [EMAIL PROTECTED]
| > * Subscription Requests: [EMAIL PROTECTED]
| > * Archive of messages:
| > *
| http://www.rational.com/support/usergroups/rose/rose_forum.jsp
| > * Other Requests: [EMAIL PROTECTED]
| > *
| > * To unsubscribe from the list, please send email
| > *To: [EMAIL PROTECTED]
| > *Subject: 
| > *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

2002-08-14 Thread eleadsolutions


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

2002-08-14 Thread Baynes, Steve


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

2002-08-13 Thread Les Munday


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
*