-----Original Message-----
From: Bennett Simon [mailto:[EMAIL PROTECTED]]
Sent: 15 August 2002 10:53
To: [EMAIL PROTECTED]; 'Les Munday'
Subject: RE: RE: (ROSE) UML and Business RulesHi 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 >= 0or you can set pre and postconditions on an operation:
context BankAccount::withdraw_money(amount : Money)
pre: balance >= 0
post: balance - amount >= 0Incidentally, 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 >= 0context BankAccount::withdraw_money(amount : Money)
pre beforeWithdrawalOK: balance - amount >= 0
post afterWithdrawalOK: balance >= 0can be overridden by:
context BankAccount inv withdrawalLimit:
self.balance >= overdraftLimitcontext BankAccount::withdraw_money(amount : Money)
pre beforeWithdrawalOK: balance - amount >= overdraftLimit
post afterWithdrawalOK: balance >= overdraftLimitPersonally, 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. ************************************************************************
Title: RE: RE: (ROSE) UML and Business Rules
Alternatively
post
condition
self.balance+self.Overdraft-self.withdrawal
<=0
- RE: (ROSE) UML and Business Rules Romuald Restout
- RE: (ROSE) UML and Business Rules Baynes, Steve
- RE: (ROSE) UML and Business Rules Baynes, Steve
- RE: (ROSE) UML and Business Rules eleadsolutions
- RE: (ROSE) UML and Business Rules Lyalin, David S.
- Re: RE: (ROSE) UML and Business Rules Les Munday
- Re: RE: (ROSE) UML and Business Rules Les Munday
- Re: RE: (ROSE) UML and Business Rules Richard Howlett
- RE: RE: (ROSE) UML and Business Rules Baynes, Steve
- RE: RE: (ROSE) UML and Business Rules Bennett Simon
- FW: (ROSE) UML and Business Rules Baynes, Steve
- FW: (ROSE) UML and Business Rules Lyalin, David S.
- RE: (ROSE) UML and Business Rules Lyalin, David S.
- Re: (ROSE) UML and Business Rules Richard Howlett
- RE: RE: (ROSE) UML and Business Rules Lyalin, David S.
- Re:(ROSE) UML and Business Rules Alan . Yezierski
- Re: (ROSE) UML and Business Rules Eric D. Tarkington
- RE: (ROSE) UML and Business Rules Baynes, Steve
- RE: (ROSE) UML and Business Rules G H Smith
- Re: (ROSE) UML and Business Rules Richard Howlett
- Re: RE: (ROSE) UML and Business Rules Les Munday
