Issue 14356: Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics (uml2-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: Reconcile the algebra of collections across OCL & UML’s intentional & extensional semantics & test this statically with OCL & dynamically with OCL & fUML scenarios. Bran, Your comments and those from Dave Hawkins & Salman Qadri confirm my suspicions that it would be unwise to submit a resolution to 8023 in ballot 10; I won’t. Dragan Milicev’s paper is really excellent; I’m really glad you pointed this out. I highly recommend this paper for consideration in the UML2 RFI workshop: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Dragan clearly states that his formalization of association is squarely in the domain of intentional semantics; not extensional semantics as stated in clause 7.3.3: “An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link.” This paper points to a fundamental limitation in the way the runtime semantics of the UML2 has been specified in clause 6.3.1 in the domain of extensional semantics: “Classes, events, and behaviors model sets of objects, occurrences, and executions with similar properties. Value specifications, occurrence specifications, and execution specifications model individual objects, occurrences, and executions within a particular context.” The real problem here isn’t in the fact that there are two different ways to specify the semantics of associations ­ the restrictive interpretation in Dragan’s terminology which is really an extensional semantics and the intentional semantics Dragan proposes which I believe is fundamentally correct (as far as I’ve read it). The real problem is in the semantic mismatch between the extensional & intentional semantics of associations (assuming Dragan is right). The current extensional semantics of the UML2 is based on an impoverished notion of collections: sets & sequences. Dragan’s intentional semantics for associations involves the same categories of collections that OCL uses: sets, sequences & bags (see clause 7.5.11 in ocl2/ocl2.1) What this all means is that we need to focus an RTF cycle on reconciling the algebra of collections across OCL & the extensional & intentional semantics of UML2 and of fUML. The goal of this reconciliation is twofold: we should be able to specify all necessary well-formedness constraints on the relationship between M1 & M0 in OCL we should be able to use fUML to exercise relevant scenarios of events starting in one M1/M0 context and finishing in another M1/M0’ context and specify in OCL well-formedness constraints on the relationship between M0/M0’ as a function of the events processed & the behavior that happened as a result of processing by some active object (see clause 6.4.2). We can use the fUML subset to scope this reconciliation effort to something manageable as an RTF; learn from this experience and use that to tackle more exotic things like state machines. Resolution: Revised Text: Actions taken: September 8, 2009: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (316A)" To: Juergen Boldt Date: Tue, 8 Sep 2009 10:38:24 -0700 Subject: Re: Strategic issue: revisit the runtime semantics of the uml2 -- Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Topic: Strategic issue: revisit the runtime semantics of the uml2 -- Re: Why subsetting/redefinition implies specialization (issue 8023?) -- Re: 14235 -- Re: Ballot 10: status Thread-Index: Acowp//xxMHuWSMDSouunvcRv696IgAAypTU Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized I think so; I suggest the following title: Reconcile the algebra of collections across OCL & UML.s intentional & extensional semantics & test this statically with OCL & dynamically with OCL & fUML scenarios. - Nicolas On 9/8/09 10:15 AM, "Juergen Boldt" wrote: new issue? -Juergen At 12:37 PM 9/8/2009, you wrote: Bran, Your comments and those from Dave Hawkins & Salman Qadri confirm my suspicions that it would be unwise to submit a resolution to 8023 in ballot 10; I won.t. Dragan Milicev.s paper is really excellent; I.m really glad you pointed this out. I highly recommend this paper for consideration in the UML2 RFI workshop: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Dragan clearly states that his formalization of association is squarely in the domain of intentional semantics; not extensional semantics as stated in clause 7.3.3: .An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link.. This paper points to a fundamental limitation in the way the runtime semantics of the UML2 has been specified in clause 6.3.1 in the domain of extensional semantics: .Classes, events, and behaviors model sets of objects, occurrences, and executions with similar properties. Value specifications, occurrence specifications, and execution specifications model individual objects, occurrences, and executions within a particular context.. The real problem here isn.t in the fact that there are two different ways to specify the semantics of associations ­ the restrictive interpretation in Dragan.s terminology which is really an extensional semantics and the intentional semantics Dragan proposes which I believe is fundamentally correct (as far as I.ve read it). The real problem is in the semantic mismatch between the extensional & intentional semantics of associations (assuming Dragan is right). The current extensional semantics of the UML2 is based on an impoverished notion of collections: sets & sequences. Dragan.s intentional semantics for associations involves the same categories of collections that OCL uses: sets, sequences & bags (see clause 7.5.11 in ocl2/ocl2.1) What this all means is that we need to focus an RTF cycle on reconciling the algebra of collections across OCL & the extensional & intentional semantics of UML2 and of fUML. The goal of this reconciliation is twofold: we should be able to specify all necessary well-formedness constraints on the relationship between M1 & M0 in OCL we should be able to use fUML to exercise relevant scenarios of events starting in one M1/M0 context and finishing in another M1/M0. context and specify in OCL well-formedness constraints on the relationship between M0/M0. as a function of the events processed & the behavior that happened as a result of processing by some active object (see clause 6.4.2). We can use the fUML subset to scope this reconciliation effort to something manageable as an RTF; learn from this experience and use that to tackle more exotic things like state machines. Ok, enough dreaming, back to the reality of today.s work... - Nicolas. On 9/8/09 1:58 AM, "Bran Selic" > wrote: Excellent, rationalization of redefinition, Nicolas, it almost makes the original intent look rational. I believe that this explanation should eventually find its way into the spec as a kind of cleanup item. However, I recommend against its inclusion in an urgent fix ballot for two reasons: (1) it is only a partial fix to the issue of association and feature semantics and, as such, it may lead to conflicts with potential future fixes (in other words, I think we need to think about it some more) and (2) it is not an urgent issue (the problem has been around for a long time and the world is still intact) and I do not think it is a good idea to set a precedent of "sneaking" in non-urgent issue resolutions in an urgent ballot, which in many ways shortcircuits the usual peer review process. This opens up a loophole for some serious misuse in the future. BTW, note that redefinition also applies to behavioral features, not just structural features. When we introduced the concept of redefinition in UML 2, the idea was to simply capture what is established practice in most common OO languages. For example, most such languages will allow you to redefine the implementation of a method in a subclass without being too particular about whether or not the redefined method is semantically compatible with the one that it is redefining. (This is because such things are practically impossible to formally verify except in very trivial cases.) We did throw in some mumbo-jumbo about the redefined element being "consistent with" what it is redefining, but, this is really just a placebo (the default isConsistentWith( ) OCL query is a that simply returns "false" -- it is, in fact, a semantic variation point that should be overridden in any specific implementation of UML). The semantics of links are still not quite finalized. For example, Dragan Milicev proposed a perfectly reasonable semantics for links (and, consequently associations) that are currently not supported in fUML, but which, in my opinion, should be allowed in UML. In this variation, it is quite possible for one end of an association to be "unique" while the other is non-"unique" (for a contrary view see, for example, issue 5977). The idea is to think of links as function-like mappings from a source domain to a target domain which imposes a kind of "directionality" to them. This is a different view from the traditional one in which there is no directionality to a link (NB: this has nothing to do with navigability, which is practically an irrelevant feature nowadays). I won't go into more details here, but merely want to point out that there is still work left to do to define the semantics of things as basic as association ends and that, therefore, you should avoid trying to introduce partial fixes through urgent ballots. Cheers...Bran On Mon, Sep 7, 2009 at 1:28 AM, Rouquette, Nicolas F (316A) < nicolas.f.rouquette@jpl.nasa.gov > wrote: I forgot to explain why subsetting/redefinition of association end properties implies association specialization. The explanation below could be part of a resolution to issue 8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 The explanation involves making a distinction between two ways in which one can specify the relationship between A) a classifier at M1 and the set of instances at M0 that will be classified by that classifier B) a structural feature at M1 and the set of values at M0 that will be in a slot corresponding to that structural feature For classifiers (A): - by extension ­ i.e., specifying which elements are classified by that classifier - by intension ­ i.e., specifying the criteria for an element to be classified by that classifier This leads to two different techniques for specializing a classifier: - by extension ­ i.e., specifying that the extent of the specialized classifier is a subset of the extent of the general classifier (e.g., Generalization) - by intension ­ i.e., specifying that the criteria for an element to be classifier by the specialized classifier is more restrictive than the membership criteria specified for the general classifier (e.g., Redefinition) For structural features (B): - by extension ­ i.e., specifying which elements are in the set of values of a slot for that structural feature - by intension ­ i.e., specifying the criteria for an element to be in the set of values for a slot for that structural feature This leads to two different techniques for specializing a structural feature: - by extension ­ i.e., specifying that the set of values for a slot for the specialized structural feature is a subset of the set of values for a slot of the general structural feature (e.g., property subsetting) - by intension ­ i.e., specifying that the criteria for an element to be in the set of values for a slot for the specialized structural feature is more restrictive than the membership criteria specified for the general structural feature (e.g., property redefinition) In the case of an association (a classifier), association end subsetting/specialization must be consistent with the purpose of these mechanisms fo For subsetting, the explanation stems from the meaning of subsetting in the domain of extensional semantics. The extensional semantics of an association is a set of tuples. When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. When redefinition is applied to all of the association ends, it follows that the membership criteria of the association whose association ends do the redefining will be more constraining than the membership criteria of the association whose ends are redefined; i.e., the set of tuples of the former association will be a restricted subset of the set of tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the intentional semantics of an association as specifying the membership criteria for a tuple to be included in the extent of that association. This implies that an association is not well-formed when a proper subset of its association ends are subsetting and/or redefining a proper subset of another association.s association ends because this use of subsetting for association ends leads to an incomplete characterization of the relationship between the actual/intended extent of the association with the association ends doing the subsetting/redefining and the actual/intended extent of the association whose association ends are subsetted/redefined. Note that one can apply property subsetting outside the context of association end properties. As much as I feel confident about this explanation, I.m reluctant to put it as part of a resolution to 8023 for ballot 10 unless Ed and Conrad have enough time to review it and check that it is kosher w.r.t. their enlightened understanding of UML semantics prior to voting on ballot 10. It would be clearly counterproductive to introduce any resolution in ballot 10 on something potentially as contentious as clarifying hidden secrets of UML semantics. - Nicolas. On 9/6/09 1:43 PM, "Rouquette, Nicolas F (316A)" < nicolas.f.rouquette@jpl.nasa.gov < http://nicolas.f.rouquette@jpl.nasa.gov > > wrote: I was looking into (1) when I received this. I agree we need a separate issue; please make sure to focus the issue to the property subsetting of the two associations pertaining to redefinitions in the superstructure & the infrastructure, i.e.: A_redefinedElement_redefinableElement A_redefinitionContext_redefinableElement This issue is addresses a limited scope of other issues already filed about subsetting/redefinitions. These 4 issues are asking for explanations of concepts related to associations & association end properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue6498 http://www.omg.org/issues/uml2-rtf.open.html#Issue8023 http://www.omg.org/issues/uml2-rtf.open.html#Issue13927 http://www.omg.org/issues/uml2-rtf.open.html#Issue14084 (duplicate of 13927) This issue is focused on an apparent inconsistency in property subsetting: http://www.omg.org/issues/uml2-rtf.open.html#Issue8952 This issues is narrowly focused on the case of subsetting for non-derived union properties: http://www.omg.org/issues/uml2-rtf.open.html#Issue11238 The present issue about the specialization hierarchy of redefinition-related associations is outside the scope of 8952 & 11238; however, the resolution may be helpful for the 4 issues above. In fact, the use of .copy-down. in (2) is a practice that has not been properly explained before; opinions may vary on why it is needed. The bottom line is that subsetting/redefining association end properties implies association specialization as indicated in 7.3.3 in UML 2.3. Why? See below. Once this is understood, then you can consider the question whether we are specializing wholly-defined elements or not. For example, in the case of 14235, we needed to have Interface::ownedAttribute in Classes::Interfaces subset Classifier::attribute. Since the {subets...} & {redefines...} notation uses base names instead of qualified names, it would be ambiguous in the diagram notation whether {subsets attribute} would refer to Classes::Kernel::Classifier::attribute or Classes::Interfaces::Classifier::attribute. It would also be incorrect in this case to add simply Classes::Interfaces::Classifier::attribute without the defining association because Classifier::attribute would be a vanilla property, not an association-end property and the association specialization semantics wouldn.t kick in... In general, the idea behind .copy-down. is to make sure that anything we subset/redefine from the receiving This issue may be useful to resolve 13927; in fact, the use of .copy-down. in (2) is precisely related to the problem of property subsetting/redefinition in the context of package merge. Basically, the idea of .copy down. is to make sure that in the context of a single package, you have either: - the general elements (metaclasses, associations, properties) are wholly defined in the context of the merged package without matching definitions in the context of the receiving package - the specific elements (metaclasses, associations, properties) are in the context of the receiving package or: - copy-down the structure of the general elements (metaclasses, associations, properties) from the context of the merged package to the context of the receiving package such that the general element in the context of the receiving package has a matching definition in the context of the merged package. We need to add to 14235 a new constraint for the package merge of properties. Matching properties must have matching classifiers (i.e., the .classifier. end of the A_attribute_classifier association on figure 7.9 which requires that this association be properly specialized for specializations of Classifier (which as a large taxonomy as shown in Annex F). I.ll make the modification to 14235. - Nicolas. On 9/6/09 11:57 AM, "Salman Qadri" < http://Salman.Qadri@mathworks.com > > wrote: Actually looking at the spec under 7.3.44, owningAssociation is expected to subset RedefinedElement::redefinitionContext. This is, however, missing from the XMI. I also think .class. and.datatype. should also be updated in the spec as well as the xmi to also subset redefinitionContext. For these I will create a separate issue. For 14235, I will add redefinitionContext as a subset in the resolution for the new property .interface.. My question about the copy-down of Classifier still stands. Salman From: Salman Qadri Sent: Sunday, September 06, 2009 12:54 PM To: Rouquette, Nicolas F (316A); Dave Hawkins Cc: uml2-rtf@omg.org < http://uml2-rtf@omg.org > Subject: RE: 14235 -- Re: Ballot 10: status Hi Nicolas, I updated the resolution with the suggested fixes. However in doing so I have 2 more flags that I wanted to address with you: 1) The original issue proposes that the new .interface. property should also subset Classes-Kernel-RedefinableElement-redefinitionContext, which is not part of the resolution but I think is needed. But I also noticed that Classes-Kernel-Property-datatype and Classes-Kernel-Property-class also fail to subset Classes-Kernel-RedefinableElement-redefinitionContext, which means that adding it to the resolution would make .interface. inconsistent with .datatype., .owningAssociation. and .class.. Should we add this subsettedProperty only to .interface., or should we propose to add it to all of them, or should we do none of them and raise this is a separate issue? For now my hunch is we.ll create a new issue about this. 2) I do not see why the resolution does a copy-down of . Classes-Kernel-A_attribute_classifier. or .Classes-Kernel-Classifier.. In my opinion a copy-down should only be done when something within the elements that are being copied-down needs to change, not when they are simply being referred to. I would suggest we remove these copy-downs into .Classes-Interfaces. but I wanted to understand why you felt we should do it. Thanks, Salman From: Rouquette, Nicolas F (316A) [ mailto:nicolas.f.rouquette@jpl.nasa.gov ] Sent: Friday, September 04, 2009 3:28 PM To: Salman Qadri; Dave Hawkins Cc: uml2-rtf@omg.org < http://uml2-rtf@omg.org > Subject: Re: 14235 -- Re: Ballot 10: status Salman, I agree with your points. Feel free to update the resolution in the SVN. - Nicolas. On 9/4/09 12:21 PM, "Salman Qadri" < http://Salman.Qadri@mathworks.com > > wrote: Hi Nicolas, I had a couple of points on the Resolution for 14235: 1) In clause 7.3.44 Property, under Associations, add the following at the bottom of the list: . interface : Interface[0..1] References the Interface that owns the Property. Subsets NamedElement::namespace, Feature::featuringClassifier I think you are should also have the subset .Property::classifier. (to be consistent with what is done for .datatype., point 3 under 7.3.44 under Associations). In the XMI, this translates to .Classes-Kernel-A_attribute_classifier-classifier. (this is there currently for Classes-Kernel-Property-datatype as well as Classes-Kernel-Property-class in the XMI). 2) Most importantly, I think you forgot to mention the fact that we need to add the ownedAttribute .interface. to Classes::Interfaces::Property, set its. association to . Classes-Interfaces-A_interface_ownedAttribute . and set its subsettedProperty to be .Classes-Kernel-Feature-featuringClassifier Classes-Kernel-NamedElement-namespace Classes-Kernel-A_attribute_classifier-classifier.. Its. id should be .Classes-Interfaces-Property-interface. and the .interface. member end of . Classes-Interfaces-A_interface_ownedAttribute . as you already mentioned in your resolution should now be .Classes-Interfaces-Property-interface.. Can you update the resolution to this effect, or I can do it if you want. Salman From: Rouquette, Nicolas F (316A) [ mailto:nicolas.f.rouquette@jpl.nasa.gov ] Sent: Friday, September 04, 2009 10:45 AM To: Dave Hawkins Cc: uml2-rtf@omg.org < http://uml2-rtf@omg.org > Subject: 14235 -- Re: Ballot 10: status Salman, You are correct about the property subsetting; my statement about (3) is wrong. I agree that the metamodel needs a good scrubbing to carefully review all of the hierarchies we have: specialization ­ are we consistent in the fact that generalization relationships are not exclusive? association subsetting/redefinition & association specialization ­ 9374 barely scratched the surface on this. - Nicolas. On 9/4/09 7:06 AM, "Dave Hawkins" < http://dave.hawkins@oracle.com > > wrote: Rouquette, Nicolas F (316A) wrote: > Dave, > > On 9/3/09 11:40 AM, "Dave Hawkins" < http://dave.hawkins@oracle.com > > wrote: > > For 14235, while I don't disagree with the inconsistency that there > is no navigable Property-interface property, I don't think it's > true to say that owner or namespace wouldn't be populated. The opposite > end of Interface-ownedAttribute subsets namespace. That's sufficient. > > > Property::owner & Property::namespace are properly populated because of > the associations in Classes::Kernel, not because of the associations in > Classes::Interfaces. > This part of 14235.s point (3) is indeed inaccurate. You mean the ownedElement-owner and ownedMember-namespace associations? I agree that has to be the case. However that's not how derived unions are defined in the specification. In Association (7.3.3) we have: "{union} to show that the end is derived by being the union of its subsets." In Property (7.3.44) we have: "isDerivedUnion : Boolean Specifies whether the property is derived as the union of all of the properties that are constrained to subset it. The default value is false." and "A property may be marked as being a derived union. This means that the collection of values denoted by the property in some context is derived by being the strict union of all of the values denoted, in the same context, by properties defined to subset it. If the property has a multiplicity upper bound of 1, then this means that the values of all the subsets must be null or the same." These seem pretty clear. A derived union is derived from its subsets, not its subsets and a derivation from its opposite end. This means that either the above definitions need to change or all ends of an association must subset a derived union if the one end does. I think this is an issue. > > > Of greater concern is that I believe there are a large number of > associations where this isn't the case. That is, there is a mismatch > between the subsetted properties of the ends. For example: > > Transition::effect {subsets ownedElement} > A_effect_transition::transition > > As both owner and ownedElement are derived unions and those are defined > to be the strict unions of their subsets I think this probably does > mean that owner isn't correctly populated. > > > > Transition::owner & Transition::namespace will be properly populated for > the same reason as above; the definition of A_effect_transition doesn.t > affect these properties. Obviously I disagree with this statement. I don't think the specification of the derivation supports that view. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Rouquette, Nicolas F (316A)" To: Salman Qadri , Maged Elaasar CC: Pete Adaptive , "uml2-rtf@omg.org" Date: Tue, 13 Oct 2009 10:33:53 -0700 Subject: Re: UML 2.3 Metamodel Publish Thread-Topic: UML 2.3 Metamodel Publish Thread-Index: AcpMB+kJehBz6S0BRuKwjcZzY/xWFgABISogAARdoeEAA1w+yQ== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized With XPath2.0, one can write a query to find association bad smells in CMOF metamodels: //ownedMember[@xmi:type="cmof:Association"][not(contains(@memberEnd," "))] For https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Specification/Deliverables/UML2.3 Merged XMI.zip, revision 19226, this produces: Infrastructure, Superstructure, L0.merged, LM.merged: none L1.merged: /xmi:XMI[1]/cmof:Package[1]/ownedMember[47] - memberEnd="Feature-featuringClassifier" name="A_feature_featuringClassifier" xmi:id="A_feature_featuringClassifier" xmi: ... L2.merged: /xmi:XMI[1]/cmof:Package[1]/ownedMember[45] - memberEnd="Feature-featuringClassifier" name="A_feature_featuringClassifier" xmi:id="A_feature_featuringClassifier" xmi: ... /xmi:XMI[1]/cmof:Package[1]/ownedMember[179] - memberEnd="ConnectableElement-end" name="A_end_role" xmi:id="A_end_role" xmi:type="cmof:Association" L3.merged: /xmi:XMI[1]/cmof:Package[1]/ownedMember[42] - memberEnd="Feature-featuringClassifier" name="A_feature_featuringClassifier" xmi:id="A_feature_featuringClassifier" xmi: ... /xmi:XMI[1]/cmof:Package[1]/ownedMember[174] - memberEnd="ConnectableElement-end" name="A_end_role" xmi:id="A_end_role" xmi:type="cmof:Association" This looks to me like a bug in the Eclipse UML implementation of package merge. - Nicolas. On 10/13/09 8:57 AM, "Rouquette, Nicolas F (316A)" wrote: Thanks Salman for your keen review. There is indeed something very fishy about associations with only one member end in the xmi. Association::memberEnd has a lower multiplicity of 2 and it isn.t derived; thus, it seems to me that the xmi should also have at least two member ends. For CMOF models, all associations should have exactly two member ends in the xmi; there are many violations of that in our xmi. I.ve explained elsewhere that generalization relationships among associations are necessary due to the extensional semantics of association end subsetting: http://www.omg.org/issues/issue14356.txt --------- When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. --------- Currently, the unmerged metamodel lacks most (if not all) generalization relationships among associations. This is not surprising: historically, subsetting and redefinition have been applied only to named association ends when in fact they should have been applied symmetrically to both ends according to the extensional and intentional semantics of subsetting and redefinition respectively. Currently, generalization relationships among associations are inferred during package merge; that.s why you find them in the merged metamodel but not in the unmerged metamodel. They should be in both. Late in the UML 2.3 RTF, you and Dave Hawkins reported several embarassing bugs in the XMI. As a result, Maged and I discussed effective techniques to systematically find such offending cases of metamodeling bad smells. As of today, there are 8 metamodeling bad smells operationalized as OCL queries in RSA 7.5 here: https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Models/Constraints/RSA7.5-OCL/ I suppose that we need to add a ninth XSLT bad smell to check that all associations in CMOF artifacts have 2 member ends. However, I suspect that this is more than a bad smell but a genuine bug in the Eclipse UML machinery we.ve been using. - Nicolas. On 10/13/09 7:00 AM, "Salman Qadri" wrote: In Specification\Deliverables\UML2.3 Merged XMI.zip, if I open L3.merged.cmof, I see the following: Notice there is only 1 member end. This is not the case in 2.1.1. In 2.3 I also see: Notice again, the one end. I do not see this in 2.1.1. Also, I.m not sure if this is intentional or not, but 2.3 is full of generalizations on Associations, which were not there in 2.1.1. Is this intentional or not? If not, we should remove them. For example: Notice how ownedAttribute specializes 3 other associations. If this is intentional, can you point me to the issue # that addresses this? Thanks, Salman From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, October 13, 2009 9:20 AM To: Salman Qadri Cc: Pete Rivett; uml2-rtf@omg.org Subject: Re: UML 2.3 Metamodel Publish Salman, I checked the two associations you mentioned and copied what I see. They look identical to me and have two ends in "memberEnd". Can you please elaborate on the discrepency you see? In 2.3: In 2.1.1: In 2.3: In 2.1.1: Salman Qadri Salman Qadri 10/08/2009 08:38 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett , "uml2-rtf@omg.org" Subject Re: UML 2.3 Metamodel Publish There are still some regressions/bugs maged in the XMI. I noticed A_end_role and A_feature_featuringClassifier each have only one member end. Please compare with 2.1.1 for correct output. Salman On Oct 1, 2009, at 3:30 PM, "Maged Elaasar" wrote: > An updated UML 2.3 model doc with the following changes: > > 1- section Association End => Owned Association End > 2- the constraint's language showin between ( ), for example: body > (OCL): true > 3- Classifiers can have a "Found In Diagram" section with references > to diagrams they appear on > 4- Diagrams have "Classifiers Local to Package" and "Classifier > External to Package" sections with links to classifiers on these > diagrams > 5- Removed the cross arrow icon that used to link to the opposite > end of an association end. The 'aggregation' icon is still there and > it links to the association, which lists the two member ends (so 2 > clicks now to get to opposite) > 6- TOC of PDF files are all collapsed when doc is opened. > > (See attached file: UML 2.3 Metamodel.zip) > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [cid:2__=0ABBFCD1DFFAE4D78f9e8a93df938@ca.ibm.com]Maged Elaasar/ > Ottawa/IBM@IBMCA > > > > Maged Elaasar/Ottawa/IBM@IBMCA > > 09/30/2009 07:10 PM > > > > To > > "Pete Rivett" > > cc > > uml2-rtf@omg.org > > Subject > > RE: UML 2.3 Metamodel Publish > > > > Thank you Pete, comments inline. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > > "Pete Rivett" wrote on 09/30/2009 > 06:46:06 PM: > >> There are only 2 diagrams included under Classes::Kernel . am I >> missing something? > > Those are the diagrams that got changed in 2.3. If you remember, we > started off with a 2.2 metamodel that had no diagrams (long story > there) and I stared recreating the diagrams that got changed in 2.3. > Ofcoure, long term I plan to create the remaining diagrams as well > to make the report complete. > >> Would it be possible to have an index of where a class is defined? >> E.g. if I want to find the definition of metaclass X and I don.t >> know what Package it.s defined in. I cannot even seem to do a sea >> rch >> to achieve this e.g. .Class Package. to find the definition (this >> is >> using Foxit not Adobe Reader). Maybe because the class name in its >> definition is a hyperlink . but it just links to itself which seems >> a bit pointless. > > The class name is a link, since it could extend over several pages, > this allows you to go to the first page from any page quickly. Let > me know if this makes sense. And in Acrobat, I could search and find > "Class Package" properly. I will investigate the Index idea, good one. > >> Need to link from an association end to the Association . this is a >> significant omission > > The link is there. It is from the icon beside the association end > that shows the 'aggregation' of the association. The other cross- > arrows icon is to navigate the the association end's 'opposite' > >> · Link from an element to the diagrams it appears in > > Can do this one no prob. > >> · Hyperlinks from shapes on diagrams to their definition > > Easier done in the HTML version, but will see if doable in the PDF one > >> · Searchable diagrams. What format are you using . it se >> ems >> fuzzy so I guess JPG . SVG would be ideal but PNG or GIF would be >> better than JPG for quality if not searchability > > Will try to use SVG instead > >> · more nesting in the contents page e.g. Activities:: >> BasicActivities nested within Activities. And to start off with it >> all collapsed or only one level open. At the moment it.s a pain to >> navigate. > > Will investigate the nesting of packages in the TOC insteadof a flat > structure. About the TOC being collapsed, is this a something that > is generated into the PDF or something I can set after the > production of the PDF? > >> · key for the little symbols shown next to Properties e.g. >> does 2 opposite-facing arrows indicate navigable in both directions? >> I suspect not since /redefinableElement has the symbol. That does >> mean that navigability is not represented anywhere except in the >> diagrams: there is not even a subheading for Navigable Owned End. >> HOWEVER maybe that.s just as well . since in the UML spec >> .navigability. is by convention a means to indicate end ownersh >> ip, >> and this IS correctly represented in the document. > > Yes, I took the showing of the end under the Class/Association as > enough indication of the navigability. BTW, the little arrow-icons > is not meant to indicate navigability, it is just an icon to allow > you to navigate to the 'opposite' end (does not reflect any > semantics). Maybe bad choice of icon? any other suggestion? > >> · Indication of the language used for constraints (i.e. >> Expression::language). > > I can add the language > >> · Hyperlinks in the OCL to definitions for the properties or >> operations used > > Ok, will keep it in mind as a stretch goal :) > >> · The subheading .Association Ends. should really be >> .Owned >> Association Ends. (under both Class and Association). > > Ok, but should it also be 'Owned Attribute' and 'Owned Operaion'..etc? > > > > From: "Rouquette, Nicolas F (316A)" To: Salman Qadri , Maged Elaasar CC: Pete Adaptive , "uml2-rtf@omg.org" Date: Tue, 13 Oct 2009 10:33:53 -0700 Subject: Re: UML 2.3 Metamodel Publish Thread-Topic: UML 2.3 Metamodel Publish Thread-Index: AcpMB+kJehBz6S0BRuKwjcZzY/xWFgABISogAARdoeEAA1w+yQ== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized With XPath2.0, one can write a query to find association bad smells in CMOF metamodels: //ownedMember[@xmi:type="cmof:Association"][not(contains(@memberEnd," "))] For https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Specification/Deliverables/UML2.3 Merged XMI.zip, revision 19226, this produces: Infrastructure, Superstructure, L0.merged, LM.merged: none L1.merged: /xmi:XMI[1]/cmof:Package[1]/ownedMember[47] - memberEnd="Feature-featuringClassifier" name="A_feature_featuringClassifier" xmi:id="A_feature_featuringClassifier" xmi: ... L2.merged: /xmi:XMI[1]/cmof:Package[1]/ownedMember[45] - memberEnd="Feature-featuringClassifier" name="A_feature_featuringClassifier" xmi:id="A_feature_featuringClassifier" xmi: ... /xmi:XMI[1]/cmof:Package[1]/ownedMember[179] - memberEnd="ConnectableElement-end" name="A_end_role" xmi:id="A_end_role" xmi:type="cmof:Association" L3.merged: /xmi:XMI[1]/cmof:Package[1]/ownedMember[42] - memberEnd="Feature-featuringClassifier" name="A_feature_featuringClassifier" xmi:id="A_feature_featuringClassifier" xmi: ... /xmi:XMI[1]/cmof:Package[1]/ownedMember[174] - memberEnd="ConnectableElement-end" name="A_end_role" xmi:id="A_end_role" xmi:type="cmof:Association" This looks to me like a bug in the Eclipse UML implementation of package merge. - Nicolas. On 10/13/09 8:57 AM, "Rouquette, Nicolas F (316A)" wrote: Thanks Salman for your keen review. There is indeed something very fishy about associations with only one member end in the xmi. Association::memberEnd has a lower multiplicity of 2 and it isn.t derived; thus, it seems to me that the xmi should also have at least two member ends. For CMOF models, all associations should have exactly two member ends in the xmi; there are many violations of that in our xmi. I.ve explained elsewhere that generalization relationships among associations are necessary due to the extensional semantics of association end subsetting: http://www.omg.org/issues/issue14356.txt --------- When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. --------- Currently, the unmerged metamodel lacks most (if not all) generalization relationships among associations. This is not surprising: historically, subsetting and redefinition have been applied only to named association ends when in fact they should have been applied symmetrically to both ends according to the extensional and intentional semantics of subsetting and redefinition respectively. Currently, generalization relationships among associations are inferred during package merge; that.s why you find them in the merged metamodel but not in the unmerged metamodel. They should be in both. Late in the UML 2.3 RTF, you and Dave Hawkins reported several embarassing bugs in the XMI. As a result, Maged and I discussed effective techniques to systematically find such offending cases of metamodeling bad smells. As of today, there are 8 metamodeling bad smells operationalized as OCL queries in RSA 7.5 here: https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Models/Constraints/RSA7.5-OCL/ I suppose that we need to add a ninth XSLT bad smell to check that all associations in CMOF artifacts have 2 member ends. However, I suspect that this is more than a bad smell but a genuine bug in the Eclipse UML machinery we.ve been using. - Nicolas. On 10/13/09 7:00 AM, "Salman Qadri" wrote: In Specification\Deliverables\UML2.3 Merged XMI.zip, if I open L3.merged.cmof, I see the following: Notice there is only 1 member end. This is not the case in 2.1.1. In 2.3 I also see: Notice again, the one end. I do not see this in 2.1.1. Also, I.m not sure if this is intentional or not, but 2.3 is full of generalizations on Associations, which were not there in 2.1.1. Is this intentional or not? If not, we should remove them. For example: Notice how ownedAttribute specializes 3 other associations. If this is intentional, can you point me to the issue # that addresses this? Thanks, Salman From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, October 13, 2009 9:20 AM To: Salman Qadri Cc: Pete Rivett; uml2-rtf@omg.org Subject: Re: UML 2.3 Metamodel Publish Salman, I checked the two associations you mentioned and copied what I see. They look identical to me and have two ends in "memberEnd". Can you please elaborate on the discrepency you see? In 2.3: In 2.1.1: In 2.3: In 2.1.1: Salman Qadri Salman Qadri 10/08/2009 08:38 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett , "uml2-rtf@omg.org" Subject Re: UML 2.3 Metamodel Publish There are still some regressions/bugs maged in the XMI. I noticed A_end_role and A_feature_featuringClassifier each have only one member end. Please compare with 2.1.1 for correct output. Salman On Oct 1, 2009, at 3:30 PM, "Maged Elaasar" wrote: > An updated UML 2.3 model doc with the following changes: > > 1- section Association End => Owned Association End > 2- the constraint's language showin between ( ), for example: body > (OCL): true > 3- Classifiers can have a "Found In Diagram" section with references > to diagrams they appear on > 4- Diagrams have "Classifiers Local to Package" and "Classifier > External to Package" sections with links to classifiers on these > diagrams > 5- Removed the cross arrow icon that used to link to the opposite > end of an association end. The 'aggregation' icon is still there and > it links to the association, which lists the two member ends (so 2 > clicks now to get to opposite) > 6- TOC of PDF files are all collapsed when doc is opened. > > (See attached file: UML 2.3 Metamodel.zip) > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [cid:2__=0ABBFCD1DFFAE4D78f9e8a93df938@ca.ibm.com]Maged Elaasar/ > Ottawa/IBM@IBMCA > > > > Maged Elaasar/Ottawa/IBM@IBMCA > > 09/30/2009 07:10 PM > > > > To > > "Pete Rivett" > > cc > > uml2-rtf@omg.org > > Subject > > RE: UML 2.3 Metamodel Publish > > > > Thank you Pete, comments inline. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > > "Pete Rivett" wrote on 09/30/2009 > 06:46:06 PM: > >> There are only 2 diagrams included under Classes::Kernel . am I >> missing something? > > Those are the diagrams that got changed in 2.3. If you remember, we > started off with a 2.2 metamodel that had no diagrams (long story > there) and I stared recreating the diagrams that got changed in 2.3. > Ofcoure, long term I plan to create the remaining diagrams as well > to make the report complete. > >> Would it be possible to have an index of where a class is defined? >> E.g. if I want to find the definition of metaclass X and I don.t >> know what Package it.s defined in. I cannot even seem to do a sea >> rch >> to achieve this e.g. .Class Package. to find the definition (this >> is >> using Foxit not Adobe Reader). Maybe because the class name in its >> definition is a hyperlink . but it just links to itself which seems >> a bit pointless. > > The class name is a link, since it could extend over several pages, > this allows you to go to the first page from any page quickly. Let > me know if this makes sense. And in Acrobat, I could search and find > "Class Package" properly. I will investigate the Index idea, good one. > >> Need to link from an association end to the Association . this is a >> significant omission > > The link is there. It is from the icon beside the association end > that shows the 'aggregation' of the association. The other cross- > arrows icon is to navigate the the association end's 'opposite' > >> · Link from an element to the diagrams it appears in > > Can do this one no prob. > >> · Hyperlinks from shapes on diagrams to their definition > > Easier done in the HTML version, but will see if doable in the PDF one > >> · Searchable diagrams. What format are you using . it se >> ems >> fuzzy so I guess JPG . SVG would be ideal but PNG or GIF would be >> better than JPG for quality if not searchability > > Will try to use SVG instead > >> · more nesting in the contents page e.g. Activities:: >> BasicActivities nested within Activities. And to start off with it >> all collapsed or only one level open. At the moment it.s a pain to >> navigate. > > Will investigate the nesting of packages in the TOC insteadof a flat > structure. About the TOC being collapsed, is this a something that > is generated into the PDF or something I can set after the > production of the PDF? > >> · key for the little symbols shown next to Properties e.g. >> does 2 opposite-facing arrows indicate navigable in both directions? >> I suspect not since /redefinableElement has the symbol. That does >> mean that navigability is not represented anywhere except in the >> diagrams: there is not even a subheading for Navigable Owned End. >> HOWEVER maybe that.s just as well . since in the UML spec >> .navigability. is by convention a means to indicate end ownersh >> ip, >> and this IS correctly represented in the document. > > Yes, I took the showing of the end under the Class/Association as > enough indication of the navigability. BTW, the little arrow-icons > is not meant to indicate navigability, it is just an icon to allow > you to navigate to the 'opposite' end (does not reflect any > semantics). Maybe bad choice of icon? any other suggestion? > >> · Indication of the language used for constraints (i.e. >> Expression::language). > > I can add the language > >> · Hyperlinks in the OCL to definitions for the properties or >> operations used > > Ok, will keep it in mind as a stretch goal :) > >> · The subheading .Association Ends. should really be >> .Owned >> Association Ends. (under both Class and Association). > > Ok, but should it also be 'Owned Attribute' and 'Owned Operaion'..etc? > > > > From: Salman Qadri To: "Rouquette, Nicolas F (316A)" , Maged Elaasar CC: Pete Adaptive , "uml2-rtf@omg.org" Date: Tue, 13 Oct 2009 13:38:16 -0400 Subject: RE: UML 2.3 Metamodel Publish Thread-Topic: UML 2.3 Metamodel Publish Thread-Index: AcpMB+kJehBz6S0BRuKwjcZzY/xWFgABISogAARdoeEAAy/nMA== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Your welcome. The main thing is that we should have no regressions from the 2.1.1 xmi; only improvements. About issue 14356: There was no resolution or voting done for this issue. We should not incorporate it until it is approved. Salman From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Tuesday, October 13, 2009 11:58 AM To: Salman Qadri; Maged Elaasar Cc: Pete Adaptive; uml2-rtf@omg.org Subject: Re: UML 2.3 Metamodel Publish Thanks Salman for your keen review. There is indeed something very fishy about associations with only one member end in the xmi. Association::memberEnd has a lower multiplicity of 2 and it isn.t derived; thus, it seems to me that the xmi should also have at least two member ends. For CMOF models, all associations should have exactly two member ends in the xmi; there are many violations of that in our xmi. I.ve explained elsewhere that generalization relationships among associations are necessary due to the extensional semantics of association end subsetting: http://www.omg.org/issues/issue14356.txt --------- When subsetting is applied to all of the association ends, it follows that the tuples of the association whose association ends do the subsetting will be a subset of the tuples of the association whose association ends are subsetted; i.e., the set of tuples of the former association will be a subset of the tuples of the latter association. Consequently, the former association will be a specialization of the latter association according to the extensional semantics of an association as the set of tuples in the actual extent of that association. --------- Currently, the unmerged metamodel lacks most (if not all) generalization relationships among associations. This is not surprising: historically, subsetting and redefinition have been applied only to named association ends when in fact they should have been applied symmetrically to both ends according to the extensional and intentional semantics of subsetting and redefinition respectively. Currently, generalization relationships among associations are inferred during package merge; that.s why you find them in the merged metamodel but not in the unmerged metamodel. They should be in both. Late in the UML 2.3 RTF, you and Dave Hawkins reported several embarassing bugs in the XMI. As a result, Maged and I discussed effective techniques to systematically find such offending cases of metamodeling bad smells. As of today, there are 8 metamodeling bad smells operationalized as OCL queries in RSA 7.5 here: https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Models/Constraints/RSA7.5-OCL/ I suppose that we need to add a ninth XSLT bad smell to check that all associations in CMOF artifacts have 2 member ends. However, I suspect that this is more than a bad smell but a genuine bug in the Eclipse UML machinery we.ve been using. - Nicolas. On 10/13/09 7:00 AM, "Salman Qadri" wrote: In Specification\Deliverables\UML2.3 Merged XMI.zip, if I open L3.merged.cmof, I see the following: Notice there is only 1 member end. This is not the case in 2.1.1. In 2.3 I also see: Notice again, the one end. I do not see this in 2.1.1. Also, I.m not sure if this is intentional or not, but 2.3 is full of generalizations on Associations, which were not there in 2.1.1. Is this intentional or not? If not, we should remove them. For example: Notice how ownedAttribute specializes 3 other associations. If this is intentional, can you point me to the issue # that addresses this? Thanks, Salman From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Tuesday, October 13, 2009 9:20 AM To: Salman Qadri Cc: Pete Rivett; uml2-rtf@omg.org Subject: Re: UML 2.3 Metamodel Publish Salman, I checked the two associations you mentioned and copied what I see. They look identical to me and have two ends in "memberEnd". Can you please elaborate on the discrepency you see? In 2.3: In 2.1.1: In 2.3: In 2.1.1: Salman Qadri Salman Qadri 10/08/2009 08:38 PM To Maged Elaasar/Ottawa/IBM@IBMCA cc Maged Elaasar/Ottawa/IBM@IBMCA, Pete Rivett , "uml2-rtf@omg.org" Subject Re: UML 2.3 Metamodel Publish There are still some regressions/bugs maged in the XMI. I noticed A_end_role and A_feature_featuringClassifier each have only one member end. Please compare with 2.1.1 for correct output. Salman On Oct 1, 2009, at 3:30 PM, "Maged Elaasar" wrote: > An updated UML 2.3 model doc with the following changes: > > 1- section Association End => Owned Association End > 2- the constraint's language showin between ( ), for example: body > (OCL): true > 3- Classifiers can have a "Found In Diagram" section with references > to diagrams they appear on > 4- Diagrams have "Classifiers Local to Package" and "Classifier > External to Package" sections with links to classifiers on these > diagrams > 5- Removed the cross arrow icon that used to link to the opposite > end of an association end. The 'aggregation' icon is still there and > it links to the association, which lists the two member ends (so 2 > clicks now to get to opposite) > 6- TOC of PDF files are all collapsed when doc is opened. > > (See attached file: UML 2.3 Metamodel.zip) > > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > [cid:2__=0ABBFCD1DFFAE4D78f9e8a93df938@ca.ibm.com]Maged Elaasar/ > Ottawa/IBM@IBMCA > > > > Maged Elaasar/Ottawa/IBM@IBMCA > > 09/30/2009 07:10 PM > > > > To > > "Pete Rivett" > > cc > > uml2-rtf@omg.org > > Subject > > RE: UML 2.3 Metamodel Publish > > > > Thank you Pete, comments inline. > > Maged Elaasar, PhD Candidate > Senior Software Engineer, Rational Modeling Tools > IBM Representative@OMG, CAS Research Staff Member > IBM Canada, Ottawa Lab, +1 613 270 4651 > > "Pete Rivett" wrote on 09/30/2009 > 06:46:06 PM: > >> There are only 2 diagrams included under Classes::Kernel . am I >> missing something? > > Those are the diagrams that got changed in 2.3. If you remember, we > started off with a 2.2 metamodel that had no diagrams (long story > there) and I stared recreating the diagrams that got changed in 2.3. > Ofcoure, long term I plan to create the remaining diagrams as well > to make the report complete. > >> Would it be possible to have an index of where a class is defined? >> E.g. if I want to find the definition of metaclass X and I don.t >> know what Package it.s defined in. I cannot even seem to do a sea >> rch >> to achieve this e.g. .Class Package. to find the definition (this >> is >> using Foxit not Adobe Reader). Maybe because the class name in its >> definition is a hyperlink . but it just links to itself which seems >> a bit pointless. > > The class name is a link, since it could extend over several pages, > this allows you to go to the first page from any page quickly. Let > me know if this makes sense. And in Acrobat, I could search and find > "Class Package" properly. I will investigate the Index idea, good one. > >> Need to link from an association end to the Association . this is a >> significant omission > > The link is there. It is from the icon beside the association end > that shows the 'aggregation' of the association. The other cross- > arrows icon is to navigate the the association end's 'opposite' > >> · Link from an element to the diagrams it appears in > > Can do this one no prob. > >> · Hyperlinks from shapes on diagrams to their definition > > Easier done in the HTML version, but will see if doable in the PDF one > >> · Searchable diagrams. What format are you using . it se >> ems >> fuzzy so I guess JPG . SVG would be ideal but PNG or GIF would be >> better than JPG for quality if not searchability > > Will try to use SVG instead > >> · more nesting in the contents page e.g. Activities:: >> BasicActivities nested within Activities. And to start off with it >> all collapsed or only one level open. At the moment it.s a pain to >> navigate. > > Will investigate the nesting of packages in the TOC insteadof a flat > structure. About the TOC being collapsed, is this a something that > is generated into the PDF or something I can set after the > production of the PDF? > >> · key for the little symbols shown next to Properties e.g. >> does 2 opposite-facing arrows indicate navigable in both directions? >> I suspect not since /redefinableElement has the symbol. That does >> mean that navigability is not represented anywhere except in the >> diagrams: there is not even a subheading for Navigable Owned End. >> HOWEVER maybe that.s just as well . since in the UML spec >> .navigability. is by convention a means to indicate end ownersh >> ip, >> and this IS correctly represented in the document. > > Yes, I took the showing of the end under the Class/Association as > enough indication of the navigability. BTW, the little arrow-icons > is not meant to indicate navigability, it is just an icon to allow > you to navigate to the 'opposite' end (does not reflect any > semantics). Maybe bad choice of icon? any other suggestion? > >> · Indication of the language used for constraints (i.e. >> Expression::language). > > I can add the language > >> · Hyperlinks in the OCL to definitions for the properties or >> operations used > > Ok, will keep it in mind as a stretch goal :) > >> · The subheading .Association Ends. should really be >> .Owned >> Association Ends. (under both Class and Association). > > Ok, but should it also be 'Owned Attribute' and 'Owned Operaion'..etc? > > > >