Thanks for the response Pete, Pete Rivett wrote:
>You should use "not(wife.oclIsUndefined())" as opposed to >"wife->notEmpty()". This avoids the problems you outline about treating >the value as a Set. > I still don't see how this would work: now there is an assumed method called oclIsUndefined() inherited into the the type that wife points to, i.e. Person. Either I am forced to start putting OCL overhead classes into the model I am trying to write - just to achieve what I think any normal modeller would expect in almost any formalism - or I have to throw away the assumption that OCL statements obey the types and signatures of the model they are annotating. I also don't see the semantic difference between the _intention_ of wife.oclIsUndefined() and wife <> null; but the former does have quite different concrete semantic implications. Here I will also re-iterate my other complaint - it is _such_ a pity not to use the principle of univform reference and write wife.oclIsUndefined without the brackets - this is not just syntactic sugar! >There was a conscious decision not to use null: this is a quote from a >response I had from the submission lead on the subject: > >"Null is not defined in the spec. You should test the value for = >Undefined. >We have not put both Null and Undefined in the spec, because that will >raise many discussions about different types of being void." > yes - well I appreciate this difficulty - language lawyers do tend ot go to town on these kind of issues. But... realisitically, I think that the OCL submitters just have to take a stand and go with it. I think the current stand is the wrong one, and I think it should be changed - and I hope you can at least see what some of the objections could be - it is not a matter of taste - there really are semantic problems waiting to come out if OCL goes this way (e.g. what really is the definition of the contents of one of these notional sets which can be substituted as the value of a 0..1 or 1..1 attribute?). I also do appreciate the overall difficulty of trying to write specifications such as this - I have been involved in some standards efforts myself, and I know very well that everyone wants something different. The requirements are always a minefield, and it is often the case that every single person on the authoring committee has to cave in on something even though they're right! But, this time, I am talking as a standard consumer, not a creator (thank god!) so I hope you feel it is reasonable for me to try and make the objections clear. One of the reasons I want to try and convince you to change this part of the semantics is because I think the rest of OCL is actually pretty good - there are not that many standards which are wonderful, but OCL could be.... I can even live with the "." and "->" business (and maybe even use it) if the "->" semantics do not step on the semantics of making more basic statements about static models. One question I now have in my mind, based on conversations with Grahame Grieve (Kestral, Australia), who is thinking of implementing OCL as a business rules language, is what the primary purpose of OCL really is. I have to admit I thought that OCL was really about being able to specify static constraints on models, i.e. class invariants, and routine pre- and post-conditions. I have been doing this for 10 years in Eiffel and on paper with first order predicate logic - it is very important. This has come to be called "Design by Contract" by people like B Meyer, Haim Kilov and Martin Fowler, and its importance is finally being recognised. However, Grahame has come to the conclusion that OCL is not really for that, but for business rules (feel free to state your POV Grahame!). Now, what I would call a "business rule" is something which fits the followinig profile: - is not true for all instances of a class at all times, therefore cannot be put into the semantic contract of a class at design/compile time - may be created and/or modified at runtime by a user - violation at runtime does not mean there is a software bug, it means that a business requirement / process rule or something else at the business level has been broken - usually business rules require special syntaxes. In my own experience, I have been involved in systems which both have static model correctness constraints - contracts - and business rules. For the latter, we wrote a language, used yaxx/lex tools to build the parser, built a GUI editor, and stored the rules and evaluated them at runtime. But when one of these rules broke, we didn't go looking for a bug in the software, we went to some person in the company who had done a trade outside the bounds defined by the rule for the fundholder.. None of the points above are to do with correctness of software, but on the contrary, with using software to determine whether processes in the running of some business are working correctly. So.... what is OCL for? Is it about static model (and hence software) correctness or is it about a language for writing runtime evaluable rules? (Note: static model constraints can be evaluated at runtime too - Eiffel tools do this very nicely, but again, the significance of a violation is quite different - it means there is a bug in the software). >However I can see that this is a decision we may wish to review as part >of the Finalization process and input from people such as yourselves. >Personally I think oclIsUndefined may be too broad. > >Note that those interested who are OMG members can sign themselves up to >the FTF mailing list without being official FTF members. The FTF will be >cartered in the June Paris meeting. > Currently I am not an OMG member, but the DSTC is, and I am pretty sure I can find people there who would represent the same point of view as myself, if it would help. Once again, thanks for taking the time to hear these comments. I don't know that the required changes would have to be that big to fix this - maybe the "wife->yourSetOperationHere()" stuff can still be legal, as long as "wife <> Null" (or wife /= Void, as we say in Eiffel;-) is made legal as well. Anyway, I will be very interested to see if there can be any movement on this - I think it would be a real improvement. regards, - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
