Issue 6347: Profiles in fixed repositories (uml2-superstructure-ftf) Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com) Nature: Clarification Severity: Critical Summary: Do profiles working for fixed repositories in UML 2? My understanding is that they are at M3 now, so they wouldn't. If that's the case, then what is their purpose? The other feature of dynamically changing metaclasses is something a repository could provide if it was useful, instead of using stereotypes. Resolution: see above Revised Text: Actions taken: October 20, 2003: received issue March 8, 2005: closed issue Discussion: 1 Change the text in the overview of profiles (actual text) The Profiles package contains mechanisms that allow metaclasses from existing metamodels to be extended to adapt them for different purposes. This includes the ability to tailor the UML metamodel for different platforms (such as J2EE or .NET) or domains (such as real-time or business process modeling). The profiles mechanism is consistent with the OMG Meta Object Facility (MOF). (Add) Positioning profiles versus metamodels, MOF and UML: The infrastructure specification is reused at several meta-levels in various OMG specifications that deal with modeling. For example, MOF uses it to provide the ability to model metamodels, whereas the UML superstructure uses it to model the UML model. This chapter deals with use cases comparable to the MOF at the meta-meta- level, which is one level higher than the rest of the superstructure specification. Thus, in this chapter, when we mention “Class”, in most cases we are dealing with the meta-metaclass “Class” (used to define every meta class in the UML superstructure specification (Activity, Class, State, Use Case, etc.). Profiles History and design requirements The Profile mechanism has been specifically defined for providing a lightweight extension mechanism to the UML standard. In UML 1.1, stereotypes and tagged values were used as string-based extensions that could be attached to UML model elements in a flexible way. In subsequent revisions of UML, the notion of a Profile was defined in order to provide more structure and precision to the definition of Stereotypes and Tagged values. The UML2.0 infrastructure and superstructure specifications have carried this further, by defining it as a specific meta- modelling technique. Stereotypes are specific metaclasses, tagged values are standard metaattributes, and profiles are specific kinds of packages. The following requirements have driven the definition of profile semantics from inception: 1. A profile must provide mechanisms for specializing a reference metamodel (such as a set of UML packages) in such a way that the specialized semantics do not contradict the semantics of the reference metamodel. That is, profile constraints may typically define wellformedness rules that are more constraining (but consistent with) those specified by the reference metamodel. 2. It must be possible to interchange profiles between tools, together with models to which they have been applied, by using the UML XMI interchange mechanisms. A profile must therefore be defined as an interchangeable UML model. In addition to exchanging profiles together with models between tools, profile application should also be definable “by reference” (e.g. “import by name”); that is, a profile does not need to be interchanged if it is already present in the importing tool. 3. A profile must be able to reference domain-specific UML libraries where certain model elements are pre-defined. 4. It must be possible to specify which profiles are being applied to a given Package (or any of specializations of that concept). This is particularly useful during model interchange so that an importing environment can interpret a model correctly. 5. It should be possible to define a UML extension that combines profiles and model libraries (including template libraries) into a single logical unit. However, within such a unit, for definitional clarity and for ease of interchange (e.g. ‘reference by name’), it should still be possible to keep the libraries and the profiles distinct from each other. 6. A profile should be able to specialize the semantics of standard UML metamodel elements, e.g., in a model with the profile “Java model” generalization of classes should be able to be restricted to single inheritance, without having to explicitly assign a stereotype «Java class» to each and every class instance. 7. A notational convention for graphical stereotype definitions as part of a profile should be provided. 8. In order to satisfy requirement [1] above, UML Profiles should form a metamodel extension mechanism that imposes certain restrictions on how the UML metamodel can be modified. The reference metamodel is considered as a “read only” model, that is extended witho ut changes by profiles. It is therefore forbidden to insert new metaclasses in the UML metaclass hierarchy (i.e. new super-classes for standard UML metaclasses) or to modify the standard UML metaclass definitions, e.g. by adding meta-associations. Such restrictions do not apply in a MOF context where in principle any metamodel can be reworked in any direction. 9. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constraint these tools to have an internal implementation based on a metametamodel/ metamodel architecture. 10. Profiles can be dynamically applied to or retracted from a model. It is possible on an existing model to apply new profiles, or to change the set of applied profiles. 11. Profiles can be dynamically combined. Frequently, several profiles will be applied at the same time on the same model. This profile combination may not be foreseen at profile definition time. 12. Models can be exchanged regardless of the profiles known by the destina tion target. The destination of the exchange of a model extended by a profile may not know the profile, and is not required to interpret a specific profile description. The destination environment interprets extensions only if it possesses the required profiles. 2 Change in the text of Stereotype: semantics (Change) A stereotype is a limited kind of metaclass that cannot be used isolated, but must always be used in conjunction with one of the metaclasses it extends. Each stereotype may extend one or more classes through extensions as part of a profile. Similarly, a class may be extended by one or more stereotypes. An instance of a stereotype is linked to an instance of an extended metaclass (or stereotype) by virtue of the extension between their types. (Into) A stereotype is a limited kind of metaclass that cannot be used by itself, but must always be used in conjunction with one of the metaclasses it extends. Each stereotype may extend one or more classes through extensions as part of a profile. Similarly, a class may be extended by one or more stereotypes. An instance “S” of Stereotype is a kind of (meta) class. Relating it to a metaclass “C” from the reference metamodel (typically UML) using an “Extension” (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of “S” (see example Figure 454). At the model level (such as in Figure 457) instances of “S” are related to “C” model elements (instances of “C”) by links (occurrences of the association/extension from “S’ to “C”). Any model element from the reference metamodel (any UML model element) can be extended by a stereotype. For example in UML, States, Transitions, Activities, Use cases, Components, Attributes, Dependencies, etc. can all be extended with stereotypes. 3 In Profile : semantics (add) The most direct implementation of the Profile mechanism that a tool can provide, is by having a metamodel based implementation, similar to the Profile metamodel. However, this is not a requirement of the current standard, which requires only the support of the specified notions, and the standard XMI based interchange capacities. The profile mechanism has been designed to be implementable by tools that do not have a metamodel-based implementation. Practically any mechanism used to attach new values to model elements can serve as a valid profile implementation. As an example, the UML1.4 profile metamodel could be the basis for implementing a UML2.0-compliant profile tool. 4 in Package : Semantics Currently : No additional semantics. (Replace with) The association “appliedProfile” between a package and a profile crosses metalevels: It links one element from a model (a kind of package) to an element of its metamodel and represents the set of profiles that define the extensions applicable to the package. Although this kind of situation is rare in the UML metamodel, this only shows that model and metamodel can coexist on the same space, and can have links between them. 5 In Extension : Semantics (Change ) In order to be able to navigate to the extended metaclass when writing constraints, the end must have a name. If no name is given, the default name is baseClass. (into) The equivalence to a MOF construction is shown in Figure 447. This figure illustrates the case shown in Figure 449, where the “Home” stereotype extends the “Interface” metaclass. The MOF construct equivalent to an extension is an aggregation from the extended metaclass to the extension stereotype, navigable from the extension stereotype to the extended metaclass. When the extension is required, then the cardinality on the extension stereotype is “1”. The role names are provided using the following rule : The name of the role of the extended metaclass is –base“ExtendedMetaclassName”-; the name of the role of the extension stereotype is –extension“StereotypeName”-. Constraints are frequently added to stereotypes. The role names will be used for expressing OCL navigations. For example, the following OCL expression states that a Home interface shall not have attributes: self.baseInterface.ownedAttributes->size() = 0 Interface Home baseInterface extensionHome 1 0..1 Figure 447 – MOF model equivalent to extending “Interface” by the “Home” stereotype 6 in Stereotypes : Examples (Change) Note that in order to be able to write constraints on the stereotype Clock that should be applied to the metaclass Class or any of its relationships, it is necessary to give the end typed by the metaclass a name for navigation purposes. A typical such name would be for example base. In Figure 455, an instance specification of the example in Figure 454 is shown. Note that the extension must be composite, and that the derived required attribute in this case is false. (Into) In Figure 455, an instance specification of the example in Figure 454 is shown. Note that the extension must be composite, and that the derived isRequired” attribute in this case is false. Figure 455 shows the repository schema of the stereotype “clock” defined in Figure 454. In this schema, the extended instance (:Class; “name = Class”) is defined in the UML2.0 (reference metamodel) repository. In a UML modeling tool these extended instances referring to the UML2.0 standard would typically be in a “read only” form, or presented as proxies to the metaclass being extended. (It is therefore still at the same meta-level as UML, and does not show the instance model of a model extended by the stereotype. An example of this is provided in Figures 457 and 458.) The Semantics subsection of the Extension concept explains the MOF equivalent, and how constraints can be attached to stereotypes. (Update Figure 458 “Showing values of stereotypes and a simple instance specificiation”) StopWatch <<Clock>> <<Clock>> Resolution=2 :Class name="StopWatch" :Clock resolution=2 baseClass extensionClock End of Annotations:===== me: SysML Company: SysML Partners mailFrom: sanford.friedenthal@lmco.com Nature: Clarification Severity: Critical Subject: Profiles in fixed repositories Do profiles working for fixed repositories in UML 2? My understanding is that they are at M3 now, so they wouldn't. If that's the case, then what is their purpose? The other feature of dynamically changing metaclasses is something a repository could provide if it was useful, instead of using stereotypes. Issue 6347: Profiles in fixed repositories (uml2-superstructure-ftf) Click here for this issue's archive. Source: INCOSE (Mr. Sanford A. Friedenthal, sanford.friedenthal@lmco.com) Nature: Clarification Severity: Critical Summary: Do profiles working for fixed repositories in UML 2? My understanding is that they are at M3 now, so they wouldn't. If that's the case, then what is their purpose? The other feature of dynamically changing metaclasses is something a repository could provide if it was useful, instead of using stereotypes. Discussion: Almost all of the above issues will be solved by a global change to the profile spec. The intend is to clarify the meta aspects between profile and UML models, to recall the requirement driving the definition of profiles, so that the reader be more aware of the position of the profile spec. Disposition: 1 Change the text in the overview of profiles (actual text) The Profiles package contains mechanisms that allow metaclasses from existing metamodels to be extended to adapt them for different purposes. This includes the ability to tailor the UML metamodel for different platforms (such as J2EE or .NET) or domains (such as real-time or business process modeling). The profiles mechanism is consistent with the OMG Meta Object Facility (MOF). (Add) Positioning profiles versus metamodels, MOF and UML: The infrastructure specification is reused at several meta-levels within the OMG specifications. For example, MOF is reusing it for having the capacity to model meta-models, whereas the UML superstructure reuses it to model the UML model. The Profile chapter is covering use cases comparable to the MOF at the meta-meta-level, which is for example one level above the rest of the superstructure specification. For example, in this chapter, when we mention .Class., we designate most of the time the meta-meta-class .Class. from which for example every meta class of the UML superstructure specification (Activity, State, Use Case, etc.) is instanciated. Profiles History and design requirements The Profile mechanism has been specifically defined for providing a lighweight extension mechanism to the UML standard. Stereotypes and tagged values were originately used as .string based. extensions that can be attached to UML model elements in a flexible way. Since UML1.3, and more specifically UML1.4, the notion of Profile has been defined in order to structure the definition of Stereotypes and Tagged values. The UML2.0 infrastructure and superstructure specifications have reinforced the formalization of the profile mechanism, by defining it as a specific meta-modeling technique. Stereotypes are specific meta classes, tagged values are usual meta attributes, and profiles specific packages. The following requirements have driven, since its beginning, the definition of the profile semantics: 1. A profile must provide mechanisms for specializing a reference meta-model (such as a set of UML packages) in such a way that the specialized semantics do not violate the semantics of the reference meta-model. That is, profile constraints may typically define well-formedness rules that are more constraining (but consistent with) those specified by the reference meta-model. 2. It must be possible to interchange profiles between tools, together with models to which they have been applied, by using the UML XMI interchange mechanisms. A profile must therefore be defined as an interchangeable UML model. In addition to exchanging profiles together with models between tools, profile application should also be definable .by reference. (e.g. .import by name.): in that way, a profile does not need to be interchanged if it is already present in the importing tool. 3. A profile must be able to reference the applicable subset of meta-classes from the UML meta-model. 4. A profile must be able to reference domain specific UML libraries where certain model elements are pre-defined. 5. It must be possible to specify the profiles applied to a given Package (and therefore its subclasses Model and Subsystem) or sub-Package. This is particularly useful during model interchange so that an importing environment can interpret a model correctly. 6. It should be possible to define a UML extension that combines profiles and model libraries (including template libraries) into a single logical unit. However, within such a unit, for definitional clarity and for ease of interchange (e.g. .reference by name.), it should still be possible to keep the various components distinct from each other. 7. A profile should be able to specialize the semantics of standard UML metamodel elements, e.g. in a model with the profile .Java model. generalization of classes should be able to be restricted to single inheritance, without having to explicitly assign a stereotype <> to each and every class instance. 8. A notational convention for graphical stereotype definitions as part of a profile should be provided. 9. In order to satisfy the requirement [1], UML Profiles should form a meta-model extension mechanism that imposes certain restrictions on how the UML meta-model can be modified. For instance, it is not possible to insert new meta-classes in the UML meta-class hierarchy (i.e. new super-classes for standard UML meta-classes). It is also not possible to modify the standard UML meta-class definitions, e.g. by adding meta-associations. Such restrictions do not apply in a MOF context where in principle any meta-model can be reworked in any direction. 10. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constraint these tools to have an internal implementation based on a meta-meta-model/meta-model architecture. 11. Profiles can be dynamically applied to or retracted from a model. It is possible on an existing model to apply new profiles, or to change the set of applied profiles. 12. Profiles can be dynamically combined. Frequently, several profiles will be applied at the same time on the same model. This profile combination is most of the time not foreseen at the profile definition time. 13. Models can be exchanged regardless of the profiles known by the destination target. The destination of the exchange of a model extended by a profile may not know the profile, and is not required to interpret a specific profile description. The destination environment interprets extensions, only if it possesses the required profiles. 2 Change in the text of Stereotype: semantics (Change) A stereotype is a limited kind of metaclass that cannot be used isolated, but must always be used in conjunction with one of the metaclasses it extends. Each stereotype may extend one or more classes through extensions as part of a profile. Similarly, a class may be extended by one or more stereotypes. An instance of a stereotype is linked to an instance of an extended metaclass (or stereotype) by virtue of the extension between their types. (Into) A stereotype is a limited kind of metaclass that cannot be used by itself, but must always be used in conjunction with one of the metaclasses it extends. Each stereotype may extend one or more classes through extensions as part of a profile. Similarly, a class may be extended by one or more stereotypes. An instance .S. of Stereotype is a kind of (meta) class. Relating it to a meta-class .C. from the reference metamodel (typically UML) using the .Extension. specific kind of association, specifies that model elements instantiating C can be extended by an instance of .S. (see example Figure 454). At the model level (such as in Figure 457) instances of the .S. are related to .C. model elements (instances of the .C.) by links (occurrences of the .S.è.C. association/extension). Any model element from the reference metamodel (any UML model element) can be extended by a stereotype. For example in UML, States, Transitions, Activities, Use cases, Components, Attributes, Dependencies, etc. can all be extended with stereotypes. 3 In Profile : semantics (add) The most direct implementation of the Profile mechanism that a tool can provide, is by having a metamodel based implementation, similar to the Profile metamodel. However, this is not a requirement of the current standard, which requires only the support of the specified notions, and the standard XMI based interchange capacities. The profile mechanism has been designed to be implementable by tools which do not have a metamodel based implementation. Many mechanisms able to attach new values to model elements can provide a valid profile implementation. As an example, the UML1.4 profile metamodel could be a basis for implementing a UML2.0 compliant profile tool. 4 in Package : Semantics Currently : No additional semantics. (Add) The association .appliedProfile. between a package and a profile crosses one metalevel : It links one element from a model(a package) to one element of the metamodel : profiles that defines the extensions applicable to the package. Although this kind of situation is rare in the UML metamodel, this only shows that model and metamodel can coexist on the same space, and can have links together. Issue 6347: Profiles in fixed repositories (uml2-superstructure-ftf) Click here for this issue's archive. Source: INCOSE (Mr. Sanford A. Friedenthal, sanford.friedenthal@lmco.com) Nature: Clarification Severity: Critical Summary: Do profiles working for fixed repositories in UML 2? My understanding is that they are at M3 now, so they wouldn't. If that's the case, then what is their purpose? The other feature of dynamically changing metaclasses is something a repository could provide if it was useful, instead of using stereotypes. Disposition: See the .Global change proposal. Global Change Proposal Almost all of the above issues will be solved by a global change to the profile spec. The intend is to clarify the meta aspects between profile and UML models, to recall the requirement driving the definition of profiles, so that the reader be more aware of the position of the profile spec. Disposition 1 Change the text in the overview of profiles (actual text) The Profiles package contains mechanisms that allow metaclasses from existing metamodels to be extended to adapt them for different purposes. This includes the ability to tailor the UML metamodel for different platforms (such as J2EE or .NET) or domains (such as real-time or business process modeling). The profiles mechanism is consistent with the OMG Meta Object Facility (MOF). (Add) Positioning profiles versus metamodels, MOF and UML: The infrastructure specification is reused at several meta-levels within thein various OMG specifications that deal with modeling. For example, MOF is reusinguses it forto provide having the capacitythe ability to model meta-modelmetamodels, whereas the UML superstructure reuses uses it to model the UML model. The ProfileThis chapter is coveringdeals with use cases comparable to the MOF at the meta-meta-level, which is for example one level above higher than the rest of the superstructure specification. For exampleThus, in this chapter, when we mention .Class., we designate most ofin most cases we are dealing with the time the meta-meta-classmetaclass .Class. from (used to definewhich for example every meta class of in the UML superstructure specification (Activity, Class, State, Use Case, etc.)) is instanciated. Profiles History and design requirements The Profile mechanism has been specifically defined for providing a lightweight extension mechanism to the UML standard. In UML 1.1, sStereotypes and tagged values were originately used as .string- based. extensions that can could be attached to UML model elements in a flexible way. Since In UML1.3, and more specifically UML1.4subsequent revisions of UML, the notion of a Profile has beenwas defined in order to structure provide more structure and precision to the definition of Stereotypes and Tagged values. The UML2.0 infrastructure and superstructure specifications have reinforced the formalization of the profile mechanismcarried this further, by defining it as a specific meta-modelingmodelling technique. Stereotypes are specific meta- classes, tagged values are usual standard meta attributes, and profiles specific are specific kinds of packages. The following requirements have driven, since its beginning, the definition of the profile semantics from inception: 1. A profile must provide mechanisms for specializing a reference meta-modelmetamodel (such as a set of UML packages) in such a way that the specialized semantics do not violate contradict the semantics of the reference meta-modelmetamodel. That is, profile constraints may typically define well-formedness rules that are more constraining (but consistent with) those specified by the reference meta-modelmetamodel. 2. It must be possible to interchange profiles between tools, together with models to which they have been applied, by using the UML XMI interchange mechanisms. A profile must therefore be defined as an interchangeable UML model. In addition to exchanging profiles together with models between tools, profile application should also be definable .by reference. (e.g. .import by name.): in that way, a profile does not need to be interchanged if it is already present in the importing tool. 3. A profile must be able to reference the applicable subset of meta-classmetaclasses from the UML meta-modelmetamodel. 4. A profile must be able to reference domain- specific UML libraries where certain model elements are pre-defined. 5. It must be possible to specify the which profiles are being applied to a given Package (and therefore its subclasses specializations Model and Subsystem) or sub-Package. This is particularly useful during model interchange so that an importing environment can interpret a model correctly. 6. It should be possible to define a UML extension that combines profiles and model libraries (including template libraries) into a single logical unit. However, within such a unit, for definitional clarity and for ease of interchange (e.g. .reference by name.), it should still be possible to keep the various components distinct from each other. 7. A profile should be able to specialize the semantics of standard UML metamodel elements, e.g., in a model with the profile .Java model. generalization of classes should be able to be restricted to single inheritance, without having to explicitly assign a stereotype «<> to each and every class instance. 8. A notational convention for graphical stereotype definitions as part of a profile should be provided. 9. In order to satisfy the requirement [1] above, UML Profiles should form a meta-modelmetamodel extension mechanism that imposes certain restrictions on how the UML meta-modelmetamodel can be modified. For instance, it is not possible to insert new meta-classes in the UML meta-classmetaclass hierarchy (i.e. new super-classes for standard UML meta-classes). It is also not possible to modify the standard UML meta-class definitions, e.g. by adding meta-associations. Such restrictions do not apply in a MOF context where in principle any meta-modelmetamodel can be reworked in any direction. 10. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constraint these tools to have an internal implementation based on a meta-meta-modelmetamodel/meta-modelmetamodel architecture. 11. Profiles can be dynamically applied to or retracted from a model. It is possible on an existing model to apply new profiles, or to change the set of applied profiles. 12. Profiles can be dynamically combined. Frequently, several profiles will be applied at the same time on the same model. This profile combination is most of the time not foreseen at the profile definition time. 13. Models can be exchanged regardless of the profiles known by the destination target. The destination of the exchange of a model extended by a profile may not know the profile, and is not required to interpret a specific profile description. The destination environment interprets extensions, only if it possesses the required profiles. 2 Change in the text of Stereotype: semantics (Change) A stereotype is a limited kind of metaclass that cannot be used isolatedisolated, but must always be used in conjunction with one of the metaclasses it extends. Each stereotype may extend one or more classes through extensions as part of a profile. Similarly, a class may be extended by one or more stereotypes. An instance of a stereotype is linked to an instance of an extended metaclass (or stereotype) by virtue of the extension between their types. (Into) A stereotype is a limited kind of metaclass that cannot be used by itself, but must always be used in conjunction with one of the metaclasses it extends. Each stereotype may extend one or more classes through extensions as part of a profile. Similarly, a class may be extended by one or more stereotypes. An instance .S. of Stereotype is a kind of (meta) class. Relating it to a meta-classmetaclass .C. from the reference metamodel (typically UML) using the .Extension. specific kind of association, specifies that model elements instantiating C can be extended by an instance of .S. (see example Figure 454). At the model level (such as in Figure 457) instances of the .S. are related to .C. model elements (instances of the .C.) by links (occurrences of the .S.è.C. association/extension). Any model element from the reference metamodel (any UML model element) can be extended by a stereotype. For example in UML, States, Transitions, Activities, Use cases, Components, Attributes, Dependencies, etc. can all be extended with stereotypes. 3 In Profile : semantics (add) The most direct implementation of the Profile mechanism that a tool can provide, is by having a metamodel based implementation, similar to the Profile metamodel. However, this is not a requirement of the current standard, which requires only the support of the specified notions, and the standard XMI based interchange capacities. The profile mechanism has been designed to be implementable by tools which that do not have a metamodel based implementation. Many mechanisms able to attach new values to model elements can provide a valid profile implementation. As an example, the UML1.4 profile metamodel could be a the basis for implementing a UML2.0- compliant profile tool. 4 in Package : Semantics Currently : No additional semantics. (AddReplace with) The association .appliedProfile. between a package and a profile crosses one metalevel : It links one element from a model (a package) to one an element of the metamodel : the set of profiles that defines the extensions applicable to the package. Although this kind of situation is rare in the UML metamodel, this only shows that model and metamodel can coexist on the same space, and can have links togetherbetween them. Subject: RE: Draft of Ballot 7 Date: Tue, 3 Feb 2004 10:12:47 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of Ballot 7 Thread-Index: AcPqHDUXSEAovukjSquUagm8xu/K8QASqFFQ From: "Pete Rivett" To: "Branislav Selic" , Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i13F1nJN015695 It seems that Issue 6199 is not addressed by the big solution to 6347, but by the reply that Philippe made to me: the last sentence at the bottom of page 571 states "In order to be able to navigate to the extended metaclass when writing constraints, the end must have a name. If no name is given, the default name is baseClass." What do you think Bran - it's your 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: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, February 02, 2004 10:03 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Draft of Ballot 7 Attached is the draft version of Ballot 7 -- scheduled to start this Wednesday (Feb. 4). So far, there are only 15 issues on this ballot -- well below our goal of 55 issues per ballot. If you have any other issues that you would like to add to the ballot (that qualify!), please send them to me no later than Tuesday night. Remember, only sure things should be proposed for the ballot. Please review this ballot and tell me if there are problems with it. Cheers, Bran Reply-To: From: "Conrad Bock" To: Subject: RE: Draft of Ballot 7, 6347 Date: Tue, 3 Feb 2004 16:23:26 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Philippe, Sorry for the late feedback on issue 6347. It's great to have clarification on profile requirements, but there is still not adequate explanation of how the abstract syntax works in a fixed repository. I'm surely missing something, but if the an extension is an association, as shown in Figure 446, it seems like the repository schema must be modified to extend a metaclass. The repository model example given in Figure 455, shows this, unless there is some trick in using an intance of class as a proxy for a metaclass. I'm willing to go along if everyone else understands how it works (please explain on this list), but otherwise, I'd suggest removing 6347 from the ballot until we can get some clearer wording for the semantics section of Stereotype and for Figure 455. Thanks, Conrad To: Cc: uml2-superstructure-ftf@omg.org Subject: RE: Draft of Ballot 7, 6347 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 3 Feb 2004 19:53:28 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/03/2004 19:53:30, Serialize complete at 02/03/2004 19:53:30 I will withdraw this issue from the ballot. Bran "Conrad Bock" 02/03/2004 04:23 PM Please respond to conrad.bock To: cc: Subject: RE: Draft of Ballot 7, 6347 Hi Philippe, Sorry for the late feedback on issue 6347. It's great to have clarification on profile requirements, but there is still not adequate explanation of how the abstract syntax works in a fixed repository. I'm surely missing something, but if the an extension is an association, as shown in Figure 446, it seems like the repository schema must be modified to extend a metaclass. The repository model example given in Figure 455, shows this, unless there is some trick in using an intance of class as a proxy for a metaclass. I'm willing to go along if everyone else understands how it works (please explain on this list), but otherwise, I'd suggest removing 6347 from the ballot until we can get some clearer wording for the semantics section of Stereotype and for Figure 455. Thanks, Conrad Reply-To: From: "DESFRAY Philippe" To: "'Branislav Selic'" , Cc: Subject: RE: Draft of Ballot 7, 6347 Date: Wed, 4 Feb 2004 11:27:34 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal OK, lets remove it for now, and work on clarification. However, I just find the word "repository" in this specification inappropriate and I am very reluctant to go to such an image. We are talking about metamodel specification, not about physical storage. We can speak about XMI and XMI correspondance, talk also on navigation issue for exampl to express OCL rules, and iterate working on clarification, which is certainly a good direction to pursue. Anyway, the express of concerns helps to find which kind of clarification is asked for. >>> it seems like the repository schema must be modified to extend a metaclass May be Pete's suggestion to show the Profile extension/MOF correspondance will clarify this. -- Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 4 février 2004 01:53 À : conrad.bock@nist.gov Cc : uml2-superstructure-ftf@omg.org Objet : RE: Draft of Ballot 7, 6347 I will withdraw this issue from the ballot. Bran "Conrad Bock" 02/03/2004 04:23 PM Please respond to conrad.bock To: cc: Subject: RE: Draft of Ballot 7, 6347 Hi Philippe, Sorry for the late feedback on issue 6347. It's great to have clarification on profile requirements, but there is still not adequate explanation of how the abstract syntax works in a fixed repository. I'm surely missing something, but if the an extension is an association, as shown in Figure 446, it seems like the repository schema must be modified to extend a metaclass. The repository model example given in Figure 455, shows this, unless there is some trick in using an intance of class as a proxy for a metaclass. I'm willing to go along if everyone else understands how it works (please explain on this list), but otherwise, I'd suggest removing 6347 from the ballot until we can get some clearer wording for the semantics section of Stereotype and for Figure 455. Thanks, Conrad Date: Wed, 04 Feb 2004 11:37:28 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: philippe.desfray@softeam.fr CC: "'Branislav Selic'" , conrad.bock@nist.gov, uml2-superstructure-ftf@omg.org Subject: Re: Draft of Ballot 7, 6347 X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE Philippe, Agreed that 'repository' is not something we should incorporate in the spec. Different tools use different persistence mechanisms, and repository is just one of them. I think the intention of the question might have been around applying profiles to a "fixed" (i.e. "specified") meta model definition, e.g. "the UML 2.0 meta model", and whether such a profile application would impact the definition of that meta model. Thanks, Guus DESFRAY Philippe wrote: OK, lets remove it for now, and work on clarification. However, I just find the word "repository" in this specification inappropriate and I am very reluctant to go to such an image. We are talking about metamodel specification, not about physical storage. We can speak about XMI and XMI correspondance, talk also on navigation issue for exampl to express OCL rules, and iterate working on clarification, which is certainly a good direction to pursue. Anyway, the express of concerns helps to find which kind of clarification is asked for. >>> it seems like the repository schema must be modified to extend a metaclass May be Pete's suggestion to show the Profile extension/MOF correspondance will clarify this. -- Philippe -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 4 février 2004 01:53 À : conrad.bock@nist.gov Cc : uml2-superstructure-ftf@omg.org Objet : RE: Draft of Ballot 7, 6347 I will withdraw this issue from the ballot. Bran "Conrad Bock" 02/03/2004 04:23 PM Please respond to conrad.bock To: cc: Subject: RE: Draft of Ballot 7, 6347 Hi Philippe, Sorry for the late feedback on issue 6347. It's great to have clarification on profile requirements, but there is still not adequate explanation of how the abstract syntax works in a fixed repository. I'm surely missing something, but if the an extension is an association, as shown in Figure 446, it seems like the repository schema must be modified to extend a metaclass. The repository model example given in Figure 455, shows this, unless there is some trick in using an intance of class as a proxy for a metaclass. I'm willing to go along if everyone else understands how it works (please explain on this list), but otherwise, I'd suggest removing 6347 from the ballot until we can get some clearer wording for the semantics section of Stereotype and for Figure 455. Thanks, Conrad -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Draft of Ballot 7, 6347 Date: Wed, 4 Feb 2004 09:50:52 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Hi Philippe. > However, I just find the word "repository" in this specification > inappropriate and I am very reluctant to go to such an image. As Guus said, we can clarify the relation of M1 and M2 in stereotypes without using the term "repository". In any case, requirement 10 refers to implementation and for many vendors avoiding change to their repository schema is the main reason for using stereotypes. Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: [profile] - Proposed issue resolution for profile issues assigned to me Date: Wed, 18 Feb 2004 13:33:24 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MS-TNEF-Correlator: Hi Philippe, Still couldn't get from the new text how the metaclass is referred to from the user model. In particular, the description of Figure 455, does not say what the :Class instance is. Is it a metaclass, ie, an actual element of the repository schema? If so, how can it referred to from a user model? Usually the elements of such schema are not available for that. Other text say this is possible, but not how: The association "appliedProfile" between a package and a profile crosses one metalevel: It links one element from a model (a package) to an element of the metamodel: the set of profiles that define the extensions applicable to the package. Although this kind of situation is rare in the UML metamodel, this only shows that model and metamodel can coexist on the same space, and can have links between them. If :Class is actually in the user model, then I gather it is a "shadow" copy of the schema element, is that right? Issue 6347 is just a simple request for more information about Figure 455, really. The proposed text is not needed for that. Conrad eply-To: From: "DESFRAY Philippe" To: , , Subject: RE: [profile] - Proposed issue resolution for profile issues assigned to me Date: Thu, 19 Feb 2004 10:28:45 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A8C43AA000 Conrad, I am still struggeling to find what is unclear there. Lets give another try to see if further explainations fits your question. I have put more emphasis in the amended text to explain that we are at the meta-meta level. Figure 455 is the instance model of Figure 454. this instance model is at the meta level of UML. - ... what the :Class instance is... ? the "Class" UML metaclass is an instance of the "Class" meta-meta class. So its name is "Class". >>> If so, how can it referred to from a user model? No less no more than any metaclass defined at the UML metamodel level. Fondamentally a Class is associated to a Stereotype, just like it is associated to an attribute. At the model level, you navigate between the occurences using the usual navigation rules. And you are right to say that this instance model in Figure 455 is just a picture of a (kind of) repository of the metamodel that is of little interest to understand how to navigate at the model level. The latest upodate I have provided explains how to write OCL rules which navigate between the extended model elements and the extension elements. I believe that the explaination you are looking for is there and not around Figure 455. -- Philippe -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoyé : mercredi 18 février 2004 19:33 À : uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Objet : RE: [profile] - Proposed issue resolution for profile issues assigned to me Hi Philippe, Still couldn't get from the new text how the metaclass is referred to from the user model. In particular, the description of Figure 455, does not say what the :Class instance is. Is it a metaclass, ie, an actual element of the repository schema? If so, how can it referred to from a user model? Usually the elements of such schema are not available for that. Other text say this is possible, but not how: The association "appliedProfile" between a package and a profile crosses one metalevel: It links one element from a model (a package) to an element of the metamodel: the set of profiles that define the extensions applicable to the package. Although this kind of situation is rare in the UML metamodel, this only shows that model and metamodel can coexist on the same space, and can have links between them. If :Class is actually in the user model, then I gather it is a "shadow" copy of the schema element, is that right? Issue 6347 is just a simple request for more information about Figure 455, really. The proposed text is not needed for that. Conrad winmail3.dat Reply-To: From: "Conrad Bock" To: , Subject: RE: [profile] - the Proposed issue resolution for profile issues Date: Sun, 7 Mar 2004 08:57:13 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MS-TNEF-Correlator: Importance: Normal Hi Philippe, Very sorry for not responding on 6347. I want to propose a simpler resolution. It is not clear that Figure 455 is a *user model*, is, it is stored in their fixed-schema repository at M1. The rest of the text in the chapter says that stereotypes are at M2. By the time readers get to Figure 455, they are prepared to see a modification of M2. Stereotypes are only conceptually at M2, but are stored at M1, and those two aspects of Stereotypes need to be explained. My suggestions below. Conrad As explanation to Figure 455: Figure 455 shows a user model for Figure 454. It is stored in the user's repository, even though conceptually stereotypes extend the UML metamodel. The UML metamodel is referred to in Figure 455 by the creating a proxy for the metaclass being extended, which is the object labelled :Class. The name of the proxy is the name of the metaclass being extended. Note that in order to be able to write constraints on the stereotype Clock that should be applied to the metaclass Class or any of its relationships, it is necessary to give the end typed by the metaclass proxy a name for navigation purposes. A typical such name would be for example "base". If you want, go through the rest of the chapter and clarify that instances of the metaclass Stereotype are in the user model, there is no change to the UML metamodel. This would apply whenever the text says that stereotypes are at the metalevel. I would drop the design requirements and background, they don't really clarify the distinction between the conceptual versus actual aspects Stereotype. Reply-To: From: "DESFRAY Philippe" To: , , Subject: RE: [profile] - the Proposed issue resolution for profile issues Date: Mon, 8 Mar 2004 10:04:36 +0100 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: 0000000000C3B727BFC1BC11A4646E0283BD88A824ADA100 Conrad, Thanks for your proposal. There has been many feedbacks regarding profiles, that is why I would not drop the other explainations including background. I feel that people coming from different angles of view have different misunderstanding on profiles, and there is a strong need for explainations. I am not too confortable with the explainations in your text mentioning the "user's repository" (what is it in the spec?), but I think I see which kind of explaination you require. I will rephrase it (at the risk of further iterations). Cheers -- Philippe -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoyé : dimanche 7 mars 2004 14:57 À : uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Objet : RE: [profile] - the Proposed issue resolution for profile issues Hi Philippe, Very sorry for not responding on 6347. I want to propose a simpler resolution. It is not clear that Figure 455 is a *user model*, is, it is stored in their fixed-schema repository at M1. The rest of the text in the chapter says that stereotypes are at M2. By the time readers get to Figure 455, they are prepared to see a modification of M2. Stereotypes are only conceptually at M2, but are stored at M1, and those two aspects of Stereotypes need to be explained. My suggestions below. Conrad As explanation to Figure 455: Figure 455 shows a user model for Figure 454. It is stored in the user's repository, even though conceptually stereotypes extend the UML metamodel. The UML metamodel is referred to in Figure 455 by the creating a proxy for the metaclass being extended, which is the object labelled :Class. The name of the proxy is the name of the metaclass being extended. Note that in order to be able to write constraints on the stereotype Clock that should be applied to the metaclass Class or any of its relationships, it is necessary to give the end typed by the metaclass proxy a name for navigation purposes. A typical such name would be for example "base". If you want, go through the rest of the chapter and clarify that instances of the metaclass Stereotype are in the user model, there is no change to the UML metamodel. This would apply whenever the text says that stereotypes are at the metalevel. I would drop the design requirements and background, they don't really clarify the distinction between the conceptual versus actual aspects Stereotype. Reply-To: From: "Cris Kobryn" To: "'Branislav Selic'" , Cc: Subject: RE: Draft of ballot 10: speak up now or forever keep your peace Date: Wed, 17 Mar 2004 12:58:10 -0800 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQLhS3KWnjcSpVQS8OTcxr0zLY1zwAqpTSg > Here is your chance to review what is currently proposed to be on ballot > 10. There are 59 resolutions in all (good job folks!). > > Note that the resolution to issue 7159 contains the entire new Classes > chapter, reorganized to conform to other chapter numbers. The entire PDF > file is embedded in the resolution section (tell me if you have problems > reading it). Note that, to separate the chapter reorganization from the > resolution to the package merge and compliance points issues, a new issue > was created for this purpose. This was done to minimize the amount of > duplicate editing that would need to be done and nicely stages the > solution to the package merge problem (if we adopt the proposed > resolution, of course). Note also that this chapter has the hyperlinks to > the parent classes (called "Generalizations"). I plan to add this to the > rest of the document, but that is to be addressed as a separate issue > (there is an issue just for that in the database). > > Please do review these issue resolutions: as I said before, this is the > time to complain about anything that you find objectionable, not after the > vote commences. (I realize that this is not always feasible, but we should > (shall?) do our best.) I object to including issues 7159 and 6347 and their proposed resolutions on this ballot. Re Issue 6347: Issue 6347 asks for a clarification regarding whether "profiles [work] for fixed repositories in UML 2." The approximately 6 pages of recommended changes never clearly answer this question, and compound the confusion regarding metalayers and other meta terminology using inconsistent and imprecise language. For example, the first paragraph proposed to be added states that "when we mention 'Class', in most cases we are dealing with the meta-metaclass 'Class'", even though in the rest of the Superstructure spec this typically refers to a metaclass. A later proposed paragraph discusses an "instance 'S' of Stereotype is a kind of (meta) class. Relating it to a metaclass 'C' ..." So what's the difference here between a stereotype, a metaclass, a "kind of metaclass" and a "kind of (meta) class"? (BTW, I would provide specific references to the paragraphs cited above, but the proposal itself lacks them. All proposals, especially lengthy ones such as thes,e should include specific references (page, section, paragraph) to the areas where we are proposing changes.) At the very least the response to issue 6347 should include a clear, concise response to the specific questions being asked. It also should provide clear, concise definitions for the relevant meta terms (stereotype vs. metaclass vs. meta-metaclass) and use them consistently here and in other parts of the UML 2 specifications. Re Issue 7147: "The Classes chapter is organized differently from all other chapters in the document -- it should be made consistent with the organization of all the other chapters." This Classes chapter was organized differently *intentionally* by the UML 2 submitters, in order to facilitate readability and share common content with the Infrastructure specification. As with most issues of this sort, there are advantages and disadvantages with both approaches. In general, I oppose any large scale changes of this sort in an FTF where the value is highly questionable. They introduce the likelihood of introducing new errors, require a long time for review, and violate one of the FTF/RTF's basic principles of operation: we should specify all proposed changes in such a manner that a non-UML expert (e.g., Linda Heaton) can make the changes. This is clearly a large-scale violation of that principle which establishes a bad precedent for future work. -- Cris Subject: RE: Draft of ballot 10: speak up now or forever keep your peace Date: Wed, 17 Mar 2004 21:53:36 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of ballot 10: speak up now or forever keep your peace Thread-Index: AcQLhS3KWnjcSpVQS8OTcxr0zLY1zwAqpTSgABa5xmA= From: "Pete Rivett" To: , "Branislav Selic" , Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i2I2jUre022240 Although 6347 did go into the ballot I feel the need to respond to the points made by Cris - in case they influence people to vote NO to the resolution in the ballot. Personally I think the proposed resolution is a dramatic improvement over the current chapter. It has already undergone a fair amount of iteration after input from several people (myself included). While it is not perfect, I think it is good enough: in the interests of an *efficient process* (where have I heard that recently?) I think we need to be able to detect when we've done enough (the perfect is the enemy of the good). A general question to ask ourselves when looking at a resolution: if I saw the resolution as a part of the spec would I have so much of a problem that I'd raise an issue about it? Furthermore, if I was on the receiving end of the issue (in the RTF) would I consider it worth expending energy on resolving? If the answer to either of these is 'no' then I'd suggest that people think hard before objecting to it/voting against it and ask whether it is just slowing the process for not a lot of added value. See point-by-point responses below. 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 > -----Original Message----- > From: Cris Kobryn [mailto:cris.kobryn@telelogic.com] > Sent: Wednesday, March 17, 2004 8:58 PM > To: 'Branislav Selic'; uml2-superstructure-ftf@omg.org > Cc: mu2i-ftf@omg.org > Subject: RE: Draft of ballot 10: speak up now or forever keep > your peace ----snip---- > I object to including issues 7159 and 6347 and their proposed > resolutions on > this ballot. > > Re Issue 6347: Issue 6347 asks for a clarification regarding whether > "profiles [work] for fixed repositories in UML 2." The > approximately 6 pages > of recommended changes never clearly answer this question, IMHO the following statement from the resolution *does* clearly and concisely answer the above question: "The profile mechanism has been designed to be implementable by tools that do not have a metamodel-based implementation. Practically any mechanism used to attach new values to model elements can serve as a valid profile implementation. As an example, the UML1.4 profile metamodel could be the basis for implementing a UML2.0-compliant profile tool." BTW this is in part 3 of the resolution which has the heading "3 In Profile : semantics " which is good enough for me to locate its intended location in the spec. > and compound the > confusion regarding metalayers and other meta terminology > using inconsistent > and imprecise language. For example, the first paragraph > proposed to be > added states that "when we mention 'Class', in most cases we > are dealing > with the meta-metaclass 'Class'", even though in the rest of the > Superstructure spec this typically refers to a metaclass. A > later proposed > paragraph discusses an "instance 'S' of Stereotype is a kind of (meta) > class. Relating it to a metaclass 'C' ..." So what's the > difference here > between a stereotype, a metaclass, a "kind of metaclass" and > a "kind of > (meta) class"? The last question is answered in the Profiles chapter as a whole. Individual sentences may be confusing taken out of context, but as a whole, with the aid of instance diagrams of the metamodel such as Figure 455, it makes sense to me. It does take careful reading, but this are non-trivial concepts being explained here. > > (BTW, I would provide specific references to the paragraphs > cited above, but > the proposal itself lacks them. All proposals, especially > lengthy ones such > as thes,e should include specific references (page, section, > paragraph) to > the areas where we are proposing changes.) The resolution does provide clear unambiguous editing instructions by citing not only the location but the precisely the old text to be replaced by each chunk of new text. The location is underlined and specified by section heading rather than section number, for example: "1 Change the text in the overview of profiles", "2 Change in the text of Stereotype: semantics". The whole chapter is fairly short and it is not hard to find the locations quoted: I certainly do not see it as a reason to hold back the issue (we have in fact approved resolutions that have been a lot more vague in where they apply). > > At the very least the response to issue 6347 should include a > clear, concise > response to the specific questions being asked. It also should provide > clear, concise definitions for the relevant meta terms (stereotype vs. > metaclass vs. meta-metaclass) and use them consistently here > and in other > parts of the UML 2 specifications. I don't think the Profiles chapter is the place to define terms like metaclass and meta-metaclass. Chapter 7 of Infrastructure, Language Architecture (which is for all of UML including Superstructure), covers meta-levels and relationship between UML and MOF in a fair amount of detail, and it does not make sense to repeat it in Profiles. If chapter 7 is not clear enough a separate issue should be raised on Infrastructure. Similarly, inconsistent use of terms "in other parts of the UML 2 specification" should be dealt with by raising specific issues (specifying page, section and paragraph numbers of course). The only thing needed here is a clear definition of Stereotype --- snip --- > > -- Cris > > > > > > >