Re: OCL challenge



Date view Thread view Subject view Author view

Jos Warmer (J.Warmer@klasse.nl)
Wed, 20 Dec 2000 12:24:36 +0100


Hi Tony, here's the "Dutch team" tuning in (:-) At 10:56 AM 12/20/00 +0000, Tony Simons wrote: >Daniel, > >You're right in your supposition that, for some set-valued attribute >p of an object x, the expression: > > x.p.q > >is really OCL shorthand for: > > x.p->collect(p : P | p.q) > >although I would prefer to distinguish x.p the set from p the >iteration variable (I assume you rebind p in the iteration). That's right, I prefer to use a dufferent name for the iteration variable to avoid this kind of confusion. I would write: x.p->collect(i : P | i.q) >The fundamental flaw in OCL in my view is that by semantically >merging/confusing single-valued and set-valued access paths in >expressions like x.p.q, this causes the knock-on problem that you >cannot distinguish methods of elements from methods of sets. >OCL "fixed" this by introducing a spurious syntactic distinction >p->q to mean "the set's method" rather than p.q to mean "the result >of mapping q over every element of the set p". This is a syntactic >kludge to fix a more important semantic fault. You _can_ distinguish between single-values and set-valued access paths as you describe above. Disregarding the syntax, which you don't seem to like, they are semantically different. I do not see any inherent ambiguity in the way OCL handles this. If there is, please explain it to us. >I argued this case vociferously when OCL was being defined, and >talked to the Dutch team who wrote the book. The counter-argument >was that developers preferred the shorthand over having to use >explicit mapping and filtering methods. I still don't think that's >a good reason for kludgy semantics. A better example is Shipman's >DAPLEX language for defining OO databases. In this, he distinguishes >single-valued from multi-valued functions: Although I was the leading member of the "OCL team", many more people from the UML team and around it have shaped the current OCL definition. There have been many 'furious' debates on OCL design issues. The debate about the '->' syntax was resolved by good arguments and most (not all :-() people involved agreed on this solution. Many more people have argued vociferously on a number of issues. Sometimes you win the debate, sometimes you lose. Maybe it is comforting to know that I have lost several debates as well... That's an inherent problem of an standard that is defined by a large group: not everybody will be fully happy with the end result. From UML 1.1 to 1.4 we have resolved most semantic issues that were send to the UML RTF. In the upcoming UML 2.0 submission for OCL we hope to get even more (hopefully all) of them resolved. > father->age > > father->>children > >such that expressions like: > > father->>children->age >have an implicit sense of mapping age over each child and collecting >the set result. Here, the syntax difference reflects the semantic >difference directly, unpacking each child in the returned set. >The ->> had both the sense of visually indicating a set-valued result >and of implicitly implying a "for all" quantification in the path >expression. Since this was for databases, the results of queries >were always either single objects, or flattened sets of objects. > >You could then use (my own suggestion here): > > father->children > >to refer to the SET explicitly, such that: > > father->children->size > >were instantly meaningful. OK, you OCL hackers, how about it then? What exactly is an 'OCL hacker' ? Could I be one? And what do 'father' and 'children' refer to in the above example ? If you explain I will try to give the OCL for this. >--Tony Jos _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl


Date view Thread view Subject view Author view