Issue 6280: UML2.super (or infra)/Profiles-Stereotype (18.3.7) (uml2-superstructure-ftf) Source: Softeam (Mr. Philippe Desfray, phd(at)softeam.fr) Nature: Uncategorized Issue Severity: Summary: UML2.super (or infra)/Profiles-Stereotype (18.3.7)/absence of diagram customization mechanism This feature was supported in UML1.4 by an attribute called "icon:string". At the time of the design of the Profile metamodel for UML2.0, it has been argued this this was a mechanism to be treated by the diagram interchange proposal. To my knowledge, this is not the case, or if it is this is not eplained. This is at least a backward compatibility issue Two options can at least be envisaged : 1 if that is supported by the global "2.0" specifications, explain in the profile chapter how 2 introduce back this "icon:string" attribute. In that cas, thenotation ch^pter has to be extended to explain how this icon can be displayed, and how multiple stereotype can be handled. Resolution: see above Revised Text: Actions taken: October 1, 2003: received issue March 8, 2005: closed issue Discussion: In the Profile chapter In the profile metamodel (Abstract syntax, Figure 446), add the Image metaclass, and an association between “Stereotype” and Image as follows: Stereotype Image icon * * In Class description Add the following text: Image (from Profiles) Physical definition of a graphical image. Description The Image class provides the necessary information to display an Image in a diagram. Icons are typically handled through the Image class. Attribute No additional attributes. Associations No additional associations. Constraints No additional constraints. Semantics Information such as physical localization or format is provided by the Image class. The Image class is abstract. It must be concretely defined within specifications dedicated to graphic handling (see for example the UML 2.0 Diagram Interchange OMG adopted specification). In Class description : Stereotype : association area, Replace “No additional associations.” By icon : Image [*] Stereotype can change the graphical appearance of the extended model element by using attached icons. When this association is not null, it references the location of the icon content to be displayed within diagrams presenting the extended model elements. In Class description : Stereotype : Constraints area, at the end add: [3] Stereotype names should not clash with keyword names for the extended model element. In Class description : Stereotype : Notation area, at the end of the first paragraph “If multiple stereotypes … guillemets” add: When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword, within separate guillemets (example: «interface»«Clock» ). In Class descrip tion : Stereotype : Notation area, after the paragraph “Presentation options”, add a new paragraph Icon presentation When a stereotype includes the definition of an icon, this icon can be graphically attached to the model elements extended by the stereotype. Every model element that has a graphical presentation can have an attached icon. When model elements are graphically expressed as: ?? Boxes (see Figure 461), the box can be replaced by the icon, and the name of model element appears below the icon. This presentation option can be used only when a model element is extended by one single stereotype, and when properties of the model element are not presented (i.e. attributes, operations of a class). As an other option, the icon can be presented in a reduced shape, inside and on the top of the box representing the model element. When several stereotypes are applied, several icons can be presented within the box. ?? Links, the icon can be presented close to the link ?? textual notation, the icon can be presented on the left of the textual notation. Several icons can be attached to a stereotype. The interpretation of the different attached icons in that case is a semantic variation point. Some tools may require to have different images for the icon replacing the box, fo r the reduced icon inside the box, for icons used within explorers, etc. Depending on the image format, other tools may choose to display one single icon into different sizes. Some model elements are already using an icon for their default presentation. A typical example of this is the actor model element which uses the stickman icon. In that case, when the model element is extended by a stereotype with an icon, the stereotype’s icon replaces the default presentation icon within diagrams. In Class description : Stereotype : Notation, add at the end of the “Examples” Paragraph the following figure Figure 461 – Presentation options for an extended class. End of Annotations:===== eply-To: From: "DESFRAY Philippe" To: "'Juergen Boldt'" Subject: UML2 superstructure issue Date: Wed, 1 Oct 2003 10:58:18 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal Juergen, I hoep I am following the right process, still on schedule. Here is an issue I want to raise for UML2.0. Best regards UML2.super (or infra)/Profiles-Stereotype (18.3.7)/absence of diagram customization mechanism This feature was supported in UML1.4 by an attribute called "icon:string". At the time of the design of the Profile metamodel for UML2.0, it has been argued this this was a mechanism to be treated by the diagram interchange proposal. To my knowledge, this is not the case, or if it is this is not eplained. This is at least a backward compatibility issue Two options can at least be envisaged : 1 if that is supported by the global "2.0" specifications, explain in the profile chapter how 2 introduce back this "icon:string" attribute. In that cas, thenotation ch^pter has to be extended to explain how this icon can be displayed, and how multiple stereotype can be handled. -- 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. Profile resolution proposal for Ballot 14 OMG Issue N° 6280 Title : absence of diagram customization mechanism for stereotypes Source: Softeam (Mr. Philippe Desfray, phd@softeam.fr) Summary: This feature was supported in UML1.4 by an attribute called "icon:string". At the time of the design of the Profile metamodel for UML2.0, it has been argued this this was a mechanism to be treated by the diagram interchange proposal. To my knowledge, this is not the case, or if it is this is not explained. This is at least a backward compatibility issue. Proposed Resolution Two options can at least be envisaged : 1 if that is supported by the global "2.0" specifications, explain in the profile chapter how 2 introduce back this "icon:string" attribute. In that case, the notation chapter has to be extended to explain how this icon can be displayed, and how multiple stereotype can be handled. Discussion In the Profile chapter In the profile metamodel (Abstract syntax, Figure 446), add the following attributes to the .Stereotype. metaclass : iconUri : string iconMimeType : string In Class description : Stereotype : attribute area, Replace .No additional attributes.. By iconUri : string Stereotype can change the graphical appearance of the extended model element by using attached icons. When this attribute is not null, it references the location of the icon content to be displayed within diagrams attached to the extended model element. iconMimeType : string Specifies the format of the icon to be displayed, when applicable. In Class description : Stereotype : Notation area, after the paragraph .Presentation options., add a new paragraph Icon presentation When a stereotype includes the definition of an icon, this icon can be optionally graphically attached to the model elements extended by the stereotype. Every model element that has a graphical presentation can have an attached icon. When model elements are graphically expressed as: Boxes (see Figure 461), the box can be replaced by the icon, and the name of model element appears below the icon. This presentation option can be used only when a model element is extended by only one stereotype, and when properties of the model element are not presented (i.e. attributes, operations of a class). As an other option, the icon can be presented in a reduced shape, inside and on the top of the box representing the model element. When several stereotypes are applied, several icons can be presented within the box. Links, the icon can be presented close to the link textual notation, the icon can be presented on the left of the textual notation. In Class description : Stereotype : Notation, add at the end of the .Examples. Paragraph the following figure Figure 461 . Presentation options for an extended class. 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.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. 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. 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: "'Marko Boger'" Subject: [profiles] Proposed issues for 15 Date: Tue, 18 May 2004 11:11:58 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Dear all, Here comes a new attempt to solve the controversial 6280 issue (handling icons with stereotypes). Having received many feedbacks from the first attempt and from the DI ftf, here is what we get. Once this will be adopted (hopefully), DI-ftf will have to slightly adapt the di specification. ==================================== 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 ProfileResolutionBallot15.doc Profile resolution proposal for Ballot 15 OMG Issue N° 6280 Title : absence of diagram customization mechanism for stereotypes Source: Softeam (Mr. Philippe Desfray, phd@softeam.fr) Summary: This feature was supported in UML1.4 by an attribute called "icon:string". At the time of the design of the Profile metamodel for UML2.0, it has been argued this this was a mechanism to be treated by the diagram interchange proposal. To my knowledge, this is not the case, or if it is this is not explained. This is at least a backward compatibility issue. Proposed Resolution Two options can at least be envisaged : 1 if that is supported by the global "2.0" specifications, explain in the profile chapter how 2 introduce back this "icon:string" attribute. In that case, the notation chapter has to be extended to explain how this icon can be displayed, and how multiple stereotype can be handled. Discussion In the Profile chapter In the profile metamodel (Abstract syntax, Figure 446), add the Image metaclass, and an association between .Stereotype. and Image as follows: In Class description Add the following text: Image (from Profiles) Physical definition of a graphical image. Description The Image class provides the necessary information to display an Image in a diagram. Icons are typically handled through the Image class. Attributes No additional attributes. Associations No additional associations. Constraints No additional constraints. Semantics Information such as physical localization or format is provided by the Image class. The Image class is abstract. It must be concretely defined within specifications dedicated to graphic handling (see for example the UML 2.0 Diagram Interchange OMG adopted specification). In Class description : Stereotype : association area, Replace .No additional associations.. By icon : Image [*] Stereotype can change the graphical appearance of the extended model element by using attached icons. When this association is not null, it references the location of the icon content to be displayed within diagrams presenting the extended model elements. In Class description : Stereotype : Constraints area, at the end add: [3] Stereotype names should not clash with keyword names for the extended model element. In Class description : Stereotype : Notation area, at the end of the first paragraph .If multiple stereotypes . guillemets. add: When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword, within separate guillemets (example: <><> ). In Class description : Stereotype : Notation area, after the paragraph .Presentation options., add a new paragraph Icon presentation When a stereotype includes the definition of an icon, this icon can be graphically attached to the model elements extended by the stereotype. Every model element that has a graphical presentation can have an attached icon. When model elements are graphically expressed as: · Boxes (see Figure 461), the box can be replaced by the icon, and the name of model element appears below the icon. This presentation option can be used only when a model element is extended by one single stereotype, and when properties of the model element are not presented (i.e. attributes, operations of a class). As an other option, the icon can be presented in a reduced shape, inside and on the top of the box representing the model element. When several stereotypes are applied, several icons can be presented within the box. · Links, the icon can be presented close to the link · textual notation, the icon can be presented on the left of the textual notation. Several icons can be attached to a stereotype. The interpretation of the different attached icons in that case is a semantic variation point. Some tools may require to have different images for the icon replacing the box, for the reduced icon inside the box, for icons used within explorers, etc. Depending on the image format, other tools may choose to display one single icon into different sizes. Some model elements are already using an icon for their default presentation. A typical example of this is the actor model element which uses the stickman icon. In that case, when the model element is extended by a stereotype with an icon, the stereotype.s icon replaces the default presentation icon within diagrams. In Class description : Stereotype : Notation, add at the end of the .Examples. Paragraph the following figure Figure 461 . Presentation options for an extended class. Disposition: Resolved --