Re: A question on OCL



Re: A question on OCL

From: Jos Warmer <j.warmer_at_klasse.nl>
Date: Sun, 21 Dec 2008 20:52:50 +0100
Message-ID: <494E9E92.90701@klasse.nl>
Earl,

As far as I am concerned your answer is the one that Arno should be using. 
In general allInstances() is something that you should avoid, because it 
is unclear in what context allInstances is evaluated.  This is 
somethiong that must be defined outside of your model (so outside the 
UML and OCL stuff) and is therefore usually ambiguous.

Jos

Waldin, Earl wrote:
> Hello Arnon
>  
> Well, you can always use allInstances to get a hold of all instances 
> of any classifier, as long as that classifier has a finite extent 
> (i.e., a finite number of instances) which is the case here. Something 
> like the following would do
>  
>   Item.allInstances()->forAll(i | i.type="journal" or 
> i.type="proceeding") implies Person.allInstances()->forAll(p | p.type 
> = "faculty")
>  
> If journal, proceeding and faculty are classifiers (i.e., they are 
> subtypes of item or person) then you could write it
>  
> Item.allInstances()->forAll(i | i.oclIsKindOf(Journal) or 
> i.oclIsKindOf(Proceeding)) implies Person.allInstances()->forAll(p | 
> p.oclIsKindOf(Faculty))
>  
> Note that allInstances is not always the best way to model things. 
> Relevent semantics may get lost, e.g., is it really all persons, or 
> just persons affiliated with the library? Most likely you have some 
> classifier that represents the library system (say Library) and all 
> the items and persons in this system are owned directly or indirectly 
> by the library. Persons in general would not be, but there is likely 
> some classifier that is, say LibraryMember. Assume both items and 
> members are owned directly by the library. Then you could write:
>  
> context Library
>   self.items->forAll(i | i.oclIsKindOf(Journal) or 
> i.oclIsKindOf(Proceeding)) implies self.members->forAll(m | 
> m.oclIsKindOf(Faculty))
>  
> In general, if you are modeling a system, or some closed world, there 
> is, or should be, some classifier that represents the whole thing.  
> Otherwise your universe of discourse is not clear. If you follow this 
> guideline, then everything can be reached from this classifier. If 
> your universe of discouse is clear without a representative, for 
> example, you are creating a UML profile for a specific domain whose 
> context is clear, then you can possibly skip the representative 
> classifier and use allInstances. If you have a profile, 
> then allInstances refers to all instances of the classifiers in the 
> domain of the profile. Some people may argue that you must always have 
> such a representative classifier, but I'll leave that question open.
>  
> This representative classifier is not simply a "mediator". Rather, it 
> is the glue that holds the model together and makes it a coherent whole.
>  
>     -Earl
>
> ----------------------------------------------------------------------
> Earl Waldin                             tel: +41 31 828 9222
> Paranor AG                              fax: +41 31 828 9299
> Juraweg 14                              email: earl.waldin@paranor.ch
> CH-3046 Wahlendorf
> Switzerland
> ----------------------------------------------------------------------
>
>     -----Original Message-----
>     *From:* puml-list-request@cs.york.ac.uk
>     [mailto:puml-list-request@cs.york.ac.uk] *On Behalf Of *Arnon Sturm
>     *Sent:* Thursday, 18 December, 2008 09:36
>     *To:* puml-list@cs.york.ac.uk
>     *Subject:* A question on OCL
>
>     All,
>      
>     I wonder whether it is possible to specify an OCL constraint on
>     two or more model elements which do not have a navigation path
>     among them.
>      
>     For example, in case of a library system we have two "unrelated"
>     classes: item and person.
>     I would like to specify the follwoing constraint: if the items of
>     a particular system are all of type 'journal' or 'proceeding',
>     then all the persons in this system are of type 'faculty'.
>      
>     For sure, there is the possibility to define a "mediator" class
>     that will create navigation paths. However, we are interested in
>     specifying the constraint without that "mediator" class.
>      
>     Thanks for your help,
>      
>     Arnon Sturm
>
Received on Sun 21 Dec 2008 - 19:51:29 GMT