Issue 6453: UML 2.0 Superstructure FTF issue - Profiles (uml2-superstructure-ftf) Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr) Nature: Uncategorized Issue Severity: Summary: In the Profile chapter, there is no section for "Changes from UML 1.4" for stereotypes However, one feature of UML1.4 : attaching tagged values independently of any stereotype, has disappeared in UML2.0 The evolution tagged values --> attribute should be discussed and that particular case enlighted. a specific pattern for converting UML1.4 stereotype independant tags into UML2.0 should be provided. Resolution: see above Revised Text: Actions taken: November 7, 2003: received issue March 8, 2005: closed issue Discussion: In Class description : Stereotype, Notation Add at the end of the paragraph “Presentation option” It is a semantic variation point that a tool can choose to display or not stereotypes. In particular, some tools can choose not to display “required stereotypes”, but to display only their attributes (tagged values) if any. In Class description : Stereotype Add at the end (just before 18.4) the following paragraph Changes from previous UML In UML1.3, tagged values could extend a model element without the required presence of a stereotype. In UML1.4, this capacity, although being still supported, was recommended to use only for backward compatibility reason. In UML2.0, a tagged value can only be represented as an attribute defined on a stereotype. Therefore, a model element must be extended by a stereotype in order to be extended by tagged values. The usage of the “required” extension mechanism can however provide an automated stereotype extension, on which attributes can be valuated. The end user service can therefore be very close to the one provided by UML1.3, depending on tool support of this functionality. End of Annotations:===== eply-To: From: "DESFRAY Philippe" To: "'Juergen Boldt'" Subject: UML 2.0 Superstructure FTF issue - Profiles Date: Fri, 7 Nov 2003 15:02:18 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal Juergen, Shame on me, I did forgot the exact procedure to send issues. I think you are the right person to mail. Here it is : In the Profile chapter, there is no section for "Changes from UML 1.4" for stereotypes However, one feature of UML1.4 : attaching tagged values independently of any stereotype, has disappeared in UML2.0 The evolution tagged values --> attribute should be discussed and that particular case enlighted. a specific pattern for converting UML1.4 stereotype independant tags into UML2.0 should be provided. -- Philippe DESFRAY VP for R& D phd@softeam.fr SOFTEAM - Objecteering Software --------Think Object 144 avenue des Champs Elysées - 75008 PARIS - Tel (33 1) 53968400 - Fax (33 1) 53968401 Get for FREE a highly professional UML case tool at www.objecteering.com see the Unique "Objecteering/UML Requirement analysis" tool, providing extensions to UML for requirement analysis, dictionnary and traceability management. -- -----Message d'origine----- De : Juergen Boldt [mailto:juergen@omg.org] Envoyé : jeudi 6 novembre 2003 20:06 À : issues@omg.org; uml2-superstructure-ftf@omg.org Objet : issue6439 -- UML 2.0 Superstructure FTF issue This is issue # 6439 Jon Siegel UML 2.0 significant typo - collaboration diagram In the UML 2.0 Superstructure final adopted specification document 03-08-02 (and all previous versions), the phrase "collaboration diagram" appears in the last row of Figure 464 on page 590, and in no other place in the entire document. This occurrence probably missed the global change from "collaboration diagram" to "communication diagram". This is a key figure that is likely to be reproduced in many articles and slide sets, and should be fixed. ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org OMG Issue 6453: Title: "Changes from UML 1.4" for stereotypes Source: Softeam (Mr. Philippe Desfray, phd@softeam.fr) Summary: In the Profile chapter, there is no section for "Changes from UML 1.4" for Stereotypes. However, one feature of UML1.4 : attaching tagged values independently of any stereotype, has disappeared in UML2.0. The evolution tagged values --> attribute should be discussed and that particular case enlighted. a specific pattern for converting UML1.4 stereotype independant tags into UML2.0 should be provided. Proposed Resolution Define a pattern providing a solution close to the previous .tagged value. effect. That pattern can be based on the .is required. property of stereotypes, that makes tagged values available without having to .manually. annotate a model. Discussion In Class description : Stereotype Add at the end (just before 18.4) the following paragraph Changes from previous UML Previously, tagged values could extend a model element, without the required presence of a stereotype. In UML2.0, a tagged value is represented as an attribute defined on a stereotype. Therefore, a model element must be extended by a stereotype in order to be extended by tagged values. In order to obtain the same behaviour using UML2.0, the following approach can be used: Define an anonymous Stereotype that extends a metaclass with .isRequired = true.. Then, once the profile is applied to a model, every model element instantiating the metaclass will be extended by the anonymous stereotype, and will therefore allow to provide values for the stereotype.s attributes. The user will notice a similar behaviour than in UML1.4. To: Cc: "'Branislav Selic'" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: [profile] resolution proposals for Ballot 14 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Mon, 3 May 2004 11:36:36 -0600 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/03/2004 11:36:41, Serialize complete at 05/03/2004 11:36:41 Philippe, Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Issue 6453: anonymous stereotypes will be difficult to deal with in diagrams that define the stereotype, or in organizing properties in tools by extensions. How can a profile developer distinguish two different anonymous stereotype vs. the same stereotype extending two different metaclasses, but simply using a different graphic view? Is it really necessary to have the stereotypes be unnamed? Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. Disposition: Resolved To: Cc: "'Branislav Selic'" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: [profile] resolution proposals for Ballot 14 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Kenneth Hussey Date: Mon, 3 May 2004 14:25:58 -0400 X-MIMETrack: Serialize by Router on D25ML06/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/03/2004 14:26:00, Serialize complete at 05/03/2004 14:26:00 Philippe, Issue 6280: Couldn't the icon type be determined from the URI (e.g. file extension)? Also, if we are going to add notation-related information to stereotypes, we should also add a label (display name) attribute. Issue 6453: Wouldn't anonymous (unnamed) stereotypes violate the constraint that named elements within a namespace must be distinguishable? As Jim points out, either we should recommend that required stereotypes not be displayed or provide an additional flag on Stereotype that indicates whether the stereotype should be displayed (i.e. isVisible?). Or, maybe we could use the visibility of the stereotype to indicate whether it should appear (i.e. PUBLIC == visible, otherwise not visible)... Cheers, Kenn Hussey Eclipse UML2 Project Lead Rational Software, IBM Software Group 770 Palladium Drive Kanata, Ontario, K2V 1C8 T: (613) 599-3980 F: (613) 599-3912 "DESFRAY Philippe" 05/03/2004 05:09 AM Please respond to philippe.desfray To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject [profile] resolution proposals for Ballot 14 -- Philippe [attachment "ProfileResolutionBallot14.doc" deleted by Kenneth Hussey/Ottawa/IBM] Reply-To: From: "Desfray" To: "'Jim Amsden'" Cc: "'Branislav Selic'" , , , Subject: RE: [profile] resolution proposals for Ballot 14 Date: Tue, 4 May 2004 10:48:10 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Jim, Thanks for the feedbacks >>> Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Agreed. One could even say one for the "large icon" in diagrams, one for the "small icon" in diagrams, and one for the explorer. Can we say that "small diagram icon = explorer icon", or shall we define 3 icons? >>>> Issue 6453: I was expecting that kind of feedback. Within a NameSpace (a profile) there is a constraint: All the members of a Namespace are distinguishable within it. membersAreDistinguishable() Which means that two members cannot have the same name, or that two anonymous members cannot exist (I beleive). >>>Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. ??? I am not sure to understand this. Yes required stereotypes cannot be applied by users. should we spell that out? >>> Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? I do not beleive so. required stereotypes are effectively applied stereotypes. >>> Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. That is an interesting alternative to the one I am proposing. This requires that these stereotypes extend only one metaclass (but that was the case in UML1.4). The rule would be : a required stereotype is not shown in the list of applied stereotypes when it has the same name as its (single) extended metaclass. I am in favor of this last proposal. Any objection? -----Message d'origine----- De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : lundi 3 mai 2004 19:37 À : philippe.desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Issue 6453: anonymous stereotypes will be difficult to deal with in diagrams that define the stereotype, or in organizing properties in tools by extensions. How can a profile developer distinguish two different anonymous stereotype vs. the same stereotype extending two different metaclasses, but simply using a different graphic view? Is it really necessary to have the stereotypes be unnamed? Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. To: Cc: "'Branislav Selic'" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 4 May 2004 08:51:09 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/04/2004 06:51:10, Serialize complete at 05/04/2004 06:51:10 I'll put my responses in tags below. Hope its readable. "Desfray" 05/04/2004 04:48 AM Please respond to Philippe.Desfray To Jim Amsden/Raleigh/IBM@IBMUS cc "'Branislav Selic'" , , , Subject RE: [profile] resolution proposals for Ballot 14 Jim, Thanks for the feedbacks >>> Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Agreed. One could even say one for the "large icon" in diagrams, one for the "small icon" in diagrams, and one for the explorer. Can we say that "small diagram icon = explorer icon", or shall we define 3 icons? Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Maybe we need to introduce an Icon metaclass and have a [0..*] association between Stereotype and Icon. Icon could then have the two properties - URI and MIME type. Different stereotypes of Icon could be used by tools to extend their roles. >>>> Issue 6453: I was expecting that kind of feedback. Within a NameSpace (a profile) there is a constraint: All the members of a Namespace are distinguishable within it. membersAreDistinguishable() Which means that two members cannot have the same name, or that two anonymous members cannot exist (I beleive). Then your proposal could work could it? You'd only be able to have one required stereotype with an anonymous name in a profile? >>>Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. ??? I am not sure to understand this. Yes required stereotypes cannot be applied by users. should we spell that out? A required stereotype is automatically applied by metamodel definition, and can never be manually applied. I'm simply proposing that this be made clear in the spec, and we recommend that only stereotypes applied by the developer are shown in the stereotype list e.e.g, <>, >>> Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? I do not beleive so. required stereotypes are effectively applied stereotypes. Yes, but we can leverage the fact that they can't be applied by users to simulate the tagged value sets in UML 1.x >>> Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. That is an interesting alternative to the one I am proposing. This requires that these stereotypes extend only one metaclass (but that was the case in UML1.4). The rule would be : a required stereotype is not shown in the list of applied stereotypes when it has the same name as its (single) extended metaclass. I am in favor of this last proposal. Any objection? I don't think we should restrict stereotypes to extend one metaclass. Some stereotypes will want to extend Class and Component for example. Instead the rule could be the stereotype is not displayed if it is required and its name matches any of the exdended metaclasses. Another possibility is to make the display of a stereotype optional in all cases, and let tools provide users with display options so they can show what's interesting to them. Then we keep this as a view issue, not a metamodel issue. -----Message d'origine----- De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : lundi 3 mai 2004 19:37 À : philippe.desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Issue 6453: anonymous stereotypes will be difficult to deal with in diagrams that define the stereotype, or in organizing properties in tools by extensions. How can a profile developer distinguish two different anonymous stereotype vs. the same stereotype extending two different metaclasses, but simply using a different graphic view? Is it really necessary to have the stereotypes be unnamed? Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. Subject: RE: [profile] resolution proposals for Ballot 14 Date: Tue, 4 May 2004 10:32:30 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [profile] resolution proposals for Ballot 14 Thread-Index: AcQx162rXNJkBppqTKuFejAKJ84YUgAAs4pw From: "Pete Rivett" To: "Jim Amsden" , Cc: "Branislav Selic" , , , , 6280 Any proposal for images must be consistent with the mechanism in Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? I have added DI to the list for this issue. Even for DI, I have a concern with use of URI in terms of how they are resolved. Also it implies we need to have a predefined set of URIs for standardized UML2 images (e.g. stickman). However if Profiles makes use of the DI class it will not need to change if and when the DI spec changes. We should not hard-code into the spec particular uses of images: in particular since the UML spec says nothing about a diagram type called 'explorer' nor does it require tools to offer browsing. Given that most UML tools offer a zooming capability so need to scale images anyway then why not rely on them to scale images for explorer views if needed? And they'd also need to scale for showing in a box as opposed to replacing the box. I would encourage vendors to use SVG for images since that inherently does support smooth scaling and provides the capabilty to define the image in a non-binary format. The resolution does not address all the diagram types where stereotyped model elements may appear e.g. on a sequence diagram or activity diagram where the situation is more complicated than just 'boxes' and 'links' (e.g. a stereotyped lifeline, a stereotyped activity flow). It may be useful to use the language of the DI spec which has more generic terms (edge and node). A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Do we need a constraint that no stereotype names should clash with keyword names? BTW in the issue resolution the last 2 lines of the main paragraph under Icon presentation don't seem to have been completed: " Links, the icon can be presented close to the link textual notation, the icon can be presented on the left of the textual notation." ----- 6543 It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. Note that at UML 1.4 and UML 1.5 non-stereotyped tags are clearly deprecated it's not really a 'feature' of UML 1.4 as claimed in the issue: "Tag definitions should be defined in conjunction with a stereotype since that allows them to be used in a more disciplined manner (stereotypes are constrained by the semantics of their base class). However, primarily for reasons of compatibility with models defined on the basis of UML 1.3, it is still possible to have tag definitions that are not associated with any stereotype." However, as some people are aware, MOF 2 has its own simple tag model which is inconsistent with profiles. It would be helpful if it could be re-framed in terms of a profile: that is a practical use case for the issue. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, May 04, 2004 5:51 AM To: Philippe.Desfray@softeam.fr Cc: 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 I'll put my responses in tags below. Hope its readable. "Desfray" 05/04/2004 04:48 AM Please respond to Philippe.Desfray To Jim Amsden/Raleigh/IBM@IBMUS cc "'Branislav Selic'" , , , Subject RE: [profile] resolution proposals for Ballot 14 Jim, Thanks for the feedbacks >>> Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Agreed. One could even say one for the "large icon" in diagrams, one for the "small icon" in diagrams, and one for the explorer. Can we say that "small diagram icon = explorer icon", or shall we define 3 icons? Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Maybe we need to introduce an Icon metaclass and have a [0..*] association between Stereotype and Icon. Icon could then have the two properties - URI and MIME type. Different stereotypes of Icon could be used by tools to extend their roles. >>>> Issue 6453: I was expecting that kind of feedback. Within a NameSpace (a profile) there is a constraint: All the members of a Namespace are distinguishable within it. membersAreDistinguishable() Which means that two members cannot have the same name, or that two anonymous members cannot exist (I beleive). Then your proposal could work could it? You'd only be able to have one required stereotype with an anonymous name in a profile? >>>Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. ??? I am not sure to understand this. Yes required stereotypes cannot be applied by users. should we spell that out? A required stereotype is automatically applied by metamodel definition, and can never be manually applied. I'm simply proposing that this be made clear in the spec, and we recommend that only stereotypes applied by the developer are shown in the stereotype list e.e.g, <>, >>> Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? I do not beleive so. required stereotypes are effectively applied stereotypes. Yes, but we can leverage the fact that they can't be applied by users to simulate the tagged value sets in UML 1.x >>> Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. That is an interesting alternative to the one I am proposing. This requires that these stereotypes extend only one metaclass (but that was the case in UML1.4). The rule would be : a required stereotype is not shown in the list of applied stereotypes when it has the same name as its (single) extended metaclass. I am in favor of this last proposal. Any objection? I don't think we should restrict stereotypes to extend one metaclass. Some stereotypes will want to extend Class and Component for example. Instead the rule could be the stereotype is not displayed if it is required and its name matches any of the exdended metaclasses. Another possibility is to make the display of a stereotype optional in all cases, and let tools provide users with display options so they can show what's interesting to them. Then we keep this as a view issue, not a metamodel issue. -----Message d'origine----- De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : lundi 3 mai 2004 19:37 À : philippe.desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Issue 6453: anonymous stereotypes will be difficult to deal with in diagrams that define the stereotype, or in organizing properties in tools by extensions. How can a profile developer distinguish two different anonymous stereotype vs. the same stereotype extending two different metaclasses, but simply using a different graphic view? Is it really necessary to have the stereotypes be unnamed? Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. Reply-To: From: "Desfray" To: "'Pete Rivett'" , "'Jim Amsden'" Cc: "'Branislav Selic'" , , , , Subject: RE: [profile] resolution proposals for Ballot 14 Date: Tue, 4 May 2004 17:24:37 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A8046AB000 Thanks for the sounded feedbacks. They reveal that lots of issues were hidden behind that "icon issue" Some synthesis proposal, and questions: (JRA)Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Me too, and Pete also. So let us stay on one icon definition. (Pete) Any proposal for images must be consistent with the mechanism in Diagram Interchange Agreed (Pete) Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? Agreed, but the class definition should move from DI to infrastructure, in order to have a shared accessibility. Shall I propose that? And (Pete) It may be useful to use the language of the DI spec which has more generic terms (edge and node). OK (Pete) A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). The usual practice is indeed to replace the image by the stereotype's icon. I propose to spell that out. (pete) A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Good point, I propose to choose <><> in that case. (pete) Do we need a constraint that no stereotype names should clash with keyword names? That sounds like good common sense. (pete) It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. that's Jim's point also. We will leave that as a variation point. -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 4 mai 2004 16:33 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : Branislav Selic; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org; uml2di-ftf@omg.org Objet : RE: [profile] resolution proposals for Ballot 14 6280 Any proposal for images must be consistent with the mechanism in Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? I have added DI to the list for this issue. Even for DI, I have a concern with use of URI in terms of how they are resolved. Also it implies we need to have a predefined set of URIs for standardized UML2 images (e.g. stickman). However if Profiles makes use of the DI class it will not need to change if and when the DI spec changes. We should not hard-code into the spec particular uses of images: in particular since the UML spec says nothing about a diagram type called 'explorer' nor does it require tools to offer browsing. Given that most UML tools offer a zooming capability so need to scale images anyway then why not rely on them to scale images for explorer views if needed? And they'd also need to scale for showing in a box as opposed to replacing the box. I would encourage vendors to use SVG for images since that inherently does support smooth scaling and provides the capabilty to define the image in a non-binary format. The resolution does not address all the diagram types where stereotyped model elements may appear e.g. on a sequence diagram or activity diagram where the situation is more complicated than just 'boxes' and 'links' (e.g. a stereotyped lifeline, a stereotyped activity flow). It may be useful to use the language of the DI spec which has more generic terms (edge and node). A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Do we need a constraint that no stereotype names should clash with keyword names? BTW in the issue resolution the last 2 lines of the main paragraph under Icon presentation don't seem to have been completed: " Links, the icon can be presented close to the link textual notation, the icon can be presented on the left of the textual notation." ----- 6543 It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. Note that at UML 1.4 and UML 1.5 non-stereotyped tags are clearly deprecated it's not really a 'feature' of UML 1.4 as claimed in the issue: "Tag definitions should be defined in conjunction with a stereotype since that allows them to be used in a more disciplined manner (stereotypes are constrained by the semantics of their base class). However, primarily for reasons of compatibility with models defined on the basis of UML 1.3, it is still possible to have tag definitions that are not associated with any stereotype." However, as some people are aware, MOF 2 has its own simple tag model which is inconsistent with profiles. It would be helpful if it could be re-framed in terms of a profile: that is a practical use case for the issue. Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) Consulting Architect, 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: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, May 04, 2004 5:51 AM To: Philippe.Desfray@softeam.fr Cc: 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 I'll put my responses in tags below. Hope its readable. "Desfray" 05/04/2004 04:48 AM Please respond to Philippe.Desfray To Jim Amsden/Raleigh/IBM@IBMUS cc "'Branislav Selic'" , , , Subject RE: [profile] resolution proposals for Ballot 14 Jim, Thanks for the feedbacks >>> Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Agreed. One could even say one for the "large icon" in diagrams, one for the "small icon" in diagrams, and one for the explorer. Can we say that "small diagram icon = explorer icon", or shall we define 3 icons? Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Maybe we need to introduce an Icon metaclass and have a [0..*] association between Stereotype and Icon. Icon could then have the two properties - URI and MIME type. Different stereotypes of Icon could be used by tools to extend their roles. >>>> Issue 6453: I was expecting that kind of feedback. Within a NameSpace (a profile) there is a constraint: All the members of a Namespace are distinguishable within it. membersAreDistinguishable() Which means that two members cannot have the same name, or that two anonymous members cannot exist (I beleive). Then your proposal could work could it? You'd only be able to have one required stereotype with an anonymous name in a profile? >>>Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. ??? I am not sure to understand this. Yes required stereotypes cannot be applied by users. should we spell that out? A required stereotype is automatically applied by metamodel definition, and can never be manually applied. I'm simply proposing that this be made clear in the spec, and we recommend that only stereotypes applied by the developer are shown in the stereotype list e.e.g, <>, >>> Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? I do not beleive so. required stereotypes are effectively applied stereotypes. Yes, but we can leverage the fact that they can't be applied by users to simulate the tagged value sets in UML 1.x >>> Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. That is an interesting alternative to the one I am proposing. This requires that these stereotypes extend only one metaclass (but that was the case in UML1.4). The rule would be : a required stereotype is not shown in the list of applied stereotypes when it has the same name as its (single) extended metaclass. I am in favor of this last proposal. Any objection? I don't think we should restrict stereotypes to extend one metaclass. Some stereotypes will want to extend Class and Component for example. Instead the rule could be the stereotype is not displayed if it is required and its name matches any of the exdended metaclasses. Another possibility is to make the display of a stereotype optional in all cases, and let tools provide users with display options so they can show what's interesting to them. Then we keep this as a view issue, not a metamodel issue. -----Message d'origine----- De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : lundi 3 mai 2004 19:37 À : philippe.desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Issue 6453: anonymous stereotypes will be difficult to deal with in diagrams that define the stereotype, or in organizing properties in tools by extensions. How can a profile developer distinguish two different anonymous stereotype vs. the same stereotype extending two different metaclasses, but simply using a different graphic view? Is it really necessary to have the stereotypes be unnamed? Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. Reply-To: From: "Desfray" To: "'Pete Rivett'" , "'Jim Amsden'" Cc: "'Branislav Selic'" , , , , Subject: RE: [profile] resolution proposals for Ballot 14 Date: Tue, 4 May 2004 17:24:37 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A8046AB000 Thanks for the sounded feedbacks. They reveal that lots of issues were hidden behind that "icon issue" Some synthesis proposal, and questions: (JRA)Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Me too, and Pete also. So let us stay on one icon definition. (Pete) Any proposal for images must be consistent with the mechanism in Diagram Interchange Agreed (Pete) Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? Agreed, but the class definition should move from DI to infrastructure, in order to have a shared accessibility. Shall I propose that? And (Pete) It may be useful to use the language of the DI spec which has more generic terms (edge and node). OK (Pete) A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). The usual practice is indeed to replace the image by the stereotype's icon. I propose to spell that out. (pete) A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Good point, I propose to choose <><> in that case. (pete) Do we need a constraint that no stereotype names should clash with keyword names? That sounds like good common sense. (pete) It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. that's Jim's point also. We will leave that as a variation point. -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 4 mai 2004 16:33 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : Branislav Selic; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org; uml2di-ftf@omg.org Objet : RE: [profile] resolution proposals for Ballot 14 6280 Any proposal for images must be consistent with the mechanism in Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? I have added DI to the list for this issue. Even for DI, I have a concern with use of URI in terms of how they are resolved. Also it implies we need to have a predefined set of URIs for standardized UML2 images (e.g. stickman). However if Profiles makes use of the DI class it will not need to change if and when the DI spec changes. We should not hard-code into the spec particular uses of images: in particular since the UML spec says nothing about a diagram type called 'explorer' nor does it require tools to offer browsing. Given that most UML tools offer a zooming capability so need to scale images anyway then why not rely on them to scale images for explorer views if needed? And they'd also need to scale for showing in a box as opposed to replacing the box. I would encourage vendors to use SVG for images since that inherently does support smooth scaling and provides the capabilty to define the image in a non-binary format. The resolution does not address all the diagram types where stereotyped model elements may appear e.g. on a sequence diagram or activity diagram where the situation is more complicated than just 'boxes' and 'links' (e.g. a stereotyped lifeline, a stereotyped activity flow). It may be useful to use the language of the DI spec which has more generic terms (edge and node). A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Do we need a constraint that no stereotype names should clash with keyword names? BTW in the issue resolution the last 2 lines of the main paragraph under Icon presentation don't seem to have been completed: " Links, the icon can be presented close to the link textual notation, the icon can be presented on the left of the textual notation." ----- 6543 It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. Note that at UML 1.4 and UML 1.5 non-stereotyped tags are clearly deprecated it's not really a 'feature' of UML 1.4 as claimed in the issue: "Tag definitions should be defined in conjunction with a stereotype since that allows them to be used in a more disciplined manner (stereotypes are constrained by the semantics of their base class). However, primarily for reasons of compatibility with models defined on the basis of UML 1.3, it is still possible to have tag definitions that are not associated with any stereotype." However, as some people are aware, MOF 2 has its own simple tag model which is inconsistent with profiles. It would be helpful if it could be re-framed in terms of a profile: that is a practical use case for the issue. Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) Consulting Architect, 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: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, May 04, 2004 5:51 AM To: Philippe.Desfray@softeam.fr Cc: 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 I'll put my responses in tags below. Hope its readable. "Desfray" 05/04/2004 04:48 AM Please respond to Philippe.Desfray To Jim Amsden/Raleigh/IBM@IBMUS cc "'Branislav Selic'" , , , Subject RE: [profile] resolution proposals for Ballot 14 Jim, Thanks for the feedbacks >>> Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Agreed. One could even say one for the "large icon" in diagrams, one for the "small icon" in diagrams, and one for the explorer. Can we say that "small diagram icon = explorer icon", or shall we define 3 icons? Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Maybe we need to introduce an Icon metaclass and have a [0..*] association between Stereotype and Icon. Icon could then have the two properties - URI and MIME type. Different stereotypes of Icon could be used by tools to extend their roles. >>>> Issue 6453: I was expecting that kind of feedback. Within a NameSpace (a profile) there is a constraint: All the members of a Namespace are distinguishable within it. membersAreDistinguishable() Which means that two members cannot have the same name, or that two anonymous members cannot exist (I beleive). Then your proposal could work could it? You'd only be able to have one required stereotype with an anonymous name in a profile? >>>Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. ??? I am not sure to understand this. Yes required stereotypes cannot be applied by users. should we spell that out? A required stereotype is automatically applied by metamodel definition, and can never be manually applied. I'm simply proposing that this be made clear in the spec, and we recommend that only stereotypes applied by the developer are shown in the stereotype list e.e.g, <>, >>> Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? I do not beleive so. required stereotypes are effectively applied stereotypes. Yes, but we can leverage the fact that they can't be applied by users to simulate the tagged value sets in UML 1.x >>> Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. That is an interesting alternative to the one I am proposing. This requires that these stereotypes extend only one metaclass (but that was the case in UML1.4). The rule would be : a required stereotype is not shown in the list of applied stereotypes when it has the same name as its (single) extended metaclass. I am in favor of this last proposal. Any objection? I don't think we should restrict stereotypes to extend one metaclass. Some stereotypes will want to extend Class and Component for example. Instead the rule could be the stereotype is not displayed if it is required and its name matches any of the exdended metaclasses. Another possibility is to make the display of a stereotype optional in all cases, and let tools provide users with display options so they can show what's interesting to them. Then we keep this as a view issue, not a metamodel issue. -----Message d'origine----- De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : lundi 3 mai 2004 19:37 À : philippe.desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Issue 6453: anonymous stereotypes will be difficult to deal with in diagrams that define the stereotype, or in organizing properties in tools by extensions. How can a profile developer distinguish two different anonymous stereotype vs. the same stereotype extending two different metaclasses, but simply using a different graphic view? Is it really necessary to have the stereotypes be unnamed? Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. From: Randall Hauch To: "'Philippe.Desfray@softeam.fr'" , "'Pete Rivett'" , "'Jim Amsden'" Cc: "'Branislav Selic'" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org, uml2di-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 Date: Tue, 4 May 2004 10:45:20 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) I'd rather not complicate the issue, but has anyone considered that many applications use icons of different sizes (resolutions). Perhaps that is intentionally out of scope? Randall -------------------------------------------------------------------------------- From: Desfray [mailto:Philippe.Desfray@softeam.fr] Sent: Tuesday, May 04, 2004 10:25 AM To: 'Pete Rivett'; 'Jim Amsden' Cc: 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org; uml2di-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 Thanks for the sounded feedbacks. They reveal that lots of issues were hidden behind that "icon issue" Some synthesis proposal, and questions: (JRA)Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Me too, and Pete also. So let us stay on one icon definition. (Pete) Any proposal for images must be consistent with the mechanism in Diagram Interchange Agreed (Pete) Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? Agreed, but the class definition should move from DI to infrastructure, in order to have a shared accessibility. Shall I propose that? And (Pete) It may be useful to use the language of the DI spec which has more generic terms (edge and node). OK (Pete) A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). The usual practice is indeed to replace the image by the stereotype's icon. I propose to spell that out. (pete) A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Good point, I propose to choose <><> in that case. (pete) Do we need a constraint that no stereotype names should clash with keyword names? That sounds like good common sense. (pete) It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. that's Jim's point also. We will leave that as a variation point. -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 4 mai 2004 16:33 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : Branislav Selic; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org; uml2di-ftf@omg.org Objet : RE: [profile] resolution proposals for Ballot 14 6280 Any proposal for images must be consistent with the mechanism in Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? I have added DI to the list for this issue. Even for DI, I have a concern with use of URI in terms of how they are resolved. Also it implies we need to have a predefined set of URIs for standardized UML2 images (e.g. stickman). However if Profiles makes use of the DI class it will not need to change if and when the DI spec changes. We should not hard-code into the spec particular uses of images: in particular since the UML spec says nothing about a diagram type called 'explorer' nor does it require tools to offer browsing. Given that most UML tools offer a zooming capability so need to scale images anyway then why not rely on them to scale images for explorer views if needed? And they'd also need to scale for showing in a box as opposed to replacing the box. I would encourage vendors to use SVG for images since that inherently does support smooth scaling and provides the capabilty to define the image in a non-binary format. The resolution does not address all the diagram types where stereotyped model elements may appear e.g. on a sequence diagram or activity diagram where the situation is more complicated than just 'boxes' and 'links' (e.g. a stereotyped lifeline, a stereotyped activity flow). It may be useful to use the language of the DI spec which has more generic terms (edge and node). A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Do we need a constraint that no stereotype names should clash with keyword names? BTW in the issue resolution the last 2 lines of the main paragraph under Icon presentation don't seem to have been completed: " Links, the icon can be presented close to the link textual notation, the icon can be presented on the left of the textual notation." ----- 6543 It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. Note that at UML 1.4 and UML 1.5 non-stereotyped tags are clearly deprecated it's not really a 'feature' of UML 1.4 as claimed in the issue: "Tag definitions should be defined in conjunction with a stereotype since that allows them to be used in a more disciplined manner (stereotypes are constrained by the semantics of their base class). However, primarily for reasons of compatibility with models defined on the basis of UML 1.3, it is still possible to have tag definitions that are not associated with any stereotype." However, as some people are aware, MOF 2 has its own simple tag model which is inconsistent with profiles. It would be helpful if it could be re-framed in terms of a profile: that is a practical use case for the issue. Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, 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: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, May 04, 2004 5:51 AM To: Philippe.Desfray@softeam.fr Cc: 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 I'll put my responses in tags below. Hope its readable. "Desfray" 05/04/2004 04:48 AM Please respond to Philippe.Desfray To Jim Amsden/Raleigh/IBM@IBMUS cc "'Branislav Selic'" , , , Subject RE: [profile] resolution proposals for Ballot 14 Jim, Thanks for the feedbacks >>> Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Agreed. One could even say one for the "large icon" in diagrams, one for the "small icon" in diagrams, and one for the explorer. Can we say that "small diagram icon = explorer icon", or shall we define 3 icons? Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Maybe we need to introduce an Icon metaclass and have a [0..*] association between Stereotype and Icon. Icon could then have the two properties - URI and MIME type. Different stereotypes of Icon could be used by tools to extend their roles. >>>> Issue 6453: I was expecting that kind of feedback. Within a NameSpace (a profile) there is a constraint: All the members of a Namespace are distinguishable within it. membersAreDistinguishable() Which means that two members cannot have the same name, or that two anonymous members cannot exist (I beleive). Then your proposal could work could it? You'd only be able to have one required stereotype with an anonymous name in a profile? >>>Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. ??? I am not sure to understand this. Yes required stereotypes cannot be applied by users. should we spell that out? A required stereotype is automatically applied by metamodel definition, and can never be manually applied. I'm simply proposing that this be made clear in the spec, and we recommend that only stereotypes applied by the developer are shown in the stereotype list e.e.g, <>, >>> Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? I do not beleive so. required stereotypes are effectively applied stereotypes. Yes, but we can leverage the fact that they can't be applied by users to simulate the tagged value sets in UML 1.x >>> Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. That is an interesting alternative to the one I am proposing. This requires that these stereotypes extend only one metaclass (but that was the case in UML1.4). The rule would be : a required stereotype is not shown in the list of applied stereotypes when it has the same name as its (single) extended metaclass. I am in favor of this last proposal. Any objection? I don't think we should restrict stereotypes to extend one metaclass. Some stereotypes will want to extend Class and Component for example. Instead the rule could be the stereotype is not displayed if it is required and its name matches any of the exdended metaclasses. Another possibility is to make the display of a stereotype optional in all cases, and let tools provide users with display options so they can show what's interesting to them. Then we keep this as a view issue, not a metamodel issue. -----Message d'origine----- De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : lundi 3 mai 2004 19:37 À : philippe.desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Issue 6453: anonymous stereotypes will be difficult to deal with in diagrams that define the stereotype, or in organizing properties in tools by extensions. How can a profile developer distinguish two different anonymous stereotype vs. the same stereotype extending two different metaclasses, but simply using a different graphic view? Is it really necessary to have the stereotypes be unnamed? Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. To: Cc: "'Branislav Selic'" , mu2i-ftf@omg.org, ocl2-ftf@omg.org, "'Pete Rivett'" , uml2-superstructure-ftf@omg.org, uml2di-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 4 May 2004 12:57:59 -0600 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/04/2004 12:58:02 Philippe: If we move Image to Infra, then there's no reason why the Stereotype cann't have a [0..*] association with Image to support more than one icon. Tools can use stereotypes of Image to indicate what the icon is for. I belive the notation for UML1.4 was <>, not <><>. The former takes less room on the diagram too. Unfortunately we're mixing stereotypes and keywords in the notation. In many instances, the keywords are just the notation for expressing some metamodel element, in others they are standard stereotypes. This could lead to confusion and problems in defining profiles. Another potential issue is that multiple applied profiles can use the same stereotype names as they are in different packages. This means that the stereotype keywords may need to be able to be qualified as in <> vs. <>. "Desfray" 05/04/2004 11:24 AM Please respond to Philippe.Desfray To "'Pete Rivett'" , Jim Amsden/Raleigh/IBM@IBMUS cc "'Branislav Selic'" , , , , Subject RE: [profile] resolution proposals for Ballot 14 Thanks for the sounded feedbacks. They reveal that lots of issues were hidden behind that "icon issue" Some synthesis proposal, and questions: (JRA)Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Me too, and Pete also. So let us stay on one icon definition. (Pete) Any proposal for images must be consistent with the mechanism in Diagram Interchange Agreed (Pete) Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? Agreed, but the class definition should move from DI to infrastructure, in order to have a shared accessibility. Shall I propose that? And (Pete) It may be useful to use the language of the DI spec which has more generic terms (edge and node). OK (Pete) A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). The usual practice is indeed to replace the image by the stereotype's icon. I propose to spell that out. (pete) A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Good point, I propose to choose <><> in that case. (pete) Do we need a constraint that no stereotype names should clash with keyword names? That sounds like good common sense. (pete) It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. that's Jim's point also. We will leave that as a variation point. -----Message d'origine----- De : Pete Rivett [mailto:pete.rivett@adaptive.com] Envoyé : mardi 4 mai 2004 16:33 À : Jim Amsden; Philippe.Desfray@softeam.fr Cc : Branislav Selic; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org; uml2di-ftf@omg.org Objet : RE: [profile] resolution proposals for Ballot 14 6280 Any proposal for images must be consistent with the mechanism in Diagram Interchange, which has a class called Image (with uri and mimeType attributes): why not make direct use of that class? I have added DI to the list for this issue. Even for DI, I have a concern with use of URI in terms of how they are resolved. Also it implies we need to have a predefined set of URIs for standardized UML2 images (e.g. stickman). However if Profiles makes use of the DI class it will not need to change if and when the DI spec changes. We should not hard-code into the spec particular uses of images: in particular since the UML spec says nothing about a diagram type called 'explorer' nor does it require tools to offer browsing. Given that most UML tools offer a zooming capability so need to scale images anyway then why not rely on them to scale images for explorer views if needed? And they'd also need to scale for showing in a box as opposed to replacing the box. I would encourage vendors to use SVG for images since that inherently does support smooth scaling and provides the capabilty to define the image in a non-binary format. The resolution does not address all the diagram types where stereotyped model elements may appear e.g. on a sequence diagram or activity diagram where the situation is more complicated than just 'boxes' and 'links' (e.g. a stereotyped lifeline, a stereotyped activity flow). It may be useful to use the language of the DI spec which has more generic terms (edge and node). A further complication is where the UML spec already allows an image to be used e.g. for Actor: what is the impact of adding a stereotype to an actor? Does that rule out the use of the stick man image (except in a box) in the same way that an image cannot be used if more than one stereotype is applied? Or does it just replace the stick man? (This may sound a bit obscure but is a common case - people often dislike the use of a stick man when the actor is an external system so use a <> stereotype). A further presentation issue with stereotypes is the combination of a keyword (as defined in the spec) with a stereotype. Keywords are shown in guillemets too: the question is are they combined or separate? So if the stereotype Java is applied to a DataType would we see <><> or <>. In either case does the ordering matter (keyword first?). Do we need a constraint that no stereotype names should clash with keyword names? BTW in the issue resolution the last 2 lines of the main paragraph under Icon presentation don't seem to have been completed: " Links, the icon can be presented close to the link textual notation, the icon can be presented on the left of the textual notation." ----- 6543 It does not seem right to insist on hiding the application of stereotypes: I agree it should be a view issue and the option to do this should be a variation point in the spec. Note that at UML 1.4 and UML 1.5 non-stereotyped tags are clearly deprecated it's not really a 'feature' of UML 1.4 as claimed in the issue: "Tag definitions should be defined in conjunction with a stereotype since that allows them to be used in a more disciplined manner (stereotypes are constrained by the semantics of their base class). However, primarily for reasons of compatibility with models defined on the basis of UML 1.3, it is still possible to have tag definitions that are not associated with any stereotype." However, as some people are aware, MOF 2 has its own simple tag model which is inconsistent with profiles. It would be helpful if it could be re-framed in terms of a profile: that is a practical use case for the issue. Pete Pete Rivett ( mailto:pete.rivett@adaptive.com ) Consulting Architect, 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: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, May 04, 2004 5:51 AM To: Philippe.Desfray@softeam.fr Cc: 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: [profile] resolution proposals for Ballot 14 I'll put my responses in tags below. Hope its readable. "Desfray" 05/04/2004 04:48 AM Please respond to Philippe.Desfray To Jim Amsden/Raleigh/IBM@IBMUS cc "'Branislav Selic'" , , , Subject RE: [profile] resolution proposals for Ballot 14 Jim, Thanks for the feedbacks >>> Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Agreed. One could even say one for the "large icon" in diagrams, one for the "small icon" in diagrams, and one for the explorer. Can we say that "small diagram icon = explorer icon", or shall we define 3 icons? Well this is surely indicating tool and notation requirements creeping into the metamodel. This makes me nervous. Maybe we need to introduce an Icon metaclass and have a [0..*] association between Stereotype and Icon. Icon could then have the two properties - URI and MIME type. Different stereotypes of Icon could be used by tools to extend their roles. >>>> Issue 6453: I was expecting that kind of feedback. Within a NameSpace (a profile) there is a constraint: All the members of a Namespace are distinguishable within it. membersAreDistinguishable() Which means that two members cannot have the same name, or that two anonymous members cannot exist (I beleive). Then your proposal could work could it? You'd only be able to have one required stereotype with an anonymous name in a profile? >>>Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. ??? I am not sure to understand this. Yes required stereotypes cannot be applied by users. should we spell that out? A required stereotype is automatically applied by metamodel definition, and can never be manually applied. I'm simply proposing that this be made clear in the spec, and we recommend that only stereotypes applied by the developer are shown in the stereotype list e.e.g, <>, >>> Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? I do not beleive so. required stereotypes are effectively applied stereotypes. Yes, but we can leverage the fact that they can't be applied by users to simulate the tagged value sets in UML 1.x >>> Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. That is an interesting alternative to the one I am proposing. This requires that these stereotypes extend only one metaclass (but that was the case in UML1.4). The rule would be : a required stereotype is not shown in the list of applied stereotypes when it has the same name as its (single) extended metaclass. I am in favor of this last proposal. Any objection? I don't think we should restrict stereotypes to extend one metaclass. Some stereotypes will want to extend Class and Component for example. Instead the rule could be the stereotype is not displayed if it is required and its name matches any of the exdended metaclasses. Another possibility is to make the display of a stereotype optional in all cases, and let tools provide users with display options so they can show what's interesting to them. Then we keep this as a view issue, not a metamodel issue. -----Message d'origine----- De : Jim Amsden [mailto:jamsden@us.ibm.com] Envoyé : lundi 3 mai 2004 19:37 À : philippe.desfray@softeam.fr Cc : 'Branislav Selic'; mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, Issue 6280: Tools might need two icons for each stereotype, one for the diagrams and one for a model explorer. Issue 6453: anonymous stereotypes will be difficult to deal with in diagrams that define the stereotype, or in organizing properties in tools by extensions. How can a profile developer distinguish two different anonymous stereotype vs. the same stereotype extending two different metaclasses, but simply using a different graphic view? Is it really necessary to have the stereotypes be unnamed? Instead, could tools recognize that all required stereotypes are automatically applied and therefore can't be applied by the user since that would effectively apply them twice. Should there be a notation convention that required stereotypes are not shown in the list of applied stereotypes? Would it even be reasonable to recommend that required stereotypes have the same name as the metaclasses they extend? This would work because they are always in different packages. To: Cc: mu2i-ftf@omg.org, ocl2-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: [profile] resolution proposals for Ballot 14 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 4 May 2004 15:38:51 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/04/2004 15:38:55, Serialize complete at 05/04/2004 15:38:55 Philippe, It seems to me that the resolution to problem 6280 belongs with the desing interchange FTF and should be transferred there. It probably means that they have to add special mechanisms for this capability. Regarding the resolution to issue 6453: if I recall, we had long arguments during the 1.4 FTF whether it should be possible to have tagged values that are unattached to stereotypes (I argued for it -- but I lost). So, if we want to keep with the spirit of what was decided in 1.4 on this issue, we really should not allow unattached tagged values. For those 1.x models which have such things, I suggest converting the tagged values into comments (that's what most are anyway). Cheers, Bran "DESFRAY Philippe" 05/03/2004 05:09 AM Please respond to philippe.desfray To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject [profile] resolution proposals for Ballot 14 -- Philippe [attachment "ProfileResolutionBallot14.doc" deleted by Branislav Selic/Ottawa/IBM] Reply-To: From: "Desfray" To: "'Branislav Selic'" Cc: , , Subject: RE: [profile] resolution proposals for Ballot 14 Date: Wed, 5 May 2004 09:38:16 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Bran, You meant diagram interchange I suppose. This should involve DIagram interchange, infrastructure and profile: The definition of an Image belongs to DI, that definition should be accessible by several metamodels and should be placed within the infrastructure to be reusable, and profile should state how a stereotype relates to an image. A debate relating to issue 6453 has been raised during the profile design stage within U2P (at that time, it was even envisaged that an attribute not necessarily belongs to a classifier ...), and had never reached conclusion. your proposal is a valid conclusion. It meets Pete's comment : this was supported in UML1.3, still supported but discouraged in UML1.4, and can be forbidden in UML2.0. (that is a usual version management pattern). In that case the resolution just has to spell out this. In order to close the debate, I will join the teleconference. I will have only 60 " available. If this subject can be put within the first places, it would help me. Cheeers, Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 4 mai 2004 21:39 À : philippe.desfray@softeam.fr Cc : mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, It seems to me that the resolution to problem 6280 belongs with the desing interchange FTF and should be transferred there. It probably means that they have to add special mechanisms for this capability. Regarding the resolution to issue 6453: if I recall, we had long arguments during the 1.4 FTF whether it should be possible to have tagged values that are unattached to stereotypes (I argued for it -- but I lost). So, if we want to keep with the spirit of what was decided in 1.4 on this issue, we really should not allow unattached tagged values. For those 1.x models which have such things, I suggest converting the tagged values into comments (that's what most are anyway). Cheers, Bran "DESFRAY Philippe" 05/03/2004 05:09 AM Please respond to philippe.desfray To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject [profile] resolution proposals for Ballot 14 -- Philippe [attachment "ProfileResolutionBallot14.doc" deleted by Branislav Selic/Ottawa/IBM] Reply-To: From: "Desfray" To: "'Branislav Selic'" Cc: , Subject: [profile] resolution proposals for Ballot 14 - 2d iteration Date: Thu, 6 May 2004 11:35:26 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Dear all, As a conclusion (I hope) of the previous debate, I propose only a resolution to issue 6453. Issue 6280 will need an action from Diagram Interchange, and from Infrastructure, before being adressable within the profile chapter. Cheers ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 4 mai 2004 21:39 À : philippe.desfray@softeam.fr Cc : mu2i-ftf@omg.org; ocl2-ftf@omg.org; uml2-superstructure-ftf@omg.org Objet : Re: [profile] resolution proposals for Ballot 14 Philippe, It seems to me that the resolution to problem 6280 belongs with the desing interchange FTF and should be transferred there. It probably means that they have to add special mechanisms for this capability. Regarding the resolution to issue 6453: if I recall, we had long arguments during the 1.4 FTF whether it should be possible to have tagged values that are unattached to stereotypes (I argued for it -- but I lost). So, if we want to keep with the spirit of what was decided in 1.4 on this issue, we really should not allow unattached tagged values. For those 1.x models which have such things, I suggest converting the tagged values into comments (that's what most are anyway). Cheers, Bran "DESFRAY Philippe" 05/03/2004 05:09 AM Please respond to philippe.desfray To Branislav Selic/Ottawa/IBM@IBMCA, , , cc Subject [profile] resolution proposals for Ballot 14 -- Philippe [attachment "ProfileResolutionBallot14.doc" deleted by Branislav Selic/Ottawa/IBM] ProfileResolutionBallot14V2.doc Profile resolution proposal for Ballot 14 OMG Issue 6453: Title: "Changes from UML 1.4" for stereotypes Source: Softeam (Mr. Philippe Desfray, phd@softeam.fr) Summary: In the Profile chapter, there is no section for "Changes from UML 1.4" for Stereotypes. However, one feature of UML1.4 : attaching tagged values independently of any stereotype, has disappeared in UML2.0. The evolution tagged values --> attribute should be discussed and that particular case enlighted. a specific pattern for converting UML1.4 stereotype independant tags into UML2.0 should be provided. Proposed Resolution UML1.3 was supporting the attachment of tagged values directly to extended model elements. UML1.4 still supported that feature for backward compatibility reasons but discouraged this practice, and UML2.0 will not support it anymore. In addition, provide clarification to the .required stereotype. notion Discussion In Class description : Stereotype, Notation Add at the end of the paragraph .Presentation option. It is a semantic variation point that a tool can choose to display or not stereotypes. In particular, some tools can choose not to display .required stereotypes., but to display only their attributes (tagged values) if any. In Class description : Stereotype Add at the end (just before 18.4) the following paragraph Changes from previous UML In UML1.3, tagged values could extend a model element without the required presence of a stereotype. In UML1.4, this capacity, although being still supported, was recommended to use only for backward compatibility reason. In UML2.0, a tagged value can only be represented as an attribute defined on a stereotype. Therefore, a model element must be extended by a stereotype in order to be extended by tagged values. The usage of the .required. extension mechanism can however provide an automated stereotype extension, on which attributes can be valuated. The end user service can therefore be very close to the one provided by UML1.3, depending on tool support of this functionality. Disposition: Resolved ================================