RE: Questions regarding oclAny.oclType



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Fri, 2 Feb 2001 10:08:16 -0500


michael, ....b) compare all attributes and associations of self and the .... argument in a generic way (all members must be equal) some hints about possible pitfalls: 1. you'd better only compare associations that are directed (and point in the right direction!). 2. comparing representations doesn't give a reasonable notion of equality: you need to compare abstractions. if your associations are properly abstract, this may be ok. 3. a widely held view is that equality for mutable types should be reference equality, so you need to know if the objects are mutable. java 1.2 reversed course on this and really messed up: the result is representation exposure (which causes hash tables to break when their keys are mutated, for example). there's a useful discussion of equality in the new edition of the book by Liskov and Guttag (Addison Wesley, 2001). i have a paper on object models of code that explains the difference between abstract and concrete associations if you're not familiar with that. /daniel ....-----Original Message----- ....From: Gruebsch, Michael [mailto:Michael.Gruebsch@ibykus.de] ....Sent: Friday, February 02, 2001 8:13 AM ....To: 'puml-list@cs.york.ac.uk' ....Subject: Questions regarding oclAny.oclType .... .... ....In my project I want to describe the post condition for an ....override of the JAVA core function: .... .... boolean java.lang.Object.equals(java.lang.Object) .... Description available under .... http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html .... ....For that reason I need to do the following .... ....a) compare the type of self and the type of the argument .... (type must be equal) in a generic way (the type itself .... is unknown) ....b) compare all attributes and associations of self and the .... argument in a generic way (all members must be equal) .... ....Unfortunately oclAny.oclType has been dropped since UML 1.3 ....because it has been defined as operation resulting in a ....unique value (property) before. .... ....My questions are: .... ....1st) Regarding my project: How can I solve a) and b) above .... by means of OCL? .... ....2nd) If oclType is self-containing it is possible to define .... an operation: .... .... oclAny::oclTypes() : Set{oclType} .... post: result = oclType.allInstances()->select .... (T : oclType | self.oclIsKindOf/TypeOf(T)) .... .... Any remarks about that? Is there already a proposal .... for such an construct? .... .... ....3rd) If oclType is not self-containing then both expressions .... "Set{oclType}" as well as "oclType.allInstances()" are .... undefined. .... .... In this case what were the solution to get on the meta .... level? .... .... ....In either way the definition is complex (IMHO): has oclType a ....type and what is it? OclType having a type implies that it ....(oclType or its type?) is a subtype of oclAny and that ocl- ....Type is self-containing. It would exclude the set-theoretical ....definition .... .... oclType = Set{oclAny} .... ....because collection-types do not belong to oclAny since UML 1.3. .... .... ....4th) I read only the statement that a certain object may be- .... long to more than one type. What was the exact objection .... against oclAny::oclType() : oclType .... .... Is it founded in multi-inheritence? .... .... ....Thank you! .... .... ....-- michael.gruebsch@ibykus.de ....--------------------------------- >8 -- .... .... .... ....To remove yourself from this list please mail ....puml-list-request@cs.york.ac.uk ....with a message containing the word "unsubscribe". ....


Date view Thread view Subject view Author view