Issue 16342: Ambiguous stereotype notation (uml2-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: Suppose we have a stereotype S extending UML::Class. We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any other element whose metaclass is a kind of UML::Class. The UML notation for stereotype allows showing applications of S as <<S>> but this notation does not clearly show what kind of element the element is. In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, UML::StateMachine) use the same notation (i.e. a box), the overall notation is ambiguous. The UML notation could be extended to show optionally the metaclass of an element, e.g., <<S>> [Class] vs. <<S>> [Activity] vs. <<S>> [StateMachine]. Proposed resolution: in clause 18.3.9, Stereotype, under notation, change: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed. For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation. If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list with a pair of guillemets. 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»). to: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed optionally followed by the name of the model element's metaclass within a pair of square brackets. For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation optionally followed by the name of the model element's metaclass within a pair of square brackets. If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword, within separate guillemets (example: «interface» [Interface], «Clock» [Class]). Resolution: Revised Text: Actions taken: June 22, 2011: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: Juergen Boldt CC: "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" , Burkhart Roger M Date: Tue, 21 Jun 2011 10:38:55 -0700 Subject: Ambiguous stereotype notation. Thread-Topic: Ambiguous stereotype notation. Thread-Index: AcwwOhjRMHCypjDsSUu2q1aTbRR6rg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Suppose we have a stereotype S extending UML::Class. We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any other element whose metaclass is a kind of UML::Class. The UML notation for stereotype allows showing applications of S as <> but this notation does not clearly show what kind of element the element is. In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, UML::StateMachine) use the same notation (i.e. a box), the overall notation is ambiguous. The UML notation could be extended to show optionally the metaclass of an element, e.g., <> [Class] vs. <> [Activity] vs. <> [StateMachine]. Proposed resolution: in clause 18.3.9, Stereotype, under notation, change: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed. For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation. If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list with a pair of guillemets. 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»). to: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed optionally followed by the name of the model element's metaclass within a pair of square brackets. For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation optionally followed by the name of the model element's metaclass within a pair of square brackets. If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword, within separate guillemets (example: «interface» [Interface], «Clock» [Class]). - Nicolas. Date: Wed, 22 Jun 2011 14:43:38 +0100 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.21 (X11/20090302) To: "Rouquette, Nicolas F (313K)" CC: Juergen Boldt , "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" , Burkhart Roger M Subject: Re: Ambiguous stereotype notation. X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E01F196.00AD:SCFMA922111,ss=1,re=-4.000,fgs=0 Having <> [Interface] seems a little odd to me, it contains redundant information. In our tool we just show keywords, metaclasses and stereotypes all within guillemets. Currently we show, for example, <>. Although that should probably be <>; I think it's previously been discussed that lower casing the first letter is a convention for which there doesn't actually appear to be a reason. Cheers, Dave On 21/06/11 18:38, Rouquette, Nicolas F (313K) wrote: Suppose we have a stereotype S extending UML::Class. We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any other element whose metaclass is a kind of UML::Class. The UML notation for stereotype allows showing applications of S as <> but this notation does not clearly show what kind of element the element is. In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, UML::StateMachine) use the same notation (i.e. a box), the overall notation is ambiguous. The UML notation could be extended to show optionally the metaclass of an element, e.g., <> [Class] vs. <> [Activity] vs. <> [StateMachine]. Proposed resolution: in clause 18.3.9, Stereotype, under notation, change: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed. For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation. If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list with a pair of guillemets. 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»). to: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed *optionally followed by the name of the* * model element's metaclass **within a pair of square brackets.* For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation *optionally * * followed by the name of the **model element's metaclass **within a pair of square brackets.* If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword, within separate guillemets (example: «interface» *[Interface],* «Clock» *[Class]*). - Nicolas. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Os Os From: "Rouquette, Nicolas F (313K)" To: Dave Hawkins CC: Juergen Boldt , "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" , Burkhart Roger M Date: Wed, 22 Jun 2011 14:11:28 -0700 Subject: Re: Ambiguous stereotype notation. Thread-Topic: Ambiguous stereotype notation. Thread-Index: AcwxIPP+ejsbQCbmRRmXRIPuue91og== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p5ML4Aj0015040 Dave, In some cases, there may be redundancy -- perhaps a smart tool could figure out that instead of showing: <> [Enumeration] it is sufficient to show: <> However, consider a stereotype S that extends UML::Element. This is the worst-case scenario where the notation may be completely ambiguous about what kind of element X is when it is shown as: X <> (assuming that X is a kind of UML::NamedElement). In practice, this happens quite often with SysML where lots of stereotypes extend UML::Class and are therefore applicable to concrete specializations such as UML::Activity, UML::StateMachine, UML::OpaqueBehavior. It is not OK to hide the metaclass nature of an element when the stereotypes applied to it are insufficient to provide unambiguous guidance to the user about what can be done with such an element. For example, it makes a big difference to a user if an element shown in a diagram simply as "X <>" happens to be a UML::Class vs. UML::Activity vs. UML::StateMachine. The things that a user can do in the 3 cases are completely different; yet there is no obvious indication at all about this. This results in folks who are genuinely confused, surprised and upset about why their modeling tool is so deceptively confusing and complicated to use! This is a significant usability issue of the language that affects how the language is implemented. Clearly, some implementations like Oracle's JDeveloper may have already addressed usability concerns above & beyond the spec; however, I believe it is important to provide something in the spec explicitly since there is plenty of evidence that usable UML tools with unambiguous diagrammatic representations of elements are exceptionally rare, not ubiquitous. - Nicolas. On Jun 22, 2011, at 6:43 AM, Dave Hawkins wrote: > Having <> [Interface] seems a little odd to me, it contains > redundant information. In our tool we just show keywords, metaclasses > and stereotypes all within guillemets. Currently we show, for example, > <>. Although that should probably be > <>; I think it's previously been discussed that lower > casing the first letter is a convention for which there doesn't > actually appear to be a reason. > > Cheers, > > Dave > > On 21/06/11 18:38, Rouquette, Nicolas F (313K) wrote: >> Suppose we have a stereotype S extending UML::Class. >> We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any >> other element whose metaclass is a kind of UML::Class. >> >> The UML notation for stereotype allows showing applications of S as >> <> but this notation does not clearly show what kind of element the >> element is. >> In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, >> UML::StateMachine) use the same notation (i.e. a box), the overall >> notation is ambiguous. >> >> The UML notation could be extended to show optionally the metaclass of >> an element, e.g., <> [Class] vs. <> [Activity] vs. <> >> [StateMachine]. >> >> Proposed resolution: >> >> in clause 18.3.9, Stereotype, under notation, change: >> >> When a stereotype is applied to a model element (an instance of a >> stereotype is linked to an instance of a metaclass), >> the name of the stereotype is shown within a pair of guillemets above or >> before the name of the model >> element, or where the name would appear if the name is omitted or not >> displayed. For model elements >> that do not have names but do have a graphical representation, unless >> specifically stated elsewhere, the stereotypes >> can be displayed within a pair of guillemets near the upper right corner >> of the graphical representation. >> If multiple stereotypes are applied, the names of the applied >> stereotypes are shown as a comma-separated list >> with a pair of guillemets. 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»). >> >> to: >> >> When a stereotype is applied to a model element (an instance of a >> stereotype is linked to an instance of a metaclass), >> the name of the stereotype is shown within a pair of guillemets above or >> before the name of the model >> element, or where the name would appear if the name is omitted or not >> displayed *optionally followed by the name of the* >> * model element's metaclass **within a pair of square brackets.* For >> model elements >> that do not have names but do have a graphical representation, unless >> specifically stated elsewhere, the stereotypes >> can be displayed within a pair of guillemets near the upper right corner >> of the graphical representation *optionally * >> * followed by the name of the **model element's metaclass **within a >> pair of square brackets.* >> If multiple stereotypes are applied, the names of the applied >> stereotypes are shown as a comma-separated list >> with a pair of guillemets. When the extended model element has a >> keyword, then the stereotype name will be displayed close to the keyword, >> within separate guillemets (example: «interface» >> *[Interface],* «Clock» *[Class]*). >> >> - Nicolas. >> > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 > Oracle JDeveloper Development > Oracle Corporation UK Ltd is a company incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Os Date: Thu, 23 Jun 2011 10:57:32 +0100 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.21 (X11/20090302) To: "Rouquette, Nicolas F (313K)" CC: Juergen Boldt , "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" , Burkhart Roger M Subject: Re: Ambiguous stereotype notation. X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E030E17.0157:SCFMA922111,ss=1,re=-4.000,fgs=0 Nicolas, I wasn't disagreeing with the need to update the specification to remove this ambiguity; we have, after all, tackled this very problem in JDeveloper. My point was simply that your proposed notation is inconsistent if you don't want to display redundant information. Throughout the specification there are references to showing 'keywords' as part of various notations. Many of these are actually metaclasses. In fact 7.3.5 Class actually makes this explicit: A class is shown using the classifier symbol. As class is the most widely used classifier, the keyword .class. need not be shown in guillemets above the name. A classifier symbol without a metaclass shown in guillemets indicates a class. (Note that isn't a strictly correct statement as the notation for a primitive type uses 'primitive' not 'primitiveType'. There are some other inconsistencies like this such as 'substitute' rather than 'substitution' and 'use' rather than 'usage'.) I think the specification should be updated show metaclasses in a consistent way in all notations. Either this means that the metaclass should never be shown within guillemets and only shown within square brackets or the metaclass should be shown within guillemets and the square bracket notation should not be introduced. Given there's already precedent for including metaclasses within the guillemets and stereotypes are quite similar conceptually, I think the guillemets only option is the best way to show the metaclasses. Any references to 'keywords' in the specification should be updated to metaclass where appropriate. I also think that the specification should be updated such that metaclasses and stereotypes are always shown exactly as they are named without the pointless lower casing of the their initial letter. Cheers, Dave On 22/06/11 22:11, Rouquette, Nicolas F (313K) wrote: Dave, In some cases, there may be redundancy -- perhaps a smart tool could figure out that instead of showing: <> [Enumeration] it is sufficient to show: <> However, consider a stereotype S that extends UML::Element. This is the worst-case scenario where the notation may be completely ambiguous about what kind of element X is when it is shown as: X <> (assuming that X is a kind of UML::NamedElement). In practice, this happens quite often with SysML where lots of stereotypes extend UML::Class and are therefore applicable to concrete specializations such as UML::Activity, UML::StateMachine, UML::OpaqueBehavior. It is not OK to hide the metaclass nature of an element when the stereotypes applied to it are insufficient to provide unambiguous guidance to the user about what can be done with such an element. For example, it makes a big difference to a user if an element shown in a diagram simply as "X <>" happens to be a UML::Class vs. UML::Activity vs. UML::StateMachine. The things that a user can do in the 3 cases are completely different; yet there is no obvious indication at all about this. This results in folks who are genuinely confused, surprised and upset about why their modeling tool is so deceptively confusing and complicated to use! This is a significant usability issue of the language that affects how the language is implemented. Clearly, some implementations like Oracle's JDeveloper may have already addressed usability concerns above & beyond the spec; however, I believe it is important to provide something in the spec explicitly since there is plenty of evidence that usable UML tools with unambiguous diagrammatic representations of elements are exceptionally rare, not ubiquitous. - Nicolas. On Jun 22, 2011, at 6:43 AM, Dave Hawkins wrote: Having <> [Interface] seems a little odd to me, it contains redundant information. In our tool we just show keywords, metaclasses and stereotypes all within guillemets. Currently we show, for example, <>. Although that should probably be <>; I think it's previously been discussed that lower casing the first letter is a convention for which there doesn't actually appear to be a reason. Cheers, Dave On 21/06/11 18:38, Rouquette, Nicolas F (313K) wrote: Suppose we have a stereotype S extending UML::Class. We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any other element whose metaclass is a kind of UML::Class. The UML notation for stereotype allows showing applications of S as <> but this notation does not clearly show what kind of element the element is. In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, UML::StateMachine) use the same notation (i.e. a box), the overall notation is ambiguous. The UML notation could be extended to show optionally the metaclass of an element, e.g., <> [Class] vs. <> [Activity] vs. <> [StateMachine]. Proposed resolution: in clause 18.3.9, Stereotype, under notation, change: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed. For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation. If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list with a pair of guillemets. 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»). to: When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element, or where the name would appear if the name is omitted or not displayed *optionally followed by the name of the* * model element's metaclass **within a pair of square brackets.* For model elements that do not have names but do have a graphical representation, unless specifically stated elsewhere, the stereotypes can be displayed within a pair of guillemets near the upper right corner of the graphical representation *optionally * * followed by the name of the **model element's metaclass **within a pair of square brackets.* If multiple stereotypes are applied, the names of the applied stereotypes are shown as a comma-separated list with a pair of guillemets. When the extended model element has a keyword, then the stereotype name will be displayed close to the keyword, within separate guillemets (example: «interface» *[Interface],* «Clock» *[Class]*). - Nicolas. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. Or Or Or OrFrom: "Rouquette, Nicolas F (313K)" To: Dave Hawkins CC: Juergen Boldt , "uml2-rtf@omg.org" , "uml-spec-simplification@omg.org" , Burkhart Roger M Date: Thu, 23 Jun 2011 12:35:52 -0700 Subject: Re: Ambiguous stereotype notation. Thread-Topic: Ambiguous stereotype notation. Thread-Index: Acwx3MQntkR8Mva1R2S5N3tJKNeDpw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p5NJSZYd012764 Dave, I like the idea of using the guillemets notation to show an element metaclass. As you indicate, there is a half-baked precedent for this anyway, it's time we clean this up and do it right. I also agree with doing away with the lower casing whatever keyword/stereotype/metaclass name we need to show. - Nicolas. On Jun 23, 2011, at 2:57 AM, Dave Hawkins wrote: > Nicolas, > > I wasn't disagreeing with the need to update the specification > to remove this ambiguity; we have, after all, tackled this very > problem in JDeveloper. My point was simply that your proposed > notation is inconsistent if you don't want to display redundant > information. > > Throughout the specification there are references to showing > 'keywords' as part of various notations. Many of these are > actually metaclasses. In fact 7.3.5 Class actually makes this > explicit: > > A class is shown using the classifier symbol. As class is the > most widely used classifier, the keyword .class. need not be > shown in guillemets above the name. A classifier symbol without > a metaclass shown in guillemets indicates a class. > > (Note that isn't a strictly correct statement as the notation > for a primitive type uses 'primitive' not 'primitiveType'. > There are some other inconsistencies like this such as > 'substitute' rather than 'substitution' and 'use' rather than > 'usage'.) > > I think the specification should be updated show metaclasses > in a consistent way in all notations. Either this means that > the metaclass should never be shown within guillemets and only > shown within square brackets or the metaclass should be shown > within guillemets and the square bracket notation should not > be introduced. Given there's already precedent for including > metaclasses within the guillemets and stereotypes are quite > similar conceptually, I think the guillemets only option is > the best way to show the metaclasses. Any references to > 'keywords' in the specification should be updated to metaclass > where appropriate. > > I also think that the specification should be updated such > that metaclasses and stereotypes are always shown exactly > as they are named without the pointless lower casing of the > their initial letter. > > Cheers, > > Dave > > On 22/06/11 22:11, Rouquette, Nicolas F (313K) wrote: >> Dave, >> >> In some cases, there may be redundancy -- perhaps a smart tool could figure out that instead of showing: >> >> <> [Enumeration] >> >> it is sufficient to show: >> >> <> >> >> However, consider a stereotype S that extends UML::Element. >> >> This is the worst-case scenario where the notation may be completely ambiguous about what kind of element X is when it is shown as: X <> >> (assuming that X is a kind of UML::NamedElement). >> >> In practice, this happens quite often with SysML where lots of stereotypes extend UML::Class and are therefore applicable to concrete specializations >> such as UML::Activity, UML::StateMachine, UML::OpaqueBehavior. It is not OK to hide the metaclass nature of an element when the stereotypes applied >> to it are insufficient to provide unambiguous guidance to the user about what can be done with such an element. >> >> For example, it makes a big difference to a user if an element shown in a diagram simply as "X <>" happens to be a UML::Class vs. UML::Activity vs. UML::StateMachine. >> The things that a user can do in the 3 cases are completely different; yet there is no obvious indication at all about this. >> This results in folks who are genuinely confused, surprised and upset about why their modeling tool is so deceptively confusing and complicated to use! >> >> This is a significant usability issue of the language that affects how the language is implemented. >> Clearly, some implementations like Oracle's JDeveloper may have already addressed usability concerns above & beyond the spec; >> however, I believe it is important to provide something in the spec explicitly since there is plenty of evidence that usable UML tools >> with unambiguous diagrammatic representations of elements are exceptionally rare, not ubiquitous. >> >> - Nicolas. >> >> On Jun 22, 2011, at 6:43 AM, Dave Hawkins wrote: >> >>> Having <> [Interface] seems a little odd to me, it contains >>> redundant information. In our tool we just show keywords, metaclasses >>> and stereotypes all within guillemets. Currently we show, for example, >>> <>. Although that should probably be >>> <>; I think it's previously been discussed that lower >>> casing the first letter is a convention for which there doesn't >>> actually appear to be a reason. >>> >>> Cheers, >>> >>> Dave >>> >>> On 21/06/11 18:38, Rouquette, Nicolas F (313K) wrote: >>>> Suppose we have a stereotype S extending UML::Class. >>>> We can apply S to a UML::Class, UML::Activity, UML::StateMachine and any >>>> other element whose metaclass is a kind of UML::Class. >>>> >>>> The UML notation for stereotype allows showing applications of S as >>>> <> but this notation does not clearly show what kind of element the >>>> element is. >>>> In cases where distinct metaclasses (e.g., UML::Class, UML::Activity, >>>> UML::StateMachine) use the same notation (i.e. a box), the overall >>>> notation is ambiguous. >>>> >>>> The UML notation could be extended to show optionally the metaclass of >>>> an element, e.g., <> [Class] vs. <> [Activity] vs. <> >>>> [StateMachine]. >>>> >>>> Proposed resolution: >>>> >>>> in clause 18.3.9, Stereotype, under notation, change: >>>> >>>> When a stereotype is applied to a model element (an instance of a >>>> stereotype is linked to an instance of a metaclass), >>>> the name of the stereotype is shown within a pair of guillemets above or >>>> before the name of the model >>>> element, or where the name would appear if the name is omitted or not >>>> displayed. For model elements >>>> that do not have names but do have a graphical representation, unless >>>> specifically stated elsewhere, the stereotypes >>>> can be displayed within a pair of guillemets near the upper right corner >>>> of the graphical representation. >>>> If multiple stereotypes are applied, the names of the applied >>>> stereotypes are shown as a comma-separated list >>>> with a pair of guillemets. 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»). >>>> >>>> to: >>>> >>>> When a stereotype is applied to a model element (an instance of a >>>> stereotype is linked to an instance of a metaclass), >>>> the name of the stereotype is shown within a pair of guillemets above or >>>> before the name of the model >>>> element, or where the name would appear if the name is omitted or not >>>> displayed *optionally followed by the name of the* >>>> * model element's metaclass **within a pair of square brackets.* For >>>> model elements >>>> that do not have names but do have a graphical representation, unless >>>> specifically stated elsewhere, the stereotypes >>>> can be displayed within a pair of guillemets near the upper right corner >>>> of the graphical representation *optionally * >>>> * followed by the name of the **model element's metaclass **within a >>>> pair of square brackets.* >>>> If multiple stereotypes are applied, the names of the applied >>>> stereotypes are shown as a comma-separated list >>>> with a pair of guillemets. When the extended model element has a >>>> keyword, then the stereotype name will be displayed close to the keyword, >>>> within separate guillemets (example: «interface» >>>> *[Interface],* «Clock» *[Class]*). >>>> >>>> - Nicolas. >>>> >>> -- >>> Dave Hawkins | Principal Software Engineer | +44 118 924 0022 >>> Oracle JDeveloper Development >>> Oracle Corporation UK Ltd is a company incorporated in England & Wales. >>> Company Reg. No. 1782505. >>> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. >> > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 > Oracle JDeveloper Development > Oracle Corporation UK Ltd is a company incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.