Dear all, I have started looking at the latest OCL submission. A lot of work has obviously been done, but it seems it is still not possible to write the most basic of all constraints, e.g.
context Person inv: wife <> null and context Person inv: wife <> null implies wife.gender = Gender::female Instead one is forced to write: context Person inv: wife->notEmpty() implies wife.gender = Gender::female which is not only counter-intuitive (Person.wife is not defined as a Set of anything, it is defined as a Person), but seems wrong because there is no formal connection between whatever Set the expression "wife->" refers to and the underlying model, so how can one say anything about what the membership of this set might imply for the value of the Person at the other end of the wife association? I think that the real problem is that UML sees associations as somehow different from attributes, when there is no difference - except graphically. I still cannot see how a Set<Person> can be called a "convenient" cast of Person - what language allows this? have I misread the submission? - thomas beale Pete Rivett wrote: >Hi Thomas, >I appreciate the trouble you've taken to evaluate OCL, and think several >of the issues are worthy of consideration. >Just for your information, and for others on this list, the latest >version of the OCL 2.0 submission is 1.6 (as opposed to 1.0 you reviewed >which is 2.5 years old!). This is due to be adopted later today, as it >happens. >Despite the imminent adoption it is still possible to submit issues to >OMG's Finalization Task Force which is responsible for considering >implementation and other issues prior to the standard becoming >officially 'Finalized' and 'Available'. To do this just send an email to >issues at omg.org, or fill in the form at the OMG web site >http://www.omg.org/technology/issuesform.htm. > >In general OMG attempts to be an open and responsive organization and >anyone (not only members) can raise issues against any OMG >specification. Though OMG can only address issues if it know about them >- so I would sincerely encourage people to use the mechanisms available. > >However, while I must admit a bias as one of the submitters of OCL 2.0, >I would disagree that the semantics are 'quite broken'. I assume the >following from the review is intended to illustrate 'broken semantics': >---> >In section 2.5.4, subsection "Navigation over Associations with >Multiplicity Zero or One" it is stated that "...a single object can be >used as a set as well. It then behaves as if it is a Set containing the >single object...". I had to read this a few times to believe it. While >there is clearly a drive to make everything somehow the same for the >purpose of querying, there is no way a formal type system can be >respected if such liberties are taken - the basis of correct >specifications disappears. There is no way, for example, that >PERSON.manager: PERSON can act as a Set<> if has been specified as a >PERSON - these are two distinct types, and have nothing to do with each >other. " ><--- > >I view treating a single object as a set as a convenient implicit 'cast' >operation. Most programming languages have such a thing: e.g. to allow >an Integer to be treated as a Real. And if really concerned about the >difference OCL has capabilities to distinguish an object from a set. > >Finally, with regard to implementability, there are several >implementations of OCL in existence (currently of OCL 1, though OCL 2 >does not introduce any radically new capabilities). These exist in both >commercial products (e.g. BoldSoft, now part of Borland) and >university/research projects (e.g. Kent Modelling Framework - >www.cs.ukc.ac.uk/kmf). > > >Regards >Pete > >Pete Rivett (pete.rivett at adaptive.com) >Consulting Architect, Adaptive Inc. >Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK >Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 >http://www.adaptive.com > > > > > > >>-----Original Message----- >>From: Thomas Beale [mailto:thomas at deepthought.com.au] >>Sent: 24 March 2003 20:42 >>To: Tom Culpepper >>Cc: dhlong at vietkey.net; openehr-technical at openehr.org; >>healthcare at omg.org >>Subject: Re: Introducing myself + question >> >> >> >> >>Tom Culpepper wrote: >> >> >> >>>I again would like to reiterate may opinion on this list concerning >>>the modeling of Healthcare. >>> >>>The business of Healthcare (both Clinical and >>> >>> >>Administrative) needs to >> >> >>>be modeled in a language, platform and operating system independent >>>manner. This will provide the opportunity for folks to provide >>>implementations that can be used across the widest spectrum while >>>leveraging legacy systems. One such universal modeling >>> >>> >>language is UML >> >> >>>(Unified Modeling Language) and the "OPEN" technology that >>> >>> >>is making >> >> >>>this a reality comes from the Object Management Group (www.omg.com >>><http://www.omg.com/>) MDA (Model Driven Architecture). >>> >>> >>well as you'll see in the specs there is no >>language-dependent stuff - >>it's all UML. The only slight problem at the moment is that >>OCL has some >>quite broken semantics which would prevent it being used properly for >>the constraints, but even then maybe we just have to go with >>it. In the >>specs currently, the constraints are expressed in a first order >>predicate form very similar to OCL. We'll have to fix tis eventually, >>but as almost no-one except Eiffel people can implement the >>statements >>directly anyway, it doesn't seem a big concern... >> >> >> >>>Making a decision to develop models that force people to use C, C++, >>>Java, Effiel, Microsoft NT, Unix, MVS, or proprietary >>> >>> >>mechanisms will >> >> >>>only hamper IT efforts for interoperable solutions. >>> >>> >>right. I don't know why we get into these discussions really - the >>specifications are competely language independent (I'd have >>to say even >>moreso than OMG actually - IDL is actually quite C++/C oriented, but >>that's history - let's not waste our breath on it now!) >> >> >> >>>I also concur with David Forsland in the use of the Object >>> >>> >>Constraint >> >> >>>Language. >>> >>> >>Tom, I'm interested in what you think about the review I have >>done. See >>http://www.deepthought.com.au/it/ocl_review.html. >> >>- thomas beale >> >> >> >> >> > >The information contained in this email and any attached files is confidential >and intended solely for the addressee(s). The e-mail may be legally privileged >or prohibited from disclosure and unauthorised use. > >If you are not the named addressee you may not use, copy or disclose this >information to any other person. If you received this message in error please >notify the sender immediately. > >Any views or opinions presented here may be solely those of the originator and >do not necessarily reflect those of the Company. > > > > -- .............................................................. Deep Thought Informatics Pty Ltd mailto:thomas at deepthought.com.au openEHR - http://www.openEHR.org Archetypes - http://www.deepthought.com.au/it/archetypes.html Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html .............................................................. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030329/24b1b266/attachment.html>
