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