Issue 7757: Unconsistent Profile extension description (02) (uml2-rtf) Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr) Nature: Uncategorized Issue Severity: Summary: 18.3.5 says that "A profile by definition extends a reference metamodel or another profile." While in theory I could see how it might be modeled, I don't see how the latter could work in practice with real tools. Let's extend the current example and define a new Profile called ClockTechnology with Stereotype AtomicClock with baseClass Clock and property radioactiveElement:String..." --- Import between profiles is supported, and stereotype generalization is the usual way to achieve what has been called "extending a profile". The reference to profile extension should be simply discarded. A profile extends a reference metamodel. . Discussion In Profiles:Profile:semantics, change the first sentence A profile by definition extends a reference metamodel or another profile. Into A profile by definition extends a reference metamodel. Resolution: Revised Text: Actions taken: September 3, 2004: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: In Profiles:Profile:semantics, change the first sentence A profile by definition extends a reference metamodel or another profile. Into A profile by definition extends a reference metamodel. Here also, the suggested change has been already made. This issue is obsolete (already solved). Disposition: Closed, no change 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 Profile extension description Source: Philippe Desfray Summary: As noticed by Pete Rivett: --- 18.3.5 says that "A profile by definition extends a reference metamodel or another profile." While in theory I could see how it might be modeled, I don't see how the latter could work in practice with real tools. Let's extend the current example and define a new Profile called ClockTechnology with Stereotype AtomicClock with baseClass Clock and property radioactiveElement:String..." --- Import between profiles is supported, and stereotype generalization is the usual way to achieve what has been called "extending a profile". The reference to profile extension should be simply discarded. A profile extends a reference metamodel. . Discussion In Profiles:Profile:semantics, change the first sentence A profile by definition extends a reference metamodel or another profile. Into A profile by definition extends a reference metamodel. Disposition: Resolved Reply-To: From: "Desfray" To: "'Branislav Selic'" Cc: , "'Joaquin Miller'" , "'MOF UML Infrastructure FTF'" , , , "'UML Superstructure FTF'" Subject: RE: Comment on proposed profile resolution Date: Tue, 31 Aug 2004 15:01:53 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-Virus-Scanned: by amavisd-new at softeam.com 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 Date: Tue, 31 Aug 2004 15:20:25 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Philippe.Desfray@softeam.fr CC: "'Branislav Selic'" , cris.kobryn@telelogic.com, "'Joaquin Miller'" , "'MOF UML Infrastructure FTF'" , sanford.friedenthal@lmco.com, sysml@yahoogroups.com, "'UML Superstructure FTF'" Subject: Re: Comment on proposed profile resolution Philippe, I support this focused modification. It re-enables the UML 1.x capabilities of profiles within the new UML 2.0 profile framework. The modifications do not impose meta tool functionality in that the base UML meta model can not be changed in any way. What we are talking about is capabilities for new, ecxtended, elements (stereotypes) to point to eachother and to existing UML meta classes (without changing the UML base metaclass definition, viz a directed association to the metaclass). Without these capabilities, profiles may well end up being too constrained for real world applications. Thanks, Guus Desfray wrote: 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 -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 Issue 7757: Unconsistent Profile extension description (02) Click here for this issue's archive. Source: Softeam (Mr. Philippe Desfray, mailto:%20phd@softeam.fr) Nature: Uncategorized Issue Severity: Summary: 18.3.5 says that "A profile by definition extends a reference metamodel or another profile." While in theory I could see how it might be modeled, I don't see how the latter could work in practice with real tools. Let's extend the current example and define a new Profile called ClockTechnology with Stereotype AtomicClock with baseClass Clock and property radioactiveElement:String..." --- Import between profiles is supported, and stereotype generalization is the usual way to achieve what has been called "extending a profile". The reference to profile extension should be simply discarded. A profile extends a reference metamodel. scussion "In Profiles:Profile:semantics, change the first sentence A profile by definition extends a reference metamodel or another profile. Into A profile by definition extends a reference metamodel. " Here also, the suggested change has been already made. This issue is obsolete (already solved). Resolution: Reject