Issue 7756: Unconsistent association extension description (uml2-rtf) Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr) Nature: Uncategorized Issue Severity: Summary: b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel." I fail to see how a profile could in fact could cause an association between 2 stereotypes to subset an existing association in a reference metamodel since the stereotypes do not at all inherit from the baseClasses so do not inherit any of its properties or associations in order to be able to subset them: this is emphasized by the MOF representation shown in the new Figure 447. --- Indeed profiles do not support association subsetting. This should be made clear in the spec to avoid any confusion while using profiles. . Discussion In Profiles:Profile:semantics, change the paragraph As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel. Into As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass. Resolution: Revised Text: This change needs to be made in both the Infrastructure (ptc/04-11-16) and Superstructure specs (ptc/04-10-02): >>>>> "In Profiles:Profile:semantics, replace the following text: As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass. The effect of new (meta)associations within profiles can be achieved in limited ways either by: 1. adding new constraints within a profile that specialize the usage of some associations of the reference metamodel, or 2. extending the Dependency metaclass by a stereotype and defining specific constraint on this stereotype. As an illustration of the first approach, the examples in Figure 450 and Figure 451 could be extended by adding a “HomeRealization” stereotype that extends the “InterfaceRealization” UML metaclass. The “Bean” stereotype will introduce the constraint that the “interfaceRealization” association can only target “InterfaceRealization” elements extended by a “HomeRealization” stereotype and the “HomeRealization” stereotype will add the constraint that the “contract” association can only target interfaces extended by a “Home” stereotype. As an illustration of second approach, one can define a stereotype “Sclass” extending Class and a stereotype “Sstate” extending State. In order to specify the default state of an “Sclass”, a “DefaultState” stereotype extending “Dependency” can be defined, with the constraints that a DefaultState Dependency can only exist between an Sclass and an Sstate. Into Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass. Actions taken: September 3, 2004: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: End of Annotations:===== eply-To: From: "Desfray" To: "'Branislav Selic'" Cc: , "'Joaquin Miller'" , "'MOF UML Infrastructure FTF'" , , , "'UML Superstructure FTF'" Subject: Profile issue resolution Date: Fri, 3 Sep 2004 11:13:44 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-Virus-Scanned: by amavisd-new at softeam.com In application of the decisions taken by the telecon, 2 issues have been raised (by me), and here come the resolutions. The issue number is not yet allocated, but this "early" resolution gives time to consider it. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Desfray [mailto:Philippe.Desfray@softeam.fr] Envoyé : vendredi 3 septembre 2004 10:34 À : 'Branislav Selic' Cc : 'cris.kobryn@telelogic.com'; 'Joaquin Miller'; 'MOF UML Infrastructure FTF'; 'sanford.friedenthal@lmco.com'; 'sysml@yahoogroups.com'; 'UML Superstructure FTF' Objet : Report of the Telecon on the profile issue Date : Sept 2, 2004 Attendees : Conrad, Jim, Pete, Philippe Subject : During a revision of the SysML proposal, Pete has noticed that SysML where using Profiles features that where not available, and that the Profile specification on Profile extension and on association extension was erroneous. In the current timeframe, this would lead to issues left to the UML2.0 RTF. However, it has been judged urgent to fix this issue, in order to solve the limitation that SysML has encountered. Philippe has proposed a rewriting, allowing to define new association that must originate from stereotypes. Bran has raised serious concerns on the burden that this would put on non metameta existing tools. After a technical discussion on the possible ways to solve the issue, Conrad has clarified that fact that what has been proposed by Philippe does not solve the problem of association definition, as SysML wanted to use it. Indeed, SysML does asociation extension and association end renaming, which dos not correspond to the proposed feature : creating new associations. The result is that an urgent fix is proposed ... that does not solve the problem deemed urgent. Pete indicates that the profile description on this subject has serious ambiguities and inconsistencies, that may let people use improperly profiles, as it ha happened for SysML. It is therefore urgent to fix the text inconsistencies. Regarding the association extention feature, which is in opposition to Bran statement on the profile limitations, Jim reminded that there are indeed only two consistent solutions: 1 Add the association definition mechanism, as proposed by Philippe's issue resolution proposal, OR 2 Withdraw advanced features of profiles : having the capacity to provide complex types to attributes, such as new classes, or metaclasses from the reference metamodel. Indeed these capacities are logically and technically of the same order than adding association originating from stereotypes. It has been decided that this choice cannot be done within a last minute emergency process, because we need the opinion of the F or R task force. The conclusion is therefore : 1 Philippe will send the issue raised by pete 2 Philippe will propose a resolution to solve the inconsistencies noticed by Pete 3 Any other decision about association extension will be differed to the RTF. ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 31 août 2004 23:46 À : Philippe.Desfray@softeam.fr Cc : cris.kobryn@telelogic.com; 'Joaquin Miller'; 'MOF UML Infrastructure FTF'; sanford.friedenthal@lmco.com; sysml@yahoogroups.com; 'UML Superstructure FTF' Objet : RE: Comment on proposed profile resolution Philippe, Since I will be travelling over the next few days, can you please: (a) suggest a time and date for a telecon on this topic within the next few days and (b) organize the telecon based on the responses you get (the OMG can help you with a telecon number if that is a problem). Thanks, Bran "Desfray" 08/31/2004 09:01 AM Please respond to Philippe.Desfray To Branislav Selic/Ottawa/IBM@IBMCA cc , "'Joaquin Miller'" , "'MOF UML Infrastructure FTF'" , , , "'UML Superstructure FTF'" Subject RE: Comment on proposed profile resolution Bran, I understand your concern, but we should maintain a balance between the foundamental reasons why profiles have been defined (recalled now in as requirements in the specification), and what end users are asking for. I agree that the purpose of the profile mechanism is not to cover the facilities provided by MOF. The purpose of profiles is now spelled out in the spec (as a recall of what has been stated in the earlyer working groups on profile UML1.4 ... UML2.0). As Jim noticed it, having the ability to associate a stereotype and a metaclass is the same order as allowing attributes definition (which can be typed by metaclasses) within stereotypes. So this does not introduce anything fundamental more in the spec now. >>> I really see no difference between a meta-association between two metaclasses, such that the association ends are owned by the meta-association, which is not allowed according to your rules, and an association between a stereotype and a meta-class, which is allowed. Very thin difference indeed. The raison I pushed back on this further extension, is that yes profiles capabilities should be focused on a minimal limited set of extension mechanisms, and that we enforce using stereotypes for defining extensions. Stereotype is the hook that one can use to implement profiles without having a metacase tool, although I agree with you that this implementation is a bit more complex with the attribute/association feature. I have not been proactive in extending the Profile features there, but I have to acknowledge Jim's argument (and pete and guus ...) and a request of the sysml users that have been judged important and urgent. What would be the other option? Withdraw some UML2 already specified capacities of profiles (i.e. capacities to type stereotype's attributes with metaclasses and/or complex classes) and not support the request to provide some association definition mechanism. I do not feel that is a path to go. Anyway, I have put on the table a poposal that I felt the safest and most appropriate. I am open to discuss it through a telecon if required. Best regards ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : lundi 30 août 2004 17:45 À : Philippe.Desfray@softeam.fr Cc : cris.kobryn@telelogic.com; 'Joaquin Miller'; 'MOF UML Infrastructure FTF'; sanford.friedenthal@lmco.com; sysml@yahoogroups.com; 'UML Superstructure FTF' Objet : Comment on proposed profile resolution Philippe, I am somewhat concerned about the proposed resolution. As I see it, one of the fundamental criteria for what is allowed in a profile is whether the proposed extension requires that a UML-compliant tool that is NOT a meta-tool can import the model. It strikes me that, as soon as you have the ability to associate a stereotype and a metaclass (regardless of who owns the association ends), a non-meta UML-compliant tool will have problems interpreting this model. If we want to support this, we might as well allow a profile to add meta-associations. Furthermore, if we follow this through to its natural conclusion, we might as well get rid of profiles altogether. I really see no difference between a meta-association between two metaclasses, such that the association ends are owned by the meta-association, which is not allowed according to your rules, and an association between a stereotype and a meta-class, which is allowed. I think we should keep profiles to what they were: simple metaclass specializations, rather than to try to extend them to what MOF is intended to handle. Keeping them simple will cut down on confusion (which do we use: MOF or profiles?) and avoid a slew of technical issues. Regards, Bran Issue -association extension in Profile-resolution.doc Issue -profile extension in Profile-resolution.doc OMG Issue N° XXXX: Title: Unconsistent association extension description Source: Philippe Desfray Summary: As noticed by Pete Rivett: --- b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel." I fail to see how a profile could in fact could cause an association between 2 stereotypes to subset an existing association in a reference metamodel since the stereotypes do not at all inherit from the baseClasses so do not inherit any of its properties or associations in order to be able to subset them: this is emphasized by the MOF representation shown in the new Figure 447. --- Indeed profiles do not support association subsetting. This should be made clear in the spec to avoid any confusion while using profiles. . Discussion In Profiles:Profile:semantics, change the paragraph As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel. Into As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass. Disposition: Resolved Profile - Issue resolution Issue 7756: Unconsistent association extension description Click here for this issue's archive. Source: Softeam (Mr. Philippe Desfray, mailto:%20phd@softeam.fr) Nature: Uncategorized Issue Severity: Summary: b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel." I fail to see how a profile could in fact could cause an association between 2 stereotypes to subset an existing association in a reference metamodel since the stereotypes do not at all inherit from the baseClasses so do not inherit any of its properties or associations in order to be able to subset them: this is emphasized by the MOF representation shown in the new Figure 447. --- Indeed profiles do not support association subsetting. This should be made clear in the spec to avoid any confusion while using profiles. scussion >>>>> "In Profiles:Profile:semantics, change the paragraph As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel. Into As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass" <<<<< Indeed, this change has been already made during FTF. This issue is now obsolete. Resolution: Reject. Subject: RE: Second version of draft 5 ballot Date: Fri, 10 Jun 2005 12:49:21 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Second version of draft 5 ballot Thread-Index: AcVqDi4LnbIGtvCzTnu2ZkZCe2GoggDuTiyQ Priority: Urgent From: "Pete Rivett" To: "Branislav Selic" , X-Virus-Scanned: by amavisd-new at sentraliant.com See below. Quite a few comments but all minor except for issue 8449 which I think should be pulled. 7756 The heading 'Discussion' should be replaced by 'Revised Text'. The issue replaces several paragraphs so instead of "change the paragraph " should say "replace the following text". The corresponding text in Infra also needs updating. 7756: the English for the new text could be improved, and I think 'a usual class' is not clear. Also 'navigable' is used in the old sense not the new sense: I presume the intention is the old sense (that there is a property on the Stereotype) Here is suggested new text (my changes in red) Stereotypes can participate in associations. The opposite class can be another stereotype, a non-Stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass. Issue 8031: I don't think the interaction between Conrad and Bran belongs in the discussion. See my proposed guidance in my vote on Ballot 4 (earlier today). Issue 8117: ditto. Issue 8187, 8239, 8262: Would be better to use the proper syntax to express the 'subsets' Issue 8225, 8262, others: Was it intentional to replace [0..*] by [*]? I thought the preferred style was the former. More generally, we seem to be spending a lot of cycles faffing around with issues related to * and 0..* - do people not realize that they are identical? Issue 8234: ditto Issue 8256: Use of 'at least' implies than more than one instance of stereotype may be attached to a single element. Suggested rewording: "If the extending stereotype has subclasses, then at one instance of the stereotype or one of its subclasses is required." Issue 8301: Should say 'increased clarity' not 'increased clarify'. Issue 8449: As I said in the discussion within the Profiles group I think Image should be a PrimitiveType. Even if Image is an instance of DataType rather than PrimitiveType the proposed resolution does not reflect this and in fact makes no sense as it stands since it is at the wrong metalevel: it would allow a Stereotype to refer, as an image to an actual datatype in the UML metamodel (or a user model) - for example 'Integer' or 'AddressType'! I will follow up with more detailed email but I think this issue must be pulled from ballot for now. Issue 8608: The Revised text says ", replace .intended. by the word .intended." - the first 'intended' should be 'intedded' The disposition should be 'Resolved' not 'closed no change' Issue 8619: I think a portion of the 'Discussion' could be added to clarify the diagram in Appendix F. I propose the following: Revised Text: Add the following to the end of the first (and only) paragraph in Appendix F The .classes. in this diagram that do not have superclasses are actually merge increments. Their superclasses can be inferred from any increment that actually has a superclass. Putting those in the diagram would not add any information but would simply clutter the diagram. Issue 8824: Did we not already address this in Ballot 4 with issue 8349 ( I have not checked the detail though)? Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, 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 -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sunday, June 05, 2005 9:17 PM To: uml2-rtf@omg.org Subject: Second version of draft 5 ballot I am having problems with my mailer that is having trouble sending larger files. It looks like my previous post of the ballot 5 draft did not get through. So, I'm sending this new ZIPPED version (however, to get around the OMG aversion to Zipped files, I have given it a "zap" suffix -- which you should change bck to "zip" when you receive the file.) For those who may have received the original version, this one is different in that it has added Tim Weilkins' fix to issue 8467. Bran